syslogd logfile per remote host
Hi,
I want to store all syslog messages received from a specific host
into a single log file. For programs this is already implemented
for !prog blocks. So do the same with +host for hostnames.
This implementation is based on a diff that Gregory Edigarov sent
to me. So there is at least one other user who needs this.
I have an alternative diff, that changes the facility in the sending
syslogd. When you specify @remotehost:514/local7 in the sending
syslog.conf, then you can use the facilty on the receiving side to
split the messages.
What is the best solution?
- Match on the hostname at the receiving side.
- Change the facility at the sending side.
- Commit both and let the user configure what fits in his environmet.
bluhm
Index: usr.sbin/syslogd/syslog.conf.5
===
RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/syslog.conf.5,v
retrieving revision 1.31
diff -u -p -r1.31 syslog.conf.5
--- usr.sbin/syslogd/syslog.conf.5 10 Feb 2015 18:42:08 - 1.31
+++ usr.sbin/syslogd/syslog.conf.5 27 Jun 2015 21:09:02 -
@@ -121,6 +121,17 @@ can be used to ensure that any ensuing b
or
.Em !!prog ) .
.Pp
+Blocks starting with
+.Em +host
+or
+.Em ++host
+or
+.Em +*
+work the same way as their
+.Em prog
+counterparts, but they match on the hostname instead of the program
+name.
+.Pp
See
.Xr syslog 3
for further descriptions of both the
Index: usr.sbin/syslogd/syslogd.c
===
RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/syslogd.c,v
retrieving revision 1.164
diff -u -p -r1.164 syslogd.c
--- usr.sbin/syslogd/syslogd.c 15 Jun 2015 21:42:15 - 1.164
+++ usr.sbin/syslogd/syslogd.c 28 Jun 2015 10:17:12 -
@@ -135,6 +135,7 @@ struct filed {
time_t f_time; /* time this was last written */
u_char f_pmask[LOG_NFACILITIES+1]; /* priority mask */
char*f_program; /* program this applies to */
+ char*f_hostname;/* host this applies to */
union {
charf_uname[MAXUNAMES][UT_NAMESIZE+1];
struct {
@@ -298,7 +299,7 @@ void ctlconn_writecb(int, short, void *
voidctlconn_logto(char *);
voidctlconn_cleanup(void);
-struct filed *cfline(char *, char *);
+struct filed *cfline(char *, char *, char *);
void cvthname(struct sockaddr *, char *, size_t);
intdecode(const char *, const CODE *);
void die(int);
@@ -1131,6 +1132,9 @@ logmsg(int pri, char *msg, char *from, i
if (f-f_program)
if (strcmp(prog, f-f_program) != 0)
continue;
+ if (f-f_hostname)
+ if (strcmp(from, f-f_hostname) != 0)
+ continue;
if (f-f_type == F_CONSOLE (flags IGN_CONS))
continue;
@@ -1595,7 +1599,7 @@ die(int signo)
void
init(void)
{
- char prog[NAME_MAX+1], *cline, *p;
+ char progblock[NAME_MAX+1], hostblock[NAME_MAX+1], *cline, *p;
struct filed_list mb;
struct filed *f, *m;
FILE *cf;
@@ -1642,8 +1646,8 @@ init(void)
(void)close(f-f_file);
break;
}
- if (f-f_program)
- free(f-f_program);
+ free(f-f_program);
+ free(f-f_hostname);
if (f-f_type == F_MEMBUF) {
f-f_program = NULL;
dprintf(add %p to mb\n, f);
@@ -1656,9 +1660,10 @@ init(void)
/* open the configuration file */
if ((cf = priv_open_config()) == NULL) {
dprintf(cannot open %s\n, ConfFile);
- SIMPLEQ_INSERT_TAIL(Files, cfline(*.ERR\t/dev/console, *),
- f_next);
- SIMPLEQ_INSERT_TAIL(Files, cfline(*.PANIC\t*, *), f_next);
+ SIMPLEQ_INSERT_TAIL(Files,
+ cfline(*.ERR\t/dev/console, *, *), f_next);
+ SIMPLEQ_INSERT_TAIL(Files,
+ cfline(*.PANIC\t*, *, *), f_next);
Initialized = 1;
return;
}
@@ -1668,12 +1673,14 @@ init(void)
*/
cline = NULL;
s = 0;
- strlcpy(prog, *, sizeof(prog));
+ strlcpy(progblock, *, sizeof(progblock));
+ strlcpy(hostblock, *, sizeof(hostblock));
while (getline(cline, s, cf) != -1) {
/*
* check for end-of-section, comments, strip off trailing
-* spaces and newline character. !prog is treated
-* specially: the following lines apply only to that program.
+* spaces and newline character. !progblock and +hostblock
+* are treated specially: the following lines apply only to
+* that program.
*/
Re: ps %cpu is 0
On Sun, 28 Jun 2015 12:43:40 +0200, Alexander Bluhm wrote: After removing the p_swtime from the kernel, ps always prints 0.0 as %cpu time. The simple fix is to remove the calculation in ps that includes the process lifetime. Just print the p_pctcpu. I think you want to keep the case 'C': but just make it a no-op. - todd
C-state FFH on x41
I have an x41 that prints the following in dmesg:
acpicpu0 at acpi0
C1: unknown FFH vendor 8: !C3(250@85 io@0x1015), C2(500@1 io@0x1014), PSS
The relevant AML indead has that strange value in the Bit Width field:
Name (CST1, Package (0x02)
{
0x01,
Package (0x04)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x08, // Bit Width
0x00, // Bit Offset
0x, // Address
,)
},
0x01,
0x01,
0x03E8
}
})
Obviously this ACPI BIOS is buggy and perhaps we should indeed
complain. But we also should include a C1 HALT state in the list
regardless, and I don't think we currently do that.
ps %cpu is 0
Hi,
After removing the p_swtime from the kernel, ps always prints 0.0
as %cpu time. The simple fix is to remove the calculation in ps
that includes the process lifetime. Just print the p_pctcpu.
This was already done when ps -C was used, now ps always behaves
this way.
ok?
bluhm
Index: bin/ps/extern.h
===
RCS file: /data/mirror/openbsd/cvs/src/bin/ps/extern.h,v
retrieving revision 1.16
diff -u -p -r1.16 extern.h
--- bin/ps/extern.h 29 Dec 2011 17:13:55 - 1.16
+++ bin/ps/extern.h 11 Jun 2015 16:38:48 -
@@ -37,7 +37,7 @@ struct var;
struct varent;
extern fixpt_t ccpu;
-extern int eval, fscale, nlistread, rawcpu, maxslp;
+extern int eval, fscale, nlistread, maxslp;
extern u_int mempages;
extern int sumrusage, termwidth, totwidth, kvm_sysctl_only, needheader;
extern VAR var[];
Index: bin/ps/print.c
===
RCS file: /data/mirror/openbsd/cvs/src/bin/ps/print.c,v
retrieving revision 1.60
diff -u -p -r1.60 print.c
--- bin/ps/print.c 15 Mar 2015 00:41:27 - 1.60
+++ bin/ps/print.c 11 Jun 2015 16:53:54 -
@@ -523,28 +523,12 @@ cputime(const struct kinfo_proc *kp, VAR
double
getpcpu(const struct kinfo_proc *kp)
{
- double d;
-
if (fscale == 0)
return (0.0);
#definefxtofl(fixpt) ((double)(fixpt) / fscale)
- /* XXX - I don't like this */
- if (kp-p_swtime == 0)
- return (0.0);
- if (rawcpu)
- return (100.0 * fxtofl(kp-p_pctcpu));
-
- d = kp-p_swtime * log(fxtofl(ccpu));
- if (d -700.0)
- d = 0.0;/* avoid IEEE underflow */
- else
- d = exp(d);
- if (d == 1.0)
- return (0.0);
- return (100.0 * fxtofl(kp-p_pctcpu) /
- (1.0 - d));
+ return (100.0 * fxtofl(kp-p_pctcpu));
}
void
Index: bin/ps/ps.1
===
RCS file: /data/mirror/openbsd/cvs/src/bin/ps/ps.1,v
retrieving revision 1.98
diff -u -p -r1.98 ps.1
--- bin/ps/ps.1 11 Feb 2015 00:43:33 - 1.98
+++ bin/ps/ps.1 28 Jun 2015 10:41:42 -
@@ -39,7 +39,7 @@
.Sh SYNOPSIS
.Nm ps
.Sm off
-.Op Fl AaCceHhjkLlmrSTuvwx
+.Op Fl AaceHhjkLlmrSTuvwx
.Sm on
.Op Fl M Ar core
.Op Fl N Ar system
@@ -76,13 +76,6 @@ Display information about processes for
terminals.
.It Fl a
Display information about processes for all users with controlling terminals.
-.It Fl C
-Change the way the CPU percentage is calculated by using a
-.Dq raw
-CPU calculation that ignores
-.Dq resident
-time (this normally has
-no effect).
.It Fl c
Do not display full command with arguments, but only the
executable name.
@@ -613,7 +606,7 @@ X/Open System Interfaces option of
.St -p1003.1-2008 .
.Pp
The flags
-.Op Fl CcHhjkLMmNOrSTvWwx
+.Op Fl cHhjkLMmNOrSTvWwx
are extensions to
.St -p1003.1-2008 .
.Pp
Index: bin/ps/ps.c
===
RCS file: /data/mirror/openbsd/cvs/src/bin/ps/ps.c,v
retrieving revision 1.64
diff -u -p -r1.64 ps.c
--- bin/ps/ps.c 9 Apr 2015 19:48:25 - 1.64
+++ bin/ps/ps.c 11 Jun 2015 16:39:59 -
@@ -60,7 +60,6 @@ extern char *__progname;
struct varent *vhead;
inteval; /* exit value */
-intrawcpu; /* -C */
intsumrusage; /* -S */
inttermwidth; /* width of screen (0 == infinity) */
inttotwidth; /* calculated width of requested variables */
@@ -135,9 +134,6 @@ main(int argc, char *argv[])
case 'a':
all = 1;
break;
- case 'C':
- rawcpu = 1;
- break;
case 'c':
commandonly = 1;
break;
@@ -477,7 +473,7 @@ static void
usage(void)
{
(void)fprintf(stderr,
- usage: %s [-AaCceHhjkLlmrSTuvwx] [-M core] [-N system] [-O fmt]
[-o fmt] [-p pid]\n,
+ usage: %s [-AaceHhjkLlmrSTuvwx] [-M core] [-N system] [-O fmt] [-o
fmt] [-p pid]\n,
__progname);
(void)fprintf(stderr,
%-*s[-t tty] [-U username] [-W swap]\n, (int)strlen(__progname) +
8, );
Re: [Patch] New item to the Migrating to OpenBSD guide
Hi, I’m sorry that it came off that way. Did you read the whole article? No that you should have, but it addresses most of the points that you mention I understand that OpenBSD owes me nothing (and vice versa) and I was just trying to help. The decision to merge that information is not mine to do, however, I honestly thought it could help people looking for a more thorough comparison between Linux and the BSDs. I’ve been using free software and contributing to it for a long time, in different projects, you can google it. I have no link to any institution or software/political group. You seem to be about certain that I have some sort of agenda, why? I’m curious. Anyway, I honestly was just trying to help. Writing the patch took me 5 minutes so just forget about it. I don’t want to create a bad mood on a place I just arrived at. Carlos On 28 Jun 2015, at 23:03, li...@wrant.com wrote: I’ve recently discovered OpenBSD after using Linux for more than 15 years. Long time, no see? And you blogged and achieved your goal of... making yourself expressed, critically on your own controlled web space. I wrote a blog article with my impressions and some other users suggested me to patch faq9.html to help other users migrating. Without reading much of the documentation to gain reasonable production usage, you're trying to mend the OpenBSD site to say it is lacking something that you thought worth having according to your current limited to Linux experience. Never occurred to you it may be intentional? This patch is regarding the fact that there are no binary updates, which is a given thing in most Linux distributions, and some tips on how to keep the system updated. And you consider this a service to other Linux long time users? Or a way to try push some notion of yours - criticise and try to lobby for some other entity's interests. Since English is not my first language, before merging the patch, please make sure the wording is proper. The pushing of binary patches notion is not appropriate. For a project that provides binary base OS and binary packages for ports on multiple architectures, and signed distribution of base and packages, before anyone else adopted these impressive achievements, you think in your own universe (and your advisor's) this group is resource constrained and incapable of providing binary patches to current and stable? Read the docs, don't be lazy and overly assuming. You're polluting the Internet with incorrect information which is a disservice to both newcomers from Linux and to the OpenBSD community. If you think the issue may be interesting to elaborate on, I could write a guide of improve on stable.html to help newcomers adapt to this method of keeping up to date. You're actually trying to scare people off, because you can't handle the lean and effective process of managing OpenBSD, justifying this with the unconfirmed fact you were advised by somebody. Realistically, you could have consulted off list before trying this stunt.
Re: [Patch] New item to the Migrating to OpenBSD guide
On Sun, Jun 28, 2015 at 07:20:51PM +0200, Carlos Fenollosa wrote: This patch is regarding the fact that there are no binary updates, which is a given thing in most Linux distributions, and some tips on how to keep the system updated. It may be worthwhile to mention that updates are comparatively very rare. I'd estimate that Ubuntu's stable distribution has been pushing a new kernel or two kernel a week lately along with countless other updates. A Debian/Ubuntu user reading that might imagine themselves manually patching and building constantly.
Re: [Patch] New item to the Migrating to OpenBSD guide
I’ve recently discovered OpenBSD after using Linux for more than 15 years. Long time, no see? And you blogged and achieved your goal of... making yourself expressed, critically on your own controlled web space. I wrote a blog article with my impressions and some other users suggested me to patch faq9.html to help other users migrating. Without reading much of the documentation to gain reasonable production usage, you're trying to mend the OpenBSD site to say it is lacking something that you thought worth having according to your current limited to Linux experience. Never occurred to you it may be intentional? This patch is regarding the fact that there are no binary updates, which is a given thing in most Linux distributions, and some tips on how to keep the system updated. And you consider this a service to other Linux long time users? Or a way to try push some notion of yours - criticise and try to lobby for some other entity's interests. Since English is not my first language, before merging the patch, please make sure the wording is proper. The pushing of binary patches notion is not appropriate. For a project that provides binary base OS and binary packages for ports on multiple architectures, and signed distribution of base and packages, before anyone else adopted these impressive achievements, you think in your own universe (and your advisor's) this group is resource constrained and incapable of providing binary patches to current and stable? Read the docs, don't be lazy and overly assuming. You're polluting the Internet with incorrect information which is a disservice to both newcomers from Linux and to the OpenBSD community. If you think the issue may be interesting to elaborate on, I could write a guide of improve on stable.html to help newcomers adapt to this method of keeping up to date. You're actually trying to scare people off, because you can't handle the lean and effective process of managing OpenBSD, justifying this with the unconfirmed fact you were advised by somebody. Realistically, you could have consulted off list before trying this stunt.
Re: [Patch] New item to the Migrating to OpenBSD guide
On 2015-06-29 00.03.09 +0300, li...@wrant.com wrote: And you consider this a service to other Linux long time users? Or a way to try push some notion of yours - criticise and try to lobby for some other entity's interests. Do you have a patch that achieves the same goal (that is, the goal he stated, not the one you're reading into) that is up to your standards?
Re: [Patch] New item to the Migrating to OpenBSD guide
I understand that OpenBSD owes me nothing (and vice versa) and I was just trying to help. The decision to merge that information is not mine to do, however, I honestly thought it could help people looking for a more thorough comparison between Linux and the BSDs. Are you by chance being mislead to post this to tech@ instead of updating your own web site? Anyway, I honestly was just trying to help. Writing the patch took me 5 minutes so just forget about it. I don’t want to create a bad mood on a place I just arrived at. Please post to misc@ these discussions.
[Patch] New item to the Migrating to OpenBSD guide
Hi, I’ve recently discovered OpenBSD after using Linux for more than 15 years. I wrote a blog article with my impressions and some other users suggested me to patch faq9.html to help other users migrating. This patch is regarding the fact that there are no binary updates, which is a given thing in most Linux distributions, and some tips on how to keep the system updated. Since English is not my first language, before merging the patch, please make sure the wording is proper. If you think the issue may be interesting to elaborate on, I could write a guide of improve on stable.html to help newcomers adapt to this method of keeping up to date. Here’s the whole article if anybody’s interested: http://cfenollosa.com/blog/openbsd-from-a-veteran-linux-user-perspective.html Thanks! Carlos PS: This is my first patch, I’m sending it inline as suggested by http://www.bsdnow.tv/tutorials/patching-obsd. Apologies if this is not the right way. ? patch-faq9.diff Index: faq9.html === RCS file: /cvs/www/faq/faq9.html,v retrieving revision 1.113 diff -u -p -r1.113 faq9.html --- faq9.html 11 May 2015 11:18:30 - 1.113 +++ faq9.html 28 Jun 2015 17:19:45 - @@ -133,6 +133,18 @@ The tree is occasionally broken, but thi will be corrected rapidly, not something that will be permitted to continue. +liThere are no binary security updates. The team has no resources +to constantly compile binaries for all architectures, they do it only +every -release. Thus, unlike Linux distributions, which come with a +package manager which takes care of updates (ttyum/tt, +ttapt-get/tt, etc), there is no single command to update the system +to the latest binary status. Keeping up-to-date (including security errata) +is a bit different. You can either (1) upgrade every -release, +(2) apply patches froma href=../errataerrata/a or (3) follow +a href=../stable-stable/a. Binary updates may be obtained +from a href=https://stable.mtier.org;a third party/a for the i386 +and amd64 architectures./li + liOpenBSD has gone through heavy and continual security auditing to ensure the quality (and thus, security) of the code.
Re: ps %cpu is 0
On Sun, Jun 28, 2015 at 08:42:21AM -0600, Todd C. Miller wrote: On Sun, 28 Jun 2015 12:43:40 +0200, Alexander Bluhm wrote: After removing the p_swtime from the kernel, ps always prints 0.0 as %cpu time. The simple fix is to remove the calculation in ps that includes the process lifetime. Just print the p_pctcpu. I think you want to keep the case 'C': but just make it a no-op. Why? And what should I document in the manpage then?
Re: [Patch] New item to the Migrating to OpenBSD guide
This patch is regarding the fact that there are no binary updates, which is a given thing What you missed : https://stable.mtier.org/
Re: [Patch] New item to the Migrating to OpenBSD guide
On Sun, 28 Jun 2015 19:55:58 +0200 Denis Fondras open...@ledeuns.net wrote: This patch is regarding the fact that there are no binary updates, which is a given thing What you missed : https://stable.mtier.org/ What do you mean? The author mentioned mtier.org both in his original blog post and the patch sent to this mailing list. Regarding the patch itself: +a href=../stable-stable/a. Binary updates may be obtained +from a href=https://stable.mtier.org;a third party/a for the i386 +and amd64 architectures./li If it's going to be merged then it's probably worth to mention that some OpenBSD developers work for mtier directly. Each time mtier is mentioned someone is deemed to chime in with but I don't trust them even though the same people commit code to the base OS... Regards, Adam
Re: [Patch] New item to the Migrating to OpenBSD guide
What do you mean? The author mentioned mtier.org both in his original blog post and the patch sent to this mailing list. Author? Exactly whose ground are you defending here, Adam? If it's going to be merged then it's probably worth to mention that if... and you're on top of each other arguing already Just reread the text and consider if there is actually some hidden context or offensive agenda somebody is pushing around, just to make a remote point elsewhere. mentioned someone is deemed to chime in with but I don't trust them quit that garbage
Re: [Patch] New item to the Migrating to OpenBSD guide
On Mon, Jun 29, 2015 at 01:02:44AM +0300, li...@wrant.com wrote: Do you have a patch that achieves the same goal (that is, the goal he stated, not the one you're reading into) that is up to your standards? One that reversed the submission of the proposed patch, correcting it and this thread to an empty string. Carlos' patch may not be appropriate, but you're kind of a condecending jerk, especially for someone who's apparently never sent mail to the OpenBSD lists before. Who are you?
Re: [Patch] New item to the Migrating to OpenBSD guide
Without reading much of the documentation to gain reasonable production usage, you're trying to mend the OpenBSD site to say it is lacking something that you thought worth having according to your current limited to Linux experience. Never occurred to you it may be intentional? The pushing of binary patches notion is not appropriate. For a project that provides binary base OS and binary packages for ports on multiple architectures, and signed distribution of base and packages, before anyone else adopted these impressive achievements, you think in your own universe (and your advisor's) this group is resource constrained and incapable of providing binary patches to current and stable? Is this a joke, perhaps a terribly unclever attempt at trolling? Lack of resources is about the only good reason there is for not providing binary updates. The wonderful signed binary package infrastructure is not terribly useful if by the time it is released, you have to build ports from CVS to not have security vulnerabilities anyway! Clearly I am not the only one who thinks this is not intentional, given the existance of m:tier, which as discussed is even run by OpenBSD maintainers. Read the docs, don't be lazy and overly assuming. You're polluting the Internet with incorrect information which is a disservice to both newcomers from Linux and to the OpenBSD community. Given that the topic is about people moving from Linux to OpenBSD, and how it is normal in the Linux world to have binary updates... what here is incorrect, or a disservice? I've been using OpenBSD for most of a decade and I think this is a fine addition given the context of what someone from the Linux world expects. You're actually trying to scare people off, because you can't handle the lean and effective process of managing OpenBSD, justifying this with the unconfirmed fact you were advised by somebody. ... pgptrMillxnPy.pgp Description: PGP signature
Re: [Patch] New item to the Migrating to OpenBSD guide
Lack of resources is about the only good reason there is for not providing binary updates. That's not true. Further, base + packages are updated frequently in snapshots, which is exactly a binary upgrade path for users without worry. This works exceedingly well and is well stated in the following current and stable pages.
Re: [Patch] New item to the Migrating to OpenBSD guide
Lack of resources is about the only good reason there is for not providing binary updates. That's not true. It must feel absolutely glorious to bask in your anonymity and make such a strong claim. I personally am not going to spend a second working on binary updates until I know there are 20+ other developers also dedicated to making it happen, and once it starts happening -- keeps happening forever. That's the lack of resources I am talking about. I have no idea what you are talking about. Nor who you are. Since I don't know who you are, it is probably best to assume you are not the right person to believe regardin reasons for our lack of attention towards binary updates.
Re: [Patch] New item to the Migrating to OpenBSD guide
Lack of resources is about the only good reason there is for not providing binary updates. That's not true. It must feel absolutely glorious to bask in your anonymity and make such a strong claim. There are no strong claims. The other good reasons are to manage the updates manually as has been so far via instructions in the errata pages, saving some effort and empty discussions. That might also help learn in the process, beneficial to the users following stable on more than one system. I personally am not going to spend a second working on binary updates until I know there are 20+ other developers also dedicated to making it happen, and once it starts happening -- keeps happening forever. That's exactly the idea, not do it or do it right and keep doing the task. So the discussion is to probably best put these upgrade details in the upgrade guide, not in the migration guide in the meantime. Without delegating resources until deemed necessary and no need to state explicitly they have no binary upgrades on the migration guide.
Re: [Patch] New item to the Migrating to OpenBSD guide
Well, not near one, but I volunteer for binary errata patch on current for i386 and amd64 (the only archs I own for now). People are going to use binary patches from you? Who are you? What is your name? That's the first step to establish trust. Boy, that's a pretty clever joke!
Re: Pure L2TP client upload performance
2015-06-26 9:20 GMT+03:00 Claudio Jeker cje...@diehard.n-r-g.com:
On Fri, Jun 26, 2015 at 04:59:32AM +0300, Sergey Ryazanov wrote:
Hello,
during building l2tp tunnel with xl2tpd-1.3.1 I was faced with its too
low upload performance. When download, the speed is 20 mbit/s at
nearly 100% CPU utilization. CPU is Pentium D 930 3 GHz. When upload,
the speed is below 2 mbit/s at nearly zero CPU utilization.
First, I examined xl2tpd code and did not find any potential issues.
Then I compiled it with -pg option and do a quick test with help of
iperf(1): 4 TCP flows, direction is toward the L2TP server, 2 min
test. Then I run gprof and got pretty strange output:
[skip]
During upload tests, everything looks like if xl2tpd doesn't perform
any work and stucks somewhere in I/O operation.
May be there are some options, what could be tuned to speedup ppp(4)
I/O performance or did I missed something during my tests? I am in
doubts. Any clues?
Can you get a ktrace output to figure out what write is doing?
Could it be that it busy loops with EINTR or EAGAIN?
It sure smells like something is going on there.
I did make the trace, which shows that write(2) works good, there are no
errors:
# kdump -f ktrace.out-0-tx | grep 'RET write' | wc -l
23999
# kdump -f ktrace.out-0-tx | grep 'RET write.*errno' | wc -l
0
That was bad news. Let's talk about something good. I finally found a way
to speed up the upload. I got 91 mbit/s, as reported by speedtest.net,
over 100 mbit Ethernet link (at 100% CPU utilization, with the patched
non-SMP kernel).
Looks like the issue is caused by too small size of pty output buffer, and
too small watermarks, which control the pty buffer filling. When pty driver
requests the tty allocation, it passes 0 as baud rate. For any rates, which
is less or equal to 115200, tty driver allocates an output buffer of size
of 1024 byte. And most likely, hardcoded watermarks in the ppp discipline
code are selected according to this buffer size. May be these values were
reasonable for 56k modems, but not for 100 mbit uplink.
Patch for tests is inlined below. All numbers are arbitrary selected values.
I just took first reasonable values and got a positive result, without any
further experiments.
This patch is not suitable for merging, since it just quick and dirty fix.
To solve the issue in more generic way I see several approaches, each of
which has pros and cons:
(a) increase default value (as in this patch);
(b) provide some API (IOCTL) to control buffer size from pppd(8);
(c) make some hack that would reveal pty for high-speed links and increase
their buffer.
Any thoughts?
P.S. If I can get 91 mbit/s of upload rate, then why I get only 20 mbit/s
of download rate on the same machine?
Index: kern/tty_pty.c
===
RCS file: /cvs/src/sys/kern/tty_pty.c,v
retrieving revision 1.70
diff -u -p -r1.70 tty_pty.c
--- kern/tty_pty.c 10 Feb 2015 21:56:10 - 1.70
+++ kern/tty_pty.c 28 Jun 2015 14:18:16 -
@@ -58,6 +58,7 @@
#include sys/rwlock.h
#define BUFSIZ 100 /* Chunk size iomoved to/from user */
+#define PTY_DEF_BAUD 100
/*
* pts == /dev/tty[p-zP-T][0-9a-zA-Z]
@@ -192,7 +193,7 @@ check_pty(int minor)
if (!pt_softc[minor]) {
pti = malloc(sizeof(struct pt_softc), M_DEVBUF,
M_WAITOK|M_ZERO);
- pti-pt_tty = ttymalloc(0);
+ pti-pt_tty = ttymalloc(PTY_DEF_BAUD);
ptydevname(minor, pti);
pt_softc[minor] = pti;
}
@@ -235,7 +236,7 @@ ptsopen(dev_t dev, int flag, int devtype
pti = pt_softc[minor(dev)];
if (!pti-pt_tty) {
- tp = pti-pt_tty = ttymalloc(0);
+ tp = pti-pt_tty = ttymalloc(PTY_DEF_BAUD);
} else
tp = pti-pt_tty;
if ((tp-t_state TS_ISOPEN) == 0) {
@@ -413,7 +414,7 @@ ptcopen(dev_t dev, int flag, int devtype
pti = pt_softc[minor(dev)];
if (!pti-pt_tty) {
- tp = pti-pt_tty = ttymalloc(0);
+ tp = pti-pt_tty = ttymalloc(PTY_DEF_BAUD);
} else
tp = pti-pt_tty;
if (tp-t_oproc)
Index: net/ppp_tty.c
===
RCS file: /cvs/src/sys/net/ppp_tty.c,v
retrieving revision 1.33
diff -u -p -r1.33 ppp_tty.c
--- net/ppp_tty.c 3 Jun 2015 00:50:09 - 1.33
+++ net/ppp_tty.c 28 Jun 2015 14:18:16 -
@@ -163,8 +163,8 @@ struct pool ppp_pkts;
/* This is a NetBSD-1.0 or later kernel. */
#define CCOUNT(q) ((q)-c_cc)
-#define PPP_LOWAT 100 /* Process more output when LOWAT on queue */
-#definePPP_HIWAT 400 /* Don't start a new packet if HIWAT on
queue */
+#define PPP_LOWAT 1024/* Process more output when LOWAT on queue */
+#define PPP_HIWAT 4096/* Don't start a new
Re: [Patch] New item to the Migrating to OpenBSD guide
Well, not near one, but I volunteer for binary errata patch on current for i386 and amd64 (the only archs I own for now). People are going to use binary patches from you? I was hoping to try help with testing at least. Who are you? What is your name? That's the first step to establish trust. An OpenBSD user for a decade, this does not change the trust state. My name is Anton Lazarov from Bulgaria. If this is some hot topic that I stepped on, how do you propose one gets into good terms with these before acting on potentially controversial posts?
Re: ps %cpu is 0
On Sun, 28 Jun 2015 20:26:31 +0200, Alexander Bluhm wrote: Why? And what should I document in the manpage then? So you don't break existing scripts that might use it. You don't need to document it. - todd
Re: C-state FFH on x41
On Sun, 28 Jun 2015, Mark Kettenis wrote:
I have an x41 that prints the following in dmesg:
acpicpu0 at acpi0
C1: unknown FFH vendor 8: !C3(250@85 io@0x1015), C2(500@1 io@0x1014), PSS
The relevant AML indead has that strange value in the Bit Width field:
...
Obviously this ACPI BIOS is buggy and perhaps we should indeed
complain. But we also should include a C1 HALT state in the list
regardless, and I don't think we currently do that.
Give the diff below a try. It inserts a fallback C1-via-halt state
before parsing the _CST objects, overwriting it if a valid _CST C1 state
is found. If no valid _CST C1 was found, the fallback should show in
dmesg as C1(@1 halt!).
As a side-benefit, this renders a couple paranoia checks obsolete in
acpicpu_idle().
Index: dev/acpi/acpicpu.c
===
RCS file: /data/src/openbsd/src/sys/dev/acpi/acpicpu.c,v
retrieving revision 1.64
diff -u -p -r1.64 acpicpu.c
--- dev/acpi/acpicpu.c 13 Jun 2015 21:41:42 - 1.64
+++ dev/acpi/acpicpu.c 28 Jun 2015 21:55:51 -
@@ -77,7 +77,7 @@ void acpicpu_setperf_ppc_change(struct a
/* flags on Intel's FFH mwait method */
#define CST_FLAG_MWAIT_HW_COORD0x1
#define CST_FLAG_MWAIT_BM_AVOIDANCE0x2
-#define CST_FLAG_UP_ONLY 0x4000 /* ignore if MP */
+#define CST_FLAG_FALLBACK 0x4000 /* fallback for broken _CST */
#define CST_FLAG_SKIP 0x8000 /* state is worse choice */
#define FLAGS_MWAIT_ONLY 0x02
@@ -339,7 +339,13 @@ acpicpu_add_cstate(struct acpicpu_softc
dnprintf(10, C%d: latency:.%4x power:%.4x addr:%.16llx\n,
state, latency, power, address);
- cx = malloc(sizeof(*cx), M_DEVBUF, M_WAITOK);
+ /* add a new state, or overwrite the fallback C1 state? */
+ if (state != ACPI_STATE_C1 ||
+ (cx = SLIST_FIRST(sc-sc_cstates)) == NULL ||
+ (cx-flags CST_FLAG_FALLBACK) == 0) {
+ cx = malloc(sizeof(*cx), M_DEVBUF, M_WAITOK);
+ SLIST_INSERT_HEAD(sc-sc_cstates, cx, link);
+ }
cx-state = state;
cx-method = method;
@@ -347,8 +353,6 @@ acpicpu_add_cstate(struct acpicpu_softc
cx-latency = latency;
cx-power = power;
cx-address = address;
-
- SLIST_INSERT_HEAD(sc-sc_cstates, cx, link);
}
/* Found a _CST object, add new cstate for each entry */
@@ -489,9 +493,18 @@ acpicpu_getcst(struct acpicpu_softc *sc)
if (aml_evalname(sc-sc_acpi, sc-sc_devnode, _CST, 0, NULL, res))
return (1);
+ /* provide a fallback C1-via-halt in case _CST's C1 is bogus */
+ acpicpu_add_cstate(sc, ACPI_STATE_C1, CST_METH_HALT,
+ CST_FLAG_FALLBACK, 1, -1, 0);
+
aml_foreachpkg(res, 1, acpicpu_add_cstatepkg, sc);
aml_freevalue(res);
+ /* only have fallback state? then no _CST objects were understood */
+ cx = SLIST_FIRST(sc-sc_cstates);
+ if (cx-flags CST_FLAG_FALLBACK)
+ return (1);
+
/*
* Scan the list for states that are neither lower power nor
* lower latency than the next state; mark them to be skipped.
@@ -500,19 +513,15 @@ acpicpu_getcst(struct acpicpu_softc *sc)
* Also keep track if all the states we'll use use mwait.
*/
use_nonmwait = 0;
- if ((cx = SLIST_FIRST(sc-sc_cstates)) == NULL)
- use_nonmwait = 1;
- else {
- while ((next_cx = SLIST_NEXT(cx, link)) != NULL) {
- if ((cx-power = next_cx-power
- cx-latency = next_cx-latency) ||
- (cx-state 1
- (sc-sc_ci-ci_feature_tpmflags TPM_ARAT) == 0))
- cx-flags |= CST_FLAG_SKIP;
- else if (cx-method != CST_METH_MWAIT)
- use_nonmwait = 1;
- cx = next_cx;
- }
+ while ((next_cx = SLIST_NEXT(cx, link)) != NULL) {
+ if ((cx-power = next_cx-power
+ cx-latency = next_cx-latency) ||
+ (cx-state 1
+ (sc-sc_ci-ci_feature_tpmflags TPM_ARAT) == 0))
+ cx-flags |= CST_FLAG_SKIP;
+ else if (cx-method != CST_METH_MWAIT)
+ use_nonmwait = 1;
+ cx = next_cx;
}
if (use_nonmwait)
sc-sc_flags = ~FLAGS_MWAIT_ONLY;
@@ -581,8 +590,12 @@ acpicpu_print_one_cst(struct acpi_cstate
if (cx-power != -1)
printf(%d, cx-power);
printf(@%d%s, cx-latency, meth);
- if (cx-flags ~CST_FLAG_SKIP)
- printf(.%x, (cx-flags ~CST_FLAG_SKIP));
+ if (cx-flags ~CST_FLAG_SKIP) {
+ if (cx-flags CST_FLAG_FALLBACK)
+ printf(!);
+ else
+ printf(.%x, (cx-flags
Re: [Patch] New item to the Migrating to OpenBSD guide
So the discussion is to probably best put these upgrade details in the upgrade guide, not in the migration guide in the meantime. Without delegating resources until deemed necessary and no need to state explicitly they have no binary upgrades on the migration guide. I think you've already said enough nasty stuff, and noone will pay attention to your wishes anymore.
Re: [Patch] New item to the Migrating to OpenBSD guide
I think you've already said enough nasty stuff Right. I personally am not going to spend a second working on binary updates until I know there are 20+ other developers also dedicated to making it happen, and once it starts happening -- keeps happening forever. Well, not near one, but I volunteer for binary errata patch on current for i386 and amd64 (the only archs I own for now). May need hand holding at first, but eager to test and perfect the procedure. The forever part is a group thing, I'm in. Please kick me at the right time and I'll pick up the task.
Re: Double fault handling on amd64
On Thu, Feb 19, 2015 at 01:50:59PM +, Wei Liu wrote: Hi all When I was trying to debug a double fault on 5.6, I found the trap frame looked a bit strange. After some investigation and reading source code, I found that double fault handling looked problematic. Per Intel SDM volume 3A, processor will push 0 to stack as error code when double fault occurs. Shouldn't it use TRAP instead of ZTRAP in vector.S? I think i386's locore.S looks OK in that regard. I only started reading OpenBSD source code since yesterday, feel free to correct / ignore me if I'm wrong. Wei. --- vector.S.~1.34.~Sat Nov 2 14:23:38 2013 +++ vector.SThu Feb 19 12:01:16 2015 @@ -126,7 +126,7 @@ call_C_LABEL(fpudna) INTRFASTEXIT IDTVEC(trap08) - ZTRAP(T_DOUBLEFLT) + TRAP(T_DOUBLEFLT) IDTVEC(trap09) ZTRAP(T_FPOPFLT) IDTVEC(trap0a) Finally got around to committing this, sorry for the delay. -ml
Re: [Patch] New item to the Migrating to OpenBSD guide
Hi, I would just do some comments inline. On Sun, Jun 28, 2015 at 07:20:51PM +0200, Carlos Fenollosa wrote: Hi, I’ve recently discovered OpenBSD after using Linux for more than 15 years. I wrote a blog article with my impressions and some other users suggested me to patch faq9.html to help other users migrating. This patch is regarding the fact that there are no binary updates, which is a given thing in most Linux distributions, and some tips on how to keep the system updated. Since English is not my first language, before merging the patch, please make sure the wording is proper. If you think the issue may be interesting to elaborate on, I could write a guide of improve on stable.html to help newcomers adapt to this method of keeping up to date. Here’s the whole article if anybody’s interested: http://cfenollosa.com/blog/openbsd-from-a-veteran-linux-user-perspective.html Thanks! Carlos PS: This is my first patch, I’m sending it inline as suggested by http://www.bsdnow.tv/tutorials/patching-obsd. Apologies if this is not the right way. it is the good way. thanks for contributing. Index: faq9.html === RCS file: /cvs/www/faq/faq9.html,v retrieving revision 1.113 diff -u -p -r1.113 faq9.html --- faq9.html 11 May 2015 11:18:30 - 1.113 +++ faq9.html 28 Jun 2015 17:19:45 - @@ -133,6 +133,18 @@ The tree is occasionally broken, but thi will be corrected rapidly, not something that will be permitted to continue. +liThere are no binary security updates. The team has no resources +to constantly compile binaries for all architectures, they do it only +every -release. Thus, unlike Linux distributions, which come with a +package manager which takes care of updates (ttyum/tt, +ttapt-get/tt, etc), there is no single command to update the system +to the latest binary status. It is a bit more complex. The package manager under OpenBSD is pkg_add(1). It is perferctly able to do binaries updates of packages (note we speak about packages, not the base system). But as you noted previously, no binary packages for security updates are provided for -stable. And if pkg_add(1) haven't a suitable source of updated packages, it couldn't do it. Now, when you build your own packages from ports(7) (after updating it), the system will build a binary package. And pkg_add(1) will update your system with this new (updated) package (make install will invoke pkg_add). Keeping up-to-date (including security errata) +is a bit different. You can either (1) upgrade every -release, +(2) apply patches froma href=../errataerrata/a or (3) follow +a href=../stable-stable/a. Binary updates may be obtained +from a href=https://stable.mtier.org;a third party/a for the i386 +and amd64 architectures./li mtier provide third party packages for the -stable version for: - base system (using the same mecanism than for ordinaries packages). As it is for -stable, it includes errata. - standard packages. As it is for -stable, it includes security updates for packages. Thanks. -- Sebastien Marie
Re: [Patch] New item to the Migrating to OpenBSD guide
So, for newcomers from other systems the practical approach would be to follow snapshots to be able to upgrade all (packages on top of base). Install first (once) 1) download a snapshot set (or only bsd.rd for network install) 2) install latest snapshot base OS 3) install your packages with pkg_add (set PKG_PATH to mirror) Upgrade later (repeat) 4) download a fresher snapshot set (or only bsd.rd for network install) 5) upgrade to latest snapshot (boot recent bsd.rd from fresh snapshot) 6) run sysmerge for base and ports 7) upgrading packages with pkg_add -ui Extremely simple and efficient process, by far the best streamlined and easy maintenance compared to other operating systems (or kernels). Please test this procedure and see if this makes you happier after a while, for me it saves a lot of effort. Might be better to put the practical approach in the FAQ, rather than some convoluted explanation about third party stuff instead of a checklist.
Re: [Patch] New item to the Migrating to OpenBSD guide
Who are you? What is your name? That's the first step to establish trust. I would not think in this way Theo. If you need a name and a social status to trust someone, then you're fucked, because everyone can fake this, and a name is just a name, symbols of some language together, nothing more.
