Print Page | Close Window

[SOLVED] Suspend Skylake Fatal1ty z170 gaming-itx

Printed From: ASRock.com
Category: Technical Support
Forum Name: Intel Motherboards
Forum Description: Question about ASRock Intel Motherboards
URL: https://forum.asrock.com/forum_posts.asp?TID=2896
Printed Date: 29 Mar 2024 at 10:28am
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com


Topic: [SOLVED] Suspend Skylake Fatal1ty z170 gaming-itx
Posted By: Jessie
Subject: [SOLVED] Suspend Skylake Fatal1ty z170 gaming-itx
Date Posted: 22 Jun 2016 at 8:06am
Hello,

I'm using the Fatal1ty z170 gaming-itx/ac (BIOS 2.1) with an Intel Skylake i3-6320 and I am unable to wake up the computer after putting it in standby.

Strangely the first time I suspend the computer, it wakes up correctly.
But the second time it is suspended, instead or waking up, it reboot automatically.

I am using :
- the latest available BIOS : 2.1
- Debian Stable (Jessie) with linux kernel 4.6 and latest intel driver (2.99.917+git20160522-1)

However I don't think this is related to the operating system, as it seems that all power is cut immediately as soon as I push the power button to wake up the computer.

I also tested the RAM with Memtest86 without any issues.

Deactivating the ACPI option "Suspend to RAM" (S3) in BIOS, get the computer to wake up every single time.

Can somebody help me ?

Thanks



Replies:
Posted By: Brad
Date Posted: 22 Jun 2016 at 8:35am
I have been having suspend issues ever since I bought this same motherboard.  

If I turn off my monitor during suspend/sleep, the motherboard will never wake the monitor back up. I have to hit the reset button to reboot which would then wake the monitor back up.  Another bug is occasionally drives will be missing on resume from sleep.  That is rare, but it does occasionally happen. 

In my opinion, this board/Bios is still very buggy.  I'm hoping a future Bios update will fix some of these issues.

I know my problem is different than yours, but I can tell you that support will recommend you use Bios 1.8 instead of 2.1.  So maybe try that and see if it helps.  




Posted By: Jessie
Date Posted: 22 Jun 2016 at 9:09am
With BIOS 1.8, I have the following result:
- when waking up from first suspend, the display is disconnected (black screen)
- when waking up from second suspend, the computer is immediately powered down (same behavior as before).


Posted By: parsec
Date Posted: 22 Jun 2016 at 12:33pm
Originally posted by Jessie Jessie wrote:

Hello,

I'm using the Fatal1ty z170 gaming-itx/ac (BIOS 2.1) with an Intel Skylake i3-6320 and I am unable to wake up the computer after putting it in standby.

Strangely the first time I suspend the computer, it wakes up correctly.
But the second time it is suspended, instead or waking up, it reboot automatically.

I am using :
- the latest available BIOS : 2.1
- Debian Stable (Jessie) with linux kernel 4.6 and latest intel driver (2.99.917+git20160522-1)

However I don't think this is related to the operating system, as it seems that all power is cut immediately as soon as I push the power button to wake up the computer.

I also tested the RAM with Memtest86 without any issues.

Deactivating the ACPI option "Suspend to RAM" (S3) in BIOS, get the computer to wake up every single time.

Can somebody help me ?

Thanks


First I must say that Linux of any flavor is not officially supported by your board.

An example of why is what you experience when you "deactivate" (Disable?) Suspend to RAM (S3 Sleep) in the UEFI. The UEFI implementation of Suspend to RAM is tailored to work with Windows. But that implementation does not work with the version/configuration of Linux that you use.

There are likely many examples of this type of difference that creates varying levels of incompatibility. We could debate which are correct, and Windows could be wrong (IMO, more likely) most of the time. But the bottom line is a choice had to be made, and Windows/Microsoft was chosen in this instance.

ACPI is a well defined specification. Entering and exiting the ACPI S3 Sleep state should be a well defined sequence of events. I don't know whom has that done correctly (Windows or the version of Linux you use), or if your Linux configuration has a bug, or Windows does, but it seems clear the implementation ASRock chose to use is not compatible with both OS versions I am discussing here. That choice was made for ASRock by the OS they chose to primarily support.

If waking from Sleep works with your Linux configuration with Suspend to RAM set to Disabled, why does that bother you? For all we know there is a "flag" variable setting in the code (on or off, true or false) that is interpreted in precisely the opposite way in each OS I've mentioned here.

Who cares if "Disabling" something causes it to work correctly for you? The main thing is you can CONFIGURE Suspend to RAM to work correctly with your OS of choice. IMO, to worry or be bothered by setting Suspend to RAM to Disabled to get it working with your OS, IF that is all that is bothering you, does not make sense and is a non-issue.

Computer code can be programmed to interpret Enabled or Disabled as 1 and 0 respectively, or 0 and 1. "True" and "False" are normally 1 and 0 respectively, but those values are arbitrary, they could just as easily be 0 and 1 respectively.

For example, the Enabled setting could be renamed "Enabled for Windows Only", and the Disabled setting renamed to "Enabled for Debian Linux Only", and both settings will disable it for the other OS.

Waking from Sleep problems are very common and sometimes cannot be diagnosed and fixed by ourselves, or anyone. My Intel P67 chipset mother board would not wake from Sleep if left in the Sleep state for more than about 15 minutes. Other owners of this board had the same problem. We discussed this issue in a forum thread (not an ASRock forum) for months and tried to find the cause and a fix. We had all kinds of theories, and a few users apparently got it working, but others including myself, never did.

Honestly, if Sleep and Wake works for me on a PC with all the different hardware and software components I am using, I am pleased and relieved. I have certain mouse models that are unable to wake the PC from Sleep, while others can. I can press the power button and wake the PC when using the mouse that fails to wake the PC.

Sleep and waking from Sleep works fine with my ASRock Z170 Extreme7+ board, using Windows 10. I use Sleep all the time, the PC is configured to enter Sleep automatically after 1/2 hour of inactivity. I trust its operation that much. It sounds like you can configure yours to do the same thing. If setting Suspend to RAM to Disabled does not negatively affect anything else, IMO just do it and move on. Geek


-------------
http://valid.x86.fr/48rujh" rel="nofollow">


Posted By: Jessie
Date Posted: 23 Jun 2016 at 1:48am
No problem if linux is not officially supported: I have wiped the linux OS and installed Windows 10 from scratch (hopefully this is an officially supported OS now).

However the problem remains the same: after the second suspend,the computer cannot wake up and reboot instead.
I've tried with both BIOS 1.8 and BIOS 2.1.
As an additional bonus (malus ?), deactivating "Suspend to RAM" (S3) also deactivate "Sleep" in Windows 10 (option is no longer available).
It seems that Windows 10 is not willing to use state S1.

So what should I do now ?

P.S.: deactivating "Suspend to RAM" (S3) makes suspending pretty useless. As the S1 state consumes approximately 15W (instead of 18W in normal use), with the loud CPU fan still spinning (the only thing shutting down is the hard drive). It was just intended as a debugging hint, not for permanent use.


Posted By: def
Date Posted: 27 Jun 2016 at 9:36am
Similar problem here: Resuming from suspend does not work for me. I also assumed it was a Linux problem at first, so I installed Windows 10, but neither can resume from suspend.


Posted By: Jessie
Date Posted: 27 Jun 2016 at 4:08pm
Can you resume one time at least ?
For me I can resume only one time, but not the second time.

Does it reboot when you try to resume ?

I contacted Asrock for this problem, so if you send me your configuration (see needed info here: http://event.asrock.com/tsd.asp). I can also report your problem.

As a side note it seems that a friend with the exact same configuration as me, does not have this problem. So maybe it is related to when you have bought the board.
Can you tell me when and where you bought it ?

Thanks


Posted By: def
Date Posted: 27 Jun 2016 at 8:22pm
No, can't resume even once, neither on Windows nor Linux. But I can resume on Linux if I disable the i915 graphics module, but then the screen goes black after resume (but I can still ssh into the system). Loading the i915 module kills it.

An idea of mine is that it has to do with the HDMI 2.0 chip. There is an updater for it on the ASRock website, but that fails to run for me, so I can't test if that would fix it.

BIOS 2.10
Purchase Date 21.06.2016 @ mindfactory.de
CPU i7 6700k
RAM 32GB (2x 16384MB) Crucial DDR4-2133
HDD 256GB Samsung SM951-NVMe M.2


Posted By: Jessie
Date Posted: 27 Jun 2016 at 8:50pm
I also bought 2 boards from Mindfactory.de!
I also got the black screen issue, and I manage to solve it (Debian).
Can you also send the board serial number ?
Danke


Posted By: def
Date Posted: 27 Jun 2016 at 10:16pm
Bios 1.8 fixed the issue for me.  Another issue was that tsc stopped working after resume, kernel parameter tsc=reliable fixed that.

Sent you the serial number in a PM.

Now I still have to figure out how to run the HDMI firmware updater.


Posted By: Jessie
Date Posted: 28 Jun 2016 at 4:37am
Strange, I think I solved the problem by going with BIOS 2.1 (with 1.8 I also got the black screen).

So you can suspend several times without problem now ?


Posted By: def
Date Posted: 29 Jun 2016 at 5:03am
Yes, I can suspend as much as I want. But one problem remains and I tried out a few BIOS versions and none fixed it, the TSC keeps becoming unstable after suspend. I believe the BIOS is changing the TSC values in suspend/resume, which it should not do. Setting tsc to reliable just makes the clock run backwards... The exact error I get about TSC:

Jun 28 22:49:23 al kernel: TSC synchronization [CPU#0 -> CPU#1]:
Jun 28 22:49:23 al kernel: Measured 3072272461 cycles TSC warp between CPUs, turning off TSC clock.
Jun 28 22:49:23 al kernel: tsc: Marking TSC unstable due to check_tsc_sync_source failed
Jun 28 01:17:48 al kernel: clocksource: Switched to clocksource hpet

Using HPET instead of TSC is not acceptable. Some applications that call gettimeofday() a lot slow down by a factor of 10 or more.


Posted By: Jessie
Date Posted: 29 Jun 2016 at 5:41am
Yes I also got that one after the first suspend:

kernel: [   47.547506] TSC synchronization [CPU#0 -> CPU#1]:
kernel: [   47.547507] Measured 4423217582 cycles TSC warp between CPUs, turning off TSC clock.
kernel: [   47.547509] tsc: Marking TSC unstable due to check_tsc_sync_source failed
kernel: [   48.678307] cache: parent cpu1 should not be sleeping
kernel: [   47.547688] CPU1 is up
kernel: [   47.547710] smpboot: Booting Node 0 Processor 2 APIC 0x1
kernel: [   48.678948] cache: parent cpu2 should not be sleeping
kernel: [   47.548329] CPU2 is up
kernel: [   47.548350] smpboot: Booting Node 0 Processor 3 APIC 0x3
kernel: [   48.679451] cache: parent cpu3 should not be sleeping
kernel: [   47.548830] CPU3 is up
kernel: [    0.020000] ACPI: Waking up from system sleep state S3
kernel: [   48.697375] clocksource: Switched to clocksource hpet

I wonder if this is causing instability (which my explain my hard reboot).
I will confirm with the second board that I also have this issue.


Posted By: Jessie
Date Posted: 30 Jun 2016 at 5:14pm
Confirmed on the computer of my friend: he has the same TSC problem.
I will contact Asrock.

Thanks def for your help.


Posted By: def
Date Posted: 04 Jul 2016 at 3:58am
Okay, actually resuming from suspend doesn't always work for me. When I do it in short intervals it seems to work fine, but after a few hours it sometimes fails.


Posted By: Jessie
Date Posted: 04 Jul 2016 at 4:12am
Ok. I have reinstalled Windows 10 in order to reproduce the problem with Windows 10 (otherwise Asrock will ignore me).
Do you have any idea how to check for TSC/HPET synchronization issues on Windows 10 ?
I have no idea how to look at the logs after resume.


Posted By: def
Date Posted: 09 Jul 2016 at 4:40pm
No idea, I'm really not a Windows guy. But they sent me a new BIOS version that's supposed to fix the TSC issue, I just can't test it because nothing newser than 1.8 can resume from suspend for me.


Posted By: Jessie
Date Posted: 09 Jul 2016 at 4:49pm
Perhaps you can send it to me ? Or drop it somewhere where I can download it ?
I can resume from suspend with a BIOS 2.1.


Posted By: Brad
Date Posted: 09 Jul 2016 at 10:45pm
Jessie,

On your original post you said you had problems resuming from suspend on Bios 2.1.

Now you say you can resume from suspend on Bios 2.1.

What has changed? Did the fresh install of Win 10 fix it?




Posted By: Jessie
Date Posted: 10 Jul 2016 at 5:14am
Hello Brad,

Sorry for the misunderstanding.
With BIOS 1.8 I cannot suspend/resume at all.
With BIOS 2.1 I can suspend/resume but only one time. And even for this one time, I got the TSC/HPET problem.

I will try the BIOS that def send me and report how it goes.


Posted By: Brad
Date Posted: 10 Jul 2016 at 8:29am
Yes, please report back.  

I've been patiently waiting for an updated BIOS.  Although, v1.8 has been working fine for me.  I do not see any ill effects on Win 10 regarding the TSC/HPET issue.








Posted By: Jessie
Date Posted: 11 Jul 2016 at 3:14am
Ok I tried flashing this BIOS and I still have the same problem (TSC deactivation).


Posted By: Jessie
Date Posted: 11 Jul 2016 at 3:16am
By the way in Windows 10, you can see the TSC desynchronisation effect by disabling HPET in the BIOS.
Normally you won't be able to suspend/resume anymore (it will go through a reboot).
Which means Windows tried to also switch to HPET after suspend/resume (but since HPET is disabled, it couldn't).


Posted By: Jessie
Date Posted: 20 Jul 2016 at 3:16am
I got a response and a new BIOS (2.10E) from Asrock.
However this new BIOS doesn't solve the problem and makes it worse (the display doesn't work anymore as with BIOS < 2.1).

For Asrock, with this new BIOS 2.10E, the board should be able to resume from S3 (suspend) and they advise to order a new board.

Anyone else interested in testing this BIOS 2.10E ?


Posted By: def
Date Posted: 20 Jul 2016 at 3:35am
Always, haven't heard anything from them for a long time. But I found a new problem with the mainboard. Sometimes randomly the CPU fan stops working and there is a high-pitched sound instead. The only solution is to restart the computer.


Posted By: Jessie
Date Posted: 20 Jul 2016 at 4:33am
Ok I send you the new BIOS in a private message.

I've never had this CPU fan problem. It seems like a valid case for sending it back.


Posted By: Brad
Date Posted: 20 Jul 2016 at 5:56am
Jessie,

Are you going to return the board since v2.10E doesn't work?




Posted By: Jessie
Date Posted: 20 Jul 2016 at 5:18pm
I've contacted my dealer in order to know what to do.
But I think I will have to return it.


Posted By: Jessie
Date Posted: 12 Aug 2016 at 7:54am
Just received another board from my dealer: same problem as before (reset at second boot).
I've tried with BIOS 1.8, BIOS 2.1 and the just release BIOS 2.3: same problem.

Has anyone tried the BIOS 2.3 on their board ? Has it solve the sleep/wakeup problem ?


Posted By: Jessie
Date Posted: 17 Aug 2016 at 6:57pm
Interesting answer from Asrock: they would like to borrow my system do debug further !
That's very unusual from a big company and I appreciate it.


Posted By: Brad
Date Posted: 17 Aug 2016 at 9:47pm
That is interesting Jessie.  This kinda makes sense.  If everyone had this sleep/wake issue there would be plenty of bad reviews out there on this board. There must be some obscure incompatibility that they want to figure out.

I'm still using v1.8 without issue.  I will try v2.3 soon and see if the wake issue returns.

As always, please keep us updated on this forum.

Thanks.


Posted By: Jessie
Date Posted: 03 Oct 2016 at 7:51pm
Some news about the issue:
- good news: the TSC/HPET issue is solved with BIOS 2.30b
- bad news: I still got the reboot after the second wake-up

What was really strange is that Asrock tested my build in their facilities, and manage to reproduce the problem in some circumstances :
- old BIOS + install OS (Debian) + flash BIOS => reboot at 2nd wake-up
- new bIOS + install OS (Ubuntu or Win10) => no reboot at 2nd wake-up

So they erased my hard-drive, and installed Ubuntu + Win10 on it, verified that it works and ship it back to me.

As soon as it arrived, I made an image of the hard-drive before even booting it (to keep the state intact).
Then I started Ubuntu and I got the reboot at 2nd wake-up ! :-(
Then I started Win10 and I got the reboot at 2nd wake-up ! :-(

I've tried switching the external power supply, changing the mini-ITX case, changing the display, changing the display cable, changing keyboard (USB and PS/2) but I still have the problem.
I even made a movie of myself doing the test to check with Asrock that I am doing exactly like they were doing.

We are running out of idea and I may ship my computer back again to Asrock to solve this mystery, once and for all.

The good news is that I found out that waking-up the computer through the keyboard instead of the mini-itx power button, manage to wake-up the computer without problem every single time.
However since I am using a wireless keyboard, I cannot use this workaround in my particular case, but it could be useful for others.

Anyone has an idea why it worked at Asrock office and can not work at my home ?

Anyway big thanks to Asrock, the support was really great !


Posted By: Jessie
Date Posted: 03 Oct 2016 at 9:01pm
With Asrock, we finally managed to nail the problem: the power button has to be pushed very quickly.
I don't know why (it wasn't a problem with other motherboard) but pushing it and maintaining it a bit longer (but less than a second) trigger the reboot.

So people having trouble resuming from suspend, try to push the button faster !


Posted By: parsec
Date Posted: 03 Oct 2016 at 11:59pm
Originally posted by Jessie Jessie wrote:

With Asrock, we finally managed to nail the problem: the power button has to be pushed very quickly.
I don't know why (it wasn't a problem with other motherboard) but pushing it and maintaining it a bit longer (but less than a second) trigger the reboot.

So people having trouble resuming from suspend, try to push the button faster !


That could be caused by the PC case power button, for several reasons. I've seen power buttons "stick" in the pressed/on position. Does your button move from the pressed/down position back to  the unpressed/up position quickly? What PC case are you using?

Also, the power button may be partially worn out or damaged. When pressed firmly, it is sending two signals to the mother board, on-off-on, or while the button seems to be released and not "on", it still is sending the "on" signal to the board. If you pressed down and held the power button down when the PC is in Sleep mode, what does it do?

Just because the power button worked fine with another board, does not mean it is working perfectly fine now. Things can break at any time for no apparent reason.

The power button on PC cases is not like a regular power switch, like a light switch. The only time the PC case power button circuit is closed or on, is when the button is pressed down. That causes the board to "see" that change in the circuit, which then sends a signal to the PSU to turn on. When the PC power button is released/not pressed, the power button circuit is open or off. It seems as if the PC power button is sending multiple on/closed signals to the board very quickly, one after another.



-------------
http://valid.x86.fr/48rujh" rel="nofollow">


Posted By: Jessie
Date Posted: 04 Oct 2016 at 7:16pm
The button is working perfectly fine. It's only at the second wake-up that the problem is there. I've never failed a first wake-up.
And with another Asrock board, there has never been any problem, either.

Asrock told me that they noticed the same problem with another case from another customer, but with the same board.
I tested the Fatal1ty z170 gaming-itx with another case at home, and I got the same problem.
So that's 3 different cases showing the problem.

Honestly I don't know who is the culprit. I've got a good workaround (press quickly) and Asrock is aware of the issue and is working on it to see if they can do something about it.
So Wait & See.

They have really spent hours on this problem.
Honestly that's the best customer service I have seen in a while !



Print Page | Close Window

Forum Software by Web Wiz Forums® version 12.04 - http://www.webwizforums.com
Copyright ©2001-2021 Web Wiz Ltd. - https://www.webwiz.net