PUBLISH YOUR BLOG POSTS

PUBLISH YOUR BLOG POSTS - INCREASE YOUR WEBSITE / BLOGS / FORUMS TRAFFIC We have skills to boost up your website, personal blogs. We are providing strong backlinks via Blog Posts to Increase Your Website Traffic as well as Your Website/Blog Ranking over Search Engines. I suggest you give us a

Re: pckbc: extend the PS/2 interface tests

Meanwhile, I think this patch is not a good idea, at least not in this form. While it may correctly establish whether there is an auxiliary interface or not, it may lead to conflicts in cases where a touchpad isn't "meant" to be run in the legacy PS/2 mode. Until now, I have thought that the lack

Re: A few questions regarding WG(4)

On Mon, Sep 28, 2020 at 6:35 PM Sven F. wrote: > Dear reader, > > i tested 6.8-beta and WG > > After going for behind NAT to behind NAT experiment , > i went for two 'clients' behind a NAT to an openBSD device with a public IP > called here 'Server' > > First of all , a minor detail, unless I

fvwm: remove osrelease from system.fvwmrc

This is the version string that shows up as part of "OpenBSD 6.8" in the bottom right window in a default installation. But as this version stems from the build machine's kernel with which fvwm was build, it can differ from the version you're running on your machine which is what you'd expect as

Quick trip report: Lenovo P1 Gen 3

There's still a lot of unrecognized devices on the P1 Gen 3, and the install process is not quite smooth yet, but it does eventually boot once installed with a GENERIC* kernel from -current. (See https://marc.info/?l=openbsd-bugs=160011933402270=2 for dmesg and vitals from the unmodified kernel.)

Re: mfokclock(4) -> mfokrtc(4): loongson's hugging arm

Patrick Wildt wrote: > On Tue, Sep 29, 2020 at 11:23:03AM -0600, Theo de Raadt wrote: > > + if (strcmp(ia->ia_name, "st,m41t83") == 0) > > > > fine with me. But in that case, why not call the driver i2c/m41t83.c > > Because it's a series of chips, like m41t80, m41t81, m41t82. Machines

Re: mfokclock(4) -> mfokrtc(4): loongson's hugging arm

On Tue, Sep 29, 2020 at 11:23:03AM -0600, Theo de Raadt wrote: > + if (strcmp(ia->ia_name, "st,m41t83") == 0) > > fine with me. But in that case, why not call the driver i2c/m41t83.c Because it's a series of chips, like m41t80, m41t81, m41t82. Machines and their device trees encode the

Re: mfokclock(4) -> mfokrtc(4): loongson's hugging arm

+ if (strcmp(ia->ia_name, "st,m41t83") == 0) fine with me. But in that case, why not call the driver i2c/m41t83.c

mfokclock(4) -> mfokrtc(4): loongson's hugging arm

Hi, some arm64 that I'd like to use as replacement server for the one that's crashing all the time (probably HW-related) has a Microcrystal RV4162 RTC. As it turns out, this is about the same as the ST M41T8x series. For that one we already have mfokclock(4), but only for loongson. After

iked(8): check ibuf_seek() return value

Hi, the diff below adds a missing return value check for ibuf_seek() in IKEv2 fragment reassembly. ok? diff --git a/sbin/iked/ikev2_pld.c b/sbin/iked/ikev2_pld.c index 7102cfff6fd..2475be07299 100644 --- a/sbin/iked/ikev2_pld.c +++ b/sbin/iked/ikev2_pld.c @@ -1793,6 +1793,7 @@

dump: better handling of large filesystems

Hi, this fixes an overwrite of spcl.c_addr. Taken form FreeBSD. See https://marc.info/?l=openbsd-misc=160018252418088=2 -Otto Index: tape.c === RCS file: /cvs/src/sbin/dump/tape.c,v retrieving revision 1.45 diff -u -p

random canary bytes for malloc

Hi, until now, canary bytes (used by the C olption) were the same as the bytes used to junk (0xfd). This means that certain overwrites are not detected, like setting the high bit. This makes the byte value used to write canaries random. I do not want to complicate the code to handle all