Re: 14.0-CURRENT panic on boot, i386 VirtualBox client

2023-01-04 Thread Paul Floyd
On 04-01-23 11:24, Konstantin Belousov wrote: On Tue, Jan 03, 2023 at 11:38:55AM +0100, Floyd, Paul wrote: On 30/12/2022 01:54, Konstantin Belousov wrote: The backtrace is needed to make a further analysis. Any suggestions for getting a backtrace? I get the panic booting either the

VirtualBox: screenshots (was: 14.0-CURRENT panic on boot, i386 VirtualBox client)

2023-01-04 Thread Graham Perrin
On 04/01/2023 10:24, Konstantin Belousov wrote: … No idea how to take the virtual screen snapshot under VB. … For me, it's the Control key to the right + E OpenPGP_signature Description: OpenPGP digital signature

Re: 14.0-CURRENT panic on boot, i386 VirtualBox client

2023-01-04 Thread Konstantin Belousov
On Tue, Jan 03, 2023 at 11:38:55AM +0100, Floyd, Paul wrote: > > On 30/12/2022 01:54, Konstantin Belousov wrote: > > > > The backtrace is needed to make a further analysis. > > > Any suggestions for getting a backtrace? I get the panic booting either the > installer ISO or the VM image, both

Re: 14.0-CURRENT panic on boot, i386 VirtualBox client

2023-01-03 Thread Floyd, Paul
On 30/12/2022 01:54, Konstantin Belousov wrote: The backtrace is needed to make a further analysis. Any suggestions for getting a backtrace? I get the panic booting either the installer ISO or the VM image, both in VirtualBox. A+ Paul

Re: 14.0-CURRENT panic on boot, i386 VirtualBox client

2022-12-29 Thread Konstantin Belousov
On Thu, Dec 29, 2022 at 09:39:44AM +0100, Paul Floyd wrote: > > > On 28-12-22 18:12, Ronald Klop wrote: > > > > > I've had success to capture errors by recording the screen with my phone > > and playing back on slow speed. > > Another option might be to enable serial port for the console of

Re: 14.0-CURRENT panic on boot, i386 VirtualBox client

2022-12-29 Thread Paul Floyd
On 28-12-22 18:12, Ronald Klop wrote: I've had success to capture errors by recording the screen with my phone and playing back on slow speed. Another option might be to enable serial port for the console of the guest and capture the output. But I don't know if the default ISO uses that

Re: 14.0-CURRENT panic on boot, i386 VirtualBox client

2022-12-28 Thread Ronald Klop
On 12/28/22 17:45, Paul Floyd wrote: Hi For quite a few weeks I've been unable to boot 14.0-CURRENT i386 in a VirtualBox VM. I've tried both booting from iso image and the vmdk image. I get a kernel panic The host is running 13.1-RELEASE-p3 amd64 No problems with 14.0-CURRENT amd64 guests.

Re: 14.0-CURRENT panic on boot, i386 VirtualBox client

2022-12-28 Thread Paul Floyd
On 28-12-22 18:05, Graham Perrin wrote: If the guest has more than CPU, try reducing to one. A step further: try booting the guest in safe mode. Neither of those changed anything (I was using 2 CPUs) A+ Paul

Re: 14.0-CURRENT panic on boot, i386 VirtualBox client

2022-12-28 Thread Graham Perrin
On 28/12/2022 16:45, Paul Floyd wrote: … I haven't been able to see the last message before the panic as it scrolls past too quickly. Any suggestions for a working either how to get more info or what vbox settings to use? If the guest has more than CPU, try reducing to one. A step

14.0-CURRENT panic on boot, i386 VirtualBox client

2022-12-28 Thread Paul Floyd
Hi For quite a few weeks I've been unable to boot 14.0-CURRENT i386 in a VirtualBox VM. I've tried both booting from iso image and the vmdk image. I get a kernel panic The host is running 13.1-RELEASE-p3 amd64 No problems with 14.0-CURRENT amd64 guests. I haven't been able to see the last

Re: Today's 13-STABLE panic on boot

2021-02-06 Thread Gleb Popov
On Sat, Feb 6, 2021 at 4:55 PM Oleh Hushchenkov wrote: > Indeed, this fixes the panic, but now I have many messages like: > > rtsx0: Controller timeout for CMD8 > rtsx0: Controller timeout for CMD8 > rtsx0: Controller timeout for CMD55 > rtsx0: Controller timeout for CMD55 > rtsx0: Controller

Re: Today's 13-STABLE panic on boot

2021-02-06 Thread Oleh Hushchenkov
Indeed, this fixes the panic, but now I have many messages like: rtsx0: Controller timeout for CMD8 rtsx0: Controller timeout for CMD8 rtsx0: Controller timeout for CMD55 rtsx0: Controller timeout for CMD55 rtsx0: Controller timeout for CMD55 rtsx0: Controller timeout for CMD55 rtsx0: Controller

Re: Today's 13-STABLE panic on boot

2021-02-06 Thread Jesper Schmitz Mouridsen
From man rtsx   •   RTS522A on Lenovo P50s and Lenovo T470p, card detection and read-only    switch are reversed.  This is sovled by adding in loader.conf(5):     dev.rtsx.0.inversion=1 Perhaps this applies to Thinkpad T440p as well? On 06.02.2021 13.51, Oleh Hushchenkov wrote: As a

Re: Today's 13-STABLE panic on boot

2021-02-06 Thread Oleh Hushchenkov
As a workaround I disabled Realtek SD card reader RTS5227 in BIOS. Now system boots fine. However not all laptops have the setting to disable integrated devices... On Sat, Feb 6, 2021, 1:23 PM Oleh Hushchenkov wrote: > Looks like attached image was removed from the message. I uploaded it >

Re: Today's 13-STABLE panic on boot

2021-02-06 Thread Oleh Hushchenkov
Looks like attached image was removed from the message. I uploaded it https://imgur.com/a/Kv1l1pB On Sat, Feb 6, 2021, 11:42 AM Oleh Hushchenkov wrote: > On cold boot I got this panic, photo attached. Strange thing. After > enabling verbose logging system successfully booted and next reboots

Today's 13-STABLE panic on boot

2021-02-06 Thread Oleh Hushchenkov
On cold boot I got this panic, photo attached. Strange thing. After enabling verbose logging system successfully booted and next reboots also works without verbose logging. My hardware is ThinkPad T440p. ___ freebsd-current@freebsd.org mailing list

Re: Panic on boot with r353298 (last known working r35295)

2019-10-08 Thread Gary Jennejohn
__zenet- > Felad__: owner-freebsd-curr...@freebsd.org > [mailto:owner-freebsd-curr...@freebsd.org] Meghatalmaz__ Evilham > K__ldve: 2019. okt__ber 8. 11:00 > C__mzett: FreeBSD Current > T__rgy: Panic on boot with r353298 (last known working r35295) > > Hey, just a heads u

RE: Panic on boot with r353298 (last known working r35295)

2019-10-08 Thread M - Krasznai András
: FreeBSD Current Tárgy: Panic on boot with r353298 (last known working r35295) Hey, just a heads up that on a Lenovo A485 (AMD Ryzen processor), r353298 panics somewhat late in the boot process. r352925 is my last known working build. I am building GENERIC-NODEBUG. Sadly my pulse is shaky and I

Panic on boot with r353298 (last known working r35295)

2019-10-08 Thread Evilham
Hey, just a heads up that on a Lenovo A485 (AMD Ryzen processor), r353298 panics somewhat late in the boot process. r352925 is my last known working build. I am building GENERIC-NODEBUG. Sadly my pulse is shaky and I can't properly read the picture I took, it appears to say: Fatal trap 32:

Re: Panic on boot with r351461 (AMD ThreadRipper 2990WX)

2019-08-25 Thread Rebecca Cran
On 2019-08-25 10:55, Mark Johnston wrote: > > Can you please try applying this patch as well? Thanks, that fixed the panic and allows the system to fully boot again. -- Rebecca Cran ___ freebsd-current@freebsd.org mailing list

Re: Panic on boot with r351461 (AMD ThreadRipper 2990WX)

2019-08-25 Thread Mark Johnston
On Sun, Aug 25, 2019 at 10:27:48AM -0600, Rebecca Cran wrote: > On 2019-08-25 08:30, Konstantin Belousov wrote: > > > > So what happens, IMO, is that for memory-less domains ds_cnt is zero > > because ds_mask is zero, which causes the exception on divide. You > > can try the following combined

Re: Panic on boot with r351461 (AMD ThreadRipper 2990WX)

2019-08-25 Thread Rebecca Cran
On 2019-08-25 08:30, Konstantin Belousov wrote: > > So what happens, IMO, is that for memory-less domains ds_cnt is zero > because ds_mask is zero, which causes the exception on divide. You > can try the following combined patch, but I really dislike the fact > that I cannot safely use

Re: Panic on boot with r351461 (AMD ThreadRipper 2990WX)

2019-08-25 Thread Mark Johnston
On Sun, Aug 25, 2019 at 05:30:34PM +0300, Konstantin Belousov wrote: > On Sun, Aug 25, 2019 at 07:17:20AM -0600, Rebecca Cran wrote: > > On 2019-08-25 00:24, Konstantin Belousov wrote: > > > What are the panic messages ? > > > > Fatal trap 18: integer divide fault while in kernel mode > > > >

Re: Panic on boot with r351461 (AMD ThreadRipper 2990WX)

2019-08-25 Thread Konstantin Belousov
On Sun, Aug 25, 2019 at 07:17:20AM -0600, Rebecca Cran wrote: > On 2019-08-25 00:24, Konstantin Belousov wrote: > > What are the panic messages ? > > Fatal trap 18: integer divide fault while in kernel mode > > instruction pointer = 0x20:0x80f1027c > > stack pointer =

Re: Panic on boot with r351461 (AMD ThreadRipper 2990WX)

2019-08-25 Thread Rebecca Cran
On 2019-08-25 00:24, Konstantin Belousov wrote: > What are the panic messages ? Fatal trap 18: integer divide fault while in kernel mode instruction pointer = 0x20:0x80f1027c stack pointer = 0x28:0x845809f0 frame pointer = 0x28:0x84580a00 code segment = base 0x0, limit

Re: Panic on boot with r351461 (AMD ThreadRipper 2990WX)

2019-08-25 Thread Konstantin Belousov
On Sat, Aug 24, 2019 at 05:29:23PM -0600, Rebecca Cran wrote: > On 2019-08-24 17:08, Konstantin Belousov wrote: > > > > Use gdb instead. > > Ah, thanks. > > (gdb) info line *0x8117f67c > Line 405 of "/usr/src/sys/amd64/amd64/mp_machdep.c" starts at address > 0x8117f674 and ends

Re: Panic on boot with r351461 (AMD ThreadRipper 2990WX)

2019-08-24 Thread Rebecca Cran
On 2019-08-24 17:08, Konstantin Belousov wrote: > > Do you happen to have NUMA node without any local memory ? (Look at the > SRAT table). If yes, try this patch. I've just remembered, that's one of the big differences between ThreadRipper and EPYC: the EPYC has memory links on all four dies,

Re: Panic on boot with r351461 (AMD ThreadRipper 2990WX)

2019-08-24 Thread Rebecca Cran
On 2019-08-24 17:08, Konstantin Belousov wrote: > > Use gdb instead. Ah, thanks. (gdb) info line *0x8117f67c Line 405 of "/usr/src/sys/amd64/amd64/mp_machdep.c" starts at address 0x8117f674 and ends at 0x8117f69a > What was the previous bootable version of the kernel

Re: Panic on boot with r351461 (AMD ThreadRipper 2990WX)

2019-08-24 Thread Konstantin Belousov
On Sat, Aug 24, 2019 at 04:54:26PM -0600, Rebecca Cran wrote: > On 2019-08-24 14:33, Konstantin Belousov wrote: > > On Sat, Aug 24, 2019 at 02:22:18PM -0600, Rebecca Cran wrote: > >> instruction pointer = 0x20: 0x811bc664 > > So what is the source line for this address ? > > > I built a

Re: Panic on boot with r351461 (AMD ThreadRipper 2990WX)

2019-08-24 Thread Rebecca Cran
On 2019-08-24 14:33, Konstantin Belousov wrote: > On Sat, Aug 24, 2019 at 02:22:18PM -0600, Rebecca Cran wrote: >> instruction pointer = 0x20: 0x811bc664 > So what is the source line for this address ? I built a new kernel and got a new panic instruction pointer address of

Re: Panic on boot with r351461 (AMD ThreadRipper 2990WX)

2019-08-24 Thread Konstantin Belousov
On Sat, Aug 24, 2019 at 02:22:18PM -0600, Rebecca Cran wrote: > I updated my kernel to r351461 today and now get a panic on boot. > > > CPU: AMD Ryzen Threadripper 2990WX 32-Core Processor (2994.45-MHz > K8-class CPU) >   Origin="AuthenticAMD"  Id=0x800f82  Family

Panic on boot with r351461 (AMD ThreadRipper 2990WX)

2019-08-24 Thread Rebecca Cran
I updated my kernel to r351461 today and now get a panic on boot. CPU: AMD Ryzen Threadripper 2990WX 32-Core Processor (2994.45-MHz K8-class CPU)   Origin="AuthenticAMD"  Id=0x800f82  Family=0x17  Model=0x8  Stepping=2   Features=0x178bfbff   Features2=0x7ed8320b   AMD Features=0x2e50

Re: Strange panic at boot with vmm in loader.conf vs manually loading it

2018-10-15 Thread Mike Tancsa
On 10/14/2018 2:19 PM, Mateusz Guzik wrote: > On 10/14/18, Mike Tancsa wrote: >> On 10/13/2018 12:48 PM, Allan Jude wrote: >>> Strange that your crash is in ZFS here... >>> >>> Can you take a crash dump? >>> >>> It looks like something is trying to write to uninitialized memory here. >> I will

Re: Strange panic at boot with vmm in loader.conf vs manually loading it

2018-10-14 Thread Mateusz Guzik
On 10/14/18, Mike Tancsa wrote: > On 10/13/2018 12:48 PM, Allan Jude wrote: >> >> Strange that your crash is in ZFS here... >> >> Can you take a crash dump? >> >> It looks like something is trying to write to uninitialized memory here. > > I will need to pop in another drive or can I do a netdump

Re: Strange panic at boot with vmm in loader.conf vs manually loading it

2018-10-14 Thread Mike Tancsa
On 10/13/2018 12:48 PM, Allan Jude wrote: > > Strange that your crash is in ZFS here... > > Can you take a crash dump? > > It looks like something is trying to write to uninitialized memory here. I will need to pop in another drive or can I do a netdump at this point ?     ---Mike --

Re: Strange panic at boot with vmm in loader.conf vs manually loading it

2018-10-13 Thread Cy Schubert
In message <8f033c7c-af8f-1ebc-d787-548634f10...@freebsd.org>, Allan Jude write s: > On 10/12/2018 11:52, Mike Tancsa wrote: > > I am guessing this does not have anything to do with vmm being loaded, > > but hardware being initialized in a particular order? If I load vmm in > > loader.conf, the

Re: Strange panic at boot with vmm in loader.conf vs manually loading it

2018-10-13 Thread Allan Jude
On 10/12/2018 11:52, Mike Tancsa wrote: I am guessing this does not have anything to do with vmm being loaded, but hardware being initialized in a particular order? If I load vmm in loader.conf, the box panics at boot up.  However, manually loading it all seems to work.  Hardware is PRIME

Strange panic at boot with vmm in loader.conf vs manually loading it

2018-10-12 Thread Mike Tancsa
I am guessing this does not have anything to do with vmm being loaded, but hardware being initialized in a particular order? If I load vmm in loader.conf, the box panics at boot up.  However, manually loading it all seems to work.  Hardware is PRIME X370-PRO, AMD Ryzen 5 1600X 32G RAM.  FreeBSD

Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed)

2018-05-18 Thread Kevin Day
> On Apr 18, 2018, at 1:42 PM, John Baldwin wrote: >> >> Chenged made for it was >> >> Index: sys/x86/x86/nexus.c >> === >> --- sys/x86/x86/nexus.c (revision 332663) >> +++ sys/x86/x86/nexus.c (working copy) >>

Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed)

2018-04-18 Thread Vitalij Satanivskij
JB> O, this is a different issue. Sorry. As a hack, try changing JB> 'FIRST_MSI_INT' to 512 in sys/amd64/include/intr_machdep.h. The issue JB> is that some systems now include more than 256 interrupt pins on I/O JB> APICs, so IRQ 256 is already reserved for use by one of those JB> interrupt

Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed)

2018-04-18 Thread John Baldwin
On Wednesday, April 18, 2018 01:56:49 PM Vitalij Satanivskij wrote: > JB> > If you need any aditional information please tell me about. > JB> > JB> Can you perhaps turn off the stack trace on boot to not lose the panic > messages > JB> (remove KDB_TRACE from kernel config) and maybe modify the

Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed)

2018-04-18 Thread Vitalij Satanivskij
JB> > If you need any aditional information please tell me about. JB> JB> Can you perhaps turn off the stack trace on boot to not lose the panic messages JB> (remove KDB_TRACE from kernel config) and maybe modify the panic message to JB> include the IRQ number passed to nexus_add_irq? Hm

Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed)

2018-04-17 Thread John Baldwin
On Tuesday, April 17, 2018 10:15:53 PM Vitalij Satanivskij wrote: > Dear John > > I'm try patch with no success > > http://hell.ukr.net/panic/recorder_patch165.webm > > Also I'm enable verbose boot and record boot process (hpet was disabled so > crash in another driver atach) >

Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed)

2018-04-17 Thread Vitalij Satanivskij
Dear John I'm try patch with no success http://hell.ukr.net/panic/recorder_patch165.webm Also I'm enable verbose boot and record boot process (hpet was disabled so crash in another driver atach) http://hell.ukr.net/panic/recorder_patch_verbose.webm root@test:/usr/src # svnlite diff Index:

Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed)

2018-04-17 Thread John Baldwin
On Monday, April 16, 2018 10:12:13 PM Vitalij Satanivskij wrote: > > igb0@pci0:1:0:0:class=0x02 card=0x152115d9 chip=0x15218086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = 'I350 Gigabit Network Connection' > class = network > subclass

Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed)

2018-04-16 Thread Vitalij Satanivskij
Oh bios. It's already lastest bios for now with agesa 1.0.0.5 in it. It's dated 2/14/2018 So most likely new version will not appear soon Stephen Hurd wrote: SH> Yeah, this looks like some sort of general MSI issue, not igb specific. SH> I'm not familiar with that part of the kernel, but maybe

Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed)

2018-04-16 Thread Vitalij Satanivskij
Dear Stephen I'm disable msix on igb both 1 and 0 and enable HPET in bios get hpet_attach panic. http://hell.ukr.net/panic/recorder_hpet.webm so i disable hpet again and get msi_alloc and so on http://hell.ukr.net/panic/recorder_msi.webm So for test I'm set hw.pci.enable_msi=0 and get

Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed)

2018-04-16 Thread Vitalij Satanivskij
igb0@pci0:1:0:0:class=0x02 card=0x152115d9 chip=0x15218086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'I350 Gigabit Network Connection' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap

Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed)

2018-04-16 Thread Conrad Meyer
Hi Vitalij, On Mon, Apr 16, 2018 at 3:27 AM, Vitalij Satanivskij wrote: > DUMP can be found here http://hell.ukr.net/panic/panic.jpg > or even video record from screen http://hell.ukr.net/panic/recorder.webm Looks like the panic message is printed directly after: "igb0: using 2

Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed)

2018-04-16 Thread Vitalij Satanivskij
Hello. We have a kernel panic when loading current or 11.1 snapshot As while booting from usb steck or from hdd/ssd with installed system Kernel - GENERIC DUMP can be found here http://hell.ukr.net/panic/panic.jpg or even video record from screen http://hell.ukr.net/panic/recorder.webm

Re: ZFS panic at boot when mounting root on r330386

2018-03-04 Thread Andriy Gapon
On 05/03/2018 02:59, Bryan Drewery wrote: >> panic: solaris assert: refcount_count(>spa_refcount) > spa->spa_minref >> || MUTEX_HELD(_namespace_lock), file: >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c, line: 952 >> cpuid = 10 >> time = 1520207367 >> KDB: stack

ZFS panic at boot when mounting root on r330386

2018-03-04 Thread Bryan Drewery
> panic: solaris assert: refcount_count(>spa_refcount) > spa->spa_minref > || MUTEX_HELD(_namespace_lock), file: > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c, line: 952 > cpuid = 10 > time = 1520207367 > KDB: stack backtrace: > db_trace_self_wrapper() at

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-21 Thread Kyle Evans
On Wed, Feb 21, 2018 at 8:55 AM, Warner Losh wrote: > > > On Wed, Feb 21, 2018 at 6:58 AM, Kyle Evans wrote: >> >> On Wed, Feb 21, 2018 at 4:43 AM, Juan Ramón Molina Menor >> wrote: >> > Le 20/02/2018 à 22:45, Kyle Evans a écrit : >> >> >> >>

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-21 Thread Warner Losh
On Wed, Feb 21, 2018 at 6:58 AM, Kyle Evans wrote: > On Wed, Feb 21, 2018 at 4:43 AM, Juan Ramón Molina Menor > wrote: > > Le 20/02/2018 à 22:45, Kyle Evans a écrit : > >> > >> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor < > lis...@club.fr> > >>

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-21 Thread Rodney W. Grimes
> Le 20/02/2018 ? 22:45, Kyle Evans a ?crit?: > > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ram?n Molina Menor > > wrote: > >> [... snip ...] > >> > >> Moreover, the "boot [kernel]" loader command does not work: > >> > >> OK ls /boot/kernel.old/kernel > >>

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-21 Thread Kyle Evans
On Wed, Feb 21, 2018 at 4:43 AM, Juan Ramón Molina Menor wrote: > Le 20/02/2018 à 22:45, Kyle Evans a écrit : >> >> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor >> wrote: >>> >>> [... snip ...] >>> >>> Moreover, the "boot [kernel]" loader command does

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-21 Thread Juan Ramón Molina Menor
Le 20/02/2018 à 22:45, Kyle Evans a écrit : On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor wrote: [... snip ...] Moreover, the "boot [kernel]" loader command does not work: OK ls /boot/kernel.old/kernel /boot/kernel.old/kernel OK boot kernel.old Command failed

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-20 Thread Kyle Evans
On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor wrote: > [... snip ...] > > Moreover, the "boot [kernel]" loader command does not work: > > OK ls /boot/kernel.old/kernel > /boot/kernel.old/kernel > OK boot kernel.old > Command failed > OK boot /boot/kernel.old/kernel

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-20 Thread Juan Ramón Molina Menor
Le 19/02/2018 à 21:21, Kyle Evans a écrit :> Hello! On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor wrote: I have done a full build of r329555 to test the new Lua boot loader. Both the new and the old kernels panic after being loaded with: panic: running without

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-19 Thread Warner Losh
On Feb 19, 2018 3:38 PM, "Kyle Evans" wrote: On Mon, Feb 19, 2018 at 4:32 PM, Warner Losh wrote: > > > On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske wrote: >> >> >> >> > On Feb 19, 2018, at 2:21 PM, Kyle Evans wrote:

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-19 Thread Devin Teske
> On Feb 19, 2018, at 4:32 PM, Warner Losh wrote: > > > >> On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske wrote: >> >> >> > On Feb 19, 2018, at 2:21 PM, Kyle Evans wrote: >> > >> > It seems that the Forth loader might be doing

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-19 Thread Kyle Evans
gets sOn Mon, Feb 19, 2018 at 6:11 PM, Peter Lei wrote: > > > On 2/19/18 5:48 PM, Kyle Evans wrote: >> >> >> On Feb 19, 2018 5:44 PM, "Peter Lei" > > wrote: >> >> >> >> On 2/19/18 2:21 PM, Kyle Evans wrote: >> > Hello!

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-19 Thread Peter Lei
On 2/19/18 5:48 PM, Kyle Evans wrote: > > > On Feb 19, 2018 5:44 PM, "Peter Lei" > wrote: > > > > On 2/19/18 2:21 PM, Kyle Evans wrote: > > Hello! > > > > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor >

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-19 Thread Kyle Evans
On Feb 19, 2018 5:44 PM, "Peter Lei" wrote: On 2/19/18 2:21 PM, Kyle Evans wrote: > Hello! > > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor wrote: >> I have done a full build of r329555 to test the new Lua boot loader. >> >> Both the new and the

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-19 Thread Peter Lei
On 2/19/18 2:21 PM, Kyle Evans wrote: > Hello! > > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor > wrote: >> I have done a full build of r329555 to test the new Lua boot loader. >> >> Both the new and the old kernels panic after being loaded with: >> >> panic:

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-19 Thread Kyle Evans
On Mon, Feb 19, 2018 at 4:32 PM, Warner Losh wrote: > > > On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske wrote: >> >> >> >> > On Feb 19, 2018, at 2:21 PM, Kyle Evans wrote: >> > >> > It seems that the Forth loader might be doing something

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-19 Thread Warner Losh
On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske wrote: > > > > On Feb 19, 2018, at 2:21 PM, Kyle Evans wrote: > > > > It seems that the Forth loader might be doing something sneaky and > > replacing the standard common "boot" with a Forth boot that handles >

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-19 Thread Juan Ramón Molina Menor
Le 19/02/2018 à 21:21, Kyle Evans a écrit : Hello! On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor wrote: I have done a full build of r329555 to test the new Lua boot loader. Both the new and the old kernels panic after being loaded with: panic: running without

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-19 Thread Devin Teske
> On Feb 19, 2018, at 2:21 PM, Kyle Evans wrote: > > It seems that the Forth loader might be doing something sneaky and > replacing the standard common "boot" with a Forth boot that handles > this a lot better. CC'ing dteske@ so they can confirm. I can indeed confirm this

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-19 Thread Kyle Evans
On Mon, Feb 19, 2018 at 3:37 PM, Warner Losh wrote: > > > On Feb 19, 2018 1:23 PM, "Kyle Evans" wrote: > > Hello! > > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor > wrote: >> I have done a full build of r329555 to test the new Lua

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-19 Thread Juan Ramón Molina Menor
Le 19/02/2018 à 15:39, David Wolfskill a écrit : On Mon, Feb 19, 2018 at 03:21:50PM +0100, Juan Ramón Molina Menor wrote: I have done a full build of r329555 to test the new Lua boot loader. Both the new and the old kernels panic after being loaded with: panic: running without device atpic

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-19 Thread Warner Losh
On Feb 19, 2018 1:23 PM, "Kyle Evans" wrote: Hello! On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor wrote: > I have done a full build of r329555 to test the new Lua boot loader. > > Both the new and the old kernels panic after being loaded with: > >

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-19 Thread Kyle Evans
Hello! On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor wrote: > I have done a full build of r329555 to test the new Lua boot loader. > > Both the new and the old kernels panic after being loaded with: > > panic: running without device atpic requires a local APIC > > For

Re: ACPI panic on boot with new Lua loader and other minor issues

2018-02-19 Thread David Wolfskill
On Mon, Feb 19, 2018 at 03:21:50PM +0100, Juan Ramón Molina Menor wrote: > I have done a full build of r329555 to test the new Lua boot loader. > > Both the new and the old kernels panic after being loaded with: > > panic: running without device atpic requires a local APIC > > For reasons

ACPI panic on boot with new Lua loader and other minor issues

2018-02-19 Thread Juan Ramón Molina Menor
Moreover, the "boot [kernel]" loader command does not work: OK ls /boot/kernel.old/kernel /boot/kernel.old/kernel OK boot kernel.old Command failed OK boot /boot/kernel.old/kernel Command failed OK boot kernel Command failed I forgot that I tried starting with "unload", which seems to

ACPI panic on boot with new Lua loader and other minor issues

2018-02-19 Thread Juan Ramón Molina Menor
I have done a full build of r329555 to test the new Lua boot loader. Both the new and the old kernels panic after being loaded with: panic: running without device atpic requires a local APIC For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous message:

Re: panic on boot after SVN r328988

2018-02-16 Thread Olivier Houchard
Hi Michael, On Fri, Feb 16, 2018 at 10:13:07AM -0500, Michael Butler wrote: > On 02/16/18 10:05, Andrey V. Elsukov wrote: > > On 16.02.2018 17:44, Michael Butler wrote: > >>> do you have some specific optimization flags in make.conf? > >>> Can you show the output of `head -40

Re: panic on boot after SVN r328988

2018-02-16 Thread Michael Butler
On 02/16/18 10:05, Andrey V. Elsukov wrote: > On 16.02.2018 17:44, Michael Butler wrote: >>> do you have some specific optimization flags in make.conf? >>> Can you show the output of `head -40 /var/run/dmesg.boot`? >>> >> >> The only relevant flags in /etc/make.conf are .. >> >> CPUTYPE?=pentium3

Re: panic on boot after SVN r328988

2018-02-16 Thread Andrey V. Elsukov
On 16.02.2018 17:44, Michael Butler wrote: >> do you have some specific optimization flags in make.conf? >> Can you show the output of `head -40 /var/run/dmesg.boot`? >> > > The only relevant flags in /etc/make.conf are .. > > CPUTYPE?=pentium3 > KERNCONF=SARAH > NO_MODULES=YES > > Boot log

Re: panic on boot after SVN r328988

2018-02-16 Thread Michael Butler
On 02/16/18 09:31, Andrey V. Elsukov wrote: > On 16.02.2018 17:13, Michael Butler wrote: >> ipfw is compiled into the kernel not loaded as a module. > > Hi, > > do you have some specific optimization flags in make.conf? > Can you show the output of `head -40 /var/run/dmesg.boot`? > The only

Re: panic on boot after SVN r328988

2018-02-16 Thread Andrey V. Elsukov
On 16.02.2018 17:13, Michael Butler wrote: > ipfw is compiled into the kernel not loaded as a module. Hi, do you have some specific optimization flags in make.conf? Can you show the output of `head -40 /var/run/dmesg.boot`? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP

panic on boot after SVN r328988

2018-02-16 Thread Michael Butler
This is on a slow (and remote :-() i386 (kgdb) bt #0 0xc076bfe8 in doadump () #1 0xc076c008 in doadump () #2 0xc0d00ee0 in suspend_blocked () #3 0xcf607548 in ?? () #4 0xc076bd8b in kern_reboot () #5 0xc076c141 in vpanic () #6 0xc076c03b in panic () #7 0xc0ab5065 in trap_fatal () #8

Panic on Boot - Current AMD64

2018-02-08 Thread Juan Ramón Molina Menor
On Wed, Feb 07, 2018 at 12:18:26PM +0100, Juan Ramón Molina Menor wrote: J> > Same panic here with HEAD from this afternoon in a Lenovo ThinkPad S440 J> > with 4 GB. J> > J> > Workaround: break into the loader prompt and: J> > J> > set vm.boot_pages=120 J> > boot J> > J> > When booting

Re: Panic on Boot - Current AMD64

2018-02-07 Thread Gleb Smirnoff
On Wed, Feb 07, 2018 at 12:18:26PM +0100, Juan Ramón Molina Menor wrote: J> > Same panic here with HEAD from this afternoon in a Lenovo ThinkPad S440 J> > with 4 GB. J> > J> > Workaround: break into the loader prompt and: J> > J> > set vm.boot_pages=120 J> > boot J> > J> > When booting

RE: Panic on Boot - Current AMD64

2018-02-07 Thread M - Krasznai András
: Panic on Boot - Current AMD64 >> I get panic on boot from current kernel. >> Since last night - changes to vm system ? >> World is Current as of this morning >> >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 12.0-CURRENT #0 r

Panic on Boot - Current AMD64

2018-02-07 Thread Juan Ramón Molina Menor
I get panic on boot from current kernel. Since last night - changes to vm system ? World is Current as of this morning FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #0 r328948: Tue Feb 6 11:30:57 PST 2018 root at pozo.com <https://lists.freebsd.

Panic on Boot - Current AMD64

2018-02-06 Thread Juan Ramón Molina Menor
I get panic on boot from current kernel. Since last night - changes to vm system ? World is Current as of this morning FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #0 r328948: Tue Feb 6 11:30:57 PST 2018 root at pozo.com <https://lists.freebsd.

Panic on Boot - Current AMD64

2018-02-06 Thread Manfred Antar
I get panic on boot from current kernel. Since last night - changes to vm system ? World is Current as of this morning FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #0 r328948: Tue Feb 6 11:30:57 PST 2018 r...@pozo.com:/usr/src/sys/amd64/compile/pozo amd64

[SOLVED] Re: Kernel Panic On Boot after r327979

2018-01-15 Thread Pete Wright
On 01/15/2018 09:26, Pete Wright wrote: Hello, I updated an amd64 system last night to r327979 and it panics into gdb after rc attempts to mount local filesystems. The panic line is: Fatal trap 12: page fault while in kernel mode gdb states that it stopped at: Stopped at   

Kernel Panic On Boot after r327979

2018-01-15 Thread Pete Wright
Hello, I updated an amd64 system last night to r327979 and it panics into gdb after rc attempts to mount local filesystems. The panic line is: Fatal trap 12: page fault while in kernel mode gdb states that it stopped at: Stopped at    prison_allow+0x4    movq    0x30(%rdi),%rax Is this a

Re: r323412: Panic on boot (slab->us_keg == keg)

2017-09-13 Thread Mark Johnston
On Tue, Sep 12, 2017 at 10:34:00AM +0200, Raphael Kubo da Costa wrote: > Mark Johnston writes: > > > I think the bug is that keg_large_init() doesn't take > > sizeof(struct uma_slab) into account when setting uk_ppera for the keg. > > In particular, the bug isn't specific to

Re: r323412: Panic on boot (slab->us_keg == keg)

2017-09-12 Thread Andrey V. Elsukov
On 12.09.2017 06:35, Mark Johnston wrote: >> [...] >> FreeBSD/SMP: 2 package(s) x 14 core(s) x 2 hardware threads >> >> Also I determined that it can successfully boot with disabled >> hyper-threading. > > After the change to CACHE_LINE_SIZE, we have > sizeof(struct uma_zone) == 448 and

Re: r323412: Panic on boot (slab->us_keg == keg)

2017-09-12 Thread Raphael Kubo da Costa
Mark Johnston writes: > I think the bug is that keg_large_init() doesn't take > sizeof(struct uma_slab) into account when setting uk_ppera for the keg. > In particular, the bug isn't specific to the bootup process; it only > affects internal zones with an item size in the

Re: r323412: Panic on boot (slab->us_keg == keg)

2017-09-11 Thread Mark Johnston
On Mon, Sep 11, 2017 at 09:15:51PM +0300, Andrey V. Elsukov wrote: > On 11.09.2017 15:23, Andrey V. Elsukov wrote: > > --- trap 0xc, rip = 0x80d84870, rsp = 0x82193970, rbp = > > 0x821939b0 --- > > zone_import() at zone_import+0x110/frame 0x821939b0 > >

Re: r323412: Panic on boot (slab->us_keg == keg)

2017-09-11 Thread Raphael Kubo da Costa
Raphael Kubo da Costa writes: > "Andrey V. Elsukov" writes: > >> On 11.09.2017 15:23, Andrey V. Elsukov wrote: >> >>> --- trap 0xc, rip = 0x80d84870, rsp = 0x82193970, rbp = >>> 0x821939b0 --- >>> zone_import() at

Re: r323412: Panic on boot (slab->us_keg == keg)

2017-09-11 Thread Andrey V. Elsukov
On 11.09.2017 21:38, John Baldwin wrote: > On Monday, September 11, 2017 09:15:51 PM Andrey V. Elsukov wrote: >> On 11.09.2017 15:23, Andrey V. Elsukov wrote: >>> --- trap 0xc, rip = 0x80d84870, rsp = 0x82193970, rbp = >>> 0x821939b0 --- >>> zone_import() at

Re: r323412: Panic on boot (slab->us_keg == keg)

2017-09-11 Thread Raphael Kubo da Costa
"Andrey V. Elsukov" writes: > On 11.09.2017 15:23, Andrey V. Elsukov wrote: > >> --- trap 0xc, rip = 0x80d84870, rsp = 0x82193970, rbp = >> 0x821939b0 --- >> zone_import() at zone_import+0x110/frame 0x821939b0 >> zone_alloc_item() at

Re: r323412: Panic on boot (slab->us_keg == keg)

2017-09-11 Thread John Baldwin
On Monday, September 11, 2017 09:15:51 PM Andrey V. Elsukov wrote: > On 11.09.2017 15:23, Andrey V. Elsukov wrote: > > --- trap 0xc, rip = 0x80d84870, rsp = 0x82193970, rbp = > > 0x821939b0 --- > > zone_import() at zone_import+0x110/frame 0x821939b0 > >

Re: r323412: Panic on boot (slab->us_keg == keg)

2017-09-11 Thread Andrey V. Elsukov
On 11.09.2017 15:23, Andrey V. Elsukov wrote: > --- trap 0xc, rip = 0x80d84870, rsp = 0x82193970, rbp = > 0x821939b0 --- > zone_import() at zone_import+0x110/frame 0x821939b0 > zone_alloc_item() at zone_alloc_item+0x36/frame 0x821939f0 > uma_startup() at

Re: r323412: Panic on boot (slab->us_keg == keg)

2017-09-11 Thread Andrey V. Elsukov
On 11.09.2017 11:31, Raphael Kubo da Costa wrote: > I've recently tried to upgrade a HEAD VM (running on a Linux host with > QEMU) from r321082 to r323412. > > The new kernel panics right after I try to boot into it with: > > panic: Assertion slab->us_keg == keg failed at

  1   2   3   4   >