Bug 539861 - Resume from suspend does not work with virt enabled (HP 6930p)
Resume from suspend does not work with virt enabled (HP 6930p)
Status: CLOSED DUPLICATE of bug 536675
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-21 06:36 EST by drago01
Modified: 2013-01-10 03:04 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-24 05:37:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg without "intel_iommu=igfx_off" (52.42 KB, text/plain)
2009-11-22 08:14 EST, drago01
no flags Details

  None (edit)
Description drago01 2009-11-21 06:36:25 EST
Description of problem:

My HP 6930p (INTEL GM45 video) does hangs on resume (backlight off, total freeze).

Matthew suggested to disable the iommu (intel_iommu=off or intel_iommu=soft) but neither fixes it.

I tryed to locate a faulty driver using pm_trace but nothing come up (it hangs very early).

Yesterday I tested a 2.6.32 kernel from koji, but it did not work either.

Today I tryed to debug it again by playing with bios options. 
So I disabled virt and suspend/resume worked flawlessly. 
Enabling virt breaks it again. 

Disabling the virt obviously disables the IOMMU so it might be still related to that.

F11 works fine with virt enabled.

Version-Release number of selected component (if applicable):

2.6.31.6-142.fc12.x86_64 (does happen with every F12 kernel though, even -125 with has the IOMMU off by default does not work).

How reproducible:

Always

Steps to Reproduce:
1. Boot F12 on a HP 6930p with virt enabled
2. Suspend it
3. Hangs on Resume
4. Do the same with virt disabled, works
  
Actual results:

It should not hang on resume because virt is enabled (works fine in F11, so there is a regression somewhere)

Expected results:

Suspend/resume should work fine with virt enabled.

Additional info:

The kvm_intel module is not causing it either (having it loaded or not does not change anything).

If you need any other information, feel free to ask.
Comment 1 drago01 2009-11-22 07:26:07 EST
OK, done some more tests.

With "iommu=off" (rather than soft or intel_iommu=off) suspend/resume does work with virt enabled.

It does flood the logs with "nommu_map_single: overflow" messages on boot.
Comment 2 drago01 2009-11-22 07:29:28 EST
(In reply to comment #1)
> OK, done some more tests.
> 
> With "iommu=off" (rather than soft or intel_iommu=off) suspend/resume does work
> with virt enabled.
> 
> It does flood the logs with "nommu_map_single: overflow" messages on boot.  

This also adds a significant delay when starting X (~5sec)
Comment 3 drago01 2009-11-22 07:33:23 EST
More testing done:

intel_iommu=igfx_off seems to be the best setting:

1) I can leave virt enabled
2) no nasty messages in the logs
3) no effect on X
4) suspend/resume works

We still need a fix to either autodetect this or fix the problem to make it not required, but as always I assume this is a bios bug.
Comment 4 David Woodhouse 2009-11-22 07:59:57 EST
In Fedora 12 we set the VGA devices to complete passthrough. The only difference between that and 'intel_iommu=igfx_off' is that in the latter case we notice that there's an IOMMU which is _just_ for the graphics device, and we don't initialise that IOMMU at all.

I'm confused, therefore, that one works and the other doesn't. Can you post the full dmesg when booting normally work no arguments?
Comment 5 drago01 2009-11-22 08:14:47 EST
Created attachment 372895 [details]
dmesg without "intel_iommu=igfx_off"

OK, here it is (dmesg with no arguments).
Comment 6 David Woodhouse 2009-11-24 05:37:27 EST

*** This bug has been marked as a duplicate of bug 533402 ***
Comment 7 David Woodhouse 2009-11-24 05:38:24 EST
Argh, sorry; wrong bug.

*** This bug has been marked as a duplicate of bug 536675 ***

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