Sun Ultra 5 / Ultra 10 RAM (memory upgrade notes)

The memory supported by Sun Ultra 5 / Ultra 10 is EDO DRAM, but there are some limitations...

Specifications:

1. Voltage is 3.3 V.
2. Form factor is 168-pin DIMM.
3. RAM is ECC-enabled.
4. RAM is buffered.
5. Access latency is 50 ns or 60 ns (lesser means quicker, therefore better peformance).
6. Refresh addressing size is 8K rows.

Quirks:

• RAM must be installed in pairs of identical size, so there can be only 2 or 4 DIMMs in the system; 4 identical modules result in best performance.
• When different speed (50 ns and 60 ns) DIMMs are mixed, the resulting memory speed is the worst one (60 ns), therefore it's not preferable to mix them.
• OBP version >=3.25v3 and CPU speed >=360 MHz is needed to use 50 ns memory (particularly, made by Micron Technology). It's better to update your OBP firmware to the latest version (OpenBoot 3.31, Sun/Oracle patch-ID# 106121-18) before memory upgrade.
• Do not use 16 MiB modules (they use 10-bit column addressing), as they cannot be mixed with any others (which use 11-bit column addressing). Therefore, you can safely use only 32, 64, 128 and 256 MiB DIMMs.
• Ordinary 256 MiB memory modules are not supported in Ultra 5 because of their size (you can try to use some "low-profile" 256 MiB DIMMs which have reduced height; alternatively, you can try to fit the box casing of Ultra 5 for your needs).
• Maximum memory module size for Ultra 10 is 256 MiB (the height of the DIMM doesn't matter there).
  Thus, the possible maximum of total RAM size in Sun Ultra 5 / 10 is 1 GiB (1024 MiB).

Be careful when buying memory modules; it's not necessary to choose only Sun-branded ones, but you should make sure it is a 8K refresh addressing EDO DRAM. Please read memory module & chip datasheets and check part numbers in advance, if you can. If you install "4K refresh" memory, it will seem to work, but the system will be able to use only a half of it (e. g., if you installed 4 x 256 MiB DIMMs, the system would show there's only 512 MiB of RAM available instead of 1 GiB).
For example, if you buy Micron Technology memory, you should probably choose MT*LD*72FG-* models ("F" is for 8K refresh). E. g.: MT36LD3272FG-5 X is a proper memory (256 MiB, EDO, 50 ns, 8K refresh) and MT36LD3272G-5 X is not (256 MiB, EDO, 50 ns, but 4K refresh).

Tested Sun-branded modules (to be updated)

Sun P/N	Module specs	Module manufacturer	Module model	Chip manufacturer	Chip model
370-3799-01	256 MiB, 50 ns	Samsung	KMM372F3280CS1-5	Samsung	KM44V16004CS-5
370-3799-02M	256 MiB, 50 ns	Micron	MT36LD3272FG-5 X	Micron	MT4LC16M4G3DJ-5 F

References:

1. Ultra 10 memory issue - Nekochan Net
2. Sun Ultra 10 RAM question(s) - Ars Technica OpenForum
3. Memory - Ultra 5 / Ultra 10 (A21 / A22) - Sun System Handbook
4. Micron datasheets ("MT9LD(T)872(F)X, MT18LD(T)1672(F)(D)X, MT36LD(T)3272(C)(F)X - 8, 16, 32 Meg x 72 Buffered DRAM DIMMs - Micron DRAM module datasheet" etc.)
5. Samsung datasheets (misc.)

---
Last updated: 2017-01-17

HOWTO: change ext3 / ext4 file system reserved block count in Linux

By default, 5% of blocks in ext3 / ext4 filesystems (not sure about others) are reserved for emergency cases and can be used only by root user and privileged processes.
On big volumes the reserved space size can be enormous (e. g. 1000 GiB * 0.05 = 50 GiB).
Fortunately, this can be easily fixed.

First of all, issue one of the following commands (where /dev/sdb2 is your ext3/ext4 partition):

$ sudo dumpe2fs -h /dev/sdb2

or

$ sudo tune2fs -l /dev/sdb2

and check the "Reserved block count" and "Block size" parameters.
By default, "Block size" is 4096 bytes (or 4 KiB).

This can set reserved blocks to 1% (e. g. 10 GiB * 0.01 = 100 MiB):

$ sudo tune2fs -m 1 /dev/sdb2

Or you can set the total number of blocks (e. g. 100000 * 4096 = 409600000 or approx. less than 400 MiB):

$ sudo tune2fs -r 100000 /dev/sdb2

I think, reserve of 500 MiB is usually enough; you can even set the number of reserved blocks to 0 (zero), but it's not recommended.

References:

1. http://www.lisnichenko.com/articles/ext3-file-system-overhead-disclosed-part-1.html

HOWTO: recovering Linux hibernate functionality after modification of the swap partition

If you change the swap partition and forget about adjusting some settings, your GNU/Linux system can lose its hibernate functionality (it will hibernate, but not resume correctly — you'll lose your hibernated session if you boot with your default system settings).
Here follows a quick solution (tested in Debian & Ubuntu).

Assume you've created a new swap partition and listed it in /etc/fstab:

user@machine:~$ cat /etc/fstab | grep swap
UUID=12345678-12ab-cd34-5678-445566778800    none    swap    sw    0    0

You can also get the swap partition UUID with blkid command:

user@machine:~$ sudo blkid | grep swap
[sudo] password for user:
/dev/sda8: UUID="12345678-12ab-cd34-5678-445566778800" TYPE="swap"

Then you need to check and modify resume file to match the UUID of swap partition.

user@machine:~$ cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=12345678-0000-0000-0000-123456789012

As you can see, the UUID of resume partition is not correct. You can edit that file with any text editor you like (gedit, nano, vi etc.), e. g.:

$ sudo nano /etc/initramfs-tools/conf.d/resume

or

$ sudoedit /etc/initramfs-tools/conf.d/resume

or

$ gksu gedit /etc/initramfs-tools/conf.d/resume

After all these manipulations, it's needed to update the initramfs image (it's usually stored in a file named like 'initrd.img'):

$ sudo update-initramfs -u

Folks say there is an alternative temporary solution based on applying a kernel option like resume=/dev/sda8 (where /dev/sda8 is a hibernate / swap partition), but usually there's no reason to do that (except the urgent manual restoring of the badly hibernated session, at the boot time).

References:

1. https://help.ubuntu.com/community/UsingUUID