This is a 4.4-rc3 regression, I cannot reproduce on 4.4-rc2 When the AC adapter is unplugged and the laptop tries to wake from suspend instead of a wakeup a reboot will occur. Never managed to reproduce when the AC plugged in (tried around 20 suspend cycles) Unplug the AC - send the laptop to suspend - press any key to wake up -> reboot Unplug the AC - send the laptop to suspend - plug AC back in - try to wake -> reboot Suspend while AC attached -> unplug AC -> try to wake -> reboot Tried about 15 cycles and it happens every time. The reboot is instant, flashing leds or blank screen occurs, the last log entry is of a successful suspend.
Still happens with 4.4-rc4
I have to correct myself. This is also reproducible using 4.4-rc2
is there any kernel that the problem does not exist?
I did not have too much time to build and try different kernels, but the laptop is only functional with 4.2 and 4.4 rc kernels since 4.3 produced black only screen last time I tried. This wakeup-reboot bug is a bit hectic, I *feel* it happens more often on 4.4-rc4 but It happened on rc2 also but I don't know how to trigger it, but once it happened it will do it every time until the next full shutdown cycle so maybe it is firmware related. The only thing I am sure at this point is that it never happenes with the dual-booted Windows. Would you like me to provide some additional info about the firmware or run some command?
please check if the problem still exists if you boot with "idle=poll".
Hi! Thanks I will try that. Currently I'm struggling to reproduce this bug. Sometimes it just happens and then it will happen until the next proper shutdown but I don't see any specific reason that causes it. When I opened the bug it just appeared frequently, nowadays it occurs once or twice a week.
Possibly unrelated, but I have been seeing very similar behavior on 4.4.0 with a Dell XPS 15 9550 (also skylake). My experience is reversed, starting with little to no suspend issues over the last month and now rebooting on almost every attempted resume. It may be coincidence but initial testing has suspend and resume functioning correctly when plugged in and the sleep is very brief. I'll try to test a bit with idle=poll and report back.
I was meaning to close this ticket because I could not reproduce it in the last month.
Okay, maybe I can enlighten things a bit. I have UX305UA, not CA, but there's the same issue. It happens when UEFI/Bios FastBoot is On. Resumes correctly when off. Kernel 4.4.2 and 4.5.0rc6
Are you dual booting Windows on it? I am not totally sure but I had the feeling that the bug disappeared when I remove windows from the laptop and started using Linux exclusively.
There's no windows on my side. I have no idea what fastboot is related to acpi.
can you please send the acpidump both when UEFI/Bios FastBoot is enabled & disabled?
Created attachment 210301 [details] UX305UA acpi dumps Sorry for the late feedback, was on some OSS conf. Here's split acpi dumps.
Binary files no_fastboot/dbgp.dat and with_fastfoot/dbgp.dat differ diff -ru no_fastboot/dbgp.dsl with_fastfoot/dbgp.dsl --- no_fastboot/dbgp.dsl 2016-04-08 11:25:22.258411301 -0400 +++ with_fastfoot/dbgp.dsl 2016-04-08 11:25:22.315078235 -0400 @@ -13,7 +13,7 @@ [000h 0000 4] Signature : "DBGP" [Debug Port table] [004h 0004 4] Table Length : 00000034 [008h 0008 1] Revision : 01 -[009h 0009 1] Checksum : 72 +[009h 0009 1] Checksum : 9A [00Ah 0010 6] Oem ID : "INTEL " [010h 0016 8] Oem Table ID : "" [018h 0024 4] Oem Revision : 00000000 @@ -21,7 +21,7 @@ [020h 0032 4] Asl Compiler Revision : 0000005F [024h 0036 1] Interface Type : 00 -[025h 0037 3] Reserved : 69CC87 +[025h 0037 3] Reserved : 2B0069 [028h 0040 12] Debug Port Register : [Generic Address Structure] [028h 0040 1] Space ID : 01 [SystemIO] @@ -33,7 +33,7 @@ Raw Table Data: Length 52 (0x34) - 0000: 44 42 47 50 34 00 00 00 01 72 49 4E 54 45 4C 20 // DBGP4....rINTEL + 0000: 44 42 47 50 34 00 00 00 01 9A 49 4E 54 45 4C 20 // DBGP4.....INTEL 0010: 00 00 00 00 00 00 00 00 00 00 00 00 4D 53 46 54 // ............MSFT - 0020: 5F 00 00 00 00 87 CC 69 01 08 00 00 40 02 00 00 // _......i....@... + 0020: 5F 00 00 00 00 69 00 2B 01 08 00 00 40 02 00 00 // _....i.+....@... 0030: 00 00 00 00 // .... Binary files no_fastboot/facs.dat and with_fastfoot/facs.dat differ diff -ru no_fastboot/facs.dsl with_fastfoot/facs.dsl --- no_fastboot/facs.dsl 2016-04-08 11:25:22.301744839 -0400 +++ with_fastfoot/facs.dsl 2016-04-08 11:25:22.351745073 -0400 @@ -12,7 +12,7 @@ [000h 0000 4] Signature : "FACS" [004h 0004 4] Length : 00000040 -[008h 0008 4] Hardware Signature : 56784D3B +[008h 0008 4] Hardware Signature : 7A65553E [00Ch 0012 4] 32 Firmware Waking Vector : 00000000 [010h 0016 4] Global Lock : 00000000 [014h 0020 4] Flags (decoded below) : 00000000 @@ -26,7 +26,7 @@ Raw Table Data: Length 64 (0x40) - 0000: 46 41 43 53 40 00 00 00 3B 4D 78 56 00 00 00 00 // FACS@...;MxV.... + 0000: 46 41 43 53 40 00 00 00 3E 55 65 7A 00 00 00 00 // FACS@...>Uez.... 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 // ................ 0020: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 // ................ 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 // ................
IOW: no relevant changes. FACS looks relevant but is actually set by the kernel. DBGP is totally irrelevant.
I have a UX305U and I'm also encountering the reboot after suspend issue (actually just had it now). I'm running the latest kernel provided by ArchLinux which is 4.5.0. I will try deactivating the fast boot feature. PS: do you guys also have screen issues? When on battery, the screen keeps flickering like crazy. The upper or lower part of the screen repeatedly goes black for a fraction of a second. When on power, it pretty much stop. I tried with the intel video driver and the modesetting driver, but it didn't change anything. Anyway, if you know of a bug report related to this issue before I open a new one, let me know!
As suggested above, I tried deactivating UEFI/Fastboot but the laptop still reboots after waking up from suspend. Let me know if you need more information or if there is something I can do to help.
I have exactly the same issue with my ASUS Zenbook UX303. When I tried to wake up from suspend, it immediately rebooted. This only happened when AC adapter was unplugged.
Okay, now we have four reporters in this thread, all with Asus laptops. 1. János Illés, ASUS Zenbook UX305CA, the original reporter, prefers to close this bug report because it can not be reproduced any more, after removing windows partition. 2. Francois Cartegnie, ASUS Zenbook UX305UA, confirmed clear BIOS Fastboot workarounds the problem. 3. Joël Porquet, UX305U, confirmed that the BIOS Fastboot workaround doesn't work. 4. Yi Hong, ASUS Zenbook UX303. IMO, we should confirm if we're experiencing exactly the same issue here, or else the response from different reporter would be misleading. So, Francois, Joël and Yi, can you please confirm Q1. the problem can only be reproduced with AC unplug actions, like János described in comment #0? Q2. Yi, please confirm if the BIOS fastboot trick works for you or not. Q3, do you have dual boot windows installed? If yes, please don't use windows (don't try boot into windows), and see if the problem can be reproduced.
Okay, so I did test again today, and this time it does not work. Pretty sure resume from suspend (lid closed) did work on battery. This gets really confusing for me. So, today, whatever combination: * Plugged from start/in session. * Unplugged before/while suspend. * Suspend by Lid/Button/command * Wake on button/key * Fastboot enabled/disabled Everything ends with a reboot on wakeup. Could it depend on something else ? Wifi ? Battery state ?
Yes, I have dual boot Windows 10 installed but I haven't used it for weeks. I experienced exactly the same as János described above, this only happened when AC adapter was unplugged. Disabling Fastboot in BIOS does the trick for me, thanks!
Okay, so confirms the weirdness of the issue. Just after posting the above comment, I tried rebooting and switch FN+F2 wifi off which didn't worked. And I did unplug the AC from the power socket (not the PC plug). And now, every wake from suspend works.
Hi Zhang, Thanks for taking the time to reach to us! > Q1. the problem can only be reproduced with AC unplug actions, like János > described in comment #0? > Q2. Yi, please confirm if the BIOS fastboot trick works for you or not. > Q3, do you have dual boot windows installed? If yes, please don't use > windows (don't try boot into windows), and see if the problem can be > reproduced. I do not have dual boot, just Linux. When I hit the issue described in this bug report, I always made sure that my laptop was connected to AC, before attempting a wake from suspend, which has been working fine for the past few weeks. Now, I tried again tonight without AC plugged (Linux 4.5.2 on ArchLinux) and everything seems to work! :) I tried activating/deactivating fastboot and suspending/waking up with AC unplugged, and I wasn't able to reproduce the inopportune reboot in any of the combination. Was a fix committed in the kernel between 4.5.1 and 4.5.2? Thanks, Joël
(In reply to Joël Porquet from comment #23) > Hi Zhang, > > Thanks for taking the time to reach to us! > > > Q1. the problem can only be reproduced with AC unplug actions, like János > > described in comment #0? > > Q2. Yi, please confirm if the BIOS fastboot trick works for you or not. > > Q3, do you have dual boot windows installed? If yes, please don't use > > windows (don't try boot into windows), and see if the problem can be > > reproduced. > > I do not have dual boot, just Linux. > > When I hit the issue described in this bug report, I always made sure that > my laptop was connected to AC, before attempting a wake from suspend, which > has been working fine for the past few weeks. > > Now, I tried again tonight without AC plugged (Linux 4.5.2 on ArchLinux) and > everything seems to work! :) > > I tried activating/deactivating fastboot and suspending/waking up with AC > unplugged, and I wasn't able to reproduce the inopportune reboot in any of > the combination. > So can you reproduce the problem with AC plugged? I'm trying to make clear if AC plug/unplug makes any difference in this bug report. > Was a fix committed in the kernel between 4.5.1 and 4.5.2? I don't know. But I'd suggest Francois and Yi to try 4.5.2 kernel as well, maybe even the same kernel configuration.
(In reply to Francois Cartegnie from comment #20) > Okay, so I did test again today, and this time it does not work. > Pretty sure resume from suspend (lid closed) did work on battery. > This gets really confusing for me. > > So, today, whatever combination: > * Plugged from start/in session. > * Unplugged before/while suspend. > * Suspend by Lid/Button/command > * Wake on button/key > * Fastboot enabled/disabled > > Everything ends with a reboot on wakeup. > what kernel version are you using? Can you try 4.5.2?
(In reply to Yi Hong from comment #21) > Yes, I have dual boot Windows 10 installed but I haven't used it for weeks. > I experienced exactly the same as János described above, this only happened > when AC adapter was unplugged. > > Disabling Fastboot in BIOS does the trick for me, thanks! what kernel version are you using? please try 4.5.2.
(In reply to Zhang Rui from comment #24) > So can you reproduce the problem with AC plugged? > I'm trying to make clear if AC plug/unplug makes any difference in this bug > report. As I was saying, I didn't have the problem when AC was plugged. And I confirm that I still don't. AC plug/unplug was making a difference before (at least for me), but doesn't seem to make a difference now. Thanks, Joël
(In reply to Joël Porquet from comment #27) > (In reply to Zhang Rui from comment #24) > > So can you reproduce the problem with AC plugged? > > I'm trying to make clear if AC plug/unplug makes any difference in this bug > > report. > > As I was saying, I didn't have the problem when AC was plugged. And I > confirm that I still don't. > > AC plug/unplug was making a difference before (at least for me), but doesn't > seem to make a difference now. > so it seems that you're now in the same page with János Illés, the original bug reporter, and you're not able to reproduce the problem any more, right?
(In reply to Zhang Rui from comment #28) > (In reply to Joël Porquet from comment #27) > > (In reply to Zhang Rui from comment #24) > > > So can you reproduce the problem with AC plugged? > > > I'm trying to make clear if AC plug/unplug makes any difference in this > bug > > > report. > > > > As I was saying, I didn't have the problem when AC was plugged. And I > > confirm that I still don't. > > > > AC plug/unplug was making a difference before (at least for me), but > doesn't > > seem to make a difference now. > > > so it seems that you're now in the same page with János Illés, the original > bug reporter, and you're not able to reproduce the problem any more, right? Yes, correct.
Good to know. Now let's see if Yi and Francois can reproduce the problem or not, after switching to the same kernel as yours.
(In reply to Joël Porquet from comment #23) > I tried activating/deactivating fastboot and suspending/waking up with AC > unplugged, and I wasn't able to reproduce the inopportune reboot in any of > the combination. > > Was a fix committed in the kernel between 4.5.1 and 4.5.2? As mentioned in my latest tests, with the same exact configuration it was 100% failing then 100% working the same day. There's an unidentified "switch" that triggers the issue, whatever the kernel was (4.2, 4.6), and i'm still unable to identify it.
Created attachment 215921 [details] UX305UA acpidump kernel 4.4.8 nofastboot (rebooting) I've been able to put the device into the "crash" mode. Seems the long button off press/hard reset has something to do. The new acpidump (rebooting) now differs from the previous ones (with/without fastboot, but when the problem was not occuring).
Additional info: - kernel 4.4.8 reboots - kernel 4.5.3 reboots - kernel 4.6.0rc7 reboots Whilst the last acpidump attachment is different from the first ones, it is now the same when reboots does not happen. Seems the long press/hard forced poweroff is the key to put it in rebooting behavior. Still haven't figured how it exits. Can someone, with a non rebooting one, test again by forcing shutdown with power button longpress and see if it restarts rebooting on wakeup ?
Can reproduce on an Asus GL552VW (Skylake 6700HQ) I think that didn't had the issue on 4.2/4.3. Sometimes suspend resumes properly, but I'm still to find a pattern. I have three kernels, 4.5, 4.5 with CK patches, and 4.6. I think that the last time I had a successful resume was on 4.5-ck a day or two ago, but at least 9 out of 10 times it will simply reboot. Still probably has nothing to do with the -ck patchset I also have Ubuntu (16.04) on a small partition and it also reproduces the issue, but not as often. The main difference here is that besides patched packages, Ubuntu is using the dedicated GPU while my main OS (Arch) doesn't. Also when plugged to AC resume will always work, unless if the suspension happened while on battery power. If that's the case it might as well reboot. I think that the issue is being triggered by some mechanism that only works when on battery. Not 100% sure if it'll happen if I suspend when plugged to AC, unplug, plug again, and resume. Overall Skylake has been a bag of problems and I'm quite tired of dealing with its bugs, still if you need any specific information or output dump just ask for it, but I won't spend dozens of hours trying software combinations with this bug.
@Francois Arg! I didn't want to try to forcefully reboot my laptop because I was so happy not to have the bug anymore, but earlier today my computer crashed and I had to shut it off using the long press on the power button. And now, the bug is back, my laptop just rebooted upon wake up from suspend ;( So I guess you're right, it is the trigger that causes this awful bug to happen. Have you figured out a way to make it disappear by any chance?
Hi, I have an Asus Zenbook UX303UB and I've been experiencing the same problem (reboot on wake-up from suspend when on battery; fine when power plugged in). Disabling Fast Boot in the BIOS seems to have fixed the problem for me. I am running Debian's 4.6.2: $ uname -a Linux corsica 4.6.0-1-amd64 #1 SMP Debian 4.6.2-2 (2016-06-25) x86_64 GNU/Linux Happy to provide any more information if needed!
(In reply to Joël Porquet from comment #35) > So I guess you're right, it is the trigger that causes this awful bug to > happen. > > Have you figured out a way to make it disappear by any chance? First try saving bios config and see if that changes something. (as mentioned turning off Fast Boot solves the issue, but isn't related to crash). then try wifi switch. (which might also write last state to bios)
(In reply to Francois Cartegnie from comment #37) > (In reply to Joël Porquet from comment #35) > > So I guess you're right, it is the trigger that causes this awful bug to > > happen. > > > > Have you figured out a way to make it disappear by any chance? > > First try saving bios config and see if that changes something. > (as mentioned turning off Fast Boot solves the issue, but isn't related to > crash). > then try wifi switch. (which might also write last state to bios) Turning off fast boot didn't help right away for me. It was still rebooting upon resume after suspend... However, by playing several times with the fast boot option in the bios in between manual reboots, I was able to finally get rid of the bug. Don't ask me the exact procedure though, at this point it's total magic...
Same issue here with ASUS N752vx (Vivobook Pro): Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz], 4.6.3-1-default #1 SMP PREEMPT Sun Jun 26 07:34:33 UTC 2016 (d4bcf2a) x86_64 1, If the suspend-resume is works once, it is works right until the next reboot. 2, After reboot, the suspend-resume rarely works, most of times not works: instead of resume it will be reboot. 3, If the suspend-resume is not works once, it won't work most of times.
Hm... the continuously plugged AC "trick" works most of time with the N752vx too: 1, AC plugged 2, suspend 3, 5 secs sleep, 10 minutes sleep, 8 hours sleep 4, Normal wake up 1, AC plugged 2, suspend 3, AC unplug and plug instantly 4, Reboot instead of wake up But the wake up with unplugged AC has worked a month ago... hm.
I'm running a Dell XPS 15 9050, and have been suffering from a similar problem for a long time. In the past, I can solve it by disabling SpeedStep and C States, but it is no longer working. Now I can solve it by disabling TLP, but it results in bad battery performance. Hope there're other ways to make it work properly...
I can fix the problem by disabling TLP's runtime power management: RUNTIME_PM_ON_BAT=on while keep TLP enabled. The laptop still feels hotter than usual, but bearable now.
> RUNTIME_PM_ON_BAT=on Its working... hm... the settings of AC was "on" (=disabled): RUNTIME_PM_ON_AC=on For months the suspend-wakeup worked fine, then a couple of weeks ago I changed the settings TLP...
(In reply to Wei Tang from comment #42) > I can fix the problem by disabling TLP's runtime power management: > RUNTIME_PM_ON_BAT=on Yesterday: worked until reboot Today: not working, even disabled TLP I don't know what is the key... I feel that is not random, but I don't know what is the reason... it is annoying... :(
(In reply to Gábor AUTH from comment #44) > (In reply to Wei Tang from comment #42) > > I can fix the problem by disabling TLP's runtime power management: > > RUNTIME_PM_ON_BAT=on > > Yesterday: worked until reboot > Today: not working, even disabled TLP > > I don't know what is the key... I feel that is not random, but I don't know > what is the reason... it is annoying... :( Well, that's wired... Here're several things I tried before RUNTIME_PM_ON_BAT=on: 1. Update my kernel from 4.4 to 4.6. 2. Disable Fastboot in BIOS. 3. Disable SpeedStep and C States in BIOS. It has been working for me for a day now. I'll get back if it happens again.
(In reply to Wei Tang from comment #45) > (In reply to Gábor AUTH from comment #44) > > (In reply to Wei Tang from comment #42) > > > I can fix the problem by disabling TLP's runtime power management: > > > RUNTIME_PM_ON_BAT=on > > > > Yesterday: worked until reboot > > Today: not working, even disabled TLP > > > > I don't know what is the key... I feel that is not random, but I don't know > > what is the reason... it is annoying... :( > > Well, that's wired... Here're several things I tried before > RUNTIME_PM_ON_BAT=on: > > 1. Update my kernel from 4.4 to 4.6. > 2. Disable Fastboot in BIOS. > 3. Disable SpeedStep and C States in BIOS. > > It has been working for me for a day now. I'll get back if it happens again. Also, I have acpi_sleep=nonv and idle=poll in boot parameters.
> 1. Update my kernel from 4.4 to 4.6. 4.6.3-1 > 2. Disable Fastboot in BIOS. Disabled. > 3. Disable SpeedStep and C States in BIOS. Hm... I will check it at the next reboot (soon). > Also, I have acpi_sleep=nonv and idle=poll in boot parameters. My parameters: intel_idle.max_cstate=7 idle=nomwait nouveau.modeset=0 pci=noaer acpi_backlight=native acpi_osi=! Without 'nouveau.modeset=0' it is freezing on boot, without 'pci=noaer' the advanced error reporting write a lot of warning message, without 'acpi_backlight=native' the fn- buttons are not working. I've tried a lot of combinations and I will try add the 'acpi_sleep=nonv' and the 'idle=poll' parameters too.
Whaaaa... I did nothing, yesterday did not work, today it is working, wake up on battery, but: [15782.225212] WARNING: CPU: 0 PID: 11963 at ../arch/x86/kernel/check.c:141 check_corruption+0xa/0x40 [15782.225214] Memory corruption detected in low memory
Hello everyone. I can also confirm the wake up from sleep issue on assus zenbook ux305ua. it goes into sleep, but when it tries to wake up, it restarts. It only happens if power brick is not connected. So when it is on battery it restarts, when on AC it works without acpi_sleep=nonv. I have tried kernel 4.4.0, 4.5.0, 4.6.4 and 4.7 RC7. All of them have the same problems with or without 'acpi_sleep=nonv'. The only way i managed to make it work, is to resume it when it AC is plugged in. Any ideas about the bug ? I would really appreciate a fix / workaround if any of you found something.
At the moment the wake up on battery works with these kernel parameters: "quiet splash=silent nouveau.modeset=0 pci=noaer acpi_backlight=native acpi_osi=!" I don't know why... :(
Hi everyone! Did you try to update the laptop firmware? I've read somewhere that Skylake microcode can be quite buggy and the only way to update skylake microcode as far as I know is to update the firmware. (I'm the original reporter of this bug, and the bug simply went away by itself for me, really strange, I use no kernel parameters)
Hi, Running 4.6.4-1 in an ASUS GL552VW, having the exact original issue as the initial reporter. Suspend and resume work fine while the power is connected to the laptop, but reboots when trying to resume if the power was disconnected at any point while it was suspended. Tried all the quirks in this bug thread: - turning on and off fast boot between manual restarts / shutdowns - boot parameters idle=poll and acpi_sleep=nonv Like a lot of the other reporters I do remember that there were some times when the resume from battery would work fine, but can't think of what the cause may have been in between. I had a weird issue with this laptop where plugging or removing anything into the USB3 ports would cause a power short and nothing would turn the laptop back on unless I unplugged the power and took the battery out for a few seconds. Anyway I tried taking the battery out for a few seconds, turning back on and the issue has been resolved! To confirm I did a hard reset by holding the power button down and the problem returned. Powered off and removed battery, wait, replace battery, resumes fine from battery again. Took acpi dumps before and after the removal of the battery and there were no differences in anything. I switched over to windows to try and reproduce the bug - and I could, same issue with windows, hard reset causes reset on resume while taking the battery out resumes expected behaviour, I don't think that this is a kernel bug, I think that this might be a hardware issue, seems like it's limited to ASUS laptops?
(In reply to Mark Flynn from comment #52) > bug, I think that this might be a hardware issue, seems like it's limited to > ASUS laptops? Not limited to Asus, as there's mention of Dell laptops as well. But definitively related to Skylake. The same device is also plagued with black screen on boot when patched with Intel's microcode update. Not a kernel issue since this is distro related, but see fedora as ex https://bugzilla.redhat.com/show_bug.cgi?id=1353103 There is also mention of uefi updates for some Asus series. Worth trying for the current bug.
> Did you try to update the laptop firmware? There is no new BIOS update... > I use no kernel parameters I'm using these kernel parameters because of the nouveau driver modeset issue, disabling the bug of PCI advanced error reporting and enable the fn-x keys on the laptop. I've tried lot of other kernel parameters too (idle, acpi_sleep, intel_max.idle_cstate, etc)... but now it works without any extra kernel parameters... :) ...but I don't know why... :(
I have this bug on my Asus UX305C notebook. For my computer, it doesn't matter if it is plugged in to the power supply or not - it will reboot when I try to resume from a full hibernation. Suspend works fine. Running Linux Mint with the 4.4.0-31-generic kernel. I have upgraded to the latest (version 300, 2016-06-24) bios from the Asus website as suggested in Comment 51 - no change. I also tried the kernel parameters as suggested in Comment 50 - again, no difference or improvement in behavior. Any help with this annoying bug is appreciated. Thanks all!
P.S. Fastboot is switched off in BIOS settings.
I have this problem on my Asus Zenbook UX301LA after I reinstalled Ubuntu 16.04. Before the reinstall, suspending worked flawlessly for almost 2 years. Unfortunately, I do not know which kernel I was running, or which options I had set, but I know I did not run a custom kernel (aka I was running whatever kernel 16.04 fed me). I have been battling this suspend problem for a couple of days now, trying all kinds of options and Googling a ton. It has not worked a single time. These are the things I have tried: * AC no AC * Fastboot enabled/disabled * Launch CSM yes/no * Kernel 4.4, 4.6, 4.7 * acpi_sleep=nonvs The reason I reinstalled Ubuntu was because I bricked my SSD by ironically pressing the power button for 10 seconds, forcing a shutdown because the computer had crashed. Obviously, I had forced shutdowns at least a 100 times before, without bricking or causing anything. I was running an older BIOS before, 209 I think, but I updated it to 211 when trying to fix this problem. Didn't work. The amount of frustration right now is unmeasurable........
I just had an 8 hour run with trying to install older versions, 15.04 and 15.10, as well as 16.10 alpha, on my UX301LA. Suspend did not work on 15.10, and I failed to install 15.04 (not sure why, but it just would not work). I also failed to install 16.10 (the installer crashed, so it's probably just a temporary problem in today's daily). Back on 16.04 with 4.4 kernel, will do a complete wipe of my computer (and BIOS) in a few weeks when I have gotten the aforementioned bricked SSD replaced, so that I can dual-boot and see if Windows can suspend fine. Will report back.
Asus Zenbook UX305UA here with F24. I've noticed so far that if the WiFi light turns on (the little light on the F2 key), then suspend will cause a reboot. Not sure if the correlation is 100$ or not because I tend not to reboot due to this problem. My laptop ran out of batteries today, and, this may be black magic, but by toggling on and off airplane mode via fn+f2 and restarting, suspend is now fine (and the wifi light is off). Anxiously awaiting a bios update from Asus.
I can confirm that the state described by Cosmin Deaconu is not 100% correlated with a solution to this problem. I managed to get my laptop into the same state by following his instructions, and while I have a vague memory that this is the state the laptop was in when it was working a month ago, suspend still doesn't work for me now. What BIOS version are you on Cosmin?
I am having the same issue on Asus GL552VW with samsung 850 evo (500GB) ssd. BIOS version 218 Arch Linux with kernel 4.7: $ uname -a Linux stoelzel 4.7.0-1-ARCH #1 SMP PREEMPT Mon Aug 8 22:05:58 CEST 2016 x86_64 GNU/Linux acpi_sleep=nonvs Resumes normally on AC but reboots instead when on battery. Fast boot off/on Launch CSM off/on Somewhat magically, after disabling the "wake on lid open" in bios, resuming from battery/AC seems to work perfectly, but like Comment 59, I don't think this has any correlation at all.
I got one of my SSDs replaced, so took the opportunity to completely wipe the computer and start over. I now got Ubuntu 16.04 on one drive and Windows 10 on the other. I can, therefore, confirm that this bug is as previously discussed not limited to Ubuntu, but possibly caused by Ubuntu. There are 2 actions that could have put my laptop into this non-working state: 1. Updating the BIOS to the latest version (211) from 209. 2. Reinstalling Ubuntu 16.04. Since suspend doesn't work in Windows either, I'm thinking of calling Asus and talk with them about it. I'm suspecting the BIOS is at fault.
I have an Asus UX303UB and had the very same issue since the beginning. It worked from time to time but since I am on 4.7 (a few weeks now) it always rebooted after suspend. Last week I finally updated my BIOS from 202 to 206 which was the latest version I found on the Asus website and I am using the parameters from https://bugzilla.kernel.org/show_bug.cgi?id=108801#c50 now. Since then resume works like a charm and I never got a reboot. May be a coincidence. We will see. :)
Thanks a lot for reporting in Christian! I'm glad you were able to get it to work. Thanks to your information, I now got this refined theory: * ASUS UX303UB had BIOS v202 released on 2015/09/28 * ASUS UX301LA had BIOS v211 released on 2015/09/16 Clearly they are related (because similar models, etc.). With Linux kernel 4.4 (could be 4.*) and onwards, something changed that broke the suspend functionality for Asus UX30* BIOS September 2015 release. This problem was later fixed by Asus on 2016/04/15 by releasing v206 for UX303UB. However, such an update has clearly not been released for the older UX301LA yet. Solution? Nag ASUS until they release such an update (and that I will do). Here are the reasons to why this theory might be true: * My suspend worked fine on Linux kernel <=4.4 (Ubuntu 16.04) with BIOS 209, released on 2014/06/18. * After updating to BIOS 211, Linux kernel 4.4+ breaks suspend, putting the computer in a faulty state that inhibits all other operating systems to suspend as well (because I tried with Windows). * Christian said it worked for him before he updated his kernel, and after he updated his BIOS. Now, this is obviously just a theory, but hey, I ain't got nothing else to believe.
I have now submitted a support request on the ASUS website, referring them to this thread and briefly describing the problem. I'll post here when I hear back.
It seems that we have quite a few reporters here, :) My intention is to close this one as it sounds like a BIOS issue and have been fixed by BIOS for some of the models. Not sure everyone agrees with me or not, but for people who think this is a kernel problem, we should 1. show that the problem can be reproduced after a kernel update, without upgrading the BIOSes. 2. run git bisect to help find out which commit introduce the problem to these Asus platforms. If no one helps me do this, I will close this bug and let's ping the Asus website to get BIOS upgrade.
I've updated the BIOS of my N752VX from version 204 (2016/02/25) to version 300 (2016/09/30) and nothing changed with the 4.7.5 kernel... :(
I also have a new UX305UA and have this problem. I upgraded my kernel to 4.6.0. I've tried all the permutations of kernel options discussed in this thread, and turned off the fastboot and wake-on-lid BIOS options. I'd love to upgrade the firmware, but 201 is the highest version firmware for this model so far. I've also pinged ASUS support in hopes they can accelerate a firmware upgrade.
I have an UX305U and runs Debian 8.6. I was using kernel 4.6.0 and suspend works fine. But I upgraded to kernel 4.7.0 and suspend mode causes the reboot. I tried the solutions here (ie, remove fastboot or airplane mode in comment #59) but they don't work.
The content of attachment 210301 [details] has been deleted for the following reason: deleted upon request due to private information leak
The content of attachment 215921 [details] has been deleted for the following reason: deleted upon request due to private information leak
Can I chip in with the same issue. Running Kernel 4.8.3 on openSuse Tumbleweed on a HP 'Star Wars' laptop, HP Pavilion Notebook/80A1, BIOS F.78 03/07/2016 When on battery, and the lid is closed, upon opening, im back at a fresh desktop, so I assume it has rebooted.
(In reply to Fredrik Blomqvist from comment #65) > I have now submitted a support request on the ASUS website, referring them > to this thread and briefly describing the problem. I'll post here when I > hear back. I've submitted support request as well: Clueless support is just telling there's no bios update, and ask for a W10 install and a return... which indeed is useless as they can't solve the issue for the aforementioned reason. Pointing out W10, googling gives results about "W10 black screen" after resume. I'm wondering then if anyone has double boot and experiences both issues. Unrelated, but I also experience other flaws with firmware or hw: if anyone has UX305UA and USB 3.0 physical detection issues when not using hub, especially with Lexar (P10 or old lightning) brand. Feedback welcome.
> Clueless support is just telling there's no bios update, and ask for a W10 > install and a return... which indeed is useless as they can't solve the > issue for the aforementioned reason. The type of my laptop is N752VX, ASUS has released two new BIOS version (300 and 301) but both of them "crap" from the point of my view... :( ...but the hibernation works which is a reasonable workaround. :)
As I've written, I'm using `systemctl hybrid-sleep` as a workaround, but my laptop never wake up from the suspend, just reboot and restore the state from the saved hibernation image. At the moment, the wake up worked but: [ 9288.467395] PM: Hibernation mode set to 'suspend' [ 9288.740734] PM: Syncing filesystems ... done. [...] [ 9337.874250] usb usb3: root hub lost power or was reset [ 9337.874252] usb usb4: root hub lost power or was reset [ 9342.014040] Corrupted low memory at ffff8cb4c0001000 (1000 phys) = fa1c1382940e0813 [...] [ 9342.014184] Corrupted low memory at ffff8cb4c0001188 (1188 phys) = b094f7cb4dc91844 [ 9342.014199] ------------[ cut here ]------------ [ 9342.014208] WARNING: CPU: 0 PID: 13794 at ../arch/x86/kernel/check.c:141 check_corruption+0xa/0x40 [ 9342.014209] Memory corruption detected in low memory [ 9342.014212] Modules linked in: snd_seq_dummy snd_seq snd_seq_device cmac rfcomm af_packet nf_log_ipv6 xt_pkttype nf_log_ipv4 nf_log_common xt_LOG xt_limit bnep msr nls_iso8859_1 nls_cp437 vfat fuse fat dm_crypt algif_skcipher af_alg uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev btusb btrtl joydev arc4 dm_mod ip6t_REJECT nf_reject_ipv6 intel_rapl xt_tcpudp x86_pkg_temp_thermal intel_powerclamp nf_conntrack_ipv6 coretemp snd_hda_codec_hdmi nf_defrag_ipv6 snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm ip6table_raw ipt_REJECT nf_reject_ipv4 i2c_designware_platform i2c_designware_core iptable_raw xt_CT asus_nb_wmi iwlmvm asus_wmi iTCO_wdt iTCO_vendor_support sparse_keymap iptable_filter snd_timer kvm_intel mac80211 [ 9342.014287] snd kvm irqbypass crct10dif_pclmul hci_uart crc32_pclmul iwlwifi crc32c_intel btbcm ghash_clmulni_intel btqca btintel rtsx_pci_ms i2c_i801 ip6table_mangle bluetooth idma64 r8169 cfg80211 memstick pcspkr soundcore i2c_smbus mii aesni_intel mei_me int3403_thermal aes_x86_64 virt_dma processor_thermal_device lrw nf_conntrack_netbios_ns glue_helper ablk_helper mei cryptd elan_i2c intel_lpss_pci intel_soc_dts_iosf nf_conntrack_broadcast battery rfkill shpchp thermal pinctrl_sunrisepoint intel_lpss_acpi nf_conntrack_ipv4 nf_defrag_ipv4 intel_lpss pinctrl_intel ip_tables asus_wireless int3402_thermal int340x_thermal_zone int3406_thermal ac tpm_crb xt_conntrack tpm_tis int3400_thermal acpi_thermal_rel acpi_pad tpm_tis_core fjes tpm nf_conntrack ip6table_filter ip6_tables x_tables rtsx_pci_sdmmc [ 9342.014361] mmc_core mxm_wmi serio_raw i915 rtsx_pci i2c_algo_bit mfd_core drm_kms_helper syscopyarea xhci_pci sysfillrect sysimgblt xhci_hcd fb_sys_fops sr_mod cdrom usbcore drm usb_common i2c_hid wmi video button sg efivarfs [ 9342.014392] CPU: 0 PID: 13794 Comm: kworker/0:1 Not tainted 4.8.3-1-default #1 [ 9342.014394] Hardware name: ASUSTeK COMPUTER INC. N752VX/N752VX, BIOS N752VX.301 08/18/2016 [ 9342.014399] Workqueue: events check_corruption [ 9342.014402] 0000000000000000 ffffffffba3a3e62 ffff8cb6b2eb3dd0 0000000000000000 [ 9342.014409] ffffffffba07ddde ffffffffbae2ab00 ffff8cb6b2eb3e20 ffff8cb943c18e80 [ 9342.014415] ffffbb60bfc02d00 0000000000000000 0ffffbb60bfc02d0 ffffffffba07de4f [ 9342.014420] Call Trace: [ 9342.014440] [<ffffffffba02eefe>] dump_trace+0x5e/0x310 [ 9342.014449] [<ffffffffba02f2cb>] show_stack_log_lvl+0x11b/0x1a0 [ 9342.014457] [<ffffffffba030001>] show_stack+0x21/0x40 [ 9342.014465] [<ffffffffba3a3e62>] dump_stack+0x5c/0x7a [ 9342.014471] [<ffffffffba07ddde>] __warn+0xbe/0xe0 [ 9342.014480] [<ffffffffba07de4f>] warn_slowpath_fmt+0x4f/0x60 [ 9342.014485] [<ffffffffba0600ea>] check_corruption+0xa/0x40 [ 9342.014493] [<ffffffffba0966bd>] process_one_work+0x1ed/0x4d0 [ 9342.014503] [<ffffffffba0969e7>] worker_thread+0x47/0x4c0 [ 9342.014508] [<ffffffffba09c59d>] kthread+0xbd/0xe0 [ 9342.014517] [<ffffffffba6d461f>] ret_from_fork+0x1f/0x40 [ 9342.018541] DWARF2 unwinder stuck at ret_from_fork+0x1f/0x40 [ 9342.018544] Leftover inexact backtrace: [ 9342.018550] [<ffffffffba09c4e0>] ? kthread_worker_fn+0x170/0x170 [ 9342.018585] ---[ end trace 305f7c8bd168440c ]--- After this, some program throws general protection errors, but the rest of the system seems ok: [13959.338814] general protection fault: 0000 [#1] PREEMPT SMP [...] [13959.339333] CPU: 1 PID: 18133 Comm: zypper Tainted: G W 4.8.3-1-default #1 [13959.339352] Hardware name: ASUSTeK COMPUTER INC. N752VX/N752VX, BIOS N752VX.301 08/18/2016 [...]
Created attachment 242751 [details] Content of the dmesg of a faulty resume
(In reply to Facundo Bianco from comment #69) > I have an UX305U and runs Debian 8.6. I was using kernel 4.6.0 and suspend > works fine. But I upgraded to kernel 4.7.0 and suspend mode causes the > reboot. Now it works on kernel 4.7.8.
> Now it works on kernel 4.7.8. Kernel 4.8.4, N752VX, latest BIOS, still crap... :(
Upgraded from 16.04 to 16.10, comes with Kernel 4.8. Still not working, same problem as earlier (reboot after suspend). Tried downgrading to 4.7.8, but also still the same problem. I have yet to receive a response to my ticket from ASUS, it's been months now. I will most likely give up and buy a new laptop sooner rather than later, and it will for sure not be an ASUS.
Gave it one last shot and actually called ASUS support. They ended up telling me to install the Intel Management Engine Interface (despite it only being listed for the 5th generation CPU, I got a 4th). They said that usually solves the problem. However, it did not. Since there is no more warranty they said I could send it in for service for $690...not gonna happen. Got an extended warranty thing on it so might send it there over Christmas or so. I will try downgrading the BIOS before then, when there's time (since it might brick it).
I had this problem earlier in the year on Asus ROG GL552-VW laptop with Skylake running Linux Mint 18 / Ubuntu Xenial with Linux kernel version 4.5.4. Somehow, it resolved and I don't know what happened (perhaps when I upgraded Linux Mint from 17 to 18). A few days ago the problem re-occurred and I read through the issue, looked on Asus website and found a BIOS / firmware upgrade -- for my laptop it is 300. After I installed the firmware update, this problem went away.
I can confirm this is still an issue with 4.8.6 on an Asus UX305UA. Unfortunately, there are no BIOS updates on Asus site. I am stuck with version 201 which is one year old.
Asus UX305UA with BIOS 201. Earlier, I have been able to make it work by going back to kernel 4.4.0. But after a hard reset (long press on power button), that stopped working, too. I can confirm that the long press seems to trigger it.
I found a temporary workaround. 1. Go into the BIOS and disable "wake on lid open" 2. Reboot into your system 3. Reboot again into the BIOS and enable "wake on lid open" 4. Reboot into your system. 5. Repeat steps 1-4 as needed. After every cycle, suspend the computer and open the lid to see if it wakes. I've had to do this up to 5 times. The computer now wakes on lid open, but it stops working *after* all kernel updates. Does this suggest it's a kernel problem? After a kernel update, steps 1-4 are required again...
Tried the workaround Michele Lacchia found but was not able to get it to work, even after 5 tries. If anyone else gets it to work please do let us know.
This bug also affects my system: • Asus Zenbook UX305UA • Latest BIOS version • 4.8.0-27-generic #29-Ubuntu SMP Thu Oct 20 21:03:13 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux The problem started some days ago. Had some hard resets in the last days. Nothing special else (except the normal system updates). If I can help providing more info, let me know.
This bug also affects my system: Asus X555UQ (6200u skylake) I tried with 4.4, 4.8, 4.8.8, 4.9rc5 kernels. I'm using pcie_aspm=off acpi_osi= acpi_backlight=native parameters. The problem occurs when unplugged or when unplug in sleep mode. If i boot into windows and shutdown couple of times or reflash the same bios problem resolves also this suspend-reboot issue affects Windows too. Also wakeup works but after wakeup a couple of pci-e devices becomes unusable until reboot (usb3 ports, nvidia gpu). Issue is not specific to linux (as it occurs in windows too) but caused by linux. As others mentioned issue caused by hard reset.
One thing to try is to use the Nvidia Persistence Daemon: http://docs.nvidia.com/deploy/driver-persistence/ >apt-get install nvidia-persistenced
I confirm this on a Dell E7470 running Opensuse Tumbleweed, kernel version 4.8.8.1 Suspend and resume works when on AC power, but fails immediately after the shortest removal of the AC plug, and doesn't work at all if running on battery. The original Windows10 worked correctly, thus I suspect a kernel issue. The same kernel works fine on an old Lenovo E125. I'm planning to try other distro to check if it is a general issue. If you need logs, tests, etc for resolving the bug, I'm happy to assist.
I have reinstalled Opensuse Tumbleweed (the previous was also a fresh install, previously the factory default windows 10 was installed) and now the problem is gone. Before reinstall I have installed Opensuse Leap 42.2 and Ubuntu 16.10 for testing other issues, but these were totally removed.
(In reply to Gábor Katona from comment #90) > I have reinstalled Opensuse Tumbleweed (the previous was also a fresh > install, previously the factory default windows 10 was installed) and now > the problem is gone. Before reinstall I have installed Opensuse Leap 42.2 > and Ubuntu 16.10 for testing other issues, but these were totally removed. Likely false negative because something has been saved in bios in between and will reappear after a hard reset. You need to verify after a forced shutdown. (power button down few secs)
Would reflashing the BIOS after a forced shutdown solve the problem? How does one do that? It does not let me reflash the same version. (Asus UX305UA)
(In reply to Francois Cartegnie from comment #91) > Likely false negative because something has been saved in bios in between > and will reappear after a hard reset. > > You need to verify after a forced shutdown. (power button down few secs) Hm. I have tried. After the first forced shutdown you were right. Suspend resulted in reboot running from battery. I was quite disappointed. BUT! After this first failure it worked again, and is still working, even after forced shutdowns (power button for few secs). Strange, but at least now it works. However I still hold, that the problem exits, although it's appearance seems somehow indeterministic.
(In reply to Gábor Katona from comment #93) > Hm. I have tried. After the first forced shutdown you were right. Suspend > resulted in reboot running from battery. I was quite disappointed. BUT! > After this first failure it worked again, and is still working, even after > forced shutdowns (power button for few secs). Strange, but at least now it > works. However I still hold, that the problem exits, although it's > appearance seems somehow indeterministic. Yes, summarizing the observations here and my personal experience, there's some "hidden" state in the bios/uefi after a hard reset which isn't expose through acpi tables and causing the reboot. This state changes at some point when storing some states in the bios (enabling wifi, ...) and from there the system is stable. Unless we can figure what kind of changes have been done in other than UX305U bios updates, or have a kernel trace on resume, we're pretty stuck.
(In reply to Francois Cartegnie from comment #94) > Unless we can figure what kind of changes have been done in other than > UX305U bios updates, or have a kernel trace on resume, we're pretty stuck. How does one get such a trace? Are you referring to ftrace?
I just managed to fix my Asus UX301LA! Just like I thought, it was BIOS 211 that was the problem. After trying all the tricks on this page numerous times (oh god so many hours that I wasted) I finally decided to try an unofficial BIOS flash. First I tried reflashing 211, but it did not change anything. Then I tried downgrading to 209, which I was at before this problem started. Bam. Suspend now works, both in Windows and Ubuntu (before it worked in neither of them). I am so happy right now that there aren't words to describe it :D Nonetheless, here are the instructions if anyone else wants to try: 1. Download and install the latest WinFlash from here (obviously you need to be running Windows): http://www.asus.com/support/Download/3/480/0/12/36/ Sidenote: If it says that it can only be installed on ASUS laptops, you need to first download and install the ATK driver for your specific model (can be found on the model's page on asus.com). 2. Start WinFlash.exe with the /nodate parameter (this allows you to flash old/same versions): WinFlash.exe /nodate 3. Click OK on the warning, select the file you want to downgrade to (note, it is the file that is inside the ZIP that you download from Asus' website). 4. Click Flash, click exit to restart, let it flash (took me about a minute both times), let it restart, done. 5. Try suspending. If it works, please report back here with your model name and what version you downgraded from/to for other people to know. Screw ASUS and their uneducated support.
(In reply to Fredrik Blomqvist from comment #96) > I just managed to fix my Asus UX301LA! > > Just like I thought, it was BIOS 211 that was the problem. After trying all > the tricks on this page numerous times (oh god so many hours that I wasted) > I finally decided to try an unofficial BIOS flash. First I tried reflashing > 211, but it did not change anything. Then I tried downgrading to 209, which > I was at before this problem started. Bam. Suspend now works, both in > Windows and Ubuntu (before it worked in neither of them). > > I am so happy right now that there aren't words to describe it :D > > Nonetheless, here are the instructions if anyone else wants to try: > > 1. Download and install the latest WinFlash from here (obviously you need to > be running Windows): > http://www.asus.com/support/Download/3/480/0/12/36/ > > Sidenote: If it says that it can only be installed on ASUS laptops, you need > to first download and install the ATK driver for your specific model (can be > found on the model's page on asus.com). > > 2. Start WinFlash.exe with the /nodate parameter (this allows you to flash > old/same versions): > WinFlash.exe /nodate > > 3. Click OK on the warning, select the file you want to downgrade to (note, > it is the file that is inside the ZIP that you download from Asus' website). > > 4. Click Flash, click exit to restart, let it flash (took me about a minute > both times), let it restart, done. > > 5. Try suspending. If it works, please report back here with your model name > and what version you downgraded from/to for other people to know. > > > Screw ASUS and their uneducated support. Thank you very much for your relentless work solving the reboot problem. I followed the steps you described above and it worked for me as well. My laptop is an Asus UX301LAA. I downgraded the BIOS from version 211 to 209. Since then suspend/resume works perfectly again for both Linux (Ubuntu 16.10) and Windows 10. As the reboot on resume issue emerged simultaneously for Windows and Linux after "upgrading" to BIOS version 211, I also presumed that the new BIOS was the culprit. With your help, the issue is now clarified.
(In reply to Juergen Struckmeier from comment #97) > Thank you very much for your relentless work solving the reboot problem. I > followed the steps you described above and it worked for me as well. My > laptop is an Asus UX301LAA. I downgraded the BIOS from version 211 to 209. > Since then suspend/resume works perfectly again for both Linux (Ubuntu > 16.10) and Windows 10. As the reboot on resume issue emerged simultaneously > for Windows and Linux after "upgrading" to BIOS version 211, I also presumed > that the new BIOS was the culprit. With your help, the issue is now > clarified. Where did you find the older versions? The Asus site only lists the latest available one for me (UX305UA, BIOS version 201).
(In reply to Michele Lacchia from comment #98) > (In reply to Juergen Struckmeier from comment #97) > > Thank you very much for your relentless work solving the reboot problem. I > > followed the steps you described above and it worked for me as well. My > > laptop is an Asus UX301LAA. I downgraded the BIOS from version 211 to 209. > > Since then suspend/resume works perfectly again for both Linux (Ubuntu > > 16.10) and Windows 10. As the reboot on resume issue emerged simultaneously > > for Windows and Linux after "upgrading" to BIOS version 211, I also > presumed > > that the new BIOS was the culprit. With your help, the issue is now > > clarified. > > Where did you find the older versions? The Asus site only lists the latest > available one for me (UX305UA, BIOS version 201). I think you're unfortunately out of luck then. Only thing you can do is call up ASUS, convince them to look at this thread and hope that they'll release an update. Now, based off my own experiences with their support, you have a 1% chance of that actually happening. If it's within warranty they'll probably let you send it in for free, and considering that they're pretty dumb, they'll probably give you a new one in exchange since they don't wanna admit their BIOS is faulty. lol.
I just hit the same problem with Asus UX303UA. Luckily more recent bios was available for me (BIOS 208) which resolved the problem. I was on previous BIOS for almost a year without any problem. I'm updating kernel almost every week and never had the problem until last week. If there is any way how to provide more information which can help to fix this issue, let me know.
I have the same problem with a Dell Latitude 7370 (Skylake Core m7 latest 1.9.3 BIOS). I'm on an Ubuntu 16.10 system running 4.8.0-30-generic the problem exists kernel 4.6.* and the variants of 4.8.* that I've tried. Fast boot doesn't seem to effect the reboots.
> I downgraded the BIOS from version 211 to 209. I downgraded the BIOS of my N752VX from 300 to 202... and the issue fixed...
(In reply to Brant from comment #101) > I have the same problem with a Dell Latitude 7370 (Skylake Core m7 latest > 1.9.3 BIOS). I'm on an Ubuntu 16.10 system running 4.8.0-30-generic the > problem exists kernel 4.6.* and the variants of 4.8.* that I've tried. Fast > boot doesn't seem to effect the reboots. The problem is not related to the Linux kernel and its version. The reboot on resume issue occurred simultaneously for Linux and Windows on my dual boot system after "upgrading" to the latest BIOS. It disappeared again simultaneously for both platforms after downgrading the BIOS to the previous version. In my case the downgrade was from BIOS version 211 to 209 for my Asus UX301LAA.
well, I have not read all the comments because we have quite some bug reporters. According to the last a few comments, it seems that most of the problem can be fixed by a BIOS upgrade/downgrade, right? For any of the reporters in this thread, if 1. the problem still exists after upgrading/downgrading BIOS 2. the problem also exists in windows as well as Linux then this indicates it is a BIOS issue, and I'd prefer to close this bug reporter as we can really do nothing here. For people who has not found a working BIOS version, please raise the problem to Asus instead. BTW, if anyone has the different symptom, please let me know.
Seems my last comment is wrong. For any of the reporters in this thread, if 1. the problem is gone after upgrading/downgrading BIOS or 2. the problem also exists in windows as well as Linux then this indicates it is a BIOS issue. If anyone has the different symptom, which indicates this is not a BIOS problem, please let me know. Or else, I'd prefer to close this bug reporter as we can really do nothing here.For people who has not found a working BIOS version, please raise the problem to Asus instead.
I just wanted to say that I have an Asus UX305UA with the same problem. I'm running Ubuntu 16.10, and I noticed that it works - or not - depending on minor version of the 4.8.0 kernel. For instance: 4.8.0-30.32 : working (= successful wake-up after resume) 4.8.0-32.34 : not working (= restart after resume) After while I upgraded to kernel 4.9 (4.9.0-040900-generic #201612111631) and then it was working again. @Zhang Rui, I contacted the Asus support, but they won't release any upgrade/downgrade of their bios. I don't know if this works on Windows or not, but this is definitely not a bios-only issue. Otherwise the issue would remain the same across kernel versions.
(In reply to Vianney Carel from comment #106) > I just wanted to say that I have an Asus UX305UA with the same problem. I'm > running Ubuntu 16.10, and I noticed that it works - or not - depending on > minor version of the 4.8.0 kernel. Can you guarantee you did start in 'always faulty state' (after hard reset, long power press and no changes using wifi key & such) between each test ?
@François, I don't know what you mean by "always faulty state". Is it some bios configuration? For your information, I switch off my laptop every evening... One day I noticed it was rebooting immediately after resume. Then I realized that I got a kernel update some days before. This was the only thing changed. And upgrading to 4.9.0 fixed the issue.
On the HP an000na, the reboot happens when the sleep occurs, ie, it tries to go to sleep, but reboots instead. Its also no every time, maybe every other, ie, seems like it can do a sleep/resume cycle, but then the next sleep results in a reboot and sleep.
(In reply to Vianney Carel from comment #108) > @François, I don't know what you mean by "always faulty state". Is it some > bios configuration? > For your information, I switch off my laptop every evening... One day I > noticed it was rebooting immediately after resume. Then I realized that I > got a kernel update some days before. This was the only thing changed. And > upgrading to 4.9.0 fixed the issue. "switching off" is not sufficient. We have seen many randomness here in this issue and the only way with UX305 to set it in faulty state is hard reset (long power press when running), then test without touching any hard saved state keys (wifi *). * which in my experience changes something in bios which makes bug unreproducible for a while.
(In reply to Vianney Carel from comment #108) > "switching off" is not sufficient. We have seen many randomness here in this > issue and the only way with UX305 to set it in faulty state is hard reset > (long power press when running), then test without touching any hard saved > state keys (wifi *). I forgot to mention: Also must run on battery. Regarding the claimed 4.9 fix, I've just tried with 4.10 on UX305UA: Still rebooting. Nothing has changed.
UX303UB with the actual BIOS: I downgraded the kernel from 4.8.0-32 generic to 4.4.0-57: System works for me. When I upgrade to 4.8.0-32: It fails. Downgrading of the bios doesn't have any impact.
Asus UX303LA with UEFI version 204. Suspending and then resuming results in a cold boot. I solved the problem by (unfortunately) installing Windows 10, downloading the older version 203 of the UEFI and the WinFlash tool and reflashing it. Before flashing, make sure you install the ATK package. The EasyFlash tool in the UEFI does not allow you to downgrade the UEFI; same with WinFlash, but you can circumvent it by running it with the switch /nodate. Reflashing the previous BIOS version solved the suspend issue. I suspect the kernel or efibootmgr messed up some EFI variables or configuration. Removing the main battery and CMOS battery did not solve the problem, only reflashing and downgrading the UEFI did.
Okay, now we have two kind of symptoms, one can be fixed by downgrading BIOS, and another can be fixed by downgrading/upgrading kernels. For the second one, 4.8.0-32 breaks p.l@posteo.de, but works for Vianney... Well, for people who can confirm the problem can be fixed by kernel change, please run git bisect to find out the commit breaks/fixes the problem. And for commit fixes the problem, please confirm the problem can be reproduced by checkout the previous commit. for commit breaks the problem, please confirm the problem does not exist by checkout the next commit.
(In reply to Zhang Rui from comment #114) > for commit breaks the problem, please confirm the problem does not exist by > checkout the next commit. sorry, I should say for commit breaks the problem, please confirm the problem does not exist by checkout the previous commit.
I've had this problem off-and-on with ux305ua. While it's OK, it's fine until a hard reset. It's been stuck in "reset every time" mode for a couple weeks now. Last night I left the machine unplugged but on, and it ran out of battery. *Then* it worked immediately after. I haven't tried this too many times, but maybe battery level has something to do with it. I'll write back after experimenting more.
The last time I had to hard reboot and had this reboot after suspend issue, I followed this procedure which, for me, has worked every time since last year: I shut down the computer. I boot it and go into the BIOS. I switch the fast boot mode to enable. After saving and quitting, the computer reboots. I go directly in the BIOS again, and switch the fast boot mode to disable. Computer reboots after saving and all is good from then. Another issue I've starting having with my UX305UA is that the cpu fan starts going full speed all of a sudden. Impossible to reset the speed from Linux (through the /sys interface), and it continues going full speed after suspend, and even after a reboot. I have to leave it completely shut down for a few minutes before I can boot again and only then the fan is finally off. I've recently discovered that doing the same trick as above when it happens gives me a week or two before the issue appears again... Anyone else has this fan issue?
This is my third time commenting on this thread (previously comments 81 and 88). The problem re-appeared for me. First, I upgraded my kernel from 4.5.4 to 4.10 and the problem remained. I found my first comment 81 and verified that I was still running the same 300 version of the BIOS which I had found helped previously. Then, I found my second comment about using nvidia-persistenced. When I implemented this (the configuration must have been lost somewhere in an update or upgrade), the problem went away... again. My speculation is that the reason that ASUS machines often show up with this problem is not because they are ASUS, but that they are often higher performance and are using new-ish NVIDIA graphics controllers, but that the real problem is buried somewhere in the mix of BIOS, graphics drivers, and Linux kernel.
Ive just upgraded tumbleweed to kernel 4.10.1. Touch-wood, my laptop has slept/resumed perfectly so far for the last 2 days. It has never worked this well. I dont want to be hasty and say its fixed, but can anyone else test the newer kernel? P.S. my laptop is the HP an000na, (skylake), not the asus.
This problem reappeared for me on my Asus ROG GL552-VW laptop with Skylake and Nvidia 960M running Linux Mint 18 / Ubuntu Xenial. This time running nvidia-persistenced did not help like it did when I commented in <a href="#c118">#118</a> and <a href="#c81">#81</a>. I upgraded my kernel from 4.5.4 to 4.5.7 and then to 4.9.13 and it did not help. Then, I downgraded my BIOS from 300 to 218 and the problem went away.
3-4 days ago I installed openSUSE Leap 42.2. Today I observed this issue, moving from home to work. Relevant information Hardware: System Information Manufacturer: Dell Inc. Product Name: Precision 3510 BIOS Information Vendor: Dell Inc. Version: 1.11.4 Before Leap 42.2, I ran Leap 42.1. The latest kernel update on 42.1 was 4.4.49. Now I run 4.4.49. However, on 42.1 the issue didn't exist. Or maybe I didn't run the latest kernel, but the previous one from the updates, which was 4.4.46. But, before reinstalling the laptop with 42.2, I upgraded the BIOS, as well. So, in my case, there were one of the triggers: - upgrade to latest BIOS for my model but, as I didn't try to suspend and resume it, before reinstalling, I didn't notice - I ran a pre 4.4.49 from openSUSE (which was either 4.4.46 or 4.4.36), where the issue didn't exist in that version. Tell me what other information do you need.
I forgot to mention that, based on the suggestions in here, I disabled FastBoot in BIOS and seems to have fixed the issue.
Well, given we have so many different symptoms of the problem and most of them are related with BIOS upgrade/downgrade or BIOS reset (enabling/disabling FASTBOOT, etc), I don't see a chance how we can fix the kernel to make the problem go away. Bug closed as we can do nothing here. If anyone can consistently reproduce the problem and can confirm the previous BIOS workarounds does not help, please feel free to open a NEW ticket instead.
(In reply to Zhang Rui from comment #123) > If anyone can consistently reproduce the problem and can confirm the > previous BIOS workarounds does not help, please feel free to open a NEW > ticket instead. I already gave the method wich is a hard reset (long power button press) when running. Everything else is due to randomness.
(In reply to Francois Cartegnie from comment #124) > (In reply to Zhang Rui from comment #123) > > If anyone can consistently reproduce the problem and can confirm the > > previous BIOS workarounds does not help, please feel free to open a NEW > > ticket instead. > > I already gave the method which is a hard reset (long power button press) > when running. > Everything else is due to randomness. Rubbish! As I described in Comment 97 regarding my laptop Asus UX301LAA, the problem occurred on my dual boot system for both Windows10 and Ubuntu Linux simultaneously on upgrading the BIOS from version 209 to 211. It again disappeared simultaneously on downgrading the BIOS from version 211 to 209. Since then suspend/resume works perfectly again for both Linux (Ubuntu 16.10) and Windows 10. This is all but randomness!
Le 27/03/2017 à 10:00, bugzilla-daemon@bugzilla.kernel.org a écrit : > https://bugzilla.kernel.org/show_bug.cgi?id=108801 > > > Rubbish! As I described in Comment 97 regarding my laptop Asus UX301LAA, the > problem occurred on my dual boot system for both Windows10 and Ubuntu Linux > simultaneously on upgrading the BIOS from version 209 to 211. It again > disappeared simultaneously on downgrading the BIOS from version 211 to 209. > Since then suspend/resume works perfectly again for both Linux (Ubuntu 16.10) > and Windows 10. This is all but randomness! > And ? If you read past comments I've noticed that the bug appears on fresh bios state, until 'something' is changed. Hence confirms your upgrade behavior (clears bios). And the long power press/reset does the same on UX305UA, it clears some bios state somehow, exposing the bug. Stating on downgrade is pointless as that's the workaround fix. Of course you can't reproduce in that case.
> As I described in Comment 97 regarding my laptop Asus UX301LAA, the > problem occurred on my dual boot system for both Windows10 and Ubuntu Linux > simultaneously on upgrading the BIOS from version 209 to 211. It again > disappeared simultaneously on downgrading the BIOS from version 211 to 209. > Since then suspend/resume works perfectly again for both Linux (Ubuntu > 16.10) and Windows 10. This also suggests this is a BIOS related problem, as it breaks/fixes windows and Linux at the same time. I'm not saying this is a problem, but IMO, we should raise this issue to Asus instead, rather than a kernel bug report.
Do you guys know what would be the most convenient and efficient channel to contact Asus and report this annoying bug? It'd be great to find a way that somehow would them force to address this issue.
I have had this bug off and on for a long time. It seems to show up spontaneously and then go away seemingly in response to everything from BIOS upgrade to BIOS downgrade. Kernel upgrade to Kernel downgrade. Running nvidia-persistenced and running nvidia-prime. My suspend / resume is now working correctly and I don't want to mess with it at the moment, but I was last trying options associated with this: http://unix.stackexchange.com/questions/291546/laptop-reboots-instead-of-resuming-from-systemd-suspend-when-on-battery-power-s This person reports that a BIOS setting for wake when lid opened does not get set properly and that they have to unset and then reset that setting in the BIOS when upgrading the kernel. Perhaps someone else will want to test this and see if it helps them...
(In reply to H Kern from comment #129) > This person reports that a BIOS setting for wake when lid opened does not > get set properly and that they have to unset and then reset that setting in > the BIOS when upgrading the kernel. > > Perhaps someone else will want to test this and see if it helps them... Likely to work: that's still changing bios from the "faulty/clear state" to a working state by writing parameter. On my side, toggling wifi using hardware button (saves state) does the same. We still don't know what happens internally, as it does not alter acpi tables.
(In reply to H Kern from comment #129) > http://unix.stackexchange.com/questions/291546/laptop-reboots-instead-of- > resuming-from-systemd-suspend-when-on-battery-power-s > > This person reports that a BIOS setting for wake when lid opened does not > get set properly and that they have to unset and then reset that setting in > the BIOS when upgrading the kernel. > > Perhaps someone else will want to test this and see if it helps them... I am that very person and, unfortunately, I have to report that the workaround that's mentioned in the StackExchange question does not work anymore. (At least for me.) It was working consistently until an unspecified point in time, between kernel 4.8 and 4.9. I wasn't able to make it work ever since, and it's possible it was just randomness from the start.
(In reply to Vianney Carel from comment #106) > I just wanted to say that I have an Asus UX305UA with the same problem. I'm > running Ubuntu 16.10, and I noticed that it works - or not - depending on > minor version of the 4.8.0 kernel. > > For instance: > 4.8.0-30.32 : working (= successful wake-up after resume) > 4.8.0-32.34 : not working (= restart after resume) > > After while I upgraded to kernel 4.9 (4.9.0-040900-generic #201612111631) > and then it was working again. > > @Zhang Rui, I contacted the Asus support, but they won't release any > upgrade/downgrade of their bios. I don't know if this works on Windows or > not, but this is definitely not a bios-only issue. Otherwise the issue would > remain the same across kernel versions. So I just upgraded to Ubuntu 17.04 with kernel 4.10.0-19 and got the issue again. Mind that hard reboot doesn't change anything *at all*. I'll try to downgrade to 4.9.0-040900 to see if it fixes the issue again. Anyway, you are not going to make the issue disappear by just closing it. Please reopen. This is a terrible situation to loose data only because your laptop went on suspend.
(In reply to Zhang Rui from comment #127) > > As I described in Comment 97 regarding my laptop Asus UX301LAA, the > > problem occurred on my dual boot system for both Windows10 and Ubuntu Linux > > simultaneously on upgrading the BIOS from version 209 to 211. It again > > disappeared simultaneously on downgrading the BIOS from version 211 to 209. > > Since then suspend/resume works perfectly again for both Linux (Ubuntu > > 16.10) and Windows 10. > > This also suggests this is a BIOS related problem, as it breaks/fixes > windows and Linux at the same time. > > I'm not saying this is a problem, but IMO, we should raise this issue to > Asus instead, rather than a kernel bug report. s/I'm not saying this is a problem/I'm not saying this is NOT a problem (In reply to Vianney Carel from comment #132) > (In reply to Vianney Carel from comment #106) > > I just wanted to say that I have an Asus UX305UA with the same problem. I'm > > running Ubuntu 16.10, and I noticed that it works - or not - depending on > > minor version of the 4.8.0 kernel. > > > > For instance: > > 4.8.0-30.32 : working (= successful wake-up after resume) > > 4.8.0-32.34 : not working (= restart after resume) > > > > After while I upgraded to kernel 4.9 (4.9.0-040900-generic #201612111631) > > and then it was working again. > > > > @Zhang Rui, I contacted the Asus support, but they won't release any > > upgrade/downgrade of their bios. I don't know if this works on Windows or > > not, but this is definitely not a bios-only issue. Otherwise the issue > would > > remain the same across kernel versions. > > So I just upgraded to Ubuntu 17.04 with kernel 4.10.0-19 and got the issue > again. Mind that hard reboot doesn't change anything *at all*. > > I'll try to downgrade to 4.9.0-040900 to see if it fixes the issue again. > > Anyway, you are not going to make the issue disappear by just closing it. > Please reopen. This is a terrible situation to loose data only because your > laptop went on suspend. Surely this can be reopened. If anybody thinks this is a kernel regression, please use git bisect to find out which commit introduces the problem. and confirm 1. the bad kernel with the commit reverted works 2. the good kernel with the commit applied breaks
I've encountered this problem on Ubuntu 16.04 LTS on Asus UX305U for the past few days, somewhere along the upgrade of kernel from 4.4.0-5x to my current 4.4.0-72 (can't really tell exactly when), in the course of regular updates of the kernel through apt. This had nothing to do with BIOS update, and since BIOS for UX305U is available only as version 201, couldn't do the upgrade/downgrade test anyways. My laptop is dual-boot with Win10. Also, I did not do hard reset (long press of power button) before the problem appeared (and not willing to test it :). I've tried several of the suggestions here, and eventually got the problem resolved, though not exactly sure what was the exact solution. Here's things I did; sorry for a noob write up, just hope this will help someone: * turned the FastBoot on and off several times (sometimes with booting to OS in-between the switches, something just one after another), currently with FastBoot off (didn't test if it matters), * since I've got the restart-after-sleep problem in Win as well before, I've logged into Win and made sure to shut down properly, in case it left some boot flag or something (like, "safe boot next time" or whatever), * changed boot flags in both /etc/default/grub and /etc/default/grub.ucf-dist to "nouveau.modeset=0 pci=noaer acpi_backlight=native acpi_osi=!" (not even sure which are relevant to me, btw).
This problem has re-appeared for me. I had many tasks running and it hung in the suspended state. After I hard-reset it (holding the on/off button until it turned off), the problem was back. This agrees with comments 125 and 126. Here are the steps I have tried to get the system back to normal (all unsuccessful): - toggled any BIOS setting I could find, including Fastboot off and on about three times - clicked the button to set BIOS settings to defaults - upgraded my kernel from 4.9.17 to 4.9.24 - upgraded Nvidia driver from 3.75 to 3.81 - changed video settings from Nvidia to Nouveau and back again - turned on Intel microcode - ran nvidia-persistenced and nvidia-prime My BIOS is version 300, which is the most recent for my system. One thing that I have noticed is that after the system gets suspended, it behaves like a suspended system, which is to say that the little bulb-light has its intermittent blink showing that the system is suspended. It is when it comes back to life that it goes into reboot state.
Hi I had the same problem with my UX305UE running ubuntu. It started when I forced the restart with the power button. The way I fixed it was the same way I caused the problem. I forced the restart again with the power button and once I did it worked perfectly. I hope this will help you.
Hi I have the same issue with Asus GL552VW (Skylake 6700HQ): 100% chance to get a restart during wake up with AC unplugged. - Ubuntu 16.04 @ Linux 4.13.12 + Nvidia 384 - BIOS 300 (didn't work with 218 too) My solution/workaround for that: + VT-d disabled in BIOS + kernel command line: pcie_aspm=force pcie_aspm.policy=powersave acpi_osi="Windows 2015" intel_iommu=on intremap=no_x2apic_optout + blacklist for bbswitch (it causes PCIe error with the following system hang) + completely suspend nvidia device (unload modules, suppress the power and disable the device) - «black magic» with nvidia in my rc.local: ( if lsmod | grep nvidia 2>&1 > /dev/null; then rmmod nvidia_drm 2>&1 > /dev/null || true rmmod nvidia_uvm 2>&1 > /dev/null || true rmmod nvidia_modeset 2>&1 > /dev/null || true rmmod nvidia 2>&1 > /dev/null || true fi echo "auto" > /sys/bus/pci/devices/0000:01:00.0/power/control echo "0" > /sys/bus/pci/devices/0000:01:00.0/enable ) || true please note that my kernel doesn't have open source nouveau/nvidia driver at all (not sure, but it could affect the result). Pros: + suspend/resume works well (with all combination of suspend/resume with/without AC) + battery lifetime grows almost twice + temperature sensors show lower temperature (about ~3-4 degrees lower than usual) Cons: - nvidia device goes down permanently up to the next reboot (I didn't find a way to bring it back to life without reboot)
It's getting worse. Now randomly won't wake-up (power button only blinks) or just plain reboot. (unsure if that's kernel >= 4.11 or bluetooth being now on) Tracing the wake-up issue it points the acpi device 0d... echo 0 > /sys/power/pm_async echo 0 > /sys/power/pm_trace sync && systemd suspend
(In reply to Francois Cartegnie from comment #138) oops, of course that's echo 0 > /sys/power/pm_async echo 1 > /sys/power/pm_trace sync && systemctl suspend
FYI: I've downgraded to 4.4.x kernel about a year ago (from 4.6.x). Since then I have no problem with suspend, I'm currently using the version 4.4.126.
I have a UX51VZ, an older ivy bridge zenbook, it has the same issue. I tried this procedure, but when suspending the laptop it would just wake up immediately.
given that this is really a long thread, and it is a tough issue with so many reporters, against different platforms/kernel_version/BIOS_version. Let's collect the test result against latest upstream kernel, please do the following test 1. set CONFIG_PM_TRACE_RTC and CONFIG_PM_DEBUG 2. echo 1 > /sys/power/pm_trace 3. set /sys/power/pm_test to different modes 4. echo mem > /sys/power/states if system does not reboot, please tell me which pm_test mode you're using if system reboots, please tell me which pm_test mode you're using and attach the dmesg output after reboot.
(In reply to Zhang Rui from comment #142) > 1. set CONFIG_PM_TRACE_RTC and CONFIG_PM_DEBUG > 2. echo 1 > /sys/power/pm_trace > 3. set /sys/power/pm_test to different modes > 4. echo mem > /sys/power/states > if system does not reboot, please tell me which pm_test mode you're using > if system reboots, please tell me which pm_test mode you're using and attach > the dmesg output after reboot. I can't fault it in any mode, except when mode is set to "none" Reboots even after running all tests when set back to "none". Addings dumps.
Created attachment 279103 [details] reboot on pm tests to "none"
Created attachment 279105 [details] reboot on pm tests to "none" after testing all other modes
Experiencing sometimes now steady (instead of blinking) power led with 4.20.4 trying to resume. Unsure if that means any progress
I'm experiencing this issue on an Asus Zenbook UX305U. I first thought it might be related to https://bugzilla.kernel.org/show_bug.cgi?id=203877, but this describes it perfectly. Currently running 5.5.0 (debian), I've had it for a while and I've been unable to get to the bottom of this. Seeing the request for info, I'll try to build the latest upstream on Debian (it's been a while) and see where I can go from there to supply the info.
Same problem for me but I found a solution : UX301LA bios version 300 Dual boot -> Manjaro 20 kernel 5.6 (no special acpi options like acpi_sleep=nonv or other stuff) & Windows 10 SDA : Manjaro + EFI Boot Partition SDB : Windows Bios : Default settings (SATA -> RAID, Fastboot On, Wake on lid Open On, Power Off Energy Saving On) & Secure boot disabled ISSUE: The PC restart instead of resuming SOLUTION : 1) Choose the sata configuration that let your Windows start without BSOD (like for example INACCESSIBLE_BOOT_DEVICE) 2) If u have one when u changed the sata configuration THEN let Windows repair the boot problem in the advanced option 3) Download the latest BIOS + Winflash 4) Start in cmd with Winflash /nodate 5) Choose ur bios file in winflash and flash it 6) PC will shutdown/flash/restart 7) Enter in your bios settings JUST after restart, CHECK if ur previous SATA configuration didn't changed like AHCI -> RAID, if yes put it back like it was saved at the step 1) 8) Disable the Secure boot + Save then boot into GRUB 9) Now sleep & resume work like they should in Linux or Windows TO REPRODUCE THE BUG : 1) Do the SOLUTION steps 2) Change the Sata configuration in BIOS & save it 3) Boot into Windows 4) Get a BLUE SCREEN OF DEATH (INACCESSIBLE_BOOT_DEVICE) 5) The PC restart in bios without any SATA drive detected 6) Shutdown & Start again 7) Now you can do what u want in the BIOS / Windows / Linux but u will face the rebooting issue SOLUTION 2 (MAYBE) : Same as SOLUTION 1 but instead of reflashing the BIOS, remove the battery and do a CMOS by shorthing the 2 contact points with a screwdriver
This problem just reappeared for me on my Asus GL552VW, now some years later and currently running Linux kernel 4.15.0-112 I believe the bug is triggered by a long-press On/Off hard reset. This time, the bug resolved when I went into Windows and used the Asus update tool to update my BIOS from 300 to 304
(In reply to H Kern from comment #149) > This time, the bug resolved when I went into Windows and used the Asus > update tool to update my BIOS from 300 to 304 The BIOS (force) update is a workaround, it is solve the issue temporarily.
This issue recently appeared on my ASUSUX305C for the first time since purchasing it several years ago. It happened immediately after upgrading from MX-Lunux 18.3 to 19.2. Reverting to old kernels that had worked fine on this laptop before did not solve the problem. The thing that worked for me was holding the power button down to do a hard shutdown. Now things are working as normal. I don't remember if I did the hard shutdown while on batter or plugged in.
Additional info... :) At the moment I'm using Windows 10 (with WSL2, but it is irrelevant) and sometimes there is exactly the same issue occurs with Windows 10 under the same conditions, but two shutdown-reboot cycle solves it (unlike Linux, I have to force reflash the BIOS to solve). But, I have a short time text mode BIOS error message during the failed boot: "(A7) Me FW Downgrade - Request MeSpiLock Failed" I don't know it is relevant or irrelevant but maybe help to clear the situation.
Using: - Using ASUS UX430UAR with updated BIOS UX430UAR.308 - Fedora 33 with Kernel version 5.10.10-200.fc33.x86_64 When the laptop goes to suspend mode, it reboots one time out of two. I tried to append acpi_sleep=nonvs on the boot command line as explained in the "sleep.c" file in sources, that has no effect it seems. The weird part is that it didn't have this problem when I bought the computer 3 years ago. The problem began maybe 4 months ago... And it's... How to say it... annoying...
This problem is still present on 5.17.7 - fedora 36 kernel 5.17.7-300.fc36.x86_64
(In reply to Jan De Luyck from comment #154) > This problem is still present on 5.17.7 - fedora 36 kernel > 5.17.7-300.fc36.x86_64 Note that surprisingly UX305 has received a BIOS update after *4 years*, while support always claimed the issue was on our side. After applying update, still no reboot since 3 weeks...
(In reply to Francois Cartegnie from comment #155) > (In reply to Jan De Luyck from comment #154) > > This problem is still present on 5.17.7 - fedora 36 kernel > > 5.17.7-300.fc36.x86_64 > > Note that surprisingly UX305 has received a BIOS update after *4 years*, > while support always claimed the issue was on our side. > > > After applying update, still no reboot since 3 weeks... Which update is this? I see nothing since 2019 (bios version 302)
(In reply to Jan De Luyck from comment #156) > (In reply to Francois Cartegnie from comment #155) > > (In reply to Jan De Luyck from comment #154) > > > This problem is still present on 5.17.7 - fedora 36 kernel > > > 5.17.7-300.fc36.x86_64 > > > > Note that surprisingly UX305 has received a BIOS update after *4 years*, > > while support always claimed the issue was on our side. > > > > > > After applying update, still no reboot since 3 weeks... > > Which update is this? I see nothing since 2019 (bios version 302) Yes, 302 for UX305UA
That will be the workaround specified above: RE flashing the bios 'helps'. I've been running 302 for years. Doesn't fix the issue.
Problem is back for me after a forced shutdown on 6.8.11. All the previous tricks did not succeed to reset the state, it was rebooting unconditionally when waking up without AC plugged. The only thing that fixed it is setting VT to off in BIOS, which resulted in a longer than usual (like 5s) Asus bootscreen. Seems toggling some options have short reboot and have no effect on the issue, while others will trigger a more complete reset, fixing the issue. (likely same as reflashing).