LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Kevin Winchester <kjwinchester@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>, LKML <linux-kernel@vger.kernel.org>,
	len.brown@intel.com, linux-pm@lists.linux-foundation.org
Subject: Re: broken suspend to ram with velocity driver
Date: Wed, 27 Feb 2008 14:06:12 +0100	[thread overview]
Message-ID: <200802271406.13312.rjw@sisk.pl> (raw)
In-Reply-To: <47C4AEB7.1030404@gmail.com>

On Wednesday, 27 of February 2008, Kevin Winchester wrote:
> Pavel Machek wrote:
> > Hi!
> > 
> >> I recompiled the kernel without the velocity driver, and got behaviour more comparable to the other failures I've experienced in the past:
> >>
> >> Feb 25 20:18:46 alekhine kernel: [   73.564725] PM: Syncing filesystems ... done.
> >> Feb 25 20:19:14 alekhine kernel: [   73.580807] Freezing user space processes ... (elapsed 0.01 seconds) done.
> >> Feb 25 20:19:14 alekhine kernel: [   73.595524] Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
> >> Feb 25 20:19:14 alekhine kernel: [   73.595839] ACPI: Preparing to enter system sleep state S3
> >> Feb 25 20:19:14 alekhine kernel: [   73.697308] Suspending console(s)
> >> Feb 25 20:19:14 alekhine kernel: [   73.700386] sd 3:0:0:0: [sda] Synchronizing SCSI cache
> >> Feb 25 20:19:14 alekhine kernel: [   73.783185] sd 3:0:0:0: [sda] Stopping disk
> >> Feb 25 20:19:14 alekhine kernel: [   73.784302] ACPI: PCI interrupt for device 0000:00:11.5 disabled
> >> Feb 25 20:19:14 alekhine kernel: [   73.794585] ACPI: PCI interrupt for device 0000:00:10.4 disabled
> >> Feb 25 20:19:14 alekhine kernel: [   73.805370] ACPI: PCI interrupt for device 0000:00:10.3 disabled
> >> Feb 25 20:19:14 alekhine kernel: [   73.816170] ACPI: PCI interrupt for device 0000:00:10.2 disabled
> >> Feb 25 20:19:14 alekhine kernel: [   73.826999] ACPI: PCI interrupt for device 0000:00:10.1 disabled
> >> Feb 25 20:19:14 alekhine kernel: [   73.837833] ACPI: PCI interrupt for device 0000:00:10.0 disabled
> >> Feb 25 20:19:14 alekhine kernel: [   73.848668] ACPI: PCI interrupt for device 0000:00:0f.1 disabled
> >> Feb 25 20:19:14 alekhine kernel: [   73.859346] ACPI: PCI interrupt for device 0000:00:0f.0 disabled
> >> Feb 25 20:19:14 alekhine kernel: [   73.882878] Intel machine check architecture supported.
> >> Feb 25 20:19:14 alekhine kernel: [   73.882878] Intel machine check reporting enabled on CPU#0.
> >> Feb 25 20:19:14 alekhine kernel: [   73.884890] ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [ALKA] -> GSI 20 (level, low) -> IRQ 20
> >> Feb 25 20:19:14 alekhine kernel: [   73.884892] ACPI: PCI Interrupt 0000:00:0f.1[A] -> Link [ALKA] -> GSI 20 (level, low) -> IRQ 20
> >> Feb 25 20:19:14 alekhine kernel: [   73.890893] ACPI: PCI Interrupt 0000:00:10.0[A] -> GSI 21 (level, low) -> IRQ 21
> >> Feb 25 20:19:14 alekhine kernel: [   73.890893] usb usb2: root hub lost power or was reset
> >> Feb 25 20:19:14 alekhine kernel: [   73.901724] ACPI: PCI Interrupt 0000:00:10.1[A] -> GSI 21 (level, low) -> IRQ 21
> >> Feb 25 20:19:14 alekhine kernel: [   73.901724] usb usb3: root hub lost power or was reset
> >> Feb 25 20:19:14 alekhine kernel: [   73.912597] ACPI: PCI Interrupt 0000:00:10.2[B] -> GSI 21 (level, low) -> IRQ 21
> >> Feb 25 20:19:14 alekhine kernel: [   73.912597] usb usb4: root hub lost power or was reset
> >> Feb 25 20:19:14 alekhine kernel: [   73.923472] ACPI: PCI Interrupt 0000:00:10.3[B] -> GSI 21 (level, low) -> IRQ 21
> >> Feb 25 20:19:14 alekhine kernel: [   73.923472] usb usb5: root hub lost power or was reset
> >> Feb 25 20:19:14 alekhine kernel: [   73.934336] ACPI: PCI Interrupt 0000:00:10.4[C] -> GSI 21 (level, low) -> IRQ 21
> >> Feb 25 20:19:14 alekhine kernel: [   73.945209] ACPI: PCI Interrupt 0000:00:11.5[C] -> GSI 22 (level, low) -> IRQ 22
> >> Feb 25 20:19:14 alekhine kernel: [   73.947465] ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
> >> Feb 25 20:19:14 alekhine kernel: [   73.947660] sd 3:0:0:0: [sda] Starting disk
> >> Feb 25 20:19:14 alekhine kernel: [   74.183122] ata3.01: ACPI cmd ef/03:0c:00:00:00:b0 filtered out
> >> Feb 25 20:19:14 alekhine kernel: [   74.183122] ata3.01: ACPI cmd ef/03:42:00:00:00:b0 filtered out
> >> Feb 25 20:19:14 alekhine kernel: [   74.336028] ata3.00: ACPI cmd ef/03:0c:00:00:00:a0 filtered out
> >> Feb 25 20:19:14 alekhine kernel: [   74.336028] ata3.00: ACPI cmd ef/03:42:00:00:00:a0 filtered out
> >> Feb 25 20:19:14 alekhine kernel: [   74.491252] ata3.00: configured for UDMA/33
> >> Feb 25 20:19:14 alekhine kernel: [   74.678330] ata3.01: configured for UDMA/33
> >> Feb 25 20:19:14 alekhine kernel: [   78.168897] ata4.00: ACPI cmd ef/03:0c:00:00:00:a0 filtered out
> >> Feb 25 20:19:14 alekhine kernel: [   78.168897] ata4.00: ACPI cmd ef/03:45:00:00:00:a0 filtered out
> >> Feb 25 20:19:14 alekhine kernel: [   78.172976] ata4.00: configured for UDMA/100
> >> Feb 25 20:19:14 alekhine kernel: [   78.177133] sd 3:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
> >> Feb 25 20:19:14 alekhine kernel: [   78.177133] sd 3:0:0:0: [sda] Write Protect is off
> >> Feb 25 20:19:14 alekhine kernel: [   78.177133] sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> >> Feb 25 20:19:14 alekhine kernel: [   78.720991] Restarting tasks ... <6>usb 2-1: USB disconnect, address 2
> >> Feb 25 20:19:14 alekhine kernel: [   78.766838] done.
> >> Feb 25 20:19:14 alekhine kernel: [   78.951998] usb 2-1: new low speed USB device using uhci_hcd and address 4
> >> Feb 25 20:19:14 alekhine kernel: [   79.114037] usb 2-1: configuration #1 chosen from 1 choice
> >> Feb 25 20:19:14 alekhine kernel: [   79.138166] input: Logitech USB Mouse as /devices/pci0000:00/0000:00:10.0/usb2/2-1/2-1:1.0/input/input5
> >> Feb 25 20:19:14 alekhine kernel: [   79.180828] input: USB HID v1.10 Mouse [Logitech USB Mouse] on usb-0000:00:10.0-1
> >> Feb 25 20:19:14 alekhine kernel: [   79.181059] usb 2-2: USB disconnect, address 3
> >> Feb 25 20:19:15 alekhine kernel: [   79.436567] usb 2-2: new low speed USB device using uhci_hcd and address 5
> >> Feb 25 20:19:15 alekhine kernel: [   79.606180] usb 2-2: configuration #1 chosen from 1 choice
> >> Feb 25 20:19:15 alekhine kernel: [   79.623893] input: Microsoft Microsoft<AE> Digital Media Pro Keyboard as /devices/pci0000:00/0000:00:10.0/usb2/2-2/2-2:1.0/input/input6
> >> Feb 25 20:19:15 alekhine kernel: [   79.663140] input: USB HID v1.11 Keyboard [Microsoft Microsoft<AE> Digital Media Pro Keyboard] on usb-0000:00:10.0-2
> >> Feb 25 20:19:15 alekhine kernel: [   79.697610] input: Microsoft Microsoft<AE> Digital Media Pro Keyboard as /devices/pci0000:00/0000:00:10.0/usb2/2-2/2-2:1.1/input/input7
> >> Feb 25 20:19:15 alekhine kernel: [   79.721948] input: USB HID v1.11 Device [Microsoft Microsoft<AE> Digital Media Pro Keyboard] on usb-0000:00:10.0-2
> >>
> >>
> >> I don't see anything there that would explain the failure, but the console never comes back, and I am forced to hard reset the box.  Anything else I can try?
> >>
> > 
> > So machine works but video is that? See suspend.sf.net...
> > 
> 
> I haven't done too much looking at what the tool on that site does,
> but I was under the impression that I should be able to do:
> 
> echo mem > /sys/power/state
> 
> and then bring the system back up and have it work.  If that is
> not expected to work, then I won't bother trying it again.  My
> goal in all this is to help test the kernel, and provide feedback
> and testing for features that are expected to work. If this is
> expected to work, then I would rather provide testing for patches
> to the kernel that will make this work, rather than relying on
> userspace tricks to get around a broken kernel (because frankly,
> I couldn't care much less if STR works for me or not - I was just
> testing it to be helpful).
> 
> Am I wrong about this?  Is the tool at suspend.sf.net supposed to
> be required for STR to work with current linux kernels?

That depends on the hardware configuration, really.  On some systems

# echo mem > /sys/power/state

works out of the box, but on some of them we need to run some real mode
quirks from the user space to bring the graphics card back on line.  That's
what s2ram is needed for.

Now, if you manage to find the combination of s2ram options appropriate for
your system, so that it can suspend and resume successfully, it will be very
helpful if you periodically test this functionality on new kernels to make sure
there are no regressions.

Thanks,
Rafael

  reply	other threads:[~2008-02-27 13:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-24  5:23 linux-next: Tree for Feb 24 Stephen Rothwell
2008-02-24 18:19 ` Kevin Winchester
2008-02-24 20:00   ` Rafael J. Wysocki
2008-02-24 23:35     ` Kevin Winchester
2008-02-24 23:43       ` Rafael J. Wysocki
2008-02-25  0:23         ` Kevin Winchester
2008-02-25  9:26       ` Pavel Machek
2008-02-26  0:24         ` broken suspend to ram with velocity driver Kevin Winchester
2008-02-26  0:49           ` Rafael J. Wysocki
2008-02-27  0:36             ` Kevin Winchester
2008-02-27 12:59               ` Rafael J. Wysocki
2008-02-27  0:48             ` Kevin Winchester
2008-02-27 13:00               ` Rafael J. Wysocki
2008-02-26 21:49           ` Pavel Machek
2008-02-27  0:28             ` Kevin Winchester
2008-02-27 13:06               ` Rafael J. Wysocki [this message]
2008-02-27 13:08               ` Matthew Garrett
2008-02-25 21:56 ` linux-next: Tree for Feb 24 Geert Uytterhoeven
2008-02-25 22:30   ` Randy Dunlap
2008-02-25 23:49   ` Stephen Rothwell
2008-02-26  7:55     ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200802271406.13312.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=kjwinchester@gmail.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=pavel@ucw.cz \
    --subject='Re: broken suspend to ram with velocity driver' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).