Bug#652469: Fwd: Re: Bug#652469: Bug#652448: panic when booting on a machine with >= 4 GiB of RAM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Forward to 652469@bugs.debian.org I forgot, sorry.
- -------- Original Message --------
On 17.12.2011 15:49, Robert Millan wrote:
> I'm not sure how relevant is
> this factor but it is unexistant on GNU/kFreeBSD, so I think this
> should be accounted for when taking Linux as reference.
More or less unexisting. The very same candidates that would cause one
to remain on a IA32 user land because of non-free cruft on Linux mostly
also holds FreeBSD as it is typically the very same software people want
to run through the Linux emulation layer. Think of Flash and Google
Earth for example. That said I have no use for kfreebsd on a desktop and
I hence didn't try any of those programs under kfreebsd so far.
> Another likely difference is that kFreeBSD in PAE mode has major
> drawbacks (in particular we'd have to disable a bunch of drivers, see
> sys/i386/conf/PAE and URL I pasted before). All in all, I have the
> impression that using PAE would be unacceptable for the majority of
> i686 users.
That on the other hand is a good rationale not to use PAE. However, if
you read the discussion I noted there is no significant performance
improvement [on Linux] to use i686 over i486. Thus, users of 686 capable
CPUs may happily use the 486 branch, whereas people who need PAE need
686 anyway.
> Good question. TBH I really dislike adding new flavours for PAE
> unless SMP is merged. Then we'd only have to replace 686-smp with
> 686-pae instead of adding two new flavours.
We're not freezing tomorrow, maybe consider waiting for upstream
regarding SMP support upstream.
> I don't know if SMP option is really usable on uniprocessor hardware.
> FWIW, I've tested -smp flavours for 8.3 and 9.0 on an uniprocessor VM
> and both seem to work fine.
I would hope it is usable. If it weren't that would certainly be a bug
in the SMP code. However, there might be design decisions that make SMP
slower on uniprocessor hardware (or not - I don't know as said).
> Maybe we should discuss this with FreeBSD? We could even propose them
> to make SMP the default there.
That makes sense, yes. In particular I guess we shouldn't be inventing
use cases which aren't supported in such a configuration upstream either.
> Given that a PAE kernel has important drawbacks (like disabling a lot
> of drivers), I'd rather leave it to the user to explicitly install
> those kernels after a normal kFreeBSD is running.
I wrote that under the impression that such a kernel would crash on
systems with more than 4G RAM. That would leave people without
possibility to install kfreebsd. If that's sorted out, i.e. the bug has
been fixed I am for a non PAE kernel too. I do not think there would be
any benefit to use >= 4G RAM in the context of D-I.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJO7LFbAAoJEMcrUe6dgPNtMjQP/ArffA1pH++cbXkYrYKtDuWr
gSE/lPpPE8039iEfMIwlma3GE47YxYSf41L57dSfThnZ2nBtTMbt7QDuG+g1dEca
s9a5tuIf0QmruwNeiOkhFmxnowPbwmfrORGLS69caJYjc85pjfVQJD56NnB50pcO
j8fkr4DyqvG8wqzzSmkkOutaSHkwUm3UbZaemchA2OYlaP20NbhVzkGj9Ze36Nnx
2mYSj8F2XvwzlYwhUqT9puJlSfWCgeWYXQmoGw1+yo8rudkEN7aApUsrADUc4wi6
jP5TxykGtVoZm0Nd0q/+gPhBoddevQZs0afaXGUpltdGxXdw0SjdNWuQfLbqdxtF
q6CwTiSEevIirf7+Tqaqo60GVScWr6fwGMw5SnU98FC9lElDUJokN2/DWzeTfBW0
duwyC7lGqOlKeIzCbRYj/KOJDOEh7uT5kBXcD/Em18hBzC86ypjQZeYDOTrhJ+Jp
FNkjoQ+iGC9l1hC/sUWkEsSgX0MDFMGv8RAJ4kp42MAZZb4zl+6keDsU4L3/pgBA
Zc1Vlm9YmxkjAwqDD4NZWsUGsL8T2AgiZXO9oYU3Whgk2jfhStqq/d5hBmwOzbvy
hgx4dtGpdgsmfaaMts+uw66D0cHh6cag0w6WE0QgnXUhayW/yAVSZJpU7dS0NVIS
4gdTDnXPmAmF9TH+qWDr
=E/Ed
-----END PGP SIGNATURE-----
Reply to: