linux-kernel - Re: 5.5.x, 5.4.x: PAGE FAULT crashes the system multiple times / 24h <- HELP needed

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] [day] [month] [year] [list]

Message-ID: <c0549c08-074a-c15f-40d0-78e9d10dae4a@moonlit-rail.com>
Date:   Sat, 7 Mar 2020 21:13:39 -0500
From:   Kris Karas <linux-1993@...nlit-rail.com>
To:     Udo van den Heuvel <udovdh@...all.nl>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: 5.5.x, 5.4.x: PAGE FAULT crashes the system multiple times / 24h
 <- HELP needed

Udo van den Heuvel wrote:
> I need help with this bug:
> https://bugzilla.kernel.org/show_bug.cgi?id=206191
> How can I proceed when the bisect kernel becomes unbootable?

Hi Udo,
I have a few general suggestions you can try.

1.  Read the manpage on git-bisect(1), particularly the section about 
"git bisect skip," which attempts to ask git to bypass a test kernel 
that doesn't boot.

2.  If that doesn't work for you, when "bit bisect good/bad" tells you 
about what it will do next, try "git bisect visualize" to see a printout 
of what it will try.  Then, using that, try to pick your own place.  For 
example, you can say, "git reset --hard HEAD~3" to move the bisect 
midpoint three commits earlier, in the hope that that place will let you 
get a booting kernel.  (I'm not a wizard when it comes to git-bisect; 
I'm sure there are other people who can suggest better discipline in 
working your way through a non-booting test-case.)

3.  I have had bad luck with Gigabyte motherboards, and am not alone in 
that experience.  On my gigabyte motherboard, conflicting memory and I/O 
ranges are programmed into the BIOS in such a way that the kernel will 
attempt to allocate space that the BIOS is using but forgot to mention; 
when this happens, the kernel locks up and/or oopses.  To get around it, 
I have to patch the kernel with a "fake" resource reservation such that 
there are no overlaps.  One thing that helps here is to turn off the 
IOMMU; from your bugzilla report, it looks as if your kernel has found 
the IOMMU and is trying to use it.  The vanilla kernel runs just fine on 
my Gigabyte board, if I disable the IOMMU; but then I lose USB3 and can 
only use USB2 peripherals.

Good luck!
Kris