[Dell Optiplex 9020] Shut down causes restart if USB3 enabled

[Owen Dunn]

Description: Ubuntu 14.04.2 LTS
Release: 14.04

linux-image-3.13.0-49-generic version 3.13.0-49.83

I have a large number of Dell Optiplex 9020 machines, and when they are asked to shutdown with e.g. shutdown -h now, they shut down successfully and then approximately four seconds later they start up again.

This problem only happens if the system's USB3 ports are enabled.

If I reinstate the code removed from xhci-pci.c in the diff.gz:

        if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
- (pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI ||
- pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI)) {
- /* Workaround for occasional spurious wakeups from S5 (or
- * any other sleep) on Haswell machines with LPT and LPT-LP
- * with the new Intel BIOS
- */
- /* Limit the quirk to only known vendors, as this triggers
- * yet another BIOS bug on some other machines
- * https://bugzilla.kernel.org/show_bug.cgi?id=66171
- */
- if (pdev->subsystem_vendor == PCI_VENDOR_ID_HP)
- xhci->quirks |= XHCI_SPURIOUS_WAKEUP;
+ pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI) {
+ xhci->quirks |= XHCI_SPURIOUS_REBOOT;
        }

and add msleep(1000) to xhci.c as suggested at http://www.gossamer-threads.com/lists/linux/kernel/1713011

...shutdown shuts the machine down as expected.

I attach the output of lspci -mnn.

(S)
---
ApportVersion: 2.14.1-0ubuntu3.10
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: lightdm 1990 F.... pulseaudio
 /dev/snd/controlC0: lightdm 1990 F.... pulseaudio
DistroRelease: Ubuntu 14.04
HibernationDevice: RESUME=/dev/mapper/CayenneSys00-swap
IwConfig:
 eth0 no wireless extensions.

 lo no wireless extensions.
MachineType: Dell Inc. OptiPlex 9020
NonfreeKernelModules: nvidia
Package: linux (not installed)
ProcFB:

ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-49-generic root=/dev/mapper/CayenneSys00-root ro biosdevname=0 quiet
ProcVersionSignature: Ubuntu 3.13.0-49.83-generic 3.13.11-ckt17
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-49-generic N/A
 linux-backports-modules-3.13.0-49-generic N/A
 linux-firmware 1.127.11
RfKill:

Tags: trusty
Uname: Linux 3.13.0-49-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: wheel
_MarkForUpload: True
dmi.bios.date: 11/20/2014
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A09
dmi.board.name: 06X1TJ
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 6
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA09:bd11/20/2014:svnDellInc.:pnOptiPlex9020:pvr01:rvnDellInc.:rn06X1TJ:rvrA00:cvnDellInc.:ct6:cvr:
dmi.product.name: OptiPlex 9020
dmi.product.version: 01
dmi.sys.vendor: Dell Inc.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1457852

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Owen Dunn (osd1000)]

apport information

[Owen Dunn (osd1000)]

apport information

[Owen Dunn (osd1000)]

apport information

[Owen Dunn (osd1000)]

apport information

[Owen Dunn (osd1000)]

apport information

[Owen Dunn (osd1000)]

apport information

[Owen Dunn (osd1000)]

apport information

[Owen Dunn (osd1000)]

apport information

[Owen Dunn (osd1000)]

apport information

[Owen Dunn (osd1000)]

apport information

[Owen Dunn (osd1000)]

apport information

[Owen Dunn (osd1000)]

apport information

[Owen Dunn (osd1000)]

apport information

[Owen Dunn (osd1000)]

On Sat, 23 May 2015, Christopher M. Penalver wrote:

> Owen Dunn, thank you for reporting this and helping make Ubuntu better.
> As per http://www.dell.com/support/home/us/en/19/product-
> support/product/optiplex-9020-desktop/drivers an update to your
> computer's buggy and outdated BIOS is available (A10). If you update to
> this following https://help.ubuntu.com/community/BIOSUpdate does it
> change anything?

No, this doesn't change anything. The system still starts up again a
second or two after it shuts down.

> If it doesn't, could you please both specify what happened, and provide the output of the following terminal command:
> sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date

root@cayenne:/home/osd1000# dmidecode -s bios-version
A10
root@cayenne:/home/osd1000# dmidecode -s bios-release-date
01/08/2015

Owen

[penalvch (penalvch)]

Owen Dunn, could you please test the latest upstream kernel available from the very top line at the top of the page (the release names are irrelevant for testing, and please do not test the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue.

If the test did not allow you to test to the issue (ex. you couldn't boot into the OS) please make a comment in your report about this, and continue to test the next most recent kernel version until you can test to the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags by clicking on the yellow circle with a black pencil icon, next to the word Tags, located at the bottom of the report description:
kernel-fixed-upstream
kernel-fixed-upstream-X.Y-rcZ

Where XY and Z are numbers corresponding to the kernel version.

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-X.Y-rcZ

Please note, an error to install the kernel does not fit the criteria of kernel-bug-exists-upstream.

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results.

Thank you for your understanding.

[Owen Dunn (osd1000)]

On Tue, 26 May 2015, Christopher M. Penalver wrote:

> Once you've tested the upstream kernel, please comment on which kernel
> version specifically you tested.

I tested with 4.1.0-040100rc5, and this has not resolved the problem.
When the system is shut down, the system powers back shortly afterwards.

Owen

[Carl Hetherington (cth-carlh)]

I see the same thing with Optiplex 9020 and BIOS A10. For reference, git commit 01414f897d20874f6f5d7ef2f756f5bf2df526fc introduced the problem.

commit 01414f897d20874f6f5d7ef2f756f5bf2df526fc
Author: Denis Turischev <email address hidden>
Date: Tue May 20 14:00:42 2014 +0300

    xhci: Switch only Intel Lynx Point-LP ports to EHCI on shutdown.

    BugLink: http://bugs.launchpad.net/bugs/1402853

    commit 0a939993bff117d3657108ca13b011fc0378aedb upstream.

    Patch "xhci: Switch Intel Lynx Point ports to EHCI on shutdown."
    commit c09ec25d3684cad74d851c0f028a495999591279 is not fully correct

    It switches both Lynx Point and Lynx Point-LP ports to EHCI on shutdown.
    On some Lynx Point machines it causes spurious interrupt,
    which wake the system: bugzilla.kernel.org/show_bug.cgi?id=76291

    On Lynx Point-LP on the contrary switching ports to EHCI seems to be
    necessary to fix these spurious interrupts.

    Signed-off-by: Denis Turischev <email address hidden>
    Reported-by: Wulf Richartz <email address hidden>
    Cc: Mathias Nyman <email address hidden>
    Signed-off-by: Greg Kroah-Hartman <email address hidden>
    Signed-off-by: Kamal Mostafa <email address hidden>

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 3fc8d9e..21223f8 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -138,7 +138,9 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
                 */
                if (pdev->subsystem_vendor == PCI_VENDOR_ID_HP)
                        xhci->quirks |= XHCI_SPURIOUS_WAKEUP;
-
+ }
+ if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
+ pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI) {
                xhci->quirks |= XHCI_SPURIOUS_REBOOT;
        }
        if (pdev->vendor == PCI_VENDOR_ID_ETRON &&

[penalvch (penalvch)]

Owen Dunn, the issue you are reporting is an upstream one. Could you please report this problem to the appropriate mailing list (linux-usb) by following the instructions verbatim at https://wiki.ubuntu.com/Bugs/Upstream/kernel ?

Please provide a direct URL to your e-mail to the mailing list once you have made it so that it may be tracked via http://vger.kernel.org/vger-lists.html . It can take a day for the new e-mail to show up in the respective archive.

Thank you for your understanding.

[Owen Dunn (osd1000)]

Email to linux-usb mailing list:

http://permalink.gmane.org/gmane.linux.usb.general/126171

[Alex Hung (alexhung)]

I have a dell laptop with similar behaviours. However, I can fix it by modifying the PCI register offset 0xA4 on LPC (ex. 00:1f.0 ISA bridge).

You can use lfdk (see http://alexhungdmz.blogspot.tw/2015/06/uitlity-reading-and-writing-pci-io-and.html) to modify the PCI register. Please change BIT15 of 0xA4 (more BIT7 of 0xA5). For example, it was 0x28 and I modified it to 0xB8 (please refer to attached screenshot).

This bit (called PME_B0_S5_DIS) is reset by RTCRST# (RTC reset) and normally that does not happen. It will stay as long as RTC has power or is written by again.

I can also check your PCI registers if you can upload output of "sudo lspci -xxx"

[Alex Hung (alexhung)]

 Let's check with Dell and see whether we can get BIOS update...