Re: cd*.iso reboot loop (vultr, Skylake AVX MDS)

Mike Larkin wrote: > On Sat, Dec 04, 2021 at 06:18:55PM +, Claus Assmann wrote: > > Just in case someone is wondering: vultr moved the VM to a different > > server, the system is up and running again. > > BTW: I guess I can ignore this: > > fd0 at fdc0 drive 1: density unknown > > > > > >

Re: cd*.iso reboot loop (vultr, Skylake AVX MDS)

On Sat, Dec 04, 2021 at 06:18:55PM +, Claus Assmann wrote: > Just in case someone is wondering: vultr moved the VM to a different > server, the system is up and running again. > BTW: I guess I can ignore this: > fd0 at fdc0 drive 1: density unknown > > > OpenBSD 6.9 (GENERIC) #464: Mon Apr 19

Re: cd*.iso reboot loop (vultr, Skylake AVX MDS)

Philip Guenther wrote: > They have your virtualization guest configured in a way that doesn't match > any real hardware: it has a family-model-stepping combination that matches > the Skylake line, real hardware of which all have the cflushopt extension, > but the host is making the guest trap

Re: cd*.iso reboot loop (vultr, Skylake AVX MDS)

Just in case someone is wondering: vultr moved the VM to a different server, the system is up and running again. BTW: I guess I can ignore this: fd0 at fdc0 drive 1: density unknown OpenBSD 6.9 (GENERIC) #464: Mon Apr 19 10:28:56 MDT 2021

Re: cd*.iso reboot loop (vultr, Skylake AVX MDS)

On Sat, Dec 4, 2021 at 4:32 AM Claus Assmann wrote: > My vultr OpenBSD 6.8 instance crashed and when it tried to reboot it > failed at: > > root on sd0a (...) > WARNING: / was not properly unmounted > kernel: privileged instruction fault trap, code=0 > mds_handler_skl_avx+0x33: clflush

cd*.iso reboot loop (vultr, Skylake AVX MDS)

My vultr OpenBSD 6.8 instance crashed and when it tried to reboot it failed at: root on sd0a (...) WARNING: / was not properly unmounted kernel: privileged instruction fault trap, code=0 mds_handler_skl_avx+0x33: clflush __ALIGN_SIZE+0x500(%rid,%rax,8) I tried to boot from cd{68,69,70}iso but

Re: Hibernation reboot loop

Probably an oversight. You could probably make a fairly simple diff to do what you wanted though. Looks like apmd.c:147 has code to extract out the ac state. You could duplicate that below, in the for (;;) loop body in main - get ac state before determining if 'autoaction' should actually call

Re: Hibernation reboot loop

On Sat, Jul 28, 2018 at 08:30:36PM +0200, Oliver Jan Krylow wrote: > Hello List! > > I have apmd configured with flags "-A -Z10 -t60" on a Thinkpad x230. > > When the machine hits <10% battery it hibernates (as it should). > I then attach the AC and boot up again. > The bsd.booted kernel boots

Hibernation reboot loop

Hello List! I have apmd configured with flags "-A -Z10 -t60" on a Thinkpad x230. When the machine hits <10% battery it hibernates (as it should). I then attach the AC and boot up again. The bsd.booted kernel boots up, but once the OS is up a moment, it reboots. This happens 2-3 times.

Re: Reboot loop

Basically yes. It's also possible to use puc(4) in some cases but you'll need to find the memory address yourself in pcidump and set it in the bootloader with "machine comaddr" and I think for some puc devices you might have a hard time setting the port to the baud rate that you want. --

Re: Reboot loop

On 08/06/18 11:36, IL Ka wrote: >> For a system console (with access to DDB etc.) you need a "standard" com > port. > Do you mean I can use "com", but not "ucom(4)", right? Using USB serial would require enumeration of the serial bus then selection of the appropriate protocol (there's at least a

Re: Reboot loop

> OpenBSD doesn't use ACPI to find an isa UART, it only looks in the fixed > locations compiled in to the kernel. Ok, I see that "com.c" does it by reading register, it even has comment "Probe for all known forms of UART" > For a system console (with access to DDB etc.) you need a

Re: Reboot loop

On 2018-06-06, IL Ka wrote: > There is >> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo > in your dmesg. > > So, I assume your box reports com port somehow (via ACPI probably) OpenBSD doesn't use ACPI to find an isa UART, it only looks in the fixed locations compiled in to the kernel.

Re: Reboot loop

IL Ka, Thanks for pointing it out. It will take a few days before I can capture the output through the com port. Until then folks, - Mensaje original - De: IL Ka Para: francis dos santos CC: OpenBSD General Misc Enviado: Wed, 06 Jun 2018 19:32:32 -0300 (ART) Asunto: Re: Reboot loop

Re: Reboot loop

Oops, spoke to soon. I'll have to break the box open/read manual to see if there is a com1 option through a header. - Mensaje original - De: IL Ka Para: francis dos santos CC: OpenBSD General Misc Enviado: Wed, 06 Jun 2018 18:45:07 -0300 (ART) Asunto: Re: Reboot loop Ok, then try

Re: Reboot loop

There is no com port on this machine. Thanks for the assistance. - Mensaje original - De: IL Ka Para: francis dos santos CC: OpenBSD General Misc Enviado: Wed, 06 Jun 2018 18:45:07 -0300 (ART) Asunto: Re: Reboot loop Ok, then try to follow Stuart Longland's advice: use serial console

Re: Reboot loop

. Needless to say, if something gets displayed before entering the tighter loop, I won't be able to see it. I do not see a kernel panic. - Mensaje original - De: IL Ka Para: francis dos santos CC: OpenBSD General Misc Enviado: Wed, 06 Jun 2018 17:29:55 -0300 (ART) Asunto: Re: Reboot loop ddb(4

Re: Reboot loop

There is > com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo in your dmesg. So, I assume your box reports com port somehow (via ACPI probably) Some boxes may have comport built into chipset but no external cable for it. I have one, I bought cable separately. Another option is to use UART

Re: Reboot loop

santos CC: OpenBSD General Misc Enviado: Wed, 06 Jun 2018 16:01:24 -0300 (ART) Asunto: Re: Reboot loop https://www.openbsd.org/report.html See "How to create a problem report" step 5

Re: Reboot loop

Ok, then try to follow Stuart Longland's advice: use serial console. Connect your PC using null-modem cable to another pc, and in boot(8) prompt type: boot> set tty com0 On another PC run cu(1) or minicom or screen (or for Windows you may use PuTTY), connect to OpenBSD and you will see all your

Re: Reboot loop

On 06/06/18 22:56, francis.dos.san...@ciudad.com.ar wrote: > About two days ago I upgraded to the version #65 below, just to see if > the game unknown-horizons would run smooth. Starting the computer anew > after evaluating the performance of the game I noticed that the machine > rebooted

Re: Reboot loop

ddb(4): "ddb is invoked upon a kernel panic when the sysctl(8) ddb.panic is set to 1". I belive this value is default. So, kernel should be dropped into ddb on panic. Does it happen? What exactly do you see on screen along with uvm_fault? Do you see whole stacktrace? Check

Re: Reboot loop

https://www.openbsd.org/report.html See "How to create a problem report" step 5

Re: Reboot loop

Theo, >> uvm_fault(0x81db7f68, 0x58, 0, 1) -> e > Just that one line? No other lines? I find that hard to believe. I should've stated that the uvm_fault messageline get's repeated ad infinitum. What can I do to get more debug info?

Re: Reboot loop

wer #82 to see > if my problem would go away, but no luck. It's stuck in an endless > reboot loop. Commenting out xenodm_flags gave me the this result. > > uvm_fault(0x81db7f68, 0x

Reboot loop

t over automatically. But luckily the second time around it proceeded to a xenodm login screen. Today the system has become unusable. I upgraded to a newer #82 to see if my problem would go away, but no luck. It's stuck in an endless reboot loop. Commenting out xenodm_flags gave me the this

Re: reboot loop on -current, one machine of several

On 11/13/17 14:24, Gregory Edigarov wrote: ... >> scsibus1 at ahci0: 32 targets >> -sd0 at scsibus1 targ 2 lun 0: SCSI3 0/direct >> fixed naa.50025388400562d4 >> +sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct >> fixed

Re: reboot loop on -current, one machine of several

On 12.11.17 21:59, Nick Holland wrote: On 11/12/17 14:13, Otto Moerbeek wrote: On Sun, Nov 12, 2017 at 01:28:39PM -0500, Nick Holland wrote: Help. I was upgrading a few very similar machines to -current today. ONE of the three decided to be unpleasant. The thing has a serial console, and

Re: reboot loop on -current, one machine of several

> booting hd0a:/bsd: 8484712+2429968+244048+0+667648 [636809heap full > (0x9d304+65536) Maybe a corrupted or too big /bsd file? I am curious about the cause.

Re: reboot loop on -current, one machine of several

On 11/12/17 14:13, Otto Moerbeek wrote: > On Sun, Nov 12, 2017 at 01:28:39PM -0500, Nick Holland wrote: > >> Help. >> >> I was upgrading a few very similar machines to -current today. >> ONE of the three decided to be unpleasant. The thing has a >> serial console, and but it is about 370km from

Re: reboot loop on -current, one machine of several

On Sun, Nov 12, 2017 at 01:28:39PM -0500, Nick Holland wrote: > Help. > > I was upgrading a few very similar machines to -current today. > ONE of the three decided to be unpleasant. The thing has a > serial console, and but it is about 370km from me. :-/ > > Upgrade from Sep 9 current to

reboot loop on -current, one machine of several

Help. I was upgrading a few very similar machines to -current today. ONE of the three decided to be unpleasant. The thing has a serial console, and but it is about 370km from me. :-/ Upgrade from Sep 9 current to today's current via bsd.rd, just like the other two. Upon reboot, it does this

Re: PC-Engines apu2c4 install reboot loop :(

Hi, Thanks everyone for the advice! For the archives, the magic was: boot: stty com0 115200 boot: set tty com0 boot: boot /bsd I was deceived by the boot prompt showing up over the console, that the whole boot process would know it's happening over a serial port. This is my first serial

Re: PC-Engines apu2c4 install reboot loop :(

. Regards, -stefan Von: owner-m...@openbsd.org [owner-m...@openbsd.org] im Auftrag von Steve Williams [st...@williamsitconsulting.com] Gesendet: Dienstag, 10. Januar 2017 23:16 Uhr An: misc@openbsd.org Betreff: PC-Engines apu2c4 install reboot loop :( Hi, I

Re: PC-Engines apu2c4 install reboot loop :(

On Tue, 10 Jan 2017, Raf Czlonka wrote: Anyway, the box is running live now so I cannot reboot for a while to get the 'dmesg'. Sorry. Try /var/run/dmesg.boot You would think so. But: No such file or directory I am not getting senile - yet. That's next year's project. Regards -

Re: PC-Engines apu2c4 install reboot loop :(

> On Jan 10, 2017, at 16:34, Reyk Floeter wrote: > > On Tue, Jan 10, 2017 at 03:26:01PM -0700, Scott Seekamp wrote: >> Also, are you setting the serial port of the loader: >> >> stty pc0 115200 > > You don't need this line, the tty will be switched to com0. > >> stty com0

Re: PC-Engines apu2c4 install reboot loop :(

On Tue, Jan 10, 2017 at 03:26:01PM -0700, Scott Seekamp wrote: > Also, are you setting the serial port of the loader: > > stty pc0 115200 You don't need this line, the tty will be switched to com0. > stty com0 115200 > set tty com0 > I think this will solve the problem. The APU2 doesn't

Re: PC-Engines apu2c4 install reboot loop :(

Hi Steve, I had the exact the same problem with the PC-Engines APU 2c4 and configuring the console with the correct settings solved it. You need to set the following settings at the boot> prompt stty pc0 115200 stty com0 115200 set tty com0 Cheers, Patrick On Tue, Jan 10, 2017 at 11:26 PM,

Re: PC-Engines apu2c4 install reboot loop :(

> On Jan 10, 2017, at 15:16, Steve Williams wrote: > > Hi, > > I purchased a new PC-Engines APU 2c4 system. I have a wireless card as well and a msata SSD (250 gig). I've tried the install with all these two boards installed, none installed and both combinations

Re: PC-Engines apu2c4 install reboot loop :(

On Tue, Jan 10, 2017 at 10:56:32PM GMT, Damian McGuckin wrote: > I would send the 'dmesg' boot messages but 'pf' keeps printing messages like > > pf: state reuse TCP in wire > or > pf: state reuse TCP out wire > > and it has filled up the /var/log/messages* so that dmesg no longer

Re: PC-Engines apu2c4 install reboot loop :(

Not that I can help but I can confirm that problem. On Tue, 10 Jan 2017, Steve Williams wrote: The BIOS prompts work fine, I get the "boot>" prompt in OpenBSD, but right after the "entry point" line prints out, the system reboots. Yes. I have seen this 3 times on a fit-PC4 Eco which is an

PC-Engines apu2c4 install reboot loop :(

Hi, I purchased a new PC-Engines APU 2c4 system. I have a wireless card as well and a msata SSD (250 gig). I've tried the install with all these two boards installed, none installed and both combinations with no change in symptoms. I have tried OpenBSD current "install60.fs"

heap full Re: Softraid Keydisk reboot loop

Am 26.12.2015 um 23:18 schrieb Alexander Hall: > On Sat, Dec 26, 2015 at 10:41:34PM +0100, Thomas Bohl wrote: >> Hello, >> >> I updated from 5.8-stabel to current today. (First just an update, than >> because of the problem a fresh installation.) On 5.8-stabel I had a >> working softraid boot

Softraid Keydisk reboot loop

Hello, I updated from 5.8-stabel to current today. (First just an update, than because of the problem a fresh installation.) On 5.8-stabel I had a working softraid boot setup with a USB-Stick as keydisk. Now, if the keydisk is plugged in, the machine resets over and over again. Unfortunately

Re: Softraid Keydisk reboot loop

On Sat, Dec 26, 2015 at 10:41:34PM +0100, Thomas Bohl wrote: > Hello, > > I updated from 5.8-stabel to current today. (First just an update, than > because of the problem a fresh installation.) On 5.8-stabel I had a > working softraid boot setup with a USB-Stick as keydisk. > > Now, if the

Re: SMP kernel/AMD64 stuck in reboot loop - NIC driver or other bug?

On Sun, Mar 22, 2015 at 09:53:24AM +, Stuart Henderson wrote: On 2015-03-21, John E.P. Hynes j...@hytronix.com wrote: If anyone has any ideas, or would like more info, or if a dev suspects it could be the driver, contact me off-list and I can arrange to send hardware if it helps.

Re: SMP kernel/AMD64 stuck in reboot loop - NIC driver or other bug?

It does the same thing on 5.3 through -current. I haven't put that box in the rack yet so I can try a few older kernels too and see if any work. Will report back. On Mar 22, 2015, at 8:45 AM, Claudio Jeker cje...@diehard.n-r-g.com wrote: On Sun, Mar 22, 2015 at 09:53:24AM +, Stuart

Re: SMP kernel/AMD64 stuck in reboot loop - NIC driver or other bug?

On 2015-03-21, John E.P. Hynes j...@hytronix.com wrote: If anyone has any ideas, or would like more info, or if a dev suspects it could be the driver, contact me off-list and I can arrange to send hardware if it helps. It might be worth talking to Supermicro.

Re: SMP kernel/AMD64 stuck in reboot loop - NIC driver or other bug?

Well, I discovered the issue - the few machines that work properly had a different quad-port nic in them. With certain BIOS settings, you can catch part of the kernel panic before the screen goes crazy. Codes that were visible depending on BIOS settings: kernel: type 1994916275 trap, code=0

SMP kernel/AMD64 stuck in reboot loop

I've got three identical boxes that all display the same behavior: Install of 5.6 or the March 18th 5.7 snapshot works, but is painfully slow (no disk access on the CD or disks while stalled) and on the first reboot, it gets about as far as loading wskbd before rebooting spontaneously. I'm