Bug 192651 - reboot command fails and shuts down instead - Dell XPS 13 9365
Summary: reboot command fails and shuts down instead - Dell XPS 13 9365
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Off (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Chen Yu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-16 06:30 UTC by davidnmfarrell
Modified: 2017-02-07 14:05 UTC (History)
3 users (show)

See Also:
Kernel Version: 4.10.RC4, 4.10 RC3, 4.9
Tree: Mainline
Regression: No


Attachments
journalctl --boot=-1 (after failed reboot) (264.02 KB, patch)
2017-01-16 06:30 UTC, davidnmfarrell
Details | Diff
reboot syscall test (614 bytes, text/plain)
2017-01-16 11:42 UTC, Chen Yu
Details
dmesg after running reboot_test (169.67 KB, text/plain)
2017-01-16 22:10 UTC, davidnmfarrell
Details
journalctl entries after reboot command (41.41 KB, text/plain)
2017-01-16 22:11 UTC, davidnmfarrell
Details
dmesg after pm_trace (65.91 KB, application/octet-stream)
2017-01-17 22:00 UTC, davidnmfarrell
Details

Description davidnmfarrell 2017-01-16 06:30:54 UTC
Created attachment 251901 [details]
journalctl --boot=-1 (after failed reboot)

Issuing a reboot command, the system begins to shutdown but encounters an error, and instead of rebooting, turns the machine off.

This is under Fedora 25 4.9 and Fedora Rawhide 4.10 RC3 kernels.

Secure boot UEFI is enabled, SATA mode is ACPI, processor is Kaby Lake i7 7Y75.

Attached is the output from:

    journalctl --boot=-1
Comment 1 davidnmfarrell 2017-01-16 07:35:17 UTC
After issuing the reboot command, the output shows many of these messages:

Device mapper: ioctl on fedora root failed: Device or resource busy
...
Device mapper: ioctl on luks <id> failed: Device or resource busy
...

And this message once:
Failed to read reboot parameter file

Which seems to come from:
https://github.com/systemd/systemd/blob/master/src/core/shutdown.c#L406

It seems similar to the issue described here:
https://bugzilla.redhat.com/show_bug.cgi?id=1346225

Except that my system does not hang, it shuts down.

Force rebooting (reboot -f) exhibits the same behavior - the system displays the error "Failed to read reboot parameter file" and shuts down but does not restart.
Comment 2 Chen Yu 2017-01-16 11:41:08 UTC
Please try with upstream kernel,
1. gcc reboot_test.c -o reboot_test
2. boot kernel with 'init=/bin/bash' in the command line to get a minimal envirment, and then upload the reboot_test to the machine, and try
  ./reboot_test 3   or  ./reboot_test 4 to see if reboot works.
3. if you have problem to boot up with init=/bin/bash, just boot into a normal system and try ./reboot_test 3 and ./reboot_test 4 respectively.
Comment 3 Chen Yu 2017-01-16 11:42:26 UTC
Created attachment 251951 [details]
reboot syscall test

compile me
Comment 4 davidnmfarrell 2017-01-16 16:29:41 UTC
Ok doke under 4.10-rc3:

"reboot_test 3" crashes the system
"reboot_test 4" doesn't seem to do anything, the system remains responsive, I can type more shell commands, etc.
Comment 5 Chen Yu 2017-01-16 17:07:49 UTC
(In reply to davidnmfarrell from comment #4)
> Ok doke under 4.10-rc3:
> 
> "reboot_test 3" crashes the system
> "reboot_test 4" doesn't seem to do anything, the system remains responsive,
> I can type more shell commands, etc.

The same in init=/bin/bash mode? What does crash mean? is there panic trace on the monitor or  journal?
Comment 6 davidnmfarrell 2017-01-16 22:10:56 UTC
Created attachment 252021 [details]
dmesg after running reboot_test
Comment 7 davidnmfarrell 2017-01-16 22:11:37 UTC
Created attachment 252031 [details]
journalctl entries after reboot command
Comment 8 davidnmfarrell 2017-01-16 22:16:42 UTC
On upstream 4.10-rc4:

- "reboot_test 3" and "reboot_test 4" have no effect, under init=/bin/bash or run level 3 or 5. I'm sure the program runs because passing no parameters prints the message "Please provide a reboot mode"
- dmesg output is exactly the same before and after running reboot_test (attached)
- "reboot" seems to work - attached is the journalctl output when the reboot sequence begins. However the system never restarts, it seems to just hang, even though the screen turns off and the log entries appear to indicate that the reboot was successful.
Comment 9 davidnmfarrell 2017-01-16 22:40:04 UTC
Ok the reason reboot_test wasn't having an effect was the reboot() call was failing "operation not permitted".

- sudo reboot_test 3 initiates a reboot. The system appears to succeed, but the screen goes blank and appears to hang. Eventually the machine turns off (same as with "reboot"). But I'm unable to view the syslog with journalctl for this boot ("journalctl --boot=-1"): ("Journal file /var/log/journal/49ff6f156aa54317ac336f9a03169aea/user-1000@00053ba767883e15-ab5411483855c7e1.journal~ uses an unsupported feature, ignoring file.").
- sudo reboot_test 4 nothing happens - the reboot() function call returns the error "bad address"
Comment 10 Len Brown 2017-01-17 02:51:57 UTC
For what it's worth, I have a Dell XPS 13 9360 (Kaby Lake i7-7500U)
BIOS version is 1.0.7 9/13/2016

This system came pre-installed with Ubuntu 16.04.1.
That distro is still installed, though I'm currently running a 9.3.0 kernel.

reboot from the GUI has always worked for me.

sometimes when I "sudo reboot" from the shell, after the GUI goes away there is text on the screen  complaining that a "stop job is running".... it it will wait there for up to 1m30s, but upon that passing, reboot succeeds.  I've never seen the reboot turn into a power-off.

FWIW, I set BIOS to defaults (except SATA is set to AHCI, rather than RAID), and so secure boot is enabled.  However, Ubuntu prints "Booting in insecure mode", so apparently it is secure up through the booter, but then allows booting any kernel...
Comment 11 davidnmfarrell 2017-01-17 22:00:42 UTC
Created attachment 252171 [details]
dmesg after pm_trace
Comment 12 Chen Yu 2017-01-23 07:30:08 UTC
How about typing "reboot" in your grub shell? Is it the same situation?(power off rather than reboot)
Comment 13 davidnmfarrell 2017-01-24 01:26:13 UTC
reboot in the Grub shell (init=/bin/bash) returns these errors:

"Failed to connect to bus: no such file or directory
Failed to talk to init daemon"


I think that's because systemd hasn't started. If I boot with systemd.unit=emergency, I get the same behavior as described earlier.
Comment 14 Chen Yu 2017-01-24 01:29:45 UTC
(In reply to davidnmfarrell from comment #13)
> reboot in the Grub shell (init=/bin/bash) returns these errors:
> 
> "Failed to connect to bus: no such file or directory
> Failed to talk to init daemon"
> 
> 
> I think that's because systemd hasn't started. If I boot with
> systemd.unit=emergency, I get the same behavior as described earlier.

I mean, type reboot in the grub, not after booting up to linux. You can enter grub's shell by typing 'Esc' once your saw the grub selecting menu.
Comment 15 Chen Yu 2017-01-24 01:31:11 UTC
(In reply to Chen Yu from comment #14)
> (In reply to davidnmfarrell from comment #13)
> > reboot in the Grub shell (init=/bin/bash) returns these errors:
> > 
> > "Failed to connect to bus: no such file or directory
> > Failed to talk to init daemon"
> > 
> > 
> > I think that's because systemd hasn't started. If I boot with
> > systemd.unit=emergency, I get the same behavior as described earlier.
> 
> I mean, type reboot in the grub, not after booting up to linux. You can
> enter grub's shell by typing 'Esc' once your saw the grub selecting menu.

And this is to figure out whether this is a firmware issue.
Comment 16 davidnmfarrell 2017-01-24 02:23:42 UTC
(In reply to Chen Yu from comment #14)

> I mean, type reboot in the grub, not after booting up to linux. You can
> enter grub's shell by typing 'Esc' once your saw the grub selecting menu.

Ah, gotcha :-)

Yes reboot from grub shell works fine: the machine powers off and then restarts.
Comment 17 Chen Yu 2017-02-05 15:17:10 UTC
(In reply to davidnmfarrell from comment #16)
> (In reply to Chen Yu from comment #14)
> 
> > I mean, type reboot in the grub, not after booting up to linux. You can
> > enter grub's shell by typing 'Esc' once your saw the grub selecting menu.
> 
> Ah, gotcha :-)
> 
> Yes reboot from grub shell works fine: the machine powers off and then
> restarts.
OK. Which grub version are you using? Besides, please appending the following different params respectively in the grub menu, and check if any of the following params make 'reboot' working in linux:

1) reboot=e
2) reboot=w
3) reboot=c
4) reboot=h
5) reboot=s
6) reboot=g
7) reboot=b
8) reboot=a
9) reboot=k
10) reboot=t
11) reboot=p
12) reboot=f
Comment 18 davidnmfarrell 2017-02-07 04:11:06 UTC
grub2-install -V
grub2-install (GRUB) 2.02~beta3
Comment 19 davidnmfarrell 2017-02-07 04:33:02 UTC
I installed the latest BIOS provided by Dell:
https://downloads.dell.com/FOLDER04127155M/1/XPS_9365_1_0_5.exe

On this drivers page:
http://www.dell.com/support/home/us/en/19/product-support/product/xps-13-9365-2-in-1-laptop/drivers?newtab=true&c=us&l=en&s=dhs

And this fixed the issue. I tested reboot in 4.9.3 and 4.10.0-rc6 and it works fine under both kernels.

If you need any further information, just let me know, otherwise I think this ticket can be closed.

Thank you for your help!
Comment 20 Chen Yu 2017-02-07 05:18:22 UTC
OK, thx.
Comment 21 Zhang Rui 2017-02-07 07:05:55 UTC
BTW, I've noticed you have another two open tickets, can you please check if the problem still exists after upgrading BIOS?
Comment 22 davidnmfarrell 2017-02-07 14:05:42 UTC
(In reply to Zhang Rui from comment #21)
> BTW, I've noticed you have another two open tickets, can you please check if
> the problem still exists after upgrading BIOS?

They still exist :-(

Note You need to log in before you can comment on or make changes to this bug.