Linux kernels that support PAE can't boot on systems that lack PAE support. I wonder what the reason is for this restriction?
\/thinking out loud
Perhaps it was a design decision in terms of making it easier to design it that way vs not. Presumably, if it were not a restriction, the design of a pae kernel would need to detect the pae capability and if it did not exist turn off the pae code paths (default)/and turn on non-pae code paths that would allow a dual-capability in the kernel to handle both cases.
\/thinking out loud off
Given the Tails mission, and the fact that Linux pae-based kernels do not have support for non-pae processors, I agree that Tails should continue to support such systems as those folks with those computers may not have the resources to upgrade their processors.
As long as the Tails 64-bit ("amd64") flavor is compatible with Intel processors of that ilk - yes, I would be happy to learn it is not an actual issue.
[email protected] wrote (14 Jan 2015 12:14:30 GMT) :
> I strongly suspect that Tails releases do not support now and may never have
> supported PAE, which it should by default in order to prevent such problems.
We used to ship Debian's 486 + 686-pae flavours, and are now shipping
586 (without PAE nor SMP) + amd64. So indeed, if you're on 32-bit,
then you won't get PAE nor SMP.
See https://labs.riseup.net/code/issues/8485 for a discussion about
whether it's worth improving the situation for the kind of hardware
you have, and if yes how best to do it.
intrigeri<[email protected]> wrote:
>I'm curious what's your take on it, given the additional info I'm
>providing above, and what I wrote in note #3 on the #8485 ticket
With regard to note #3, I am curious why the (Debian)linux kernel folks thought it not necessary to generate an SMP version in linux-image-3.16.0-4-586 as that will probably remain a strong reason not to do so.
With regard to note #1, including a third kernel for SMP (linux-image-3.2.0-4-686-pae), seems to be a huge burden for those without multi-cores, however, does avoid the 4GB memory limit problem with PAE.
With regard to PAE versions not being able to boot on non-PAE capable processors, not having the extended memory features in the hardware should not be a requirement to not boot a PAE version since by definition it covers addressing memory up to the 4GB limit and would not require activation of detecting more than that amount of RAM. Go figure. While the PAE kernel specifically supports memory greater than 4GB, booting the PAE kernel on a rig with up to but not over 4GB should not be required to have over 4GB. So, I disagree with whomever on the point to require over 4GB on PAE capable processor rigs. The question boils down to upgrading hardware RAM vs. having to install a new kernel when you do - which would yield less work? upgrading RAM without needing to upgrade the kernel to support it vs. already having the kernel support to upgrade the RAM?
Conversely, rigs with up to but not over 4GB RAM do not specifically reguire a PAE capable kernel - i.e. there is no need for it. On the other hand, rigs with more than one core would benefit greatly with SMP, but then again there should not be a restriction on booting an SMP capable kernel on a single core processor rig, say for instance where there is room to populate more RAM on the motherboards. And while more RAM is desirable for SMP, it is also a benefit to single core processor rigs in terms of being able to run more different applications in RAM at the same time.
Along the same vein of argument, SMP capable kernel builds should be capable of executing on 1 or more core processor rigs, especially where single core processors may share a compatible motherboard with multi-core processors (however, this may not even exist as there may be different sockets that restrict the support of each). As for testing the speed up on one or more core processors, it is desirable to be able to test on the same machine utilizing 1-max processors to guage performance improvement without having to migrate the code being tested to a single-core processor rig to get the comparisons. This situation can easily be finessed if the design allows runtime parameters (i.e number of processors on which to run the code) to be controlled by the tester - I have done that after having designed a parallel run-time system for a parallel language on a multi-processor with over 20 processors with a tested lock collision rate of less than 1%.
As for either detecting the number of CPUs or Total amount of Memory prior to booting a specific kernel in order to determine which kernel is best to boot (PAE vs SMP), then the boot code would need to read the SMBIOS/DMIBIOS database to determine those capabilities. Otherwise, there are several commands (dmidecode and hwinfo) which can be run at the user level once a specific kernel is booted to determine those attributes which for your purposes as stated I assume to be after the fact of being able to determine which kernel is best to boot given the hardware's specific capability.
Reading Bug #8485 and Bug #8183, it looks like you have a feasible take on what develops down stream with regard to updates to the Debian baseline technology and will revisit the issues when the time is appropriate for your user population.
\/thinking out loud
Perhaps it was a design decision in terms of making it easier to design it that way vs not. Presumably, if it were not a restriction, the design of a pae kernel would need to detect the pae capability and if it did not exist turn off the pae code paths (default)/and turn on non-pae code paths that would allow a dual-capability in the kernel to handle both cases.
\/thinking out loud off
Given the Tails mission, and the fact that Linux pae-based kernels do not have support for non-pae processors, I agree that Tails should continue to support such systems as those folks with those computers may not have the resources to upgrade their processors.
As long as the Tails 64-bit ("amd64") flavor is compatible with Intel processors of that ilk - yes, I would be happy to learn it is not an actual issue.
[email protected] wrote (14 Jan 2015 12:14:30 GMT) :
> I strongly suspect that Tails releases do not support now and may never have
> supported PAE, which it should by default in order to prevent such problems.
We used to ship Debian's 486 + 686-pae flavours, and are now shipping
586 (without PAE nor SMP) + amd64. So indeed, if you're on 32-bit,
then you won't get PAE nor SMP.
See https://labs.riseup.net/code/issues/8485 for a discussion about
whether it's worth improving the situation for the kind of hardware
you have, and if yes how best to do it.
intrigeri<[email protected]> wrote:
>I'm curious what's your take on it, given the additional info I'm
>providing above, and what I wrote in note #3 on the #8485 ticket
With regard to note #3, I am curious why the (Debian)linux kernel folks thought it not necessary to generate an SMP version in linux-image-3.16.0-4-586 as that will probably remain a strong reason not to do so.
With regard to note #1, including a third kernel for SMP (linux-image-3.2.0-4-686-pae), seems to be a huge burden for those without multi-cores, however, does avoid the 4GB memory limit problem with PAE.
With regard to PAE versions not being able to boot on non-PAE capable processors, not having the extended memory features in the hardware should not be a requirement to not boot a PAE version since by definition it covers addressing memory up to the 4GB limit and would not require activation of detecting more than that amount of RAM. Go figure. While the PAE kernel specifically supports memory greater than 4GB, booting the PAE kernel on a rig with up to but not over 4GB should not be required to have over 4GB. So, I disagree with whomever on the point to require over 4GB on PAE capable processor rigs. The question boils down to upgrading hardware RAM vs. having to install a new kernel when you do - which would yield less work? upgrading RAM without needing to upgrade the kernel to support it vs. already having the kernel support to upgrade the RAM?
Conversely, rigs with up to but not over 4GB RAM do not specifically reguire a PAE capable kernel - i.e. there is no need for it. On the other hand, rigs with more than one core would benefit greatly with SMP, but then again there should not be a restriction on booting an SMP capable kernel on a single core processor rig, say for instance where there is room to populate more RAM on the motherboards. And while more RAM is desirable for SMP, it is also a benefit to single core processor rigs in terms of being able to run more different applications in RAM at the same time.
Along the same vein of argument, SMP capable kernel builds should be capable of executing on 1 or more core processor rigs, especially where single core processors may share a compatible motherboard with multi-core processors (however, this may not even exist as there may be different sockets that restrict the support of each). As for testing the speed up on one or more core processors, it is desirable to be able to test on the same machine utilizing 1-max processors to guage performance improvement without having to migrate the code being tested to a single-core processor rig to get the comparisons. This situation can easily be finessed if the design allows runtime parameters (i.e number of processors on which to run the code) to be controlled by the tester - I have done that after having designed a parallel run-time system for a parallel language on a multi-processor with over 20 processors with a tested lock collision rate of less than 1%.
As for either detecting the number of CPUs or Total amount of Memory prior to booting a specific kernel in order to determine which kernel is best to boot (PAE vs SMP), then the boot code would need to read the SMBIOS/DMIBIOS database to determine those capabilities. Otherwise, there are several commands (dmidecode and hwinfo) which can be run at the user level once a specific kernel is booted to determine those attributes which for your purposes as stated I assume to be after the fact of being able to determine which kernel is best to boot given the hardware's specific capability.
Reading Bug #8485 and Bug #8183, it looks like you have a feasible take on what develops down stream with regard to updates to the Debian baseline technology and will revisit the issues when the time is appropriate for your user population.
Hi,
[email protected] wrote (15 Jan 2015 13:47:09 GMT) :
> Thanks for the link to the discussion.
NP :)
> As for 32-bit vs 64-bit, the issues of whether to ship PAE vs SMP are two separate
> independent issues.
In theory, yes.
In practice, no, as the only Debian x86 kernel that supports non-PAE
systems ("586" flavour) hasn't SMP support.
> The 4GB memory limitation (without PAE) was a bug issue with Windows OSes
> historically. No reason that any Linux derived OS (Tails) should be strapped with the
> same old limitation.
Linux kernels that support PAE can't boot on systems that lack PAE
support. We want to support such systems, at least for a little
while more.
> My Desktop is my only computer, i.e. I do not have a laptop. My plans for sometime
> this year is to procure a new laptop with the capability of both multi-core (4|8
> processors), 32 GB, and hardware support for VT-x, VT-i, and VT-d in order to take
> advantage of the hardware instruction set that supports VM. Then I should be able to
> do some research using Qubes and other VM approaches available.
Woohoo!
> If under that new laptop hardware, Tails were not to support PAE, that would be very
> sad indeed.
On recent x86_64 hardware, Tails boots on our 64-bit ("amd64" flavour)
kernel, so you'll be happy to learn that it's not an actual issue :)
> BTW, with regard to Bug #8485 - PAE support is not just for SMP multi-core
> processors. In other words, solution 2) is preferable to 1) and 3) both of which make
> no sense whatsoever.
I'm curious what's your take on it, given the additional info I'm
providing above, and what I wrote in note #3 on the #8485 ticket.
Cheers,
--
intrigeri
_______________________________________________
tails-support mailing list
[email protected]
https://mailman.boum.org/listinfo/tails-support
To unsubscribe from this list, send an empty email to [email protected].
[email protected] wrote (15 Jan 2015 13:47:09 GMT) :
> Thanks for the link to the discussion.
NP :)
> As for 32-bit vs 64-bit, the issues of whether to ship PAE vs SMP are two separate
> independent issues.
In theory, yes.
In practice, no, as the only Debian x86 kernel that supports non-PAE
systems ("586" flavour) hasn't SMP support.
> The 4GB memory limitation (without PAE) was a bug issue with Windows OSes
> historically. No reason that any Linux derived OS (Tails) should be strapped with the
> same old limitation.
Linux kernels that support PAE can't boot on systems that lack PAE
support. We want to support such systems, at least for a little
while more.
> My Desktop is my only computer, i.e. I do not have a laptop. My plans for sometime
> this year is to procure a new laptop with the capability of both multi-core (4|8
> processors), 32 GB, and hardware support for VT-x, VT-i, and VT-d in order to take
> advantage of the hardware instruction set that supports VM. Then I should be able to
> do some research using Qubes and other VM approaches available.
Woohoo!
> If under that new laptop hardware, Tails were not to support PAE, that would be very
> sad indeed.
On recent x86_64 hardware, Tails boots on our 64-bit ("amd64" flavour)
kernel, so you'll be happy to learn that it's not an actual issue :)
> BTW, with regard to Bug #8485 - PAE support is not just for SMP multi-core
> processors. In other words, solution 2) is preferable to 1) and 3) both of which make
> no sense whatsoever.
I'm curious what's your take on it, given the additional info I'm
providing above, and what I wrote in note #3 on the #8485 ticket.
Cheers,
--
intrigeri
_______________________________________________
tails-support mailing list
[email protected]
https://mailman.boum.org/listinfo/tails-support
To unsubscribe from this list, send an empty email to [email protected].
_______________________________________________ tails-support mailing list [email protected] https://mailman.boum.org/listinfo/tails-support To unsubscribe from this list, send an empty email to [email protected].
