Re: [smartmontools] OpenBSD testers required
On Fri, Jun 05, 2020 at 10:52:38AM +0200, Marek Benc wrote: > There's been some changes in the OpenBSD port of smartmontools, > tools for working with S.M.A.R.T diagnostic of hard drives and SSDs, > the platform-specific code was modernized, so it would be quite useful > if people could test these changes out to make sure they work on all > systems, I tested them on a macppc system with an ATA drive. > > The developer doesn't currently have access to a physical system > with OpenBSD running on it, so they wrote the changes in a virtual > machine. > > You can find the changes here: > https://github.com/smartmontools/smartmontools/pull/56 Tested on two amd64-systems. Worked on both systems.
Re: 6.6, X and braswell
On Mon, Mar 02, 2020 at 09:45:26PM +0100, whistlez...@riseup.net wrote: > Hi, > I have the following bug: > https://marc.info/?t=15636262941=1=2 > now I'm on 6.5 and it works, but maybe one month ago I tried to install > 6.6 and I found the bug. > Anyone know if it was been resolved ? > Thanks > Whistlez > The bug still exists. Using a braswell based system as daily driver myself, I disable inteldrm in the kernel after every update. (Works for me as mostly console user, but still no suspend/resume)
Unbreak ledger
Since some snapshots ledger did not build. I was able to make it build again with two changes: 1.) Use -std=gnu++11 as flag for clang 2.) Change the include-path for readline For *me* the compiled port works fine. Index: patches/patch-CMakeLists_txt === RCS file: patches/patch-CMakeLists_txt diff -N patches/patch-CMakeLists_txt --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-CMakeLists_txt2 Nov 2018 16:27:53 - @@ -0,0 +1,12 @@ +--- CMakeLists.txt Fri Nov 2 13:56:02 2018 CMakeLists.txt Fri Nov 2 13:53:16 2018 +@@ -19,7 +19,7 @@ + + enable_testing() + +-add_definitions(-std=c++11) ++add_definitions(-std=gnu++11) + if (CYGWIN) + add_definitions(-U__STRICT_ANSI__) + endif() + Index: patches/patch-src_system.hh === RCS file: patches/patch-src_system.hh diff -N patches/patch-src_system.hh --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-src_system.hh 2 Nov 2018 16:27:53 - @@ -0,0 +1,12 @@ +--- src/system.hh.in.orig 2016-01-11 15:59:38.0 + src/system.hh.in +@@ -168,7 +168,8 @@ typedef std::ostream::pos_type ostream_p + #include "utf8.h" + + #if HAVE_EDIT +-#include ++#include ++#include + #endif + + #include
Stabilize Inteldrm on Braswell
I was encountering the same crashes as some other Braswell-Users.
(Black Screen after youtube and pmap_flush_cache in panic message in
/var/log/messages)
For *me* those crashes went away as i added two Fixes which Matt Dillon
used in Dragonfly BSD.
The Patch below was applied to an cvs-checkout from 2017-11-15.
Index: i915_gem_gtt.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_gem_gtt.c,v
retrieving revision 1.15
diff -u -p -r1.15 i915_gem_gtt.c
--- i915_gem_gtt.c 1 Jul 2017 16:14:10 - 1.15
+++ i915_gem_gtt.c 16 Nov 2017 15:51:02 -
@@ -778,7 +778,10 @@ static void gen8_ppgtt_clear_pte_range(s
num_entries--;
}
- kunmap_px(ppgtt, pt);
+ kunmap_px(ppgtt, pt_vaddr); /* XXX dillon, out of order
+ * patch from linux
+ * 44a71024 12-Apr-2016
+ */
pte = 0;
if (++pde == I915_PDES) {
@@ -1317,6 +1320,8 @@ static int gen8_alloc_va_range_3lvl(stru
gen8_for_each_pde(pt, pd, pd_start, pd_len, temp, pde) {
/* Same reasoning as pd */
WARN_ON(!pt);
+if (pt == NULL) /* XXX dillon hack */
+continue; /* XXX dillon hack */
WARN_ON(!pd_len);
WARN_ON(!gen8_pte_count(pd_start, pd_len));
Re: Lenovo 110s Laptop - bug or unsupported hardware?
On Fri, Oct 27, 2017 at 10:33:48PM -0500, J Vans wrote: > When running X, and doing things that require a lot of memory (open firefox > and watch a youtube video + 3 or 4 more tabs + open evince and open a > sizeable PDF was my test) this machine freezes, and the screen goes black. > Sometimes this happens in 30 seconds, sometimes it takes 10 minutes or more. > I also tested with Chrome and Midori, and got the same behavior. I also > tested playing video locally and the results were the same. On a few > occasions it crashed while not doing much, but for the most part if I keep > memory usage low (i.e. use a text based browser, for example) it does not > crash. DDB is opening in the background after the crash, but I cannot see it. > I type ps, and trace, but they do not show up in the messages after > rebooting. I have however been able to get several core dumps. They look > identical to eachother, which leads me to believe it is the same problem > happening in each crash. I have the same Problem here on an Acer Aspire B117. Since both machines (Lenovo and Acer) are based on Braswell, I think, it could be related to the inteldrm on Braswell. I could not trigger this problem if I use wsfb in xorg.conf. Also this Box runs perfect, if i only use my "normal" small console applications (vim, w3m, mutt, newsbeuter, ledger and such).
Correct tftpproxy in faq/pf/ftp.html
Since OpenBSD 5.3 the tftpproxy is no longer startet via inetd, but as a daemon. The faq section in ftp.html still instructs you to use inetd. Below is a diff which instructs the reader to use the service instead of inetd. Index: ftp.html === RCS file: /cvs/www/faq/pf/ftp.html,v retrieving revision 1.60 diff -u -p -r1.60 ftp.html --- ftp.html15 Jan 2017 11:33:04 - 1.60 +++ ftp.html20 Jun 2017 08:29:20 - @@ -243,16 +243,12 @@ The rules above allow TFTP outbound from servers on the external network. -The last step is to enable tftp-proxy in -http://man.openbsd.org/inetd.conf;>inetd.conf(5) so that it -listens on the same port that the divert-to rule specified above, -in this case 6969. +The last step is to enable and start tftp-proxy(8). -127.0.0.1:6969 dgram udp wait root /usr/libexec/tftp-proxy tftp-proxy +# rcctl enable tftpproxy +# rcctl start tftpproxy - -Unlike ftp-proxy(8), tftp-proxy(8) is spawned from inetd.
Re: Problem with "xargs -0"
On Mon, Jan 16, 2017 at 08:44:11AM -0700, Todd C. Miller wrote: > On Mon, 16 Jan 2017 12:19:31 +0100, Andreas Kusalananda > =?iso-8859-1?B?S+Ro5HJp > ?= wrote: > > > However, when I use nul-termination instead: > > > > $ printf 'hello\00world\00' | xargs -0 -I arg printf '>%s<\n' "arg" > > >hello world< > > This appears to be a bug with the -I handling. Without -I it > works as expected: > > $ printf 'hello\00world\00' | xargs -0 printf '>%s<\n' > >hello< > >world< As I said in the other mail: The -I separates at new LINES (in the Code it sets the Parameter -L to 1, so it starts a new entry on every non empty line. Example: $printf "This is\t a\nTest and\tso on" | xargs -I arg printf '>%s<\n' "arg" >This is a< >Test and so on< If we use "-n 1" it splits every entry: $printf "This is\t a\nTest and\tso on" | xargs -n 1 -I arg printf '>%s<\n' "arg" >This< >is< >a< >Test< >and< >so< >on<
Re: Problem with "xargs -0"
On Mon, Jan 16, 2017 at 12:19:31PM +0100, Andreas Kusalananda Kähäri wrote: > I've found an issue with xargs. > > > > > > This works as expected: > > > > > > $ printf 'hello\nworld\n' | xargs -I arg printf '>%s<\n' "arg" > > > >hello< > > > >world< > > > > > > However, when I use nul-termination instead: > > > > > > $ printf 'hello\00world\00' | xargs -0 -I arg printf '>%s<\n' "arg" > > > >hello world< > > I got curious and looked into this: xargs works as described in the manpage: It invokes the command on each LINE of input. If yout replace the delimiter in your first example by tab or space, it also starts all tokens in one command. To get the result, which you expected, you have to use the parameter "-n 1" additionally.
Re: Unable to boot encrypted drive
> I recently changed my FDE passphrase and now my laptop won't boot. > Bootloader just gives me "invalid passphrase" when I try to unlock it on boot. > Its a bit odd as I can boot usb stick and manually open the drive and upgrade > the openbsd installation on it. It just won't work on the boot. Some weeks ago I had a similar problem. The problem started, because i changed the password from an system running an newer snapshot than the encrypted System. (So "invalid passphrase" can also mean "too new fde") The solution for me was starting an update from a new bsd.rd. After the update everything was fine again.
