make rain(6) use a sane default delay
rain(6) is useless. but still it should provide sane defaults
ihmo. ok?
Index: rain.6
===
RCS file: /cvs/OpenBSD/src/games/rain/rain.6,v
retrieving revision 1.14
diff -u -r1.14 rain.6
--- rain.6 31 May 2007 19:19:18 - 1.14
+++ rain.6 21 Mar 2011 06:52:36 -
@@ -47,7 +47,7 @@
or the
.Fl d
option must be used to specify a delay, in milliseconds, between each update.
-A reasonable delay is 120; the default is 0.
+The default is 120.
.Pp
As with any
.Xr curses 3
Index: rain.c
===
RCS file: /cvs/OpenBSD/src/games/rain/rain.c,v
retrieving revision 1.15
diff -u -r1.15 rain.c
--- rain.c 27 Oct 2009 23:59:26 - 1.15
+++ rain.c 21 Mar 2011 06:52:36 -
@@ -52,7 +52,7 @@
{
int x, y, j;
long tcols, tlines;
- u_int delay = 0;
+ u_int delay = 12;
int ch;
int xpos[5], ypos[5];
--
Matthieu Herrb
Re: make rain(6) use a sane default delay
On 3/21/11, Matthieu Herrb matthieu.he...@laas.fr wrote:
rain(6) is useless. but still it should provide sane defaults
ihmo. ok?
Or use sane defaults based on terminal speed; like worms(8) does.
Index: rain.6
===
RCS file: /cvs/src/games/rain/rain.6,v
retrieving revision 1.14
diff -u -r1.14 rain.6
--- rain.6 31 May 2007 19:19:18 - 1.14
+++ rain.6 21 Mar 2011 07:39:02 -
@@ -43,11 +43,18 @@
is modeled after the
.Tn VAX/VMS
program of the same name.
-To obtain the proper effect, either the terminal must be set for 9600 baud
-or the
-.Fl d
-option must be used to specify a delay, in milliseconds, between each update.
-A reasonable delay is 120; the default is 0.
+.Pp
+The options are as follows:
+.Bl -tag -width -l length
+.It Fl d Ar delay
+Specifies a delay, in milliseconds, between each update.
+This is useful for fast terminals.
+Reasonable values are around 20-200.
+The default is based on the terminal speed.
+If the terminal is 9600 baud or slower no delay is used.
+Otherwise, the delay is computed via the following formula:
+.Dl delay = speed / 9600 - 1.
+.El
.Pp
As with any
.Xr curses 3
Index: rain.c
===
RCS file: /cvs/src/games/rain/rain.c,v
retrieving revision 1.15
diff -u -r1.15 rain.c
--- rain.c 27 Oct 2009 23:59:26 - 1.15
+++ rain.c 21 Mar 2011 07:31:37 -
@@ -40,6 +40,7 @@
#include signal.h
#include stdio.h
#include stdlib.h
+#include termios.h
#include unistd.h
volatile sig_atomic_t sig_caught = 0;
@@ -55,6 +56,13 @@
u_int delay = 0;
int ch;
int xpos[5], ypos[5];
+ struct termios term;
+ speed_t speed;
+
+ /* set default delay based on terminal baud rate */
+ if (tcgetattr(STDOUT_FILENO, term) == 0
+ (speed = cfgetospeed(term)) B9600)
+ delay = (speed / B9600) - 1;
while ((ch = getopt(argc, argv, d:h)) != -1)
switch(ch) {
Re: make rain(6) use a sane default delay
On 03/21/11 08:46, Martynas Venckus wrote:
On 3/21/11, Matthieu Herrb matthieu.he...@laas.fr wrote:
rain(6) is useless. but still it should provide sane defaults
ihmo. ok?
Or use sane defaults based on terminal speed; like worms(8) does.
For this kind of app (which is indeed quite a waste of space), I find
120 a sane enough default for any terminal.
The suggested diff is OK with me.
/Alexander
Index: rain.6
===
RCS file: /cvs/src/games/rain/rain.6,v
retrieving revision 1.14
diff -u -r1.14 rain.6
--- rain.631 May 2007 19:19:18 - 1.14
+++ rain.621 Mar 2011 07:39:02 -
@@ -43,11 +43,18 @@
is modeled after the
.Tn VAX/VMS
program of the same name.
-To obtain the proper effect, either the terminal must be set for 9600 baud
-or the
-.Fl d
-option must be used to specify a delay, in milliseconds, between each update.
-A reasonable delay is 120; the default is 0.
+.Pp
+The options are as follows:
+.Bl -tag -width -l length
+.It Fl d Ar delay
+Specifies a delay, in milliseconds, between each update.
+This is useful for fast terminals.
+Reasonable values are around 20-200.
+The default is based on the terminal speed.
+If the terminal is 9600 baud or slower no delay is used.
+Otherwise, the delay is computed via the following formula:
+.Dl delay = speed / 9600 - 1.
+.El
.Pp
As with any
.Xr curses 3
Index: rain.c
===
RCS file: /cvs/src/games/rain/rain.c,v
retrieving revision 1.15
diff -u -r1.15 rain.c
--- rain.c27 Oct 2009 23:59:26 - 1.15
+++ rain.c21 Mar 2011 07:31:37 -
@@ -40,6 +40,7 @@
#include signal.h
#include stdio.h
#include stdlib.h
+#include termios.h
#include unistd.h
volatile sig_atomic_t sig_caught = 0;
@@ -55,6 +56,13 @@
u_int delay = 0;
int ch;
int xpos[5], ypos[5];
+ struct termios term;
+ speed_t speed;
+
+ /* set default delay based on terminal baud rate */
+ if (tcgetattr(STDOUT_FILENO, term) == 0
+ (speed = cfgetospeed(term)) B9600)
+ delay = (speed / B9600) - 1;
while ((ch = getopt(argc, argv, d:h)) != -1)
switch(ch) {
Re: make rain(6) use a sane default delay
On 03/21/11 10:18, Alexander Hall wrote: On 03/21/11 08:46, Martynas Venckus wrote: On 3/21/11, Matthieu Herrb matthieu.he...@laas.fr wrote: rain(6) is useless. but still it should provide sane defaults ihmo. ok? Or use sane defaults based on terminal speed; like worms(8) does. For this kind of app (which is indeed quite a waste of space), I find 120 a sane enough default for any terminal. The suggested diff is OK with me. Oh, referring to the diff suggested bu Mattheiu, that is. The worms approach just feels like overkill and the formula makes little sense. /Alexander
Re: make rain(6) use a sane default delay
On 2011/03/21 07:54, Matthieu Herrb wrote: rain(6) is useless. far from it, it's a useful network latency and jitter tester with an intuitive visual output :-) but still it should provide sane defaults ihmo. ok? ok.
ls(1) displays future timestamps improperly
Hi list,
If I touch(1) a file to a future date (or, for example, extract a tar
archive from a system with an incorrect system clock), ls -l doesn't
indicate that unless you use -T as well.
That is, ls shows a misleading timestamp for that use case.
All unixes I've worked with (including OpenBSD) shows the year instead
of hours:minutes if a file is more than six months old.
Most also show the year instead of time if a file is newer than the
current time, which in my opinion is far better than silently
suppressing that vital bit of information.
This diff makes ls(1) do that for us as well.
I've included an arbitrary grace time of a few seconds to avoid the
possibility of someone just touching a file just to find that an
immediate ls -l displays an unexpected timestamp format (seriously quick
fingers would be required).
Works like this:
bl@skynet:/tmp$ date
Mon Mar 21 11:36:14 CET 2011
bl@skynet:/tmp$ touch qwerty
bl@skynet:/tmp$ ls -l qwerty
-rw-rw-r-- 1 bl wheel 0 Mar 21 11:36 qwerty
bl@skynet:/tmp$ ls -lT qwerty
-rw-rw-r-- 1 bl wheel 0 Mar 21 11:36:16 2011 qwerty
bl@skynet:/tmp$ touch -t 202001020304.05 qwerty
bl@skynet:/tmp$ ls -l qwerty
-rw-rw-r-- 1 bl wheel 0 Jan 2 03:04 qwerty --- Misleading time
bl@skynet:/tmp$ ls -lT qwerty
-rw-rw-r-- 1 bl wheel 0 Jan 2 03:04:05 2020 qwerty
bl@skynet:/tmp$ /usr/obj/bin/ls/ls -l qwerty
-rw-rw-r-- 1 bl wheel 0 Jan 2 2020 qwerty --- Correct time
bl@skynet:/tmp$
Tested on amd64.
Regards,
/Benny
88888 (cut)
Index: print.c
===
RCS file: /cvs/src/bin/ls/print.c,v
retrieving revision 1.27
diff -u -r1.27 print.c
--- print.c 12 Sep 2010 20:16:29 - 1.27
+++ print.c 21 Mar 2011 10:20:34 -
@@ -235,6 +235,7 @@
{
int i;
char *longstring;
+ time_t now = time(NULL);
longstring = ctime(ftime);
for (i = 4; i 11; ++i)
@@ -244,7 +245,7 @@
if (f_sectime)
for (i = 11; i 24; i++)
(void)putchar(longstring[i]);
- else if (ftime + SIXMONTHS time(NULL))
+ else if (ftimenow-SIXMONTHS ftimenow+5) // a few grace secs
for (i = 11; i 16; ++i)
(void)putchar(longstring[i]);
else {
88888 (cut)
--
internetlabbet.se / work: +46 8 551 124 80 / Words must
Benny Lvfgren/ mobile: +46 70 718 11 90 / be weighed,
/ fax:+46 8 551 124 89/not counted.
/email: benny -at- internetlabbet.se
Re: pcap icmptype support
On Wed, Feb 02, 2011 at 06:49:26PM +0100, Giovanni Bechis wrote:
This diff adds support to icmptype grammar to libpcap.
With this diff we can do:
$ sudo tcpdump -netttv -i nfe0 icmp[icmptype] = 8
and capture only echo requests.
This diff is needed for an upcoming nmap update.
Comments ? ok ?
Looks good to me. Would be good to update the tcpdump manpage to show how
these keywords are used.
OK claudio@
Cheers
Giovanni
Index: scanner.l
===
RCS file: /cvs/src/lib/libpcap/scanner.l,v
retrieving revision 1.21
diff -u -p -r1.21 scanner.l
--- scanner.l 27 Oct 2009 23:59:30 - 1.21
+++ scanner.l 2 Feb 2011 17:39:32 -
@@ -270,6 +270,30 @@ address4|addr4 return ADDR4;
#endif /*INET6*/
}
{B}:+({B}:+)+{ bpf_error(bogus ethernet address %s,
yytext); }
+icmptype { yylval.i = 0; return NUM; }
+icmpcode { yylval.i = 1; return NUM; }
+icmp-echoreply { yylval.i = 0; return NUM; }
+icmp-unreach { yylval.i = 3; return NUM; }
+icmp-sourcequench{ yylval.i = 4; return NUM; }
+icmp-redirect{ yylval.i = 5; return NUM; }
+icmp-echo{ yylval.i = 8; return NUM; }
+icmp-routeradvert{ yylval.i = 9; return NUM; }
+icmp-routersolicit { yylval.i = 10; return NUM; }
+icmp-timxceed{ yylval.i = 11; return NUM; }
+icmp-paramprob { yylval.i = 12; return NUM; }
+icmp-tstamp { yylval.i = 13; return NUM; }
+icmp-tstampreply { yylval.i = 14; return NUM; }
+icmp-ireq{ yylval.i = 15; return NUM; }
+icmp-ireqreply { yylval.i = 16; return NUM; }
+icmp-maskreq { yylval.i = 17; return NUM; }
+icmp-maskreply { yylval.i = 18; return NUM; }
+tcpflags { yylval.i = 13; return NUM; }
+tcp-fin { yylval.i = 0x01; return NUM; }
+tcp-syn { yylval.i = 0x02; return NUM; }
+tcp-rst { yylval.i = 0x04; return NUM; }
+tcp-push { yylval.i = 0x08; return NUM; }
+tcp-ack { yylval.i = 0x10; return NUM; }
+tcp-urg { yylval.i = 0x20; return NUM; }
[A-Za-z0-9][-_.A-Za-z0-9]*[.A-Za-z0-9] {
yylval.s = sdup((char *)yytext); return ID; }
[A-Za-z] {yylval.s = sdup((char *)yytext); return ID; }
--
:wq Claudio
tcpdump fix for OSPF
Some crappy systems seem to send out packets with very strange lenght
fields. In my particular case the IP length is 64 bytes (overall packet)
but the ospf length is 32 bytes and therefor 12 bytes short. The box seems
to add some crap as padding (I bet uninitialized memory).
Tcpdump does not like this situation and would not print the packet. I
changed the code to allow such padded ip packets (since ospfd accepts them
as well).
Comments, OKs?
--
:wq Claudio
Index: print-ospf.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-ospf.c,v
retrieving revision 1.15
diff -u -p -r1.15 print-ospf.c
--- print-ospf.c4 Aug 2010 16:47:01 - 1.15
+++ print-ospf.c23 Feb 2011 13:38:42 -
@@ -520,15 +520,19 @@ ospf_print(register const u_char *bp, re
/* value. If it's not valid, say so and return */
TCHECK(op-ospf_type);
cp = tok2str(type2str, type%d, op-ospf_type);
- printf( OSPFv%d-%s %d:, op-ospf_version, cp, length);
+ printf( OSPFv%d-%s , op-ospf_version, cp);
if (*cp == 't')
return;
TCHECK(op-ospf_len);
- if (length != ntohs(op-ospf_len)) {
+ if (length ntohs(op-ospf_len)) {
printf( [len %d], ntohs(op-ospf_len));
return;
- }
+ } else if (length ntohs(op-ospf_len)) {
+ printf( %d[%d]:, ntohs(op-ospf_len), length);
+ length = ntohs(op-ospf_len);
+ } else
+ printf( %d:, length);
dataend = bp + length;
/* Print the routerid if it is not the same as the source */
Re: upl(4) buffer length validation
Hi,
Jasper pointed out that the minimum length should be 1.
Plese test !
Index: src/sys/dev/usb/if_upl.c
===
RCS file: /cvs/src/sys/dev/usb/if_upl.c,v
retrieving revision 1.47
diff -u -p -r1.47 if_upl.c
--- src/sys/dev/usb/if_upl.c25 Jan 2011 20:03:35 - 1.47
+++ src/sys/dev/usb/if_upl.c21 Mar 2011 18:51:02 -
@@ -494,6 +494,11 @@ upl_rxeof(usbd_xfer_handle xfer, usbd_pr
DPRINTFN(9,(%s: %s: enter status=%d length=%d\n,
sc-sc_dev.dv_xname, __func__, status, total_len));
+ if (total_len = 1 || total_len UPL_BUFSZ) {
+ ifp-if_ierrors++;
+ goto done;
+ }
+
m = c-upl_mbuf;
memcpy(mtod(c-upl_mbuf, char *), c-upl_buf, total_len);
Re: [PATCH] frame length validation for USB ethernet adapters
Hi,
I updated the diff for axe(4) based on what Laurent
sent me. He says the patch breaks his axe(4).
I also added a comment to explain why it's done,
in areas where there's a status bit called RX_STATUS.
This is based on an issue I encountered with udav(4),
wherein despite having a valid status bit, the
frame length was bogus.
It's even more important that we test this on as much
USB adapters as possible.
Thanks to the users who are doing a good job at testing
the diffs.
Index: src/sys/dev/usb/if_axe.c
===
RCS file: /cvs/src/sys/dev/usb/if_axe.c,v
retrieving revision 1.105
diff -u -p -r1.105 if_axe.c
--- src/sys/dev/usb/if_axe.c25 Jan 2011 20:03:35 - 1.105
+++ src/sys/dev/usb/if_axe.c21 Mar 2011 19:00:17 -
@@ -1018,7 +1018,8 @@ axe_rxeof(usbd_xfer_handle xfer, usbd_pr
do {
if (sc-axe_flags AX178 || sc-axe_flags AX772) {
- if (total_len sizeof(hdr)) {
+ if (total_len sizeof(hdr) ||
+ total_len sc-axe_bufsz) {
ifp-if_ierrors++;
goto done;
}
@@ -1048,8 +1049,15 @@ axe_rxeof(usbd_xfer_handle xfer, usbd_pr
else
total_len -= pktlen;
} else {
+ if (total_len sizeof(hdr) ||
+ total_len sc-axe_bufsz) {
+ ifp-if_ierrors++;
+ goto done;
+ }
+ else {
pktlen = total_len; /* crc on the end? */
total_len = 0;
+ }
}
m = axe_newbuf();
Index: src/sys/dev/usb/if_aue.c
===
RCS file: /cvs/src/sys/dev/usb/if_aue.c,v
retrieving revision 1.84
diff -u -p -r1.84 if_aue.c
--- src/sys/dev/usb/if_aue.c25 Jan 2011 20:03:35 - 1.84
+++ src/sys/dev/usb/if_aue.c21 Mar 2011 19:00:23 -
@@ -1078,12 +1078,13 @@ aue_rxeof(usbd_xfer_handle xfer, usbd_pr
usbd_get_xfer_status(xfer, NULL, NULL, total_len, NULL);
- memcpy(mtod(c-aue_mbuf, char *), c-aue_buf, total_len);
-
- if (total_len = 4 + ETHER_CRC_LEN) {
+ /* frame may still be valid but length is bogus */
+ if (total_len = 4 + ETHER_CRC_LEN || total_len AUE_BUFSZ) {
ifp-if_ierrors++;
goto done;
}
+
+ memcpy(mtod(c-aue_mbuf, char *), c-aue_buf, total_len);
memcpy(r, c-aue_buf + total_len - 4, sizeof(r));
Index: src/sys/dev/usb/if_cdce.c
===
RCS file: /cvs/src/sys/dev/usb/if_cdce.c,v
retrieving revision 1.49
diff -u -p -r1.49 if_cdce.c
--- src/sys/dev/usb/if_cdce.c 25 Jan 2011 20:03:35 - 1.49
+++ src/sys/dev/usb/if_cdce.c 21 Mar 2011 19:00:25 -
@@ -776,8 +776,11 @@ cdce_rxeof(usbd_xfer_handle xfer, usbd_p
usbd_get_xfer_status(xfer, NULL, NULL, total_len, NULL);
if (sc-cdce_flags CDCE_ZAURUS)
total_len -= 4; /* Strip off CRC added by Zaurus */
- if (total_len = 1)
+
+ if (total_len = 1 || total_len CDCE_BUFSZ) {
+ ifp-if_ierrors++;
goto done;
+ }
m = c-cdce_mbuf;
memcpy(mtod(m, char *), c-cdce_buf, total_len);
Index: src/sys/dev/usb/if_cue.c
===
RCS file: /cvs/src/sys/dev/usb/if_cue.c,v
retrieving revision 1.59
diff -u -p -r1.59 if_cue.c
--- src/sys/dev/usb/if_cue.c25 Jan 2011 20:03:35 - 1.59
+++ src/sys/dev/usb/if_cue.c21 Mar 2011 19:00:29 -
@@ -738,6 +738,11 @@ cue_rxeof(usbd_xfer_handle xfer, usbd_pr
usbd_get_xfer_status(xfer, NULL, NULL, total_len, NULL);
+ if (total_len sizeof(struct ether_header) ||total_len CUE_BUFSZ) {
+ ifp-if_ierrors++;
+ goto done;
+ }
+
memcpy(mtod(c-cue_mbuf, char *), c-cue_buf, total_len);
m = c-cue_mbuf;
Index: src/sys/dev/usb/if_kue.c
===
RCS file: /cvs/src/sys/dev/usb/if_kue.c,v
retrieving revision 1.63
diff -u -p -r1.63 if_kue.c
--- src/sys/dev/usb/if_kue.c25 Jan 2011 20:03:35 - 1.63
+++ src/sys/dev/usb/if_kue.c21 Mar 2011 19:00:34 -
@@ -741,8 +741,10 @@ kue_rxeof(usbd_xfer_handle xfer, usbd_pr
__func__, total_len,
UGETW(mtod(c-kue_mbuf, u_int8_t *;
- if (total_len = 1)
+ if (total_len = 1 || total_len KUE_BUFSZ) {
+ ifp-if_ierrors++;
goto done;
+ }
m = c-kue_mbuf;
/* copy data to mbuf */
Index: src/sys/dev/usb/if_mos.c
Re: ls(1) displays future timestamps improperly
On Mon, Mar 21, 2011 at 12:04:33PM +0100, Benny Lofgren wrote:
Realized I was sloppy with KNF. This diff is hopefully neater looking.
Regards,
/Benny
888888 (cut)
Index: print.c
===
RCS file: /cvs/src/bin/ls/print.c,v
retrieving revision 1.27
diff -u -r1.27 print.c
--- print.c 12 Sep 2010 20:16:29 - 1.27
+++ print.c 21 Mar 2011 10:57:38 -
@@ -235,6 +235,7 @@
{
int i;
char *longstring;
+ time_t now = time(NULL);
longstring = ctime(ftime);
for (i = 4; i 11; ++i)
@@ -244,7 +245,7 @@
if (f_sectime)
for (i = 11; i 24; i++)
(void)putchar(longstring[i]);
- else if (ftime + SIXMONTHS time(NULL))
+ else if (ftime now - SIXMONTHS ftime now + 5) // some grace secs
No personal comment on the diff, but a nitpick:
No C++ style comments please.
/* */ style only (see style(9) for more details).
for (i = 11; i 16; ++i)
(void)putchar(longstring[i]);
else {
888888 (cut)
--
internetlabbet.se / work: +46 8 551 124 80 / Words must
Benny Lofgren/ mobile: +46 70 718 11 90 / be weighed,
/ fax:+46 8 551 124 89/not counted.
/email: benny -at- internetlabbet.se
Cheers,
-0-
--
Man 1: Ask me the what the most important thing about telling a good
joke is.
Man 2: OK, what is the most impo --
Man 1: __TIMING!
Re: ls(1) displays future timestamps improperly
On Mon, Mar 21, 2011 at 7:04 AM, Benny Lofgren bl-li...@lofgren.biz wrote: Realized I was sloppy with KNF. This diff is hopefully neater looking. I like this, but 5 seconds is not enough. I would have chosen at least an hour, for poorly synced NFS systems, if not a whole day. Also // comments aren't really in vogue. Just leave the comment out.
qemu-old .. relevent or not?
I've gotten one request to decommission qemu-old. It surprised me, as I thought there were still issues with qemu/ even with the semi recent thread fix as well as performance differences. Does anybody have objection to retiring qemu-old to the attic or ? I'd rather not do this prematurely but if the time has come, this is the right time of release cycle to do it. Thanks, -- Todd Fries .. t...@fries.net _ | \ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC \ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX) | 2525 NW Expy #525, Oklahoma City, OK 73112 \ sip:freedae...@ekiga.net | ..in support of free software solutions. \ sip:4052279...@ekiga.net \\ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt
Re: qemu-old .. relevent or not?
I've gotten one request to decommission qemu-old. It surprised me, as I thought there were still issues with qemu/ even with the semi recent thread fix as well as performance differences. Does anybody have objection to retiring qemu-old to the attic or ? I'd rather not do this prematurely but if the time has come, this is the right time of release cycle to do it. I'm probably less educated about the functionality of newer qemu than I should be, but I still use the old version from ports (along with kqemu) to host Plan 9 on various systems. My understanding is that moving to the newer version(s) of qemu would introduce a performance hit, since kqemu is deprecated and whatever newer, fancier kernel integration has been introduced is not yet supported on OpenBSD. Is this wildly off-base? -sl
Re: qemu-old .. relevent or not?
* Todd T. Fries t...@fries.net [2011-03-21 22:01]: Does anybody have objection to retiring qemu-old to the attic or ? yes, I object for the time being. the laptops where i use(d) qemu most are stuck in tokyo, hadn't had a chance to try the recently updated 0.14 yet and due to this situation it'll be a bit, but the previous 0.13.something was oh so much worse than 0.9.x. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: qemu-old .. relevent or not?
I withdraw any thoughts of removing qemu-old anytime soon based on feedback. Henning confirms performance gains for keeping it. And we have a reminder that while kqemu is not recommended, it is only usable on qemu-old. Penned by Todd T. Fries on 20110321 15:58.35, we have: | I've gotten one request to decommission qemu-old. It surprised me, | as I thought there were still issues with qemu/ even with the semi recent | thread fix as well as performance differences. | | Does anybody have objection to retiring qemu-old to the attic or ? | | I'd rather not do this prematurely but if the time has come, this is the | right time of release cycle to do it. | | Thanks, | -- | Todd Fries .. t...@fries.net | | _ | | \ 1.636.410.0632 (voice) | | Free Daemon Consulting, LLC \ 1.405.227.9094 (voice) | | http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX) | | 2525 NW Expy #525, Oklahoma City, OK 73112 \ sip:freedae...@ekiga.net | | ..in support of free software solutions. \ sip:4052279...@ekiga.net | \\ | | 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A | http://todd.fries.net/pgp.txt -- Todd Fries .. t...@fries.net _ | \ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC \ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX) | 2525 NW Expy #525, Oklahoma City, OK 73112 \ sip:freedae...@ekiga.net | ..in support of free software solutions. \ sip:4052279...@ekiga.net \\ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt
Re: qemu-old .. relevent or not?
On 21/03/11 5:59 PM, Henning Brauer wrote: * Todd T. Friest...@fries.net [2011-03-21 22:01]: Does anybody have objection to retiring qemu-old to the attic or ? yes, I object for the time being. the laptops where i use(d) qemu most are stuck in tokyo, hadn't had a chance to try the recently updated 0.14 yet and due to this situation it'll be a bit, but the previous 0.13.something was oh so much worse than 0.9.x. Ok, well when you get your laptops back provide real bug report(s). For all I know oh so much worse was due to the libpthread bug which was causing the crashing of QEMU and/or hosted OS's within QEMU. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: qemu-old .. relevent or not?
On 21/03/11 7:08 PM, Stanley Lieber wrote: On Mon, Mar 21, 2011 at 5:53 PM, Bradb...@comstyle.com wrote: On 22/03/11 4:54 PM, Stanley Lieber wrote: I've gotten one request to decommission qemu-old. It surprised me, as I thought there were still issues with qemu/ even with the semi recent thread fix as well as performance differences. Does anybody have objection to retiring qemu-old to the attic or ? I'd rather not do this prematurely but if the time has come, this is the right time of release cycle to do it. I'm probably less educated about the functionality of newer qemu than I should be, but I still use the old version from ports (along with kqemu) to host Plan 9 on various systems. My understanding is that moving to the newer version(s) of qemu would introduce a performance hit, since kqemu is deprecated and whatever newer, fancier kernel integration has been introduced is not yet supported on OpenBSD. Is this wildly off-base? KQEMU is an unsupported piece of code that no one has ever maintained, doesn't work on MP kernels and has issues even on SP kernels. It's not deprecated. It is plain dead, period. No one cared to actually fix it when the QEMU developers asked on their list for the OS's that actually used it (*BSD, Solaris) and later some of its design limitations prevented further progress so support was removed all together. Taking that out of the picture and doing an apples to apples comparison can you find any real issues between the versions of QEMU that have a real effect on your Plan 9 images? No experimental evidence, yet, but I'm willing to give it a shot. Subjectively, the old qemu feels quite a bit slower without kqemu. Of course. That's an apples to oranges comparison. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [PATCH] Fix for kernel crash with udav(4) device
On Sun, Mar 20, 2011 at 04:07:33PM -0400, Loganaden Velvindron wrote:
With input from mk, we improved the diff.
Testing is very much appreciated.
[...]
I can't comment on the code (it isn't my area, but, worse, i'm still
too short of time), but at least a make build over nfs now finished
without any problems.
Ciao,
Kili
Index: src/sys/dev/usb/if_udav.c
===
RCS file: /cvs/src/sys/dev/usb/if_udav.c,v
retrieving revision 1.54
diff -u -p -r1.54 if_udav.c
--- src/sys/dev/usb/if_udav.c 20 Mar 2011 17:58:26 - 1.54
+++ src/sys/dev/usb/if_udav.c 20 Mar 2011 19:58:51 -
@@ -1128,18 +1128,25 @@ udav_rxeof(usbd_xfer_handle xfer, usbd_p
usbd_get_xfer_status(xfer, NULL, NULL, total_len, NULL);
+ if (total_len UDAV_RX_HDRLEN) {
+ ifp-if_ierrors++;
+ goto done;
+ }
+
h = (struct udav_rx_hdr *)c-udav_buf;
total_len = UGETW(h-length) - ETHER_CRC_LEN;
- DPRINTF((%s: RX Status: 0x%02x\n, h-pktstat));
+ DPRINTF((%s: RX Status: 0x%02x\n, sc-sc_dev.dv_xname, h-pktstat));
if (h-pktstat UDAV_RSR_LCS) {
ifp-if_collisions++;
goto done;
}
+ /* RX status may still be correct but total_len is bogus */
if (total_len sizeof(struct ether_header) ||
- h-pktstat UDAV_RSR_ERR) {
+ h-pktstat UDAV_RSR_ERR ||
+ total_len UDAV_BUFSZ ) {
ifp-if_ierrors++;
goto done;
}
Index: src/sys/dev/usb/if_udavreg.h
===
RCS file: /cvs/src/sys/dev/usb/if_udavreg.h,v
retrieving revision 1.11
diff -u -p -r1.11 if_udavreg.h
--- src/sys/dev/usb/if_udavreg.h 6 Dec 2010 04:41:39 - 1.11
+++ src/sys/dev/usb/if_udavreg.h 20 Mar 2011 19:58:51 -
@@ -200,6 +200,6 @@ struct udav_rx_hdr {
#define UDAV_RX_HDRLEN sizeof(struct udav_rx_hdr)
/* Packet length */
-#define UDAV_MAX_MTU1536 /* XXX: max frame size is unknown
*/
+#define UDAV_MAX_MTU1522 /* According to datasheet */
#define UDAV_MIN_FRAME_LEN 60
#define UDAV_BUFSZ UDAV_MAX_MTU + UDAV_RX_HDRLEN
--
Password:
You speak an infinite deal of nothing
-- sudo(8), OpenBSD
Re: qemu-old .. relevent or not?
On Mon, Mar 21, 2011 at 5:53 PM, Brad b...@comstyle.com wrote: On 22/03/11 4:54 PM, Stanley Lieber wrote: I've gotten one request to decommission qemu-old. B It surprised me, as I thought there were still issues with qemu/ even with the semi recent thread fix as well as performance differences. Does anybody have objection to retiring qemu-old to the attic or ? I'd rather not do this prematurely but if the time has come, this is the right time of release cycle to do it. I'm probably less educated about the functionality of newer qemu than I should be, but I still use the old version from ports (along with kqemu) to host Plan 9 on various systems. My understanding is that moving to the newer version(s) of qemu would introduce a performance hit, since kqemu is deprecated and whatever newer, fancier kernel integration has been introduced is not yet supported on OpenBSD. Is this wildly off-base? KQEMU is an unsupported piece of code that no one has ever maintained, doesn't work on MP kernels and has issues even on SP kernels. It's not deprecated. It is plain dead, period. No one cared to actually fix it when the QEMU developers asked on their list for the OS's that actually used it (*BSD, Solaris) and later some of its design limitations prevented further progress so support was removed all together. Taking that out of the picture and doing an apples to apples comparison can you find any real issues between the versions of QEMU that have a real effect on your Plan 9 images? No experimental evidence, yet, but I'm willing to give it a shot. Subjectively, the old qemu feels quite a bit slower without kqemu. I'll do some testing. -sl
