Hi,
Just noticed one of the VMs greeted me with a ddb> prompt.
The host is running 7.2#4 as well as the VM, dmesg of the host below.
I managed to get the following data from the VM:
ddb> show panic
*cpu0: kernel diagnostic assertion "m != NULL" failed: file
"/usr/src/sys/dev/p
v/if_vio.c",
Hi All,
Just to confirm that the below patch has been working like a charm.
Since the patch was applied, and only this patch, NSD has been behaving
properly.
Mischa
On 2021-10-20 12:33, Florian Obser wrote:
On 2021-10-20 07:55 +02, Otto Moerbeek wrote:
On Wed, Oct 20, 2021 at 07:47:30AM
On 2021-10-20 12:33, Florian Obser wrote:
On 2021-10-20 07:55 +02, Otto Moerbeek wrote:
On Wed, Oct 20, 2021 at 07:47:30AM +0200, Mischa wrote:
Unfortunately our joy was short lived. This morning I noticed a lot
of
Oct 20 07:44:15 name1 nsd[80814]: server 76410 died unexpectedly with
status
> On 24 Sep 2020, at 13:52, Sebastien Marie wrote:
>
> On Thu, Sep 24, 2020 at 12:47:30PM +0200, Mischa wrote:
>>>
>>> One quirk of the archive: It just creates a directory every night, no
>>> matter if a snap was built or not, you can check with what(1)
> On 24 Sep 2020, at 12:23, Florian Obser wrote:
>
> On Thu, Sep 24, 2020 at 12:13:31PM +0200, Mischa wrote:
>>
>>
>>> On 24 Sep 2020, at 09:15, Florian Obser wrote:
>>> 3a) does it also shutdown: bisect the hypervisor (tbh I expect the problem
> On 24 Sep 2020, at 09:15, Florian Obser wrote:
>
> Hi Mischa,
>
> On Thu, Sep 24, 2020 at 08:52:55AM +0200, Mischa wrote:
>> Hi All,
>>
>> With the last couple of -current updates I noticed a VM doesn’t come back
>> after running sysupgrade, which
> On 24 Sep 2020, at 09:15, Florian Obser wrote:
>
> Hi Mischa,
>
> On Thu, Sep 24, 2020 at 08:52:55AM +0200, Mischa wrote:
>> Hi All,
>>
>> With the last couple of -current updates I noticed a VM doesn’t come back
>> after running sysupgrade, which
?
Mischa
> On 16 Oct 2019, at 21:35, Mike Larkin wrote:
>
> On Wed, Oct 16, 2019 at 06:14:55PM +0200, Mischa wrote:
>> Hi Stuart,
>>
>>
>>>> On 16 Oct 2019, at 18:07, Stuart Henderson wrote:
>>>
>>> On 2019/10/16 18:00, Mischa wrote:
>
Hi Stuart,
> On 16 Oct 2019, at 18:07, Stuart Henderson wrote:
>
> On 2019/10/16 18:00, Mischa wrote:
>> Hi All,
>>
>> One of the OpenBSD VMs running on 6.6-beta #313 is rebooting or panicing in
>> different ways.
>> Not sure if they are all rele
Hi All,
One of the OpenBSD VMs running on 6.6-beta #313 is rebooting or panicing in
different ways.
Not sure if they are all relevant or useful but here are the ones we managed to
capture.
Mischa
###
fd0$ uvm_fault(0x81f9def0, 0x0, 0, 1) -> e
kernel: page fault trap, code=0
Stop
but I have seen this happening a couple of times now, and it seems
>> running the
>> "ifconfig bridge" command multiple times triggers this.
>
> Hi,
>
> can you update your box with latest snapshot ?
> There were some problems with "ifconfig bridge" command few months ago..
Will give that a go.
Thanx!
Mischa
>Synopsis: ifconfig bridge crashed host
>Category:
>Environment:
System : OpenBSD 6.5
Details : OpenBSD 6.5 (GENERIC.MP) #0: Wed Apr 24 23:38:54 CEST 2019
r...@syspatch-65-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> On 19 Jun 2018, at 20:28, Mischa wrote:
>
>> On 19 Jun 2018, at 17:51, Mike Larkin wrote:
>> On Tue, Jun 19, 2018 at 03:42:06PM +0200, obs...@high5.nl wrote:
>>>> Synopsis: VMs stop intermitently after vcpu_run_loop error
>>>> Category: system
>&
Hi Reyk,
Thank you for your help on the kernel includes.
I have applied the patch to vmd -current and it works well on my setup.
A non-wheel user can indeed start/stop a VM and connect to the console.
Thanx!!
Mischa
On 19 Jun at 20:38, Reyk Floeter wrote:
> Hi,
>
> On Sun, Jun
On 19 Jun at 22:10, Theo de Raadt wrote:
> Mischa wrote:
>
> > > 2. Change the default owner group to root:_vmd.
> > >
> > > It would be possible to define a hardcoded group, or use group _vmd,
> > > but this doesn't feel right.
> >
m YP/LDA, and let them mess with your VMs. I think
> this is much more viable in a multi-user environment. Add the
> following to the top/global section of /etc/vm.conf: "socket owner :devops"
Works for me. And when vm.conf doesn't exist, or the owner would exist it would
fal
tarts all the VMs at the same time. Looks like it's draining
>> resources at that point.
>>
>
> Yes, this is a known issue, I've had it on my to-do list to have some sort
> of sequencing or delay, but never got around to it (Hint, hint, such a fix
> would
> likely be an eas
Hi Reyk,
Seems like a workable solution if the security part is restricted enough by vmd.
Mischa
> On 18 Jun 2018, at 00:05, Reyk Floeter wrote:
>
> Hi,
>
> changing the umask in control.c could fix it. There’s no need to restrict it
> to wheel since vmd checks the
n 0 "Intel 82573L" rev 0x00: msi, address
00:30:48:96:42:07
I moved the cable em1 and it's been behaving as expected since.
Thanx for responding!!
Mischa
> On 03 Apr 2016, at 02:13, Evgeniy Sudyr <eject.in...@gmail.com> wrote:
>
> Mischa, please provide sendbug
that is strange is that it works after reboot, I can ping an IP. But
as soon as I run ftp or pkg_add for example, it stops working.
Mischa
--
--
> On 02 Apr 2016, at 21:15, Evgeniy Sudyr <eject.in...@gmail.com> wrote:
>
> Mischa,
>
> 1) Consider using sendbug (1) to provide report
.
But there is no longer an ARP entry.
Mischa
> On 22 Mar 2016, at 12:18, Mischa <open...@high5.nl> wrote:
>
> Hi All,
>
> I would be happy to provide remote console access if that helps.
>
> Mischa
>
>> On 20 Mar 2016, at 14:52, Mischa <open...@high5.nl> wrote:
>
Hi All,
I would be happy to provide remote console access if that helps.
Mischa
> On 20 Mar 2016, at 14:52, Mischa <open...@high5.nl> wrote:
>
> Hi All,
>
> I am running OpenBSD 5.8, and tried 5.9 as well, on a SuperMicro PDSMi which
> has an Intel 82573E.
> For
UHb00 - 1 em0
127/8 127.0.0.1 UGRS 00 32768 8 lo0
127.0.0.1 127.0.0.1 UHl10 32768 1 lo0
224/4 127.0.0.1 URS00 32768 8 lo0
Thanx!
Mischa
> On 07 Mar 2016, at 09:34, Mike Larkin <mlar...@azathoth.net> wrote:
>
> On Sun, Mar 06, 2016 at 04:33:59PM +0100, Mischa wrote:
>> Hi,
>>
>> Reyk asked me to post the following panics on this list.
>> I have seen multiple panics when running the stock re
x40014200idle0
1 0 1 0 30x82 wait init
0 -1 0 0 3 0x10200 scheduler swapper
ddb{0}>
Hopefully this will help.
Regards,
Mischa
Hi Steven,
> On 21 Nov 2015, at 18:00, Steven Chamberlain <ste...@pyro.eu.org> wrote:
>
> Hello,
>
> Mischa wrote:
>> I am running OpenBSD 5.8 GENERIC#1170 amd64 as a bhyve instance on FreeBSD
>> 10.2-RELEASE-p7.
>
> I suspect you should t
systq
29152 0 0 0 3 0x40014200idle0
1 0 1 0 30x82 wait init
0 -1 0 0 3 0x10200 scheduler swapper
Mischa
28 matches
Mail list logo
