linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Chris Jones <chrisjones@spin.net.au>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: 3.1+ kernels unbootable
Date: Wed, 25 Apr 2012 14:44:52 +1000	[thread overview]
Message-ID: <20120425144452.32a803fe@notabene.brown> (raw)
In-Reply-To: <20120425142001.2cb7a79e@ubuntu>

[-- Attachment #1: Type: text/plain, Size: 2535 bytes --]

On Wed, 25 Apr 2012 14:20:01 +1000 Chris Jones <chrisjones@spin.net.au> wrote:

> On Wed, 25 Apr 2012 13:21:22 +1000
> NeilBrown <neilb@suse.de> wrote:
> 
> > You might like to try 
> >  a/ describing your current system in more detail.
> >  b/ describe what actually happens when you try to boot a 3.1+ kernel.
> >     It is rare that absolutely nothing happens.
> >     Also describe the provenance of these 3.1+ kernels (do you compile
> >     yourself, or get them from a distro or....)
> > 
> > NeilBrown
> 
> 
> Thanks Neil. I use standard x86_64 Intel CPU system with 2.0GB DDRII
> RAM on a Gigabyte GA-8VM800PMD-775-RH motherboard.
> 
> This happens on both Ubuntu and Fedora kernels. And in fact, any kernel
> 3.1 or above. It's not only very odd, but also very annoying.
> 
> I get to the boot screen and when I select ENTER to boot into the
> system, my screen goes black and then the system reboots. It's
> definitely a kernel issue as anything (as mentioned already) with
> kernel 3.0 or below works just fine.
> 

You have a couple of options here.

One is to use git-bisect to narrow down where the breakage is.  This means
building about a dozen or a score of kernels and testing each one and then
trying again.  If you are happy building your own kernels and have an
afternoon to spare this is probably a good idea.  There should be plenty of
instruction on the web about how to do this but if you cannot find any feel
free to ask.

The other is to try turning features off and debugging on.
Many distros have some sort of "fail-safe" boot option which disables things
like ACPI and known-problematic drivers... though with it failing so early
most drives won't have even tried to run.  I'd guess an ACPI problem, but
that is largely because I know almost nothing about ACPI so it is easy to
blame it.  So try adding "acpi=off" to the boot args.

Linux has a thing called 'early_printk' which allows messages to be displayed
even before the normal drivers are loaded.  I don't know much about enabling
that on an x86 system (I use it a lot on ARM though).  You need it enabled
when the kernel is compiled, and you need a boot arg to enable it too.  Maybe
if you manage to enable  that you might get some message printed.

Or maybe there is some other much more useful thing you can try and someone
else will chime in soon and tell me I don't know what I'm talking about and
explain in detail the right way so solve this problem - that would be awesome.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  reply	other threads:[~2012-04-25  4:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-25  2:49 3.1+ kernels unbootable Chris Jones
2012-04-25  3:21 ` NeilBrown
2012-04-25  4:20   ` Chris Jones
2012-04-25  4:44     ` NeilBrown [this message]
2012-04-25 15:34       ` Bjorn Helgaas
2012-04-29  2:21       ` Chris Jones
2012-05-21 21:40         ` Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120425144452.32a803fe@notabene.brown \
    --to=neilb@suse.de \
    --cc=chrisjones@spin.net.au \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).