[lkml]   [2020]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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:
> 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!

 \ /
  Last update: 2020-03-08 03:14    [W:0.025 / U:4.620 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site