On Mon, May 29, 2017 at 14:16 +0200, Mike Belopuhov wrote:
> Thanks for taking your time to test, but unfortunately I have to
> withdraw both diffs. I've realised that there's a ton of drivers
> calling ifq_deq_begin manually from their start routines and
> there's no simple solution for that that
On 31/05/17(Wed) 22:43, Gregor Best wrote:
> Hi people,
>
> with a fresh snapshot (according to the dates on the FTP server from
> today), and a kernel built from CVS from about 20:15 UTC+1, vmd's child
> processes reproducibly enter an infinite loop relatively early after
> booting an Alpine Linu
On 31/05/17(Wed) 21:05, Olivier A. wrote:
> > Only tested on a VM this time. Will try on real hardware as soon as
> > possible.
>
> This time on real hardware with last -current snapshot available :
> kern.version=OpenBSD 6.1-current (GENERIC.MP) #87: Tue May 30 21:05:25 MDT
> 2017
> dera...
After last update, my vm.conf take the "boot" parameter and no longer the
"kernel" parameter according to the vm.conf man page.
This "bug" can be closed.
On Wed, May 31, 2017 at 10:24 AM, Olivier Antoine wrote:
> On a fresh snapshot, the man page of vm.conf says :
>
> vm name {...}
>
On 01/06/17(Thu) 10:47, Martin Pieuchot wrote:
> On 31/05/17(Wed) 22:43, Gregor Best wrote:
> > Hi people,
> >
> > with a fresh snapshot (according to the dates on the FTP server from
> > today), and a kernel built from CVS from about 20:15 UTC+1, vmd's child
> > processes reproducibly enter an in
> Can you enter ddb and type 'ps' ?
Unfortunately no. There's no panic. No ddb prompt. On my laptop under X,
xenocara is completly frozen, mouse pointer stop mouving. On a VMM, with
ddb.console=1 and cu(1) sending BREAK does nothing.
On 01/06/17(Thu) 13:36, Olivier A. wrote:
> > Can you enter ddb and type 'ps' ?
>
> Unfortunately no. There's no panic. No ddb prompt. On my laptop under X,
> xenocara is completly frozen, mouse pointer stop mouving. On a VMM, with
> ddb.console=1 and cu(1) sending BREAK does nothing.
In this c
Hi.
I tried to install openbsd 6.1 snapshot on a HP Elitebook 840 using a usb
installer.
I did dd if=pathto/install61.fs of=/dev/rsd1c bs=1m and got no error.
When I tried to boot from usb it booted and got to the prompt.
Then it hang on booting hd0a:bsd and sometime it made a beeping sound and
On Thu, Jun 01, 2017 at 10:30 +0200, Mike Belopuhov wrote:
> On Mon, May 29, 2017 at 14:16 +0200, Mike Belopuhov wrote:
> > Thanks for taking your time to test, but unfortunately I have to
> > withdraw both diffs. I've realised that there's a ton of drivers
> > calling ifq_deq_begin manually from
> In this case could you build a kernel with option MP_LOCKDEBUG and see if
> it enters ddb?
Ok, I've compiled a new kernel with option MP_LOCKDEBUG uncommented on
GENRERIC.MP conf file.
After booting :
kern.version=OpenBSD 6.1 (GENERIC.MP) #1: Thu Jun 1 15:47:28 CEST 2017
oanto...@openbsd.
On 01/06/17(Thu) 15:48, Olivier A. wrote:
> > In this case could you build a kernel with option MP_LOCKDEBUG and see if
> > it enters ddb?
>
> Ok, I've compiled a new kernel with option MP_LOCKDEBUG uncommented on
> GENRERIC.MP conf file.
> After booting :
>
> kern.version=OpenBSD 6.1 (GENERIC.M
> So the only difference is that now ping works?
Oh. I would have explicited that.
No. Ping don't work after 64th icmp echo request. I have CTRL-C at 468th packet
according to ping status.
It doesn't seems to be determinist. Sometimes it hang faster that other time.
On 01/06/17(Thu) 17:36, Olivier A. wrote:
> > So the only difference is that now ping works?
>
> Oh. I would have explicited that.
> No. Ping don't work after 64th icmp echo request. I have CTRL-C at 468th
> packet according to ping status.
> It doesn't seems to be determinist. Sometimes it hang
> In this case could you build a kernel with option MP_LOCKDEBUG and see if
it enters ddb?
Oh wait! I've a ddb when running with MP_LOCKDEBUG on real hardware!
Previously it was on VMM.
so 'ps' show a huge list of sshd command:
PID TID PPIDUID S FLAGS WAITCOMMAND
6850
Hi,
before running syspatch(8):
-rw-r--r-- 1 root wheel 10751939 Jun 1 00:45 bsd
-rw-r--r-- 1 root wheel 9431142 Jun 1 00:45 bsd.rd
-rw-r--r-- 1 root wheel 10683954 Jun 1 00:45 bsd.sp
after syspatch(8):
-rwxr-xr-x 1 root wheel 10756231 Jun 1 13:42 bsd
-rw-r--r-- 1 root
Synopsis: VM in constand boot loop
Category: amd64
Environment:
System : OpenBSD 6.1
Details : OpenBSD 6.1-current (GENERIC.MP) #88: Wed May 31
19:06:15 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
I rebooted a couple of machines in the "wrong" order, NFS server
first, followed by clients.
On one of the clients I then mistyped a command and it tried to
search for it in an NFS directory in the path, so it was stalled
pending the NFS server coming back.
Then in another window I issued a reboo
Not before long the AXEN would start malbehaving again.
Specifically, I would boot the machine - either from hard electricity
cut or just normal USB-on-CPU-off poweroff, the kernel would detect
AXEN0 on boot, and then the system would go into "starting network" and
run dhclient on the axen0.
On Thu, Jun 01, 2017 at 08:03:40AM -0500, Michael Graves wrote:
> > Synopsis: VM in constand boot loop
> > Category: amd64
> > Environment:
> System : OpenBSD 6.1
> Details : OpenBSD 6.1-current (GENERIC.MP) #88: Wed May 31
> 19:06:15 MDT 2017
> dera...@amd64.open
On Thu, Jun 01, 2017 at 12:58:27PM +0200, Martin Pieuchot wrote:
> On 01/06/17(Thu) 10:47, Martin Pieuchot wrote:
> > On 31/05/17(Wed) 22:43, Gregor Best wrote:
> > > Hi people,
> > >
> > > with a fresh snapshot (according to the dates on the FTP server from
> > > today), and a kernel built from C
On 01/06/17(Thu) 23:09, Stuart Henderson wrote:
> I rebooted a couple of machines in the "wrong" order, NFS server
> first, followed by clients.
>
> On one of the clients I then mistyped a command and it tried to
> search for it in an NFS directory in the path, so it was stalled
> pending the NFS
21 matches
Mail list logo
