Intel D945GCLF2 (Atom 330) Boot Issues

J

jef

The quick summary is that, with 7.2-RELEASE AMD64 DVD on the Intel D945GCLF2, disks seem to only be able to be made and identified as "bootable" once -- after which any any changes (while booted from the DVD or another drive) using sysinstall or fixit tools (or gpt or gpart) seem to result in the drive not being identified by the BIOS as bootable, with no clear method to recover.

I know these boards will run with an existing i386 drive that has gone from 7.0-RELEASE to 7.2-RELEASE using freebsd-update.

These boards will boot from the DVD and identify as an amd64 kernel (with all four cores active).

On the rare occasions I've gotten a recognized FreeBSD install on a hard drive or USB stick, it has run the amd64 kernel and binaries.

Two different MBs and five different drives, on PATA, SATA, and even UMASS have exhibited the same symptoms.

The BIOS has been updated to the latest (and, as delivered, is newer than that referred to in other posts here), with no change in behavior.

I have not been able to determine a reliable path to getting that sysinstall-created successful install once the drive on the board has been "broken" -- this includes
# dd if=/dev/zero of=/dev/ad0 bs=512 count=1M​
(excessive, but I even let it write the drive overnight with no count limit, in case there was something I didn't know about on the drive) and
# fdisk -Bi​
(which does not mark all partitions as "unused" as I would expect from the man page) and deleting all slices and partitions in sysinstall or sade. I've given up on trying to use gpt or gpart until I can just get a "normal" install to be reliable.

One "curious" thing, that I don't remember seeing in my history with FreeBSD going back to the 3.x releases (when "buildworld" took a day if the phase of the moon was right) is that
dmesg is persisting through reboots,​
even when booting from DVD.

Is this something seen now, or could this be part of the cause?

TIA,

jef
 
Intel D945GCLF2 BIOS/MB design problems

This appears to be a BIOS/MB issue endemic to the 945 boards, not a FreeBSD issue, per se.

http://www.ocztechnologyforum.com/forum/showthread.php?p=398859 is one great piece of detective work, which I haven't completely comprehended yet, but points to the same problems and lack of solutions.

http://communities.intel.com/message/25506 is another (Windows) user with apparently similar problems.

So far, Intel's response has been that my Corsair VS2GB667D2 is not on their approved memory list (although the VS1GB667D2 is) and I have to use tested, supported memory to get past 1st-tier support. I'll be dealing with getting one of those in to see if they have any answer.

Until this is resolved, as tempting as it is, I can't recommend this board for purchase.
 
Something To Try

jef said:
.......One "curious" thing, that I don't remember seeing in my history with FreeBSD going back to the 3.x releases (when "buildworld" took a day if the phase of the moon was right) is that
dmesg is persisting through reboots,​
even when booting from DVD.

Is this something seen now, or could this be part of the cause?

TIA,

jef
Click to expand...

Hi

Indeed that's the smoking gun.

The BIOS default setting for the power switch is a bit "interesting" on this board. Rather than turning the board off, it puts it into sleep mode. A four second press of the button turns the board "power off".

Since it's sleep mode, the OS is sitting in RAM ready to go. That's the good news. Since it's in sleep mode, it may be flaky about recognizing drives - that's the bad news.

Reset the bios for power off, rather than sleep and I'm betting the board behaves more like you expect it to. If you still have issues, go into the advanced settings and give it a bit more time to recognize drives. The board can indeed boot so fast that the drives never init ...

The same issue seems to be hitting the people in the threads you referance.

Have Fun !

Bob
 
Thanks for the suggestions!

pa_fun said:
Reset the bios for power off, rather than sleep and I'm betting the board behaves more like you expect it to.
Click to expand...

I didn't see any options for this in the setup. I have tried various combination of WOL and wake/restore-on-power with no change in behavior. I didn't see anything else that seemed to relate to S1 vs S3 or S5 in the BIOS screens. Is this the "Intel(R) Quick Resume Technology" that I'm seeing in the Intel Integrator Toolkit, but not on the BIOS screens themselves? Do you know where I should look?

The Technical Specification for the board does indicate (Section 1.13), not surprisingly for a contemporary desktop board, that "brief" pushes of the "power" switch put the board into G1 state, which is consistent with retaining memory and state in some way.

If you still have issues, go into the advanced settings and give it a bit more time to recognize drives. The board can indeed boot so fast that the drives never init ...
Click to expand...

The drives are recognized and F10 (boot menu) sees them "properly", but still can't boot them properly.

The only time I can reliably get a boot is when I soft boot and then only to CD. I've been using the BIOS install CD, which has ISOLINUX on it, that then successfully transfer boot to the hard drive. While I haven't ruled out FreeBSD GPT as what initiates this problem, once the problem exists, using a wiped drive (device level, using BCWipe port), doesn't resolve the problem.

Even using the "BIOS recovery" procedure with the on-board jumper and a USB stick containing the new BIOS, as per Intel's suggestions, does not resolve the problem.

Intel has asked me to send in the MB -- two of them are shipping out to them. Hopefully I can get the boot problem resolved -- and perhaps the memory-retention will be part of the fix.

Thanks again!
 
jef, does this problem manifest itself when Linux is installed on the hard drives?

I only ask because I have one of these boards myself which I'm currently running linux on. I haven't bumped against this issue with linux on the drives, but the system is going to run FreeBSD soon, so you have me worried. :)
 
FreeBSD 7.2 running fine

Hi

I picked up one of these boards and FreeBSD 7.2 i386 is running fine on it. No problems at all with the install, or with multiple reboots.

Setup:

2 GB Kingston bottom of the barrel RAM
Liteon bottom of the barrel CD/DVD
500 GB Hitachi hard drive
Intel Atom 330 motherboard
Iogear KVM switch

No mods to the bios, or fiddling with anything. Just a stock install from the DVD.

Bob
 
Glad to hear you're having success!

These are nice boards for physically small servers and hum along nicely for me (as long as the BIOS hasn't locked up) with "old" 7.2/i386 drives that I've transplanted from aging hardware (SE440BX, for example). With a couple Seagate 5400.6 500GB notebook drives in them, total power consumption is under 40W. Petra's Tech Shop is my semi-local source for Scythe MiniKaze 40x40x10 fans to quiet the MB, Yate-Loon D12-SL12 for the case, and Y-adapters to run them both off the BIOS-controllable PWM output on the board.

I've got two of the "hung" boards in with Intel now and I'm hoping to hear what they find about why they lock up.

GPT and/or ZFS is a "must have" for me as these machines are intended to host a large number of jails, and I prefer each to have their own partition(s) for a variety of reasons.


bin/115406: [patch] gpt(8) GPT MBR hangs award BIOS on boot suggests one problem with the PMBR, which suggests that the starting CHS is not being properly set when FreeBSD tools are used to write it.
 
Active Slice

Hi

I mark them active as a routine matter. Always have ...

I've got a second board up and running on 7.2 i386. No problems at all. I should have a third up next week.

Bob
 
I've confirmed that the PMBR written by either gpt or gpart for GPT "breaks" the BIOS for this board as previously identified in bin/115406.

These two PMBR excerpts illustrate the changes required:

This is the "stock" PMBR generated by gpart for a 500 GB SATA drive.
It does *not* allow the BIOS to boot.

Code: 
000001b0: 9090 9090 9090 9090 0000 0000 0000 00ff  ................
000001c0: ffff eeff ffff 0100 0000 2e60 383a 0000  ...........`8:..
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa  ..............U.

This is a hand-modified version of the PMBR installed on the same
drive that does permit the BIOS to boot.

Code: 
000001b0: 9090 9090 9090 9090 0000 0000 0000 8001  ................
000001c0: 0100 eeff ffff 0100 0000 2e60 383a 0000  ...........`8:..
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa  ..............U.

Note that the "bootable" flag has been set (0x80) and the start of the partition has been set to the beginning of the disk (0x010100).

Without the 0x80 flag also set, the D945GCLF2 BIOS does not identify any bootable drives.

Notes are in to freebsd-geom, but until then, I'm getting good with dd

I don't know if this will prevent the "freezing" issues, and am not excited to try to "break" more of my boards until I hear back from Intel (two up with their techs now).
 
I am battling the exact same problem right now with 8.0-RELEASE and my Intel D945GCLF2. Reading the original PR (http://www.freebsd.org/cgi/query-pr.cgi?pr=115406&cat=bin), it can be seen that a supposed fix to gpart was committed to stable/8 back in Aug 27, is it possible that this somehow didn't make it into 8.0-RELEASE or is this a question of the fix being there but not actually solving the problem?

Can anyone point me towards an explanation regarding how to edit and apply my own PMBR to my disk to see if it helps? This would be a bandaid I am willing to live with, since I don't think anything is ever likely to overwrite this without my knowledge once applied.
 
I ended up getting the Intel boards refunded as Intel could not get them to boot reliably. The changes noted above did not resolve the issue reliably.

I have had no issues with the similar Asus boards.
 
Nope -- eventually the D945GCLF2 would freeze up and require "hand holding" with USB sticks and DVD drives to get it to boot.

I have four of the Asus AT3GC-I that run quite well for me now. The AT3N7A-I is newer (and twice the price) and I may try one of them later for a (Ubuntu) MythTV box.
 
So is the problem specific to GPT partitioned disks? My GCLF2 board is running fine with a regular PC BIOS MBR...

However, there is another problem with this board - broken ACPI. If you see AE_AML_INFINITE_LOOP ACPI errors on yours, load the attached DSDT.
 

Attachments

  • D945GLF2.aml.gz
    5.6 KB · Views: 500
aragon said:
So is the problem specific to GPT partitioned disks? My GCLF2 board is running fine with a regular PC BIOS MBR...
Click to expand...
Yes, the problem is limited to GPT, googling around it seem that this is not an OS-specific problem either, as in addition to FreeBSD, GPT users of Windows 7 and Linux have also been reporting problems with this board, yet MBR installations work fine.

My problem is more complicated even, I was planning to use an Intel X25-M SSD for the root fs and main OS installation. Now I find out that my motherboard won't reliably boot off GPT and to top that off, there seem to be some nasty issues in using MBR + UFS on an SSD like this (I was getting really unexplained read and write errors), so for FreeBSD the only combination that could work for me would be MBR + ZFS, after spending over 24 hours battling the issue I didn't bother to test out that one though.

Meanwhile, both Win2008 and Windows 7 (when using MBR+NTFS) work just fine on the same board and same SSD and pass all tests with flying colors (so my random read/write errors when using MBR+UFS on the SSD were not really disk errors).
 
Jago said:
to top that off, there seem to be some nasty issues in using MBR + UFS on an SSD like this (I was getting really unexplained read and write errors)
Click to expand...

Haven't heard of anything like that before. MBR should work fine with SSDs. Have you posted details of this problem somewhere?

AFAIK, GPT is mostly only useful if you need to create partitions larger than 2 TB.
 
aragon said:
GPT is mostly only useful if you need to create partitions larger than 2 TB.
Click to expand...

...or want a manageable way to handle dozens of mirrored partitions for a jailserver.
 
I can only wonder how viable is this: http://wiki.freebsd.org/RootOnZFS/ZFSBootPartition

This describes setting up a purely zfs zfsroot system using gpart to install ZFS into a partition inside a slice, using MBR. Sounds otherwise reasonable, but this part looks really hairy:

Install the boot2 zfs stage into the convienient hole in the ZFS filesystem on-disk format which is located just after the ZFS metadata (this is the seek=1024).

Code: 
Fixit# dd if=/mnt2/boot/zfsboot of=/dev/ad0s3a skip=1 seek=1024
Click to expand...
 
You must log in or register to reply here.
Back
Top