ASUS M5A97 R2.0 motherboard

My motherboard went bad and I replaced it with an ASUS M5A97 R2.0 motherboard. About every third time I would boot-up, the boot-up would fail and the DRAM_LED light would come on. I would open up the case, press the MEM_OK button, go into BIOS and reset my DRAM settings (which for some reason had been changed from what I had set them to), save my settings and continue to boot-up. This would last for about two bootups and then the DRAM_LED would come on again.

I checked with ASUS and learned that my memory DRAM was not on their “tested” list, so I replaced my memory with Corsair CMZ8GX3M2A1600C9, which is on their “tested” memory list. I continue, however, to have the exact same boot-up problem.

I’m coming to the conclusion that either (1) the motherboard is bad, or (2) for some reason my partitioning scheme is confusing the ASUS BIOS.

Let me explain: I wanted to partition my harddrive as a GPT partition, so I set it up as a UEFI partition. This caused all kinds of problems and I eventually learned that there is some kind of incompatibility issue with an nvidia graphics card and an UEFI partition (http://www.tomshardware.com/faq/id-1737637/uefi-bios-nvidia-play-fix.html).

To use a GPT partition with legacy boot I followed the guide on Arch Linux’s website (https://wiki.archlinux.org/index.php/GRUB#GUID_Partition_Table_.28GPT.29_specific_instructions). This worked fine with my previous motherboard. That’s why I’ve come to the conclusion that either my motherboard is bad, or there is some BIOS setting that I’m missing. I guess that I could set up my harddrive with an MBR, but I don’t want to have to think about going there yet.

Any suggestions?

Thanks!
Reply to jim1112
4 answers Last reply
More about asus m5a97 motherboard
  1. MEM_OK sets the memory to the base frequency and timings so not surprising that the settings would have changed. Are you setting things manually or using an XMP profile?
    Reply to HamBown81
  2. HamBown81 said:
    MEM_OK sets the memory to the base frequency and timings so not surprising that the settings would have changed. Are you setting things manually or using an XMP profile?


    I've tried every setting I can think of. I've set it to [AUTO] and when that didn't work by itself tried adjusting every variable that I could. I've tried [D.O,C,P.] and set it to the XMP profile on my memory. I've even tried [MANUAL] but without any luck.

    I'm getting some error codes at bootup. Would those be helpful?

    LATER: I think that I may have found a solution. CSM (Compatibility Support Module) has three settings: AUTO, ENABLED and DISABLED. I had previously tried AUTO and ENABLED with the same result - boot failure. I changed the setting to DISABLED and hit F10 to save and reboot. Upon rebooting, I got a BIOS warning that my graphics card was not compatible with UEFI. (I already knew that.) I was given a choice to select F1 to change BIOS settings or F2 to continue. I selected F2.

    I have been through enough reboots so that I would have had a boot failure under the AUTO or ENABLED settings. So far everything seems to be working fine. I'm getting no error messages during bootup.

    My guess is that there is some conflict between CSM and the hardware detection module in Linux - that these two modules are fighting each other to adjust the hardware compatibility.

    If I have a boot failure over the next couple of days, I will repost that this solution didn't work. Until then, everything seems to be working fine. Thanks!
    Reply to jim1112
  3. That is possible. I know I had weird issues booting from a GPT partitioned SSD on that board. Starting from scratch with an MBR partition cleared things up for me.

    Glad that you were able to get it going.

    I would try using an alternate MBR formatted drive and see what happens if you continue to have issues. At least if we know it is that, it would be something to work around.
    Reply to HamBown81
  4. HamBown81 said:
    That is possible. I know I had weird issues booting from a GPT partitioned SSD on that board. Starting from scratch with an MBR partition cleared things up for me.

    Glad that you were able to get it going.

    I would try using an alternate MBR formatted drive and see what happens if you continue to have issues. At least if we know it is that, it would be something to work around.


    I think that I have finally tracked my problem down to a conflict between the SMBus (which I think is built into the cpu) and the i2c bus (which I think is hard-coded into the kernel). Here is the error message from running **journalctl -b -p err**:

    **[jim@jim-pc ~]$ journalctl -b -p err**
    **-- Logs begin at Thu 2017-09-21 11:58:00 CDT, end at Fri 2017-09-22 03:53:38 CDT**
    **Sep 22 03:50:38 jim-pc kernel: i2c i2c-1: SMBus Timeout!**
    **Sep 22 03:50:38 jim-pc kernel: i2c i2c-1: Failed reset at end of transaction (01**
    **Sep 22 03:50:38 jim-pc kernel: i2c i2c-1: Failed! (01)**
    **Sep 22 03:50:38 jim-pc kernel: i2c i2c-1: Failed! (01)**
    **Sep 22 03:50:38 jim-pc kernel: i2c i2c-1: Failed! (01)**

    This error eventually leads to boot failure, and I have to go into and reset BIOS.

    I have found the following webpages on this subject, going back to at least 2013, but no definitive answers. The first webpage is on github which proposes a driver to disable SMBus:

    https://github.com/opennetworklinux/linux/blob/master/3.2.65-1%2Bdeb7u2/patches/driver-adt7470-knob-to-disable-smbus-timeout.patch

    https://stackoverflow.com/questions/23999140/linux-i2c-read-does-it-really-do

    https://www.totalphase.com/support/articles/200349186-Differences-between-I2C-and-SMBus

    http://rts.lab.asu.edu/web_438/CSE438_598_slides_yhlee/438_6_Linux_I2C_SMBus.pdf

    https://github.com/raspberrypi/linux/issues/260

    I am running Manjaro 17.05 Stable-branch with linux4.9 kernel. Since the **i2c timeout** is hard coded into the kernel, I would think this might be addressed in a future kernel update (I'm running the 4.9 stable), or there may be a patch, as one of the above pages discusses, to disable the SMBus, or I could go back to the 4.4 kernel.

    Does anyone know anything about a patch, or have suggestions on a kernel change?

    Thanks, :crazy_face:
    Reply to jim1112
Ask a new question Answer

Read More

Asus Motherboards