Make ucc(4) pass audio cookie to wskbd(4)
Hi,
I recently bought a JBL USB-C wired headphones for my 2020 Apple MacBook
Air to enjoy audio without disturbing my family. The headphones is
exposed via uaudio(4) as audio1 to the system. The headphones come with
a simple consumer control keyboard supported by ucc(4) and wskbd(4). The
keyboard exposes 2 volume control keys and an unmapped key. The relevant
dmesg(8) lines are:
uaudio0 at uhub1 port 1 configuration 1 interface 1 "KTMICRO JBL TUNE
310C USB-C" rev 2.00/0.03 addr 2
uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec, 5 ctls
audio1 at uaudio0
uhidev0 at uhub1 port 1 configuration 1 interface 3 "KTMICRO JBL TUNE
310C USB-C" rev 2.00/0.03 addr 2
uhidev0: iclass 3/0, 84 report ids
ucc0 at uhidev0 reportid 1: 4 usages, 3 keys, enum
wskbd1 at ucc0 mux 1
wskbd1: connecting to wsdisplay0
uhid0 at uhidev0 reportid 75: input=10, output=10, feature=0
uhid1 at uhidev0 reportid 84: input=10, output=10, feature=0
The volume control keys unfortunately can only control audio0 in an
OpenBSD 7.5-stable system as sys/dev/hid/hidcc.c does not currently pass
the audio cookie it receives from ucc(4) on to wskbd(4). The attached
hidcc_c.patch is a (simple) attempt at fixing this issue. It allows me
to control the volume on my headphones using the consumer control
keyboard, a good quality of life improvement.
Cheers,
Mark
Index: dev/hid/hidcc.c
===
RCS file: /cvs/src/sys/dev/hid/hidcc.c,v
diff -u -r1.5 hidcc.c
--- dev/hid/hidcc.c 14 Nov 2022 00:16:44 - 1.5
+++ dev/hid/hidcc.c 7 Jul 2024 15:42:13 -
@@ -593,7 +593,7 @@
#undef N
};
-void hidcc_attach_wskbd(struct hidcc *);
+void hidcc_attach_wskbd(struct hidcc *, void *);
int hidcc_enable(void *, int);
void hidcc_set_leds(void *, int);
int hidcc_ioctl(void *, u_long, caddr_t, int, struct proc *);
@@ -667,7 +667,7 @@
/* Cannot load an empty map. */
if (sc->sc_maplen > 0)
- hidcc_attach_wskbd(sc);
+ hidcc_attach_wskbd(sc, hca->audio_cookie);
return sc;
}
@@ -755,7 +755,7 @@
}
void
-hidcc_attach_wskbd(struct hidcc *sc)
+hidcc_attach_wskbd(struct hidcc *sc, void *audio_cookie)
{
static const struct wskbd_accessops accessops = {
.enable = hidcc_enable,
@@ -767,7 +767,7 @@
.keymap = >sc_keymap,
.accessops = ,
.accesscookie = sc,
- .audiocookie = NULL, /* XXX audio_cookie */
+ .audiocookie = audio_cookie
};
sc->sc_keydesc[0].name = KB_US;
Important message for Apple Silicon OpenBSD/arm64 users
As indicated here: https://social.treehouse.systems/@AsahiLinux/112449204541186432 The system firmware that comes with macOS Sonoma 14.5 triggers a bug in the m1n1 bootloader that is used to boot OpenBSD on these machines. The bug will prevent OpenBSD from booting on some machines after the macOS update has been installed. The recommended fix is to update the "stage1" m1n1 by booting into macOS and running: $ curl https://alx.sh | sh choosing the 'm' option when prompted to upgrade as indicated in the aforementioned post. This should work even if you've already installed the macOS update. We've also released a new version of the "apple-boot" firmware (which contains a "stage2" m1n1) that has a workaround for the bug. To install this new firmware on OpenBSD 7.5 or -current, you can do: # fw_update # installboot sd0 This must be done before updating macOS. You can verify that the workaround is installed with the following command: # eeprom -p | grep m1n1 asahi,m1n1-stage2-version: '1.4.14' If the displayed version number is 1.4.14 or later, the workaround is installed. OpenBSD 7.4 users should upgrade to OpenBSD 7.5. Cheers, Mark
Re: 7.5: Fatal errors from eigrpd
(Gah! Here's the post again in plaintext. Apologies.)
Hello all,
I'm running eigrpd in a VMWare environment and after upgrading to 7.5 from
7.4 I'm noticing eigrpd is failing with a couple different errors. In 7.4
and prior I never had any problems.
I tried to include everything that I thought might be relevant but if
there's any other information I can provide please let me know.
Has anyone else come across anything similar?
Thanks,
Mark
examples:
test1# eigrpd -dv
startup
eigrp_if_start: lo1 as 1 family ipv4
eigrp_if_start: em0 as 1 family ipv4
if_join_ipv4_group: interface em0 addr 224.0.0.10
rt_new: prefix aa.bb.cc.1/32
route_new: prefix aa.bb.cc.1/32 via connected distance (28160/0)
rt_new: prefix 198.18.101.0/24
route_new: prefix 198.18.101.0/24 via connected distance (28160/0)
fatal in eigrpe: send_packet: get hdr failed
rt_del: prefix aa.bb.cc.1/32
route_del: prefix aa.bb.cc.1/32 via connected
rt_del: prefix 198.18.101.0/24
route_del: prefix 198.18.101.0/24 via connected
route decision engine exiting
kernel routing table decoupled
waiting for children to terminate
terminating
and
RouterTest# eigrpd -dv
startup
eigrp_if_start: em1 as 1 family ipv4
if_join_ipv4_group: interface em1 addr 224.0.0.10
rt_new: prefix 198.18.101.0/24
route_new: prefix 198.18.101.0/24 via connected distance (28160/0)
rt_del: prefix 198.18.101.0/24
route_del: prefix 198.18.101.0/24 via connected
route decision engine exiting
kernel routing table decoupled
waiting for children to terminate
eigrp engine terminated; signal 11
terminating
This is happening on two of two upgraded VMs.
SHA256 (/usr/sbin/eigrpd) =
3b85d7ac155afe4edd355f8b1d8c81f77c6254d96410af8b22f4018b756282a6
(just in case)
I've tried with net.inet.tcp.tso=0 and net.inet.tcp.tso=1. Same result.
test1# uname -a
OpenBSD test1.local 7.5 GENERIC.MP#82 amd64
The configs I'm running are pretty basic:
RouterTest# eigrpd -n
configuration OK
RouterTest# eigrpd -nv
router-id 198.18.101.1
fib-update yes
rdomain 0
fib-priority-internal 28
fib-priority-external 28
fib-priority-summary 28
address-family ipv4 {
autonomous-system 1 {
k-values 1 0 1 0 0 0
active-timeout 3
maximum-hops 100
maximum-paths 4
variance 8
default-metric 10 10 255 1 1500
interface em1 {
hello-interval 5
holdtime 15
delay 10
bandwidth 10
split-horizon yes
}
}
}
address-family ipv6 {
}
7.5: Fatal errors from eigrpd
Hello all,
I'm running eigrpd in a VMWare environment and after upgrading to 7.5 from
7.4 I'm noticing eigrpd is failing with a couple different errors. In 7.4
and prior I never had any problems.
I tried to include everything that I thought might be relevant but if
there's any other information I can provide please let me know.
Has anyone else come across anything similar?
Thanks,
Mark
examples:
test1# eigrpd -dv
startup
eigrp_if_start: lo1 as 1 family ipv4
eigrp_if_start: em0 as 1 family ipv4
if_join_ipv4_group: interface em0 addr 224.0.0.10
rt_new: prefix aa.bb.cc.1/32
route_new: prefix aa.bb.cc.1/32 via connected distance (28160/0)
rt_new: prefix 198.18.101.0/24
route_new: prefix 198.18.101.0/24 via connected distance (28160/0)
fatal in eigrpe: send_packet: get hdr failed
rt_del: prefix aa.bb.cc.1/32
route_del: prefix aa.bb.cc.1/32 via connected
rt_del: prefix 198.18.101.0/24
route_del: prefix 198.18.101.0/24 via connected
route decision engine exiting
kernel routing table decoupled
waiting for children to terminate
terminating
and
RouterTest# eigrpd -dv
startup
eigrp_if_start: em1 as 1 family ipv4
if_join_ipv4_group: interface em1 addr 224.0.0.10
rt_new: prefix 198.18.101.0/24
route_new: prefix 198.18.101.0/24 via connected distance (28160/0)
rt_del: prefix 198.18.101.0/24
route_del: prefix 198.18.101.0/24 via connected
route decision engine exiting
kernel routing table decoupled
waiting for children to terminate
eigrp engine terminated; signal 11
terminating
This is happening on two of two upgraded VMs.
SHA256 (/usr/sbin/eigrpd) =
3b85d7ac155afe4edd355f8b1d8c81f77c6254d96410af8b22f4018b756282a6
(just in case)
I've tried with net.inet.tcp.tso=0 and net.inet.tcp.tso=1. Same result.
test1# uname -a
OpenBSD test1.local 7.5 GENERIC.MP#82 amd64
The configs I'm running are pretty basic:
RouterTest# eigrpd -n
configuration OK
RouterTest# eigrpd -nv
router-id 198.18.101.1
fib-update yes
rdomain 0
fib-priority-internal 28
fib-priority-external 28
fib-priority-summary 28
address-family ipv4 {
autonomous-system 1 {
k-values 1 0 1 0 0 0
active-timeout 3
maximum-hops 100
maximum-paths 4
variance 8
default-metric 10 10 255 1 1500
interface em1 {
hello-interval 5
holdtime 15
delay 10
bandwidth 10
split-horizon yes
}
}
}
address-family ipv6 {
}
Re: mailman on OpenBSD - linking problem
On Wed, Mar 13, 2024 at 5:44 PM Odhiambo Washington wrote: > > This is why I suggested he should run Mailman3 from the word go. > > > It looks almost impossible to setup Mailman3 on OpenBSD. No, this is not working at all; https://xn--gckvb8fzb.com/mailman3-on-openbsd-71/ Any other tutorial I could try? Thank you.
Re: mailman on OpenBSD - linking problem
On Tue, Mar 12, 2024 at 8:52 PM Michael Hekeler wrote:
> But please keep in mind that you have disabled chroot and this is not
> recommended.
> Maybe you want to consider to copy the needed files inside the chroot?
> Or perhaps deploy mailman with something like gunicorn or uwsgi?
>
>
Hi Michael,
Thanks a lot for the suggestions and tips.
It's a basic mailing list for few gaming discussions really,
so escaping from chroot was not really that scary, at least in that case.
OpenBSD, even unchrooted, is rock solid! No? :)
After your suggestions, the latest httpd.conf is as follows;
location "/" {
block return 302 "/listinfo"
}
location "/icons/*" {
root "/usr/local/lib/mailman/icons/"
request strip 1
}
location "/pipermail/*" {
root "/var/spool/mailman/archives/public"
request strip 1
}
location "/*" {
fastcgi socket "/var/www/run/slowcgi.sock"
root "/usr/local/lib/mailman/cgi-bin"
}
my httpd.conf is much cleaner and simpler now, thanks to you guys all,
it seems everything is all set now.
Anything else I should pay attention to?
Best,
Mark.
Re: mailman on OpenBSD - linking problem
On Mon, Mar 11, 2024 at 11:16 AM Michael Hekeler wrote: > I don't know this mailman script but... > Why did you strip first component from the request? > Are these cgi's in /usr/local/lib/mailman/cgi-bin/admin or in > /var/www/usr/local/lib/mailman/cgi-bin/admin? > What is your chroot setting in httpd.conf? > And IF you changed httpd chroot how do you start slowcgi(8)? > What/where is socket? Where is path? > > Hi Michael, What does "request strip 1" actually do in that case? The cgi files are in /usr/local/lib/mailman/cgi-bin/ chroot setting in httpd.conf: chroot "/" Slowcgi starts with: slowcgi_flags="-p /" and it's socket path is: /var/www/run/slowcgi.sock Slowcgi and httpd works fine. However two things I'd like to know; As I asked, what does "request strip 1" do and if I really need that? Secondly; how to combine two locations into one? So that; "/admin" and "/admin/" would get captured both. Best wishes, Mark.
httpd location question
Hi,
In httpd, my web portal gives an HTTP 404 error when 'mysite.com/create' is
typed,
however 'mysite.com/create/' works.
In order to *solve* this issue, I added 2 different locations pointing to
the same cgi script, as:
location "/create" {
fastcgi socket "/var/www/run/slowcgi.sock"
root "/usr/local/lib/mailman/cgi-bin/create"
request strip 1
}
location "/create/*" {
fastcgi socket "/var/www/run/slowcgi.sock"
root "/usr/local/lib/mailman/cgi-bin/create"
request strip 1
}
I have lots of cgi and the httpd.conf would grow a lot,
Thus, wondering how to make both way (with ending '/' and without) to work
in a single location?
Is there any directive or regex for the 'location' directive,
so that both requests for '/create' and '/create/' would work?
Best wishes,
Mark.
mailman on OpenBSD - linking problem
Hi.
I set up a mailman on OpenBSD, and it seems I have managed to do it.
A single problem left, that I'd like to share with you and get your idea;
On mailman homepage, there is a link "you can visit the list admin overview
page"
and when I click, redirects me: mysite.com/admin and it gives error 404.
However if I add "/" at the end, making mysite.com/admin/, it works.
Also the same happens on the linked-text;
"Overview of all list.mysite.com mailing lists" linking to;
mysite.com/listinfo, which gives 404 not found when clicking on it.
But with an extra '/'; mysite.com/listinfo/ works.
Where's my mistake?
Related httpd.conf lines;
location "/admin/*" {
fastcgi socket "/var/www/run/slowcgi.sock"
root "/usr/local/lib/mailman/cgi-bin/admin"
request strip 1
}
location "/listinfo/*" {
fastcgi socket "/var/www/run/slowcgi.sock"
root "/usr/local/lib/mailman/cgi-bin/listinfo"
request strip 1
}
Regards,
Mark.
"FollowSymLinks" equivalent in httpd?
Greetings. Trying to figure out the mailman configuration on OpenBSD. What is the equivalent of the following server block in httpd? " Options FollowSymLinks AllowOverride None " Does the httpd even support following symlinks? Regards, Mark
Re: SoGo for OpenBSD?
On Tue, Feb 20, 2024 at 3:57 PM Sebastian Reitenbach < sebas...@l00-bugdead-prods.de> wrote: > is i...@mysite.com your e-mail there? Or is there something still not yet > configured? > In any case, this is now getting off-topic, and might be better asked on > the SOGo mailing > lists. > > > Each time I refresh the browser page (while SOGo inbox is open). > > > > It happens every time, every refresh adds such an error line in the > > sogo.log file, and changing browsers did not help. > > > > And I have too many; > > "Loading two versions of" lines, like; > > > > Loading two versions of SOGoTrashFolder. The class that will be used is > > undefined > > Loading two versions of SOGoMailFolder. The class that will be used is > > undefined > > Loading two versions of SOGoSpecialMailFolder. The class that will be > used > > is undefined > > these warnings can be ignored. Hi Sebastian, I completed configuring SOGo on my OpenBSD system, now it works fine. Thanks to Odhiambo and you. The only thing is, that I'd like to report you; My webserver reports in its log file, "file not found" for SOGo; /usr/local/lib/GNUstep/SOGo/WebServerResources/js/vendor/ckeditor/plugins/autocomplete/skins/default.css" failed (2: No such file or directory) I thought you might wish to have a look at this, as apparently the mentioned directories; "autocomplete/skins/default.css" are not there at all. Best, Mark.
Re: SoGo for OpenBSD?
Odhiambo Washington , wrote:
> You just need the password field. The password scheme does not matter.
> You can name the VIEW anything you want. Just make sure you use whatever
> you name it in the SOGoUserSources block in sogo.conf:
> SOGoUserSources =
> (
> {
> type = sql;
> id = directory;
> viewURL = "mysql://
> DBUSERNAME:{userpassword}@127.0.0.1:3306/DBNAME/
> <http://DBUSERNAME:%7Buserpassword%7D@127.0.0.1:3306/DBNAME/>*VIEW_NAME*";
> canAuthenticate = YES;
> isAddressBook = YES;
> userPasswordAlgorithm = blf-crypt;
> }
> );
>
Mr. Odhiambo, and all, thank you all very much for your help, I really
appreciate it,
I now have a fully working -well it seems- SOGo webmail by your help.
The two things I'd like to solve are;
I have in my sogo.log file;
[ERROR] <0x0x53075b5bb68[WOHttpTransaction]>
client disconnected during delivery of response for
(len=50): the
socket was shutdown
Each time I refresh the browser page (while SOGo inbox is open).
It happens every time, every refresh adds such an error line in the
sogo.log file, and changing browsers did not help.
And I have too many;
"Loading two versions of" lines, like;
Loading two versions of SOGoTrashFolder. The class that will be used is
undefined
Loading two versions of SOGoMailFolder. The class that will be used is
undefined
Loading two versions of SOGoSpecialMailFolder. The class that will be used
is undefined
However, they're defined in my sogo.conf file.
Any clue for these?
Best regards,
Mark.
Re: SoGo for OpenBSD?
Odhiambo Washington , wrote: Thank you, Sebastian. After knowing that I can use /etc/sogo/sogo.conf and > after installing sope-mysql-5.9.1, life should be a lot easier for Mark. > It's a matter of creating the VIEW to be used by SOGo for authenticating > the users from the MySQL database. > In my database I created it as follows: > USE exim4u; > CREATE VIEW sogo_auth_view AS SELECT user_id AS sogo_id, username AS > c_uid, username AS c_name, crypt AS c_password, realname AS c_cn, username > AS mail, realname AS displayName FROM users WHERE enabled='1'; > EXIT; > > The VIEW is used in sogo.conf as per the tutorial referred to before. > > Thank you so much, Odhiambo for the idea. Two questions; 1- My password scheme in my database is BLF-CRYPT (blowfish), should I mention this for the CREATE VIEW command? (reading that you put crypt AS c_password) 2- You created "sogo_auth_view" it seems, however the tutorial you sent does it for "sogo_view", why so? Much regards, Mark.
Re: SoGo for OpenBSD?
> > SOGo depends on SOPE, that has two subpackages for PostgreSQL and > MySQL/MariaDB. > If you want to use MariaDB as backend, you have to install the sope-mysql > subpackage, as mentioned in the SOGo README. > > As also mentioned in the README, you can use the GNUstep defaults tool > su - _sogo > $ defaults write sogod WOPort 127.0.0.1:2 > $ defaults write sogod WOWorkersCount 4 > ... > $ defaults read > sogod WOWorkersCount 4 > sogod WOPort 127.0.0.1:2 > ... > > If you insist on the config file, > you should be able to take the sogo.conf example file from: > https://github.com/Alinto/sogo/blob/master/Scripts/sogo.conf > as a start, and place it in /etc/sogo/sogo.conf > > When I remember at the next update, I'll include to install it, > otherwise if someone provides patches before that time, > send them to me directly. > > Sebastian > Thanks for that info, Sebastian. It'd be much better for me to have a single configuration file to manage all the options, settings and values within there, instead of configuring SOGo in the shell, line by line. Question #1; There is no /etc/sogo/ folder by the default after pkg_add sogo. If I manually create /etc/sogo/sogo.conf, would SOGo automatically recognize it? Or some "sogod_flags" in rc.conf.local would be needed to point to the configuration file? Question #2: Would "pkg_add sope-mysql" be a correct way to add MariaDB backend? (The file "/usr/local/share/doc/pkg-readmes/sogo" does not mention anything about that, but perhaps I'm looking for a wrong README) Many thanks, Mark.
Re: SoGo for OpenBSD?
Thanks Odhiambo, As I said, I already have a mail server setup, it's ready and working correctly. I only want to integrate SOGo into that mail server. My mail server is running: Dovecot, Postfix, Postfixadmin (domains and users stored in MariaDB). That's all. Odhiambo Washington , 17 Şub 2024 Cmt, 14:53 tarihinde şunu yazdı: > > > On Sat, Feb 17, 2024 at 1:06 PM Mark wrote: > >> Hi again everyone, Thanks for all your replies. >> >> I'm aware that I could install with "pkg_add sogo", I tried many times. >> >> My issue is its configuration. >> >> My mail server setup consists of; Postfix, Dovecot, Postfixadmin and >> Nginx. >> >> I'm looking for a way to integrate SOGo (only for its webmail interface, >> nothing more) into my mailserver. >> >> There is no sogo.conf at all. And I'd like to use that way, instead of >> GNUStep commands. >> >> @Sebastian, is it possible to set SOGo to use /etc/sogo.conf as >> configuration file? >> >> @Odhiambo, thank you very much for the links, the buff0k.co.za one seems >> to >> be helpful, even though it's for Debian. >> > > Hi Mark, > > I knew that the buff0k.co.za was Debian. However, the only difference > with OpenBSD are the installation commands. > The configurations are pretty identical as long as you conform with the > standard paths USDed by OBSD. > @Sebastian mentioned that the pkg installs a readme > in /usr/local/share/doc/pkg-readmes/sogo. > > I have looked at it too. I installed SOGo on my VM, but one thing that I > do not understand is how it will be able to interact with mariadb, > given that I have seen the SOPE component only linked against PostgreSQL > and not MySQL. > @Sebastian Reitenbach could you kindly > enlighten me on that aspect? How do I have SOPE linked to mysqlclient? Or > both mysqlclient and libpq? > > To install a "Complete Mail Server on OpenBSD" you can also use the guide > below: > > https://docs.vultr.com/an-openbsd-e-mail-server-using-opensmtpd-dovecot-rspamd-and-rainloop > Here, you can ignore the RainLoop webmail as you will use SOGo. > > > -- > Best regards, > Odhiambo WASHINGTON, > Nairobi,KE > +254 7 3200 0004/+254 7 2274 3223 > In an Internet failure case, the #1 suspect is a constant: DNS. > "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) > [How to ask smart questions: > http://www.catb.org/~esr/faqs/smart-questions.html] >
Re: SoGo for OpenBSD?
Hi again everyone, Thanks for all your replies. I'm aware that I could install with "pkg_add sogo", I tried many times. My issue is its configuration. My mail server setup consists of; Postfix, Dovecot, Postfixadmin and Nginx. I'm looking for a way to integrate SOGo (only for its webmail interface, nothing more) into my mailserver. There is no sogo.conf at all. And I'd like to use that way, instead of GNUStep commands. @Sebastian, is it possible to set SOGo to use /etc/sogo.conf as configuration file? @Odhiambo, thank you very much for the links, the buff0k.co.za one seems to be helpful, even though it's for Debian. Regards, Mark Odhiambo Washington , 17 Şub 2024 Cmt, 11:55 tarihinde şunu yazdı: > > > On Fri, Feb 16, 2024 at 4:08 PM Mark wrote: > >> Greetings. >> >> Is there any hero here, to explain/forward me a working tutorial (never >> found one) for installation of SoGo (for its webmail) on an OpenBSD mail >> server? >> > > Hi Mark, > > I am new to OpenBSD, but I have used SOGo for several years on Linux and > FreeBSD. > SOGo will be the webUI for your emails and calendar once it's running. > For the installation, you already have the 'doas pkg_add sogo'. You will > then configure it. > There are two ways to configure it, but I find it easiest to just craft a > configuration file in /etc/sogo/sogo.conf. > I am not sure where OpenBSD puts it, but the path above is where Linux > puts it. FreeBSD OTOH uses > /usr/local/etc/sogo/sogo.conf. > The backend in my case is MariaDB, with Exim (MTA) and Dovecot as the > IMAP4 server. > Here is a detailed tutorial for getting SOGo glued together with other > applications to create a Groupware server: > ``` > https://www.buff0k.co.za/tutorial/debian-11-groupware-lemp > ``` > The complete documentation for SOGo is at: > ``` > > https://www.sogo.nu/files/docs/SOGoInstallationGuide.html#_creating_a_user_account > ``` > In case you get stuck with something specific to SOGo, then there's an ML > for it where the Devs are also present: > ``` > https://www.sogo.nu/support.html > ``` > > I will be available to help where I can. > > > -- > Best regards, > Odhiambo WASHINGTON, > Nairobi,KE > +254 7 3200 0004/+254 7 2274 3223 > In an Internet failure case, the #1 suspect is a constant: DNS. > "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) > [How to ask smart questions: > http://www.catb.org/~esr/faqs/smart-questions.html] >
SoGo for OpenBSD?
Greetings. Is there any hero here, to explain/forward me a working tutorial (never found one) for installation of SoGo (for its webmail) on an OpenBSD mail server?
Second Redis instance?
Hi. I've redis-6.2.13 installed and running. I need to run a second Redis instance with a different .conf file. For instance, under FreeBSD, this is as easy as adding in rc.conf file; redis_profiles="foo bar" Giving opportunity to use /usr/local/etc/redis-FOO.conf /usr/local/etc/redis-BAR.conf respectively, as separate instances. How can I do the same under OpenBSD 7.4? Any help, ideas, tips & tricks would be appreciated, Kindest regards. Mark.
Re: New postfix-3.8.20221007p12 broken TLS for Gmail servers?
> 3.7.9 is a newer version than 3.8.20221007 Stuart, thanks very much for this information, I didn't know about that. Moved to 3.7.9 and it's working fine right now. Configured my postfix from scratch, though, to prevent any misconfiguration on my side. Best wishes, Mark. Stuart Henderson , 3 Şub 2024 Cmt, 16:23 tarihinde şunu yazdı: > On 2024-02-03, Mike Fischer wrote: > > > >> Am 03.02.2024 um 03:44 schrieb Brian Conway : > >> > >>> Why do you run such an outdated postfix snapshot? > >> > >> That is the latest version that is supported/available in > packages-stable: > >> > >> https://cdn.openbsd.org/pub/OpenBSD/7.4/packages-stable/amd64/ > > > > While we have not encountered the TLS issue with Gmail (see below) we > are in the same boat otherwise. postfix-3.8.20221007 seemed like the newest > version a while back and so we are running that version. Going back to > 3.7.9 seems like it may be a partial step backwards. > > 3.7.9 is a newer version than 3.8.20221007. > > -- > Please keep replies on the mailing list. > >
Re: New postfix-3.8.20221007p12 broken TLS for Gmail servers?
As an additional note; I upgraded my server yesterday from (amd64) OpenBSD 7.3 to 7.4 by sysupgrade tool (remotely - unattended way). Is it possible that the upgrade process created trouble with TLS, SSL libraries? It was completed without any "visible" issue, as far as I can tell. Regards. Mark , 3 Şub 2024 Cmt, 10:34 tarihinde şunu yazdı: > Hi again, > > I completely removed Postfix and installed the official stable package > "postfix-3.7.9p0-sasl2-mysql", but the problem persists. > > P.S.: The issue only happens with incoming mails from Gmail servers. > > (Well, I do have the needed lines recommended in smtp-smuggling page, the > ones for "works with all versions".) > > > Herbert J. Skuhra , 3 Şub 2024 Cmt, 10:28 tarihinde > şunu yazdı: > >> On Sat, Feb 03, 2024 at 09:19:47AM +0300, Mark wrote: >> > An experimental, unstable package in packages-stable? >> > >> > An outdated and potentially vulnerable software in the latest OpenBSD >> > 7.4-stable? >> > >> > I must really have been missing something here... >> >> Just a few links: >> >> >> https://github.com/openbsd/ports/blob/master/mail/postfix/snapshot/Makefile >> http://ftp.porcupine.org/mirrors/postfix-release/index.html#experimental >> https://www.postfix.org/smtp-smuggling.html >> >> -- >> Herbert >> >>
Re: New postfix-3.8.20221007p12 broken TLS for Gmail servers?
Hi again, I completely removed Postfix and installed the official stable package "postfix-3.7.9p0-sasl2-mysql", but the problem persists. P.S.: The issue only happens with incoming mails from Gmail servers. (Well, I do have the needed lines recommended in smtp-smuggling page, the ones for "works with all versions".) Herbert J. Skuhra , 3 Şub 2024 Cmt, 10:28 tarihinde şunu yazdı: > On Sat, Feb 03, 2024 at 09:19:47AM +0300, Mark wrote: > > An experimental, unstable package in packages-stable? > > > > An outdated and potentially vulnerable software in the latest OpenBSD > > 7.4-stable? > > > > I must really have been missing something here... > > Just a few links: > > https://github.com/openbsd/ports/blob/master/mail/postfix/snapshot/Makefile > http://ftp.porcupine.org/mirrors/postfix-release/index.html#experimental > https://www.postfix.org/smtp-smuggling.html > > -- > Herbert > >
Re: New postfix-3.8.20221007p12 broken TLS for Gmail servers?
An experimental, unstable package in packages-stable? An outdated and potentially vulnerable software in the latest OpenBSD 7.4-stable? I must really have been missing something here... Herbert J. Skuhra , 3 Şub 2024 Cmt, 09:04 tarihinde şunu yazdı: > On Fri, Feb 02, 2024 at 08:44:45PM -0600, Brian Conway wrote: > > On Fri, Feb 2, 2024, at 6:44 PM, Herbert J. Skuhra wrote: > > > On Sat, Feb 03, 2024 at 03:00:10AM +0300, Mark wrote: > > >> Hi. > > >> > > >> It seems that the recent Postfix update under 7.4-amd64, > > >> (package: postfix-3.8.20221007p12-sasl2-mysql) breaks TLS connections, > > >> coming from Gmail servers, throwing a TLS library problem. > > >> > > >> Here's the log output; > > >> > > >> postfix/smtpd[32879]: connect from mail-yw1-f178.google.com > [209.85.128.178] > > >> > > >> postfix/smtpd[7374]: Trusted TLS connection established from > > >> mail-lf1-f45.google.com[209.85.167.45]: TLSv1.3 > > >> with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 > > >> server-signature ECDSA (prime256v1) server-digest SHA256 > client-signature > > >> RSA-PSS (2048 bits) client-digest SHA256 > > >> > > >> postfix/smtpd[7374]: warning: TLS library problem: error:0A000126:SSL > > >> routines::unexpected eof while reading:ssl/record/rec_layer_s3.c:308: > > >> postfix/smtpd[7374]: lost connection after STARTTLS from > > >> mail-lf1-f45.google.com[209.85.167.45] > > >> postfix/smtpd[7374]: disconnect from mail-lf1-f45.google.com > [209.85.167.45] > > >> ehlo=1 starttls=1 commands=2 > > >> > > >> Before updating the package, I had postfix-3.8.20221007p11, and it > had no > > >> such problem. > > > > > > Why do you run such an outdated postfix snapshot? > > > > That is the latest version that is supported/available in > packages-stable: > > > > https://cdn.openbsd.org/pub/OpenBSD/7.4/packages-stable/amd64/ > > Yeah, sadly! But no reason to install/run outdated and potentially > vulnerable server software. :-) > > Postfix 3.8.20221007 is an old development snapshot (experimental!). It > should be either updated or removed. Latest version as of today is > postfix-3.9-20240129. There are also updates available for postfix35 > (3.5.24) and postfix (3.7.10/3.8.5). > > -- > Herbert > >
New postfix-3.8.20221007p12 broken TLS for Gmail servers?
Hi. It seems that the recent Postfix update under 7.4-amd64, (package: postfix-3.8.20221007p12-sasl2-mysql) breaks TLS connections, coming from Gmail servers, throwing a TLS library problem. Here's the log output; postfix/smtpd[32879]: connect from mail-yw1-f178.google.com[209.85.128.178] postfix/smtpd[7374]: Trusted TLS connection established from mail-lf1-f45.google.com[209.85.167.45]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256 postfix/smtpd[7374]: warning: TLS library problem: error:0A000126:SSL routines::unexpected eof while reading:ssl/record/rec_layer_s3.c:308: postfix/smtpd[7374]: lost connection after STARTTLS from mail-lf1-f45.google.com[209.85.167.45] postfix/smtpd[7374]: disconnect from mail-lf1-f45.google.com[209.85.167.45] ehlo=1 starttls=1 commands=2 Before updating the package, I had postfix-3.8.20221007p11, and it had no such problem. Any idea? Regards. Mark.
Re: cdn.openbsd.org: packages-stable not up to date
So, any clue? 15 Ocak 2024 Pazartesi tarihinde K R yazdı: > Hi, > > It seems packages-stable from cdn.openbsd.org haven't been > updated since Dec, 25th: > > $ curl -s https://cdn.openbsd.org/pub/OpenBSD/7.4/packages-stable/ | grep > amd64 > amd64/ 25-Dec-2023 06:06 > > ftp.openbsd.org seems fine, though: > > $ curl -s https://ftp.openbsd.org/pub/OpenBSD/7.4/packages-stable/ | grep > amd64 > amd64/ 13-Jan-2024 18:15 > > Thanks, > --Kor > >
Re: time keeping fallback mechanics during reboot on octeon
> From: Theo de Raadt > Date: Sat, 13 Jan 2024 07:39:34 -0700 (MST) > > Blocking the timeupdate in ffs_sbupdate() will be difficult. > > It is probably easier to have the BOOT kernel learn the time (from the > true root filesystem), so that ffs_sbupdate() writes back the same > value. > > That means either an ugly way to reach inittodr() or the userland code > in the bootblock could read the superblock and settimeofday(). > > But it might slide a bit.. I'd say it would be better (and easier) to have BOOT kernels not update the time in the superblock. That would closely resemble whathappens if we write to the filesystem in our normal bootloaders.
Re: Upgrading from 7.3 to 7.4 with sysupgrade
"> That will never happen." And some serious reason? It was a great idea indeed. :/ Theo de Raadt , 17 Kas 2023 Cum, 18:20 tarihinde şunu yazdı: > Odd Martin Baanrud wrote: > > > Perhaps sysupgrade should be enhanced, so one could either choose which > sets should be upgraded, or even beter, the tool could figure out which > sets are installed, and upgrade just those. > > That will never happen. > > > >
Re: ImageMagick fails on OpenBSD 7.4 fresh install
It wasn't an upgraded system, that's fresh install, a completely new
OpenBSD 7.4 amd64.
And the first package I wanted to install, was imagick. And it failed as on
the screenshot image link.
However, installing the "gtk-update-icon-cache" package, and after, pkg_add
imagick solved the problem.
That was the suggestion of "quinq", from IRC #openbsd. ("can you try
installing that package, and then ImageMagick?")
Philip Guenther , 23 Eki 2023 Pzt, 02:54 tarihinde şunu
yazdı:
> Don't know what's wrong with the pkg database (/var/db/pkg/) on your
> system, but on mine the shared-mime-info-2.2 package includes a definition
> for the update-mime-info tag, so if yours lacks that then something in
> there got hosed during your upgrade. Could be data loss from disk failure,
> could be something pruned critical info from /var/db/pkg/, could be
> something I can't think of.
>
> So, I would suggest starting with verifying your confidence in your
> storage (no kernel log error messages about I/O errors? If this machine
> has suffered any file system issues then maybe backup, verify-backup, newfs
> and restore?)
>
> Then I would probably reinstall *all* packages, but since I don't (fully)
> trust the pkg database, I would probably do it with the
> 1) pkg_info -mz > manual
> 2) cd /var/db/pkg && pkg_delete *
> 3) make sure nothing unexpected has been left behind in /var/db/pkg/ or
> /usr/local/*
> 4) pkg_add -l manual
>
>
> Or maybe now's a good time to do a fresh install.
>
>
> Philip Guenther
>
>
> On Sun, Oct 22, 2023 at 3:34 PM Mark wrote:
>
>> Tried changing the installurl, an another mirror, but didn't help.
>>
>> Here's what actually happens;
>>
>> https://i.ibb.co/G0wbGf5/terminal-sshot.png
>>
>> Regards.
>>
>> Mark , 23 Eki 2023 Pzt, 01:16 tarihinde şunu
>> yazdı:
>>
>> > pkg_add ImageMagick-6.9.12.88p0 gives me;
>> >
>> > (after fetching few libraries)
>> >
>> > "Can't install ImageMagick-6.9.12.88p0: can't resolve
>> > djvulibre-3.5.28p1,libheif-1.16.2p0"
>> >
>> > and then;
>> > "Couldn't install ImageMagick-6.9.12.88p0 djvulibre-3.5.28p1
>> > libheif-1.16.2p0."
>> >
>> > This is a fresh OpenBSD 7.4 amd64 release. My installurl is pointed to
>> > cdn.openbsd.org/pub/OpenBSD.
>> >
>> > Any other php packages were installed fine. But both
>> > pecl80-imagick-3.7.0p1 and ImageMagick fail.
>> >
>> > Some idea would be much appreciated!
>> >
>> > Regards.
>> >
>>
>
Re: ImageMagick fails on OpenBSD 7.4 fresh install
Tried changing the installurl, an another mirror, but didn't help. Here's what actually happens; https://i.ibb.co/G0wbGf5/terminal-sshot.png Regards. Mark , 23 Eki 2023 Pzt, 01:16 tarihinde şunu yazdı: > pkg_add ImageMagick-6.9.12.88p0 gives me; > > (after fetching few libraries) > > "Can't install ImageMagick-6.9.12.88p0: can't resolve > djvulibre-3.5.28p1,libheif-1.16.2p0" > > and then; > "Couldn't install ImageMagick-6.9.12.88p0 djvulibre-3.5.28p1 > libheif-1.16.2p0." > > This is a fresh OpenBSD 7.4 amd64 release. My installurl is pointed to > cdn.openbsd.org/pub/OpenBSD. > > Any other php packages were installed fine. But both > pecl80-imagick-3.7.0p1 and ImageMagick fail. > > Some idea would be much appreciated! > > Regards. >
ImageMagick fails on OpenBSD 7.4 fresh install
pkg_add ImageMagick-6.9.12.88p0 gives me; (after fetching few libraries) "Can't install ImageMagick-6.9.12.88p0: can't resolve djvulibre-3.5.28p1,libheif-1.16.2p0" and then; "Couldn't install ImageMagick-6.9.12.88p0 djvulibre-3.5.28p1 libheif-1.16.2p0." This is a fresh OpenBSD 7.4 amd64 release. My installurl is pointed to cdn.openbsd.org/pub/OpenBSD. Any other php packages were installed fine. But both pecl80-imagick-3.7.0p1 and ImageMagick fail. Some idea would be much appreciated! Regards.
Re: SSL issues after upgrading from 7.3 to 7.4
So, no idea on this? There are people having similar SSL issues (have been reading about them in IRC channels) I don't use TLSv1.0, TLSv1.1 neither. I'm aware of the related-changes in 7.4. Best, Mark. Mark , 16 Eki 2023 Pzt, 22:01 tarihinde şunu yazdı: > Hi. > > First of all, thank you very much for all your great efforts on 7.4! > > I upgraded my VPS from 7.3 to 7.4, and It's weird that, after upgrade, > Qualys SSL Labs test for HTTPS/SSL websites gives: > "HTTP request to this server failed, see below for details." > > However, my website works fine with browsers, > and my nginx configuration has nothing weird at all, > checked with "nginx -t", I had no such message as I checked just before I > upgraded. > > And also, one more tool; immuniweb.com/ssl/ reports: > "SERVER DOES NOT SUPPORT OCSP STAPLING" after the upgrade. > > However, again, OCSP stapling is implemented correctly in my nginx.conf > file, working since a year. > > And just before upgrade, I had no such messages from none of those SSL > checkers. > > and I haven't changed anything at all regarding my nginx configuration. > > My VPS is rented from Hetzner, and I had created a snapshot of it just > before the upgrade process. > So, now one-click revert to older snapshot, back to OpenBSD 7.3, both > tests' reports are fine now. > > No more "HTTP request to this server failed" from Qualys SSL Labs, > and no more "SERVER DOES NOT SUPPORT OCSP STAPLING" from Immuniweb SSL > test. > > Obviously, something is not good with 7.4? > > My SSL certificates are from Let's Encrypt, and I have "ssl_protocols > TLSv1.3 TLSv1.2;" in my nginx.conf, if that would help? > > Best Wishes, > > Mark. >
SSL issues after upgrading from 7.3 to 7.4
Hi. First of all, thank you very much for all your great efforts on 7.4! I upgraded my VPS from 7.3 to 7.4, and It's weird that, after upgrade, Qualys SSL Labs test for HTTPS/SSL websites gives: "HTTP request to this server failed, see below for details." However, my website works fine with browsers, and my nginx configuration has nothing weird at all, checked with "nginx -t", I had no such message as I checked just before I upgraded. And also, one more tool; immuniweb.com/ssl/ reports: "SERVER DOES NOT SUPPORT OCSP STAPLING" after the upgrade. However, again, OCSP stapling is implemented correctly in my nginx.conf file, working since a year. And just before upgrade, I had no such messages from none of those SSL checkers. and I haven't changed anything at all regarding my nginx configuration. My VPS is rented from Hetzner, and I had created a snapshot of it just before the upgrade process. So, now one-click revert to older snapshot, back to OpenBSD 7.3, both tests' reports are fine now. No more "HTTP request to this server failed" from Qualys SSL Labs, and no more "SERVER DOES NOT SUPPORT OCSP STAPLING" from Immuniweb SSL test. Obviously, something is not good with 7.4? My SSL certificates are from Let's Encrypt, and I have "ssl_protocols TLSv1.3 TLSv1.2;" in my nginx.conf, if that would help? Best Wishes, Mark.
Re: pfsync/rdomain broken on -current (works on 7.3)
On 9/18/23 8:59 PM, Stuart Henderson wrote:
On 2023-09-18, Mark Patruck wrote:
i've already wrote to dlg@, but also want to know if others see
the same behavior or at least inform about it.
pfsync(4) in combination with rdomain(4) doesn't work anymore on
a fresh -current. I see packets on pfsync0, but nothing leaves
the machine, so no states are synchronised.
pfsync had a big rewrite between 7.3 and -current. Setting rtableid
in the packet header was present in the 7.3 version but dropped in the
rewrite; can you try this?
Index: if_pfsync.c
===
RCS file: /cvs/src/sys/net/if_pfsync.c,v
retrieving revision 1.321
diff -u -p -r1.321 if_pfsync.c
--- if_pfsync.c 16 Sep 2023 09:33:27 - 1.321
+++ if_pfsync.c 18 Sep 2023 18:59:14 -
@@ -1537,6 +1537,7 @@ pfsync_sendout(struct pfsync_softc *sc,
imo.imo_ifidx = sc->sc_sync_ifidx;
imo.imo_ttl = PFSYNC_DFLTTL;
imo.imo_loop = 0;
+ m->m_pkthdr.ph_rtableid = sc->sc_if.if_rdomain;
if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, , NULL, 0) == 0) {
counters_pkt(sc->sc_if.if_counters, ifc_opackets,
The diff works fine on two of my systems. Traffic is flowing
between syncdevs again. Thanks Stuart.
--
Mark Patruck ( mark at wrapped.cx )
GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51
https://www.wrapped.cx
pfsync/rdomain broken on -current (works on 7.3)
Hi, i've already wrote to dlg@, but also want to know if others see the same behavior or at least inform about it. pfsync(4) in combination with rdomain(4) doesn't work anymore on a fresh -current. I see packets on pfsync0, but nothing leaves the machine, so no states are synchronised. For example (w/ or w/o vlan(4) doesn't make a difference) - pfsync0 in rdomain 5 (configured with syncdev vlan5 and syncpeer, so no multicast traffic) - vlan5 in rdomain 5 - lo5 in rdomain 5 - pf(4) is passing pfsync traffic With tcpdump i only see packets on pfsync0 Sep 18 11:41:52.207074 PFSYNCv69 len 212 but nothing on vlan5. Besides that, the kernel prints the following message every sec, so it seems pfsync(4) is not rdomain aware anymore. /bsd: vlan5: trying to send packet on wrong domain. if 5 vs. mbuf 0 I've tested with 7.3 and here it works. Sep 18 11:56:19.142731 52:59:06:94:af:12 52:01:45:47:1c:34 0800 142: 192.168.5.1: PFSYNCv6 len 108act UPD ST COMP count 1 ... (DF) [tos 0x10] -Mark -- Mark Patruck ( mark at wrapped.cx ) GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 https://www.wrapped.cx
10G ixl(4)/vio(4) Proxmox 8 - analysis
Hi misc@, i'm running a one day old -current on Proxmox 8. The underlying system is based on is a Supermicro/Epyc 7402P 24x 2,8GHz with 128GB memory and Intel X710 ixl(4) cards (latest FW 9.30). Tests on the HV itself look good with speeds near to 9.5Gbit/s and the same applies for direct connections between two Debian VMs i've used for testing routing performance of OpenBSD in the first place. All in all, my tests over the last days show more or less, that even with PCIe passthrough i hardly reach 4Gbit/s routing performance when testing with iperf3 and a real world transfer (http) between two VMs running -current comes close to 1,3Gbit/s. MTU always set to 1500. I've tried a lot of different variations, added more/less cores, more/less memory, different emulation types, enabled multiqueue support for vio(4), but nothing really changes numbers big-time. So for me it looks like that for running OpenBSD a 10G router you need a much faster CPU then my 2,8GHz, as singlecore performance still matters most. Perhaps also MTU=9000 could help, but i'm not sure about the drawbacks. Besides i'd like to have general input on this topic, can anyone shed light upon how ESXI with vmx(4) would behave here (in general, multi-queue support). Thanks, -Mark -- Mark Patruck ( mark at wrapped.cx ) GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 https://www.wrapped.cx
Re: Feedback on redesigned OpenBSD.org
On my desktop with dual 4K screens @3840x2160 (16:9) resolution the new design is basically illegible because the css wrongly determines this to be a high resolution small screen (aka phone) which is a step backwards, browser-zooming to 200% is not really an option because that also changes the layout. Also centering text blocks on the page really doesn't improve legibility on big screens.
Re: dhcpleased[59824]: sendto: Permission denied
What kind of anger and rudeness is that? We're all (at least those who ask questions) learning here. @misc is for that, right? And I think you should learn, too. You must. You said it's -no way- related to PF. Yet, it was PF in the end. Anyway, stop blindly insulting people here. Zack Newman , 8 Tem 2023 Cmt, 20:02 tarihinde şunu yazdı: > I am only replying to this in the interest of closure since I am > already part of this thread, but disclaimer here is some tough love. > > You need to stop being lazy and actually understand your network > topology, the security/privacy real or contrived-I see you adhere to > the whole security by obscurity nonsense with the masking of the last > 2 octets of that IPv4 address-and pf. Besides your first attempt at > "magically" fixing your problem which was doomed to fail for the > reasons I gave, you are now asking for people to guess what rules you > need. > > Do you "really need to block 'martians'"? Seriously? Ignoring the > philosophical trap of what you mean by "need", do you even know what a > "martian" is; and if not, then why are you blindly blocking them? If you > don't know what you are doing, then just don't do it. I don't even know > what a "martian" is other than an alien thing from outer space. In the > interest of providing a modicum of constructive criticism as opposed to > just criticism, here you go: > > https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml > . > > https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml > Not sure if that is what "martians" refer to, but your "martians" > appear to be a proper subset of what is listed there or at least close. > With that information, seek out what those blocks mean and decide based > on your topology and security/privacy needs if you should block > them. > > Should I block 192.168.3.2 on my laptop? What about > ingress traffic from 2343:24ad:afde:8224::23 destined to UDP port 764 > on my VPS? Those are obviously rhetorical questions as only I know (or > at least _should_ know) what my network topology is like, what > services I run, to whom I want to serve, etc. > > You clearly blindly copied and pasted some rules you found without > knowing what they do or why you are doing it as evidenced by the rather > embarrassing blocking of your DHCP server. If you are going to be lazy > and just want stuff to magically work, then disable pf. Bam. Don't need > to worry about anything. If you plan to block stuff though, then > actually learn about what you are blocking and why. > > Here is a tiny olive branch: I would allow all egress traffic from your > VPS since that is within _my_ wheel of trust. If my VPS is trying to > talk to an IP, then either it is already compromised or at least running > software it shouldn't at which point I have bigger problems; or it > needs to. Does that "magical" rule apply to you? I don't know, and it > sounds like you don't either. Even if it does, you will still need to > decide if you want to allow other IPs to send traffic; but that requires > you to learn more about your topology, pf, and security/privacy needs. > >
Re: dhcpleased[59824]: sendto: Permission denied
So it seems PF was indeed blocking my DHCP stuff. After disabling PF for a
long time, I grabbed this:
"Jul 7 19:13:54 mailsrv dhcpleased[15591]: adding 95.214.xxx.xxx to vio0
(lease from 172.31.1.1)"
from /var/log/daemon file. Noticed; "lease from 172.31.1.1" that's the DHCP
server of my server provider it seems.
(Still weird, as I receive an IP starting like; 95.214.xx from that,
anyways)
AND, I had in my pf.conf file;
martians = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8,
169.254.0.0/16, 192.0.2.0/24, 0.0.0.0/8, 240.0.0.0/4 }"
block drop in quick on $ext_if from $martians to any
block drop out quick on $ext_if from any to $martians
See "172.16.0.0/12" there among the IPs?
Removed that block from the martians and it seems my problem is solved.
Question: for a mail/web server VPS box with a single public IP with only
one NIC, do I really need to block "martians"?
Best wishes.
Mark.
Otto Moerbeek , 4 Tem 2023 Sal, 21:44 tarihinde şunu yazdı:
> On Mon, Jul 03, 2023 at 10:34:24AM -0600, Zack Newman wrote:
>
> > On 7/3/23 11:25, Mark wrote:
> > > I'm getting (I think once per day) "dhcpleased[59824]: sendto:
> Permission
> > > denied" error message in my daemon and messages log files.
> > >
> > > I think that's happening due to my PF configuration.
> >
> > Certainly could be. If this happens consistently around a particular
> > time, you can "live dangerously" and allow all traffic temporarily to
> > see if the issue is resolved. More safely, use tcpdump(8) to see if you
> > can find the problem.
> >
> > > I tried to add:
> > > pass log quick on $ext_if proto udp from any to any port = 67
> > > in my pf.conf file, didn't help.
> >
> > Completely useless. DHCP traffic never makes its way to pf(4) due to
> > being handled by bpf(4) first, so you don't need such a rule-in fact
> > you could explicitly block such traffic, and it won't matter. Proof:
>
> That may be true for reading dhcp packets, but in some cases
> dhcpleased sends UDP datagram lika any ordinary program, for other
> cases it uses BPF for sending. As the error reported is for sending,
> it *is* possible that pf plays a role.
>
> -Otto
>
> >
> > router# cat /etc/pf.conf
> > # Options.
> > set block-policy drop
> >
> > # Macros.
> > wan = em0
> >
> > # Filtering rules.
> > block in quick on $wan inet proto udp to port 68
> > block out quick on $wan inet proto udp to port 67
> > pass quick
> >
> > router# rcctl stop dhcpcd
> > dhcpcd(ok)
> > router# rm -rf /var/run/dhcpcd/
> > router# ifconfig em0 -inet
> > router# ifconfig em0 -inet6
> > router# ifconfig em0 down
> > router# pfctl -f /etc/pf.conf
> > router# tcpdump -ntt -i em0 -w pkts.dat 'udp and ip and (dst port 67 or
> dst port 68)' &
> > [1] 98425
> > router# tcpdump: listening on em0, link-type EN10MB
> > router# rcctl start dhcpcd
> > dhcpcd(ok)
> > router# pkill -x tcpdump
> >
> > 12551 packets received by filter
> > 0 packets dropped by kernel
> > router# tcpdump -nr pkts.dat
> > 10:02:29.663056 0.0.0.0.68 > 255.255.255.255.67: xid:0x3544268 [|bootp]
> > 10:02:32.802098 0.0.0.0.68 > 255.255.255.255.67: xid:0x3544268 secs:3
> [|bootp]
> > 10:02:32.857942 96.120.140.45.67 > 73.78.65.184.68: xid:0x3544268
> Y:73.78.65.184 G:96.120.140.45 [|bootp] [tos 0x10]
> >
> > The use of dhcpcd(8) is not relevant. I choose to use it for both DHCPv6
> > and DHCP so that I only have one daemon. I am _not_ recommending its
> > use over dhcpleased(8). The point is to show that such traffic is
> > allowed regardless of what rules you have in pf(4).
> >
> > If it is a pf(4) issue, then it not related to that traffic.
> >
>
>
Re: dhcpleased[59824]: sendto: Permission denied
Hi again, thanks for your detailed and very informative reply, Zack. Much appreciated! I wanted to re-try the fact (memories), on FreeBSD 13.2-RELEASE-p1; I removed the pass line from my pf.conf; "pass log quick on $ext_if proto udp from any to any port = 67" reloaded PF, then dmesg -a showed; Jul 4 04:59:09 myhost dhclient[18366]: send_packet: Permission denied Jul 4 04:59:33 myhost syslogd: last message repeated 3 times Jul 4 05:01:43 myhost syslogd: last message repeated 4 times Jul 4 05:11:29 myhost syslogd: last message repeated 18 times Jul 4 05:20:11 myhost syslogd: last message repeated 10 times I then, enabled the line again: "pass log quick on $ext_if proto udp from any to any port = 67" Restarted pf. the "dhclient: send_packet: Permission denied" messages were gone, disappeared from "dmesg -a" output, and it wasn't produced anymore. I tried this, again and again. Obviously PF blocks something. Just my two cents.. Subject:Re: dhcpleased[59824]: sendto: Permission denied From: Zack Newman Date: 2023-07-04 15:41:31 Message-ID: a1d467d7-6a63-00dd-72c3-e9bd8dd7e1a8 () philomathiclife ! com On 7/3/23 21:14, Mark wrote: > I really do remember, under FreeBSD, I was having a similar "dmesg -a" > output > > telling about DHCP's permission denied issue, and finally > > I solved it with a pass rule like: > > "pass log quick on $ext_if proto udp from any to any port = 67 keep state" > > in /usr/local/etc/pf.conf file. Well unfortunately memories are rather unreliable. Additionally, people often times come to incorrect conclusions. For starters even if that rule mattered, you should at least have "out" specified since that rule is only trying to handle traffic sent to the DHCP server. Two, there should be a corresponding rule for ingress traffic sent to the DHCP client. Three, "keep state" is irrelevant since the traffic is sent to 255.255.255.255:67, but the response is sent from a DHCP server or relay server that most certainly doesn't have the IP 255.255.255.255; thus the state entry is pointless. It's one thing to rely on the default behavior (i.e., "keep state"), but to explicitly add that is at the very least bizarre. > And reading DHCP traffic never makes its way to pf, > > surprised me. Perhaps that's valid only on OpenBSD but not on FreeBSD? > > Anyways.. It probably surprises many, but it has been that way for a while. Besides my "proof" that such rules are irrelevant, you can and even should read more. There was even a recent thread on @misc where someone inquired why there are DHCP-based rules in rc(8) when such rules don't matter, and Theo de Raadt explained the historical reason for it. I also doubt that it's "valid only on OpenBSD but not FreeBSD" despite what you (mis)remember, but I am not interested enough to spend time installing FreeBSD just to prove this. I spent a minute searching, and dhclient(8) ( https://man.freebsd.org/cgi/man.cgi?query=dhclient=8=html) explicitly talks about BPF, and this very old thread (https://lists.freebsd.org/pipermail/freebsd-ipfw/2005-April/001756.html) is about someone not able to block DHCP traffic with ipfw(8) where the reason given was "dhcpd uses BPF directly (like tcpdump)". I realize that thread is very old, concerns dhcpd instead of dhclient, and the individual uses ipfw instead of pf; but those two references in addition to your dubious rule are enough for me to maintain my skepticism.
unwind[92074]: bad packet: too large?
Hi there. I'm getting this one in daemon/messages log files: Jul 3 20:52:53 unwind[92074]: bad packet: too large: 65552 - 1.0.0.127.bl.blocklist.de. IN A Jul 3 20:52:53 last message repeated 4 times What does that mean? This is my mail server and Rspamd running behind, should I worry about unwind's message above? Best.
Re: dhcpleased[59824]: sendto: Permission denied
Hi Zack, Very interesting reply. I really do remember, under FreeBSD, I was having a similar "dmesg -a" output telling about DHCP's permission denied issue, and finally I solved it with a pass rule like: "pass log quick on $ext_if proto udp from any to any port = 67 keep state" in /usr/local/etc/pf.conf file. And reading DHCP traffic never makes its way to pf, surprised me. Perhaps that's valid only on OpenBSD but not on FreeBSD? Anyways.. Zack Newman wrote: Certainly could be. If this happens consistently around a particular time, you can "live dangerously" and allow all traffic temporarily to see if the issue is resolved. More safely, use tcpdump(8) to see if you can find the problem. > I tried to add: > pass log quick on $ext_if proto udp from any to any port = 67 > in my pf.conf file, didn't help. Completely useless. DHCP traffic never makes its way to pf(4) due to being handled by bpf(4) first, so you don't need such a rule-in fact you could explicitly block such traffic, and it won't matter. Proof:
Re: dhcpleased[59824]: sendto: Permission denied
Thanks, I'll look into it. Just extended the log rotation interval for messages, daemon and pflog files, to dig about it further. Best. Sven F. , 3 Tem 2023 Pzt, 15:03 tarihinde şunu yazdı: > On Mon, Jul 3, 2023 at 7:42 AM Mark wrote: > > > > I'm getting (I think once per day) "dhcpleased[59824]: sendto: Permission > > denied" error message in my daemon and messages log files. > > > > I think that's happening due to my PF configuration. > > > > This is a VPS, getting it's IP from my server provider, through autoconf > > setting. So I assume it's a DHCP access issue? > > > > I tried to add: > > pass log quick on $ext_if proto udp from any to any port = 67 > > in my pf.conf file, didn't help. > > > > Any clue on this please? > > Best. > > OS: OpenBSD 7.3 > > Hello, > > I would log the block rules and check the pledge related log if any ( > in dmesg ? ). > Maybe the configuration received tries to do something unexpected. > > checking pflogd or tcpdump ing pflog will be helpful. > Before adding a dubious pass log. > > Best. > > -- > -- > > - > Knowing is not enough; we must apply. Willing is not enough; we must do >
dhcpleased[59824]: sendto: Permission denied
I'm getting (I think once per day) "dhcpleased[59824]: sendto: Permission denied" error message in my daemon and messages log files. I think that's happening due to my PF configuration. This is a VPS, getting it's IP from my server provider, through autoconf setting. So I assume it's a DHCP access issue? I tried to add: pass log quick on $ext_if proto udp from any to any port = 67 in my pf.conf file, didn't help. Any clue on this please? Best. OS: OpenBSD 7.3
unwind validation failure?
Hi. On OpenBSD 7.3, I frequently receive the following lines in 'daemon' and 'messages' log files inside /var/log/ directory; unwind[47246]: validation failure <181.219.85.209.in-addr.arpa. PTR IN>: No DNSKEY record for key in-addr.arpa. while building chain of trust unwind[72140]: validation failure <99.74.250.142.in-addr.arpa. PTR IN>: No DNSKEY record for key in-addr.arpa. while building chain of trust What are those messages and is there anything that I should do for this? Thank you very much.
Re: High Interrupt After 7.3 Upgrade
Hi Chris, On Tue, May 30, 2023 at 8:59 AM Chris Cappuccio wrote: > Samuel Jayden [samueljaydan1...@gmail.com] wrote: > > Hi again, > > > > Just for the record: > > I've downgraded to OpenBSD 7.2 (reinstalled) and everything is working > like > > a charm again. > > I don't know what is wrong with 7.3 but ipi interrupt rate is too much > and > > somehow OpenBSD performance is too bad.. > > Thanks for reading. > > > > Sounds like you are using 'systat' to measure interrupts. This is a bug > in systat was was fixed in 7.3. Here is Scott Cheloha's message from that > fix: > > "systat(1): vmstat: measure elapsed time with clock_gettime(2) instead of > ticks > > The vmstat view in systat(1) should not use statclock() ticks to count > elapsed time. First, ticks are low resolution. Second, the statclock > is sometimes randomized, so each tick is not necessarily of equal > length. Third, we're counting ticks from every CPU on the system, so > every rate in the view is divided by the number of CPUs. For example, > on an amd64 system with 8 CPUs you currently see: > > 200 clock > > ... when the true clock interrupt rate on that system is 1600. > > Instead, measure elapsed time with clock_gettime(2). Use CLOCK_UPTIME > here so we exclude time when the system is suspended. With this > change we no longer need "stathz" or "hertz". We can also get rid of > the anachronistic secondary clock failure test. > > > I'm not the OP, but that's interesting to me because I'm wondering if it's why Prometheus' node_exporter from packages is reporting wildly wrong CPU stats on 7.3 that don't at all match what you'd expect when comparing top/htop output? It was fine prior to upgrading to 7.3, but I've just left digging into it on the back burner due to other priorities. Thanks! Mark
High sys/spin CPU and hangs on ThinkPad T14 (amdgpu)
I've been running snapshots on my Ryzen ThinkPad T14 for about 1.5 years and everything has been working great except for some occasional hangs which seem to be getting more frequent. I've heard about some amdgpu issues upstream and am not sure if this is related to that or something different. - The same graphical programs are always running: i3, Firefox (usually with at least 1 YouTube video tab playing, possibly more open in the background but not actively playing), and Remmina with one RDP session. - When the issue starts the mouse can still be moved around but it gets more sluggish as time goes on. Within 1-2 minutes the mouse usually stops responding and there is no keyboard response. The longer it sits in this state the less chance it can be recovered without a power cycle. - In the past there was no high CPU usage but there were messages like this in dmesg: [drm] *ERROR* ring sdma0 timeout, signaled seq=68607, emitted seq=68607 - On recent snaps (noticed after upgrading from Mar 25 to May 3) the effect seems to be almost 100% CPU usage (~40% sys/~60% spin) making the whole system sluggish. I haven't seen the drm error recently. - If caught fast enough sometimes I can SSH in from another machine and `pkill firefox` which will take some minutes to complete and eventually things return to normal. Other times pkilling firefox ends up with several zombie processes and does not recover without a power cycle. - Sitting in the bad state long enough (a few minutes) will cause the system to hang, stop responding to ping, stop responding to SSH. - Opening a new Firefox window, trying to play another YouTube video, or loading a heavy javascript site can trigger the issue sometimes but not always. Sometimes things are fine for a few days, other times I'll have to power cycle multiple times per day. - Nothing interesting in /var/log/messages or /var/log/Xorg* at the issue times Below is some info gathered via SSH during the issue. Is there anything else that would be helpful to collect to narrow this down? Thanks in advance for any pointers, -Mark dmesg: OpenBSD 7.3-current (GENERIC.MP) #1184: Tue May 16 15:53:34 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 7711297536 (7354MB) avail mem = 7457939456 (7112MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xbf71 (67 entries) bios0: vendor LENOVO version "R1BET73W(1.42 )" date 12/09/2022 bios0: LENOVO 20UD000HUS efi0 at bios0: UEFI 2.7 efi0: Lenovo rev 0x1360 acpi0 at bios0: ACPI 6.3 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT IVRS SSDT SSDT TPM2 SSDT MSDM BATB HPET APIC MCFG SBST WSMT VFCT SSDT CRAT CDIT FPDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT UEFI SSDT SSDT BGRT acpi0: wakeup devices GPP0(S0) RESA(S3) GPP5(S0) GPP6(S0) GP17(S0) LID_(S4) SLPB(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 5 PRO 4650U with Radeon Graphics, 2100.00 MHz, 17-60-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Ryzen 5 PRO 4650U with Radeon Graphics, 2100.00 MHz, 17-60-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Ryzen 5 PRO 4650U with Radeon Graphics, 2100.00 MHz, 17-60-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES
Re: Guide for Configuring python(1) with httpd(8)
> -Original Message-
> From: owner-m...@openbsd.org On Behalf Of indivC
> Sent: 18 December 2022 07:07
> To: misc@openbsd.org
> Subject: Guide for Configuring python(1) with httpd(8)
>
> Can anyone provide a guide for this or rough instructions?
> I'm running httpd(8) and trying to utilize a python(1) script
> with an html file.
[snipped]
> This is why I was hoping someone could provide a link to a guide
> or provide some general steps for configuring this.
> Currently, I've just been trying to piece together
> what I've been able to find online.
>
> Thanks.
Hi indivC,
This is the script I use to set up python for httpd:
#!/bin/sh
#
# Enable Python3 to operate in a chrooted environment (for httpd)
#
export CHROOT=/var/www
rm -rf ${CHROOT}/usr ${CHROOT}/var ${CHROOT}/etc ${CHROOT}/sbin \
${CHROOT}/run ${CHROOT}/logs
mkdir -p ${CHROOT}/usr/local/bin ${CHROOT}/usr/lib ${CHROOT}/usr/libexec \
${CHROOT}/sbin ${CHROOT}/var/run ${CHROOT}/etc \
${CHROOT}/usr/local/lib ${CHROOT}/run ${CHROOT}/logs
chown www ${CHROOT}/usr/local/bin ${CHROOT}/usr/lib ${CHROOT}/usr/libexec \
${CHROOT}/sbin ${CHROOT}/var/run ${CHROOT}/etc \
${CHROOT}/usr/local/lib ${CHROOT}/run ${CHROOT}/logs
cp -p /sbin/ldconfig ${CHROOT}/sbin
cp -p /usr/local/bin/python3.9 ${CHROOT}/usr/local/bin/python
cp -pr /usr/local/lib/python3.9 ${CHROOT}/usr/local/lib
cp -p /usr/local/lib/libpython3.9.so.* ${CHROOT}/usr/local/lib
cp -p /usr/local/lib/libintl.so.7.0 ${CHROOT}/usr/local/lib
cp -p /usr/local/lib/libiconv.so.7.0 ${CHROOT}/usr/local/lib
cp -p /usr/lib/libpthread.so.* ${CHROOT}/usr/lib
cp -p /usr/lib/libutil.so.* ${CHROOT}/usr/lib
cp -p /usr/lib/libm.so.* ${CHROOT}/usr/lib
cp -p /usr/lib/libc.so.* ${CHROOT}/usr/lib
cp -p /usr/libexec/ld.so ${CHROOT}/usr/libexec
cp -p /usr/lib/libz.so.* ${CHROOT}/usr/lib
cp -p /usr/lib/libpthread.so.* ${CHROOT}/usr/lib
cp -p /usr/lib/libutil.so.* ${CHROOT}/usr/lib
cp -p /usr/lib/libm.so.* ${CHROOT}/usr/lib
cp -p /usr/lib/libssl.so* ${CHROOT}/usr/lib
cp -p /usr/lib/libcrypto.so* ${CHROOT}/usr/lib
cp -p /etc/pwd.db ${CHROOT}/etc
# build ld.hints.so file so python can find its libraries
chroot ${CHROOT} /sbin/ldconfig /usr/local/lib
Hope it helps.
-mark
--
Mark Willson
Re: Zabbix 6.0.3 with Postgresql 14.2 on OpenBSD 7.1 stops graphing after two hours
On 19.04.2022 10:30, Mark Patruck wrote: On 16.04.2022 20:44, Noth wrote: Hi, Hi, I built the new 7.1 packages for Zabbix and PostgreSQL, and upgraded my monitoring VM. To my horror the zabbix_server process stops graphing after a couple of hours of uptime, with the housekeeper and history syncer processes at over 80% cpu usage. PostgreSQL shows INSERT processes stuck at 80% too, and restarting zabbix_server hangs, leaving zombie processes. I was using 2 vcpus and 2G of RAM. Feeling that the login.conf limits might be the problem I uped them by quite a bit: The zabbix_server process won't eat up your system normally...it's more database related. 1) how big is your database? (important, as you don't have much memory for a busy PostgreSQL database) 2) did you make changes to /var/postgresql/data/postgresql.conf? (work_mem, shared_buffers, effective_cache_size, random_page_cost) 2) how many items do you monitor? 3) did you always follow the Zabbix upgrade guide (especially 5->6)? 4) how do your Zabbix server graphs "data gathering", "internal", "data handling" look like before the problem starts? Any high spikes? 5) have you already tried with a new database instance, i.e. move /var/postgresql/data to /var/postgresql/data_old and start with Zabbix 6.0.3 from scratch to see, if the database issues start immediately even when almost empty? postgresql:\ -:openfiles=1024:\ +:openfiles=4096:\ :tc=daemon: :datasize-max=2048M:\ :datasize-cur=2048M:\ In almost all environments i've dealt with so far, you didn't need a postgresql login class at all. Forget about that...i had the zabbix_server login class in mind. -Mark I also uped sysctls: -kern.seminfo.semmns=2048 -kern.shminfo.shmall=1024512 +kern.seminfo.semmns=4096 +kern.shminfo.shmall=1572864 This helped quite a bit, the graphing at least doesn't stop. Yet the housekeeper & history sync processes are still stuck continuously at over 80%. I even doubled the RAM to 4G and the vcpus to 4. Yet this is what top shows: CPU0 states: 82.4% user, 0.0% nice, 14.7% sys, 1.0% spin, 0.0% intr, 2.0% idle CPU1 states: 79.4% user, 0.0% nice, 9.8% sys, 0.0% spin, 0.0% intr, 10.8% idle CPU2 states: 80.4% user, 0.0% nice, 9.8% sys, 0.0% spin, 0.0% intr, 9.8% idle CPU3 states: 94.1% user, 0.0% nice, 4.9% sys, 0.0% spin, 0.0% intr, 1.0% idle Memory: Real: 738M/2131M act/tot Free: 1796M Cache: 1091M Swap: 0K/2055M PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND 48835 _postgre 640 307M 247M onproc/0 -23.4H 98.24% postgres: zabbix zabbix [local] SELECT 42079 _postgre 640 307M 245M run/2 -25.3H 98.10% postgres: zabbix zabbix [local] SELECT 3630 _postgre 630 308M 282M onproc/1 -21.2H 82.42% postgres: zabbix zabbix [local] DELETE 12622 _postgre 600 307M 127M onproc/2 -20.8H 79.10% postgres: zabbix zabbix [local] INSERT None of this behaviour happened with versions 2.x through to 5.x. Yes I've followed the pkg-readme for both PostgreSQL and Zabbix. Maybe these need adjusting? I'm at a loss on what I need to tune to make everything go back to being running with low CPU usage. I am fully aware 6.x now collects data points of a gazillion more things (so many entries with just $1 as the name now, I'm not sure what's going on there). Hopefully some of you have an idea, cheers, Noth OpenBSD 7.1 (GENERIC.MP) #1: Wed Apr 6 18:48:24 CEST 2022 r...@builder2.nineinchnetworks.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4255670272 (4058MB) avail mem = 4109398016 (3919MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xbfbcb000 (13 entries) bios0: vendor BHYVE version "13.0" date 11/10/2020 bios0: FreeBSD BHYVE acpi0 at bios0: ACPI 4.0 acpi0: sleep states S5 acpi0: tables DSDT FACP HPET APIC MCFG SPCR acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 16777216 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) E-2278G CPU @ 3.40GHz, 3408.57 MHz, 06-9e-0d cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,SDBG,FMA3,CX16,xTPR,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,BMI1,HLE,AVX2,BMI2,ERMS,INVPCID,RTM,RDSEED,MD_CLEAR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: CPU supports MTRRs but not enabled by BIOS cpu0: apic clock running at 134MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Xeon(R) E-2278G CPU @ 3.40GHz, 3413.28 MHz, 06-9e-0d cpu1: FPU,VME,D
Re: Zabbix 6.0.3 with Postgresql 14.2 on OpenBSD 7.1 stops graphing after two hours
On 16.04.2022 20:44, Noth wrote: Hi, Hi, I built the new 7.1 packages for Zabbix and PostgreSQL, and upgraded my monitoring VM. To my horror the zabbix_server process stops graphing after a couple of hours of uptime, with the housekeeper and history syncer processes at over 80% cpu usage. PostgreSQL shows INSERT processes stuck at 80% too, and restarting zabbix_server hangs, leaving zombie processes. I was using 2 vcpus and 2G of RAM. Feeling that the login.conf limits might be the problem I uped them by quite a bit: The zabbix_server process won't eat up your system normally...it's more database related. 1) how big is your database? (important, as you don't have much memory for a busy PostgreSQL database) 2) did you make changes to /var/postgresql/data/postgresql.conf? (work_mem, shared_buffers, effective_cache_size, random_page_cost) 2) how many items do you monitor? 3) did you always follow the Zabbix upgrade guide (especially 5->6)? 4) how do your Zabbix server graphs "data gathering", "internal", "data handling" look like before the problem starts? Any high spikes? 5) have you already tried with a new database instance, i.e. move /var/postgresql/data to /var/postgresql/data_old and start with Zabbix 6.0.3 from scratch to see, if the database issues start immediately even when almost empty? postgresql:\ -:openfiles=1024:\ +:openfiles=4096:\ :tc=daemon: :datasize-max=2048M:\ :datasize-cur=2048M:\ In almost all environments i've dealt with so far, you didn't need a postgresql login class at all. -Mark I also uped sysctls: -kern.seminfo.semmns=2048 -kern.shminfo.shmall=1024512 +kern.seminfo.semmns=4096 +kern.shminfo.shmall=1572864 This helped quite a bit, the graphing at least doesn't stop. Yet the housekeeper & history sync processes are still stuck continuously at over 80%. I even doubled the RAM to 4G and the vcpus to 4. Yet this is what top shows: CPU0 states: 82.4% user, 0.0% nice, 14.7% sys, 1.0% spin, 0.0% intr, 2.0% idle CPU1 states: 79.4% user, 0.0% nice, 9.8% sys, 0.0% spin, 0.0% intr, 10.8% idle CPU2 states: 80.4% user, 0.0% nice, 9.8% sys, 0.0% spin, 0.0% intr, 9.8% idle CPU3 states: 94.1% user, 0.0% nice, 4.9% sys, 0.0% spin, 0.0% intr, 1.0% idle Memory: Real: 738M/2131M act/tot Free: 1796M Cache: 1091M Swap: 0K/2055M PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND 48835 _postgre 640 307M 247M onproc/0 -23.4H 98.24% postgres: zabbix zabbix [local] SELECT 42079 _postgre 640 307M 245M run/2 -25.3H 98.10% postgres: zabbix zabbix [local] SELECT 3630 _postgre 630 308M 282M onproc/1 -21.2H 82.42% postgres: zabbix zabbix [local] DELETE 12622 _postgre 600 307M 127M onproc/2 -20.8H 79.10% postgres: zabbix zabbix [local] INSERT None of this behaviour happened with versions 2.x through to 5.x. Yes I've followed the pkg-readme for both PostgreSQL and Zabbix. Maybe these need adjusting? I'm at a loss on what I need to tune to make everything go back to being running with low CPU usage. I am fully aware 6.x now collects data points of a gazillion more things (so many entries with just $1 as the name now, I'm not sure what's going on there). Hopefully some of you have an idea, cheers, Noth OpenBSD 7.1 (GENERIC.MP) #1: Wed Apr 6 18:48:24 CEST 2022 r...@builder2.nineinchnetworks.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4255670272 (4058MB) avail mem = 4109398016 (3919MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xbfbcb000 (13 entries) bios0: vendor BHYVE version "13.0" date 11/10/2020 bios0: FreeBSD BHYVE acpi0 at bios0: ACPI 4.0 acpi0: sleep states S5 acpi0: tables DSDT FACP HPET APIC MCFG SPCR acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 16777216 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) E-2278G CPU @ 3.40GHz, 3408.57 MHz, 06-9e-0d cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,SDBG,FMA3,CX16,xTPR,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,BMI1,HLE,AVX2,BMI2,ERMS,INVPCID,RTM,RDSEED,MD_CLEAR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: CPU supports MTRRs but not enabled by BIOS cpu0: apic clock running at 134MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Xeon(R) E-2278G CPU @ 3.40GHz, 3413.28 MHz, 06-9e-0d cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLM
Re: rtable - cannot start svc anymore - current
On 19.03.2022 10:29, Stuart Henderson wrote: On 2022-03-18, Stuart Henderson wrote: The thing most likely to have affected this is https://marc.info/?t=16435008481=1=2 but it's not expected that you should have to change anything, and I don't see that problem here - I just did this to try and replicate : tb@ pointed out that su was changed as well, and I've confirmed that it's the latter change causing the problem. I've backed out the su change for now. Thanks. Works again. -- Mark Patruck ( mark at wrapped.cx ) GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 https://www.wrapped.cx
rtable - cannot start svc anymore - current
Hi, after updating a first bunch of backup systems to -current today, i have issues starting services on machines w/ different rdomains. $ cat /etc/rc.conf.local ifstated_flags= ntpd_flags=NO ntpd106_rtable=106 smtpd_flags=NO smtpd202_rtable=202 syslogd_flags=NO syslogd104_rtable=104 zabbix_agentd104_rtable=104 pkg_scripts=ntpd106 smtpd202 syslogd104 zabbix_agentd104 None of the services come up when started either via $ doas rcctl start smtpd202 or $ /etc/rc.d/smtpd202 start The only thing that works, is $ doas route -T202 exec /usr/sbin/smtpd Did i miss changes to -current (login class stuff perhaps)? Thanks, -Mark -- Mark Patruck ( mark at wrapped.cx ) GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 https://www.wrapped.cx
Re: ttyflags hangs on Dell PowerEdge R200
> Date: Mon, 31 Jan 2022 15:41:32 +0100 > From: Jan Stary > > On Jan 31 14:47:41, mark.kette...@xs4all.nl wrote: > > > Date: Mon, 31 Jan 2022 14:03:29 +0100 > > > From: Jan Stary > > > > > > On Jan 26 18:02:17, mark.kette...@xs4all.nl wrote: > > > > > > > > revision 1.406 > > > > date: 2022/01/26 14:39:07; author: kettenis; state: Exp; lines: +2 > > > > -2; commitid: zL3Ot2UVnkpDz6go; > > > > An ACPI device needs to be both present and enabled for it to function. > > > > So only attempt to attach hardware that has both bits enabled. This > > > > fixes > > > > an issue where com(4) would attach for a disabled serial port leading to > > > > misdetection of the hardware variant and a subsequent hang when /etc/rc > > > > runs ttyflags -a. > > > > > > > > > While this fixes the original problem on Dell PowerEdge > > > it also seems to make /dev/console disappear on Beagle Bone Black > > > (current/armv7) - last good dmesg and current dmesg below, > > > the highlight of the diff being > > > > > > -com0 at omsysc7: ti16750, 64 byte fifo > > > -com0: console > > > +"serial" at omsysc7 not configured > > > +init: can't open /dev/console: Device not configured > > > > > > Jan > > > > Sorry, but no, the code I changed isn't even compiled on armv7. > > Ah, sorry for the confusion. > > > Not sure what's happening here. Are both kernels running with the > > same U-Boot version? > > Yes, U-Boot SPL 2021.10 (Nov 01 2021 - 20:37:54 -0600) Good. Did you try building a current kernel yourself? Sometimes there are patches that need testing in the snapshots. In fact, the Jan 24 may have had a version of Theo's fix for your ttyflags problem in it ;). > > > OpenBSD 7.0-current (GENERIC) #0: Tue Jan 4 22:31:14 CET 2022 > > > h...@bbb.stare.cz:/usr/src/sys/arch/armv7/compile/GENERIC > > > real mem = 484184064 (461MB) > > > avail mem = 463884288 (442MB) > > > random: good seed from bootblocks > > > mainbus0 at root: TI AM335x BeagleBone Black > > > cpu0 at mainbus0 mpidr 0: ARM Cortex-A8 r3p2 > > > cpu0: 32KB 64b/line 4-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache > > > cpu0: 256KB 64b/line 8-way L2 cache > > > omap0 at mainbus0 > > > prcm0 at omap0 rev 0.2 > > > dmtimer0 at omap0 rev 3.1 > > > dmtimer1 at omap0 rev 3.1 > > > omsysc0 at mainbus0: "target-module" > > > omsysc1 at omsysc0: "target-module" > > > "pmu" at omsysc1 not configured > > > simplebus0 at mainbus0: "ocp" > > > intc0 at simplebus0 rev 5.0 > > > omsysc2 at simplebus0: "target-module" > > > simplebus1 at simplebus0: "interconnect" > > > simplebus2 at simplebus1: "segment" > > > simplebus3 at simplebus1: "segment" > > > omsysc3 at simplebus3: "target-module" > > > "cpu" at omsysc3 not configured > > > simplebus4 at simplebus1: "segment" > > > omsysc4 at simplebus4: "target-module" > > > simplebus5 at omsysc4: "prcm" > > > omcm0 at simplebus5: "per-cm" > > > omclock0 at omcm0: "l4ls-clkctrl" > > > omclock1 at omcm0: "l3s-clkctrl" > > > omclock2 at omcm0: "l3-clkctrl" > > > omclock3 at omcm0: "l4hs-clkctrl" > > > omclock4 at omcm0: "pruss-ocp-clkctrl" > > > omclock5 at omcm0: "cpsw-125mhz-clkctrl" > > > omclock6 at omcm0: "lcdc-clkctrl" > > > omclock7 at omcm0: "clk-24mhz-clkctrl" > > > omcm1 at simplebus5: "wkup-cm" > > > omclock8 at omcm1: "l4-wkup-clkctrl" > > > omclock9 at omcm1: "l3-aon-clkctrl" > > > omclock10 at omcm1: "l4-wkup-aon-clkctrl" > > > omcm2 at simplebus5: "mpu-cm" > > > omclock11 at omcm2: "mpu-clkctrl" > > > omcm3 at simplebus5: "l4-rtc-cm" > > > omclock12 at omcm3: "l4-rtc-clkctrl" > > > omcm4 at simplebus5: "gfx-l3-cm" > > > omclock13 at omcm4: "gfx-l3-clkctrl" > > > omcm5 at simplebus5: "l4-cefuse-cm" > > > omclock14 at omcm5: "l4-cefuse-clkctrl" > > > "prm" at simplebus5 not configured > > > "prm" at simplebus5 not configured > > > "prm" at simplebus5 not configured > > > "prm" at simplebus5 not configured > > > "prm" at simplebus5 not configured > > > "prm" at simplebus5 not configured > > > "prm" at simplebus5 not configured > > > omsysc5 at simplebus4: "target-module" > > > simplebus6 at omsysc5: "scm" > > > syscon0 at simplebus6: "scm_conf" > > > pinctrl0 at simplebus6 > > > "control" at simplebus6 not configured > > > "wkup_m3_ipc" at simplebus6 not configured > > > "dma-router" at simplebus6 not configured > > > omsysc6 at simplebus4: "target-module" > > > omgpio0 at omsysc6: rev 0.1 > > > gpio0 at omgpio0: 32 pins > > > omsysc7 at simplebus4: "target-module" > > > com0 at omsysc7: ti16750, 64 byte fifo > > > com0: console > > > omsysc8 at simplebus4: "target-module" > > > tiiic0 at omsysc8 rev 0.11 > > > iic0 at tiiic0 > > > "ti,tps65217" at iic0 addr 0x24 not configured > > > "atmel,24c256" at iic0 addr 0x50 not configured > > > nxphdmi0 at iic0 addr 0x70: rev 0x0301 > > > nxphdmi0: no display detected > > > omsysc9 at simplebus4: "target-module" > > > omsysc10 at simplebus4: "target-module" > > > "timer" at omsysc10 not configured > > > omsysc11 at
Re: ttyflags hangs on Dell PowerEdge R200
> Date: Mon, 31 Jan 2022 14:03:29 +0100 > From: Jan Stary > > On Jan 26 18:02:17, mark.kette...@xs4all.nl wrote: > > > > revision 1.406 > > date: 2022/01/26 14:39:07; author: kettenis; state: Exp; lines: +2 -2; > > commitid: zL3Ot2UVnkpDz6go; > > An ACPI device needs to be both present and enabled for it to function. > > So only attempt to attach hardware that has both bits enabled. This fixes > > an issue where com(4) would attach for a disabled serial port leading to > > misdetection of the hardware variant and a subsequent hang when /etc/rc > > runs ttyflags -a. > > > While this fixes the original problem on Dell PowerEdge > it also seems to make /dev/console disappear on Beagle Bone Black > (current/armv7) - last good dmesg and current dmesg below, > the highlight of the diff being > > -com0 at omsysc7: ti16750, 64 byte fifo > -com0: console > +"serial" at omsysc7 not configured > +init: can't open /dev/console: Device not configured > > Jan Sorry, but no, the code I changed isn't even compiled on armv7. Not sure what's happening here. Are both kernels running with the same U-Boot version? > OpenBSD 7.0-current (GENERIC) #0: Tue Jan 4 22:31:14 CET 2022 > h...@bbb.stare.cz:/usr/src/sys/arch/armv7/compile/GENERIC > real mem = 484184064 (461MB) > avail mem = 463884288 (442MB) > random: good seed from bootblocks > mainbus0 at root: TI AM335x BeagleBone Black > cpu0 at mainbus0 mpidr 0: ARM Cortex-A8 r3p2 > cpu0: 32KB 64b/line 4-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache > cpu0: 256KB 64b/line 8-way L2 cache > omap0 at mainbus0 > prcm0 at omap0 rev 0.2 > dmtimer0 at omap0 rev 3.1 > dmtimer1 at omap0 rev 3.1 > omsysc0 at mainbus0: "target-module" > omsysc1 at omsysc0: "target-module" > "pmu" at omsysc1 not configured > simplebus0 at mainbus0: "ocp" > intc0 at simplebus0 rev 5.0 > omsysc2 at simplebus0: "target-module" > simplebus1 at simplebus0: "interconnect" > simplebus2 at simplebus1: "segment" > simplebus3 at simplebus1: "segment" > omsysc3 at simplebus3: "target-module" > "cpu" at omsysc3 not configured > simplebus4 at simplebus1: "segment" > omsysc4 at simplebus4: "target-module" > simplebus5 at omsysc4: "prcm" > omcm0 at simplebus5: "per-cm" > omclock0 at omcm0: "l4ls-clkctrl" > omclock1 at omcm0: "l3s-clkctrl" > omclock2 at omcm0: "l3-clkctrl" > omclock3 at omcm0: "l4hs-clkctrl" > omclock4 at omcm0: "pruss-ocp-clkctrl" > omclock5 at omcm0: "cpsw-125mhz-clkctrl" > omclock6 at omcm0: "lcdc-clkctrl" > omclock7 at omcm0: "clk-24mhz-clkctrl" > omcm1 at simplebus5: "wkup-cm" > omclock8 at omcm1: "l4-wkup-clkctrl" > omclock9 at omcm1: "l3-aon-clkctrl" > omclock10 at omcm1: "l4-wkup-aon-clkctrl" > omcm2 at simplebus5: "mpu-cm" > omclock11 at omcm2: "mpu-clkctrl" > omcm3 at simplebus5: "l4-rtc-cm" > omclock12 at omcm3: "l4-rtc-clkctrl" > omcm4 at simplebus5: "gfx-l3-cm" > omclock13 at omcm4: "gfx-l3-clkctrl" > omcm5 at simplebus5: "l4-cefuse-cm" > omclock14 at omcm5: "l4-cefuse-clkctrl" > "prm" at simplebus5 not configured > "prm" at simplebus5 not configured > "prm" at simplebus5 not configured > "prm" at simplebus5 not configured > "prm" at simplebus5 not configured > "prm" at simplebus5 not configured > "prm" at simplebus5 not configured > omsysc5 at simplebus4: "target-module" > simplebus6 at omsysc5: "scm" > syscon0 at simplebus6: "scm_conf" > pinctrl0 at simplebus6 > "control" at simplebus6 not configured > "wkup_m3_ipc" at simplebus6 not configured > "dma-router" at simplebus6 not configured > omsysc6 at simplebus4: "target-module" > omgpio0 at omsysc6: rev 0.1 > gpio0 at omgpio0: 32 pins > omsysc7 at simplebus4: "target-module" > com0 at omsysc7: ti16750, 64 byte fifo > com0: console > omsysc8 at simplebus4: "target-module" > tiiic0 at omsysc8 rev 0.11 > iic0 at tiiic0 > "ti,tps65217" at iic0 addr 0x24 not configured > "atmel,24c256" at iic0 addr 0x50 not configured > nxphdmi0 at iic0 addr 0x70: rev 0x0301 > nxphdmi0: no display detected > omsysc9 at simplebus4: "target-module" > omsysc10 at simplebus4: "target-module" > "timer" at omsysc10 not configured > omsysc11 at simplebus4: "target-module" > omdog0 at omsysc11 rev 0.1 > omsysc12 at simplebus4: "target-module" > "rtc" at omsysc12 not configured > simplebus7 at simplebus0: "interconnect" > simplebus8 at simplebus7: "segment" > omsysc13 at simplebus8: "target-module" > omsysc14 at simplebus8: "target-module" > omsysc15 at simplebus8: "target-module" > omsysc16 at simplebus8: "target-module" > omsysc17 at simplebus8: "target-module" > "mcasp" at omsysc17 not configured > omsysc18 at simplebus8: "target-module" > omsysc19 at simplebus8: "target-module" > "timer" at omsysc19 not configured > omsysc20 at simplebus8: "target-module" > "timer" at omsysc20 not configured > omsysc21 at simplebus8: "target-module" > "timer" at omsysc21 not configured > omsysc22 at simplebus8: "target-module" > "timer" at omsysc22 not configured > omsysc23 at simplebus8: "target-module" >
Re: Raspberry Pi 4B performance compared to APU / wireless networking?
> The APU itself doesn't have wlan so that depends on what card you use > of course. bwfm(4) does work well though the antenna is a resonant cavity > etched on the PCB and there's no way to move it outside of the case. > If you want to run a high performance AP you'll still want a separate > device. The CM4 has a connector for an external antenna (but only one). Not sure how well bwfm(4) works as an AP though. Note that CM4 PCIe support only works in -current.
Re: T14 AMD Gen 1 Ethernet woes
ux 0 pms0: Synaptics clickpad, firmware 10.32, 0x1e2a1 0x940300 0x378f40 0xf014a3 0x12e800 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 wbsio0 at isa0 port 0x4e/2: W83627HF rev 0x61 vmm0 at mainbus0: SVM/RVI efifb at mainbus0 not configured uvideo0 at uhub0 port 4 configuration 1 interface 0 "Azurewave Integrated Camera" rev 2.01/19.09 addr 2 video0 at uvideo0 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets sd1 at scsibus3 targ 1 lun 0: sd1: 953868MB, 512 bytes/sector, 1953523553 sectors root on sd1a (404807442e16f6a6.a) swap on sd1b dump on sd1b iwx0: could not read firmware iwx-cc-a0-48 (error 2) iwx0: failed to load init firmware drm:pid0:amdgpu_device_parse_gpu_info_fw *ERROR* Failed to load gpu_info firmware "amdgpu/renoir_gpu_info.bin" drm:pid0:amdgpu_attachhook *ERROR* Fatal error during GPU init efifb0 at mainbus0: 1920x1080, 32bpp wsdisplay0 at efifb0 mux 1: console (std, vt100 emulation), using wskbd0 wsdisplay0: screen 1-5 added (std, vt100 emulation) umass0 at uhub1 port 6 configuration 1 interface 0 "USB SanDisk 3.2Gen1" rev 3.20/1.00 addr 2 umass0: using SCSI over Bulk-Only scsibus4 at umass0: 2 targets, initiator 0 sd2 at scsibus4 targ 1 lun 0: removable serial.078155918107542a8311 sd2: 29340MB, 512 bytes/sector, 60088320 sectors sd2 detached scsibus4 detached umass0 detached umass0 at uhub1 port 6 configuration 1 interface 0 "SanDisk Ultra USB 3.0" rev 3.00/1.00 addr 2 umass0: using SCSI over Bulk-Only scsibus4 at umass0: 2 targets, initiator 0 sd2 at scsibus4 targ 1 lun 0: removable serial.07815591161119102385 sd2: 14664MB, 512 bytes/sector, 30031872 sectors -- Mark Patruck ( mark at wrapped.cx ) GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 https://www.wrapped.cx
Re: Suspend/resume does not work on Lenovo X1 Carbon 3rd gen laptop
On 4/5/2021 5:51 PM, Mike Larkin wrote: On Sun, Apr 04, 2021 at 09:15:14AM +0100, Mark Hesselink wrote: Hi Theo, Thanks for reaching out and explaining the issue in more detail. It prompted me to check the disklabel for the drive. If I recall correctly, the disk was formatted using the autoformatting option supplied by the OpenBSD 6.8 installer and has the following disklabel: # /dev/rsd0c: type: SCSI disk: SCSI disk label: SAMSUNG MZHPV512 duid: e4819536ae37a0af flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 62260 total sectors: 1000215216 # total bytes: 476.9G boundstart: 64 boundend: 1000206900 drivedata: 0 16 partitions: # size offset fstype [fsize bsize cpg] a: 1.0G 64 4.2BSD 2048 16384 12960 # / b: 8.1G 2097216 swap # none c: 476.9G 0 unused d: 4.0G 19164928 4.2BSD 2048 16384 12960 # /tmp e: 19.8G 27553536 4.2BSD 2048 16384 12956 # /var f: 6.0G 69028992 4.2BSD 2048 16384 12960 # /usr g: 1.0G 81611904 4.2BSD 2048 16384 12960 # /usr/X11R6 h: 20.0G 83709056 4.2BSD 2048 16384 12960 # /usr/local i: 2.0G 125652096 4.2BSD 2048 16384 12960 # /usr/src j: 6.0G 129846400 4.2BSD 2048 16384 12960 # /usr/obj k: 300.0G 142429312 4.2BSD 4096 32768 26062 # /home By the looks of it, the swap partition should be sufficiently large to support hibernate. I went through the following steps to highlight the issue: 1. Reboot machine using "doas reboot" to start the test with a clean slate. 2. Switch to console; The machine starts xenodm at boot as the machine is meant to be used as a workstation by my children. 3. Login, execute "ZZZ" and wait for the machine to finish hibernating. 4. Resume machine. 5. OpenBSD boot(8) bootstrap program shows the standard boot prompt, i.e. it does not detect that the machine is being resumed after it has been hibernated. Does it say "unhibernate detected; switching to bsd.booted" at the boot> prompt here? -ml No, it unfortunately does not. The machine simply boots up as if it is a fresh boot. I have other Lenovo laptops (X200 Tablet and T430s) that do support hibernate, so I feel that I should be able to recognize a successful hibernate/resume sequence. I forgot to mention in my previous email that, while the machine is hibernating, the screen is switched off as well making it hard to know what exactly is going on. Cheers, Mark 6. Machine boots as if the hibernate request was never executed. During boot OpenBSD detects a number of uncleanly unmounted filesystems as well. The above test sequence was executed on a fresh OpenBSD 6.9 snapshot which was successfully installed using "sysupgrade -s": OpenBSD 6.9-beta (GENERIC.MP) #446: Sat Apr 3 01:48:42 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8261603328 (7878MB) avail mem = 7995830272 (7625MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (65 entries) bios0: vendor LENOVO version "N14ET54W (1.32 )" date 03/19/2020 bios0: LENOVO 20BTS0MX00 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI MSDM BATB FPDT UEFI acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 798.31 MHz, 06-3d-04 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 798.16 MHz, 06-3d-04 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,
Re: Does Minecraft + Microsoft account on OpenBSD work?
On 4/5/2021 3:49 AM, Pamela Mosiejczuk wrote: On 4/4/21 12:06 PM, Parodper wrote: O 04/04/21 ás 16:34, Mark Hesselink escribiu: Hi, Minecraft Java Edition can be easily installed on OpenBSD using the games/minecraft port (see e.g. https://openports.se/games/minecraft). Before I buy the game, which at 17.95 GBP is reasonably priced IMHO, I wanted to ask the OpenBSD community whether anyone has been able to get the Minecraft port to work using a Microsoft account: Since 1 December 2020 one needs a Microsoft account to buy and play Minecraft Java Edition. I have attempted to start the games/minecraft port in demo mode using the instructions posted at https://minecraft.fandom.com/wiki/Demo_mode: Supposedly passing the --demo argument to minecraft.jar should launch the demo. Assuming these instructions are correct, I have not been able to log in to Minecraft using my Microsoft account despite registering the account for a free trial. Would anyone know the magic trick to play Minecraft Java Edition on OpenBSD using a Microsoft account? Cheers, Mark I have an account with the paid game. For me it runs perfectly. However there is a problem: this launcher is outdated. Now there is a new one that runs from a native executable, and the Java one is deprecated. This means that you can't run the newer versions (haven't tried it, but after a bit of searching I can find complains from version 1.14.4). And I can't find what are you saying about that «Demo mode page». It clearly says that for launching the demo you only need to login as an account without the game bought. The «--demo» option is for servers. To handle the newer versions we have games/multimc for a more feature-rich launcher or you can tinker with games/py-minecraft-launcher-lib (kmos@ has scripts for different versions here: https://github.com/kmosiejczuk/minecraft-launchers). But no, neither currently handles Microsoft accounts. I believe multimc plans that for their 0.7 release. -pamela Pamela, thanks for pointing me in the right direction! I will patiently await the MultiMC release that support Microsoft accounts. Cheers, Mark
Re: gl.inet Brume (GL-MV1000): sdcard works with 6.8 but not -current
> From: Darren Tucker > Date: Sun, 4 Apr 2021 09:18:30 +1000 > > On Sun, 4 Apr 2021 at 01:32, Patrick Wildt wrote: > > [...] > Maybe you both can try my revert and make sure it doesn't introduce any > other regressions? > > That also seems to work on the Brume in question: Works for the Turris MOX as well. Do you want to commit the revert Darren? > >> OpenBSD/arm64 BOOTAA64 1.2 > boot> boot /bsd.test > booting sd0a:/bsd.test: 8808452+1793560+567784+830080 > [634134+109+1073400+630260]=0xf904a0 > type 0x2 pa 0x0 va 0x0 pages 0x4000 attr 0x8 > [lots snipped] > type 0x2 pa 0x3ffa6000 va 0x3e715000 pages 0x5a attr 0x8 > [ using 2338872 bytes of bsd ELF symbol table ] > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2021 OpenBSD. All rights reserved. > https://www.OpenBSD.org > > OpenBSD 6.9-beta (GENERIC.MP) #1: Thu Apr 1 19:48:05 AEDT 2021 > dtuc...@brume.dtucker.net:/usr/src/sys/arch/arm64/compile/GENERIC.MP > real mem = 1032523776 (984MB) > avail mem = 968355840 (923MB) > random: good seed from bootblocks > mainbus0 at root: GL.inet GL-MV1000 (Marvell) > psci0 at mainbus0: PSCI 1.0 > cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4 > cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache > cpu0: 256KB 64b/line 16-way L2 cache > cpu0: CRC32,SHA2,SHA1,AES+PMULL,ASID16 > cpu1 at mainbus0 mpidr 1: ARM Cortex-A53 r0p4 > cpu1: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache > cpu1: 256KB 64b/line 16-way L2 cache > cpu1: CRC32,SHA2,SHA1,AES+PMULL,ASID16 > efi0 at mainbus0: UEFI 2.0.5 > efi0: Das U-boot rev 0x0 > apm0 at mainbus0 > agtimer0 at mainbus0: 12500 kHz > "pmu" at mainbus0 not configured > simplebus0 at mainbus0: "soc" > simplebus1 at simplebus0: "internal-regs" > mvclock0 at simplebus1 > mvclock1 at simplebus1 > mvclock2 at simplebus1 > mvpinctrl0 at simplebus1 > syscon0 at simplebus1: "syscon" > mvpinctrl1 at simplebus1 > agintc0 at simplebus1 shift 4:3 nirq 224 nredist 2 ipi: 0, 1: > "interrupt-controller" > mvspi0 at simplebus1 > mvuart0 at simplebus1 > mvneta0 at simplebus1 > mvneta0: Ethernet address 94:83:c4:03:b0:d9 > mvmdio0 at simplebus1: "mdio" > mvsw0 at mvmdio0 phy 1: 88E6141 rev 0 > xhci0 at simplebus1, xHCI 1.0 > usb0 at xhci0: USB revision 3.0 > uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev > 3.00/1.00 addr 1 > "usb" at simplebus1 not configured > "u3d" at simplebus1 not configured > "udc" at simplebus1 not configured > "xor" at simplebus1 not configured > sdhc0 at simplebus1 > sdhc0: SDHC 3.0, 400 MHz base clock > sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed, dma > sdhc1 at simplebus1 > sdhc1: SDHC 3.0, 400 MHz base clock > sdmmc1 at sdhc1: 8-bit, sd high-speed, mmc high-speed, ddr52, dma > "sata" at simplebus1 not configured > mvkpcie0 at simplebus0 > mvkpcie0: timeout > "regulator" at mainbus0 not configured > scsibus0 at sdmmc1: 2 targets, initiator 0 > sd0 at scsibus0 targ 1 lun 0: removable > sd0: 7456MB, 512 bytes/sector, 15269888 sectors > scsibus1 at sdmmc0: 2 targets, initiator 0 > sd1 at scsibus1 targ 1 lun 0: removable > sd1: 30436MB, 512 bytes/sector, 62333952 sectors > vscsi0 at root > scsibus2 at vscsi0: 256 targets > softraid0 at root > scsibus3 at softraid0: 256 targets > root on sd1a (9e51f250b602291d.a) swap on sd1b dump on sd1b > WARNING: CHECK AND RESET THE DATE! > Automatic boot in progress: starting file system checks. > /dev/sd1a (9e51f250b602291d.a): file system is clean; not checking > 9e51f250b602291d.i: 6 files, 16034 free (8017 clusters) > pf enabled > starting network > starting early daemons: syslogd pflogd ntpd. > starting RPC daemons:. > savecore: can't find device 255/16777088 > checking quotas: done. > clearing /tmp > kern.securelevel: 0 -> 1 > creating runtime link editor directory cache. > preserving editor files. > starting network daemons: sshd smtpd sndiod. > starting local daemons: cron. > Thu Apr 1 19:50:48 AEDT 2021 > > OpenBSD/arm64 (brume.dtucker.net) (console) > > > > That BRUME thingy looks cute, but has a bit of an issue. It doesn't > > > really have three Ethernet ports. Instead those ports are part of a > > > switch that also connects to an Ethernet interface on the SoC. > > > > Yeah I noticed that. Single ethernet plus programmable switch seems > to > > be pretty common in this class of device. > > And if someone wants to program it, feel free to, mvsw(4) exists for a > reason, might just need some code. :) > > and maybe docs :-) > > # man 4 mvsw > man: No entry for mvsw in section 4 of the manual. You must be doing that on an OpenBSD 6.8 system. Man page is there on -current.
Does Minecraft + Microsoft account on OpenBSD work?
Hi, Minecraft Java Edition can be easily installed on OpenBSD using the games/minecraft port (see e.g. https://openports.se/games/minecraft). Before I buy the game, which at 17.95 GBP is reasonably priced IMHO, I wanted to ask the OpenBSD community whether anyone has been able to get the Minecraft port to work using a Microsoft account: Since 1 December 2020 one needs a Microsoft account to buy and play Minecraft Java Edition. I have attempted to start the games/minecraft port in demo mode using the instructions posted at https://minecraft.fandom.com/wiki/Demo_mode: Supposedly passing the --demo argument to minecraft.jar should launch the demo. Assuming these instructions are correct, I have not been able to log in to Minecraft using my Microsoft account despite registering the account for a free trial. Would anyone know the magic trick to play Minecraft Java Edition on OpenBSD using a Microsoft account? Cheers, Mark
Re: Suspend/resume does not work on Lenovo X1 Carbon 3rd gen laptop
cpiprt5 at acpi0: bus 10 (EXP6) acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 acpibat0 at acpi0: BAT0 model "00HW003" serial 3800 type LiP oem "SMP" acpiac0 at acpi0: AC unit offline acpithinkpad0 at acpi0: version 1.0 tpm0 at acpi0 TPM_ addr 0xfed4/0x5000, device 0x104a rev 0x4e "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "INT340F" at acpi0 not configured acpicpu0 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1 acpipwrres1 at acpi0: NVP3, resource for PEG_ acpipwrres2 at acpi0: NVP2, resource for PEG_ acpitz0 at acpi0: critical temperature is 128 degC acpivideo0 at acpi0: VID_ acpivout0 at acpivideo0: LCD0 acpivideo1 at acpi0: VID_ cpu0: using VERW MDS workaround (except on vmm entry) cpu0: Enhanced SpeedStep 798 MHz: speeds: 2601, 2600, 2500, 2300, 2100, 2000, 1800, 1700, 1500, 1400, 1200, 1100, 900, 800, 600, 500 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 5G Host" rev 0x09 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 5500" rev 0x09 drm0 at inteldrm0 inteldrm0: msi, BROADWELL, gen 8 azalia0 at pci0 dev 3 function 0 "Intel Core 5G HD Audio" rev 0x09: msi azalia0: No codecs found xhci0 at pci0 dev 20 function 0 "Intel 9 Series xHCI" rev 0x03: msi, xHCI 1.0 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 "Intel 9 Series MEI" rev 0x03 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 "Intel I218-LM" rev 0x03: msi, address 54:ee:75:5a:b9:cd azalia1 at pci0 dev 27 function 0 "Intel 9 Series HD Audio" rev 0x03: msi azalia1: codecs: Realtek ALC292 audio0 at azalia1 ppb0 at pci0 dev 28 function 0 "Intel 9 Series PCIE" rev 0xe3: msi pci1 at ppb0 bus 3 ppb1 at pci0 dev 28 function 1 "Intel 9 Series PCIE" rev 0xe3: msi pci2 at ppb1 bus 4 iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7265" rev 0x59, msi ppb2 at pci0 dev 28 function 5 "Intel 9 Series PCIE" rev 0xe3: msi pci3 at ppb2 bus 10 ahci0 at pci3 dev 0 function 0 "Samsung SM951 AHCI" rev 0x01: apic 2 int 16, AHCI 1.3 ahci0: port 0: 6.0Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: naa.50025389 sd0: 488386MB, 512 bytes/sector, 1000215216 sectors, thin pcib0 at pci0 dev 31 function 0 "Intel 9 Series LPC" rev 0x03 ichiic0 at pci0 dev 31 function 3 "Intel 9 Series SMBus" rev 0x03: apic 2 int 18 iic0 at ichiic0 pchtemp0 at pci0 dev 31 function 6 "Intel 9 Series Thermal" rev 0x03 isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 wsmouse1 at pms0 mux 0 pms0: Synaptics clickpad, firmware 8.1, 0x1e2b1 0x943300 0x330040 0xf003a3 0x12e800 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 ugen0 at uhub0 port 7 "Intel Bluetooth" rev 2.01/0.01 addr 2 uvideo0 at uhub0 port 8 configuration 1 interface 0 "Chicony Electronics Co.,Ltd. Integrated Camera" rev 2.00/0.29 addr 3 video0 at uvideo0 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (e4819536ae37a0af.a) swap on sd0b dump on sd0b WARNING: / was not properly unmounted inteldrm0: 1920x1080, 32bpp wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 wsdisplay0: screen 1-5 added (std, vt100 emulation) iwm0: hw rev 0x210, fw ver 17.3216344376.0, address 4c:34:88:04:af:ec Cheers, Mark On 4/4/2021 3:23 AM, Theo de Raadt wrote: This is not about tpm. The tpm issues people have hit were on the resume side. Your machine is failing to commit to swap a viable resume signature I've read the report. But can you try it once again, from the top, just for me, explaining it step by step? Mark Hesselink wrote: Hi Ricky, I tested your suspend suggestion and interestingly suspend works like a charm. Hibernate however still does not work. I still suspect the tpm(4) driver may lack support for this particular Lenovo X1 Carbon 3rd gen machine, but have no proof to conclusively claim this. Cheersm Mark P.S. If any OpenBSD developer is reading this email, I am more than happy to try out tpm(4) patches and report back. On 3/23/2021 3:48 AM, Ricky Cintron wrote: Hey Mark, I don't have an X1C so I can't offer any hardware-specific advice, but I see you're using the ZZZ command to hibernate the system, yet it appears you want to suspend the system (based on wording). Have you tested
Re: Suspend/resume does not work on Lenovo X1 Carbon 3rd gen laptop
Hi Ricky, I tested your suspend suggestion and interestingly suspend works like a charm. Hibernate however still does not work. I still suspect the tpm(4) driver may lack support for this particular Lenovo X1 Carbon 3rd gen machine, but have no proof to conclusively claim this. Cheersm Mark P.S. If any OpenBSD developer is reading this email, I am more than happy to try out tpm(4) patches and report back. On 3/23/2021 3:48 AM, Ricky Cintron wrote: Hey Mark, I don't have an X1C so I can't offer any hardware-specific advice, but I see you're using the ZZZ command to hibernate the system, yet it appears you want to suspend the system (based on wording). Have you tested zzz (lowercase) instead? Maybe your hardware/setup doesn't support hibernation. If you are indeed trying to hibernate, then I have nothing. Sorry. ‐‐‐ Original Message ‐‐‐ On Monday, March 22nd, 2021 at 8:20 AM, Mark Hesselink wrote: Hi, I'm sending the below bug report to misc@openbsd.org as I have deliberately not configured my OpenBSD workstations to be able to send mail -- they are mostly used by my children -- and a bug report sent directly to b...@openbsd.org never seems to have arrived. Hopefully this email does arrive. Cheers, Mark --- Synopsis: Suspend/resume does not work on Lenovo X2 Carbon 3rd gen laptop Category: system Environment: System : OpenBSD 6.9 Details : OpenBSD 6.9-beta (GENERIC.MP) #398: Fri Mar 12 15:01:24 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 Description: Suspend/resume unfortunately does not work on my Lenovo X1 Carbon 3rd gen laptop. Suspending the laptop using the ZZZ command does seem to suspend the laptop, but restarting the laptop afterwards does not result in the expected boot loader prompt of: >> OpenBSD/amd64 BOOT 3.53 unhibernate detected: switching to /bsd.booted boot> Instead a standard boot prompt is presented as if the laptop never completed the suspend request, but instead was abruptly shut down. During boot the system detects that 1 or more filesystems were not cleanly unmounted as well. I have tried playing around with the various TPM settings in the BIOS, i.e. disabled, hidden and enabled TPM. Neither of these settings seem to have an effects on the laptop's ability to cleanly suspend/resume. How-To-Repeat: ZZZ followed by booting of the laptop. Fix: No known work around. dmesg: OpenBSD 6.9-beta (GENERIC.MP) #398: Fri Mar 12 15:01:24 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8261603328 (7878MB) avail mem = 7995826176 (7625MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (65 entries) bios0: vendor LENOVO version "N14ET54W (1.32 )" date 03/19/2020 bios0: LENOVO 20BTS0MX00 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI MSDM BATB FPDT UEFI acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.63 MHz, 06-3d-04 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.24 MHz, 06-3d-04 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
Re: gl.inet Brume (GL-MV1000): sdcard works with 6.8 but not -current
Hi Darren, This got broken when Patrick fixed something related to slow mode for the Marvel ARMADA 8040 SoC. The diff below fixes it for me on my Turris MOX which uses the same SoC. Not entirely sure what is going wrong here since looking at the Linux code suggests that Patrick's fix should work on the ARMADA 3720 as well. Patrick, should I commit this? Or do you want to figure out a better fix? That BRUME thingy looks cute, but has a bit of an issue. It doesn't really have three Ethernet ports. Instead those ports are part of a switch that also connects to an Ethernet interface on the SoC. The switch can be configured to only allow traffic between certain switch ports and to do hardware VLAN tagging. But by default OpenBSD configures the switch to allow traffic between all ports, which probably isn't what you want for this particular device. If you end up playing with this again, eeprom -p output would be appreciated. Cheers, Mark Index: dev/fdt/sdhc_fdt.c === RCS file: /cvs/src/sys/dev/fdt/sdhc_fdt.c,v retrieving revision 1.14 diff -u -p -r1.14 sdhc_fdt.c --- dev/fdt/sdhc_fdt.c 22 Feb 2021 18:55:23 - 1.14 +++ dev/fdt/sdhc_fdt.c 1 Apr 2021 22:36:11 - @@ -282,6 +282,8 @@ sdhc_fdt_attach(struct device *parent, s if (OF_getproplen(faa->fa_node, "marvell,xenon-phy-slow-mode") == 0) sc->sc_slow_mode = 1; + if (OF_is_compatible(faa->fa_node, "marvell,armada-3700-sdhci")) + sc->sc_slow_mode = 1; sc->sc_znr = OF_getpropint(faa->fa_node, "marvell,xenon-phy-znr", 0xf);
OpenBSD 6.9beta issue: kernel: protection fault trap, code=0
Is it a known issue in OpenBSD 6.9 beta / Snapshot 12th March 2021 ?
The system has crashed after running less than 16 hours.
*kernel: protection fault trap, code=0**
*
*Stopped at dounmount+0x52: movq 0x28(%r13),%rax*
*ddb{0}>*
Details:
# ---
OpenBSD obsd69git.it-infra.org 6.9 GENERIC.MP#398 amd64
Snapshot 12th March 2021
CPU: AMD FX(tm)-8350 Eight-Core Processor, 4014.02 MHz, 15-02-00
obsd69git# dmesg | grep -i bios
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdc315018 (61 entries)
bios0: vendor American Megatrends Inc. version "1901" date 12/24/2013
bios0: ASUSTeK COMPUTER INC. CROSSHAIR V FORMULA-Z
acpi0 at bios0: ACPI 5.0
obsd69git# dmesg | grep -i SATA
ahci2 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x40: apic 9 int
19, AHCI 1.2
obsd69git# dmesg | grep -i RAM
spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM ECC PC3-10600 with thermal sensor
spdmem1 at iic0 addr 0x51: 4GB DDR3 SDRAM ECC PC3-10600 with thermal sensor
spdmem2 at iic0 addr 0x52: 4GB DDR3 SDRAM ECC PC3-10600 with thermal sensor
spdmem3 at iic0 addr 0x53: 4GB DDR3 SDRAM ECC PC3-10600 with thermal sensor
pchb3 at pci0 dev 24 function 2 "AMD 15/0xh DRAM Cfg" rev 0x00
obsd69git# dmesg | grep -i samsung
sd0 at scsibus1 targ 0 lun 0:
naa.5002538e408ac11b
sd1 at scsibus1 targ 1 lun 0:
naa.5002538e408ac10e
sd2 at scsibus3 targ 0 lun 0:
naa.50024e92068f5d9f
sd3 at scsibus3 targ 1 lun 0:
naa.50024e92068f5d9a
sd4 at scsibus3 targ 2 lun 0:
naa.50024e92068f5d9c
sd5 at scsibus3 targ 3 lun 0:
naa.50024e92068f5d6a
sd6 at scsibus3 targ 4 lun 0:
naa.50024e92068f5d84
sd7 at scsibus3 targ 5 lun 0:
naa.50024e92068f5d99
obsd69git# dmesg | grep -i softraid
softraid0 at root
scsibus6 at softraid0: 256 targets
softraid0: sd9 was not shutdown properly
obsd69git# sysctl hw.disknames
hw.disknames=sd0:553cae16451b3cb7,sd1:dae36235ce6b361a,sd2:adba0b481ff5b6be,sd3:4bdc656f37091800,sd4:934967dd2ec59d94,sd5:754233445f3d62cf,sd6:bbdea192299df3a3,sd7:5107567be1a8f7aa,sd8:93ec5e3b72df4d82,sd9:e723933b51373e58
#Boot drive (Samsung 840 PRO 256GB connected over SATA3 / USB3 adapter
to an internal USB3 port of the main board)
obsd69git# bioctl -q sd8
sd8: , serial (unknown)
Thank you, Mark
--
m...@it-infrastrukturen.org
Suspend/resume does not work on Lenovo X1 Carbon 3rd gen laptop
Hi, I'm sending the below bug report to misc@openbsd.org as I have deliberately not configured my OpenBSD workstations to be able to send mail -- they are mostly used by my children -- and a bug report sent directly to b...@openbsd.org never seems to have arrived. Hopefully this email does arrive. Cheers, Mark --- >Synopsis: Suspend/resume does not work on Lenovo X2 Carbon 3rd gen laptop >Category: system >Environment: System : OpenBSD 6.9 Details : OpenBSD 6.9-beta (GENERIC.MP) #398: Fri Mar 12 15:01:24 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: Suspend/resume unfortunately does not work on my Lenovo X1 Carbon 3rd gen laptop. Suspending the laptop using the ZZZ command does seem to suspend the laptop, but restarting the laptop afterwards does not result in the expected boot loader prompt of: >> OpenBSD/amd64 BOOT 3.53 unhibernate detected: switching to /bsd.booted boot> Instead a standard boot prompt is presented as if the laptop never completed the suspend request, but instead was abruptly shut down. During boot the system detects that 1 or more filesystems were not cleanly unmounted as well. I have tried playing around with the various TPM settings in the BIOS, i.e. disabled, hidden and enabled TPM. Neither of these settings seem to have an effects on the laptop's ability to cleanly suspend/resume. >How-To-Repeat: ZZZ followed by booting of the laptop. >Fix: No known work around. dmesg: OpenBSD 6.9-beta (GENERIC.MP) #398: Fri Mar 12 15:01:24 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8261603328 (7878MB) avail mem = 7995826176 (7625MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (65 entries) bios0: vendor LENOVO version "N14ET54W (1.32 )" date 03/19/2020 bios0: LENOVO 20BTS0MX00 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI MSDM BATB FPDT UEFI acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.63 MHz, 06-3d-04 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.24 MHz, 06-3d-04 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 3 (EXP1) acpiprt3 at acpi0: bus 4 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpiprt5 at acpi0: bus 10 (EXP6) acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 acpibat0 at acpi0: BAT0 model "00HW003" serial 3800 type LiP oem "SMP" acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0: version 1.0 tpm0 at acpi0 TPM_ addr 0xfed4/0x5000, device 0x104a rev 0x4e "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "INT340F" at acpi0 not configured acpicpu0 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@
Re: OpenBSD 6.8 - softraid issue: "uvm_fault(0xffffffff821f5490, 0x40, 0, 1) -> e"
On 02.03.21 10:39, Stuart Henderson wrote:
On 2021/03/02 00:09, Mark Schneider wrote:
Hi,
Thank you for your feeeback.
Also OpenBSD 6.9beta snapshot is crashing when I setup RAID5 with three
"Samsung PRO 860 1TB" SSDs.
OpenBSD obsd69b.it-infra.org 6.9 GENERIC.MP#368 amd64
obsd69b# dmesg | grep -i bios
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdc312018 (61 entries)
bios0: vendor American Megatrends Inc. version "2201" date 03/23/2015
bios0: ASUSTeK COMPUTER INC. CROSSHAIR V FORMULA-Z
acpi0 at bios0: ACPI 5.0
Can you isolate softraid from the equation? Are the drives reliable with
this hardware configuration when not using softraid? I guess it would
need testing with simultaneous writes to the 3 drives to give a closer
match to the situation with softraid.
Thanks a lot for all hints Stuart.
The isolated 1TB SSD Samsung PRO 860 drives have some AHCI errors
(OpenBSD_6.9beta-RAID5-3x1TB-SSD-isolated.txt in the attachment).
Writing to an "isolated" drive does not crash OpenBSD even there are
AHCI errors and sometimes an I/O error from dd (see directly below).
# ---
obsd69b# dd if=/dev/urandom of=/ssd1T-sd1a/1GB-urandom.bin bs=1M count=1024
dd: /ssd1T-sd1a/1GB-urandom.bin: Input/output error
1+0 records in
0+0 records out
0 bytes transferred in 0.014 secs (0 bytes/sec)
obsd69b# dd if=/dev/urandom of=/ssd1T-sd1a/1GB-urandom.bin bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 5.156 secs (208228191 bytes/sec)
# ---
ahci2: NCQ errored slot 3 is idle (0400 active)
ahci2: NCQ errored slot 13 is idle (7c0f01eb active)
ahci2: NCQ errored slot 26 is idle (03fe1e07 active)
ahci2: NCQ errored slot 30 is idle (03e1e38f active)
ahci2: NCQ errored slot 28 is idle (03e1fc71 active)
ahci2: NCQ errored slot 30 is idle (03fc9f81 active)
ahci2: NCQ errored slot 9 is idle (0f0ee03f active)
ahci2: NCQ errored slot 16 is idle (70f400ff active)
ahci2: NCQ errored slot 28 is idle (0f3c407f active)
ahci2: NCQ errored slot 13 is idle (70dc41fc active)
ahci2: NCQ errored slot 17 is idle (0f3c1fe0 active)
ahci2: NCQ errored slot 30 is idle (0f7c181f active)
Writing to all "isolated" drives simultanously does not crash OpenBSD
even there are AHCI errors
#
--
obsd69b# dd if=/dev/urandom of=/ssd1T-sd1a/10GB-urandom.bin bs=10M
count=1024
1024+0 records in
1024+0 records out
10737418240 bytes transferred in 160.129 secs (67054710 bytes/sec)
obsd69b# dd if=/dev/urandom of=/ssd1T-sd2a/10GB-urandom.bin bs=10M
count=1024
1024+0 records in
1024+0 records out
10737418240 bytes transferred in 158.783 secs (67623059 bytes/sec
obsd69b# dd if=/dev/urandom of=/ssd1T-sd3a/10GB-urandom.bin bs=10M
count=1024
1024+0 records in
1024+0 records out
10737418240 bytes transferred in 160.085 secs (67072961 bytes/sec
# ---
ahci2: NCQ errored slot 25 is idle (00ff active)
ahci2: NCQ errored slot 21 is idle (7fff active)
ahci2: NCQ errored slot 6 is idle (0001 active)
ahci2: NCQ errored slot 21 is idle (03ff active)
ahci2: NCQ errored slot 1 is idle (0380 active)
ahci2: NCQ errored slot 27 is idle (01ff active)
ahci2: NCQ errored slot 23 is idle (0030 active)
ahci2: NCQ errored slot 25 is idle (0fff active)
# OpenBSD 6.9beta is crashing after a dd command writing to the RAID5
softraid volume (sd4a) and the access to the ddb{4}> prompt is not
possible to run trace, ps or sh commands (the root console is dead).
"trace" and "sh reg" from ddb would give more clues.
I am not able to run the commands above as the root ddb{4} console is
dead (I can see only the last error message but I am not able to type in
using the keyboard)
I will connect those Samsung PRO 860 1TB SSDs to a Xeon based system
(another SATA-controller) and check there for AHCI errors.
Maybe it is worth to mention, that the original RAID tests on Debian
buster with six of 512GB Samsung PRO 860 (the same drives andf RAID6 set
with mdadm) worked without crashing the OS.
Kind regards
Mark
bs=10M count=1024
# Error messages
uvm_fault(0x821f5490, 0x40, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at sr_validate_io+0x44: cmpl $0,0x40(%r9)
ddb{2}>
$ objdump -dlr softraid.o | less
...skipping...
9cc0 :
sr_validate_io():
/usr/src/sys/dev/softraid.c:4569
9cc0: 4c 8b 1d 00 00 00 00mov0(%rip),%r11# 9cc7
9cc3: R_X86_64_PC32
__retguard_3962+0xfffc
9cc7: 4c 33 1c 24 xor(%rsp),%r11
9ccb: 55 push %rbp
9ccc: 48 89 e5mov%rsp,%rbp
9ccf: 57 push %rdi
9cd0: 56 push %rsi
9cd1: 52 push %rdx
9cd2: 57 push %rdi
Re: OpenBSD 6.8 - softraid issue: "uvm_fault(0xffffffff821f5490, 0x40, 0, 1) -> e"
Hi,
Thank you for your feeeback.
Also OpenBSD 6.9beta snapshot is crashing when I setup RAID5 with three
"Samsung PRO 860 1TB" SSDs.
OpenBSD obsd69b.it-infra.org 6.9 GENERIC.MP#368 amd64
obsd69b# dmesg | grep -i bios
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdc312018 (61 entries)
bios0: vendor American Megatrends Inc. version "2201" date 03/23/2015
bios0: ASUSTeK COMPUTER INC. CROSSHAIR V FORMULA-Z
acpi0 at bios0: ACPI 5.0
# ---
sha512sum install69_amd64_snapshot.img
9bcf7feae186966cecf0de041d283ef27678ef350fd5c17e953e3d27d719aa8e3b034634b65ac04794d8568a7bb4807f7673fcdb6a86a66808ba0a55f4087368
install69_amd64_snapshot.img
md5sum -b install69_amd64_snapshot.img
0408ba32001dccb6465f76faefc6eb8a *install69_amd64_snapshot.img
OpenBSD 6.8 or 6.9beta do not crash writing big files to RAID5 when the
SSDs are "Samsung PRO 850 1TB" or "Intel DC S3520 150GB"
Today I have used only 6G SATA cables for the RAID configuration.
What I really worry about is the fact, that OpenBSD 6.8 or 6.9beta is
crashing with RAID5 based on Samsung PRO 860 512MB or 1TB SSD drives.
Kind regards
Mark
On 01.03.21 15:35, Atanas Vladimirov wrote:
On 2021-02-27 03:35, Mark Schneider wrote:
Hi,
I face system crash on OpenBSD 6.8 when trying to use softraid RAID5
drive trying to write big files (like 10GBytes) to it.
I can reproduce the error (tested on two different systems with
OpenBSD 6.8 installed on an SSD drive or an USB stick). The RAID5
drive itself consist of six Samsung PRO 860 512GB SSDs.
In short:
bioctl -c 5 -l sd0a,sd1a,sd2a,sd3a,sd4a,sd5a softraid0
obsdssdarc# disklabel sd7
# /dev/rsd7c:
type: SCSI
disk: SCSI disk
label: SR RAID 5
duid: a50fb9a25bf07243
flags:
bytes/sector: 512
sectors/track: 255
tracks/cylinder: 511
sectors/cylinder: 130305
cylinders: 38379
total sectors: 5001073280
boundstart: 0
boundend: 5001073280
drivedata: 0
16 partitions:
# size offset fstype [fsize bsize cpg]
a: 5001073280 0 4.2BSD 8192 65536 52270
c: 5001073280 0 unused
#
obsdssdarc# time dd if=/dev/urandom of=/arc-ssd/1GB-urandom.bin bs=1M
count=1024
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 8.120 secs (132218264 bytes/sec)
0m08.13s real 0m00.00s user 0m08.14s system
# Working as expected
^^
obsdssdarc# time dd if=/dev/urandom of=/arc-ssd/10GB-urandom.bin
bs=10M count=1024
# Error messages
uvm_fault(0x821f5490, 0x40, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at sr_validate_io+0x44: cmpl $0,0x40(%r9)
ddb{2}>
# Crashing OpenBSD 6.8
^^^
# After reboot:
obsdssdarc# mount /dev/sd7a /arc-ssd/
mount_ffs: /dev/sd7a on /arc-ssd: Device not configure
obsdssdarc# grep sd7 /var/run/dmesg.boot
softraid0: trying to bring up sd7 degraded
softraid0: sd7 was not shutdown properly
softraid0: sd7 is offline, will not be brought online
More details in attached files. Thanks a lot in advance for short
feedback.
Kind regards
Mark
Hi,
I can't reproduce this on a resent snapshot:
```
temp# bioctl sd5
Volume Status Size Device
softraid0 1 Online 2356352188416 sd5 RAID5
0 Online 785450747904 1:0.0 noencl
1 Online 785450747904 1:1.0 noencl
2 Online 785450747904 1:2.0 noencl
3 Online 785450747904 1:3.0 noencl
temp# time dd if=/dev/urandom of=20GB-urandom.bin bs=10M count=2048
2048+0 records in
2048+0 records out
21474836480 bytes transferred in 1845.313 secs (11637500 bytes/sec)
30m45.95s real 0m00.01s user 2m21.61s system
temp# ls -lh
total 41948288
-rw-r--r-- 1 root wheel 20.0G Mar 1 13:05 20GB-urandom.bin
```
```
OpenBSD 6.9-beta (GENERIC.MP) #366: Sun Feb 28 07:15:39 MST 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17134055424 (16340MB)
avail mem = 16599408640 (15830MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb5a0 (56 entries)
bios0: vendor American Megatrends Inc. version "2.3a" date 01/06/2021
bios0: Supermicro X9SCL/X9SCM
```
# OpenBSD 6.9beta RAID5 configuration with three 1TB "Samsung SSD PRO 860"
drives
sysctl hw.disknames
disklabel sd1
disklabel -E sd1
disklabel -E sd2
odisklabel -E sd3
bioctl -c 5 -l sd1a,sd2a,sd3a softraid0
disklabel -E sd4
newfs sd4a
obsdarc# mkdir /arc-3xssd
obsdarc# mount /dev/sd4a /arc-3xssd/
Re: OpenBSD 6.8 - softraid issue: "uvm_fault(0xffffffff821f5490, 0x40, 0, 1) -> e"
Hi Karel,
Thank you very much for your feedback and hints.
I have already opened a bug request for this issue, however I am not
able to deliver the output of "trace" and "ps" commands from the ddb{4}>
or ddb{2}> prompts as the crashed system is frozen so I can not type or
see output typing blind.
In another email to misc (or just further below) I described some more
tests.
I have to check how to compile a kernel with debug support and install
it on the OpenBSD 6.8 box for further investigations.
Kind regards
Mark
# --- copy of the previous email to misc
Thank you very much for your feedback, suggestions and hints.
Indeed yesterday I saw one read and one write error related to Samsung
PRO SSDs before another OS crash (I run more different tests writing big
files to the RAID5 using "dd" or "cat" commands)
Today I have installed three new 1TB Samsung PRO 960 SSD drives inside a
third box (however also an ASUS mainboard with AMD FX CPU and 16GB ECC
RAM) and set RAID5 as described in the attached file.
And again a similar error after dd (slightly different values):
# ---
dd if=/dev/urandom of=/arc-3xssd/1GB-urandom.bin bs=1M count=1024
# Error messages
uvm_fault(0x821ede50, 0x40, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at sr_validate_io+0x44: cmpl $0,0x40(%r9)
ddb{4}>
The error happens on the RAID5 level (there is no encryption).
In the test case above I used 30cm long SATA 3G cables (Samsung PRO 860
and the SATA controller are 6G) as I did not have the 6G SATA cables
available.
I run the original tests with 6G SATA cables.
For some reason the "ddb{4}>" is frozen so I am not able to type
anything on the ddb input prompt on the console (and I don't see any
output typing blind "trace" or "ps" ).
I have somewhere some older Samsung PRO 850 SSDs so I will try to test
the RAID5 configuration with them.
On 28.02.21 19:55, Karel Gardas wrote:
Hi,
compile kernel with debug enabled so you will get line number from the
crash. See what's there. Go thorough git/cvs logs and see if anybody
did anything with global mutex over sata/sr raid. Read the code. The
possibility is you are hitting a bug which is there since raid5 was
added to obsd, none
just tested with that amount of ssds so you are in unique position to
hunt this bug down. Congratulations and good luck!
Karel
On 2/28/21 3:05 AM, Mark Schneider wrote:
Hi again,
I have repeated softraid tests using six pcs of 1TB Samsung HDD 3G
SATA drives as RAID5 and I do not face the crash issue of the OS when
using SSDs in the RAID5.
Details of the RAID5 setting are in the attached file.
It looks like using SSD drives as RAID5 leads for some reason to the
OpenBSD 6.8 crash. Samsung 512MB PRO 860 SSDs have 6G SATA interface
(what is different compared to tested HDDs)
NB: Using those SSDs as RAID6 on debian Linux (buster - mdadm /
cryptoLUKS) does not face any issues
There are also no issues using those SSDs as RAID on FreeBSD
(TrueNAS).
Kind regards
Mark
On 27.02.21 04:30, Mark Schneider wrote:
Hi,
I face system crash on OpenBSD 6.8 when trying to use softraid RAID5
drive trying to write big files (like 10GBytes) to it.
I can reproduce the error (tested on two different systems with
OpenBSD 6.8 installed on an SSD drive or an USB stick). The RAID5
drive itself consist of six Samsung PRO 860 512GB SSDs.
In short:
bioctl -c 5 -l sd0a,sd1a,sd2a,sd3a,sd4a,sd5a softraid0
obsdssdarc# disklabel sd7
# /dev/rsd7c:
type: SCSI
disk: SCSI disk
label: SR RAID 5
duid: a50fb9a25bf07243
flags:
bytes/sector: 512
sectors/track: 255
tracks/cylinder: 511
sectors/cylinder: 130305
cylinders: 38379
total sectors: 5001073280
boundstart: 0
boundend: 5001073280
drivedata: 0
16 partitions:
# size offset fstype [fsize bsize cpg]
a: 5001073280 0 4.2BSD 8192 65536 52270
c: 5001073280 0 unused
#
obsdssdarc# time dd if=/dev/urandom of=/arc-ssd/1GB-urandom.bin
bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 8.120 secs (132218264 bytes/sec)
0m08.13s real 0m00.00s user 0m08.14s system
# Working as expected
^^
obsdssdarc# time dd if=/dev/urandom of=/arc-ssd/10GB-urandom.bin
bs=10M count=1024
# Error messages
uvm_fault(0x821f5490, 0x40, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at sr_validate_io+0x44: cmpl $0,0x40(%r9)
ddb{2}>
# Crashing OpenBSD 6.8
^^^
# After reboot:
obsdssdarc# mount /dev/sd7a /arc-ssd/
mount_ffs: /dev/sd7a on /arc-ssd: Device not configure
obsdssdarc# grep sd7 /var/run/dmesg.boot
softraid0: trying to bring up sd7 degraded
sof
Re: OpenBSD 6.8 - softraid issue: "uvm_fault(0xffffffff821f5490, 0x40, 0, 1) -> e"
Hi Stefan
Thank you very much for your feedback, suggestions and hints.
Indeed yesterday I saw one read and one write error related to Samsung
PRO SSDs before another OS crash (I run more different tests writing big
files to the RAID5 using "dd" or "cat" commands)
Today I have installed three new 1TB Samsung PRO 960 SSD drives inside a
third box (however also an ASUS mainboard with AMD FX CPU and 16GB ECC
RAM) and set RAID5 as described in the attached file.
And again a similar error after dd (slightly different values):
# ---
dd if=/dev/urandom of=/arc-3xssd/1GB-urandom.bin bs=1M count=1024
# Error messages
uvm_fault(0x821ede50, 0x40, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at sr_validate_io+0x44: cmpl $0,0x40(%r9)
ddb{4}>
The error happens on the RAID5 level (there is no encryption).
In the test case above I used 30cm long SATA 3G cables (Samsung PRO 860
and the SATA controller are 6G) as I did not have the 6G SATA cables
available.
I run the original tests with 6G SATA cables.
For some reason the "ddb{4}>" is frozen so I am not able to type
anything on the ddb input prompt on the console (and I don't see any
output typing blind "trace" or "ps" ).
I have somewhere some older Samsung PRO 850 SSDs so I will try to test
the RAID5 configuration with them.
Kind regards
Mark
On 28.02.21 20:17, Stefan Sperling wrote:
On Sun, Feb 28, 2021 at 03:05:49AM +0100, Mark Schneider wrote:
Hi again,
I have repeated softraid tests using six pcs of 1TB Samsung HDD 3G SATA
drives as RAID5 and I do not face the crash issue of the OS when using SSDs
in the RAID5.
Details of the RAID5 setting are in the attached file.
It looks like using SSD drives as RAID5 leads for some reason to the OpenBSD
6.8 crash. Samsung 512MB PRO 860 SSDs have 6G SATA interface (what is
different compared to tested HDDs)
NB: Using those SSDs as RAID6 on debian Linux (buster - mdadm / cryptoLUKS)
does not face any issues
There are also no issues using those SSDs as RAID on FreeBSD
(TrueNAS).
I've seen some Samsung Pro SSDs cause I/O errors on ahci(4) due to unhandled
NCQ error conditions. Not sure if this relates to your problem; I assume that
these errors were specific to my machine, which is over 10 years old. Its AHCI
controller has likely not been designed with modern SSDs in mind. I switched
to different SSDs and the problem disappeared. This was on RAID1 where the
kernel didn't crash. Instead, the volume ended up in degraded state.
Maybe some I/O error is happening in your case as well?
Perhaps the raid5 code doesn't handle i/o errors gracefully?
In any case, your bug report is missing important information:
# Error messages
uvm_fault(0x821f5490, 0x40, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at sr_validate_io+0x44: cmpl $0,0x40(%r9)
ddb{2}>
This tells us where it crashed but not how the code flow ended up here.
Please show the stack trace printed by the 'trace' command, and the output
of the 'ps' command (both commands at the ddb> prompt).
# OpenBSD 6.8 RAID5 configuration with three 1TB "Samsung SSD PRO 860" drives
sysctl hw.disknames
disklabel sd1
disklabel -E sd1
disklabel -E sd2
odisklabel -E sd3
bioctl -c 5 -l sd1a,sd2a,sd3a softraid0
disklabel -E sd4
newfs sd4a
obsdarc# mkdir /arc-3xssd
obsdarc# mount /dev/sd4a /arc-3xssd/
obsdarc# df -h | grep 3xssd
/dev/sd4a 1.8T8.0K1.8T 0%/arc-3xssd
# --
dd if=/dev/urandom of=/arc-3xssd/1GB-urandom.bin bs=1M count=1024
# Error messages
uvm_fault(0x821ede50, 0x40, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at sr_validate_io+0x44:cmpl $0,0x40(%r9)
ddb{4}>
# --
obsdarc# disklabel sd1
# /dev/rsd1c:
type: SCSI
disk: SCSI disk
label: Samsung SSD 860
duid: cb0d589d6d25894e
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 124519
total sectors: 2000409264
boundstart: 0
boundend: 2000409264
drivedata: 0
16 partitions:
#size offset fstype [fsize bsize cpg]
a: 2000409264
Re: OpenBSD 6.8 - softraid issue: "uvm_fault(0xffffffff821f5490, 0x40, 0, 1) -> e"
Hi again,
I have repeated softraid tests using six pcs of 1TB Samsung HDD 3G SATA
drives as RAID5 and I do not face the crash issue of the OS when using
SSDs in the RAID5.
Details of the RAID5 setting are in the attached file.
It looks like using SSD drives as RAID5 leads for some reason to the
OpenBSD 6.8 crash. Samsung 512MB PRO 860 SSDs have 6G SATA interface
(what is different compared to tested HDDs)
NB: Using those SSDs as RAID6 on debian Linux (buster - mdadm /
cryptoLUKS) does not face any issues
There are also no issues using those SSDs as RAID on FreeBSD
(TrueNAS).
Kind regards
Mark
On 27.02.21 04:30, Mark Schneider wrote:
Hi,
I face system crash on OpenBSD 6.8 when trying to use softraid RAID5
drive trying to write big files (like 10GBytes) to it.
I can reproduce the error (tested on two different systems with
OpenBSD 6.8 installed on an SSD drive or an USB stick). The RAID5
drive itself consist of six Samsung PRO 860 512GB SSDs.
In short:
bioctl -c 5 -l sd0a,sd1a,sd2a,sd3a,sd4a,sd5a softraid0
obsdssdarc# disklabel sd7
# /dev/rsd7c:
type: SCSI
disk: SCSI disk
label: SR RAID 5
duid: a50fb9a25bf07243
flags:
bytes/sector: 512
sectors/track: 255
tracks/cylinder: 511
sectors/cylinder: 130305
cylinders: 38379
total sectors: 5001073280
boundstart: 0
boundend: 5001073280
drivedata: 0
16 partitions:
# size offset fstype [fsize bsize cpg]
a: 5001073280 0 4.2BSD 8192 65536 52270
c: 5001073280 0 unused
#
obsdssdarc# time dd if=/dev/urandom of=/arc-ssd/1GB-urandom.bin bs=1M
count=1024
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 8.120 secs (132218264 bytes/sec)
0m08.13s real 0m00.00s user 0m08.14s system
# Working as expected
^^
obsdssdarc# time dd if=/dev/urandom of=/arc-ssd/10GB-urandom.bin
bs=10M count=1024
# Error messages
uvm_fault(0x821f5490, 0x40, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at sr_validate_io+0x44: cmpl $0,0x40(%r9)
ddb{2}>
# Crashing OpenBSD 6.8
^^^
# After reboot:
obsdssdarc# mount /dev/sd7a /arc-ssd/
mount_ffs: /dev/sd7a on /arc-ssd: Device not configure
obsdssdarc# grep sd7 /var/run/dmesg.boot
softraid0: trying to bring up sd7 degraded
softraid0: sd7 was not shutdown properly
softraid0: sd7 is offline, will not be brought online
More details in attached files. Thanks a lot in advance for short
feedback.
Kind regards
Mark
obsdarc# history -0
1 sysctl hw.disknames
3 dd if=/dev/zero of=/dev/rsd1c bs=1m count=1024
4 dd if=/dev/zero of=/dev/rsd2c bs=1m count=1024
5 dd if=/dev/zero of=/dev/rsd3c bs=1m count=1024
6 dd if=/dev/zero of=/dev/rsd4c bs=1m count=1024
7 dd if=/dev/zero of=/dev/rsd5c bs=1m count=1024
8 dd if=/dev/zero of=/dev/rsd6c bs=1m count=1024
9 fdisk -iy sd1
10 fdisk -iy sd2
11 fdisk -iy sd3
12 fdisk -iy sd4
13 fdisk -iy sd5
14 fdisk -iy sd6
15 disklabel -E sd1
16 disklabel -E sd2
17 disklabel -E sd3
18 disklabel -E sd4
19 disklabel -E sd5
20 disklabel -E sd6
21 bioctl -c 5 -l sd1a,sd2a,sd3a,sd4a,sd5a,sd6a softraid0
22 disklabel -E sd7
23 fdisk sd7
24 disklabel sd7
25 newfs sd7a
26 mkdir /arc-hdd
27 mount /dev/sd7a /arc-hdd/
30 dd if=/dev/urandom of=/arc-hdd/1GB-urandom.bin bs=1M count=1024
31 dd if=/dev/urandom of=/arc-hdd/512MB-urandom.bin bs=1M count=512
32 dd if=/dev/urandom of=/arc-hdd/2GB-urandom.bin bs=2M count=1024
33 dd if=/dev/urandom of=/arc-hdd/10GB-urandom.bin bs=10M count=1024
# ---
obsdarc# dd if=/dev/urandom of=/arc-hdd/10GB-urandom.bin bs=10M count=1024
1024+0 records in
1024+0 records out
10737418240 bytes transferred in 229.232 secs (46840774 bytes/sec)
/dev/sd7a 4.5T 13.5G4.3T 0%/arc-hdd
# ---
obsdarc# disklabel sd1
# /dev/rsd1c:
type: SCSI
disk: SCSI disk
label: SAMSUNG HN-M101M
duid: 5107567be1a8f7aa
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 121601
total sectors: 1953525168
boundstart: 64
boundend: 1953520065
drivedata: 0
16 partitions:
#size offset fstype [fsize bsize cpg]
a: 1953520001 64RAID
c: 19535251680 unused
UEFI install issues
Hello group, I've tried for the last two hours to install OpenBSD 6.8 onto an new HPE MicroServer but so far without success. Installed the .img file onto a USB stick (via Balena Etcher on a Macbook). Booted up the device and eventually got it to boot from the USB stick. The USB keyboard works initially, i.e. it allows me to press carriage return at the boot loader prompt. When I get to the 'Install, Upgrade...' prompt the keyboard no longer responds. I've disconnected and reconnected the keyboard and get the expected messages on screen to show that these actions have taken place. I've subsequently installed FreeBSD 12.2 and that's gone in with no issues at all (trouble is, whilst I could use FreeBSD for what I intend to do, I've prefer to use OpenBSD). Any thoughts?
Fw: ospf question
I'll try this message one more time. I have a question regarding the use of ospf with OpenBSD 6.8. > I have a network that consists of 23 OpenBSD 6.8 based routers (created, > within a virtualbox environment on a GNU/Linux server, to match the physical > network I manage - the only different being that the physical network > consists of FreeBSD based routers rather than OpenBSD ones). I set this up > after have replaced a FreeBSD based router with an OpenBSD based one in the > real network and immediately experiencing an issue accessing parts of the > network. > > Within my setup there is one router (router22) that is six hops away from the > designated default gateway (which I'll call the firewall) and there are two > paths (going different ways around the network) to get to it. I am able to > run a traceroute to router22, but am not able to ping it or ssh onto it. If I > ssh to the router connected to the firewall then I can ping and ssh to > router22 (at that point it's only 5 hops away). If I reboot any router that > lies within the path to router22 then I am subsequently able to ping and ssh > router22 from the firewall. > > I have also subsequently duplicated the entire network again using FreeBSD > 12.2 and the problem does not occur, so as far as I can see it's just an > OpenBSD ospf issue. > > I first set this up after replacing a FreeBSD based router with an OpenBSD > based one and experiencing another strange issue. In this instance the > shortest path from my server network (accessible from router01) to router08, > router11 and router12 was router01 <-> router13 <-> router21 <-> router08 <-> > router11 <-> router12, when I put the OpenBSD router in as router13 I could > no longer ping router08, router11 or router12 (though I could still ping > router21). If I connected to a router in a different part of the network I > was able to ping each of the inaccessible ones, so it was only when the > OpenBSD based router was along the shortest path the issue manifested itself. > > Is anyone aware of incompatibilities between the OSPF implementation within > OpenBSD and that provided by quagga on FreeBSD? Or of any limitations of OSPF > on OpenBSD? > > In each setup I have the same hello and dead interval and have md5 crypt > authentication in place on each link between routers. Each router is in area > 0.0.0.0. > > regards, > Mark
ospf question
Hello list, I have a question regarding the use of ospf with OpenBSD 6.8. I have a network that consists of 23 OpenBSD 6.8 based routers (created, within a virtualbox environment on a GNU/Linux server, to match the physical network I manage - the only different being that the physical network consists of FreeBSD based routers rather than OpenBSD ones). I set this up after have replaced a FreeBSD based router with an OpenBSD based one in the real network and immediately experiencing an issue accessing parts of the network. Within my setup there is one router (router22) that is six hops away from the designated default gateway (which I'll call the firewall) and there are two paths (going different ways around the network) to get to it. I am able to run a traceroute to router22, but am not able to ping it or ssh onto it. If I ssh to the router connected to the firewall then I can ping and ssh to router22 (at that point it's only 5 hops away). If I reboot any router that lies within the path to router22 then I am subsequently able to ping and ssh router22 from the firewall. I have also subsequently duplicated the entire network again using FreeBSD 12.2 and the problem does not occur, so as far as I can see it's just an OpenBSD ospf issue. I first set this up after replacing a FreeBSD based router with an OpenBSD based one and experiencing another strange issue. In this instance the shortest path from my server network (accessible from router01) to router08, router11 and router12 was router01 <-> router13 <-> router21 <-> router08 <-> router11 <-> router12, when I put the OpenBSD router in as router13 I could no longer ping router08, router11 or router12 (though I could still ping router21). If I connected to a router in a different part of the network I was able to ping each of the inaccessible ones, so it was only when the OpenBSD based router was along the shortest path the issue manifested itself. Is anyone aware of incompatibilities between the OSPF implementation within OpenBSD and that provided by quagga on FreeBSD? Or of any limitations of OSPF on OpenBSD? In each setup I have the same hello and dead interval and have md5 crypt authentication in place on each link between routers. Each router is in area 0.0.0.0. regards, Mark
Re: snapshot boot fails with error "entry point at 0x1001000"
Hi Kastus, Please don't have technical discussions on misc@; some developers, like me, only read it sporadically. The tech@ list is a much better place. The problem with your approach is that you allocate memory at a fixed address, and we can't be sure that memory is available. We may have to extend the amount of memory we allocate such that larger kernels fit. The diff below bumps it from 32MB to 64MB. Does this work for you? Index: arch/amd64/stand/efiboot/efiboot.c === RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v retrieving revision 1.35 diff -u -p -r1.35 efiboot.c --- arch/amd64/stand/efiboot/efiboot.c 22 Mar 2020 14:59:11 - 1.35 +++ arch/amd64/stand/efiboot/efiboot.c 27 Oct 2020 12:36:45 - @@ -39,7 +39,7 @@ #include "eficall.h" #include "run_i386.h" -#defineKERN_LOADSPACE_SIZE (32 * 1024 * 1024) +#defineKERN_LOADSPACE_SIZE (64 * 1024 * 1024) EFI_SYSTEM_TABLE *ST; EFI_BOOT_SERVICES *BS;
Re: OpenBSD X support for big resolution monitors
On 2020-08-21 14:51, Mihai Popescu wrote: Hello, My 13 years old monitor is fading out and I will need to get a replacement soon. Shops are offering here many monitors with resolution greater than Full HD 1080p,with a little price increase only. I never used nor tested such a monitor on OpenBSD X server. I am afraid fonts will be too tiny on such resolutions, so my question is how good are bigger than FHD resolution monitors supported on OpenBSD X? Do I need some extra scaling or special setup for font sizes? It works just fine on a 32"@4K (140dpi) display with different programs (cwm, firefox, thunderbird, gimp, chromium, vlc,...) Basically, you need to set: - Xft.dpi: 120 in ~/.Xresources - xrandr --dpi 120 in ~/.xsession As you can see, i use 120dpi here, but perhaps 140dpi (bigger fonts) suits you better...depends on personal preference. You can verify your current dpi setting with: $ xdpyinfo | grep resolution -Mark Thanks. -- Mark Patruck ( mark at wrapped.cx ) GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 https://www.wrapped.cx
.iso installer file sets
Good day, files sets not included in "install67.iso" installer? It suppose to be included as indicated in the documentation "/6.7/amd64/INSTALL.amd64"? Thanks and God Bless. Sincerely, Mark Novem P. Grisola
Re: mfs mount loosing permissions on -current
On 2020-05-19 13:45, Stuart Henderson wrote: On 2020-05-19, Mark Patruck wrote: Hi, sounds strange, but is anyone else seeing mfs mounted fs loosing permissions after reboot in -current (12h old)? Problem tracked down, diff is on bugs@. Thanks. Missed that one. I saw lots of permission denied errors for /tmp while trying to build via dpb. Reason was /tmp mounted 755 after boot. # chmod 1777 /tmp; ls -l / drwxrwxrwt 6 root wheel 512 May 19 12:42 tmp # mount mfs:66540 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=1048576 512 -blocks) reboot... # ls -l / drwxr-xr-x 6 root wheel 512 May 19 12:43 tmp # mount mfs:66540 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=1048576 512 -blocks) No issues on a 6 days old -current. -- Mark Patruck ( mark at wrapped.cx ) GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 https://www.wrapped.cx
mfs mount loosing permissions on -current
Hi, sounds strange, but is anyone else seeing mfs mounted fs loosing permissions after reboot in -current (12h old)? I saw lots of permission denied errors for /tmp while trying to build via dpb. Reason was /tmp mounted 755 after boot. # chmod 1777 /tmp; ls -l / drwxrwxrwt 6 root wheel 512 May 19 12:42 tmp # mount mfs:66540 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=1048576 512 -blocks) reboot... # ls -l / drwxr-xr-x 6 root wheel 512 May 19 12:43 tmp # mount mfs:66540 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=1048576 512 -blocks) No issues on a 6 days old -current. -- Mark Patruck ( mark at wrapped.cx ) GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 https://www.wrapped.cx
-current: make release fails (rvnd0i not configured)
Hi, yesterday i've tried to make a release again...the first time in the last ~ two weeks, but it always fails with the error below. Hint: - i didn't change anything regarding my amd64 build machine - after e2k19 i've updated via snap w/o issues, ran sysmerge and updated /dev - of course /dev/rvnd0i is there # export RELEASEDIR=/release/base DESTDIR=/dest/base # cd /usr/src/etc && make release strip -R .comment -R .SUNW_ctf bsd.strip gzip -9cn bsd.strip > bsd.gz dd if=/dev/zero of=miniroot66.fs bs=512 count=9600 9600+0 records in 9600+0 records out 4915200 bytes transferred in 0.037 secs (132287931 bytes/sec) vnconfig -v miniroot66.fs > vnd vnd0: 4915200 bytes on miniroot66.fs fdisk -yi -l 9600 -b 960 -f /dest/base/usr/mdec/mbr `cat vnd` Writing MBR at offset 0. disklabel -wAT /usr/src/distrib/amd64/ramdisk_cd/template `cat vnd` newfs -t msdos /dev/r`cat vnd`i newfs_msdos: /dev/rvnd0i: Device not configured *** Error 1 in /usr/src/distrib/amd64/ramdisk_cd (Makefile:23 'miniroot66.fs') *** Error 2 in /usr/src/distrib/amd64 (:48 'all') *** Error 2 in /usr/src/distrib (:48 'all') *** Error 2 in . (Makefile:298 'distrib') *** Error 2 in . (Makefile:274 'do-release') *** Error 2 in /usr/src/etc (Makefile:257 'release') Am i missing sth? -Mark -- Mark Patruck ( mark at wrapped.cx ) GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 https://www.wrapped.cx
Re: Tools for writers
Joe Davis wrote >> Some writers swear on Scrivener. It's proprietary and Mac/Win only, >> though. > > Manuskript[1] looks promising as a foss alternative. Haven't attempted > to build it on OpenBSD. None of the dependencies look to be a major > problem. > > Cheers, > Joe > > [1]: http://www.theologeek.ch/manuskript/ This looks really interesting. Thanks for sharing, Joe. -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
sr.ht: Open source development platform with OpenBSD support
Sourcehut is a stand-in replacement for Github et al. as a git repository hosting service; but also offers continuous integration on OpenBSD VMs. It's open source, has zero tracking nor advertising, and no JavaScript. It presents a clean, minimal interface, which I find pleasant. It's still in alpha, but provides a host of tooling that might be of interest to the list. I wrote a short review here[0], but sourcehut.org provides a good introduction. Regards, Mark Jamsek [0] https://jamsek.dev/posts/2019/Sep/27/sourcehut-open-source-software-development-platform/ -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: IPv4 & IPv6 CIDR subnet calculator
Hi Martin, It is, yet IPv4 still traffics most of the Internet with 75% coverage, which suggests IPv4 would be the prevalent use case. I mostly use it for IPv4. But if IPv6 is the dominant use case, I can change it. I initially thought to make it dynamically detect the version so you would only need to enter the ipaddr/prefix irrespective of the address version. I think this would be the best change. In the meantime, you can always postfix the -6 if you forget: netcalc 8c6b:dbfd:5c73:8f14:f815:a4a2:5dab:38b0/110 -6 works just the same. Or simply alias it, which is what I've done: $ type nc6 nc6 is an alias for 'netcalc -6' Regards, Mark Jamsek -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: IPv4 & IPv6 CIDR subnet calculator
Hi Martin, Here you go: https://jamsek.dev/resources/pub/netcalc/netcalc03.c No switch needed for IPv4 or IPv6. Regards, Mark Jamsek -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
IPv4 & IPv6 CIDR subnet calculator
Hi all, I’ve created a subnet calculator for both IPv4 and IPv6 written in C. As well as using it to find a network for a given IPv4 CIDR range, you can request multiple subnets with the -s option: ./netcalc 10.20.30.40/24 -s4 Or use the -6 switch for IPv6 addresses: ./netcalc -6 8c6b:dbfb:5c73:8f14:f815:a4a2:5dab:38b0/110 You’ll need to compile it with the math library linked: cc -Werror -Wall -o netcalc netcalc.c -lm Only tested on OpenBSD 6.5 and macOS Mojave 10.14 but it's probably compatible elsewhere too. https://jamsek.dev/resources/pub/netcalc There's also a man page. Regards, Mark Jamsek -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: OpenBSD Project
Ingo Schwarze wrote > Avstin Kim wrote: > >> My question is, how is the OpenBSD Project governance structured; > > There is no formal structure and no "governance". > > ... > > If your choice of operating system depends on any kind of formalities > rather than on technical quality, OpenBSD is not the project you > are looking for. > > Yours, > Ingo This is one of the ardently appealing factors of OpenBSD; technical quality isn't compromised or superseded by other arbitrary and subjective measures. The singular focus on technical quality and correctness is reassuring and consistently produces a reliable, performant product. It's certainly a quality that I find appealing and keeps me looking to contribute however I can to the project. Ingo articulated this response so well, I wanted to remark on how I feel the OpenBSD approach is received—at least for me. And to say thank you for the many contributions made these last 25 years. Thanks. -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: Answer 2 / Re: 10GBit network performance on OpenBSD 6.4
Hi Karel Thank you very much for your hint. Yes, I used FreeBSD 13.0 for final performance testing (scp transfer and iperf3). Before I run some tests with stable FreeBSD 12.0 but the performance was much lower (even still approx 3 times better than OpenBSD 6.4). FreeBSD 12.0 recognized less NIC hardware than FreeBSD 13.0 and OpenBSD 6.4. Last scp based test I run yesterday and today was with FreeNAS 11.2 including 1Gbit/s and 10Gbit/s fiber NICs and Linux on the client side. For diredtly connectet 1Gbit NICs (fiber) the scp transfer spead was like 100MBytes/s. For directly connected 10Gbit NICs (X520-DA2) the scp transfer spead was like 120MBytes/s. Quite small difference beetwen 1Gbit and 10Gbit NICs. The CPU usage for 10Gbit NICs during the transfer was very high. The iperf3 test delivered nearly 10Gbit/s (FreeBSD and Linux). # Fiber 10Gbit/s 02:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01) 02:00.1 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01) # Fiber 1Gbit/s 04:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (rev 12) # Copper 1Gbit/s 06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection I will have a look if I can get 10Gbit NICs from another maker and rerun the performance test on OpenBSD 6.4 again. Probably I will upgrade my few years old hardware (Xeon(R) CPU E31270 @ 3.40GHz, with 32GB ECC DDR RAM and Samsung 860 pro SSD) to something like current AMD Ryzen Threadripper, DDR RAM and Optane SSD. In case I could help with 10Gbit/s network performance tests for OpenBSD 6.5 please let me know. Kind regards Mark -- m...@it-infrastrukturen.org Am 11.04.2019 15:19, schrieb Karel Gardas: On 4/9/19 6:56 PM, Mark Schneider wrote: Hi Peter Thank you very much for your feedback. It looks like the performance issue is more complex than I have expected. Just for the test I have installed OpenBSD 6.4 and FreeBSD 13.0 on few different servers and compared results (details are in attached files). I'm afraid you have installed FBSD 13.0 current which does have a lot of debugging code and invariants checking built in and which can't be used for any sensible performance evaluations. If you are curious about FBSD performance, then please install latest stable release. Cheers, Karel -- m...@it-infrastrukturen.org
Answer 6 - ix network driver from FreeBSD 13.0 / Re: 10GBit network performance on OpenBSD 6.4
Hi Stuart Thank you very much for the link. The total ssh based performace depends strongly on the server hardware (and installed OSes). For the "fastest" test configuration (server hardware / installed OS) I was possible to achieve a total trasfer speed of approx 400MBytes/s (on the 10Gbit fiber link) for few parallel read/write scp sessions. I don't know if the ix network drivers used in FreeBSD 13.0 orLinux kernel are much more efficient and it is possible to use the ix network driver from FreeBSD 13.0 in OpenBSD 6.4. # --- # fbsdsrv1 kernel: CPU: Intel(R) Xeon(R) CPU X5690 @ 3.47GHz (3465.76-MHz K8-class CPU) # fbsdsrv1 kernel: FreeBSD/SMP: Multiprocessor System Detected: 24 CPUs # fbsdsrv1 kernel: real memory = 103079215104 (98304 MB) # fbsdsrv1 kernel: da0: Fixed Direct Access SPC-3 SCSI device # fbsdsrv1 kernel: da0: Serial Number PACCRCN80ZL1RD7 # fbsdsrv1 kernel: da0: 135.168MB/s transfers # fbsdsrv1 kernel: da0: Command Queueing enabled # fbsdsrv1 kernel: da0: 839893MB (1720102192 512 byte sectors) # fbsdsrv1 kernel: ix0: port 0x7000-0x701f mem 0xe9a8-0xe9af,0xe9a7-0xe9a73fff irq 26 # at device 0.0 on pci6 # fbsdsrv1 kernel: ix0: Using 2048 tx descriptors and 2048 rx descriptors # fbsdsrv1 kernel: ix0: queue equality override not set, capping rx_queues at 12 and tx_queues at 12 # fbsdsrv1 kernel: ix0: Using 12 rx queues 12 tx queues # fbsdsrv1 kernel: ix0: Using MSI-X interrupts with 13 vectors # fbsdsrv1 kernel: ix0: allocated for 12 queues # fbsdsrv1 kernel: ix0: allocated for 12 rx queues # fbsdsrv1 kernel: ix0: Ethernet address: 90:e2:ba:16:20:a4 # fbsdsrv1 kernel: ix0: PCI Express Bus: Speed 5.0GT/s Width x4 # fbsdsrv1 kernel: ix0: netmap queues/slots: TX 12/2048, RX 12/2048 # fbsdsrv1 kernel: ix1: port 0x7020-0x703f mem 0xe998-0xe99f,0xe997-0xe9973fff irq 25 # at device 0.1 on pci6 # fbsdsrv1 kernel: ix1: Using 2048 tx descriptors and 2048 rx descriptors # fbsdsrv1 kernel: ix1: queue equality override not set, capping rx_queues at 12 and tx_queues at 12 # fbsdsrv1 kernel: ix1: Using 12 rx queues 12 tx queues # fbsdsrv1 kernel: ix1: Using MSI-X interrupts with 13 vectors # fbsdsrv1 kernel: ix1: allocated for 12 queues # fbsdsrv1 kernel: ix1: allocated for 12 rx queues # fbsdsrv1 kernel: ix1: Ethernet address: 90:e2:ba:16:20:a5 # fbsdsrv1 kernel: ix1: PCI Express Bus: Speed 5.0GT/s Width x4 # fbsdsrv1 kernel: ix1: netmap queues/slots: TX 12/2048, RX 12/2048 # --- ironm@fbsdsrv1:~ $ scp t1.iso ironm@200.0.0.20:/home/ironm/fbsd2fbs-send-conf1.iso Password for ironm@fbsdsrv2: t1.iso 100% 3626MB 132.0MB/s 00:27 Kind regards Mark -- m...@it-infrastrukturen.org Am 09.04.2019 13:31, schrieb Stuart Henderson: On 2019-04-07, Mark Schneider wrote: Short feedback: Just for the test I have checked the 10GBit network performance between two FreeBSD 13.0 servers (both HP DL380g7 machines) transfering data in both directions # --- ironm@fbsdsrv2:~ $ scp ironm@200.0.0.10:/home/ironm/t2.iso t100.iso Password for ironm@fbsdsrv1: t2.iso 100% 3626MB 130.2MB/s 00:27 # --- ironm@fbsdsrv2:~ $ scp obsd2fbsd.iso ironm@200.0.0.10:/home/ironm/t1.iso Password for ironm@fbsdsrv1: obsd2fbsd.iso 100% 3626MB 140.4MB/s 00:25 # --- scp is a *terrible* way to test network performance. If you are only interested in scp performance between two hosts then it's relevant, and you can probably improve speeds by using something other than scp. Otherwise irrelevant. The ssh performance using 10GBit network connection on FreeBSD 13.0 is approx 7 times higher than the one on OpenBSD 6.4. Is it the question of the "ix" NIC driver of OpenBSD 6.4? (X520-DA2 NICs from Intel) Does one of you achieve good 10Gbit network performance with other 10Gbit NICs? FreeBSD's network stack can make better use of multiple processors. OpenBSD is improving (you can read some stories about this work at www.grenadille.net) but is slower. Jumbo frames should help if you can use them. Much of network performance is related to packets-per-second not bits-per-second. For scp, switching ciphers/MACs is likely to speed things up too.
Answer 5 / Re: 10GBit network performance on OpenBSD 6.4
Am 08.04.2019 23:46, schrieb Anatoli: Thank you very much for the idea Anatoli! Running dd with "/dev/zero" and "/dev/null" gave me back a very good overview what is going on (different server hardware and operating systems) ironm@wheezy:~$ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4294967296 Bytes (4.3 GB) kopiert, 1.0029 s, 4.3 GB/s -- ironm@fbsdsrv8:~ $ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4294967296 bytes transferred in 8.432852 secs (509313755 bytes/sec) -- ironm@fbsdsrv1:~ $ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4294967296 bytes transferred in 5.947370 secs (722162508 bytes/sec) -- ironm@fbsdsrv2:~ $ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4294967296 bytes transferred in 8.804378 secs (487821753 bytes/sec) -- ronm@wheezy:~$ time dd if=file1.tmp of=/dev/null bs=1M count=4096 && sync 4294967296 Bytes (4.3 GB) kopiert, 0.410687 s, 10.5 GB/s -- ironm@wheezy:~$ time dd if=file1.tmp of=/dev/null bs=1M count=512 && sync 536870912 Bytes (537 MB) kopiert, 0.0558006 s, 9.6 GB/s -- ironm@fbsdsrv8:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=4096 && sync 4294967296 bytes transferred in 1.338350 secs (3209151777 bytes/sec) -- ironm@fbsdsrv8:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=512 && sync 536870912 bytes transferred in 0.167219 secs (3210581655 bytes/sec) -- ironm@fbsdsrv1:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=4096 && sync 4294967296 bytes transferred in 1.173098 secs (3661217181 bytes/sec) -- ironm@fbsdsrv1:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=512 && sync 536870912 bytes transferred in 0.191353 secs (2805662938 bytes/sec) -- ironm@fbsdsrv2:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=4096 && sync 4294967296 bytes transferred in 1.159899 secs (3702879890 bytes/sec) -- ironm@fbsdsrv2:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=512 && sync 536870912 bytes transferred in 0.213278 secs (2517231248 bytes/sec) -- obsdsrv2$ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4294967296 bytes transferred in 9.136 secs (470078173 bytes/sec) -- obsdsrv2$ time dd if=file1.tmp of=/dev/null bs=1M count=4096 && sync 4294967296 bytes transferred in 11.280 secs (380734881 bytes/sec) -- obsdsrv2$ time dd if=file1.tmp of=/dev/null bs=1M count=4096 && sync 4294967296 bytes transferred in 10.167 secs (422400700 bytes/sec) -- obsdsrv2$ time dd if=file1.tmp of=/dev/null bs=1M count=2048 && sync 2147483648 bytes transferred in 4.515 secs (475551520 bytes/sec) -- obsdsrv2$ time dd if=file1.tmp of=/dev/null bs=1M count=1024 && sync 1073741824 bytes transferred in 1.728 secs (621203080 bytes/sec) -- obsdsrv2$ time dd if=file1.tmp of=/dev/null bs=1M count=512 && sync 536870912 bytes transferred in 0.265 secs (2021821094 bytes/sec) Kind regards Mark -- m...@it-infrastrukturen.org ironm@wheezy:~$ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4096+0 Datensätze ein 4096+0 Datensätze aus 4294967296 Bytes (4.3 GB) kopiert, 1.0029 s, 4.3 GB/s real0m1.231s user0m0.000s sys 0m1.224s --- ironm@fbsdsrv8:~ $ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 8.432852 secs (509313755 bytes/sec) 8.79 real 0.01 user 3.36 sys --- ironm@fbsdsrv1:~ $ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 5.947370 secs (722162508 bytes/sec) 6.41 real 0.00 user 4.65 --- ironm@fbsdsrv2:~ $ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 8.804378 secs (487821753 bytes/sec) 9.26 real 0.00 user 4.94 sys ronm@wheezy:~$ time dd if=file1.tmp of=/dev/null bs=1M count=4096 && sync 4096+0 Datensätze ein 4096+0 Datensätze aus 4294967296 Bytes (4.3 GB) kopiert, 0.410687 s, 10.5 GB/s real0m0.412s user0m0.000s sys 0m0.408s ironm@wheezy:~$ time dd if=file1.tmp of=/dev/null bs=1M count=512 && sync 512+0 Datensätze ein 512+0 Datensätze aus 536870912 Bytes (537 MB) kopiert, 0.0558006 s, 9.6 GB/s real0m0.057s user0m0.000s sys 0m0.056s --- ironm@fbsdsrv8:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=4096 && sync 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 1.338350 secs (3209151777 bytes/sec) 1.34 real 0.00 user 1.34 sys ironm@fbsdsrv8:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=512 && sync 512+0 records in 512+0 records out 536870912 bytes transferred in 0.167219 secs (3210581655 bytes/sec) 0
Answer 4 / Re: 10GBit network performance on OpenBSD 6.4
Hi > Whats your performance without scp? tcpbench / netcat, for example? Thank you very much for your hint. I did not run them yet (only iperf3 as listed below) Further test details are in attached files. Kind regards Mark -- m...@it-infrastrukturen.org Am 08.04.2019 22:06, schrieb Abel Abraham Camarillo Ojeda: On Sun, Apr 7, 2019 at 5:21 PM Mark Schneider wrote: Short feedback: Just for the test I have checked the 10GBit network performance between two FreeBSD 13.0 servers (both HP DL380g7 machines) transfering data in both directions # --- ironm@fbsdsrv2:~ $ scp ironm@200.0.0.10:/home/ironm/t2.iso t100.iso Password for ironm@fbsdsrv1: t2.iso 100% 3626MB 130.2MB/s 00:27 # --- ironm@fbsdsrv2:~ $ scp obsd2fbsd.iso ironm@200.0.0.10:/home/ironm/t1.iso Password for ironm@fbsdsrv1: obsd2fbsd.iso 100% 3626MB 140.4MB/s 00:25 # --- The ssh performance using 10GBit network connection on FreeBSD 13.0 is approx 7 times higher than the one on OpenBSD 6.4. Is it the question of the "ix" NIC driver of OpenBSD 6.4? (X520-DA2 NICs from Intel) Does one of you achieve good 10Gbit network performance with other 10Gbit NICs? Thank you in advance for your hints. Kind regards Mark -- m...@it-infrastrukturen.org Am 06.04.2019 22:52, schrieb Mark Schneider: Hi, Please allow me few questions regarding 10GBit network performance on OpenBSD 6.4. I face quite low network performance for the Intell X520-DA2 10GBit network card. Test configuration in OpenBSD-Linux-10GBit_net_performance.txt - http://paste.debian.net/1076461/ Low transfer rate for scp - OpenBSD-10GBit-perftest.txt - http://paste.debian.net/1076460/ Test configuration: # --- # OpenBSD 6.4 on HP DL380g7 # - # 10GBit X520-DA2 NIC ix0: flags=208843 mtu 1500 media: Ethernet autoselect (10GbaseSR full-duplex,rxpause,txpause) inet6 fe80::d51e:1b74:17d7:8230%ix0 prefixlen 64 scopeid 0x1 inet 200.0.0.3 netmask 0xff00 broadcast 200.0.0.255 ix1: flags=208843 mtu 1500 media: Ethernet autoselect (10GbaseSR full-duplex,rxpause,txpause) inet 10.0.0.7 netmask 0xff00 broadcast 10.0.0.255 inet6 fe80::b488:caea:5d6f:9992%ix1 prefixlen 64 scopeid 0x2 # --- Compare to Linux the 10GBit transfer from/to OpenBSD is few times slower: # --- # OpenBSD to Linux (Asus P8BWS) # - srvob# iperf3 -c 10.0.0.2 ... - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 1.50 GBytes 1.29 Gbits/sec sender [ 5] 0.00-10.20 sec 1.50 GBytes 1.27 Gbits/sec receiver # --- # --- # Linux (DL380g7) to Linux (Asus P8BWS) # - root@kali:~# iperf3 -c 100.0.0.2 ... - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 10.9 GBytes 9.39 Gbits/sec 328 sender [ 5] 0.00-10.04 sec 10.9 GBytes 9.35 Gbits/sec receiver # --- The scp transfer rate is like 21MBytes/s only per ssh connection (OpenBSD <-> Linux): # --- root@kali:~# scp /re*/b*/ka*/kali-linux-kde-2019.1a-*.iso ironm@10.0.0.7:/home/ironm/t12.iso ironm@10.0.0.7's password: kali-linux-kde-2019.1a-amd64.iso 4% 173MB 21.5MB/s 02:40 ETA # --- The 1GBit cooper based NIC works also slower but reaching almost 40% of the max trasfer rate of 1 Gbit: # --- # OpenBSD 6.4 (DL380g7 1Gbit NIC) to Linux (DL380g7 1GBit NIC) # srvob# iperf3 -c 170.0.0.10 ... - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 471 MBytes 395 Mbits/sec sender [ 5] 0.00-10.20 sec 471 MBytes 388 Mbits/sec receiver # --- # --- # Linux (Asus P8BWS) to Linux (DL380g7) # - root@kali:~# iperf3 -c 192.168.1.122 ... - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec 183 sender [ 5] 0.00-10.04 sec 1.09 GBytes 934 Mbits/sec receiver # --- Thank you in advance for your hints what OpenBSD 6.4 settings do I miss. Best regards Mark Whats your performance without scp? tcpbench / netcat, for example? ironm@wheezy:~$ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4096+0 Datensätze ein 4096+0 Datensätze aus 4294967296 Bytes (4.3 GB) kopiert, 1.0029 s, 4.3 GB/s real0m1.231s user0m0.000s sys 0m1.224s --- ironm@fbsdsrv8:~ $ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 8.432852 secs (509313755 bytes/sec) 8.79 real 0.01 user 3.36 sys --- ironm@fbsdsrv1:~ $ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 &&
Answer 3 / Re: 10GBit network performance on OpenBSD 6.4
Hi Anatoly Thank you very much for your helpfull hints. The CPU usage (one of available cores) was nearly 100%. FreeBSD 13.0 and Linux (Debian) seem currently to have faster network stacks (and faster mass storage handling). During test I used debian linux running in live mode (transfer to DDR3 memory instead of RAID or SSD) Just for the test I have installed OpenBSD 6.4 and FreeBSD 13.0 on few different servers (with 6G/15k SAS drives RAID or Pro 860 SATA3 SSDs) and compared results (details are in attached files). I have got some further hints from the misc list to run tests usinf "/dev/null" so I will try repeat few tests. More details are in attached files. Kind regards Mark Am 08.04.2019 19:30, schrieb Anatoli: Hi, I guess you're hitting 2 bottlenecks: the CPU performance for iperf and HDD performance for scp. Check how much CPU is consumed during iperf transfer and try scp'ing something not from/to HDD, e.g. /dev/zero. I've seen extremely slow HDD performance in OpenBSD, like 12x slower than on Linux, also no filesystem cache, so depending on your HDD with scp you may be hitting the max throughput for the FS, not the network. Regards, Anatoli *From:* Mark Schneider *Sent:* Saturday, April 06, 2019 17:52 *To:* Misc *Subject:* 10GBit network performance on OpenBSD 6.4 Hi, Please allow me few questions regarding 10GBit network performance on OpenBSD 6.4. I face quite low network performance for the Intell X520-DA2 10GBit network card. Test configuration in OpenBSD-Linux-10GBit_net_performance.txt - http://paste.debian.net/1076461/ Low transfer rate for scp - OpenBSD-10GBit-perftest.txt - http://paste.debian.net/1076460/ Test configuration: # --- # OpenBSD 6.4 on HP DL380g7 # - # 10GBit X520-DA2 NIC ix0: flags=208843 mtu 1500 media: Ethernet autoselect (10GbaseSR full-duplex,rxpause,txpause) inet6 fe80::d51e:1b74:17d7:8230%ix0 prefixlen 64 scopeid 0x1 inet 200.0.0.3 netmask 0xff00 broadcast 200.0.0.255 ix1: flags=208843 mtu 1500 media: Ethernet autoselect (10GbaseSR full-duplex,rxpause,txpause) inet 10.0.0.7 netmask 0xff00 broadcast 10.0.0.255 inet6 fe80::b488:caea:5d6f:9992%ix1 prefixlen 64 scopeid 0x2 # --- Compare to Linux the 10GBit transfer from/to OpenBSD is few times slower: # --- # OpenBSD to Linux (Asus P8BWS) # - srvob# iperf3 -c 10.0.0.2 ... - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 1.50 GBytes 1.29 Gbits/sec sender [ 5] 0.00-10.20 sec 1.50 GBytes 1.27 Gbits/sec receiver # --- # --- # Linux (DL380g7) to Linux (Asus P8BWS) # - root@kali:~# iperf3 -c 100.0.0.2 ... - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 10.9 GBytes 9.39 Gbits/sec 328 sender [ 5] 0.00-10.04 sec 10.9 GBytes 9.35 Gbits/sec receiver # --- The scp transfer rate is like 21MBytes/s only per ssh connection (OpenBSD <-> Linux): # --- root@kali:~# scp /re*/b*/ka*/kali-linux-kde-2019.1a-*.iso ironm@10.0.0.7:/home/ironm/t12.iso ironm@10.0.0.7's password: kali-linux-kde-2019.1a-amd64.iso 4% 173MB 21.5MB/s 02:40 ETA # --- The 1GBit cooper based NIC works also slower but reaching almost 40% of the max trasfer rate of 1 Gbit: # --- # OpenBSD 6.4 (DL380g7 1Gbit NIC) to Linux (DL380g7 1GBit NIC) # srvob# iperf3 -c 170.0.0.10 ... - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 471 MBytes 395 Mbits/sec sender [ 5] 0.00-10.20 sec 471 MBytes 388 Mbits/sec receiver # --- # --- # Linux (Asus P8BWS) to Linux (DL380g7) # - root@kali:~# iperf3 -c 192.168.1.122 ... - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec 183 sender [ 5] 0.00-10.04 sec 1.09 GBytes 934 Mbits/sec receiver # --- Thank you in advance for your hints what OpenBSD 6.4 settings do I miss. Best regards Mark ironm@wheezy:~$ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4096+0 Datensätze ein 4096+0 Datensätze aus 4294967296 Bytes (4.3 GB) kopiert, 1.0029 s, 4.3 GB/s real0m1.231s user0m0.000s sys 0m1.224s --- ironm@fbsdsrv8:~ $ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 8.432852 secs (509313755 bytes/sec) 8.79 real 0.01 user 3.36 sys --- ironm@fbsdsrv1:~ $ time dd if=/d
Answer 2 / Re: 10GBit network performance on OpenBSD 6.4
Hi Peter Thank you very much for your feedback. It looks like the performance issue is more complex than I have expected. Just for the test I have installed OpenBSD 6.4 and FreeBSD 13.0 on few different servers and compared results (details are in attached files). Pure network speed I have to test with sucht tools like tcpbench, iperf3 or netperf to get independent of the mass storage stuff and other things. Kind regards Mark -- m...@it-infrastrukturen.org Am 08.04.2019 05:12, schrieb Peter Membrey: Hi Mark, I saw very similar performance issues on my system as well. The card was an Intel X550-10 dual port on an Atom C2750 box (8 core but low power). I've never had great TCP performance from OpenBSD on this box, but routing traffic through it had always been fine. Upgrading to 10Gb/s though I found I couldn't get much more than the speeds you were seeing. As the OS was due for an upgrade anyway, I tried it with Linux, and was immediately about to hit 9.8Gb/s. Since I'm also quite comfortable using Linux, I left it in place (it's a key router for me) and it's been working great ever since. I'm afraid I can't add much to help you apart from a "me too" but at least it rules out it being an issue with your particular hardware. Kind Regards, Peter Membrey - Original Message ----- From: "Mark Schneider" To: "misc" Sent: Monday, 8 April, 2019 06:09:09 Subject: Re: 10GBit network performance on OpenBSD 6.4 Short feedback: Just for the test I have checked the 10GBit network performance between two FreeBSD 13.0 servers (both HP DL380g7 machines) transfering data in both directions # --- ironm@fbsdsrv2:~ $ scp ironm@200.0.0.10:/home/ironm/t2.iso t100.iso Password for ironm@fbsdsrv1: t2.iso 100% 3626MB 130.2MB/s 00:27 # --- ironm@fbsdsrv2:~ $ scp obsd2fbsd.iso ironm@200.0.0.10:/home/ironm/t1.iso Password for ironm@fbsdsrv1: obsd2fbsd.iso 100% 3626MB 140.4MB/s 00:25 # --- The ssh performance using 10GBit network connection on FreeBSD 13.0 is approx 7 times higher than the one on OpenBSD 6.4. Is it the question of the "ix" NIC driver of OpenBSD 6.4? (X520-DA2 NICs from Intel) Does one of you achieve good 10Gbit network performance with other 10Gbit NICs? Thank you in advance for your hints. Kind regards Mark ironm@wheezy:~$ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4096+0 Datensätze ein 4096+0 Datensätze aus 4294967296 Bytes (4.3 GB) kopiert, 1.0029 s, 4.3 GB/s real0m1.231s user0m0.000s sys 0m1.224s --- ironm@fbsdsrv8:~ $ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 8.432852 secs (509313755 bytes/sec) 8.79 real 0.01 user 3.36 sys --- ironm@fbsdsrv1:~ $ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 5.947370 secs (722162508 bytes/sec) 6.41 real 0.00 user 4.65 --- ironm@fbsdsrv2:~ $ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 8.804378 secs (487821753 bytes/sec) 9.26 real 0.00 user 4.94 sys ronm@wheezy:~$ time dd if=file1.tmp of=/dev/null bs=1M count=4096 && sync 4096+0 Datensätze ein 4096+0 Datensätze aus 4294967296 Bytes (4.3 GB) kopiert, 0.410687 s, 10.5 GB/s real0m0.412s user0m0.000s sys 0m0.408s ironm@wheezy:~$ time dd if=file1.tmp of=/dev/null bs=1M count=512 && sync 512+0 Datensätze ein 512+0 Datensätze aus 536870912 Bytes (537 MB) kopiert, 0.0558006 s, 9.6 GB/s real0m0.057s user0m0.000s sys 0m0.056s --- ironm@fbsdsrv8:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=4096 && sync 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 1.338350 secs (3209151777 bytes/sec) 1.34 real 0.00 user 1.34 sys ironm@fbsdsrv8:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=512 && sync 512+0 records in 512+0 records out 536870912 bytes transferred in 0.167219 secs (3210581655 bytes/sec) 0.17 real 0.00 user 0.17 sys --- ironm@fbsdsrv1:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=4096 && sync 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 1.173098 secs (3661217181 bytes/sec) 1.17 real 0.00 user 1.17 sys ironm@fbsdsrv1:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=512 && sync 512+0 records in 512+0 records out 536870912 bytes transferred in 0.191353 secs (2805662938 bytes/sec) 0.19 real 0.00 user 0.18 sys --- ironm@fbsdsrv2:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=4096 &&
Re: 10GBit network performance on OpenBSD 6.4
Hello Tom Thank you very much for your hint. I have disabled pf with "pfctrl -d" command but didn't notice any difference in the 10GBit transfer speed. The CPU usage was high (like 100% for one of the available CPU cores) # Single send obsdsrv2$ scp 4GByte-random.bin ironm@10.0.0.2:/home/ironm/send4GByte-v1.bin 4GByte-random.bin89% 3665MB 71.0MB/s 00:06 ETA --- # Send and receive at once (two scp connections) obsdsrv2$ scp 4GByte-random.bin ironm@10.0.0.2:/home/ironm/send4GByte-v1.bin 4GByte-random.bin50% 2050MB 47.7MB/s 00:42 ETA obsdsrv2$ scp ironm@10.0.0.2:/home/ironm/4GByte-random.bin receive4GByte-v1.bin 4GByte-random.bin 68% 2814MB 50.8MB/s 00:25 ETA Details of the test are in the attached file: obsd2obsd-send_conf_AMD_FX_4100_to_Xeon-E31270-10gbit-NICs-SSD_cpu-load-top.txt Kind regards Mark -- m...@it-infrastrukturen.org Am 08.04.2019 00:20, schrieb Tom Smyth: Hello if you disable pf you should get alot higher speeds, as PF uses 1 CPU alternatively you can enable experimental pf code that uses more than one CPU On Sun, 7 Apr 2019 at 23:15, Mark Schneider wrote: Short feedback: Just for the test I have checked the 10GBit network performance between two FreeBSD 13.0 servers (both HP DL380g7 machines) transfering data in both directions # --- ironm@fbsdsrv2:~ $ scp ironm@200.0.0.10:/home/ironm/t2.iso t100.iso Password for ironm@fbsdsrv1: t2.iso 100% 3626MB 130.2MB/s 00:27 # --- ironm@fbsdsrv2:~ $ scp obsd2fbsd.iso ironm@200.0.0.10:/home/ironm/t1.iso Password for ironm@fbsdsrv1: obsd2fbsd.iso 100% 3626MB 140.4MB/s 00:25 # --- The ssh performance using 10GBit network connection on FreeBSD 13.0 is approx 7 times higher than the one on OpenBSD 6.4. Is it the question of the "ix" NIC driver of OpenBSD 6.4? (X520-DA2 NICs from Intel) Does one of you achieve good 10Gbit network performance with other 10Gbit NICs? Thank you in advance for your hints. Kind regards Mark -- m...@it-infrastrukturen.org Am 06.04.2019 22:52, schrieb Mark Schneider: Hi, Please allow me few questions regarding 10GBit network performance on OpenBSD 6.4. I face quite low network performance for the Intell X520-DA2 10GBit network card. Test configuration in OpenBSD-Linux-10GBit_net_performance.txt - http://paste.debian.net/1076461/ Low transfer rate for scp - OpenBSD-10GBit-perftest.txt - http://paste.debian.net/1076460/ Test configuration: # --- # OpenBSD 6.4 on HP DL380g7 # - # 10GBit X520-DA2 NIC ix0: flags=208843 mtu 1500 media: Ethernet autoselect (10GbaseSR full-duplex,rxpause,txpause) inet6 fe80::d51e:1b74:17d7:8230%ix0 prefixlen 64 scopeid 0x1 inet 200.0.0.3 netmask 0xff00 broadcast 200.0.0.255 ix1: flags=208843 mtu 1500 media: Ethernet autoselect (10GbaseSR full-duplex,rxpause,txpause) inet 10.0.0.7 netmask 0xff00 broadcast 10.0.0.255 inet6 fe80::b488:caea:5d6f:9992%ix1 prefixlen 64 scopeid 0x2 # --- Compare to Linux the 10GBit transfer from/to OpenBSD is few times slower: # --- # OpenBSD to Linux (Asus P8BWS) # - srvob# iperf3 -c 10.0.0.2 ... - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 1.50 GBytes 1.29 Gbits/sec sender [ 5] 0.00-10.20 sec 1.50 GBytes 1.27 Gbits/sec receiver # --- # --- # Linux (DL380g7) to Linux (Asus P8BWS) # - root@kali:~# iperf3 -c 100.0.0.2 ... - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 10.9 GBytes 9.39 Gbits/sec 328 sender [ 5] 0.00-10.04 sec 10.9 GBytes 9.35 Gbits/sec receiver # --- The scp transfer rate is like 21MBytes/s only per ssh connection (OpenBSD <-> Linux): # --- root@kali:~# scp /re*/b*/ka*/kali-linux-kde-2019.1a-*.iso ironm@10.0.0.7:/home/ironm/t12.iso ironm@10.0.0.7's password: kali-linux-kde-2019.1a-amd64.iso 4% 173MB 21.5MB/s 02:40 ETA # --- The 1GBit cooper based NIC works also slower but reaching almost 40% of the max trasfer rate of 1 Gbit: # --- # OpenBSD 6.4 (DL380g7 1Gbit NIC) to Linux (DL380g7 1GBit NIC) # srvob# iperf3 -c 170.0.0.10 ... - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 471 MBytes 395 Mbits/sec sender [ 5] 0.00-10.20 sec 471 MBytes 388 Mbits/sec receiver # --- # --- # Linux (Asus P8BWS) to Linux (DL380g7) # - root@kali:~# iperf3 -c 192.168.1.122 ... - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.09 GBytes 939 Mbits/s
Re: 10GBit network performance on OpenBSD 6.4
Short feedback: Just for the test I have checked the 10GBit network performance between two FreeBSD 13.0 servers (both HP DL380g7 machines) transfering data in both directions # --- ironm@fbsdsrv2:~ $ scp ironm@200.0.0.10:/home/ironm/t2.iso t100.iso Password for ironm@fbsdsrv1: t2.iso 100% 3626MB 130.2MB/s 00:27 # --- ironm@fbsdsrv2:~ $ scp obsd2fbsd.iso ironm@200.0.0.10:/home/ironm/t1.iso Password for ironm@fbsdsrv1: obsd2fbsd.iso 100% 3626MB 140.4MB/s 00:25 # --- The ssh performance using 10GBit network connection on FreeBSD 13.0 is approx 7 times higher than the one on OpenBSD 6.4. Is it the question of the "ix" NIC driver of OpenBSD 6.4? (X520-DA2 NICs from Intel) Does one of you achieve good 10Gbit network performance with other 10Gbit NICs? Thank you in advance for your hints. Kind regards Mark -- m...@it-infrastrukturen.org Am 06.04.2019 22:52, schrieb Mark Schneider: Hi, Please allow me few questions regarding 10GBit network performance on OpenBSD 6.4. I face quite low network performance for the Intell X520-DA2 10GBit network card. Test configuration in OpenBSD-Linux-10GBit_net_performance.txt - http://paste.debian.net/1076461/ Low transfer rate for scp - OpenBSD-10GBit-perftest.txt - http://paste.debian.net/1076460/ Test configuration: # --- # OpenBSD 6.4 on HP DL380g7 # - # 10GBit X520-DA2 NIC ix0: flags=208843 mtu 1500 media: Ethernet autoselect (10GbaseSR full-duplex,rxpause,txpause) inet6 fe80::d51e:1b74:17d7:8230%ix0 prefixlen 64 scopeid 0x1 inet 200.0.0.3 netmask 0xff00 broadcast 200.0.0.255 ix1: flags=208843 mtu 1500 media: Ethernet autoselect (10GbaseSR full-duplex,rxpause,txpause) inet 10.0.0.7 netmask 0xff00 broadcast 10.0.0.255 inet6 fe80::b488:caea:5d6f:9992%ix1 prefixlen 64 scopeid 0x2 # --- Compare to Linux the 10GBit transfer from/to OpenBSD is few times slower: # --- # OpenBSD to Linux (Asus P8BWS) # - srvob# iperf3 -c 10.0.0.2 ... - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 1.50 GBytes 1.29 Gbits/sec sender [ 5] 0.00-10.20 sec 1.50 GBytes 1.27 Gbits/sec receiver # --- # --- # Linux (DL380g7) to Linux (Asus P8BWS) # - root@kali:~# iperf3 -c 100.0.0.2 ... - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 10.9 GBytes 9.39 Gbits/sec 328 sender [ 5] 0.00-10.04 sec 10.9 GBytes 9.35 Gbits/sec receiver # --- The scp transfer rate is like 21MBytes/s only per ssh connection (OpenBSD <-> Linux): # --- root@kali:~# scp /re*/b*/ka*/kali-linux-kde-2019.1a-*.iso ironm@10.0.0.7:/home/ironm/t12.iso ironm@10.0.0.7's password: kali-linux-kde-2019.1a-amd64.iso 4% 173MB 21.5MB/s 02:40 ETA # --- The 1GBit cooper based NIC works also slower but reaching almost 40% of the max trasfer rate of 1 Gbit: # --- # OpenBSD 6.4 (DL380g7 1Gbit NIC) to Linux (DL380g7 1GBit NIC) # srvob# iperf3 -c 170.0.0.10 ... - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 471 MBytes 395 Mbits/sec sender [ 5] 0.00-10.20 sec 471 MBytes 388 Mbits/sec receiver # --- # --- # Linux (Asus P8BWS) to Linux (DL380g7) # - root@kali:~# iperf3 -c 192.168.1.122 ... - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec 183 sender [ 5] 0.00-10.04 sec 1.09 GBytes 934 Mbits/sec receiver # --- Thank you in advance for your hints what OpenBSD 6.4 settings do I miss. Best regards Mark
10GBit network performance on OpenBSD 6.4
Hi, Please allow me few questions regarding 10GBit network performance on OpenBSD 6.4. I face quite low network performance for the Intell X520-DA2 10GBit network card. Test configuration in OpenBSD-Linux-10GBit_net_performance.txt - http://paste.debian.net/1076461/ Low transfer rate for scp - OpenBSD-10GBit-perftest.txt - http://paste.debian.net/1076460/ Test configuration: # --- # OpenBSD 6.4 on HP DL380g7 # - # 10GBit X520-DA2 NIC ix0: flags=208843 mtu 1500 media: Ethernet autoselect (10GbaseSR full-duplex,rxpause,txpause) inet6 fe80::d51e:1b74:17d7:8230%ix0 prefixlen 64 scopeid 0x1 inet 200.0.0.3 netmask 0xff00 broadcast 200.0.0.255 ix1: flags=208843 mtu 1500 media: Ethernet autoselect (10GbaseSR full-duplex,rxpause,txpause) inet 10.0.0.7 netmask 0xff00 broadcast 10.0.0.255 inet6 fe80::b488:caea:5d6f:9992%ix1 prefixlen 64 scopeid 0x2 # --- Compare to Linux the 10GBit transfer from/to OpenBSD is few times slower: # --- # OpenBSD to Linux (Asus P8BWS) # - srvob# iperf3 -c 10.0.0.2 ... - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 1.50 GBytes 1.29 Gbits/sec sender [ 5] 0.00-10.20 sec 1.50 GBytes 1.27 Gbits/sec receiver # --- # --- # Linux (DL380g7) to Linux (Asus P8BWS) # - root@kali:~# iperf3 -c 100.0.0.2 ... - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 10.9 GBytes 9.39 Gbits/sec 328 sender [ 5] 0.00-10.04 sec 10.9 GBytes 9.35 Gbits/sec receiver # --- The scp transfer rate is like 21MBytes/s only per ssh connection (OpenBSD <-> Linux): # --- root@kali:~# scp /re*/b*/ka*/kali-linux-kde-2019.1a-*.iso ironm@10.0.0.7:/home/ironm/t12.iso ironm@10.0.0.7's password: kali-linux-kde-2019.1a-amd64.iso 4% 173MB 21.5MB/s 02:40 ETA # --- The 1GBit cooper based NIC works also slower but reaching almost 40% of the max trasfer rate of 1 Gbit: # --- # OpenBSD 6.4 (DL380g7 1Gbit NIC) to Linux (DL380g7 1GBit NIC) # srvob# iperf3 -c 170.0.0.10 ... - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 471 MBytes 395 Mbits/sec sender [ 5] 0.00-10.20 sec 471 MBytes 388 Mbits/sec receiver # --- # --- # Linux (Asus P8BWS) to Linux (DL380g7) # - root@kali:~# iperf3 -c 192.168.1.122 ... - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec 183 sender [ 5] 0.00-10.04 sec 1.09 GBytes 934 Mbits/sec receiver # --- Thank you in advance for your hints what OpenBSD 6.4 settings do I miss. Best regards Mark -- m...@it-infrastrukturen.org
Re: hacked for the second time
This seems relevant: https://blog.netspi.com/stealing-unencrypted-ssh-agent-keys-from-memory/ On Wed, Apr 3, 2019 at 2:33 PM R0me0 *** wrote: > you can block connections from tor, the ssh keys must be replaced and of > course, are you using a passphrase for them? > > Regards, > > > Em qua, 3 de abr de 2019 às 16:12, Zeb Packard > escreveu: > > > If you've got money go here: https://www.openbsd.org/support.html > > > > If you don't have money go ask here: http://daemonforums.org/ > > > > Generally, msp, isp, it requests don't go on this list. You've posted no > > evidence - a big no no. You need a high level of forensic verification > > before you bring this problem to the list. > > > > Good luck, > > > > Zeb > > > > On Wed, Apr 3, 2019 at 11:59 AM Cord wrote: > > > > > Hi, > > > I have some heavy suspect that my openbsd box was been hacked for the > > > second time in few weeks. The first time was been some weeks ago, I > have > > > got some suspects and after few checks I have found that someone was > been > > > connected to my vps via ssh on a non-standard port using my ssh key. > The > > > connection came from a tor exit node. There were been 2 connections and > > up > > > since 5 days. Now I have some other new suspects because some private > > email > > > seems knew from others. Also I have found other open sessions on the > web > > > gui of my email provider, but I am abolutely sure I have done the > logout > > > always. > > > I am using just chrome+unveil and I haven't used any other script or > > > opened pdf (maybe I have opened 1 or 2 pdf from inside of chrome). I > have > > > used epiphany *only* to open the webmail because chrome crash. My email > > > provider support html (obviously) but generally photo are not loaded. > > > Ofcourse I have pf enable and few service. > > > I also use a vpn and I visit very few web site with chrome.. maybe 20 > or > > > 25 website just to read news. Sometimes I search things about openbsd. > > > Anyone could help me ? > > > Cord. > > > > > > > > > > > > > > >
patch for Inseego/Novatel MiFi 8800L as urndis0
pointAddress=2-in bmAttributes=bulk wMaxPacketSize=1024 bInterval=0 Unknown descriptor (class 255/0): bLength=6 bDescriptorType=48 ... ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=1-out bmAttributes=bulk wMaxPacketSize=1024 bInterval=0 Unknown descriptor (class 255/0): bLength=6 bDescriptorType=48 ... INTERFACE descriptor 3: bLength=9 bDescriptorType=interface(4) bInterfaceNumber=3 bAlternateSetting=0 bNumEndpoints=2 bInterfaceClass=255 bInterfaceSubClass=255 bInterfaceProtocol=255 iInterface=0() ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=4-in bmAttributes=bulk wMaxPacketSize=1024 bInterval=0 Unknown descriptor (class 255/255): bLength=6 bDescriptorType=48 ... ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=2-out bmAttributes=bulk wMaxPacketSize=1024 bInterval=0 Unknown descriptor (class 255/255): bLength=6 bDescriptorType=48 ... INTERFACE descriptor 4: bLength=9 bDescriptorType=interface(4) bInterfaceNumber=4 bAlternateSetting=0 bNumEndpoints=2 bInterfaceClass=255 bInterfaceSubClass=66 bInterfaceProtocol=1 iInterface=10(ADB Interface) ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=3-out bmAttributes=bulk wMaxPacketSize=1024 bInterval=0 Unknown descriptor (class 255/66): bLength=6 bDescriptorType=48 ... ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=5-in bmAttributes=bulk wMaxPacketSize=1024 bInterval=0 Unknown descriptor (class 255/66): bLength=6 bDescriptorType=48 ... Unknown descriptor (class 255/66): bLength=8 bDescriptorType=11 ... INTERFACE descriptor 5: bLength=9 bDescriptorType=interface(4) bInterfaceNumber=12 bAlternateSetting=0 bNumEndpoints=1 bInterfaceClass=2 bInterfaceSubClass=2 bInterfaceProtocol=1 iInterface=11(CDC Abstract Control Model (ACM)) CDC INTERFACE descriptor: bLength=5 bDescriptorType=cs_interface(36) bDescriptorSubtype=header bcdCDC=1.10 CDC INTERFACE descriptor: bLength=5 bDescriptorType=cs_interface(36) bDescriptorSubtype=Call_Management bmCapabilities=0x0 bDataInterface=13 CDC INTERFACE descriptor: bLength=4 bDescriptorType=cs_interface(36) bDescriptorSubtype=Abstract_Control_Model bmCapabilities=0x2 CDC INTERFACE descriptor: bLength=5 bDescriptorType=cs_interface(36) bDescriptorSubtype=union bMasterInterface=12 bSlaveInterface0=13 ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=7-in bmAttributes=interrupt wMaxPacketSize=10 bInterval=9 Unknown descriptor (class 2/2): bLength=6 bDescriptorType=48 ... INTERFACE descriptor 6: bLength=9 bDescriptorType=interface(4) bInterfaceNumber=13 bAlternateSetting=0 bNumEndpoints=2 bInterfaceClass=10 bInterfaceSubClass=0 bInterfaceProtocol=0 iInterface=12(CDC ACM Data) ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=6-in bmAttributes=bulk wMaxPacketSize=1024 bInterval=0 Unknown descriptor (class 10/0): bLength=6 bDescriptorType=48 ... ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=4-out bmAttributes=bulk wMaxPacketSize=1024 bInterval=0 Unknown descriptor (class 10/0): bLength=6 bDescriptorType=48 ... INTERFACE descriptor 7: bLength=9 bDescriptorType=interface(4) bInterfaceNumber=14 bAlternateSetting=0 bNumEndpoints=1 bInterfaceClass=3 bInterfaceSubClass=0 bInterfaceProtocol=0 iInterface=15(HID Interface) HID descriptor: bLength=9 bDescriptorType=cs_device(33) bcdHID=1.01 bCountryCode=0 bNumDescriptors=1 bDescriptorType[0]=cs_config(34), wDescriptorLength[0]=34 -- Mark Nipper
smbd slow to start on -current
Folks, I'm running -current from 2019-02-11 (dmesg below) and seeing very slow start up with samba's smbd (4.8.7 version from ports). It appears to be a recurrence of the issue described here: https://groups.google.com/forum/#!topic/fa.openbsd.tech/yFTn1lyOQQI and here https://bugzilla.samba.org/show_bug.cgi?id=11355 The delay can be seen using this command: LD_DEBUG=1 smbd -D 2>&1 | ts %.s The key piece of output is here, showing a 55s delay after examining /usr/lib/libm.so.10.1: 1550056982.254470 linking dep /usr/local/lib/libgmp.so.10.0 as child of /usr/local/lib/libhogweed.so.2.0 1550056982.254539 examining: '/usr/local/lib/libgmp.so.10.0' 1550056982.254609 examining: '/usr/local/lib/libsasl2.so.3.1' 1550056982.254678 examining: '/usr/lib/libssl.so.47.3' 1550056982.254747 loading: libcrypto.so.45.3 required by /usr/lib/libssl.so.47.3 1550056982.254816 linking dep /usr/lib/libcrypto.so.45.3 as child of /usr/lib/libssl.so.47.3 1550056982.254886 examining: '/usr/lib/libm.so.10.1' 1550057037.791375 flags /usr/libexec/ld.so = 0x0 1550057037.791565 obj /usr/libexec/ld.so has smbd as head 1550057037.791672 static tls size=0 align=8 offset=0 1550057037.791894 protect RELRO [0x3a05766e000,0x3a05766f000) in /usr/lib/libm.so.10.1 1550057037.793600 protect RELRO [0x3a04047b000,0x3a04048) in /usr/lib/libssl.so.47.3 if I compile and link a program, that does nothing, with "_Wl,--as-needed" and the shared libs used by smbd, I see the same kind of delay on startup. Maybe the issue is with ld, but I'm not sure if I am using the --as-needed flag in the correct way. Thanks, -mark OpenBSD 6.4-current (GENERIC.MP) #706: Mon Feb 11 20:59:31 MST 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2129461248 (2030MB) avail mem = 2055290880 (1960MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (68 entries) bios0: vendor LENOVO version "7FET96WW (2.14 )" date 12/25/2006 bios0: LENOVO 0674KSG acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT SSDT SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB3(S3) USB7(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz, 1995.35 MHz, 06-0f-06 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 4MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 166MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz, 1995.01 MHz, 06-0f-06 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 4MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xf000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus 4 (EXP2) acpiprt5 at acpi0: bus 12 (EXP3) acpiprt6 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PUBS, resource for USB0, USB7 acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpicmos0 at acpi0 "IBM0071" at acpi0 not configured tpm0 at acpi0: TPM_ addr 0xfed4/0x1000: Atmel 97SC3203 rev 0x5 acpibat0 at acpi0: BAT0 model "92P1129" serial 1672 type LION oem "Panasonic" acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpidock0 at acpi0: GDCK not docked (0) acpivideo0 at acpi0: VID_ acpivout0 at acpivideo0: LCD0 acpivideo1 at acpi0: VID_ acpivout at acpivideo1 not configured cpu0: Enhanced SpeedStep 1995 MHz: speeds: 2000, 1667, 1333, 1000 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03 ppb0 at pci0 dev 1 function 0 "Intel 82945GM PCIE" rev 0x03: msi pci1 at ppb0 bus 1 radeondrm0 at pci1 dev 0 function 0 "ATI FireGL V5200" rev 0x00 drm0 at radeond
Cannot ping local IPv6 traffic on seperate lo1 interface
Hello everyone, I've set up another interface for local services, as I would like to have internal firewall rules. Using lo0 is problematic as it's what everything else uses. I can't, however, ping the IPv6 addresses I added: # ping6 ::2 PING ::2 (::2): 56 data bytes ^ this hangs So does this: # ping6 ::2 ::1 works fine: # ping6 ::1 PING ::1 (::1): 56 data bytes 64 bytes from ::1: icmp_seq=0 hlim=64 time=0.369 ms 64 bytes from ::1: icmp_seq=4 hlim=64 time=0.340 ms ^C --- ::1 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.180/0.362/0.481/0.104 ms Here is /etc/hostname.lo1: #inet 127.0.0.1 255.0.0.0 inet 127.0.0.2 255.0.0.0 inet alias 127.0.0.3 255.0.0.0 #inet6 ::1 128 inet6 ::2 128 inet6 alias ::3 128 pf.conf has nothing concerning lo1. Issue persists if pf is disabled. Here's ifconfig: lo0: flags=8049 mtu 32768 index 3 priority 0 llprio 3 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff00 vio0: flags=8843 mtu 1500 lladdr fa:16:3e:35:ba:80 index 1 priority 0 llprio 3 groups: egress media: Ethernet autoselect status: active inet 51.38.80.182 netmask 0xff00 broadcast 51.38.80.255 inet6 fe80::c4d0:8bc6:3c06:9c91%vio0 prefixlen 64 scopeid 0x1 inet6 2001:41d0:801:2000::cbb prefixlen 64 enc0: flags=0<> index 2 priority 0 llprio 3 groups: enc status: active lo1: flags=8049 mtu 32768 index 4 priority 0 llprio 3 groups: lo inet 127.0.0.2 netmask 0xff00 inet6 fe80::1%lo1 prefixlen 64 scopeid 0x4 inet6 ::2 prefixlen 128 inet6 ::3 prefixlen 128 pflog0: flags=141 mtu 33136 index 5 priority 0 llprio 3 groups: pflog Here's route -n show: Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default51.38.80.1 UGS 18 1416 - 8 vio0 224/4 127.0.0.1 URS00 32768 8 lo0 51.38.80/2451.38.80.182 UCn10 - 4 vio0 51.38.80.1 32:7a:6c:96:dc:ff UHLch 2 73 - 3 vio0 51.38.80.182 fa:16:3e:35:ba:80 UHLl 0 4100 - 1 vio0 51.38.80.255 51.38.80.182 UHb00 - 1 vio0 127/8 127.0.0.1 UGRS 00 32768 8 lo0 127.0.0.1 127.0.0.1 UHhl 47 6876 32768 1 lo0 127.0.0.2 127.0.0.2 UHl4 388 32768 1 lo1 127.0.0.3 127.0.0.3 UHl00 32768 1 lo1 185.16.85.134 51.38.80.1 UGHD 1 1382 - L 8 vio0 Internet6: DestinationGatewayFlags Refs Use Mtu Prio Iface default2001:41d0:801:2000::1 UGS 2 466 - 8 vio0 ::/96 ::1UGRS 02 32768 8 lo0 ::1::1UHhl 10 30 32768 1 lo0 ::2::2UHl 04 32768 1 lo1 ::3::3UHl 06 32768 1 lo1 :::0.0.0.0/96 ::1UGRS 00 32768 8 lo0 2001:41d0:801:2000::/642001:41d0:801:2000::cbbUCn 10 - 4 vio0 2001:41d0:801:2000::1 32:7a:6c:96:dc:ff UHLch 1 52 - 3 vio0 2001:41d0:801:2000::cbbfa:16:3e:35:ba:80 UHLl 0 474 - 1 vio0 2002::/24 ::1UGRS 00 32768 8 lo0 2002:7f00::/24 ::1UGRS 00 32768 8 lo0 2002:e000::/20 ::1UGRS 00 32768 8 lo0 2002:ff00::/24 ::1UGRS 00 32768 8 lo0 fe80::/10 ::1UGRS 02 32768 8 lo0 fec0::/10 ::1UGRS 00 32768 8 lo0 fe80::%vio0/64 fe80::c4d0:8bc6:3c06:9c91%vio0 UCn 12 - 4 vio0 fe80::307a:6cff:fe96:dcff%vio0 32:7a:6c:96:dc:ff UHLc 0 153 - 3 vio0 fe80::c4d0:8bc6:3c06:9c91%vio0 fa:16:3e:35:ba:80 UHLl 0 22 - 1 vio0 fe80::1%lo0fe80::1%lo0UHl 00 32768 1 lo0 fe80::1%lo1fe80::1%lo1UHl 00 32768 1 lo1
Re: pkg_add + httpd...high latency on 6.4
- http or https doesn't matter
- only pkg_add is affected, ftp download works
- reverting benno@'s change to
/src/usr.sbin/httpd/{httpd.h,server.c,server_http.c}
10 days ago makes pkg_add work normally again
On Wed, Oct 10, 2018 at 10:27:11PM +, Stuart Henderson wrote:
> On 2018-10-10, Mark Patruck wrote:
> > Hi,
> >
> > is anyone else seeing a high latency when running pkg_add with 6.4?
> >
> > - server with httpd (5 hours old 6.4)
> > - client running pkg_add (5 hours old 6.4)
> >
> > $ doas pkg_add -u
> >
> > nothing happens for ~60 seconds
> >
> > $ (done)
> >
> > Everything works normally, if
> >
> > - i replace httpd with nginx for testing
> > - pkg_add against httpd running on a 25 days old -current
> >
> >
> > -Mark
> >
>
> Can you figure out what's slow? Are plain fetches from that server
> using ftp(1) also slow or is it just with pkg_add?
>
> Is it using http or https? If https, is http any better?
>
> Is it possible to try building older httpd from source (e.g.
> "cd /usr/src/usr.sbin/httpd; cvs up -D 2018/09/15; make obj; make;
> doas make install") and see if the problem occurs there too? (i.e
> determine whether it's an httpd change or some other change that
> caused it).
>
>
--
Mark Patruck ( mark at wrapped.cx )
GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51
http://www.wrapped.cx
pkg_add + httpd...high latency on 6.4
Hi, is anyone else seeing a high latency when running pkg_add with 6.4? - server with httpd (5 hours old 6.4) - client running pkg_add (5 hours old 6.4) $ doas pkg_add -u nothing happens for ~60 seconds $ (done) Everything works normally, if - i replace httpd with nginx for testing - pkg_add against httpd running on a 25 days old -current -Mark -- Mark Patruck ( mark at wrapped.cx ) GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 http://www.wrapped.cx
Re: Downloadable CIDR network calculator
>From the link: IPV6: An Internet addressing protocol using 2128, less some stretches used for special things. IPV6 is not relevant to this document, nor is this document relevant to IPV6. > On 12 Sep 2018, at 1:28 am, Stuart Henderson wrote: > > On 2018-09-11, Steve Litt wrote: >> I've created a downloadable CIDR (Classless Inter-Domain Routing) >> network calculator, whose sole dependency is Python3. It runs in any >> terminal or terminal emulator on any Linux or presumably BSD machine. >> >> http://troubleshooters.com/linux/cidr_calc.htm > > Doesn't seem to work with the current version of IP .. > > $ python3 cidr_calc.py.txt 2a02:8011:7003:1:fab1:56ff:feac:3276/64 > > > IP address (2a02:8011:7003:1:fab1:56ff:feac:3276) not numeric. > USAGE: subnet_calc ipaddr/maskbits > EXAMPLE: subnet_calc 192.168.100.128/28 > > >
Re: iked[12345]: pfkey_reply: no reply from PF_KEY (-current)
Yes, a short test shows no errors anymore. On Mon, Sep 10, 2018 at 10:39:56AM -0300, Martin Pieuchot wrote: > On 10/09/18(Mon) 12:15, Mark Patruck wrote: > > I've tested with a current snapshot and two freshly installed systems > > and get the same error, but... > > > > reverting mpi@s 'Add per-TDB counters and a new SADB extension (1)' > > changes make the issues disappear. > > > > (1) https://marc.info/?l=openbsd-cvs=153546931106420=2 > > Does the smaller revert below also fix the issue? > > Index: net/pfkeyv2.c > === > RCS file: /cvs/src/sys/net/pfkeyv2.c,v > retrieving revision 1.191 > diff -u -p -r1.191 pfkeyv2.c > --- net/pfkeyv2.c 31 Aug 2018 12:55:46 - 1.191 > +++ net/pfkeyv2.c 10 Sep 2018 13:39:01 - > @@ -793,8 +793,7 @@ pfkeyv2_get(struct tdb *tdb, void **head > void *p; > > /* Find how much space we need */ > - i = sizeof(struct sadb_sa) + sizeof(struct sadb_lifetime) + > - sizeof(struct sadb_x_counter); > + i = sizeof(struct sadb_sa) + sizeof(struct sadb_lifetime); > > if (tdb->tdb_soft_allocations || tdb->tdb_soft_bytes || > tdb->tdb_soft_timeout || tdb->tdb_soft_first_use) > @@ -955,9 +954,6 @@ pfkeyv2_get(struct tdb *tdb, void **head > export_tap(, tdb); > } > #endif > - > - headers[SADB_X_EXT_COUNTER] = p; > - export_counter(, tdb); > > rval = 0; > > -- Mark Patruck ( mark at wrapped.cx ) GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 http://www.wrapped.cx
