| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 10 Feb 2014 14:20:35 +0200
From: Mika Westerberg <mika.westerberg@...ux.intel.com>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Peter Wu <lekensteyn@...il.com>,
Bastien Traverse <bastien.traverse@...il.com>,
linux-kernel@...r.kernel.org, francis.moro@...il.com,
linux-pm@...r.kernel.org
Subject: Re: 3.12: ethernet controller missing after resuming from suspend to
RAM
On Mon, Feb 10, 2014 at 01:10:19PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 10, 2014 02:15:22 AM Peter Wu wrote:
> > On Monday 10 February 2014 01:52:14 Rafael J. Wysocki wrote:
> > > > Could the following commit have something to do with it?
> > > >
> > > >
> > > >
> > > > commit 4ebe34503baa0644c9352bcd76d4cf573bffe206
> > > > Author: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > > > Date: Tue Jul 16 22:10:35 2013 +0200
> > > >
> > > >
> > > > ACPI / hotplug / PCI: Check for new devices on enabled slots
> > >
> > > This one, or another one in that series. I rather suspect
> > >
> > > ab1225901da2 Revert "ACPI / hotplug / PCI: Avoid doing too much for spurious
> > > notifies"
> > >
> > > from Mika, but it really doesn't matter.
> > >
> > > Can you please check the patch below (it is on top of 3.14-rc1, but I think
> > > it'll still apply to 3.13) and report back?
> >
> > I applied the following patch:
> >
> > --- drivers/pci/hotplug/acpiphp_glue.c.orig 2014-02-10 01:46:59.678124018 +0100
> > +++ drivers/pci/hotplug/acpiphp_glue.c 2014-02-10 01:48:59.634124004 +0100
> > @@ -552,10 +552,10 @@
> > struct pci_dev *dev;
> > struct pci_bus *bus = slot->bus;
> > struct acpiphp_func *func;
> > - int max, pass;
> > + int nr_found, max, pass, bridges_scanned = 0;
> > LIST_HEAD(add_list);
> >
> > - acpiphp_rescan_slot(slot);
> > + nr_found = acpiphp_rescan_slot(slot);
> > max = acpiphp_max_busnr(bus);
> > for (pass = 0; pass < 2; pass++) {
> > list_for_each_entry(dev, &bus->devices, bus_list) {
> > @@ -571,9 +571,16 @@
> > __pci_bus_size_bridges(dev->subordinate,
> > &add_list);
> > }
> > + bridges_scanned++;
> > }
> > }
> > }
> > + /* Nothing more to do here if there are no new devices on this bus. */
> > + if (!nr_found && !bridges_scanned && (slot->flags & SLOT_ENABLED)) {
> > + pr_debug("No more new devices on this bus.\n");
> > + return;
> > + }
> > +
> > __pci_bus_assign_resources(bus, &add_list, NULL);
> >
> > acpiphp_sanitize_bus(bus);
> >
> > Unfortunately, the adapter still vanishes. dmesg is below this message.
> >
> > Peter
> >
> > [ 44.558995] CPU3 is up
> > [ 44.561438] ACPI: Waking up from system sleep state S3
> > [ 45.254084] ehci-pci 0000:00:1a.0: System wakeup disabled by ACPI
> > [ 45.280727] ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI
> > [ 45.307403] xhci_hcd 0000:02:00.0: System wakeup disabled by ACPI
> > [ 45.361012] PM: noirq resume of devices complete after 133.354 msecs
> > [ 45.361292] PM: early resume of devices complete after 0.233 msecs
> > [ 45.361680] iwlwifi 0000:05:00.0: RF_KILL bit toggled to enable radio.
> > [ 45.361731] pcieport 0000:00:1c.1: System wakeup disabled by ACPI
> > [ 45.470912] snd_hda_intel 0000:00:1b.0: irq 48 for MSI/MSI-X
> > [ 45.700502] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> > [ 45.700533] ata5: SATA link down (SStatus 0 SControl 300)
> > [ 45.701385] ata1.00: configured for UDMA/133
> > [ 45.701503] sd 0:0:0:0: [sda] Starting disk
> > [ 45.707139] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> > [ 45.872011] ata2.00: configured for UDMA/100
> > [ 46.791141] PM: resume of devices complete after 1430.658 msecs
> > [ 46.791560] PM: Finishing wakeup.
> > [ 46.791565] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03
> > [ 46.791568] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP03
> > [ 46.791642] acpiphp_glue: No more new devices on this bus.
> > [ 46.791571] Restarting tasks ... done.
> > [ 46.793204] video LNXVIDEO:00: Restoring backlight state
> > [ 46.793211] video LNXVIDEO:01: Restoring backlight state
> > [ 47.246425] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported
> > [ 47.251540] jme 0000:04:00.5: irq 50 for MSI/MSI-X
> > [ 47.276949] jme 0000:04:00.5 eth0: Link is down
>
> I'm wondering why these two messages are printed here.
>
> > [ 47.276974] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> > [ 47.278423] iwlwifi 0000:05:00.0: L1 Enabled; Disabling L0S
> > [ 47.285758] iwlwifi 0000:05:00.0: Radio type=0x1-0x3-0x1
> > [ 47.393492] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP01
> > [ 47.393495] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP01
> > [ 47.393517] acpiphp_glue: No more new devices on this bus.
> > [ 47.393525] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP02
> > [ 47.393527] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP02
>
> Anyway, the message you've added to the patch is not printed for this bridge,
> so the condition is not satified for its bus. We need to find out why it isn't
> satisfied and what exactly happens to the devices that appear to go away.
One thing, I noticed when checking the DSDT:
Device (J380)
{
Method (_STA, 0, NotSerialized) // _STA: Status
{
If (LNotEqual (DVID, 0xFFFFFFFF))
{
Return (0x0A)
}
Else
{
Return (Zero)
}
}
_STA() returns 0x0A instead of 0x0F. Could there be something missing in
the ACPI hotplug code that overlooks this and removes the device on resume?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists