Re: USB Printer Prebloms
On Tue, Mar 03, 2020 at 10:57:03PM -0700, Duncan Patton a Campbell wrote: > > I've had problems getting an old Brother printer to work (again) > and have managed to locate/understand? the source of the problems. > > 1. ulpt must be disabled: > # config -ef /bsd > ukc> disable ulpt > ukc> quit > > 2. modifying the kernel changes the kernel checksum so to get it to relink > sha256 -h /var/db/kernel.SHA256 /bsd > > 3. relinking the kernel _re-enables_ ulpt. > > So I'm going to have install the build system and run thru the kernel patches > after I figure out how to disable ulpt in the GENERIC.MP build. > > Does this sound like it will work? Pratical advice: Depending your need, you could also live without kernel relinking (KARL) in order to keep ulpt(4) disabled using config(8). I would still relink after an upgrade in order to have an unique /bsd (and not the one publicly available from internet). So it would be: - after an upgrade, reboot and wait relinking to be done (a fresh /bsd will be installed) - run `config -ef /bsd' and disable ulpt in the new (and unique) kernel - do *NOT* regenerate /var/db/kernel.SHA256 (so sha256 will mismatch) - reboot again and run on the new /bsd (with ulpt disabled) System will complains that relinking failed, but your /bsd with ulpt disabled will stay. Developer advice: mpi@ already pointed the right way to deal with it: make ulpt(4) and ugen(4) to coexist. This way you could use cupsd (using ugen) with a GENERIC kernel. see https://marc.info/?l=openbsd-tech=151618565000531=2 for details Thanks. -- Sebastien Marie
Re: Time jumping forward issue under OpenBSD 6.6 VMM
‐‐‐ Original Message ‐‐‐ On Tuesday, March 3, 2020 8:52 PM, Jordan Geoghegan wrote: > The clocks are basically broken on vmm. The pvclock stuff is definitely > an improvement, but it's still not there. There's still a ways to go > before we have proper, reasonably accurate clocks for vmm guests. Thanks Jordan for this info. For now I might just avoid VMM for time sensitive services and use bare metal with OpenBSD of course. I will for sure go back to VMM once the clock is more accurate.
octeon splassert: yield: want 0 have 1
hi i get often this message "splassert: yield: want 0 have 1" in my dmesg. did i have somthing to care ? my hardware ist an edgerouter 6p . holger Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2019 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.6-current (GENERIC.MP) #48: Tue Dec 10 16:30:01 MST 2019 dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP real mem = 1073741824 (1024MB) avail mem = 1020985344 (973MB) mainbus0 at root: board 20300 rev 1.20 cpu0 at mainbus0: CN70xx/CN71xx CPU rev 0.2 1000 MHz, CN70xx/CN71xx FPU rev 0.0 cpu0: cache L1-I 78KB 39 way D 32KB 32 way, L2 1024KB 8 way cpu1 at mainbus0: CN70xx/CN71xx CPU rev 0.2 1000 MHz, CN70xx/CN71xx FPU rev 0.0 cpu1: cache L1-I 78KB 39 way D 32KB 32 way, L2 1024KB 8 way cpu2 at mainbus0: CN70xx/CN71xx CPU rev 0.2 1000 MHz, CN70xx/CN71xx FPU rev 0.0 cpu2: cache L1-I 78KB 39 way D 32KB 32 way, L2 1024KB 8 way cpu3 at mainbus0: CN70xx/CN71xx CPU rev 0.2 1000 MHz, CN70xx/CN71xx FPU rev 0.0 cpu3: cache L1-I 78KB 39 way D 32KB 32 way, L2 1024KB 8 way
USB Printer Prebloms
I've had problems getting an old Brother printer to work (again) and have managed to locate/understand? the source of the problems. 1. ulpt must be disabled: # config -ef /bsd ukc> disable ulpt ukc> quit 2. modifying the kernel changes the kernel checksum so to get it to relink sha256 -h /var/db/kernel.SHA256 /bsd 3. relinking the kernel _re-enables_ ulpt. So I'm going to have install the build system and run thru the kernel patches after I figure out how to disable ulpt in the GENERIC.MP build. Does this sound like it will work? RSVP thanks, Dhu -- Je suis Canadien. Ce n'est pas Francais ou Anglaise. C'est une esp`ece de sauvage: ne obliviscaris, vix ea nostra voco;-)
Pledge Policy for Tset Binary
Hi, I was looking at the pledge policy for the tset binary and I was wondering why wpath is necessary. I removed the group from the pledge and did some basic tests with the utility and there was no error. Removing any of the other groups produces an error so they seem necessary. Any assistance would be appreciated. Regards, Shankara Pailoor
Hardening browser
Hi, in the following message: https://marc.info/?l=openbsd-misc=158110613210895=2 Theo discourages to use unveil instead of chroot. I asked if he suggests the same for the browser but he asked that chroot is onlye for *root*. Then what should I do to hardening the most exposed piece of code that we use everyday ? Now I'm using unveil+chrome... Thank you.
Re: Time jumping forward issue under OpenBSD 6.6 VMM
On 2020-03-03 07:43, mabi wrote: Hello, I am running an OpenBSD 6.6 VMM server with a few virtual machines also running 6.6 and noticed that one of them which is running Dovecot 2.3.9 package outputs the following warning every few 10-15 seconds: dovecot: imap: Warning: Time jumped forwards 28.294585 seconds It looks like there is a time issue on that VM although I am running the default ntpd of OpenBSD 6.6 and I have added the following parameter into my /etc/sysctl.conf on that VM: kern.timecounter.hardware=tsc Is there anything else I can do to avoid this time issue in my VM? Best regards, Mabi The clocks are basically broken on vmm. The pvclock stuff is definitely an improvement, but it's still not there. There's still a ways to go before we have proper, reasonably accurate clocks for vmm guests.
Re: Time jumping forward issue under OpenBSD 6.6 VMM
‐‐‐ Original Message ‐‐‐ On Tuesday, March 3, 2020 5:58 PM, Ian Gregory wrote: > I've had similar issues with timekeeping within guests of VMM, > although there are improvements in -current with the pvclock time > source. Since the fix below I now see occasional instances of the > clock stepping by a few whole seconds (typically less than 8s) but > it's much less frequent and the magnitude is within the bounds of what > ntpd can correct. > > See > http://openbsd-archive.7691.n7.nabble.com/pvclock-stability-tp376946p377922.html > for some backstory > > (aside: I see similar small occasional clock jumps of an integer > number of seconds on OpenBSD-6.6 guests using tsc running on a VMware > ESXi host) Thank you Ian for your answer. Unfortunately I don't understand too much of that post you linked. But if I understand you correctly you are suggesting that I should change on my VM: kern.timecounter.hardware=pvclock and the drift or jumps should be better than with "tsc" ?
Re: Having PF enabled breaks up rsync (and scp) over ssh connections
Jyri Hovila [Turvamies.fi] [jyri.hov...@turvamies.fi] wrote: > Hello everyone! > > Now here's a mysterious one -- I've been working on this for weeks and still > have no clue what's causing it. > > "client_loop: send disconnect: Broken pipe > > As soon as I disable pf entirely, the problem goes away. > > Any ideas on how to debug this further? > Figure out which exact part of your pf config is causing this. Try disabling everything line-by-line.
Re: Time jumping forward issue under OpenBSD 6.6 VMM
On Tue, 3 Mar 2020 at 15:47, mabi wrote: > It looks like there is a time issue on that VM although I am running the > default ntpd of OpenBSD 6.6 and I have added the following parameter into my > /etc/sysctl.conf on that VM: > > kern.timecounter.hardware=tsc I've had similar issues with timekeeping within guests of VMM, although there are improvements in -current with the pvclock time source. Since the fix below I now see occasional instances of the clock stepping by a few whole seconds (typically less than 8s) but it's much less frequent and the magnitude is within the bounds of what ntpd can correct. See http://openbsd-archive.7691.n7.nabble.com/pvclock-stability-tp376946p377922.html for some backstory (aside: I see similar small occasional clock jumps of an integer number of seconds on OpenBSD-6.6 guests using tsc running on a VMware ESXi host) Regards Ian
Re: man to render pure text? (or a pipe in vi macros ?)
hello Ingo, > > rare cases. so i finally think it's not worth ... col -b is an elegant > > solution. > Premature optimization is evil. this case isn't about optimizing, it's about slowing down 99.999% to add a case that already have an elegant and simple solution. but as i said: i don't feel skilled enough to be sure of anything. your call ;) cheers marc
Re: man to render pure text? (or a pipe in vi macros ?)
Hi Marc, Marc Chantreux wrote on Tue, Mar 03, 2020 at 10:05:41AM +0100: > Ingo Schwarze wrote: >> :map K yw:E /tmp/vi.keyword.$$p!!xargs man >> >> i get: >> >> Error detected while processing function >> line 30: >> E132: Function call depth is higher than 'maxfuncdepth' > it's a bug in the :E command, i reported it there: > > https://github.com/vim/vim/issues/5723 > > thank you for spotting it. Heh. I'm a blind squirrel, and look at the nut i just found... >> Also, the patch that would be required is very small and straightforward. > indeed. you made me like reading C code. >> So, what do people think? Should i test the patch below in more >> depth and commit it? Or do people consider this bloat? > i'm very naive about performance things but: as you add a condition > in a loop that is used while reading the input, it will be a little > bit slower. > which means penality for everyone to avoid using a very simple pipe on > rare cases. so i finally think it's not worth ... col -b is an elegant > solution. I ran "mandoc /usr/share/man/man1/ksh.1" 100 times, 10 times. Before the change: 0m07.65s real 0m05.68s user 0m01.52s system 0m07.62s real 0m05.92s user 0m01.47s system 0m07.64s real 0m05.97s user 0m01.49s system 0m07.62s real 0m05.90s user 0m01.42s system 0m07.68s real 0m06.13s user 0m01.51s system 0m07.65s real 0m06.01s user 0m01.46s system 0m07.66s real 0m05.89s user 0m01.50s system 0m07.60s real 0m05.89s user 0m01.54s system 0m07.73s real 0m06.00s user 0m01.38s system 0m07.68s real 0m05.70s user 0m01.47s system 7.653 +- 0.037 seconds for 100 times ksh(1) 76.53ms +- 0.37ms for formatting ksh(1) After the change: 0m07.68s real 0m06.22s user 0m01.34s system 0m07.62s real 0m06.02s user 0m01.42s system 0m07.68s real 0m05.87s user 0m01.46s system 0m07.66s real 0m06.01s user 0m01.41s system 0m07.59s real 0m06.00s user 0m01.41s system 0m07.62s real 0m06.09s user 0m01.20s system 0m07.63s real 0m05.95s user 0m01.44s system 0m07.67s real 0m05.83s user 0m01.48s system 0m07.59s real 0m06.11s user 0m01.46s system 0m07.71s real 0m05.86s user 0m01.45s system 7.645 +- 0.041 seconds for 100 times ksh(1) 76.45ms +- 0.41ms for formatting ksh(1) So the slowdown is -8 +- 55 microseconds for formatting ksh(1) which is consistent with "no change" with a precision of about 7 permille. It would no doubt be possible to measure this with more precision, but i think knowing that there is no measurable performance change on a one-percent level is good enough. Also, i'm not surprised that one more "if" per output character isn't relevant compared to all the other stuff that needs to be done in the parsers and formatters. I still do performance testing before changing overall algorithmic order, but mere "if"s are almost never relevant. I even mostly stopped worrying about malloc(3) inside loops; at least in mandoc, i have rarely seen relevant effects of slowdown. Premature optimization is evil. Yours, Ingo
Time jumping forward issue under OpenBSD 6.6 VMM
Hello, I am running an OpenBSD 6.6 VMM server with a few virtual machines also running 6.6 and noticed that one of them which is running Dovecot 2.3.9 package outputs the following warning every few 10-15 seconds: dovecot: imap: Warning: Time jumped forwards 28.294585 seconds It looks like there is a time issue on that VM although I am running the default ntpd of OpenBSD 6.6 and I have added the following parameter into my /etc/sysctl.conf on that VM: kern.timecounter.hardware=tsc Is there anything else I can do to avoid this time issue in my VM? Best regards, Mabi
Re: Web documentation available offline by default?
On 2020-03-02, Peter N. M. Hansteen wrote: > I was thinking of the probably quite unlikely event that somebody who wants > this > comes up with an actually reproducible way that could be turned into an > otherwise > unremarkable make target. >From experience with other generated files: it won't get used by everyone who updates the faq, meaning that it's another thing that somebody has to watch out for and fix it. IMHO the only way to fix this is to convert the faq to some other format that is used to generate a variety of output files (such that the html files aren't stored in the repository, only the "input" files, so there's no chance of getting it wrong). And *that* has enough implications that I don't think it will work well either.
Re: upgrade i386 kernel to amd64
On 2020-03-02, Justin Muir wrote: > Hello all, > > Running GENERIC i386 kernel on on a 64-bit amd machine. Just wondering > whether an upgrade amd64 is warranted. Any opinions? Generally yes, unless you are low on memory. > If so, just upgrade system? Re-compile kernel? Other options? Do NOT try to do this by just updating the kernel, it will not work. OpenBSD does not do "mixed 32/64 bit" like some OS. An OpenBSD/amd64 kernel cannot run 32-bit binaries. The official advice: you should reinstall from scratch. There may be other advantages to doing that too in particular if some of your filesystems are too tight for space you will need to rearrange them to fit the larger amd64 binaries. However unofficially - essentially this is like a "flag day" upgrade of the same architecture (like was done in 5.5 for the time_t changes). I won't give more advice on how to do that here because if you need more advice than the clues in the previous sentence this is not the route for you! But if you are willing to deal with fallout yourself if it breaks it could be a good learning experience. If you go for that route: Be prepared to reinstall the whole system in case of problems. Do have usable backups of anything you care about first.
Re: man to render pure text? (or a pipe in vi macros ?)
Le 02/03/2020 à 17:59, Marc Chantreux a écrit : i felt dumb reading this as i gave a try to the mandoc man. but i just double checked: man mandoc|col -b|grep -w col Hmmm, here I have it though: https://man.openbsd.org/mandoc In the “ASCII Output” paragraph. -- David
Re: man to render pure text? (or a pipe in vi macros ?)
hello Ingo, > :map K yw:E /tmp/vi.keyword.$$p!!xargs man > > i get: > > Error detected while processing function > line 30: > E132: Function call depth is higher than 'maxfuncdepth' > Press ENTER or type command to continue it's a bug in the :E command, i reported it there: https://github.com/vim/vim/issues/5723 thank you for spotting it. > Also, the patch that would be required is very small and straightforward. indeed. you made me like reading C code. > So, what do people think? Should i test the patch below in more > depth and commit it? Or do people consider this bloat? i'm very naive about performance things but: as you add a condition in a loop that is used while reading the input, it will be a little bit slower. which means penality for everyone to avoid using a very simple pipe on rare cases. so i finally think it's not worth ... col -b is an elegant solution. regards marc
