Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: 5.5.x, 5.4.x: PAGE FAULT crashes the system multiple times / 24h
 <- HELP needed
To:     Udo van den Heuvel <udovdh@xs4all.nl>
References: <36e8696a-fb99-23dc-c458-21824fc807fb@xs4all.nl>
Cc:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
From:   Kris Karas <linux-1993@moonlit-rail.com>
Message-ID: <c0549c08-074a-c15f-40d0-78e9d10dae4a@moonlit-rail.com>
Date:   Sat, 7 Mar 2020 21:13:39 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <36e8696a-fb99-23dc-c458-21824fc807fb@xs4all.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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