[Pi 3525] 64bit OS problems - random reboots with 4 GB RAM!

[oversized]

I plan to do the same - I don't need 64bit - just 4 GB in 32 bit

Anyways I flashed to new BIOS 1.09c and Ubuntu 9.10 amd64 edition works much better now! No reboot for over 30 min Multitasking.... everything was OK and then again reboot. But it's a step forward from Fujitsu, they should keep working on this BIOS thing.

I also tried Fedora x64 live and both acpi=off and mem=4096m kernel parameters don't give me 4 GB of RAM, around 3 GB just like in 32bit editions.

[oversized]

A little (big) update on this issue!

I'm typing this from my Pi 3525 / OpenSolaris 64bit!

What I've done: just removed one RAM slot (2GB) so now I'm running without any problems 64bit OS!!! That's the catch, something with memory controller must be wrong?! With only 2 GB (perhaps with 3 GB too) everything works fine, but when you cross the magic border of 4 GB, problems comes into action!

[oversized]

Ideas about LAN card drivers, etc. are wrong. FSC designed the Amilo Pi3540 with an incorrect memory controller! The device reports wronge values to the OS. I'll hope the FSC support will fix this some day.

http://www.amilo-forum.com/topic,2326,- ... html#p8578


We have ignition Memory controller is to blame for all this troubles and the 'good' news is the whole Amilo Pi series is involved!

[NeoLojik]

The issue isn't with the memory controller hardware. The chipset is a just a standard Intel GM45, if the flaw was in the chipset it would affect all laptops, from all manufacturers, using the GM45, not just the Pi series from FSC.

The real problem lies with the BIOS, which means it can be fixed with an updated one, but Fujitsu are very firm in their stance that their consumer laptops aren't designed for 64bit, and hence they refuse to fix it.

Again, this is a BIOS problem, NOT a hardware one. Physically there's nothing wrong with the Pi 3525/3540.

It's most likely an issue with remapping memory over the 4GB boundary, as reducing the system memory to less than 4GB solves the issue. That would also explain why restricting memory to less than 4GB works, as everything above the 4GB boundary is ignored. Unfortunately, as is the case with most laptop BIOS, all the advanced options in the BIOS are hidden from the end user. The BIOS itself is based on the new SecureCore from Phoenix, so you can't even edit the BIOS to re-enable all the advanced stuff. At this point, only Fujitsu could fix it.

My solution is just to use PAE (BIGMEM64G) on a 32bit Linux kernel. I can access all 4GB of RAM and don't have to worry about running 64bit.

Under Windows and Linux 64bit you can limit the RAM to 4095m and have a stable system, if you really need 64bit.

I know it's not exactly ideal, but it's hardly the end of the world is it?

[oversized]

NeoLojik, have you heard of 4-Gigabyte Tuning?

http://msdn.microsoft.com/en-us/library ... 85%29.aspx

On 32-bit editions of Windows, applications have 4 gigabyte (GB) of virtual address space available. The virtual address space is divided so that 2 GB is available to the application and the other 2 GB is available only to the system.

The 4-gigabyte tuning (4GT) feature, formerly called 4GT RAM Tuning, increases the virtual address space that is available to the application up to 3 GB, and reduces the amount available to the system to between 1 and 2 GB.

For applications that are memory-intensive, such as database management systems (DBMS), the use of a larger virtual address space can provide considerable performance and scalability benefits. However, the file cache, paged pool, and nonpaged pool are smaller, which can adversely affect applications with heavy networking or I/O. Therefore, you might want to test your application under load, and examine the performance counters to determine whether your application benefits from the larger address space.

To enable 4GT, use the BCDEdit /set command to set the increaseuserva boot entry option to a value between 2048 (2 GB) and 3072 (3 GB).

Windows Server 2003 and earlier: To enable 4GT, add the /3GB switch to the Boot.ini file. The /3GB switch is supported on the following systems:

* Windows Server 2003
* Windows XP Professional
* Windows 2000 Datacenter Server
* Windows 2000 Advanced Server

The /3GB switch makes a full 3 GB of virtual address space available to applications and reduces the amount available to the system to 1 GB. On Windows Server 2003, the amount of address space available to applications can be adjusted by setting the /USERVA switch in Boot.ini to a value between 2048 and 3072, which increases the amount of address space available to the system. This can help maintain overall system performance when the application requires more than 2 GB but less than 3 GB of address space.

Is that what it is? We can use 3 GB for applications, and the rest 1 GB for OS? That would mean full usage of 4 GB RAM on 32 bit OS?

I'm gonna give it a try on our Amilo Pi 3525

Also, about PAE and other methods:

Comparing PAE and other Large Memory Support

PAE, 4-gigabyte tuning (4GT), and Address Windowing Extensions (AWE) serve different purposes and can be used independently of each other:

* PAE allows the operating system to access and use more than 4 GB of physical memory.
* 4GT increases the portion of the virtual address space that is available to a process from 2 GB to up to 3 GB.
* AWE is a set of APIs that allows a process to allocate nonpaged physical memory and then dynamically map portions of this memory into the virtual address space of the process.


System Support for PAE

PAE is supported only on the following 32-bit versions of Windows running on x86-based systems:

* Windows 7 (32 bit only)
* Windows Server 2008 (32-bit only)
* Windows Vista (32-bit only)
* Windows Server 2003 (32-bit only)
* Windows XP (32-bit only)
* Windows 2000 Datacenter Server
* Windows 2000 Advanced Server

http://msdn.microsoft.com/en-us/library ... 85%29.aspx

[NeoLojik]

Oversized, the 4 gigabyte tuning has nothing to do with how much RAM an operating system can access. It's a method of letting 32bit applications access 3GB of memory instead of the usual 2GB which is the default for all Microsoft's consumer OS's.

Enabling PAE to access the full 4GB of RAM will only work on select Microsoft OS's, mainly their datacenter editions as it breaks many consumer drivers. It used to be possible in Windows XP, prior to service pack 1 or 2, I forget which, but it caused so many problems with drivers that it was eventually permanently disabled. Any information telling you how to enable it is wrong, it's not possible on their consumer OS's any more.

The only way to access the full 4GB of RAM is to run a BIGMEM64G enabled kernel under Linux. Even then, all the drivers being loaded require support for it and there is a minor performance penalty.

Even though XP and Vista say "Physical Address Extension" under the properties of "My Computer", it's only select parts needed for things like the No-Execute (NX) bit, it doesn't enable the 36bit memory access which is needed to access all 4GB of RAM in a 32bit OS.

Once again, this is 100% not a hardware fault, it's an issue with the BIOS, most likely with the memory remapping over the 4GB boundary, which Fujitsu refuses to fix.

Regardless. I'm happily running a 32bit Linux kernel with BIGMEM64G enabled and can happily access all 4GB of RAM without issue. It's just not possible under Windows, I'm sorry.

[oversized]

Oh, now I see... thanks!

So we can be assured that even M$ states PAE is available in certain systems, it is not possible? M$

When we're talking about Linux, I've read some users reported 8 GB of RAM on 32 bit Debian. Perhaps they got it with PAE kernel-enabled (BIGMEM64G)?

What Linux distro is yours?

I really hope Fujitsu will fix this in the next BIOS release.

[NeoLojik]

Oh, now I see... thanks!

So we can be assured that even M$ states PAE is available in certain systems, it is not possible? M$

When we're talking about Linux, I've read some users reported 8 GB of RAM on 32 bit Debian. Perhaps they got it with PAE kernel-enabled (BIGMEM64G)?

What Linux distro is yours?

I really hope Fujitsu will fix this in the next BIOS release.

The BIGMEM64G kernel allows up to 64GB or RAM to be used when running a 32bit kernel.
Under Ubuntu and Debian the PAE kernel is the same name as the normal kernels, it just has -pae at the end.

I'm currently running the Ubuntu 9.10 beta, with the PAE kernel. It runs great ^^

As for a BIOS update to solve it? I wouldn't hold out hope. Fujitsu themselves have stated they don't support 64bit OS's under any circumstances. I tried and failed to discuss this further with them.

[oversized]

Yes I got that, but I was just wondering whenever that user did recompiled kernel with BIGMEM64G or not, 'cuz he said that he doesn't know what PAE or BIGMEM64G is, and hence he's running a 32bit Debian 5.0 with full 8 GB of RAM usable. As we studied this case, it is theoretically impossible to use more than 4 GB (3.5 actually) on any 32 bit operating system. Of course without using, may I say your workaround with -PAE enabled.


@BIOS update: yes, I don't hope much either, but that's the only thing we can expect that would 100% solve this issue.
The good news is that Fujitsu Amilo Pi 3560 (first under Fujitsu's brand, without -Siemens) comes with full 64bit OS support, and even comes preinstalled with x64 Vista and 4 GB of RAM.




Cheers!

[NeoLojik]

Neat updated machine, but I find anything over 15.4" to cumbersome to be called "mobile".

I bought my Pi 3525 fully knowing about the 64bit issue. Under Linux, using a BIGMEM64G kernel there really isn't much point to running 64bit anyway. I can access all my RAM and don't have to worry about maintaining both 32bit and 64bit libraries.

Even if I was running Windows, the ~700MB RAM lost really isn't that big of a deal. I mean, 64bit computing really benefits things like databases, video editing and such. I've got a Core i5 PC running Vista 64bit for jobs like those.

Anyway, you never know, Fujitsu Seimens might one day decide to fix it, but I'm not fussed either way. I love my Pi 3525 just the way it is ^^

[supertorpe]

Hi, the last summer I bought the Amilo Pi 3525 with 4Gb of memory and its problems of random reboots with 64 bits OS.
I found this forum and finally decided to install Xubuntu 64bits booting with mem=4096m (hereinafter "the hack") that paradoxically makes for less than 4GB available, with the hope that Fujitsu issue a BIOS fix for the problem of memory remapping. This is what I've seen:

With the Hack:

Code: Select all

ercilla@ercilla-laptop:~$ free
             total       used       free     shared    buffers     cached
Mem:       3015984    2988880      27104          0       7404     754960
-/+ buffers/cache:    2226516     789468
Swap:      8827676    4345036    4482640

Without Hack:

Code: Select all

ercilla@ercilla-laptop:~$ free
             total       used       free     shared    buffers     cached
Mem:       3949424     709204    3240220          0      98020     265936
-/+ buffers/cache:     345248    3604176
Swap:      8827676          0    8827676

I invite you to analyze differences in the dmesg output. These are my results:

Without the Hack:

Code: Select all

[    0.000000] Command line: root=UUID=88483cf5-fee5-4553-b37a-737bd6c4fa9c ro quiet splash

With the Hack:

Code: Select all

[    0.000000] Command line: root=UUID=88483cf5-fee5-4553-b37a-737bd6c4fa9c ro quiet splash mem=4096m

With and without the Hack, next block is identical:

Code: Select all

[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009c400 (usable)
[    0.000000]  BIOS-e820: 000000000009c400 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000dc000 - 00000000000e0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000bd6a3000 (usable)
[    0.000000]  BIOS-e820: 00000000bd6a3000 - 00000000bd6a9000 (reserved)
[    0.000000]  BIOS-e820: 00000000bd6a9000 - 00000000bd7c3000 (usable)
[    0.000000]  BIOS-e820: 00000000bd7c3000 - 00000000bd80f000 (reserved)
[    0.000000]  BIOS-e820: 00000000bd80f000 - 00000000bd90d000 (usable)
[    0.000000]  BIOS-e820: 00000000bd90d000 - 00000000bdb0f000 (reserved)
[    0.000000]  BIOS-e820: 00000000bdb0f000 - 00000000bdb18000 (usable)
[    0.000000]  BIOS-e820: 00000000bdb18000 - 00000000bdb1f000 (reserved)
[    0.000000]  BIOS-e820: 00000000bdb1f000 - 00000000bdb65000 (usable)
[    0.000000]  BIOS-e820: 00000000bdb65000 - 00000000bdb9f000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000bdb9f000 - 00000000bdc00000 (ACPI data)
[    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)


With the Hack is shown a block that does not exists without it:

Code: Select all

[    0.000000] user-defined physical RAM map:
[    0.000000]  user: 0000000000000000 - 000000000009c400 (usable)
[    0.000000]  user: 000000000009c400 - 00000000000a0000 (reserved)
[    0.000000]  user: 00000000000dc000 - 00000000000e0000 (reserved)
[    0.000000]  user: 00000000000e4000 - 0000000000100000 (reserved)
[    0.000000]  user: 0000000000100000 - 00000000bd6a3000 (usable)
[    0.000000]  user: 00000000bd6a3000 - 00000000bd6a9000 (reserved)
[    0.000000]  user: 00000000bd6a9000 - 00000000bd7c3000 (usable)
[    0.000000]  user: 00000000bd7c3000 - 00000000bd80f000 (reserved)
[    0.000000]  user: 00000000bd80f000 - 00000000bd90d000 (usable)
[    0.000000]  user: 00000000bd90d000 - 00000000bdb0f000 (reserved)
[    0.000000]  user: 00000000bdb0f000 - 00000000bdb18000 (usable)
[    0.000000]  user: 00000000bdb18000 - 00000000bdb1f000 (reserved)
[    0.000000]  user: 00000000bdb1f000 - 00000000bdb65000 (usable)
[    0.000000]  user: 00000000bdb65000 - 00000000bdb9f000 (ACPI NVS)
[    0.000000]  user: 00000000bdb9f000 - 00000000bdc00000 (ACPI data)


Note that appears to be identical with "BIOS-provided physical RAM map" but missing the last line:

Code: Select all

   0000000100000000 - 0000000140000000 (usable)

With and without the hack there is a block "modified physical RAM map", but without the hack there is a line that not exists with the hack:

Code: Select all

[    0.000000]  modified: 0000000100000000 - 0000000140000000 (usable)

I think here is where the crux of the matter. Is there any way to force the memory block to reach the 4Gb?


There are more things, do not know whether providing information relevant to this problem ...

Without the hack there is a block that does not exists with it:

Code: Select all

[    0.000000] init_memory_mapping: 0000000100000000-0000000140000000
[    0.000000]  0100000000 - 0140000000 page 2M
[    0.000000] kernel direct mapping tables up to 140000000 @ 13000-19000
[    0.000000] last_map_addr: 140000000 end: 140000000


Without the hack:

Code: Select all

[    0.000000] (7 early reservations) ==> bootmem [0000000000 - 0140000000]
[    0.000000]   #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 0000001000]
[    0.000000]   #1 [0000006000 - 0000008000]       TRAMPOLINE ==> [0000006000 - 0000008000]
[    0.000000]   #2 [0000200000 - 0000b7cbb0]    TEXT DATA BSS ==> [0000200000 - 0000b7cbb0]
[    0.000000]   #3 [0037851000 - 0037fefff8]          RAMDISK ==> [0037851000 - 0037fefff8]
[    0.000000]   #4 [000009c400 - 0000100000]    BIOS reserved ==> [000009c400 - 0000100000]
[    0.000000]   #5 [0000010000 - 0000013000]          PGTABLE ==> [0000010000 - 0000013000]
[b][    0.000000]   #6 [0000013000 - 0000014000]          PGTABLE ==> [0000013000 - 0000014000][/b]



With the hack:

Code: Select all

[    0.000000] (6 early reservations) ==> bootmem [0000000000 - 00bdb65000]
[    0.000000]   #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 0000001000]
[    0.000000]   #1 [0000006000 - 0000008000]       TRAMPOLINE ==> [0000006000 - 0000008000]
[    0.000000]   #2 [0000200000 - 0000b7cbb0]    TEXT DATA BSS ==> [0000200000 - 0000b7cbb0]
[    0.000000]   #3 [0037851000 - 0037fefff8]          RAMDISK ==> [0037851000 - 0037fefff8]
[    0.000000]   #4 [000009c400 - 0000100000]    BIOS reserved ==> [000009c400 - 0000100000]
[    0.000000]   #5 [0000010000 - 0000013000]          PGTABLE ==> [0000010000 - 0000013000]


Is there a linux expert at the forum that can interpret these data?

[oversized]

Hi supertorpe...

you did a good job I beleive! But I think the only person here is mr. NeoLojik who can help you/us with this.

But I don't believe there's anything that it could be done without a new BIOS release :/

Have you tried PAE on Linux? Read previos NeoLojik's posts.


As it seems Fujitsu will NOT support 'former FSC' models. Which leaves us with a very little hope they'll ever made available new BIOS, drivers etc.

[supertorpe]

Hi oversized,

a few months ago I decided to install xubuntu 64 bit instead of 32 bits + pae thinking that fujitsu will release a patch for the BIOS. Now it would be very costly to reinstall everything (I use the laptop to work and I have a lot of software installed and configured). Furthermore, it appears that some drivers may not work well with PAE, which does not give me adequate safeguards.

[oversized]

Yes, I've read something about that...

but here are the good news


I managed to boot OpenSolaris with full 4 GB of RAM!


The result:

Code: Select all

load averages:  0.11,  0.12,  0.11;               up 0+01:29:19        16:38:05
76 processes: 70 sleeping, 5 stopped, 1 on cpu
CPU states: 97.7% idle,  1.9% user,  0.4% kernel,  0.0% iowait,  0.0% swap
Kernel: 724 ctxsw, 4 trap, 479 intr, 3229 syscall
Memory: 4057M phys mem, 3204M free mem


Memory: 4057M phys mem

Is that what it is?

This is 'top' command in terminal, it's slightly different then the same command in Linux.


Here's something more specific to Solaris:

Code: Select all

jack@opensolaris:~$ echo '::memstat' | pfexec mdb -k

Page Summary                Pages                MB  %Tot
------------     ----------------  ----------------  ----
Kernel                      57499               224    6%
Anon                       105508               412   10%
Exec and libs                2572                10    0%
Page cache                  17722                69    2%
Free (cachelist)            64094               250    6%
Free (freelist)            789058              3082   76%

Total                     1036453              4048
Physical                  1036452              4048

Note the last two lines: both 4048 MB


Direct from the device driver utility:

Memory Information:
Physical Memory: 4G (2G + 2G)
Maximum Memory Support: 4G
Memory Subsystem 0:
Array Used Function: System memory
Memory Error Correction Supported:None
Maximum Array Capacity: 4G
Number of Memory Devices: 2
Memory Device 0:
Memory Device Locator: M1
Total Width: 64
Data Width: 64
Installed Size: 2048M
Memory Device Type: DDR2
Speed: 800MHZ
Memory Device 1:
Memory Device Locator: M2
Total Width: 64
Data Width: 64
Installed Size: 2048M
Memory Device Type: DDR2
Speed: 800MHZ

What you need to do (OpenSolaris 2009.06):

To boot 32 bit (x86) kernel:

1. insert CD and boot

2. edit boot lines for the first highlighted option (OpenSolaris 2009.06)

in the both first and 2nd line REMOVE:

/$ISADIR

from: $kernel /platform/i86pc/kernel/$ISADIR/unix

so after removal the lines would look like this:

$kernel /platform/i86pc/kernel/unix
$boot /boot/x86.microroot

That will force load of x86 kernel on any x64 compatibile CPU.

In our issue, this will lead to stable system (32bit, i386) with full 4 GB of RAM usable.

The system will load krenel:

Code: Select all

jack@opensolaris:~$ isainfo -v
32-bit i386 applications
   sse4.1 ssse3 ahf cx16 mon sse3 sse2 sse fxsr mmx cmov sep cx8 tsc fpu

Now I'm waiting for somebody to deny this like 'man, that's not true the system is still unable to use full ~4GB of RAM... '

[NeoLojik]

Hello again all,

Thanks for the PM Supertorpe, I'm hoping I can clarify a few things for you. Figured I'd do it in the thread rather than via PM, so it's public.

The reason mem=4096m works is because it restricts the entire memory map to 4GB. On the Pi3525 and indeed in general, any memory over 3GB is "remapped" over the 4GB boundary as things like system resources have to reside in the 32bit address space. As any additional RAM is placed above the 4GB boundary, using mem=4096m effectively "cut's it off" and it's never used.

As for why there's an issue with the Pi3525 and 64bit when using all 4GB of RAM, I'm unsure. My tests seem to indicate that it's something to do with the ACPI support, as when booting a Gentoo x64 disk, it'll run quite happily if you don't load the ACPI modules at all. I'm not an advanced programmer, but at a guess I'd say something is corrupting memory, causing the reboot.

I use a 32bit Linux kernel with PAE enabled. All the hardware in the Pi3525 runs quite happily with PAE, though I'm not using any additional hardware so it's possible you are which is causing an issue.

Fujitsu have expressed no interest in fixing this problem, which I must emphasise is a software issue not a hardware one, and I know too little about EFI/BIOS's to go digging around for a solution.

Really we're left with 3 viable choices under Linux:
1) Run a 32bit kernel with PAE disabled (3GB RAM usable)
2) Run a 32bit kernel with PAE enabled (all 4GB RAM usable)
3) Run a 64bit kernel with mem=4096m (3GB RAM usable)

The forth isn't really viable for day-to-day use due to loosing ACPI:
4) Run a 64bit kernel with acpi=off (4GB RAM usable, no power management)

As for Windows, you're stuck with 3GB RAM no matter what. End-user versions of Windows don't support PAE, and I don't believe you can disable ACPI.

All the best.