Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
Can't install 64b version on Dual Xeon setup
Re: Can't install 64b version on Dual Xeon setup
issue looks to be low level. Would compiling your own kernel on your config help ?
Re: Can't install 64b version on Dual Xeon setup
ThanksYou dang sure get A for effort.
Kernel compilation definitly looks a good idea, and I'll try that if nothing else works. But before, I wanted to test very old images, and here is a nice surprise, I have found debian-live-500-amd64-standard working fine !
Now I will try to find the latest image that works / the first that fails, and will surely let you know. I think it will help understanding what's wrong (could it be that past a certain point, kernel is built with SSE4, or any other extention that my CPU does not have ?)
- Head_on_a_Stick
- Posts: 14114
- Joined: 2014-06-01 17:46
- Location: London, England
- Has thanked: 81 times
- Been thanked: 133 times
Re: Can't install 64b version on Dual Xeon setup
Perhaps a kernel regression then. See https://wiki.debian.org/DebianKernel/GitBisect but you can't really follow that without a working system.bmx34 wrote:debian-live-500-amd64-standard working fine !
EDIT: confused nonsense removed.
deadbang
Re: Can't install 64b version on Dual Xeon setup
OK, now I have nailed down the first distribution causing issues : Jessie.
I can install 7.11, but 8.0.0 fails. Looks like a regression indeed.
Next step : have a look at GitBisect !
I can install 7.11, but 8.0.0 fails. Looks like a regression indeed.
Next step : have a look at GitBisect !
Re: Can't install 64b version on Dual Xeon setup
Make that A+ for effort.
Rampant speculation follows. It did cross my mind to suggest trying older kernels, though have zero clue what quality in terms of performance or other significant metrics such an install would be likely to have. Would be far too many question marks to endorse or advise anyone of such a course of action. Like many things could be a try it and see situation. Using older kernels on Buster. Have formerly installed archived software from former releases (gksu) and yep, continues working w/o problems. Might also focus on older versions of gnu/nix firmware. At some point software must be slated to being dropped and that system would reasonably be a candidate for that type of thing @15yrs. Can't be very many pc's that old still commonly in use.
As with so much else hardware related, comes back to kernel + firmware.
Rampant speculation follows. It did cross my mind to suggest trying older kernels, though have zero clue what quality in terms of performance or other significant metrics such an install would be likely to have. Would be far too many question marks to endorse or advise anyone of such a course of action. Like many things could be a try it and see situation. Using older kernels on Buster. Have formerly installed archived software from former releases (gksu) and yep, continues working w/o problems. Might also focus on older versions of gnu/nix firmware. At some point software must be slated to being dropped and that system would reasonably be a candidate for that type of thing @15yrs. Can't be very many pc's that old still commonly in use.
As with so much else hardware related, comes back to kernel + firmware.
Most powerful FREE tech-support tool on the planet * HERE. *
Re: Can't install 64b version on Dual Xeon setup
You can't believe your eyes if your imagination is out of focus.
Re: Can't install 64b version on Dual Xeon setup
Might have something to do with it. The date of that system, stems from a time Intel was just starting to release 64bit chips apparently. AMD beat them out, doing so in 2003, depending on reference ... Intel didn't follow until 04 or 2005. Looks like that architecture was abandoned in Jessie onwards.
https://wiki.debian.org/Ports/ia64
PS, not that overly matters, you got 64b. Should mean 64b Java, thus Minecrafty goodness for the younguns. Have said often just because x-software goes end-of-life clearly doesn't mean it ceases working or being perfectly good software.
https://wiki.debian.org/Ports/ia64
PS, not that overly matters, you got 64b. Should mean 64b Java, thus Minecrafty goodness for the younguns. Have said often just because x-software goes end-of-life clearly doesn't mean it ceases working or being perfectly good software.
Most powerful FREE tech-support tool on the planet * HERE. *
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: Can't install 64b version on Dual Xeon setup
Xeon processors are x86, not Itanium. Itanium (ia64) has nothing to do with x86_64 (amd64). They are totally unrelated architectures and processors.
Re: Can't install 64b version on Dual Xeon setup
It took me a few days of dichotomy in kernels, but now I know which is the first one failing.
3.4.113 is OK
3.5.1 fails.
I've had a look at the changelog (https://mirrors.edge.kernel.org/pub/lin ... eLog-3.5.1), and some changes are definilty cpu specific, but nothing obvious to me can explain my problem.
Bisect can now help me spoting the faulty commit I guess.
3.4.113 is OK
3.5.1 fails.
I've had a look at the changelog (https://mirrors.edge.kernel.org/pub/lin ... eLog-3.5.1), and some changes are definilty cpu specific, but nothing obvious to me can explain my problem.
Bisect can now help me spoting the faulty commit I guess.
Re: Can't install 64b version on Dual Xeon setup
Indeed, their is a 3.5. I did not noticed it because this version does not have a changelog file here : https://mirrors.edge.kernel.org/pub/linux/kernel/v3.x. I am not sure why.
But the code is definitly available, and I built it. If fails.
So the problem comes from a changelist between 3.4.113 and 3.5
But the code is definitly available, and I built it. If fails.
So the problem comes from a changelist between 3.4.113 and 3.5
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: Can't install 64b version on Dual Xeon setup
I don't know why, but changelogs for major x.y kernel versions (x.y.z are only stable bugfix releases) are not available any more at kernel.org. This is one of the reasons why I maintain my own clone of the kernel git repository and build the missing changelogs myself.
If you are interested, I uploaded ChangeLog-3.5 here : http://www.plouf.fr.eu.org/bazar/ChangeLog-3.5
It contains all commits between 3.4 (not 3.4.113) and 3.5.
If you are interested, I uploaded ChangeLog-3.5 here : http://www.plouf.fr.eu.org/bazar/ChangeLog-3.5
It contains all commits between 3.4 (not 3.4.113) and 3.5.
Re: Can't install 64b version on Dual Xeon setup
Hi
Here are some news about this issue :
I have found the faulty commit : 8e029fcdd8702719c9179317cae9ef84ebe7027e, on branch 'x86-trampoline-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
The problem is that with this change, the NX flag is being activated. In my case, it appears that my 2 CPUs are slightly different :
and while the first one supports the NX flag, the second does not... Seems that I got those CPUs just when Intel started to support the NX flag, and unfortunately, I have 2 different revisions.
I tried to rebuild a kernel without setting this flag, and it works fine. However, it is probably not great for security, as NX is all about malicious softwares...
Another workaround I found is to start with nosmp. In that case, I only use the first cpu, which supports NX, but I loose all the benefit of my dual cpu. Maybe physically switching my 2 CPU would also help, as the CPU 0 would then be the one not supporting NX... I did not had a look where the CPU flags are tested in the code.
I filled a bug report here : https://bugzilla.kernel.org/show_bug.cgi?id=207919
Here are some news about this issue :
I have found the faulty commit : 8e029fcdd8702719c9179317cae9ef84ebe7027e, on branch 'x86-trampoline-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
The problem is that with this change, the NX flag is being activated. In my case, it appears that my 2 CPUs are slightly different :
Code: Select all
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 3.40GHz
stepping : 1
microcode : 0x5
cpu MHz : 2800.000
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc pebs bts nopl pni dtes64 monitor ds_cpl est cid cx16 xtpr
bogomips : 6800.52
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 3
model name : Intel(R) Xeon(TM) CPU 3.40GHz
stepping : 4
microcode : 0xe
cpu MHz : 2800.000
cache size : 1024 KB
physical id : 3
siblings : 2
core id : 0
cpu cores : 1
apicid : 6
initial apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc pebs bts nopl pni dtes64 monitor ds_cpl est tm2 cid xtpr
bogomips : 6800.71
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:
I tried to rebuild a kernel without setting this flag, and it works fine. However, it is probably not great for security, as NX is all about malicious softwares...
Another workaround I found is to start with nosmp. In that case, I only use the first cpu, which supports NX, but I loose all the benefit of my dual cpu. Maybe physically switching my 2 CPU would also help, as the CPU 0 would then be the one not supporting NX... I did not had a look where the CPU flags are tested in the code.
I filled a bug report here : https://bugzilla.kernel.org/show_bug.cgi?id=207919
-
- Global Moderator
- Posts: 2680
- Joined: 2018-06-20 15:16
- Location: Colorado
- Has thanked: 41 times
- Been thanked: 196 times
Re: Can't install 64b version on Dual Xeon setup
Intersting, good work. I've intentionally mixed some mult-sockets and as you found it is the lowest common denominator match if it works. Some more modern stuff should run asymmetrically with respect to clocks and multipliers, but features need to match.
The correct cpu should be cheap!
The correct cpu should be cheap!
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: Can't install 64b version on Dual Xeon setup
You should be able to disable the NX bit without compiling a kernel, either in the BIOS settings, either by adding "noexec=off" to the kernel command line.bmx34 wrote:I tried to rebuild a kernel without setting this flag, and it works fine.
Not really about malicious software. Rather about software vulnerable to buffer overflow attacks.bmx34 wrote:However, it is probably not great for security, as NX is all about malicious softwares...
You cannot worry about disabling the NX bit and want to use a processor which does not support it at the same time. You must choose between security and performance.bmx34 wrote:Another workaround I found is to start with nosmp. In that case, I only use the first cpu, which supports NX, but I loose all the benefit of my dual cpu.
Note that nosmp will also disable multicore and hyperthreading on the active CPU. Probably not the best choice.
- Head_on_a_Stick
- Posts: 14114
- Joined: 2014-06-01 17:46
- Location: London, England
- Has thanked: 81 times
- Been thanked: 133 times
Re: Can't install 64b version on Dual Xeon setup
SMP is a potential source of *many* side-channel vulnerabilities and disabling it can actually increase performance for non-hyperthreaded applications.p.H wrote:Note that nosmp will also disable multicore and hyperthreading on the active CPU. Probably not the best choice.
deadbang
-
- Global Moderator
- Posts: 2680
- Joined: 2018-06-20 15:16
- Location: Colorado
- Has thanked: 41 times
- Been thanked: 196 times
Re: Can't install 64b version on Dual Xeon setup
Two different things with two different settings. Disabling hyperthreading can improve performance and does not disable multcore. nosmp does. In either case I use the bios, which can also limit the number of cores.Head_on_a_Stick wrote:SMP is a potential source of *many* side-channel vulnerabilities and disabling it can actually increase performance for non-hyperthreaded applications.p.H wrote:Note that nosmp will also disable multicore and hyperthreading on the active CPU. Probably not the best choice.
- Head_on_a_Stick
- Posts: 14114
- Joined: 2014-06-01 17:46
- Location: London, England
- Has thanked: 81 times
- Been thanked: 133 times
Re: Can't install 64b version on Dual Xeon setup
D'oh! Thanks for the correction. I was confusing SMP with SMT (again).CwF wrote:Two different things with two different settings.
deadbang
Re: Can't install 64b version on Dual Xeon setup
Unfortunatly, I do not have any option in the BIOS to deactivate NX, but I found in some Intel documents that "Mixing processors of different steppings but the same model (as per CPUID instruction) is supported". And I am not in this situation, as my CPUs are model 4/stepping 1 and model 3 stepping 4.
Still, I tried to physically swap my CPUs, so that CPU 0, that seems to be used to detect the capabilities of the system is the one without NX. The nice thing is that it seem to work fine ! In this configuration, I managed to start MX Linux, *once*...
The sad part is that during this swap, I must have damaged something on that old guy, as I now have huge unstatility and randomness : sometimes I even don't get the BIOS beep, sometimes it reboots by itself, crash, and sometimes I manage to boot... I checked memory, graphic card, swap again the CPUs, use a single CPU, etc... but for now, I did not managed to find were the problem is. I'll give it a few more hours of work until I declare it as RIP, but I am quite pessimist to manage to find a solution.
One thing for sure : for now, I have more than a Linux issue, and it seem that swapping the CPUs was a key workaround.
Still, I tried to physically swap my CPUs, so that CPU 0, that seems to be used to detect the capabilities of the system is the one without NX. The nice thing is that it seem to work fine ! In this configuration, I managed to start MX Linux, *once*...
The sad part is that during this swap, I must have damaged something on that old guy, as I now have huge unstatility and randomness : sometimes I even don't get the BIOS beep, sometimes it reboots by itself, crash, and sometimes I manage to boot... I checked memory, graphic card, swap again the CPUs, use a single CPU, etc... but for now, I did not managed to find were the problem is. I'll give it a few more hours of work until I declare it as RIP, but I am quite pessimist to manage to find a solution.
One thing for sure : for now, I have more than a Linux issue, and it seem that swapping the CPUs was a key workaround.