Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Intel DH77EB motherboard woes.

  1. #1
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,583

    Default Intel DH77EB motherboard woes.

    Just thought I would post a few things I have encountered with these motherboards. The reason I bought this board was because it had a mPCI-e slot for a mPCI-e SSD. If anyone is considering this board there are some things they should know about before they consider purchasing it.

    First of all, these things have absolutely horrid BIOS/uEFI implementations. Early versions of the BIOS/uEFI BIOS did allow for successful booting via uEFI. intel in their infinite wisdom decided to "fix this" by making newer versions of the BIOS incapable of storing the proper NVRAM entries for a uEFI boot. In fact if you upgrade the BIOS, be prepared for all NVRAM uEFI entries to be lost rendering your installed OS unbootable. So if you want to boot uEFI, be prepared to stick with an older uEFI BIOS such as 0062 or older. But wait there is another "gotcha" with going that route. If you stick with an older BIOS there is a very strong possibility that some of your PCI-e cards will not work (such as tv tuners). intel has fixed that in the latest BIOS but still has uEFI issues.

    Second, if you plan to use the the mPCI-e sata capabilities, do not plan on using it for a boot drive and another traditional drive for data. There is yet another bug in their BIOS that forces the system to try to boot to an installed conventional instead despite the BIOS/uEFI clearly being set to boot off the mPCIe SSD. The only way to boot to the SSD is to manually hit F10 to get the boot selection screen and select it there. This occurs on all versions of the BIOS post 0062 and it even occurs when the BIOS is set to traditional BIOS mode and uEFI disabled.

    3rd if you plan on shutting down the system, you must use a kernel >= 3.5.2. These boards have a chipset bug in the USB 3 controller that causes the system to do a reboot instead of a shutdown. There is a patch available that can be backported on the LKM to fix this which can be backported to other kernels. It swishes the USB 3 ports first to ehci mode before shutting down. I have not seen however any distro that has backported the patch in their updates yet. The other workaround to it is to disable WOL in the BIOS (I know, I know, WTF does WOL have to do with USB 3 but it does work).

    Overall, I thought going with an intel board might be worth it for a stable "reference" platform but this is by far, without doubt, the buggiest board I have come across ever. Contacting intel so far has been OK, and they do accept linux as a valid system to report bugs against which is a nice change but it is really starting to feel like dealing with wine bugs. They fix one thing and break another with their BIOS updates. Many of these issues are also present in the DH77DF. It's too bad, as I can't seem to find another motherboard to meet the criteria that I am looking for (mPCI-e slot, all PCI-e, mATX and an intel NIC). One other thing to note, the mPCI-e slot for the SSD on the intel board is multiplexed with one of the SATA II ports so don't expect SATA III SSD speeds from the mPCIe SSD.

    Overall, I cannot recommend the newer Intel boards for use for linux until these BIOS bugs are sorted out.

    PS: This is just not a defective board, 3 boards from different batches have been already tried.

  2. #2
    Join Date
    Aug 2007
    Posts
    6,619

    Default

    It seems to be common that updateing the bios kills the uefi boot records, that happens with asrock boards as well, nothing intel specific.

  3. #3
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,583

    Default

    Quote Originally Posted by Kano View Post
    It seems to be common that updateing the bios kills the uefi boot records, that happens with asrock boards as well, nothing intel specific.
    Asus and Gigabyte boards retain the NVRAM just fine on both AMD and Intel boards during BIOS updates and downgrades.

  4. #4
    Join Date
    Aug 2007
    Posts
    6,619

    Default

    Well it is stored in the same chip so it depends how much you overrite there. For me it is no big deal as i know how to use the efi shell. Btw. it would be more interesting for me if the board has secure boot or not.

  5. #5
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,583

    Default

    Quote Originally Posted by Kano View Post
    Well it is stored in the same chip so it depends how much you overrite there. For me it is no big deal as i know how to use the efi shell.
    Yes it is on the same device, and I could even understand it if you were to use a manual boot disk method of updating the BIOS/uEFI, but using the built in upgrade BIOS/uEFI should not under any circumstance render a system unbootable requiring to manually reload the NVRAM. That is broken by design and unforgivable given that uEFI is intel's answer to the outdated BIOS.

    Btw. it would be more interesting for me if the board has secure boot or not.
    Nope, thank goodness.

  6. #6

    Default

    Quote Originally Posted by Kano View Post
    It seems to be common that updateing the bios kills the uefi boot records, that happens with asrock boards as well, nothing intel specific.
    Also on Zotac.
    Let's wait and see what happen when Windows users starting to upgrade UEFI on Intel, ASRock and Zotac boards, and what they say to tech.support about their broken-after-upgrade systems

  7. #7
    Join Date
    Aug 2007
    Posts
    6,619

    Default

    Nothing will happen there. All known boards will autodetect Win installs - which is fairly easy btw. My guess is that all boards which wipe out the bootorder do not use InsydeH2O firmware as this does not happen there (asus desktops use that). But what happen with InsydeH2O is: when you try to add a bootentry with a previously used file (efibootmgr -l option) then only the last entry survies a reboot. As the efi partition is fat a hack is to use a differnet upper/lowercase for that filename, any extra options are ignored for that autocleanup. Also when you remove a hd often the same cleanup code wipes out all entries which are impossible now. Some boards have got an option to enable or disable that wipe, but Asus/InsydeH2O does not. Btw. there are even boards with built-in EFI Shell - like new MSI series 7 boards. Most others boot it from the filesystem - this is basically easier as you could use this feature to start something else as well, like a fallback gummiboot.efi/grub.efi renamed to shellx64.efi. Btw for the asus bug thats what i reported but got ignored because i used Linux to create the entries (what a joke):

    http://kanotix.com/files/fix/efi/asu...v-uefi-bug.txt

    Btw. it is possible to identify autoadded Win boot entries. In the same example you see it: Boot 0007 is autoadded and 0000 was done by the installer -> Win installers usually add some options but those seem to be optional, therefore it still boots without any option.
    Last edited by Kano; 10-29-2012 at 03:40 AM.

  8. #8
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,583

    Default

    Quote Originally Posted by Kano View Post
    All known boards will autodetect Win installs - which is fairly easy btw.
    Not in the case of the DH77EB/DF believe it or not.

  9. #9
    Join Date
    Aug 2007
    Posts
    6,619

    Default

    Send me the board if you dislike it I still have got cpus for s1155 but no boards.

  10. #10
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,583

    Default

    Quote Originally Posted by Kano View Post
    Send me the board if you dislike it I still have got cpus for s1155 but no boards.
    Heh, solved the issue another way, built my father a new system, disabled uEFI mode, installed his Windows 7 on a 2TB drive and kept the Asus board that I bought for his system for myself. He will never hit the issues that I have come across on them.

    PS Intel has acknowledged the issue with the board and are currently "researching the issue". I don't have much faith however given these boards apparently have their BIOS development farmed out to Phoenix now.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •