linux-kernel - Re: Kernel panic - not syncing: IO-APIC + timer doesn't work!

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cc298d3e-9a14-d3e1-025b-6bb1f8bfb4ae@broadcom.com>
Date:   Tue, 28 Jul 2020 10:30:18 -0700
From:   Scott Branden <scott.branden@...adcom.com>
To:     Thomas Gleixner <tglx@...utronix.de>, bp@...en8.de, x86@...nel.org,
        mingo@...hat.com
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Kernel panic - not syncing: IO-APIC + timer doesn't work!

Hi Thomas,

On 2020-07-28 1:22 a.m., Thomas Gleixner wrote:
> Scott,
>
> Scott Branden <scott.branden@...adcom.com> writes:
>> Bios now updated to latest.  Same kernel panic issue.  Log below.
>>
>> I think it is related to power cycling quickly.
>> Should APIC work if PC power cycled in a few seconds or is that the
>> problem?
> Yes, emphasis on should. Just to clarify, if you reboot it works and
> cold start works as well if power was off long enough?
So far I have only been able to reproduce the issue by cold start with power off for only a few seconds
before re-powering the system.  It has not failed via reboot yet that I remember.
Will have to keep my eye on whether using reboot is an issue or not.
And also keeping power off longer when doing a cold start.
>
>> [    0.000000] Linux version 5.8.0-rc6 (oe-user@...host) (x86_64-poky-linux-gcc (GCC) 10.1.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP Sat Jul 25 03:55:25 UTC 2020
>> [    0.000000] Command line: BOOT_IMAGE=/bzImage ima_policy=tcb
>> apic=debug ip=dhcp raid=noautodetect console=ttyS0,115200
>> root=/dev/nfs nfsroot=192.168.1.100:/nfs/vxc,hard,tcp,intr,v3 rootwait
>> nfsrootdebug
> The working dmesg and the failing console log are hard to compare
> because the latter does not contain debug level printks. Please add
> 'ignore_loglevel' to the command line parameters.
Please find attached the failed console log with ignore_loglevel.
>
> Thanks,
>
>         tglx
Regards,
Scott

View attachment "ignore_loglevel_fail.txt" of type "text/plain" (20976 bytes)