Weblog entry #76 for dkg

Debian on Thecus N8800Pro
Posted by dkg on Tue 5 Apr 2011 at 20:07
Tags: ,
I recently set up debian on a Thecus N8800Pro. It seems to be a decent rackmount 2U chassis with 8 3.5" hot-swap SATA drives, dual gigabit NICs, a standard DB9 RS-232 serial port, one eSATA port, a bunch of USB 2.0 connectors, and dual power supplies. I'm happy to be able to report that Thecus appears to be attempting to fulfill their obligations under the GPL with this model (i'm fetching their latest source tarball now to have a look).

Internally, it's an Intel Core 2 Duo processor, two DIMMS of DDR RAM, and a PCIe slot for extensions if you like. It has two internally-attached 128MiB SSDs that it wants to boot off of.

The downsides as i see them:

BIOS
The BIOS only runs over VGA, which is not easy to access. I wish it ran over the serial port. It's also not clear how one would find an upgrade to the BIOS. dmidecode reports the BIOS as:
        Vendor: Phoenix Technologies, LTD
        Version: 6.00 PG
        Release Date: 02/24/2009
RAM
The mainboard has only two DIMM sockets. It came pre-populated with two 2GiB DDR DIMMs. memtest86+ reports those DIMMs clearly, but sees only 3070MiB in aggregate. The linux kernel also sees ~3GiB of RAM, despite dmidecode and lshw reporting that the two DIMM modules each are only 1GiB in size. I'm assuming this is a bios problem. Anyone know how to get access to the full 4GiB? Should i be reporting bugs on any of these packages?
SSDs
The internal SSDs are absurdly small and very slow for both reading and writing. This isn't a big deal because i'm basically only using them for the bootloader, kernel, and initramfs. But i'm surprised that they could even find 128MiB devices in these days of $10 1GiB flash units.
processor
/proc/cpuinfo reports two cores of a Intel(R) Core(TM)2 Duo CPU T5500 @ 1.66GHz, each with ~3333 bogomips, and apparently without hardware virtualization support. It's not clear to me whether the lack of virtualization support is something that could be fixed with a BIOS upgrade.

I used Andy Millar's nice description of how to get access to the BIOS -- I found i didn't need a hacksaw to modify the VGA cable i had. just pliers to remove the outer metal shield on the side of the connector i plugged into the open socket.

lshw sees four SiI 3132 Serial ATA Raid II Controller PCI devices, each of which appears to support two SATA ports. I'm currently using only four of the 8 SATA bays, so i've tried to distribute the disks so that each of them is attached to an independent PCI device (instead of having two disks on one PCI device, and another PCI device idle). I don't know if this makes a difference, though, in the RAID10 configuration i'm using.

There's also a neat 2-line character-based LCD display on the front panel which apparently can be driven by talking to a serial port, though i haven't tried. Apparently there are also LEDs that might be controllable directly from the kernel via ICH7 and GPIO, but i haven't tried that yet either.

Any suggestions on how to think about or proceed with a BIOS upgrade to get access to the full 4GiB of RAM, BIOS-over-serial, and/or enable hardware virtualization?

 

Comments on this Entry

Posted by Anonymous (188.222.xx.xx) on Tue 5 Apr 2011 at 20:26
Sweet. I've just sold on an n2100 that I ran Debian on for years. It's good to see the company still churning out F/OSS based products!

[ Parent | Reply to this comment ]

Posted by Anonymous (82.17.xx.xx) on Tue 5 Apr 2011 at 22:57
ark.intel.com/Product.aspx?id=27253 says no hardware VT-x for that CPU so a BIOS update won't help unfortunately.

At work we put together one of these www.mini-itx.com/store/?c=51 quite nice little hardware and works well with Linux. A bit slow but can fit 2 m-itx motherboards in 1u with a psu each!

sno

[ Parent | Reply to this comment ]

Posted by Anonymous (141.3.xx.xx) on Tue 5 Apr 2011 at 22:59

The processor doesn't have VT-x according to Intel [see hxxp:ark.intel.com/Product.aspx?id=27253 the processor's ark page (no link because your site harasses non-registered users)]. You also didn't show the kernel you booted. It needs to support PAE/bigmem to access more RAM. Even then you could theoretically be restricted by the chipset, though, like some Thinkpads which only support 3 GB.

-- Philipp Kern

[ Parent | Reply to this comment ]

Posted by Ben_Hutchings (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Tue 5 Apr 2011 at 23:00
"The mainboard has only two DIMM sockets. It came pre-populated with two 2GiB DDR DIMMs. memtest86+ reports those DIMMs clearly, but sees only 3070MiB in aggregate. The linux kernel also sees ~3GiB of RAM, despite dmidecode and lshw reporting that the two DIMM modules each are only 1GiB in size. I'm assuming this is a bios problem. Anyone know how to get access to the full 4GiB? Should i be reporting bugs on any of these packages?"

Are you using the '686' kernel flavour? That doesn't use PAE.

debian-installer is supposed to pick the '686-bigmem' flavour (using PAE) on machines with RAM above the 4GB mark.

[ Parent | Reply to this comment ]

Posted by dkg (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Tue 5 Apr 2011 at 23:05
[ View dkg's Scratchpad | View Weblogs ]
i'm using debian's amd64 archive (squeeze), so the kernel i'm using is 2.6.32-5-amd64.

[ Parent | Reply to this comment ]

Posted by Ben_Hutchings (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Tue 5 Apr 2011 at 23:17
Boot log, please?

[ Parent | Reply to this comment ]

Posted by dkg (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Tue 5 Apr 2011 at 23:42
[ View dkg's Scratchpad | View Weblogs ]
Boot log temporarily on paste.debian.net. Thanks for the attention to this, Ben. I'll happily move this discussion over to the BTS if you tell me what package i should be reporting a bug against.

note that memtest86+ also saw only 3GiB of RAM.

[ Parent | Reply to this comment ]

Posted by Ben_Hutchings (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Tue 5 Apr 2011 at 23:58
Looks like a BIOS bug. It's not reporting any RAM above 4GB in the 'e820' map, which is the way the kernel discovers which RAM it can use. (DMI will tell you where the RAM is but not which addresses are reserved for video or firmware use.)

[ Parent | Reply to this comment ]

Posted by dkg (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Wed 6 Apr 2011 at 00:20
[ View dkg's Scratchpad | View Weblogs ]
I think you're talking about this part of the bootlog:
Apr  5 12:58:41 wiggum kernel: [    0.000000] BIOS-provided physical RAM map:
Apr  5 12:58:41 wiggum kernel: [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
Apr  5 12:58:41 wiggum kernel: [    0.000000]  BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
Apr  5 12:58:41 wiggum kernel: [    0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
Apr  5 12:58:41 wiggum kernel: [    0.000000]  BIOS-e820: 0000000000100000 - 00000000bfde0000 (usable)
Apr  5 12:58:41 wiggum kernel: [    0.000000]  BIOS-e820: 00000000bfde0000 - 00000000bfde3000 (ACPI NVS)
Apr  5 12:58:41 wiggum kernel: [    0.000000]  BIOS-e820: 00000000bfde3000 - 00000000bfdf0000 (ACPI data)
Apr  5 12:58:41 wiggum kernel: [    0.000000]  BIOS-e820: 00000000bfdf0000 - 00000000bfe00000 (reserved)
Apr  5 12:58:41 wiggum kernel: [    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
Apr  5 12:58:41 wiggum kernel: [    0.000000]  BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
Apr  5 12:58:41 wiggum kernel: [    0.000000] DMI 2.2 present.
Apr  5 12:58:41 wiggum kernel: [    0.000000] Phoenix BIOS detected: BIOS may corrupt low RAM, working around it.
Apr  5 12:58:41 wiggum kernel: [    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
Apr  5 12:58:41 wiggum kernel: [    0.000000] last_pfn = 0xbfde0 max_arch_pfn = 0x400000000
I believe the system only has a 4GiB of physical RAM. Are you suggesting that some of that RAM is actually above the 4GiB address but the BIOS isn't reporting it? Or rather that the reserved regions (or that the gap between 0xbfe00000 and 0xe0000000 should be marked "usable" for another half-gig at least?

Any idea what i could do to work around a BIOS bug like this? I wish coreboot was available for this mainboard :/

Thanks for helping me understand what's going on here, Ben!

[ Parent | Reply to this comment ]

Posted by Ben_Hutchings (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Wed 6 Apr 2011 at 00:35
"I believe the system only has a 4GiB of physical RAM. Are you suggesting that some of that RAM is actually above the 4GiB address but the BIOS isn't reporting it?"

Most BIOSes map memory-mapped peripherals below the 4GB address, and reserve 512MB or more address space for them. This is done for compatibility with older operating systems and peripherals that only work with 32-bit addresses. So if you have 4GB RAM then some of it should be mapped above the 4GB address.

"Or rather that the reserved regions (or that the gap between 0xbfe00000 and 0xe0000000 should be marked "usable" for another half-gig at least?"

That's also possible.

"Any idea what i could do to work around a BIOS bug like this?"

Upgrading the BIOS is the only good option.

However you could experiment with the 'memmap' kernel parameter (http://www.kernel.org/doc/Documentation/kernel-parameters.txt) to find out whether the missing 1GB is accessible.

[ Parent | Reply to this comment ]

Posted by pabs (122.104.xx.xx) on Wed 6 Apr 2011 at 01:38
It would be great if you could contribute to the InstallingDebianOn documentation:

https://wiki.debian.org/InstallingDebianOn
https://wiki.debian.org/InstallingDebianOn/HowToContribute

[ Parent | Reply to this comment ]