public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Mateusz Jonczyk <mat.jonczyk@o2.pl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Testers wanted: Atom netbooks with x86_64 disabled by BIOS
Date: Sun, 28 Mar 2021 00:25:51 +0100	[thread overview]
Message-ID: <20210327232551.GA20783@1wt.eu> (raw)
In-Reply-To: <20210327211322.121708-1-mat.jonczyk@o2.pl>

Hi,

On Sat, Mar 27, 2021 at 10:13:22PM +0100, Mateusz Jonczyk wrote:
> W dniu 27.03.2021 o 21:32, Mateusz Jonczyk pisze:
> > Hello,
> >
> > There are some netbooks with Intel Atom processors that have 64-bit
> > support disabled by BIOS. Theoretically, the processor supports 64-bit
> > operation, but BIOS allows only 32-bit code to run.
> >
> > I wonder whether the 64-bit mode is really disabled in the CPU or only
> > hidden in the CPUID flags. If the latter, the computer could be made to
> > run a 64-bit kernel.
> >
> > Similarly, there are some Pentium M processors that support PAE
> > (Physical Address Extensions), but do not show this in CPUID. They could
> > be made to run distributions that require PAE with the "forcepae" kernel
> > command line parameter.
> >
> > I would like to ask people with such netbooks to try to run a 64-bit kernel
> > with this patch applied.
> >
> > When a patched 64-bit kernel is run in `qemu-system-i386`, the virtual
> > machine restarts instantly. Without this patch in such a case a 64-bit
> > kernel hangs indefinitely (inside .Lno_longmode in head_64.S).
> 
> I have made two mistakes:
> - I left commented out code,
> - I have commented out lines with '#'. The code compiled though.
> 
> Attaching corrected patch, please excuse me.

FWIW I tested on my ASUS 1025C which runs on an Atom N2600 forced to
32-bit. I had already tried in the past but wanted to give it a try
again in case I'd have missed anything. Sadly it didn't work, I'm
still getting the "requires an x86-64 CPU" message.

Given these machines were really cheap, I've always suspected that they
employ cheaper, low-grade CPUs, possibly having been subject to reduced
tests where x86_64-specific parts were not even verified and might be
defective. This may explain why they forcefully disable long mode there,
but that's just speculation.

Cheers,
Willy

  reply	other threads:[~2021-03-27 23:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-27 20:32 Testers wanted: Atom netbooks with x86_64 disabled by BIOS Mateusz Jończyk
2021-03-27 21:13 ` Mateusz Jończyk
2021-03-27 23:25   ` Willy Tarreau [this message]
2021-03-28  1:07     ` Thomas Gleixner
2021-03-28  6:18       ` Willy Tarreau
     [not found]         ` <CAHp75Ve_Yhs3ib5yk=d-+bhb4vHpx-j6D4jGGBKuD2k1qv38Vg@mail.gmail.com>
2021-03-28 21:58           ` Willy Tarreau
2021-03-28 22:18             ` Thomas Gleixner
2021-03-29 10:59             ` Andy Shevchenko
2021-03-28 12:37       ` Mateusz Jończyk
2021-03-28 13:30         ` Willy Tarreau
2021-03-28 15:55           ` Willy Tarreau

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=20210327232551.GA20783@1wt.eu \
    --to=w@1wt.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mat.jonczyk@o2.pl \
    /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