Re: amd64 Intel cpu microcode

Does microcode updated that way is being erased after each reboot? From: "Theo de Raadt" To: tech@openbsd.org; Date: 1:09 Niedziela 2018-01-14 Subject: amd64 Intel cpu microcode > Patrick and others commited amd64 Intel cpu microcode update code > over the last few days.

Re: Intel CPU Security Flaw Kernel Memory Leak (no microcode update) SW workarounds only

https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html or shortened URLs: goo.gl/ndYk6H goo.gl/kTfwfn Od: "Tom Smyth" Do: tech@openbsd.org; Temat: Intel CPU Security Flaw Kernel

Re: ffs/msdosfs: Flush cache when updating mount to R/O

What if somebody remounts from default options (metadata: sync, data: nosync) to fully synced (metadata: sync, data: sync) Example: # mount | grep /home /dev/sd1h on /home type ffs (local) # /sbin/mount -u -o sync /home # mount |

Re: usb disk dirty after every reboot

>I found a few cases, where we should send a cache flush but don't. >Unfortunately, none of these cases explain the problem seen by >Jan and Darren. >The cases I have found are: >* When a R/W mount is updated to R/O. I will send patches for this in a >separate mail. >* When a R/W mount is

Re: Help me testing the netlock

> > panic: rw_enter: netlock locking against myself > > Your tree is not up-to-date, you're missing sys/net/route.c r1.332. My bad. With updated sources I have tested this for few minutes and I don't encountered any kernel panic. CVS sync, wget to download base system from mirror, browsing web

Re: Help me testing the netlock

panic: rw_enter: netlock locking against myself TIDPID UIDPRFLAGS 12705 12705 1041 0x23 *62630 62630 1000 0x32 PFLAGS CPU COMMAND 0 1chrome 0 0 Xorg panic() rw_enter() rw_enter_write() rw_enter_timer() timeout_run() softlock()

Re: Kernel panic pf.c during halting

My system don't started Tor daemon and dnscrypt-proxy daemon and still I get this kernel panic. I still use Unbound. I still have pf rules for transparent proxying. I only disabled Tor client. I was thinking about simplify more before I answer, but dhill () mindcry ! org posted similar bug to bug

Re: Kernel panic pf.c during halting

> > > The key is really being able to reproduce the problem, Lampshade do you > > already know which service or config triggers this panic? Could you try > > to figure out by simplifying your setup? > > I don't know. > Problem is that even with most complicated

Re: Kernel panic pf.c during halting

Another crash. I should note that this kernel is build by me with patches to GENERIC (HZ from 100 to 300), pci and acpi files. Both previous reports were from official kernel builds (snapshots). Source code is based on: cvs -d$CVSROOT up -D "2016-08-26 12:45" -Pd As always with this panic I

Re: Kernel panic pf.c during halting

> Are you using the tor TRANS_PF stuff for transparent proxying? Yes, I am. # grep -v -e ^# -e Password /etc/tor/instancjaDlaFF.conf user _tor_do_FF RunAsDaemon 1 DataDirectory /home/_tor_do_FF/ Log notice file /home/_tor_do_FF/logs/log SocksPort 0 TransListenAddress 172.10.0.2:9040 TransPort

Re: Kernel panic pf.c during halting

> > > Which daemons do you use on this machine? > > # rcctl ls on > check_quotas > cron > dnscrypt_proxy_one > dnscrypt_proxy_second > messagebus > pf > pflogd > relayd > sndiod > syslogd > unbound > # rcctl ls started > cron > dnscrypt_proxy_one > dnscrypt_proxy_second > messagebus

Re: Kernel panic pf.c during halting

> On 22/06/16(Wed) 00:53, Lampshade wrote: > > I don't know if this is enough, but I haven't had access to web > > using other device when kernel panicked. > > What's the output of ifconfig and route -n show for this system? > Sorry for silence. Kernel panic ha

Kernel panic pf.c during halting

I don't know if this is enough, but I haven't had access to web using other device when kernel panicked. sysctl kern.version kern.version=OpenBSD 6.0-beta (GENERIC.MP) #2198: Sun Jun 19 11:58:45 MDT 2016

Re: Get PCI resources from ACPI

Firstly diff, secondly all dmesg from unmodified and modified with yours patch kernel. OpenBSD-current amd64 with source code updated using cvs -d$CVSROOT up -D "2016-01-07 05:00" -Pd diff -u /katalogDmesg/nieZmodyfikowaneAcpiMark/dmesg.log /katalogDmesg/zmodyfikowaneAcpiMark/dmesg.log ---

Re: Mesa has broken r300/r600 (gallium) dri DSO

My answer is based on OpenBSD-current dated 18-12-2015 amd64

Re: virtualization support

Sorry for newbie question, but I am curious and this hipervisor is new thing so there is no man pages yet. I have read general classification of hypervisors on Wikipedia and there are types: Type-1 and Type-2. I have also read about KVM on cern.ch's Wiki.