Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

(resending to list only as original attempt did not make it)

> The symptoms of the breakage are that sometimes the box hangs solid
> during resume, sometimes it hangs but can be rebooted by pressing
> Alt-SysRq-b, and sometimes it just powers off while resuming.  Still,
> it resumes correctly in about 75% of cases and that made the issue very
> hard to debug.
> [Interestingly enough, it was not reproducible with snd_hda_intel 
> unloaded, which made me think it was related to the driver, but
> evidently it wasn't.] 

This almost exactly describes problems I've been seeing on my HP 2510p. I 
never tried Alt-SysRq-b and have not seen the spontaneous power-off, but 
the percentage correct boots and relationship with the sound driver are 
spot on.

I worked around the sound driver relationship by using a very low power 
save setting so I can virtually count on it being disabled when I 
suspend.

I'll give your patch a go and report the results. Nice work!

Cheers,
FJP

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

On Thursday 29 January 2009, Ingo Molnar wrote:
> > Quick revival of this old thread with good news.
> > The "APIC error on CPU1" message is now gone!
>
> that was an old mystery!
>
> So enabling interrupts too early (possibly before the lapic, the hpet
> or both are initialized properly?) can generate an APIC error message?

I'm not really sure what change has caused the error to disappear. I could 
do some investigation, but fear we may have had too many changes (and 
broken suspend between them) to accurately pinpoint it.

> > With current git head I get:
> >    ACPI: Waking up from system sleep state S3
> >    ACPI: EC: non-query interrupt received, switching to interrupt
> > mode
>
> i started getting those messages too - but earlier in the cycle, during
> one of the ACPI merges i think.

I get the same message during a normal boot and in roughly the same place: 
shortly after CPU1 is enabled and CPUs attaching to sched-domains. So I'm 
happy with Alexey's comment that this is normal.

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Alexey Starikovskiy]

Rafael J. Wysocki wrote:
> On Thursday 29 January 2009, Ingo Molnar wrote:
>> * Frans Pop <elendil@planet.nl> wrote:
>>> With current git head I get:
>>>    ACPI: Waking up from system sleep state S3
>>>    ACPI: EC: non-query interrupt received, switching to interrupt mode
>> i started getting those messages too - but earlier in the cycle, during 
>> one of the ACPI merges i think.
> 
> AFAICS, the last message only means that the ACPI EC code is now going to use
> interrupts instead of polling, which generally is good.
> 
> Alex, is that correct?
Yes. Interrupt mode is better.

Regards,
Alex.

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Thursday 29 January 2009, Ingo Molnar wrote:
> 
> * Frans Pop <elendil@planet.nl> wrote:
> 
> > On Friday 05 December 2008, Linus Torvalds wrote:
> > > On Thu, 4 Dec 2008, Linus Torvalds wrote:
> > > > The third thing that worries me is the _very_ early occurrence of
> > > >
> > > > 	ACPI: Waking up from system sleep state S3
> > > > 	APIC error on CPU1: 00(40)
> > > > 	ACPI: EC: non-query interrupt received, switching to interrupt mode
> > > >
> > > > Now, that "APIC error" thing is worrisome. It's worrisome for
> > > > multiple reasons:
> > > >
> > > >  - errors are never good (0x40 means "received illegal vector",
> > > > whatever caused _that_)
> > > >
> > > >  - more importantly, it seems to imply that interrupts are enabled on
> > > >    CPU1, and they sure as hell shouldn't be enabled at this stage!
> > > >
> > > >    Do we perhaps have a SMP resume bug where we resume the other
> > > > CPU's with interrupts enabled?
> > > >
> > > >  - the "ACPI: EC: non-query interrupt received, switching to
> > > > interrupt mode" thing is from ACPI, and _also_ implies that
> > > > interrupts are on.
> > > >
> > > > Why are interrupts enabled that early? I really don't like seeing
> > > > interrupts enabled before we've even done the basic PCI resume.
> > 
> > Quick revival of this old thread with good news.
> > The "APIC error on CPU1" message is now gone!
> 
> that was an old mystery!
> 
> So enabling interrupts too early (possibly before the lapic, the hpet or 
> both are initialized properly?) can generate an APIC error message?

Hmm, I think that's something different, because the APIC error was on CPU1.
Perhaps the restoration of all standard PCI config spaces before bringing CPU1
up helped here.

> > With current git head I get:
> >    ACPI: Waking up from system sleep state S3
> >    ACPI: EC: non-query interrupt received, switching to interrupt mode
> 
> i started getting those messages too - but earlier in the cycle, during 
> one of the ACPI merges i think.

AFAICS, the last message only means that the ACPI EC code is now going to use
interrupts instead of polling, which generally is good.

Alex, is that correct?

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Ingo Molnar]

* Frans Pop <elendil@planet.nl> wrote:

> On Friday 05 December 2008, Linus Torvalds wrote:
> > On Thu, 4 Dec 2008, Linus Torvalds wrote:
> > > The third thing that worries me is the _very_ early occurrence of
> > >
> > > 	ACPI: Waking up from system sleep state S3
> > > 	APIC error on CPU1: 00(40)
> > > 	ACPI: EC: non-query interrupt received, switching to interrupt mode
> > >
> > > Now, that "APIC error" thing is worrisome. It's worrisome for
> > > multiple reasons:
> > >
> > >  - errors are never good (0x40 means "received illegal vector",
> > > whatever caused _that_)
> > >
> > >  - more importantly, it seems to imply that interrupts are enabled on
> > >    CPU1, and they sure as hell shouldn't be enabled at this stage!
> > >
> > >    Do we perhaps have a SMP resume bug where we resume the other
> > > CPU's with interrupts enabled?
> > >
> > >  - the "ACPI: EC: non-query interrupt received, switching to
> > > interrupt mode" thing is from ACPI, and _also_ implies that
> > > interrupts are on.
> > >
> > > Why are interrupts enabled that early? I really don't like seeing
> > > interrupts enabled before we've even done the basic PCI resume.
> 
> Quick revival of this old thread with good news.
> The "APIC error on CPU1" message is now gone!

that was an old mystery!

So enabling interrupts too early (possibly before the lapic, the hpet or 
both are initialized properly?) can generate an APIC error message?

> With current git head I get:
>    ACPI: Waking up from system sleep state S3
>    ACPI: EC: non-query interrupt received, switching to interrupt mode

i started getting those messages too - but earlier in the cycle, during 
one of the ACPI merges i think.

	Ingo

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

On Friday 05 December 2008, Linus Torvalds wrote:
> On Thu, 4 Dec 2008, Linus Torvalds wrote:
> > The third thing that worries me is the _very_ early occurrence of
> >
> > 	ACPI: Waking up from system sleep state S3
> > 	APIC error on CPU1: 00(40)
> > 	ACPI: EC: non-query interrupt received, switching to interrupt mode
> >
> > Now, that "APIC error" thing is worrisome. It's worrisome for
> > multiple reasons:
> >
> >  - errors are never good (0x40 means "received illegal vector",
> > whatever caused _that_)
> >
> >  - more importantly, it seems to imply that interrupts are enabled on
> >    CPU1, and they sure as hell shouldn't be enabled at this stage!
> >
> >    Do we perhaps have a SMP resume bug where we resume the other
> > CPU's with interrupts enabled?
> >
> >  - the "ACPI: EC: non-query interrupt received, switching to
> > interrupt mode" thing is from ACPI, and _also_ implies that
> > interrupts are on.
> >
> > Why are interrupts enabled that early? I really don't like seeing
> > interrupts enabled before we've even done the basic PCI resume.

Quick revival of this old thread with good news.
The "APIC error on CPU1" message is now gone!

With current git head I get:
   ACPI: Waking up from system sleep state S3
   ACPI: EC: non-query interrupt received, switching to interrupt mode

Looks like the recent suspend/resume changes are definitely moving us in 
the right direction.

Cheers,
FJP

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Saturday, 6 of December 2008, Rafael J. Wysocki wrote:
> On Saturday, 6 of December 2008, Linus Torvalds wrote:
> > 
> > On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> > >
> > > It only affects the legacy handling, but the non-legacy handling was left
> > > untouched.  IOW, the old "default" functions are still there and are being
> > > called by the "non-legacy" code (it's only used by USB at the moment, AFAICS).
> > 
> > Ok.
> > 
> > > Anyway, I did the test doing it only to the devices which don't have any
> > > non-default suspend-resume handling at all and _that_ apparently fixed the
> > > problem on my box. :-)
> > 
> > Which makes sense, btw. Because if you do the pci_save_state() on a device 
> > that _does_ have a suspend function, you'll be saving the post-suspend 
> > state - ie the device turned off.
> > 
> > So yeah, we really can only do the default suspend if the device has no 
> > pre-existing suspend function - or we'd need to make sure that all PCI 
> > drivers that do have suspend functions would only do the higher-level 
> > functionality.
> > 
> > Anyway, what I'm most interested in hearing is whether this actually 
> > improves your situation.
> 
> Yes, it does, from what I can tell at the moment. :-)

OK, this patch alone doesn't fix the problem, ie. I was able to reproduce it
with this patch applied, but it decreases the probability of a failure.

_However_, when I added two more patches to the mix:
- a patch that moved the PCI Express port suspend and resume to functions
  executed with interrupts disabled
- a patch that moves the restoration of the PCI config space in snd_hda_intel
  to a ->resume_early() callback
I'm not able to reproduce the problem any more (I did over 20
hibernation-resume cycles with this combination of patches applied with
occasional suspend-to-RAM-resume cycles in between and there were no problems
resuming).

I'm going to post the three patches in a separate thread for discussion.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Greg KH]

On Fri, Dec 05, 2008 at 05:55:16PM -0800, Linus Torvalds wrote:
> 
> 
> On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> >
> > It only affects the legacy handling, but the non-legacy handling was left
> > untouched.  IOW, the old "default" functions are still there and are being
> > called by the "non-legacy" code (it's only used by USB at the moment, AFAICS).
> 
> Ok.
> 
> > Anyway, I did the test doing it only to the devices which don't have any
> > non-default suspend-resume handling at all and _that_ apparently fixed the
> > problem on my box. :-)
> 
> Which makes sense, btw. Because if you do the pci_save_state() on a device 
> that _does_ have a suspend function, you'll be saving the post-suspend 
> state - ie the device turned off.

I think that is why we did not do it for every device, we didn't want to
touch drivers that already had working suspend calls.

> So yeah, we really can only do the default suspend if the device has no 
> pre-existing suspend function - or we'd need to make sure that all PCI 
> drivers that do have suspend functions would only do the higher-level 
> functionality.

Agreed.

thanks,

greg k-h

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Saturday, 6 of December 2008, Linus Torvalds wrote:
> 
> On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> >
> > It only affects the legacy handling, but the non-legacy handling was left
> > untouched.  IOW, the old "default" functions are still there and are being
> > called by the "non-legacy" code (it's only used by USB at the moment, AFAICS).
> 
> Ok.
> 
> > Anyway, I did the test doing it only to the devices which don't have any
> > non-default suspend-resume handling at all and _that_ apparently fixed the
> > problem on my box. :-)
> 
> Which makes sense, btw. Because if you do the pci_save_state() on a device 
> that _does_ have a suspend function, you'll be saving the post-suspend 
> state - ie the device turned off.
> 
> So yeah, we really can only do the default suspend if the device has no 
> pre-existing suspend function - or we'd need to make sure that all PCI 
> drivers that do have suspend functions would only do the higher-level 
> functionality.
> 
> Anyway, what I'm most interested in hearing is whether this actually 
> improves your situation.

Yes, it does, from what I can tell at the moment. :-)

Tomorrow I'll do more testing to (hopefully) confirm that.

> I can _easily_ see that your resume problem could be due to interrupt
> timing. That's especially true if there are shared interrupts, but even in
> the absense of that, I'm not at all sure that the e1000e resume code is
> interrupt-safe, for example. 

Agreed.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
>
> It only affects the legacy handling, but the non-legacy handling was left
> untouched.  IOW, the old "default" functions are still there and are being
> called by the "non-legacy" code (it's only used by USB at the moment, AFAICS).

Ok.

> Anyway, I did the test doing it only to the devices which don't have any
> non-default suspend-resume handling at all and _that_ apparently fixed the
> problem on my box. :-)

Which makes sense, btw. Because if you do the pci_save_state() on a device 
that _does_ have a suspend function, you'll be saving the post-suspend 
state - ie the device turned off.

So yeah, we really can only do the default suspend if the device has no 
pre-existing suspend function - or we'd need to make sure that all PCI 
drivers that do have suspend functions would only do the higher-level 
functionality.

Anyway, what I'm most interested in hearing is whether this actually 
improves your situation. I can _easily_ see that your resume problem could 
be due to interrupt timing. That's especially true if there are shared 
interrupts, but even in the absense of that, I'm not at all sure that the 
e1000e resume code is interrupt-safe, for example.

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Saturday, 6 of December 2008, Linus Torvalds wrote:
> 
> On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > I tested the appended patch with suspend-to-RAM and it just hangs during
> > resume.
> 
> That patch looks bogus. It only changes the "legacy" cases as far as I can 
> tell, so anybogy who has drv->pm set will now not do any state save at 
> all.
> 
> Or am I misreading it?

It only affects the legacy handling, but the non-legacy handling was left
untouched.  IOW, the old "default" functions are still there and are being
called by the "non-legacy" code (it's only used by USB at the moment, AFAICS).

Anyway, I did the test doing it only to the devices which don't have any
non-default suspend-resume handling at all and _that_ apparently fixed the
problem on my box. :-)

Appended is a very crude version of the patch (it duplicates some code),
tomorrow I'll post a cleaned-up version.

I'm still thinkig it will be reasonable to save standard config registers for
all devices with interrupts disabled, but that appears to be more complicated
that I thought it would be.

Thanks,
Rafael

---
 drivers/pci/pci-driver.c |   66 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)

Index: linux-2.6/drivers/pci/pci-driver.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci-driver.c
+++ linux-2.6/drivers/pci/pci-driver.c
@@ -300,6 +300,54 @@ static void pci_device_shutdown(struct d
 
 #ifdef CONFIG_PM_SLEEP
 
+static void pci_default_suspend_noirq(struct pci_dev *pci_dev)
+{
+	dev_info(&pci_dev->dev, "saving standard PCI config registers\n");
+
+	/* save the PCI config space */
+	pci_save_state(pci_dev);
+	/*
+	 * mark its power state as "unknown", since we don't know if
+	 * e.g. the BIOS will change its device state when we suspend.
+	 */
+	if (pci_dev->current_state == PCI_D0)
+		pci_dev->current_state = PCI_UNKNOWN;
+}
+
+static void pci_default_resume_noirq(struct pci_dev *pci_dev)
+{
+	dev_info(&pci_dev->dev, "restoring standard PCI config registers\n");
+
+	/* restore the PCI config space */
+	pci_restore_state(pci_dev);
+}
+
+static int pci_default_resume(struct pci_dev *pci_dev)
+{
+	int retval = 0;
+
+	dev_info(&pci_dev->dev, "trying to reenable device\n");
+
+	/* if the device was enabled before suspend, reenable */
+	retval = pci_reenable_device(pci_dev);
+	/*
+	 * if the device was busmaster before the suspend, make it busmaster
+	 * again
+	 */
+	if (pci_dev->is_busmaster)
+		pci_set_master(pci_dev);
+
+	return retval;
+}
+
+static bool pci_has_legacy_pm_handling(struct pci_dev *pci_dev)
+{
+	struct pci_driver *drv = pci_dev->driver;
+
+	return drv && (drv->suspend || drv->suspend_late || drv->resume
+		|| drv->resume_early);
+}
+
 /*
  * Default "suspend" method for devices that have no driver provided suspend,
  * or not even a driver at all.
@@ -343,6 +391,9 @@ static int pci_legacy_suspend(struct dev
 	struct pci_driver * drv = pci_dev->driver;
 	int i = 0;
 
+	if (!pci_has_legacy_pm_handling(pci_dev))
+		return 0;
+
 	if (drv && drv->suspend) {
 		i = drv->suspend(pci_dev, state);
 		suspend_report_result(drv->suspend, i);
@@ -358,10 +409,16 @@ static int pci_legacy_suspend_late(struc
 	struct pci_driver * drv = pci_dev->driver;
 	int i = 0;
 
+	if (!pci_has_legacy_pm_handling(pci_dev)) {
+		pci_default_suspend_noirq(pci_dev);
+		return 0;
+	}
+
 	if (drv && drv->suspend_late) {
 		i = drv->suspend_late(pci_dev, state);
 		suspend_report_result(drv->suspend_late, i);
 	}
+
 	return i;
 }
 
@@ -371,6 +428,9 @@ static int pci_legacy_resume(struct devi
 	struct pci_dev * pci_dev = to_pci_dev(dev);
 	struct pci_driver * drv = pci_dev->driver;
 
+	if (!pci_has_legacy_pm_handling(pci_dev))
+		return pci_default_resume(pci_dev);
+
 	if (drv && drv->resume)
 		error = drv->resume(pci_dev);
 	else
@@ -384,8 +444,14 @@ static int pci_legacy_resume_early(struc
 	struct pci_dev * pci_dev = to_pci_dev(dev);
 	struct pci_driver * drv = pci_dev->driver;
 
+	if (!pci_has_legacy_pm_handling(pci_dev)) {
+		pci_default_resume_noirq(pci_dev);
+		return 0;
+	}
+
 	if (drv && drv->resume_early)
 		error = drv->resume_early(pci_dev);
+
 	return error;
 }
 

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> 
> I tested the appended patch with suspend-to-RAM and it just hangs during
> resume.

That patch looks bogus. It only changes the "legacy" cases as far as I can 
tell, so anybogy who has drv->pm set will now not do any state save at 
all.

Or am I misreading it?

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Friday, 5 of December 2008, Linus Torvalds wrote:
> 
> On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > Well, actually I think we should go further and save the standard config
> > registers of _all_ PCI devices in the _late() callbacks (ie. with interrupts
> > disabled) and restore them in the _early() callbacks.
> 
> That would certainly simplify the code. 
> 
> > I don't really understand why pci_restore_state() is not called by the core
> > and every single driver calls it by itself.
> 
> The idea was to allow PCI drivers to override it if they wanted to.
> 
> That said, the ones that do their own state restore generally do it wrong 
> (eg the USB host controllers doing things in the wrong order and enabling 
> the device before having actually written back the BAR values), so it's 
> arguably broken to let drivers override it.
> 
> > IOW, I would split the resume of PCI devices into two parts, the first of
> > which will call pci_restore_state() with interrupts disabled and the second
> > will do the remaining stuff.
> 
> I would definitely not disagree with that - leave the regular 
> "suspend/resume" callbacks for purely higher-level actions. It would 
> interesting to hear what it does for you.

I tested the appended patch with suspend-to-RAM and it just hangs during
resume.

Next, I'll try to do that only for devices the drivers of which don't define their own
suspend-resume callbacks at all.

Thanks,
Rafael

---
 drivers/pci/pci-driver.c |   50 ++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 47 insertions(+), 3 deletions(-)

Index: linux-2.6/drivers/pci/pci-driver.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci-driver.c
+++ linux-2.6/drivers/pci/pci-driver.c
@@ -300,6 +300,46 @@ static void pci_device_shutdown(struct d
 
 #ifdef CONFIG_PM_SLEEP
 
+static void pci_default_suspend_noirq(struct pci_dev *pci_dev)
+{
+	dev_info(&pci_dev->dev, "saving standard PCI config registers\n");
+
+	/* save the PCI config space */
+	pci_save_state(pci_dev);
+	/*
+	 * mark its power state as "unknown", since we don't know if
+	 * e.g. the BIOS will change its device state when we suspend.
+	 */
+	if (pci_dev->current_state == PCI_D0)
+		pci_dev->current_state = PCI_UNKNOWN;
+}
+
+static void pci_default_resume_noirq(struct pci_dev *pci_dev)
+{
+	dev_info(&pci_dev->dev, "restoring standard PCI config registers\n");
+
+	/* restore the PCI config space */
+	pci_restore_state(pci_dev);
+}
+
+static int pci_default_resume(struct pci_dev *pci_dev)
+{
+	int retval = 0;
+
+	dev_info(&pci_dev->dev, "trying to reenable device\n");
+
+	/* if the device was enabled before suspend, reenable */
+	retval = pci_reenable_device(pci_dev);
+	/*
+	 * if the device was busmaster before the suspend, make it busmaster
+	 * again
+	 */
+	if (pci_dev->is_busmaster)
+		pci_set_master(pci_dev);
+
+	return retval;
+}
+
 /*
  * Default "suspend" method for devices that have no driver provided suspend,
  * or not even a driver at all.
@@ -346,8 +386,6 @@ static int pci_legacy_suspend(struct dev
 	if (drv && drv->suspend) {
 		i = drv->suspend(pci_dev, state);
 		suspend_report_result(drv->suspend, i);
-	} else {
-		pci_default_pm_suspend(pci_dev);
 	}
 	return i;
 }
@@ -362,6 +400,9 @@ static int pci_legacy_suspend_late(struc
 		i = drv->suspend_late(pci_dev, state);
 		suspend_report_result(drv->suspend_late, i);
 	}
+
+	pci_default_suspend_noirq(pci_dev);
+
 	return i;
 }
 
@@ -374,7 +415,7 @@ static int pci_legacy_resume(struct devi
 	if (drv && drv->resume)
 		error = drv->resume(pci_dev);
 	else
-		error = pci_default_pm_resume(pci_dev);
+		error = pci_default_resume(pci_dev);
 	return error;
 }
 
@@ -384,8 +425,11 @@ static int pci_legacy_resume_early(struc
 	struct pci_dev * pci_dev = to_pci_dev(dev);
 	struct pci_driver * drv = pci_dev->driver;
 
+	pci_default_resume_noirq(pci_dev);
+
 	if (drv && drv->resume_early)
 		error = drv->resume_early(pci_dev);
+
 	return error;
 }
 

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> 
> Well, actually I think we should go further and save the standard config
> registers of _all_ PCI devices in the _late() callbacks (ie. with interrupts
> disabled) and restore them in the _early() callbacks.

That would certainly simplify the code. 

> I don't really understand why pci_restore_state() is not called by the core
> and every single driver calls it by itself.

The idea was to allow PCI drivers to override it if they wanted to.

That said, the ones that do their own state restore generally do it wrong 
(eg the USB host controllers doing things in the wrong order and enabling 
the device before having actually written back the BAR values), so it's 
arguably broken to let drivers override it.

> IOW, I would split the resume of PCI devices into two parts, the first of
> which will call pci_restore_state() with interrupts disabled and the second
> will do the remaining stuff.

I would definitely not disagree with that - leave the regular 
"suspend/resume" callbacks for purely higher-level actions. It would 
interesting to hear what it does for you.

			Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Friday, 5 of December 2008, Linus Torvalds wrote:
> 
> On Thu, 4 Dec 2008, Linus Torvalds wrote:
> > 
> > The third thing that worries me is the _very_ early occurrence of
> > 
> > 	ACPI: Waking up from system sleep state S3
> > 	APIC error on CPU1: 00(40)
> > 	ACPI: EC: non-query interrupt received, switching to interrupt mode
> > 
> > Now, that "APIC error" thing is worrisome. It's worrisome for multiple 
> > reasons:
> > 
> >  - errors are never good (0x40 means "received illegal vector", whatever 
> >    caused _that_)
> > 
> >  - more importantly, it seems to imply that interrupts are enabled on 
> >    CPU1, and they sure as hell shouldn't be enabled at this stage!
> > 
> >    Do we perhaps have a SMP resume bug where we resume the other CPU's 
> >    with interrupts enabled?
> > 
> >  - the "ACPI: EC: non-query interrupt received, switching to interrupt 
> >    mode" thing is from ACPI, and _also_ implies that interrupts are on. 
> > 
> > Why are interrupts enabled that early? I really don't like seeing 
> > interrupts enabled before we've even done the basic PCI resume. 
> 
> Oh, I finally started looking more at this.
> 
> It's because the PCI layer uses the late resume for resuming. Which is 
> horrid. It really shouldn't. Resuming your device after interrupts were 
> enabled really sounds like a disaster. *Especially* if the device was 
> active before, either because of hibernation or simply because firmware 
> pre-initialized it to some "live" state (which could easily happen with 
> ethernet in particular).
> 
> I do wonder why the PCI layer wants to resume things so late. It sounds 
> totally insane to do things like resume the PCI bridge setup long *after* 
> you have resumed other devices early. So by doing the default resume late, 
> it just means that nobody can possibly use the early resume, and now 
> everybody needs to resume everything with interrupts already going full 
> blast.
> 
> IOW, the _sane_ thing would be to do something like the following patch 
> does, namely:
> 
>  - if the driver has a suspend or suspend_early function, _only_ call that 
>    (whether legacy or not)
> 
>  - otherwise, do the default suspend/resume late/early with interrupts 
>    disabled.
> 
> which means that by default, we'll do all save-restore of the PCI state 
> close to the actual CPU suspend event as possible.
> 
> Of course, hibernate probably depends on ->suspend() saving state, which 
> it won't. Again, if thats' the case, then that's just hibernate (again) 
> being totally fundamentally broken, and messing with STR functions. 

No, hibernate doesn't care whether ->suspend() or ->suspend_late() saves
the state, if that's what you mean.  Also, we have the hibernation-specific
callbacks in the new framework anyway.

> Rafael?

Well, actually I think we should go further and save the standard config
registers of _all_ PCI devices in the _late() callbacks (ie. with interrupts
disabled) and restore them in the _early() callbacks.

I don't really understand why pci_restore_state() is not called by the core
and every single driver calls it by itself.  Moreover, many of them
call pci_set_power_state(dev, PCI_D0) before calling pci_restore_state(),
although this is not really necessary, because they subsequently call
pci_enable_device() which calls pci_set_power_state(dev, PCI_D0) again.

IOW, I would split the resume of PCI devices into two parts, the first of
which will call pci_restore_state() with interrupts disabled and the second
will do the remaining stuff.

> I have neither tested the patch nor even tried to compile it - it's meant 
> to be an example and get people thinking about this, rather than anything 
> else.

I'm going to try it, though, and see what happens. ;-)

Thanks,
Rafael


> ---
>  drivers/pci/pci-driver.c |   20 ++++++++++----------
>  1 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index b4cdd69..6395983 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -346,8 +346,6 @@ static int pci_legacy_suspend(struct device *dev, pm_message_t state)
>  	if (drv && drv->suspend) {
>  		i = drv->suspend(pci_dev, state);
>  		suspend_report_result(drv->suspend, i);
> -	} else {
> -		pci_default_pm_suspend(pci_dev);
>  	}
>  	return i;
>  }
> @@ -361,7 +359,8 @@ static int pci_legacy_suspend_late(struct device *dev, pm_message_t state)
>  	if (drv && drv->suspend_late) {
>  		i = drv->suspend_late(pci_dev, state);
>  		suspend_report_result(drv->suspend_late, i);
> -	}
> +	} else if (!drv || !drv->suspend)
> +		pci_default_pm_suspend(pci_dev);
>  	return i;
>  }
>  
> @@ -373,8 +372,6 @@ static int pci_legacy_resume(struct device *dev)
>  
>  	if (drv && drv->resume)
>  		error = drv->resume(pci_dev);
> -	else
> -		error = pci_default_pm_resume(pci_dev);
>  	return error;
>  }
>  
> @@ -386,6 +383,8 @@ static int pci_legacy_resume_early(struct device *dev)
>  
>  	if (drv && drv->resume_early)
>  		error = drv->resume_early(pci_dev);
> +	else if (!drv || !drv->resume)
> +		error = pci_default_pm_resume(pci_dev);
>  	return error;
>  }
>  
> @@ -420,8 +419,6 @@ static int pci_pm_suspend(struct device *dev)
>  		if (drv->pm->suspend) {
>  			error = drv->pm->suspend(dev);
>  			suspend_report_result(drv->pm->suspend, error);
> -		} else {
> -			pci_default_pm_suspend(pci_dev);
>  		}
>  	} else {
>  		error = pci_legacy_suspend(dev, PMSG_SUSPEND);
> @@ -441,7 +438,8 @@ static int pci_pm_suspend_noirq(struct device *dev)
>  		if (drv->pm->suspend_noirq) {
>  			error = drv->pm->suspend_noirq(dev);
>  			suspend_report_result(drv->pm->suspend_noirq, error);
> -		}
> +		} else if (!drv->pm->suspend)
> +			pci_default_pm_suspend(pci_dev);
>  	} else {
>  		error = pci_legacy_suspend_late(dev, PMSG_SUSPEND);
>  	}
> @@ -458,8 +456,7 @@ static int pci_pm_resume(struct device *dev)
>  	pci_fixup_device(pci_fixup_resume, pci_dev);
>  
>  	if (drv && drv->pm) {
> -		error = drv->pm->resume ? drv->pm->resume(dev) :
> -			pci_default_pm_resume(pci_dev);
> +		error = drv->pm->resume ? drv->pm->resume(dev) : 0;
>  	} else {
>  		error = pci_legacy_resume(dev);
>  	}
> @@ -467,6 +464,7 @@ static int pci_pm_resume(struct device *dev)
>  	return error;
>  }
>  
> +
>  static int pci_pm_resume_noirq(struct device *dev)
>  {
>  	struct pci_dev *pci_dev = to_pci_dev(dev);
> @@ -478,6 +476,8 @@ static int pci_pm_resume_noirq(struct device *dev)
>  	if (drv && drv->pm) {
>  		if (drv->pm->resume_noirq)
>  			error = drv->pm->resume_noirq(dev);
> +		else if (!drv->pm->resume)
> +			error = pci_default_pm_resume(pci_dev);
>  	} else {
>  		error = pci_legacy_resume_early(dev);
>  	}
> 
> 



-- 
Everyone knows that debugging is twice as hard as writing a program
in the first place.  So if you're as clever as you can be when you write it,
how will you ever debug it? --- Brian Kernighan

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Friday, 5 of December 2008, Linus Torvalds wrote:
> 
> On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> > > 
> > > It would be very interesting to see if people affected get any printouts 
> > > about IO decodes that don't show up in /proc/ioports...
> > 
> > From my box:
> > 
> > pci 0000:00:1f.0: quirk: region d800-d87f claimed by ICH6 ACPI/GP IO/TCO
> > pci 0000:00:1f.0: quirk: region eec0-eeff claimed by ICH6 GPIO
> > pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0680 (mask 007f)
> > pci 0000:00:1f.0: ICH7 LPC Generic IO decode 4 PIO at 01e0 (mask 000f)
> > 
> > The second one shows up in /proc/ioports as "01e0-01ef : pnp 00:09", but the
> > first one (at 680) doesn't.
> 
> Ok, so the patch is interesting and probably worth expanding on (to 
> actually allocate the regions), but at the same time it too doesn't 
> actually explain your problems.
> 
> While the kernel doesn't know about that magic 0x680 allocation, it also 
> won't be allocating anything over it, since we define PCIBIOS_MIN_IO to 
> 0x1000 on x86, and will never allocate new resources under that.

In the meantime I did some more debugging with unpatched mainline and found
that if resume from hibernation fails, it usually fails immediately after
resuming the SATA controller (once it apparently failed right after resuming
EHCI, but then it just might be a problem with printing more messages), where
the resume sequence is (again, for easier reference):

pci:0000:00:00.0
pci:0000:00:02.0 <- graphics
pci:0000:00:02.1 <- graphics
pci:0000:00:1b.0 <- snd_hda_intel
pci:0000:00:1c.0 <- PCI Express port 1
pci:0000:00:1c.2 <- PCI Express port 3
pci:0000:00:1d.0 <- USB UHCI
pci:0000:00:1d.1 <- USB UHCI
pci:0000:00:1d.2 <- USB UHCI
pci:0000:00:1d.3 <- USB UHCI
pci:0000:00:1d.7 <- USB EHCI
pci:0000:00:1e.0 <- transparent bridge (Intel Corporation 82801 Mobile PCI Bridge)
pci:0000:00:1f.0 <- ISA bridge
pci:0000:00:1f.2 <- SATA (ahci)

--> so it usually hangs here or during the e1000e resume (I don't
get any messages from e1000e in the failing cycles, though).

pci:0000:01:00.0 <- e1000e
No Bus:0000:01
pci:0000:02:00.0 <- wireless (iwlagn)
No Bus:0000:02
pci:0000:03:0b.0 <- cardbus bridge
pci:0000:03:0b.1 <- FireWire
pci:0000:03:0b.3 <- SD Host controller (Texas Instruments)
No Bus:0000:04
No Bus:0000:03

Interestingly enough, usually after a failure some messages still get printed
into the screen (eg. messages from the ACPI battery driver) and the keyboard
sort of works, although the keys are not decoded correctly.

Next, as I was unable to get anything with the help of magic sysrq, so I tried
to boot the kernel with nmi_watchdog=1 and in this configuration I could not
reproduce the problem.  This clearly indicates that this really is a timing
issue.

I also noticed two things that may or may not be relevant.

First, the snd_hda_intel device is a PCI Express endpoind integrated into the
root complex which is the host bridge in this case.  This may be relevant since
unloading the snd_hda_intel driver makes things work 100% of the time.

Second, the transparent bridge 0000:00:1e.0 does supports subtractive
decoding, so if there is a device doing subtractive decode behind it (the
cardbus bridge may do that, for example) it will claim any transaction not
claimed by any other device on bus 0.

Next, I'm going to hack the magic sysrq so that it will allow me to get a stack
dump after a resume failure and I will add some debug printks to the PCI
resume code path.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Thu, 4 Dec 2008, Linus Torvalds wrote:
> 
> The third thing that worries me is the _very_ early occurrence of
> 
> 	ACPI: Waking up from system sleep state S3
> 	APIC error on CPU1: 00(40)
> 	ACPI: EC: non-query interrupt received, switching to interrupt mode
> 
> Now, that "APIC error" thing is worrisome. It's worrisome for multiple 
> reasons:
> 
>  - errors are never good (0x40 means "received illegal vector", whatever 
>    caused _that_)
> 
>  - more importantly, it seems to imply that interrupts are enabled on 
>    CPU1, and they sure as hell shouldn't be enabled at this stage!
> 
>    Do we perhaps have a SMP resume bug where we resume the other CPU's 
>    with interrupts enabled?
> 
>  - the "ACPI: EC: non-query interrupt received, switching to interrupt 
>    mode" thing is from ACPI, and _also_ implies that interrupts are on. 
> 
> Why are interrupts enabled that early? I really don't like seeing 
> interrupts enabled before we've even done the basic PCI resume. 

Oh, I finally started looking more at this.

It's because the PCI layer uses the late resume for resuming. Which is 
horrid. It really shouldn't. Resuming your device after interrupts were 
enabled really sounds like a disaster. *Especially* if the device was 
active before, either because of hibernation or simply because firmware 
pre-initialized it to some "live" state (which could easily happen with 
ethernet in particular).

I do wonder why the PCI layer wants to resume things so late. It sounds 
totally insane to do things like resume the PCI bridge setup long *after* 
you have resumed other devices early. So by doing the default resume late, 
it just means that nobody can possibly use the early resume, and now 
everybody needs to resume everything with interrupts already going full 
blast.

IOW, the _sane_ thing would be to do something like the following patch 
does, namely:

 - if the driver has a suspend or suspend_early function, _only_ call that 
   (whether legacy or not)

 - otherwise, do the default suspend/resume late/early with interrupts 
   disabled.

which means that by default, we'll do all save-restore of the PCI state 
close to the actual CPU suspend event as possible.

Of course, hibernate probably depends on ->suspend() saving state, which 
it won't. Again, if thats' the case, then that's just hibernate (again) 
being totally fundamentally broken, and messing with STR functions. 

Rafael?

I have neither tested the patch nor even tried to compile it - it's meant 
to be an example and get people thinking about this, rather than anything 
else.

		Linus
---
 drivers/pci/pci-driver.c |   20 ++++++++++----------
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index b4cdd69..6395983 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -346,8 +346,6 @@ static int pci_legacy_suspend(struct device *dev, pm_message_t state)
 	if (drv && drv->suspend) {
 		i = drv->suspend(pci_dev, state);
 		suspend_report_result(drv->suspend, i);
-	} else {
-		pci_default_pm_suspend(pci_dev);
 	}
 	return i;
 }
@@ -361,7 +359,8 @@ static int pci_legacy_suspend_late(struct device *dev, pm_message_t state)
 	if (drv && drv->suspend_late) {
 		i = drv->suspend_late(pci_dev, state);
 		suspend_report_result(drv->suspend_late, i);
-	}
+	} else if (!drv || !drv->suspend)
+		pci_default_pm_suspend(pci_dev);
 	return i;
 }
 
@@ -373,8 +372,6 @@ static int pci_legacy_resume(struct device *dev)
 
 	if (drv && drv->resume)
 		error = drv->resume(pci_dev);
-	else
-		error = pci_default_pm_resume(pci_dev);
 	return error;
 }
 
@@ -386,6 +383,8 @@ static int pci_legacy_resume_early(struct device *dev)
 
 	if (drv && drv->resume_early)
 		error = drv->resume_early(pci_dev);
+	else if (!drv || !drv->resume)
+		error = pci_default_pm_resume(pci_dev);
 	return error;
 }
 
@@ -420,8 +419,6 @@ static int pci_pm_suspend(struct device *dev)
 		if (drv->pm->suspend) {
 			error = drv->pm->suspend(dev);
 			suspend_report_result(drv->pm->suspend, error);
-		} else {
-			pci_default_pm_suspend(pci_dev);
 		}
 	} else {
 		error = pci_legacy_suspend(dev, PMSG_SUSPEND);
@@ -441,7 +438,8 @@ static int pci_pm_suspend_noirq(struct device *dev)
 		if (drv->pm->suspend_noirq) {
 			error = drv->pm->suspend_noirq(dev);
 			suspend_report_result(drv->pm->suspend_noirq, error);
-		}
+		} else if (!drv->pm->suspend)
+			pci_default_pm_suspend(pci_dev);
 	} else {
 		error = pci_legacy_suspend_late(dev, PMSG_SUSPEND);
 	}
@@ -458,8 +456,7 @@ static int pci_pm_resume(struct device *dev)
 	pci_fixup_device(pci_fixup_resume, pci_dev);
 
 	if (drv && drv->pm) {
-		error = drv->pm->resume ? drv->pm->resume(dev) :
-			pci_default_pm_resume(pci_dev);
+		error = drv->pm->resume ? drv->pm->resume(dev) : 0;
 	} else {
 		error = pci_legacy_resume(dev);
 	}
@@ -467,6 +464,7 @@ static int pci_pm_resume(struct device *dev)
 	return error;
 }
 
+
 static int pci_pm_resume_noirq(struct device *dev)
 {
 	struct pci_dev *pci_dev = to_pci_dev(dev);
@@ -478,6 +476,8 @@ static int pci_pm_resume_noirq(struct device *dev)
 	if (drv && drv->pm) {
 		if (drv->pm->resume_noirq)
 			error = drv->pm->resume_noirq(dev);
+		else if (!drv->pm->resume)
+			error = pci_default_pm_resume(pci_dev);
 	} else {
 		error = pci_legacy_resume_early(dev);
 	}

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Jesse Barnes]

On Thursday, December 4, 2008 7:25 pm Linus Torvalds wrote:
> On Thu, 4 Dec 2008, Linus Torvalds wrote:
> > Ok, the ICH6 LPC side has something similar, but not the same. Just two
> > ranges, and slightly less flexible wrt sizing.
> >
> > And ICH8/9/10 seems to have the same thing as ICH7.
>
> Here's a patch that implements what I think is the correct quirks (apart
> from the commented ICH6 lazy detail I didn't do).
>
> It would be very interesting to see if people affected get any printouts
> about IO decodes that don't show up in /proc/ioports...
>
> And I know I've looked for these kinds of things before in the Intel ICH
> docs, and apparently always missed these things (or been too lazy to
> react), so can somebody else see if they can find any other ranges like
> this? Maybe in non-LPC controllers?
>
> Jesse, are there any Intel chipset people who could once and for all say
> "these are the things we decode in our chipset" for _all_ chipsets and
> _all_ dynamic ranges? I've asked for that before. There must be people who
> know this, without having to wade through many thousands of pages of
> boring datasheets?

Yeah, I can get that info.  Sorry I haven't spent more time on this bug so 
far, I've been on vacation this week and very selective about which mails I 
reply to. :)

> The ICH datasheets tend to be 850 pages each, and there is more than one
> of them. And they _do_ differ in the details, even if there is a lot of
> sharing going on. So reading the docs is a huge effort, when there's bound
> to be somebody who just knows the answer.
>
> NOTE! This patch will just add a _printout_ of the IO regions it finds. It
> won't actually register them as known resources. So it won't make the
> kernel know to avoid them if they were to clash!
>
> Also, see the "This is not correct" for the ICH6 dynamically sized case.

Some of these may be listed as ACPI PNP ranges too...

Jesse

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > It would be very interesting to see if people affected get any printouts 
> > about IO decodes that don't show up in /proc/ioports...
> 
> From my box:
> 
> pci 0000:00:1f.0: quirk: region d800-d87f claimed by ICH6 ACPI/GP IO/TCO
> pci 0000:00:1f.0: quirk: region eec0-eeff claimed by ICH6 GPIO
> pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0680 (mask 007f)
> pci 0000:00:1f.0: ICH7 LPC Generic IO decode 4 PIO at 01e0 (mask 000f)
> 
> The second one shows up in /proc/ioports as "01e0-01ef : pnp 00:09", but the
> first one (at 680) doesn't.

Ok, so the patch is interesting and probably worth expanding on (to 
actually allocate the regions), but at the same time it too doesn't 
actually explain your problems.

While the kernel doesn't know about that magic 0x680 allocation, it also 
won't be allocating anything over it, since we define PCIBIOS_MIN_IO to 
0x1000 on x86, and will never allocate new resources under that.

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Friday, 5 of December 2008, Linus Torvalds wrote:
> 
> On Thu, 4 Dec 2008, Linus Torvalds wrote:
> > 
> > Ok, the ICH6 LPC side has something similar, but not the same. Just two 
> > ranges, and slightly less flexible wrt sizing.
> > 
> > And ICH8/9/10 seems to have the same thing as ICH7.
> 
> Here's a patch that implements what I think is the correct quirks (apart 
> from the commented ICH6 lazy detail I didn't do).
> 
> It would be very interesting to see if people affected get any printouts 
> about IO decodes that don't show up in /proc/ioports...

>From my box:

pci 0000:00:1f.0: quirk: region d800-d87f claimed by ICH6 ACPI/GP IO/TCO
pci 0000:00:1f.0: quirk: region eec0-eeff claimed by ICH6 GPIO
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0680 (mask 007f)
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 4 PIO at 01e0 (mask 000f)

The second one shows up in /proc/ioports as "01e0-01ef : pnp 00:09", but the
first one (at 680) doesn't.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

On Friday 05 December 2008, Frans Pop wrote:
> On Friday 05 December 2008, Linus Torvalds wrote:
> > Here's a patch that implements what I think is the correct quirks
> > (apart from the commented ICH6 lazy detail I didn't do).
>
> I get:
> pci 0000:00:1f.0: quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
> pci 0000:00:1f.0: quirk: region 1100-113f claimed by ICH6 GPIO
> pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0500 (mask 007f)
> pci 0000:00:1f.0: ICH7 LPC Generic IO decode 4 PIO at 02e8 (mask 0007)

Sorry, I missed:
> It would be very interesting to see if people affected get any
> printouts about IO decodes that don't show up in /proc/ioports...

Looks like 02e8 is missing (see /proc/ioports below).


I also tried the patch on my ICH7 desktop which gives:
pci 0000:00:1f.0: quirk: region 0400-047f claimed by ICH6 ACPI/GPIO/TCO
pci 0000:00:1f.0: quirk: region 0500-053f claimed by ICH6 GPIO
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0680 (mask 007f)
But 0680 is accounted for in /proc/ioports:
0680-06ff : pnp 00:06

Cheers,
FJP

/proc/ioports (for notebook):
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0064-0064 : keyboard
0070-0071 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : 0000:00:1f.1
  0170-0177 : ata_piix
01f0-01f7 : 0000:00:1f.1
  01f0-01f7 : ata_piix
02f8-02ff : pnp 00:0c
0376-0376 : 0000:00:1f.1
  0376-0376 : ata_piix
03c0-03df : vesafb
03f6-03f6 : 0000:00:1f.1
  03f6-03f6 : ata_piix
03f8-03ff : pnp 00:0c
04d0-04d1 : pnp 00:0c
0500-055f : pnp 00:0a
0800-080f : pnp 00:0a
0cf8-0cff : PCI conf1
1000-107f : 0000:00:1f.0
  1000-107f : pnp 00:0c
    1000-1003 : ACPI PM1a_EVT_BLK
    1004-1005 : ACPI PM1a_CNT_BLK
    1008-100b : ACPI PM_TMR
    1010-1015 : ACPI CPU throttle
    1020-1020 : ACPI PM2_CNT_BLK
    1028-102f : ACPI GPE0_BLK
    1060-107f : iTCO_wdt
1100-113f : 0000:00:1f.0
  1100-113f : pnp 00:0c
1200-121f : pnp 00:0c
2000-2007 : 0000:00:02.0
2008-200f : 0000:00:03.2
2010-2013 : 0000:00:03.2
2018-201f : 0000:00:03.2
2020-2023 : 0000:00:03.2
2030-203f : 0000:00:03.2
2040-2047 : 0000:00:03.3
  2040-2047 : serial
2060-207f : 0000:00:19.0
2080-209f : 0000:00:1a.0
  2080-209f : uhci_hcd
20a0-20bf : 0000:00:1a.1
  20a0-20bf : uhci_hcd
20c0-20df : 0000:00:1d.0
  20c0-20df : uhci_hcd
20e0-20ff : 0000:00:1d.1
  20e0-20ff : uhci_hcd
2100-211f : 0000:00:1d.2
  2100-211f : uhci_hcd
2120-212f : 0000:00:1f.1
  2120-212f : ata_piix
3000-3fff : PCI Bus 0000:02
  3000-30ff : PCI CardBus 0000:03
  3400-34ff : PCI CardBus 0000:03

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

On Friday 05 December 2008, Rafael J. Wysocki wrote:
> On Friday, 5 of December 2008, Linus Torvalds wrote:
> > Oh, btw, I thought your and Frans' laptops were identical?
>
> No, they are from different vendors. :-)  Mine is a Toshiba one and the
> Frans' one is from HP.

Also, the CardBus bridge and what's behind them are quite different
(and we use different firewire stacks).

Mine is:
02:06.0 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev ba)
        Kernel driver in use: yenta_cardbus
        Kernel modules: yenta_socket
02:06.1 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 04)
        Kernel driver in use: ohci1394
        Kernel modules: ohci1394
02:06.2 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 21)
        Kernel driver in use: sdhci-pci
        Kernel modules: sdhci-pci
02:06.3 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller [1180:0843] (rev ff)
        Kernel driver in use: ricoh-mmc
        Kernel modules: ricoh_mmc
(The ricoh_mmc module disables the last one.)

While Rafael has:
03:0b.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
	Kernel driver in use: yenta_cardbus
	Kernel modules: yenta_socket
03:0b.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller (prog-if 10 [OHCI])
	Kernel driver in use: firewire_ohci
	Kernel modules: firewire-ohci
03:0b.3 SD Host controller: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller (prog-if 01)
	Kernel driver in use: sdhci-pci
	Kernel modules: sdhci-pci

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

On Friday 05 December 2008, Linus Torvalds wrote:
> Here's a patch that implements what I think is the correct quirks
> (apart from the commented ICH6 lazy detail I didn't do).

I get:
pci 0000:00:1f.0: quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
pci 0000:00:1f.0: quirk: region 1100-113f claimed by ICH6 GPIO
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0500 (mask 007f)
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 4 PIO at 02e8 (mask 0007)

The ICH6 and ICH7 in those messages is a bit weird given that my system is 
ICH8...

Hardware info (JFYI):
00:1f.0 ISA bridge [0601]: Intel Corporation 82801HBM (ICH8M-E) LPC 
Interface Controller [8086:2811] (rev 03)

System Information
        Manufacturer: Hewlett-Packard
        Product Name: HP Compaq 2510p Notebook PC
        Version: F.0C
Base Board Information
        Manufacturer: Hewlett-Packard
        Product Name: 30C9
        Version: KBC Version 75.28
BIOS Information
        Vendor: Hewlett-Packard
        Version: 68MSP Ver. F.0C
        Release Date: 06/18/2008

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Thu, 4 Dec 2008, Linus Torvalds wrote:
> 
> Ok, the ICH6 LPC side has something similar, but not the same. Just two 
> ranges, and slightly less flexible wrt sizing.
> 
> And ICH8/9/10 seems to have the same thing as ICH7.

Here's a patch that implements what I think is the correct quirks (apart 
from the commented ICH6 lazy detail I didn't do).

It would be very interesting to see if people affected get any printouts 
about IO decodes that don't show up in /proc/ioports...

And I know I've looked for these kinds of things before in the Intel ICH 
docs, and apparently always missed these things (or been too lazy to 
react), so can somebody else see if they can find any other ranges like 
this? Maybe in non-LPC controllers? 

Jesse, are there any Intel chipset people who could once and for all say 
"these are the things we decode in our chipset" for _all_ chipsets and 
_all_ dynamic ranges? I've asked for that before. There must be people who 
know this, without having to wade through many thousands of pages of 
boring datasheets?

The ICH datasheets tend to be 850 pages each, and there is more than one 
of them. And they _do_ differ in the details, even if there is a lot of 
sharing going on. So reading the docs is a huge effort, when there's bound 
to be somebody who just knows the answer.

NOTE! This patch will just add a _printout_ of the IO regions it finds. It 
won't actually register them as known resources. So it won't make the 
kernel know to avoid them if they were to clash!

Also, see the "This is not correct" for the ICH6 dynamically sized case. 

		Linus

---
 drivers/pci/quirks.c |  105 ++++++++++++++++++++++++++++++++++++++++++-------
 1 files changed, 90 insertions(+), 15 deletions(-)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 5f4f85f..1b64b28 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -449,7 +449,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,    PCI_DEVICE_ID_INTEL_82801DB_12,
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,    PCI_DEVICE_ID_INTEL_82801EB_0,		quirk_ich4_lpc_acpi);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,    PCI_DEVICE_ID_INTEL_ESB_1,		quirk_ich4_lpc_acpi);
 
-static void __devinit quirk_ich6_lpc_acpi(struct pci_dev *dev)
+static void __devinit ich6_lpc_acpi_gpio(struct pci_dev *dev)
 {
 	u32 region;
 
@@ -459,20 +459,95 @@ static void __devinit quirk_ich6_lpc_acpi(struct pci_dev *dev)
 	pci_read_config_dword(dev, 0x48, &region);
 	quirk_io_region(dev, region, 64, PCI_BRIDGE_RESOURCES+1, "ICH6 GPIO");
 }
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH6_0, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH6_1, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH7_0, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH7_1, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH7_31, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH8_0, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH8_2, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH8_3, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH8_1, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH8_4, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_2, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_4, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_7, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_8, quirk_ich6_lpc_acpi);
+
+static void __devinit ich6_lpc_generic_decode(struct pci_dev *dev, unsigned reg, const char *name, int dynsize)
+{
+	u32 val;
+	u32 size, base;
+
+	pci_read_config_dword(dev, reg, &val);
+
+	/* Enabled? */
+	if (!(val & 1))
+		return;
+	base = val & 0xfffc;
+	if (dynsize) {
+		/*
+		 * This is not correct. It is 16, 32 or 64 bytes depending on
+		 * register D31:F0:ADh bits 5:4.
+		 *
+		 * But this gets us at least _part_ of it.
+		 */
+		size = 16;
+	} else {
+		size = 128;
+	}
+	base &= ~(size-1);
+
+	/* Just print it out for now. We should reserve it after more debugging */
+	dev_info(&dev->dev, "%s PIO at %04x-%04x\n", name, base, base+size-1);
+}
+
+static void __devinit quirk_ich6_lpc(struct pci_dev *dev)
+{
+	/* Shared ACPI/GPIO decode with all ICH6+ */
+	ich6_lpc_acpi_gpio(dev);
+
+	/* ICH6-specific generic IO decode */
+	ich6_lpc_generic_decode(dev, 0x84, "LPC Generic IO decode 1", 0);
+	ich6_lpc_generic_decode(dev, 0x88, "LPC Generic IO decode 2", 1);
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH6_0, quirk_ich6_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH6_1, quirk_ich6_lpc);
+
+static void __devinit ich7_lpc_generic_decode(struct pci_dev *dev, unsigned reg, const char *name)
+{
+	u32 val;
+	u32 mask, base;
+
+	pci_read_config_dword(dev, reg, &val);
+
+	/* Enabled? */
+	if (!(val & 1))
+		return;
+
+	/*
+	 * IO base in bits 15:2, mask in bits 23:18, both
+	 * are dword-based
+	 */
+	base = val & 0xfffc;
+	mask = (val >> 16) & 0xfc;
+	mask |= 3;
+
+	/* Just print it out for now. We should reserve it after more debugging */
+	dev_info(&dev->dev, "%s PIO at %04x (mask %04x)\n", name, base, mask);
+}
+
+/* ICH7-10 has the same common LPC generic IO decode registers */
+static void __devinit quirk_ich7_lpc(struct pci_dev *dev)
+{
+	/* We share the common ACPI/DPIO decode with ICH6 */
+	ich6_lpc_acpi_gpio(dev);
+
+	/* And have 4 ICH7+ generic decodes */
+	ich7_lpc_generic_decode(dev, 0x84, "ICH7 LPC Generic IO decode 1");
+	ich7_lpc_generic_decode(dev, 0x88, "ICH7 LPC Generic IO decode 2");
+	ich7_lpc_generic_decode(dev, 0x8c, "ICH7 LPC Generic IO decode 3");
+	ich7_lpc_generic_decode(dev, 0x90, "ICH7 LPC Generic IO decode 4");
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH7_0, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH7_1, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH7_31, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH8_0, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH8_2, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH8_3, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH8_1, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH8_4, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_2, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_4, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_7, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_8, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_ICH10_1, quirk_ich7_lpc);
 
 /*
  * VIA ACPI: One IO region pointed to by longword at

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Thu, 4 Dec 2008, Linus Torvalds wrote:
> 
> NOTE NOTE NOTE! I didn't check which all LPC bridges there are out there 
> that have these magic registers. But it shows up in the ICH7 docs. It 
> migth exist in ICH[5-9] for all I know. But at least for ICH7, the only 
> LPC bridge ID's I find in the spec update are 27b8, 27b9 and 27bd, which 
> are those three devices that I list in the quirks.

Ok, the ICH6 LPC side has something similar, but not the same. Just two 
ranges, and slightly less flexible wrt sizing.

And ICH8/9/10 seems to have the same thing as ICH7.

And looking at my own machine (ICH10) it actually appears like my ICH10 
setup has two of the magic IO ranges that it decodes, and only one of them 
is covered by the BIOS PnP tables.

They're both below 0x1000, though, so Linux shouldn't ever allocate 
anything on top of them. And that's the norm - when firmware sets up 
hidden magic system IO ranges, they do tend to be low IO ports.

But if some incompetent firmware person screws that up...

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > Maybe the PIO window matters? Any magic suspend registers are usually in 
> > PIO space, not in MMIO space. Did /proc/ioports change, and if so, how? 
> 
> |18,20c18,19
> |< 1000-1fff : PCI Bus 0000:03
> |<   1000-10ff : PCI CardBus 0000:04
> |<   1400-14ff : PCI CardBus 0000:04
> |---
> |> 1000-10ff : PCI CardBus 0000:04
> |> 1400-14ff : PCI CardBus 0000:04
> 
> where the first one is with my patch and the second one is with the "no sizing
> for transparent bridges" patch.  No difference to my eyes, if the "transparent"
> bridge is really transparent. :-)

Well, there _is_ a difference, although a subtle one. Not for the Cardbus 
card itself, but for decode of _non-cardbus_ IO ranges.

IOW, if there is a secret magic IO port that we don't know about at (say) 
address 0x1100, then the difference is that now there would be a fight 
over who would take it.

And I think I actually have found some secret IO decoding in ICH7. Damn. I 
_hate_ it when Intel does that. I asked (long ago) that Intel double-check 
that we have quirks for all their idiotic magic IO addresses, but they 
clearly never did that.

Or maybe I'm reading the ICH7 docs wrong. But I don't think I am.

NOTE NOTE NOTE! I didn't check which all LPC bridges there are out there 
that have these magic registers. But it shows up in the ICH7 docs. It 
migth exist in ICH[5-9] for all I know. But at least for ICH7, the only 
LPC bridge ID's I find in the spec update are 27b8, 27b9 and 27bd, which 
are those three devices that I list in the quirks.

Somebody should double-check this, and also check whether ICH6-9 have the 
same LPC decode logic..

Anyway, does this cause anything to be printed out for you? I have _not_ 
checked whether this is the only such programmable hidden range register 
set.

That said, the "no IO window" case should be the safe one (if there are 
hidden IO ports that clash), and it's the one that does _not_ work for 
you, so this may not be it either. But these kinds of quirks were very 
common reasons for ACPI power states not working (because we would just 
allocate something else on top of the damn hidden things that we didn't 
know about).

		Linus

---
 drivers/pci/quirks.c |   36 ++++++++++++++++++++++++++++++++++++
 1 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 5f4f85f..355ccf2 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -474,6 +474,42 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_4, quirk_
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_7, quirk_ich6_lpc_acpi);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_8, quirk_ich6_lpc_acpi);
 
+static void __devinit ich7_lpc_generic_decode(struct pci_dev *dev, unsigned reg, const char *name)
+{
+	u32 val;
+	u32 mask, base;
+
+	pci_read_config_dword(dev, reg, &val);
+
+	/* Enabled? */
+	if (!(val & 1))
+		return;
+
+	/* Base in bits 15:2 */
+	base = val & 0xfffc;
+
+	/* Decode mask in bits 23:18 */
+	mask = (val >> 16) & 0xfc;
+
+	/* The mask is only on a dword address, the word/byte is always matched */
+	mask |= 3;
+
+	/* Just print it out for now. We should reserve it after debugging */
+	dev_info(&dev->dev, "%s PIO at %04x (mask %04x)\n", name, base, mask);
+}
+
+static void __devinit quirk_ich7_lpc_decode(struct pci_dev *dev)
+{
+	ich7_lpc_generic_decode(dev, 0x84, "ICH7 LPC Generic IO decode 1");
+	ich7_lpc_generic_decode(dev, 0x88, "ICH7 LPC Generic IO decode 2");
+	ich7_lpc_generic_decode(dev, 0x8c, "ICH7 LPC Generic IO decode 3");
+	ich7_lpc_generic_decode(dev, 0x90, "ICH7 LPC Generic IO decode 4");
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_ICH7_0, quirk_ich7_lpc_decode);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_ICH7_1, quirk_ich7_lpc_decode);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_ICH7_31, quirk_ich7_lpc_decode);
+
+
 /*
  * VIA ACPI: One IO region pointed to by longword at
  *	0x48 or 0x20 (256 bytes of ACPI registers)

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Friday, 5 of December 2008, Linus Torvalds wrote:
> 
> On Thu, 4 Dec 2008, Linus Torvalds wrote:
> > 
> > On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> > > 
> > > There's a difference, though.  It doesn't cause the resources flags to be
> > > cleared for the cardbus bridge and the cardbus bridge gets the correct sizes
> > > of both prefetchable and non-prefetchable windows (64 MB).
> > 
> > Yes, true. In that sense, it minimizes the differences between the 
> > "working" and "nonworking" case. 
> 
> Hmm. 
> 
> One other issue: we've been looking mostly at MMIO, but another thing that 
> differs here is the PIO part.
> 
> Your patch only changes pbus_size_mem(), so what happens is that it avoids 
> allocating the prefetch window. But it still allocates the PIO window, 
> because pbus_size_io() is still run.
> 
> Maybe the PIO window matters? Any magic suspend registers are usually in 
> PIO space, not in MMIO space. Did /proc/ioports change, and if so, how? 

|18,20c18,19
|< 1000-1fff : PCI Bus 0000:03
|<   1000-10ff : PCI CardBus 0000:04
|<   1400-14ff : PCI CardBus 0000:04
|---
|> 1000-10ff : PCI CardBus 0000:04
|> 1400-14ff : PCI CardBus 0000:04

where the first one is with my patch and the second one is with the "no sizing
for transparent bridges" patch.  No difference to my eyes, if the "transparent"
bridge is really transparent. :-)

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Thu, 4 Dec 2008, Linus Torvalds wrote:
> 
> On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > There's a difference, though.  It doesn't cause the resources flags to be
> > cleared for the cardbus bridge and the cardbus bridge gets the correct sizes
> > of both prefetchable and non-prefetchable windows (64 MB).
> 
> Yes, true. In that sense, it minimizes the differences between the 
> "working" and "nonworking" case. 

Hmm. 

One other issue: we've been looking mostly at MMIO, but another thing that 
differs here is the PIO part.

Your patch only changes pbus_size_mem(), so what happens is that it avoids 
allocating the prefetch window. But it still allocates the PIO window, 
because pbus_size_io() is still run.

Maybe the PIO window matters? Any magic suspend registers are usually in 
PIO space, not in MMIO space. Did /proc/ioports change, and if so, how? 

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Friday, 5 of December 2008, Linus Torvalds wrote:
> 
> On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> > > 
> > > Yes. And in the case of Frans' machine, the e1000e controller was before 
> > > all the bridges too.
> > 
> > Hm.  And unloading it before suspend made things work?  Interesting.
> 
> Yeah. Frans' workaround was
> 
>  - unloading e1000e before suspend
>  - using aggressive powersave setting on snd_hda_intel to ensure that
>    sound controller was already sleeping before entering suspend
> 
> and both of those devices are on the root PCI bus and are enumerated (and 
> thus resumed) before the transparent bridge.
> 
> So yeah, the whole "resource allocation for that bridge" saga should 
> _really_ not matter. But it clearly does seem to.

Well, I'm going to have a closer look at what we're doing to PCI bridges in the
resume code path, as this _feels_ relevant in this case.

Perhaps we're not doing something we're supposed to do (that already happened
for regular devices in the past) or we're doing something we're not supposed
to do.  Unfortunately, I'd have to dig into the PCI bridge spec for this
purpose and that will take time.  Still, I suspect that's worth doing, as
potentially the problem may affect a wide range of systems.

The fact that I have a box on which I can reproduce the problem should help
here. ;-)

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > Yes. And in the case of Frans' machine, the e1000e controller was before 
> > all the bridges too.
> 
> Hm.  And unloading it before suspend made things work?  Interesting.

Yeah. Frans' workaround was

 - unloading e1000e before suspend
 - using aggressive powersave setting on snd_hda_intel to ensure that
   sound controller was already sleeping before entering suspend

and both of those devices are on the root PCI bus and are enumerated (and 
thus resumed) before the transparent bridge.

So yeah, the whole "resource allocation for that bridge" saga should 
_really_ not matter. But it clearly does seem to.

			Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > Not very interesting. It just does the same thing your previous patches 
> > have done - ignores the cardbus slot for sizing. It just does it 
> > differently and more explicitly.
> 
> There's a difference, though.  It doesn't cause the resources flags to be
> cleared for the cardbus bridge and the cardbus bridge gets the correct sizes
> of both prefetchable and non-prefetchable windows (64 MB).

Yes, true. In that sense, it minimizes the differences between the 
"working" and "nonworking" case. 

Which is interesting in the sense that it makes it even less likely that 
it's an actual resource clash. 

> I know that. :-)  Still, I find it important to notice that the memory windows
> of the cardbus bridge can be 64 MB-wide and things work in that case too.
> Also, I like it more than the previous patch. ;-)
> 
> Moreover, I _think_ it would work for Frans too, because I _suspect_ the
> problem is related to a cardbus bridge being located behind that "transparent"
> thing somehow.

Well, I suspect that on Frans' machine, there will be no difference at all 
between your patch and my previous patch, since he already had a bridge 
window allocated by the BIOS. And he also had just that firewire and mmc 
thing that only needed that memory window, so he'd end up with the exact 
same resource allocation, methinks.

> > Can you send "lspci -vv" and "dmesg" output for that kernel?
> 
> No prob, both attached along with the contents of /proc/iomem .

It all looks very sane. Too bad it apparently doesn't work.

> > Even if it failed the suspend/resume, it's interesting, because I would
> > actually have expected that one to have the same layout as the successful
> > ones. 
> 
> Well, not exactly.  Actually, with this patch the graphics and "ICH HD audio"
> get their memory ranges before the ranges of _all_ devices behind the
> transparent bridge, while in the "working" case their memory ranges are located
> _after_ the memory ranges of devices behind the transparent bridge _except_
> for the cardbus bridge's memory windows.

Yes, however, it shouldn't matter.

Except in cae the audio driver (for example) were to access past its MMIO 
window, and we'd have a situation where we care what was just before it or 
after it. That doesn't seem very likely, though.

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Friday, 5 of December 2008, Linus Torvalds wrote:
> 
> On Thu, 4 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > That said the "don't bother allocating bridging windows for transparent
> > bridges" patch resulted in the following layout on my box (from /proc/iomem):
> > 
> > 88000000-8807ffff : 0000:00:02.1
> > 88080000-88083fff : 0000:00:1b.0
> >   88080000-88083fff : ICH HD audio
> > 88084000-88087fff : 0000:03:0b.1
> > 88088000-88088fff : 0000:03:0b.0
> >   88088000-88088fff : yenta_socket
> > 88089000-880897ff : 0000:03:0b.1
> >   88089000-880897ff : firewire_ohci
> > 88089800-880898ff : 0000:03:0b.3
> >   88089800-880898ff : mmc0
> > 8808a000-8808afff : Intel Flush Page
> > 8c000000-8fffffff : PCI CardBus 0000:04
> > 90000000-93ffffff : PCI CardBus 0000:04
> > 
> > while my "don't allocate bridging windows for cardbus bridges behind
> > transparent bridges" patch I've just sent (appended for easier reference)
> > results in the layout:
> > 
> > 88000000-880fffff : PCI Bus 0000:03
> >   88000000-88003fff : 0000:03:0b.1
> >   88004000-88004fff : 0000:03:0b.0
> >     88004000-88004fff : yenta_socket
> >   88005000-880057ff : 0000:03:0b.1
> >     88005000-880057ff : firewire_ohci
> >   88005800-880058ff : 0000:03:0b.3
> >     88005800-880058ff : mmc0
> > 88100000-8817ffff : 0000:00:02.1
> > 88180000-88183fff : 0000:00:1b.0
> >   88180000-88183fff : ICH HD audio
> > 88184000-88184fff : Intel Flush Page
> > 8c000000-8fffffff : PCI CardBus 0000:04
> > 90000000-93ffffff : PCI CardBus 0000:04
> 
> Well, this happens because in the second case, you still will allocate a 
> non-prefetchable window due to the _other_ devices behind the bridge (ie 
> the firewire and mmc device.
> 
> So with your "ignore cardbus device resources", you still do end up with a 
> bridge window allocated, but now it will depend entirely on what other 
> devices exist on that PCI bus. Which is why I really dislike that patch, 
> because it really makes no sense at all. 
> 
> And once you've allocated the PCI bridge window, then the alignment 
> requirements are that you end up having at least 1MB of window, and now 
> because a window exists, and will fit, it will then happily put the yenta 
> control mappings into that window even though it didn't size it for them.
> 
> See?
> 
> Also, notice how it doesn't put the actual cardbus bridge windows 
> themselves into that PCI bridge window, because they won't fit. So these 
> resources:
> 
> 	8c000000-8fffffff : PCI CardBus 0000:04
> 	90000000-93ffffff : PCI CardBus 0000:04
> 
> are outside the window, even though that bus is topologically inside the 
> same bus, and they both end up depending on the fact that the PCI bus 
> controller is transparent.
> 
> So the above results are fairly easy to explain.
> 
> The _ordering_ difference comes simply from the allocation order. We'll do 
> bus allocations first (if we do them), which is why _if_ we allocate a 
> window for that PCI bus 03 (ie the one that is bridged to by 0:1e.0, that 
> transparent bridge), then we'll end up allocating it first. So that's why 
> the PCI bridge window shows up at 0x88000000, if it shows up at all 
> (because that's the starting address for PCI allocations).
> 
> Then, we'll do the regular devices in the order we found them, so then 
> we'll allocate the resources for device 0:02.1 and then 0:1b.0. Now, _if_ 
> we did a bus window allocation, they'll end up being after the bus window 
> we allocated. Otherwise they'll end up being the first allocations.
> 
> So then, by the time we actually get to bus#3, and devices 3:0b.*, where 
> they end up is going to depend on whether we allocated that bus window (in 
> which case they'll preferentially get allocated inside the window - ie 
> starting at 0x88000000), or they'll just get allocated inside the parent 
> (root) PCI bus. In the latter case they'll be allocated after the 0:02.1 
> etc devices.
> 
> So the differences in ordering really do make sense, and are a direct 
> consequence of whether we decided to need to allocate a bridging window 
> for that PCI-PCI bridge at 0:1e.0.
> 
> Also note that _if_ PCI bus #3 had had other devices with prefetchable 
> memory resources, then we'd have allocated a prefetchable window for 
> those even with your patch, and then we'd have been back to the original 
> allocation again (although sizing might cause changes, since your patch 
> will make us ignore the cardbus controlle for sizing).

Yes, I do realize all of what you said above.  I only wanted to note that the
layouts of device's memory ranges are different with both patches.

> > where devices behind the transparent bridge (PCI Bus 0000:03) are located
> > _before_ ICH HD audio in the memory address space, and this one appears to
> > work.  So there _may_ be an effect of the layout too.
> 
> I do agree that your patch will affect layout. I just don't think it makes 
> any real amount of sense because of how it essentially does so "randomly" 
> depending on what other devices you'd have behind the transparent bridge.
> 
> Which is why I think we should either not size transparent bridges at all, 
> or we should size _all_ the devices behind them.

I'm not saying it's unreasonable to do this in general.  Still, on this
particular box it appears to break things in a very subtle way.

Also, I do realize that most probably the root cause of that is something
else, but we can make it show up itself or hide by changing the layout of
the memory space.  What is this, though, I don't know.

> Oh, btw, I thought your and Frans' laptops were identical?

No, they are from different vendors. :-)  Mine is a Toshiba one and the Frans'
one is from HP.

> They don't seem to be: in Frans' case, the firmware does seem to set up one
> memory window, so he gets that one even with my "don't size anything" patch,
> just because we'll still honor allocations done by firmware.
> 
> > Well, given that both affected boxes have the same chipset (945GM), I seriously
> > suspect a nastiness in that chipset we're not aware of.  Especially that
> > the problem is not reproducible without snd_hda_intel (at least on my box).
> 
> Well, the counter-argument to that is that the 945GM should be a _very_ 
> common chipset. So I'd not expect a chipset nastiness.

Unless people don't report problems with it, because they are so rare that
are regarded as "random" and "unreproducible".

Also, since the layout of devices in the PCI config space seems to matter,
the problem need not appear on other systems with that chipset at all.

> I'd be more wary about the BIOS doing something odd. Or an ACPI thing. 

Well, unlikely, _unless_ Toshiba and HP both use the same Intel reference
BIOS or something.

> > I've already checked the resume ordering of PCI devices on my box and it
> > is the following:
> >   [snip]
> > So, snd_hda_intel resumes before all of the bridges and the layout of devices
> > _behind_ the transparent bridge shouldn't affect it at all.
> 
> Yes. And in the case of Frans' machine, the e1000e controller was before 
> all the bridges too.

Hm.  And unloading it before suspend made things work?  Interesting.

Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

[-- Attachment #1: Type: text/plain, Size: 2336 bytes --]

On Thursday, 4 of December 2008, Linus Torvalds wrote:
> 
> On Thu, 4 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > However, this one appears to work reliably for me (on top of vanilla current
> > mainline):
> 
> Not very interesting. It just does the same thing your previous patches 
> have done - ignores the cardbus slot for sizing. It just does it 
> differently and more explicitly.

There's a difference, though.  It doesn't cause the resources flags to be
cleared for the cardbus bridge and the cardbus bridge gets the correct sizes
of both prefetchable and non-prefetchable windows (64 MB).

> Your original patch did it by simply giving the resources invalid 
> alignments (in a very non-obvious way). This one does it by being explicit 
> and saying "we won't care about cardbus resources behind transparent 
> bridges". But it's still a very hacky thing, and thus not really 
> interesting at all as a patch.
> 
> IOW, it's not a patch that makes sense - it's just a patch that ON YOUR 
> PARTICULAR MACHINE causes us to get the layout you want in order to hide 
> the bug.

I know that. :-)  Still, I find it important to notice that the memory windows
of the cardbus bridge can be 64 MB-wide and things work in that case too.
Also, I like it more than the previous patch. ;-)

Moreover, I _think_ it would work for Frans too, because I _suspect_ the
problem is related to a cardbus bridge being located behind that "transparent"
thing somehow.

> And it doesn't really even do anything new - it's just doing the  
> same thing in an old way.
> 
> But it's interesting that the "don't size _anything_ behind a transparent 
> bridge" apparently made no difference for you.
> 
> Can you send "lspci -vv" and "dmesg" output for that kernel?

No prob, both attached along with the contents of /proc/iomem .

> Even if it failed the suspend/resume, it's interesting, because I would
> actually have expected that one to have the same layout as the successful
> ones. 

Well, not exactly.  Actually, with this patch the graphics and "ICH HD audio"
get their memory ranges before the ranges of _all_ devices behind the
transparent bridge, while in the "working" case their memory ranges are located
_after_ the memory ranges of devices behind the transparent bridge _except_
for the cardbus bridge's memory windows.

Thanks,
Rafael

[-- Attachment #2: dmesg.log --]
[-- Type: text/x-log, Size: 54515 bytes --]

[    0.000000] BIOS EBDA/lowmem at: 0009fc00/0009fc00
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Linux version 2.6.28-rc7-rjw (rafael@chimera) (gcc version 4.2.1 (SUSE Linux)) #57 SMP Thu Dec 4 23:55:55 CET 2008
[    0.000000] Command line: root=/dev/disk/by-id/scsi-SATA_Hitachi_HTS5425080611BB6300ACJRP5TG-part3 edd=off resume=/dev/sda2 vga=0x314
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Centaur CentaurHauls
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[    0.000000]  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e0000 - 00000000000eee00 (reserved)
[    0.000000]  BIOS-e820: 00000000000eee00 - 00000000000ef000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000000ef000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 000000007f750000 (usable)
[    0.000000]  BIOS-e820: 000000007f750000 - 0000000080000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec18000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec20000 - 00000000fec28000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
[    0.000000]  BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
[    0.000000]  BIOS-e820: 00000000feda0000 - 00000000fedc0000 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  BIOS-e820: 00000000ffa00000 - 00000000ffc00000 (reserved)
[    0.000000]  BIOS-e820: 00000000ffd00000 - 0000000100000000 (reserved)
[    0.000000] DMI 2.4 present.
[    0.000000] last_pfn = 0x7f750 max_arch_pfn = 0x3ffffffff
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] init_memory_mapping: 0000000000000000-000000007f750000
[    0.000000]  0000000000 - 007f600000 page 2M
[    0.000000]  007f600000 - 007f750000 page 4k
[    0.000000] kernel direct mapping tables up to 7f750000 @ 8000-c000
[    0.000000] last_map_addr: 7f750000 end: 7f750000
[    0.000000] RAMDISK: 37770000 - 37feff02
[    0.000000] ACPI: RSDP 000F0210, 0014 (r0 TOSHIB)
[    0.000000] ACPI: RSDT 7F750000, 004C (r1 TOSHIB A0058    20070822 TASM  4010000)
[    0.000000] ACPI: FACP 7F750078, 0084 (r2 TOSHIB A0058    20070822 TASM  4010000)
[    0.000000] ACPI: DSDT 7F7500FC, 5CA1 (r2 TOSHIB A0058    20070822 MSFT  100000E)
[    0.000000] ACPI: FACS 000EEE00, 0040
[    0.000000] ACPI: SSDT 7F755D9D, 0306 (r2 TOSHIB A0058    20060907 MSFT  100000E)
[    0.000000] ACPI: BOOT 7F750050, 0028 (r1 TOSHIB A0058    20070822 TASM  4010000)
[    0.000000] ACPI: APIC 7F756955, 0068 (r1 TOSHIB A0058    20070822 TASM  4010000)
[    0.000000] ACPI: MCFG 7F7569BD, 003C (r1 TOSHIB A0058    20070822 TASM  4010000)
[    0.000000] ACPI: HPET 7F756A2D, 0038 (r1 TOSHIB A0058    20070822 TASM  4010000)
[    0.000000] ACPI: TCPA 7F756A65, 0032 (r2 TOSHIB A0058    20070822 TASM  4010000)
[    0.000000] ACPI: SLIC 7F756A97, 0176 (r1 TOSHIB A0058    20070822 TASM  4010000)
[    0.000000] ACPI: SSDT 7F756C0D, 016C (r2 TOSHIB A0058    20070309 MSFT  100000E)
[    0.000000] ACPI: SSDT 7F7576BF, 0081 (r2 TOSHIB A0058    20060907 MSFT  100000E)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] (6 early reservations) ==> bootmem [0000000000 - 007f750000]
[    0.000000]   #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 0000001000]
[    0.000000]   #1 [0000006000 - 0000008000]       TRAMPOLINE ==> [0000006000 - 0000008000]
[    0.000000]   #2 [0000200000 - 0000784d3c]    TEXT DATA BSS ==> [0000200000 - 0000784d3c]
[    0.000000]   #3 [0037770000 - 0037feff02]          RAMDISK ==> [0037770000 - 0037feff02]
[    0.000000]   #4 [000009fc00 - 0000100000]    BIOS reserved ==> [000009fc00 - 0000100000]
[    0.000000]   #5 [0000008000 - 000000a000]          PGTABLE ==> [0000008000 - 000000a000]
[    0.000000]  [ffffe20000000000-ffffe20001bfffff] PMD -> [ffff880001200000-ffff880002dfffff] on node 0
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000000 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x00100000
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[2] active PFN ranges
[    0.000000]     0: 0x00000000 -> 0x0000009f
[    0.000000]     0: 0x00000100 -> 0x0007f750
[    0.000000] On node 0 totalpages: 521967
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 1513 pages reserved
[    0.000000]   DMA zone: 2430 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 7082 pages used for memmap
[    0.000000]   DMA32 zone: 510886 pages, LIFO batch:31
[    0.000000]   Normal zone: 0 pages used for memmap
[    0.000000]   Movable zone: 0 pages used for memmap
[    0.000000] ACPI: PM-Timer IO Port: 0xd808
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 0, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] SMP: Allowing 2 CPUs, 0 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
[    0.000000] PM: Registered nosave memory: 00000000000e0000 - 00000000000ee000
[    0.000000] PM: Registered nosave memory: 00000000000ee000 - 00000000000ef000
[    0.000000] PM: Registered nosave memory: 00000000000ef000 - 0000000000100000
[    0.000000] Allocating PCI resources starting at 88000000 (gap: 80000000:7ec00000)
[    0.000000] PERCPU: Allocating 45056 bytes of per cpu data
[    0.000000] NR_CPUS: 2, nr_cpu_ids: 2, nr_node_ids 1
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 513316
[    0.000000] Kernel command line: root=/dev/disk/by-id/scsi-SATA_Hitachi_HTS5425080611BB6300ACJRP5TG-part3 edd=off resume=/dev/sda2 vga=0x314
[    0.000000] Initializing CPU#0
[    0.000000] RCU-based detection of stalled CPUs is enabled.
[    0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes)
[    0.000000] Fast TSC calibration using PIT
[    0.000000] Detected 1330.112 MHz processor.
[    0.004000] Console: colour dummy device 80x25
[    0.004000] console [tty0] enabled
[    0.004000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.004000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.004000] Checking aperture...
[    0.004000] No AGP bridge found
[    0.004000] Memory: 2040900k/2088256k available (2369k kernel code, 388k absent, 46340k reserved, 1741k data, 356k init)
[    0.004000] hpet clockevent registered
[    0.004000] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
[    0.004000] Calibrating delay loop (skipped), value calculated using timer frequency.. 2660.22 BogoMIPS (lpj=5320448)
[    0.004000] Security Framework initialized
[    0.004000] Mount-cache hash table entries: 256
[    0.004000] CPU: L1 I cache: 32K, L1 D cache: 32K
[    0.004000] CPU: L2 cache: 2048K
[    0.004000] CPU: Physical Processor ID: 0
[    0.004000] CPU: Processor Core ID: 0
[    0.004000] CPU0: Thermal monitoring handled by SMI
[    0.004000] using mwait in idle threads.
[    0.004000] ACPI: Core revision 20080926
[    0.014425] Setting APIC routing to flat
[    0.014850] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[    0.054558] CPU0: Intel(R) Core(TM)2 Duo CPU     U7700  @ 1.33GHz stepping 0d
[    0.056001] Booting processor 1 APIC 0x1 ip 0x6000
[    0.004000] Initializing CPU#1
[    0.004000] Calibrating delay using timer specific routine.. 2659.97 BogoMIPS (lpj=5319951)
[    0.004000] CPU: L1 I cache: 32K, L1 D cache: 32K
[    0.004000] CPU: L2 cache: 2048K
[    0.004000] CPU: Physical Processor ID: 0
[    0.004000] CPU: Processor Core ID: 1
[    0.004000] CPU1: Thermal monitoring enabled (TM2)
[    0.004000] x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
[    0.141643] CPU1: Intel(R) Core(TM)2 Duo CPU     U7700  @ 1.33GHz stepping 0d
[    0.141709] checking TSC synchronization [CPU#0 -> CPU#1]: passed.
[    0.144033] Brought up 2 CPUs
[    0.144040] Total of 2 processors activated (5320.19 BogoMIPS).
[    0.144103] CPU0 attaching sched-domain:
[    0.144107]  domain 0: span 0-1 level MC
[    0.144111]   groups: 0 1
[    0.144119] CPU1 attaching sched-domain:
[    0.144121]  domain 0: span 0-1 level MC
[    0.144124]   groups: 1 0
[    0.144213] net_namespace: 1376 bytes
[    0.144297] Time: 23:00:06  Date: 12/04/08
[    0.144297] NET: Registered protocol family 16
[    0.144297] ACPI: bus type pci registered
[    0.144297] PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 63
[    0.144297] PCI: Not using MMCONFIG.
[    0.144297] PCI: Using configuration type 1 for base access
[    0.149237] ACPI: EC: Look up EC in DSDT
[    0.154570] ACPI Warning (dsobject-0501): Package List length (C) larger than NumElements count (3), truncated
[    0.154584]  [20080926]
[    0.158240] ACPI: Interpreter enabled
[    0.158247] ACPI: (supports S0 S3 S4 S5)
[    0.158286] ACPI: Using IOAPIC for interrupt routing
[    0.158371] PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 63
[    0.163833] PCI: MCFG area at f0000000 reserved in ACPI motherboard resources
[    0.168551] PCI: Using MMCONFIG at f0000000 - f3ffffff
[    0.181279] ACPI: ACPI Dock Station Driver: 1 docks/bays found
[    0.181308] ACPI: PCI Root Bridge [PCI0] (0000:00)
[    0.181353] pci 0000:00:02.0: reg 10 32bit mmio: [0xffc80000-0xffcfffff]
[    0.181353] pci 0000:00:02.0: reg 14 io port: [0xcff8-0xcfff]
[    0.181353] pci 0000:00:02.0: reg 18 32bit mmio: [0xe0000000-0xefffffff]
[    0.181353] pci 0000:00:02.0: reg 1c 32bit mmio: [0xffc40000-0xffc7ffff]
[    0.181353] pci 0000:00:02.1: reg 10 32bit mmio: [0x000000-0x07ffff]
[    0.181353] pci 0000:00:1b.0: reg 10 64bit mmio: [0x000000-0x003fff]
[    0.181353] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
[    0.181353] pci 0000:00:1b.0: PME# disabled
[    0.181353] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    0.181353] pci 0000:00:1c.0: PME# disabled
[    0.181353] pci 0000:00:1c.2: PME# supported from D0 D3hot D3cold
[    0.181353] pci 0000:00:1c.2: PME# disabled
[    0.181353] pci 0000:00:1d.0: reg 20 io port: [0xafe0-0xafff]
[    0.181353] pci 0000:00:1d.1: reg 20 io port: [0xaf80-0xaf9f]
[    0.181353] pci 0000:00:1d.2: reg 20 io port: [0xaf60-0xaf7f]
[    0.181353] pci 0000:00:1d.3: reg 20 io port: [0xaf40-0xaf5f]
[    0.181353] pci 0000:00:1d.7: reg 10 32bit mmio: [0xffc3fc00-0xffc3ffff]
[    0.181353] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
[    0.181353] pci 0000:00:1d.7: PME# disabled
[    0.181353] pci 0000:00:1f.0: quirk: region d800-d87f claimed by ICH6 ACPI/GPIO/TCO
[    0.181353] pci 0000:00:1f.0: quirk: region eec0-eeff claimed by ICH6 GPIO
[    0.181353] pci 0000:00:1f.2: reg 10 io port: [0xaf38-0xaf3f]
[    0.181353] pci 0000:00:1f.2: reg 14 io port: [0xaf34-0xaf37]
[    0.181353] pci 0000:00:1f.2: reg 18 io port: [0xaf28-0xaf2f]
[    0.181356] pci 0000:00:1f.2: reg 1c io port: [0xaf24-0xaf27]
[    0.181366] pci 0000:00:1f.2: reg 20 io port: [0xaf10-0xaf1f]
[    0.181377] pci 0000:00:1f.2: reg 24 32bit mmio: [0xffc3f800-0xffc3fbff]
[    0.181402] pci 0000:00:1f.2: PME# supported from D3hot
[    0.181411] pci 0000:00:1f.2: PME# disabled
[    0.181523] pci 0000:01:00.0: reg 10 32bit mmio: [0xff9e0000-0xff9fffff]
[    0.181551] pci 0000:01:00.0: reg 18 io port: [0xbfe0-0xbfff]
[    0.181623] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[    0.181636] pci 0000:01:00.0: PME# disabled
[    0.181696] pci 0000:01:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    0.181766] pci 0000:00:1c.0: bridge io port: [0xb000-0xbfff]
[    0.181772] pci 0000:00:1c.0: bridge 32bit mmio: [0xff900000-0xff9fffff]
[    0.181942] pci 0000:02:00.0: reg 10 64bit mmio: [0xff8fe000-0xff8fffff]
[    0.182062] pci 0000:02:00.0: PME# supported from D0 D3hot D3cold
[    0.182093] pci 0000:02:00.0: PME# disabled
[    0.182550] pci 0000:00:1c.2: bridge 32bit mmio: [0xff800000-0xff8fffff]
[    0.184005] pci 0000:03:0b.0: reg 10 32bit mmio: [0x000000-0x000fff]
[    0.184020] pci 0000:03:0b.0: supports D1 D2
[    0.184023] pci 0000:03:0b.0: PME# supported from D0 D1 D2 D3hot
[    0.184033] pci 0000:03:0b.0: PME# disabled
[    0.184087] pci 0000:03:0b.1: reg 10 32bit mmio: [0x000000-0x0007ff]
[    0.184098] pci 0000:03:0b.1: reg 14 32bit mmio: [0x000000-0x003fff]
[    0.184149] pci 0000:03:0b.1: supports D1 D2
[    0.184152] pci 0000:03:0b.1: PME# supported from D0 D1 D2 D3hot
[    0.184162] pci 0000:03:0b.1: PME# disabled
[    0.184217] pci 0000:03:0b.3: reg 10 32bit mmio: [0x000000-0x0000ff]
[    0.184276] pci 0000:03:0b.3: supports D1 D2
[    0.184279] pci 0000:03:0b.3: PME# supported from D0 D1 D2 D3hot
[    0.184289] pci 0000:03:0b.3: PME# disabled
[    0.184346] pci 0000:00:1e.0: transparent bridge
[    0.184415] bus 00 -> node 0
[    0.184425] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[    0.184750] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT]
[    0.185003] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX1._PRT]
[    0.185223] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MPEX._PRT]
[    0.188573] ACPI: PCI Interrupt Link [LNKA] (IRQs *10)
[    0.192116] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *11)
[    0.192410] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *11)
[    0.192699] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *11)
[    0.192987] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 *11)
[    0.193274] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *11)
[    0.193562] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *11)
[    0.193850] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 *11)
[    0.193948] SCSI subsystem initialized
[    0.193948] PCI: Using ACPI for IRQ routing
[    0.208013] NetLabel: Initializing
[    0.208019] NetLabel:  domain hash size = 128
[    0.208024] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.208058] NetLabel:  unlabeled traffic allowed by default
[    0.208090] PCI-GART: No AMD GART found.
[    0.208105] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[    0.208115] hpet0: 3 comparators, 64-bit 14.318180 MHz counter
[    0.228011] pnp: PnP ACPI init
[    0.228028] ACPI: bus type pnp registered
[    0.235698] pnp: PnP ACPI: found 12 devices
[    0.235706] ACPI: ACPI bus type pnp unregistered
[    0.235724] system 00:00: iomem range 0x0-0x9ffff could not be reserved
[    0.235732] system 00:00: iomem range 0xe0000-0xfffff could not be reserved
[    0.235741] system 00:00: iomem range 0x100000-0x7f74ffff could not be reserved
[    0.235750] system 00:00: iomem range 0x7f750000-0x7f75ffff has been reserved
[    0.235758] system 00:00: iomem range 0x7f760000-0x7f7fffff has been reserved
[    0.235766] system 00:00: iomem range 0x7f800000-0x7fffffff has been reserved
[    0.235774] system 00:00: iomem range 0xfec00000-0xfec17fff has been reserved
[    0.235783] system 00:00: iomem range 0xfec20000-0xfec27fff has been reserved
[    0.235791] system 00:00: iomem range 0xfed14000-0xfed19fff has been reserved
[    0.235799] system 00:00: iomem range 0xfed1c000-0xfed1ffff has been reserved
[    0.235807] system 00:00: iomem range 0xfed20000-0xfed3ffff has been reserved
[    0.235815] system 00:00: iomem range 0xfed45000-0xfed8ffff has been reserved
[    0.235823] system 00:00: iomem range 0xfeda0000-0xfedbffff has been reserved
[    0.235831] system 00:00: iomem range 0xfee00000-0xfee00fff has been reserved
[    0.235839] system 00:00: iomem range 0xffa00000-0xffbfffff has been reserved
[    0.235848] system 00:00: iomem range 0xffd00000-0xffffffff has been reserved
[    0.235860] system 00:01: iomem range 0xf0000000-0xf3ffffff has been reserved
[    0.235876] system 00:09: ioport range 0x1e0-0x1ef has been reserved
[    0.235884] system 00:09: ioport range 0x480-0x48f has been reserved
[    0.235891] system 00:09: ioport range 0xe000-0xe07f has been reserved
[    0.235899] system 00:09: ioport range 0xe080-0xe0ff has been reserved
[    0.235907] system 00:09: ioport range 0xe400-0xe47f has been reserved
[    0.235914] system 00:09: ioport range 0xe480-0xe4ff has been reserved
[    0.235922] system 00:09: ioport range 0xe800-0xe87f has been reserved
[    0.235930] system 00:09: ioport range 0xe880-0xe8ff has been reserved
[    0.235937] system 00:09: ioport range 0xec00-0xec7f has been reserved
[    0.235945] system 00:09: ioport range 0xec80-0xecff has been reserved
[    0.235953] system 00:09: ioport range 0xd800-0xd87f has been reserved
[    0.235960] system 00:09: ioport range 0xd880-0xd89f has been reserved
[    0.235968] system 00:09: ioport range 0xeeb0-0xeebf has been reserved
[    0.235976] system 00:09: ioport range 0xeec0-0xeeff has been reserved
[    0.235984] system 00:09: ioport range 0x690-0x6ff has been reserved
[    0.235994] system 00:09: ioport range 0x4d0-0x4d1 has been reserved
[    0.241200] pci 0000:00:1c.0: PCI bridge, secondary bus 0000:01
[    0.241210] pci 0000:00:1c.0:   IO window: 0xb000-0xbfff
[    0.241221] pci 0000:00:1c.0:   MEM window: 0xff900000-0xff9fffff
[    0.241231] pci 0000:00:1c.0:   PREFETCH window: disabled
[    0.241245] pci 0000:00:1c.2: PCI bridge, secondary bus 0000:02
[    0.241251] pci 0000:00:1c.2:   IO window: disabled
[    0.241262] pci 0000:00:1c.2:   MEM window: 0xff800000-0xff8fffff
[    0.241272] pci 0000:00:1c.2:   PREFETCH window: disabled
[    0.241307] pci 0000:03:0b.0: CardBus bridge, secondary bus 0000:04
[    0.241314] pci 0000:03:0b.0:   IO window: 0x001000-0x0010ff
[    0.241324] pci 0000:03:0b.0:   IO window: 0x001400-0x0014ff
[    0.241333] pci 0000:03:0b.0:   PREFETCH window: 0x8c000000-0x8fffffff
[    0.241344] pci 0000:03:0b.0:   MEM window: 0x90000000-0x93ffffff
[    0.241354] pci 0000:00:1e.0: PCI bridge, secondary bus 0000:03
[    0.241360] pci 0000:00:1e.0:   IO window: disabled
[    0.241371] pci 0000:00:1e.0:   MEM window: disabled
[    0.241380] pci 0000:00:1e.0:   PREFETCH window: disabled
[    0.241406] pci 0000:00:1c.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[    0.241418] pci 0000:00:1c.0: setting latency timer to 64
[    0.241430] pci 0000:00:1c.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[    0.241441] pci 0000:00:1c.2: setting latency timer to 64
[    0.241451] pci 0000:00:1e.0: setting latency timer to 64
[    0.241462] pci 0000:03:0b.0: enabling device (0000 -> 0003)
[    0.241472] pci 0000:03:0b.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
[    0.241485] bus: 00 index 0 io port: [0x00-0xffff]
[    0.241492] bus: 00 index 1 mmio: [0x000000-0xffffffffffffffff]
[    0.241499] bus: 01 index 0 io port: [0xb000-0xbfff]
[    0.241505] bus: 01 index 1 mmio: [0xff900000-0xff9fffff]
[    0.241511] bus: 01 index 2 mmio: [0x0-0x0]
[    0.241516] bus: 01 index 3 mmio: [0x0-0x0]
[    0.241521] bus: 02 index 0 mmio: [0x0-0x0]
[    0.241527] bus: 02 index 1 mmio: [0xff800000-0xff8fffff]
[    0.241533] bus: 02 index 2 mmio: [0x0-0x0]
[    0.241538] bus: 02 index 3 mmio: [0x0-0x0]
[    0.241543] bus: 03 index 0 mmio: [0x0-0x0]
[    0.241548] bus: 03 index 1 mmio: [0x0-0x0]
[    0.241553] bus: 03 index 2 mmio: [0x0-0x0]
[    0.241558] bus: 03 index 3 io port: [0x00-0xffff]
[    0.241564] bus: 03 index 4 mmio: [0x000000-0xffffffffffffffff]
[    0.241571] bus: 04 index 0 io port: [0x1000-0x10ff]
[    0.241577] bus: 04 index 1 io port: [0x1400-0x14ff]
[    0.241583] bus: 04 index 2 mmio: [0x8c000000-0x8fffffff]
[    0.241589] bus: 04 index 3 mmio: [0x90000000-0x93ffffff]
[    0.241632] NET: Registered protocol family 2
[    0.280082] IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
[    0.280646] TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
[    0.283847] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.284834] TCP: Hash tables configured (established 262144 bind 65536)
[    0.284843] TCP reno registered
[    0.296131] NET: Registered protocol family 1
[    0.296308] checking if image is initramfs...<7>Switched to high resolution mode on CPU 1
[    0.503972] Switched to high resolution mode on CPU 0
[    0.783076]  it is
[    1.298597] Freeing initrd memory: 8703k freed
[    1.305128] Simple Boot Flag value 0xb read from CMOS RAM was invalid
[    1.305142] Simple Boot Flag at 0x7c set to 0x1
[    1.306461] audit: initializing netlink socket (disabled)
[    1.306491] type=2000 audit(1228431607.305:1): initialized
[    1.306856] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    1.307036] VFS: Disk quotas dquot_6.5.1
[    1.307086] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.307189] msgmni has been set to 4004
[    1.307464] alg: No test for stdrng (krng)
[    1.307481] io scheduler noop registered
[    1.307488] io scheduler anticipatory registered
[    1.307494] io scheduler deadline registered
[    1.307518] io scheduler cfq registered (default)
[    1.308057] pci 0000:00:02.0: Boot video device
[    1.313171] pcieport-driver 0000:00:1c.0: setting latency timer to 64
[    1.313229] pcieport-driver 0000:00:1c.0: found MSI capability
[    1.313280] pcieport-driver 0000:00:1c.0: irq 319 for MSI/MSI-X
[    1.313301] pci_express 0000:00:1c.0:pcie00: allocate port service
[    1.313360] pci_express 0000:00:1c.0:pcie03: allocate port service
[    1.313589] pcieport-driver 0000:00:1c.2: setting latency timer to 64
[    1.313647] pcieport-driver 0000:00:1c.2: found MSI capability
[    1.313799] pcieport-driver 0000:00:1c.2: irq 318 for MSI/MSI-X
[    1.313819] pci_express 0000:00:1c.2:pcie00: allocate port service
[    1.313874] pci_express 0000:00:1c.2:pcie03: allocate port service
[    1.314399] vesafb: framebuffer at 0xe0000000, mapped to 0xffffc20004100000, using 1875k, total 7872k
[    1.314410] vesafb: mode is 800x600x16, linelength=1600, pages=7
[    1.314416] vesafb: scrolling: redraw
[    1.314422] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
[    1.327854] Console: switching to colour frame buffer device 100x37
[    1.338710] fb0: VESA VGA frame buffer device
[    1.353232] Non-volatile memory driver v1.2
[    1.353428] Linux agpgart interface v0.103
[    1.353588] Serial: 8250/16550 driver4 ports, IRQ sharing disabled
[    1.356635] brd: module loaded
[    1.356889] PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    1.362155] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.364006] serio: i8042 AUX port at 0x60,0x64 irq 12
[    1.365933] mice: PS/2 mouse device common for all mice
[    1.367995] input: PC Speaker as /class/input/input0
[    1.378485] input: AT Translated Set 2 keyboard as /class/input/input1
[    1.397117] cpuidle: using governor ladder
[    1.399494] cpuidle: using governor menu
[    1.402721] registered taskstats version 1
[    1.405441]   Magic number: 4:738:48
[    1.408226] Freeing unused kernel memory: 356k freed
[    1.411246] Write protecting the kernel read-only data: 3820k
[    1.471233] ACPI: SSDT 7F7563E5, 00F3 (r2 TOSHIB A0058    20060907 MSFT  100000E)
[    1.475513] ACPI: SSDT 7F75654E, 034E (r2 TOSHIB A0058    20060907 MSFT  100000E)
[    1.479893] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
[    1.483809] processor ACPI_CPU:00: registered as cooling_device0
[    1.488084] ACPI: SSDT 7F7564D8, 0076 (r2 TOSHIB A0058    20060907 MSFT  100000E)
[    1.492875] ACPI: SSDT 7F75689C, 0079 (r2 TOSHIB A0058    20060907 MSFT  100000E)
[    1.497917] ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3])
[    1.502467] processor ACPI_CPU:01: registered as cooling_device1
[    1.506447] Marking TSC unstable due to TSC halts in idle
[    1.516663] thermal LNXTHERM:01: registered as thermal_zone0
[    1.521930] ACPI: Thermal Zone [THRM] (66 C)
[    1.547500] libata version 3.00 loaded.
[    1.552220] ahci 0000:00:1f.2: version 3.0
[    1.552249] ahci 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[    1.557597] ahci 0000:00:1f.2: irq 317 for MSI/MSI-X
[    1.557685] ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 1.5 Gbps 0x1 impl SATA mode
[    1.562910] ahci 0000:00:1f.2: flags: 64bit ncq pm led clo pio slum part 
[    1.568215] ahci 0000:00:1f.2: setting latency timer to 64
[    1.568408] scsi0 : ahci
[    1.573773] scsi1 : ahci
[    1.578904] scsi2 : ahci
[    1.583949] scsi3 : ahci
[    1.589196] ata1: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 317
[    1.594142] ata2: DUMMY
[    1.599067] ata3: DUMMY
[    1.603817] ata4: DUMMY
[    2.000172] Clocksource tsc unstable (delta = -385447840 ns)
[    2.332153] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    2.337822] ACPI Error (nspredef-0163): \_SB_.PCI0.FNC2.PRT0._GTF: Missing expected return value [20080926]
[    2.348206] ata1.00: ATA-8: Hitachi HTS542516K9SA00, BBCOC33P, max UDMA/133
[    2.353573] ata1.00: 312581808 sectors, multi 0: LBA48 NCQ (depth 31/32)
[    2.360202] ata1.00: configured for UDMA/133
[    2.380464] scsi 0:0:0:0: Direct-Access     ATA      Hitachi HTS54251 BBCO PQ: 0 ANSI: 5
[    2.414442] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[    2.419900] EDD information not available.
[    2.725174] usbcore: registered new interface driver usbfs
[    2.731201] usbcore: registered new interface driver hub
[    2.733432] Driver 'sd' needs updating - please use bus_type methods
[    2.733590] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors: (160 GB/149 GiB)
[    2.733614] sd 0:0:0:0: [sda] Write Protect is off
[    2.733618] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    2.733656] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.733749] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors: (160 GB/149 GiB)
[    2.733771] sd 0:0:0:0: [sda] Write Protect is off
[    2.733774] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    2.733812] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.733816]  sda: sda1 sda2 sda3 sda4 < sda5<6>usbcore: registered new device driver usb
[    2.799812] uhci_hcd: USB Universal Host Controller Interface driver
[    2.803584] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    2.803642] ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[    2.819116] ehci_hcd 0000:00:1d.7: setting latency timer to 64
[    2.819122] ehci_hcd 0000:00:1d.7: EHCI Host Controller
[    2.825507]  sda6<6>ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
[    2.839762] ehci_hcd 0000:00:1d.7: debug port 1
[    2.846456] ehci_hcd 0000:00:1d.7: cache line size of 32 is not supported
[    2.846479]  sda7 >
[    2.853306] sd 0:0:0:0: [sda] Attached SCSI disk
[    2.860085] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xffc3fc00
[    2.884044] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
[    2.890788] usb usb1: configuration #1 chosen from 1 choice
[    2.897207] hub 1-0:1.0: USB hub found
[    2.903664] hub 1-0:1.0: 8 ports detected
[    2.909999] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    2.916314] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.922437] usb usb1: Product: EHCI Host Controller
[    2.928492] usb usb1: Manufacturer: Linux 2.6.28-rc7-rjw ehci_hcd
[    2.928494] usb usb1: SerialNumber: 0000:00:1d.7
[    2.932071] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[    2.932085] uhci_hcd 0000:00:1d.0: setting latency timer to 64
[    2.932090] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[    2.932141] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
[    2.932182] uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000afe0
[    2.932339] usb usb2: configuration #1 chosen from 1 choice
[    2.932386] hub 2-0:1.0: USB hub found
[    2.932395] hub 2-0:1.0: 2 ports detected
[    2.932533] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
[    2.932536] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.932539] usb usb2: Product: UHCI Host Controller
[    2.932541] usb usb2: Manufacturer: Linux 2.6.28-rc7-rjw uhci_hcd
[    2.932543] usb usb2: SerialNumber: 0000:00:1d.0
[    2.932574] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[    2.932582] uhci_hcd 0000:00:1d.1: setting latency timer to 64
[    2.932586] uhci_hcd 0000:00:1d.1: UHCI Host Controller
[    2.932619] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
[    2.932670] uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000af80
[    2.932788] usb usb3: configuration #1 chosen from 1 choice
[    2.932828] hub 3-0:1.0: USB hub found
[    2.932837] hub 3-0:1.0: 2 ports detected
[    2.932968] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
[    2.932971] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.932974] usb usb3: Product: UHCI Host Controller
[    2.932976] usb usb3: Manufacturer: Linux 2.6.28-rc7-rjw uhci_hcd
[    2.932978] usb usb3: SerialNumber: 0000:00:1d.1
[    2.933005] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[    2.933013] uhci_hcd 0000:00:1d.2: setting latency timer to 64
[    2.933017] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[    2.933049] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
[    2.933092] uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000af60
[    2.933212] usb usb4: configuration #1 chosen from 1 choice
[    2.933252] hub 4-0:1.0: USB hub found
[    2.933261] hub 4-0:1.0: 2 ports detected
[    2.933391] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
[    2.933394] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.933397] usb usb4: Product: UHCI Host Controller
[    2.933399] usb usb4: Manufacturer: Linux 2.6.28-rc7-rjw uhci_hcd
[    2.933401] usb usb4: SerialNumber: 0000:00:1d.2
[    2.933432] uhci_hcd 0000:00:1d.3: PCI INT D -> GSI 16 (level, low) -> IRQ 16
[    2.933440] uhci_hcd 0000:00:1d.3: setting latency timer to 64
[    2.933444] uhci_hcd 0000:00:1d.3: UHCI Host Controller
[    2.933483] uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
[    2.933526] uhci_hcd 0000:00:1d.3: irq 16, io base 0x0000af40
[    2.933641] usb usb5: configuration #1 chosen from 1 choice
[    2.933685] hub 5-0:1.0: USB hub found
[    2.933693] hub 5-0:1.0: 2 ports detected
[    2.933829] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
[    2.933832] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.933835] usb usb5: Product: UHCI Host Controller
[    2.933837] usb usb5: Manufacturer: Linux 2.6.28-rc7-rjw uhci_hcd
[    2.933839] usb usb5: SerialNumber: 0000:00:1d.3
[    3.461236] PM: Starting manual resume from disk
[    3.628069] usb 1-4: new high speed USB device using ehci_hcd and address 4
[    3.766296] usb 1-4: configuration #1 chosen from 1 choice
[    3.774690] usb 1-4: New USB device found, idVendor=0930, idProduct=0c05
[    3.781178] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    3.787119] usb 1-4: Product: Optical Drive Controller
[    3.792932] usb 1-4: Manufacturer: TOSHIBA
[    3.855769] kjournald starting.  Commit interval 5 seconds
[    3.862448] EXT3 FS on sda3, internal journal
[    3.868884] EXT3-fs: mounted filesystem with ordered data mode.
[    4.148124] usb 2-2: new full speed USB device using uhci_hcd and address 2
[    4.317422] usb 2-2: configuration #1 chosen from 1 choice
[    4.335436] usb 2-2: New USB device found, idVendor=0930, idProduct=1302
[    4.342122] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=2
[    4.348852] usb 2-2: Product: Novatel Wireless HSDPA Modem
[    4.355510] usb 2-2: Manufacturer: Novatel Wireless
[    4.362125] usb 2-2: SerialNumber: Novatel Wireless HSDPA Modem
[    4.608065] usb 3-1: new full speed USB device using uhci_hcd and address 2
[    4.777838] usb 3-1: configuration #1 chosen from 1 choice
[    4.786985] usb 3-1: New USB device found, idVendor=08ff, idProduct=1600
[    4.793693] usb 3-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    4.800401] usb 3-1: Product: Fingerprint Sensor
[    5.044063] usb 4-1: new full speed USB device using uhci_hcd and address 2
[    5.225297] usb 4-1: configuration #1 chosen from 1 choice
[    5.237431] usb 4-1: New USB device found, idVendor=046d, idProduct=c526
[    5.243894] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    5.250257] usb 4-1: Product: USB Receiver
[    5.256375] usb 4-1: Manufacturer: Logitech
[    6.910048] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    7.086238] iTCO_vendor_support: vendor-support=0
[    7.221463] ACPI Warning (nspredef-0858): \_SB_.BAT1._BIF: Return Package type mismatch at index 12 - found Integer, expected String/Buffer [20080926]
[    7.233732] ACPI: Battery Slot [BAT1] (battery present)
[    7.241393] input: Power Button (FF) as /class/input/input2
[    7.261012] ACPI: AC Adapter [ADP1] (on-line)
[    7.284152] ACPI: Power Button (FF) [PWRF]
[    7.290161] input: Lid Switch as /class/input/input3
[    7.308268] ACPI: Lid Switch [LID]
[    7.314191] input: Power Button (CM) as /class/input/input4
[    7.330658] e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k6
[    7.336353] e1000e: Copyright (c) 1999-2008 Intel Corporation.
[    7.342666] e1000e 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    7.348572] e1000e 0000:01:00.0: setting latency timer to 64
[    7.348871] e1000e 0000:01:00.0: irq 316 for MSI/MSI-X
[    7.369154] ACPI: Power Button (CM) [PWRB]
[    7.380199] cfg80211: Calling CRDA to update world regulatory domain
[    7.409338] e1000e 0000:01:00.0: Warning: detected ASPM enabled in EEPROM
[    7.472822] 0000:01:00.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:1c:7e:af:dd:ac
[    7.478447] 0000:01:00.0: eth0: Intel(R) PRO/1000 Network Connection
[    7.484235] 0000:01:00.0: eth0: MAC: 2, PHY: 2, PBA No: ffffff-0ff
[    7.509464] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.04
[    7.515348] iTCO_wdt: Found a ICH7-M or ICH7-U TCO device (Version=2, TCOBASE=0xd860)
[    7.521224] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[    7.531674] agpgart-intel 0000:00:00.0: Intel 945GM Chipset
[    7.538278] agpgart-intel 0000:00:00.0: detected 7932K stolen memory
[    7.547561] agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xe0000000
[    7.700568] Initializing USB Mass Storage driver...
[    7.708456] scsi4 : SCSI emulation for USB Mass Storage devices
[    7.714637] usbcore: registered new interface driver usb-storage
[    7.720799] USB Mass Storage support registered.
[    7.720975] usb-storage: device found at 4
[    7.720977] usb-storage: waiting for device to settle before scanning
[    7.726997] input: PS/2 Mouse as /class/input/input5
[    7.795742] input: AlpsPS/2 ALPS GlidePoint as /class/input/input6
[    7.925834] rtc_cmos 00:08: RTC can wake from S4
[    7.931808] rtc_cmos 00:08: rtc core: registered rtc_cmos as rtc0
[    7.938495] rtc0: alarms up to one year, 114 bytes nvram, hpet irqs
[    8.748797] yenta_cardbus 0000:03:0b.0: CardBus bridge found [1179:0001]
[    8.754473] yenta_cardbus 0000:03:0b.0: Enabling burst memory read transactions
[    8.760298] yenta_cardbus 0000:03:0b.0: Using CSCINT to route CSC interrupts to PCI
[    8.765927] yenta_cardbus 0000:03:0b.0: Routing CardBus interrupts to PCI
[    8.771566] yenta_cardbus 0000:03:0b.0: TI: mfunc 0x01aa1022, devctl 0x64
[    8.794719] usbcore: registered new interface driver hiddev
[    8.803607] input: Logitech USB Receiver as /class/input/input7
[    8.840166] generic-usb 0003:046D:C526.0001: input,hidraw0: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:1d.2-1/input0
[    8.857322] input: Logitech USB Receiver as /class/input/input8
[    8.885028] acpi device:0a: registered as cooling_device2
[    8.891840] input: Video Bus as /class/input/input9
[    8.900251] generic-usb 0003:046D:C526.0002: input,hiddev0,hidraw1: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:1d.2-1/input1
[    8.912591] usbcore: registered new interface driver usbhid
[    8.918943] usbhid: v2.6:USB HID core driver
[    8.946265] sdhci: Secure Digital Host Controller Interface driver
[    8.952289] sdhci: Copyright(c) Pierre Ossman
[    8.952425] ACPI: Video Device [VGA] (multi-head: yes  rom: yes  post: no)
[    9.032874] yenta_cardbus 0000:03:0b.0: ISA IRQ mask 0x0cf8, PCI irq 21
[    9.039193] yenta_cardbus 0000:03:0b.0: Socket status: 30000006
[    9.045169] pci_bus 0000:03: Raising subordinate bus# of parent bus (#03) from #04 to #07
[    9.065819] firewire_ohci 0000:03:0b.1: enabling device (0000 -> 0002)
[    9.072353] firewire_ohci 0000:03:0b.1: PCI INT B -> GSI 20 (level, low) -> IRQ 20
[    9.152069] firewire_ohci: Added fw-ohci device 0000:03:0b.1, OHCI version 1.10
[    9.158403] sdhci-pci 0000:03:0b.3: SDHCI controller found [104c:803c] (rev 0)
[    9.164857] sdhci-pci 0000:03:0b.3: enabling device (0000 -> 0002)
[    9.171094] sdhci-pci 0000:03:0b.3: PCI INT D -> GSI 23 (level, low) -> IRQ 23
[    9.172574] toshiba_acpi: Toshiba Laptop ACPI Extras version 0.19
[    9.172577] toshiba_acpi:     HCI method: \_SB_.VALZ.GHCI
[    9.187726] input: Toshiba RFKill Switch as /class/input/input10
[    9.218430] mmc0: SDHCI controller on PCI [0000:03:0b.3] using DMA
[    9.551971] HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
[    9.558305] HDA Intel 0000:00:1b.0: enabling device (0000 -> 0002)
[    9.564851] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[    9.571358] HDA Intel 0000:00:1b.0: setting latency timer to 64
[    9.656214] firewire_core: created device fw0: GUID 0000390000be012e, S400
[    9.680080] usb 5-2: new full speed USB device using uhci_hcd and address 2
[    9.872681] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks
[    9.878934] iwlagn: Copyright(c) 2003-2008 Intel Corporation
[    9.879130] usb 5-2: configuration #1 chosen from 1 choice
[    9.891964] iwlagn 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[    9.892354] usb 5-2: New USB device found, idVendor=0930, idProduct=0508
[    9.892358] usb 5-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    9.911106] iwlagn 0000:02:00.0: setting latency timer to 64
[    9.914819] iwlagn: Detected Intel Wireless WiFi Link 4965AGN REV=0x4
[    9.971524] iwlagn: Tunable channels: 13 802.11bg, 19 802.11a channels
[    9.977853] iwlagn 0000:02:00.0: PCI INT A disabled
[    9.984485] phy0: Selected rate control algorithm 'iwl-agn-rs'
[   10.249982] Bluetooth: Core ver 2.13
[   10.258034] NET: Registered protocol family 31
[   10.263837] Bluetooth: HCI device and connection manager initialized
[   10.269873] Bluetooth: HCI socket layer initialized
[   10.578379] Bluetooth: Generic Bluetooth USB driver ver 0.3
[   10.584301] usbcore: registered new interface driver btusb
[   11.520616] Bluetooth: L2CAP ver 2.11
[   11.526480] Bluetooth: L2CAP socket layer initialized
[   11.563289] Bluetooth: RFCOMM socket layer initialized
[   11.569021] Bluetooth: RFCOMM TTY layer initialized
[   11.574616] Bluetooth: RFCOMM ver 1.10
[   11.674873] Adding 4200988k swap on /dev/sda2.  Priority:-1 extents:1 across:4200988k
[   12.716152] isa bounce pool size: 16 pages
[   12.722950] scsi 4:0:0:0: CD-ROM            MATSHITA DVD-RAM UJ-844S  1.10 PQ: 0 ANSI: 0
[   12.729928] scsi 4:0:0:0: Attached scsi generic sg1 type 5
[   12.743701] usb-storage: device scan complete
[   12.808924] Driver 'sr' needs updating - please use bus_type methods
[   12.822035] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
[   12.828086] Uniform CD-ROM driver Revision: 3.20
[   12.834121] sr 4:0:0:0: Attached scsi CD-ROM sr0
[   13.531610] device-mapper: uevent: version 1.0.3
[   13.538112] device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com
[   15.022438] loop: module loaded
[   15.066028] kjournald starting.  Commit interval 5 seconds
[   15.066299] EXT3 FS on sda7, internal journal
[   15.066306] EXT3-fs: mounted filesystem with ordered data mode.
[   15.111438] kjournald starting.  Commit interval 5 seconds
[   15.111703] EXT3 FS on sda6, internal journal
[   15.111708] EXT3-fs: mounted filesystem with ordered data mode.
[   15.179126] kjournald starting.  Commit interval 5 seconds
[   15.179408] EXT3 FS on sda5, internal journal
[   15.179413] EXT3-fs: mounted filesystem with ordered data mode.
[   15.373458] fuse init (API version 7.10)
[   19.313397] platform microcode: firmware: requesting intel-ucode/06-0f-0d
[   19.388051] platform microcode: firmware: requesting intel-ucode/06-0f-0d
[   19.398786] Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[   20.285818] NET: Registered protocol family 10
[   20.291080] lo: Disabled Privacy Extensions
[   20.643977] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   21.067004] ip_tables: (C) 2000-2006 Netfilter Core Team
[   21.515617] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[   21.522388] CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
[   21.527818] nf_conntrack.acct=1 kernel paramater, acct=1 nf_conntrack module option or
[   21.533190] sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
[   22.066794] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   22.072350] Bluetooth: BNEP filters: protocol multicast
[   24.959113] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[   24.959117] EDD information not available.
[   28.017836] e1000e 0000:01:00.0: irq 316 for MSI/MSI-X
[   28.073159] e1000e 0000:01:00.0: irq 316 for MSI/MSI-X
[   28.076079] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   28.086868] iwlagn 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[   28.087006] iwlagn 0000:02:00.0: restoring config space at offset 0x1 (was 0x100002, writing 0x100006)
[   28.087172] iwlagn 0000:02:00.0: irq 315 for MSI/MSI-X
[   28.087299] iwlagn 0000:02:00.0: firmware: requesting iwlwifi-4965-2.ucode
[   28.457373] Registered led device: iwl-phy0:radio
[   28.458072] Registered led device: iwl-phy0:assoc
[   28.462528] Registered led device: iwl-phy0:RX
[   28.462605] Registered led device: iwl-phy0:TX
[   28.506242] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   28.824609] NET: Registered protocol family 17
[   34.537881] [drm] Initialized drm 1.1.0 20060810
[   34.621165] pci 0000:00:02.0: power state changed by ACPI to D0
[   34.621183] pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   34.621192] pci 0000:00:02.0: setting latency timer to 64
[   34.621597] [drm] Initialized i915 1.6.0 20080730 on minor 0
[   37.648145] evdev.c(EVIOCGBIT): Suspicious buffer size 511, limiting output to 64 bytes. See http://userweb.kernel.org/~dtor/eviocgbit-bug.html
[  457.782731] CPU0 attaching NULL sched-domain.
[  457.782742] CPU1 attaching NULL sched-domain.
[  457.793186] CPU0 attaching sched-domain:
[  457.793194]  domain 0: span 0-1 level MC
[  457.793199]   groups: 0 1
[  457.793208]   domain 1: span 0-1 level CPU
[  457.793213]    groups: 0-1
[  457.793222] CPU1 attaching sched-domain:
[  457.793227]  domain 0: span 0-1 level MC
[  457.793231]   groups: 1 0
[  457.793238]   domain 1: span 0-1 level CPU
[  457.793243]    groups: 0-1
[  458.838671] wlan0: direct probe to AP 00:1d:7e:aa:87:ee try 1
[  458.843799] wlan0 direct probe responded
[  458.843809] wlan0: authenticate with AP 00:1d:7e:aa:87:ee
[  458.845708] wlan0: authenticated
[  458.845718] wlan0: associate with AP 00:1d:7e:aa:87:ee
[  458.848476] wlan0: RX AssocResp from 00:1d:7e:aa:87:ee (capab=0x411 status=0 aid=1)
[  458.848482] wlan0: associated
[  458.877940] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  462.725909] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=64 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=44 
[  462.877927] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=468 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=448 
[  462.928382] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=242 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=222 
[  463.128769] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=468 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=448 
[  463.379176] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=468 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=448 
[  468.956114] wlan0: no IPv6 routers present
[  469.730168] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=64 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=44 
[  470.608643] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6211 PROTO=2 
[  477.735086] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=64 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=44 
[  480.733900] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=34144 PROTO=2 
[  493.748617] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=64 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=44 
[  525.760640] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=64 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=44 
[  531.279188] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6233 PROTO=2 
[  535.222619] CE: hpet increasing min_delta_ns to 15000 nsec
[  540.934330] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=37454 PROTO=2 
[  589.780169] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=64 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=44 
[  591.189410] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6270 PROTO=2 
[  601.072925] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=41154 PROTO=2 
[  608.068229] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6271 PROTO=UDP SPT=2224 DPT=137 LEN=58 
[  619.154128] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6282 PROTO=UDP SPT=2224 DPT=137 LEN=58 
[  629.164217] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6283 PROTO=UDP SPT=2225 DPT=137 LEN=58 
[  631.551246] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6284 PROTO=UDP SPT=2225 DPT=137 LEN=58 
[  638.804178] CE: hpet increasing min_delta_ns to 22500 nsec
[  643.846962] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6295 PROTO=UDP SPT=2225 DPT=137 LEN=58 
[  650.259141] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6296 PROTO=UDP SPT=2226 DPT=137 LEN=58 
[  656.194406] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6298 PROTO=UDP SPT=2226 DPT=137 LEN=58 
[  668.622210] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6309 PROTO=UDP SPT=2226 DPT=137 LEN=58 
[  711.018111] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6320 PROTO=2 
[  717.847346] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=64 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=44 
[  721.378919] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=49397 PROTO=2 
[  771.777958] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6359 PROTO=2 
[  781.797633] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=52938 PROTO=2 
[  797.932181] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6370 PROTO=UDP SPT=2230 DPT=137 LEN=58 
[  803.982015] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6371 PROTO=UDP SPT=2230 DPT=137 LEN=58 
[  816.428242] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6382 PROTO=UDP SPT=2230 DPT=137 LEN=58 
[  819.032711] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6383 PROTO=UDP SPT=2231 DPT=137 LEN=58 
[  828.810006] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6384 PROTO=UDP SPT=2231 DPT=137 LEN=58 
[  831.689495] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6385 PROTO=2 
[  840.127230] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6386 PROTO=UDP SPT=2232 DPT=137 LEN=58 
[  841.128815] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6397 PROTO=UDP SPT=2232 DPT=137 LEN=58 
[  892.444899] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6419 PROTO=2 
[  902.129978] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=60532 PROTO=2 
[  952.360345] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6440 PROTO=2 
[  962.200380] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=63631 PROTO=2 
[  973.927221] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=64 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=44 
[ 1012.275976] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6461 PROTO=2 
[ 1022.283353] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=16577 PROTO=2 
[ 1072.187524] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6492 PROTO=2 
[ 1082.294164] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=20510 PROTO=2 
[ 1132.103381] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6513 PROTO=2 
[ 1142.424284] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=23675 PROTO=2 
[ 1192.861176] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6534 PROTO=2 
[ 1202.990844] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=27461 PROTO=2 
[ 1253.620878] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6565 PROTO=2 
[ 1263.273181] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=30511 PROTO=2 

[-- Attachment #3: lspci-vv.txt --]
[-- Type: text/plain, Size: 18833 bytes --]

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: [e0] Vendor Specific Information <?>
	Kernel driver in use: agpgart-intel
	Kernel modules: intel-agp

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
	Subsystem: Toshiba America Info Systems Device 0022
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at ffc80000 (32-bit, non-prefetchable) [size=512K]
	Region 1: I/O ports at cff8 [size=8]
	Region 2: Memory at e0000000 (32-bit, prefetchable) [size=256M]
	Region 3: Memory at ffc40000 (32-bit, non-prefetchable) [size=256K]
	Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
		Address: 00000000  Data: 0000
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel modules: intelfb

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
	Subsystem: Toshiba America Info Systems Device 0022
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Region 0: Memory at 88000000 (32-bit, non-prefetchable) [disabled] [size=512K]
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 22
	Region 0: Memory at 88080000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100] Virtual Channel <?>
	Capabilities: [130] Root Complex Link <?>
	Kernel driver in use: HDA Intel
	Kernel modules: snd-hda-intel

00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 0000b000-0000bfff
	Memory behind bridge: ff900000-ff9fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v1) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
			ExtTag- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
			ClockPM- Suprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
		Address: fee0300c  Data: 4161
	Capabilities: [90] Subsystem: Toshiba America Info Systems Device 0001
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [100] Virtual Channel <?>
	Capabilities: [180] Root Complex Link <?>
	Kernel driver in use: pcieport-driver
	Kernel modules: shpchp

00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	Memory behind bridge: ff800000-ff8fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v1) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
			ExtTag- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #3, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
			ClockPM- Suprise- LLActRep+ BwNot-
		LnkCtl:	ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
		Address: fee0300c  Data: 4169
	Capabilities: [90] Subsystem: Toshiba America Info Systems Device 0001
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [100] Virtual Channel <?>
	Capabilities: [180] Root Complex Link <?>
	Kernel driver in use: pcieport-driver
	Kernel modules: shpchp

00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 23
	Region 4: I/O ports at afe0 [size=32]
	Kernel driver in use: uhci_hcd
	Kernel modules: uhci-hcd

00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 19
	Region 4: I/O ports at af80 [size=32]
	Kernel driver in use: uhci_hcd
	Kernel modules: uhci-hcd

00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin C routed to IRQ 18
	Region 4: I/O ports at af60 [size=32]
	Kernel driver in use: uhci_hcd
	Kernel modules: uhci-hcd

00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin D routed to IRQ 16
	Region 4: I/O ports at af40 [size=32]
	Kernel driver in use: uhci_hcd
	Kernel modules: uhci-hcd

00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 23
	Region 0: Memory at ffc3fc00 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Debug port: BAR=1 offset=00a0
	Kernel driver in use: ehci_hcd
	Kernel modules: ehci-hcd

00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) (prog-if 01 [Subtractive decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Bus: primary=00, secondary=03, subordinate=07, sec-latency=32
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [50] Subsystem: Toshiba America Info Systems Device 0001

00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: [e0] Vendor Specific Information <?>
	Kernel modules: iTCO_wdt

00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 02) (prog-if 01 [AHCI 1.0])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 317
	Region 0: I/O ports at af38 [size=8]
	Region 1: I/O ports at af34 [size=4]
	Region 2: I/O ports at af28 [size=8]
	Region 3: I/O ports at af24 [size=4]
	Region 4: I/O ports at af10 [size=16]
	Region 5: Memory at ffc3f800 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
		Address: fee0300c  Data: 4179
	Capabilities: [70] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: ahci
	Kernel modules: ahci

01:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 316
	Region 0: Memory at ff9e0000 (32-bit, non-prefetchable) [size=128K]
	Region 2: I/O ports at bfe0 [size=32]
	Capabilities: [c8] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
		Address: 00000000fee0100c  Data: 41b1
	Capabilities: [e0] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <128ns, L1 <64us
			ClockPM+ Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100] Advanced Error Reporting <?>
	Capabilities: [140] Device Serial Number ac-dd-af-ff-ff-7e-1c-00
	Kernel driver in use: e1000e
	Kernel modules: e1000e

02:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)
	Subsystem: Intel Corporation Device 1101
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 315
	Region 0: Memory at ff8fe000 (64-bit, non-prefetchable) [size=8K]
	Capabilities: [c8] Power Management version 3
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
		Address: 00000000fee0300c  Data: 41b9
	Capabilities: [e0] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 unlimited
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <128ns, L1 <64us
			ClockPM+ Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100] Advanced Error Reporting <?>
	Capabilities: [140] Device Serial Number e7-38-c3-ff-ff-3b-1f-00
	Kernel driver in use: iwlagn
	Kernel modules: iwlagn

03:0b.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 168, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 21
	Region 0: Memory at 88088000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=03, secondary=04, subordinate=07, sec-latency=176
	Memory window 0: 8c000000-8ffff000 (prefetchable)
	Memory window 1: 90000000-93fff000
	I/O window 0: 00001000-000010ff
	I/O window 1: 00001400-000014ff
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
	16-bit legacy interface ports at 0001
	Kernel driver in use: yenta_cardbus
	Kernel modules: yenta_socket

03:0b.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller (prog-if 10 [OHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (500ns min, 1000ns max), Cache Line Size: 32 bytes
	Interrupt: pin B routed to IRQ 20
	Region 0: Memory at 88089000 (32-bit, non-prefetchable) [size=2K]
	Region 1: Memory at 88084000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME+
	Kernel driver in use: firewire_ohci
	Kernel modules: firewire-ohci

03:0b.3 SD Host controller: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller (prog-if 01)
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (1750ns min, 1000ns max), Cache Line Size: 32 bytes
	Interrupt: pin D routed to IRQ 23
	Region 0: Memory at 88089800 (32-bit, non-prefetchable) [size=256]
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: sdhci-pci
	Kernel modules: sdhci-pci


[-- Attachment #4: proc_iomem.txt --]
[-- Type: text/plain, Size: 2070 bytes --]

00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000e0000-000eedff : reserved
000eee00-000eefff : ACPI Non-volatile Storage
000ef000-000fffff : reserved
00100000-7f74ffff : System RAM
  00200000-00450686 : Kernel code
  00450687-00603c37 : Kernel data
  00678000-00784d3b : Kernel bss
7f750000-7fffffff : reserved
  7f750000-7f75ffff : pnp 00:00
  7f760000-7f7fffff : pnp 00:00
  7f800000-7fffffff : pnp 00:00
88000000-8807ffff : 0000:00:02.1
88080000-88083fff : 0000:00:1b.0
  88080000-88083fff : ICH HD audio
88084000-88087fff : 0000:03:0b.1
88088000-88088fff : 0000:03:0b.0
  88088000-88088fff : yenta_socket
88089000-880897ff : 0000:03:0b.1
  88089000-880897ff : firewire_ohci
88089800-880898ff : 0000:03:0b.3
  88089800-880898ff : mmc0
8808a000-8808afff : Intel Flush Page
8c000000-8fffffff : PCI CardBus 0000:04
90000000-93ffffff : PCI CardBus 0000:04
e0000000-efffffff : 0000:00:02.0
  e0000000-e07affff : vesafb
f0000000-f3ffffff : PCI MMCONFIG 0
  f0000000-f3ffffff : pnp 00:01
fec00000-fec17fff : reserved
  fec00000-fec17fff : pnp 00:00
    fec00000-fec00fff : IOAPIC 0
fec20000-fec27fff : reserved
  fec20000-fec27fff : pnp 00:00
fed00000-fed003ff : HPET 0
  fed00000-fed003ff : reserved
fed14000-fed19fff : reserved
  fed14000-fed19fff : pnp 00:00
fed1c000-fed8ffff : reserved
  fed1c000-fed1ffff : pnp 00:00
  fed20000-fed3ffff : pnp 00:00
  fed45000-fed8ffff : pnp 00:00
feda0000-fedbffff : reserved
  feda0000-fedbffff : pnp 00:00
fee00000-fee00fff : Local APIC
  fee00000-fee00fff : reserved
    fee00000-fee00fff : pnp 00:00
ff800000-ff8fffff : PCI Bus 0000:02
  ff8fe000-ff8fffff : 0000:02:00.0
    ff8fe000-ff8fffff : iwlagn
ff900000-ff9fffff : PCI Bus 0000:01
  ff9e0000-ff9fffff : 0000:01:00.0
    ff9e0000-ff9fffff : e1000e
ffa00000-ffbfffff : reserved
  ffa00000-ffbfffff : pnp 00:00
ffc3f800-ffc3fbff : 0000:00:1f.2
  ffc3f800-ffc3fbff : ahci
ffc3fc00-ffc3ffff : 0000:00:1d.7
  ffc3fc00-ffc3ffff : ehci_hcd
ffc40000-ffc7ffff : 0000:00:02.0
ffc80000-ffcfffff : 0000:00:02.0
ffd00000-ffffffff : reserved
  ffd00000-ffffffff : pnp 00:00

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Thu, 4 Dec 2008, Rafael J. Wysocki wrote:
> 
> That said the "don't bother allocating bridging windows for transparent
> bridges" patch resulted in the following layout on my box (from /proc/iomem):
> 
> 88000000-8807ffff : 0000:00:02.1
> 88080000-88083fff : 0000:00:1b.0
>   88080000-88083fff : ICH HD audio
> 88084000-88087fff : 0000:03:0b.1
> 88088000-88088fff : 0000:03:0b.0
>   88088000-88088fff : yenta_socket
> 88089000-880897ff : 0000:03:0b.1
>   88089000-880897ff : firewire_ohci
> 88089800-880898ff : 0000:03:0b.3
>   88089800-880898ff : mmc0
> 8808a000-8808afff : Intel Flush Page
> 8c000000-8fffffff : PCI CardBus 0000:04
> 90000000-93ffffff : PCI CardBus 0000:04
> 
> while my "don't allocate bridging windows for cardbus bridges behind
> transparent bridges" patch I've just sent (appended for easier reference)
> results in the layout:
> 
> 88000000-880fffff : PCI Bus 0000:03
>   88000000-88003fff : 0000:03:0b.1
>   88004000-88004fff : 0000:03:0b.0
>     88004000-88004fff : yenta_socket
>   88005000-880057ff : 0000:03:0b.1
>     88005000-880057ff : firewire_ohci
>   88005800-880058ff : 0000:03:0b.3
>     88005800-880058ff : mmc0
> 88100000-8817ffff : 0000:00:02.1
> 88180000-88183fff : 0000:00:1b.0
>   88180000-88183fff : ICH HD audio
> 88184000-88184fff : Intel Flush Page
> 8c000000-8fffffff : PCI CardBus 0000:04
> 90000000-93ffffff : PCI CardBus 0000:04

Well, this happens because in the second case, you still will allocate a 
non-prefetchable window due to the _other_ devices behind the bridge (ie 
the firewire and mmc device.

So with your "ignore cardbus device resources", you still do end up with a 
bridge window allocated, but now it will depend entirely on what other 
devices exist on that PCI bus. Which is why I really dislike that patch, 
because it really makes no sense at all. 

And once you've allocated the PCI bridge window, then the alignment 
requirements are that you end up having at least 1MB of window, and now 
because a window exists, and will fit, it will then happily put the yenta 
control mappings into that window even though it didn't size it for them.

See?

Also, notice how it doesn't put the actual cardbus bridge windows 
themselves into that PCI bridge window, because they won't fit. So these 
resources:

	8c000000-8fffffff : PCI CardBus 0000:04
	90000000-93ffffff : PCI CardBus 0000:04

are outside the window, even though that bus is topologically inside the 
same bus, and they both end up depending on the fact that the PCI bus 
controller is transparent.

So the above results are fairly easy to explain.

The _ordering_ difference comes simply from the allocation order. We'll do 
bus allocations first (if we do them), which is why _if_ we allocate a 
window for that PCI bus 03 (ie the one that is bridged to by 0:1e.0, that 
transparent bridge), then we'll end up allocating it first. So that's why 
the PCI bridge window shows up at 0x88000000, if it shows up at all 
(because that's the starting address for PCI allocations).

Then, we'll do the regular devices in the order we found them, so then 
we'll allocate the resources for device 0:02.1 and then 0:1b.0. Now, _if_ 
we did a bus window allocation, they'll end up being after the bus window 
we allocated. Otherwise they'll end up being the first allocations.

So then, by the time we actually get to bus#3, and devices 3:0b.*, where 
they end up is going to depend on whether we allocated that bus window (in 
which case they'll preferentially get allocated inside the window - ie 
starting at 0x88000000), or they'll just get allocated inside the parent 
(root) PCI bus. In the latter case they'll be allocated after the 0:02.1 
etc devices.

So the differences in ordering really do make sense, and are a direct 
consequence of whether we decided to need to allocate a bridging window 
for that PCI-PCI bridge at 0:1e.0.

Also note that _if_ PCI bus #3 had had other devices with prefetchable 
memory resources, then we'd have allocated a prefetchable window for 
those even with your patch, and then we'd have been back to the original 
allocation again (although sizing might cause changes, since your patch 
will make us ignore the cardbus controlle for sizing).

> where devices behind the transparent bridge (PCI Bus 0000:03) are located
> _before_ ICH HD audio in the memory address space, and this one appears to
> work.  So there _may_ be an effect of the layout too.

I do agree that your patch will affect layout. I just don't think it makes 
any real amount of sense because of how it essentially does so "randomly" 
depending on what other devices you'd have behind the transparent bridge.

Which is why I think we should either not size transparent bridges at all, 
or we should size _all_ the devices behind them.

Oh, btw, I thought your and Frans' laptops were identical? They don't seem 
to be: in Frans' case, the firmware does seem to set up one memory window, 
so he gets that one even with my "don't size anything" patch, just because 
we'll still honor allocations done by firmware.

> Well, given that both affected boxes have the same chipset (945GM), I seriously
> suspect a nastiness in that chipset we're not aware of.  Especially that
> the problem is not reproducible without snd_hda_intel (at least on my box).

Well, the counter-argument to that is that the 945GM should be a _very_ 
common chipset. So I'd not expect a chipset nastiness.

I'd be more wary about the BIOS doing something odd. Or an ACPI thing. 

> I've already checked the resume ordering of PCI devices on my box and it
> is the following:
>   [snip]
> So, snd_hda_intel resumes before all of the bridges and the layout of devices
> _behind_ the transparent bridge shouldn't affect it at all.

Yes. And in the case of Frans' machine, the e1000e controller was before 
all the bridges too.

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Thursday, 4 of December 2008, Frans Pop wrote:
> On Thursday 04 December 2008, Linus Torvalds wrote:
> > On Thu, 4 Dec 2008, Frans Pop wrote:
> > > I've given your patch a try and the few resumes from STR I've done
> > > were all successful. That's not 100% conclusive yet, but a nice
> > > start. Some info from logs etc. below.
> >
> > Ok, but I thought you had a hard time reproducing this _anyway_, even
> > with just plain -rc7. No?
> 
> Well, I had a failure rate of about 1 in 5-10 resumes originally.
> See: http://bugzilla.kernel.org/show_bug.cgi?id=11545
> 
> Then I found the 2 workarounds and *with those in place* I got almost 100% 
> reliable resumes. Now I've removed those workarounds and with either the 
> revert or your oneliner I still get 100% success.
> From my PoV that is a very definite improvement: the machine now "feels" a 
> hell of a lot more reliable for critical use.
> 
> So I _could_ reproduce it reliably given enough suspend/resume cycles.
> But I guess this does support your suspicion that it may be a timing 
> issue: if the timing happens to be right, the resume succeeds; if it's 
> wrong I get a dead box.
> 
> > Since it's apparently STR, has anybody gotten _anything_ sane out of
> > trying to enable PM_TRACE_RTC, and then doing that
> >
> > 	echo 1 > /sys/power/pm_trace
> 
> I did try that at the beginning. That's how I ended up removing e1000e 
> before suspend. See http://bugzilla.kernel.org/show_bug.cgi?id=11545.
> 
> My next hint was that Matthew Garret, who has the same notebook, was 
> surprised at my resume problems as he did not see them. So I did a 
> comparison of our kernel configs and made some changes to mine. From
> that I found that a very low value for SND_HDA_POWER_SAVE_DEFAULT (5) 
> reduced the failure rate to practically zero.
> 
> At some point I tried keeping e1000e loaded for a bit, but that quickly 
> gave me a failure again, so I starting removing it again during suspend.
> 
> So I did have some data, but as I got no response on my BR I had no idea 
> where to go from there. I was really very happy to see Rafael's mail as 
> his description almost exactly matched what I had been seeing.
> 
> I'd be happy to run with unpatched kernels for a while and do some more 
> pm_traces, but only if someone is going to follow up and interpret the 
> results for me or provide suggestions for targeted additional debugging.

Please go for it, I'm very interested in understanding the underlying problem.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Thursday, 4 of December 2008, Linus Torvalds wrote:
> 
> On Thu, 4 Dec 2008, Frans Pop wrote:
> 
> > On Wednesday 03 December 2008, Linus Torvalds wrote:
> > > Well, I think that what _would_ be generally correct, and actually
> > > pretty simple, is a rather different approach: just not sizing things
> > > behind a transparent bridge AT ALL, since it really shouldn't matter.
> > 
> > I've given your patch a try and the few resumes from STR I've done were 
> > all successful. That's not 100% conclusive yet, but a nice start.
> > Some info from logs etc. below.
> 
> Ok, but I thought you had a hard time reproducing this _anyway_, even with 
> just plain -rc7. No?
> 
> That said, of the various patches posted, the "don't bother allocating 
> bridging windows for transparent bridges" one is not just the simplest, 
> but the only one that actually makes sense so far.
> 
> So I'm happy it's apparently working for you, I'm just wondering about 
> whather your success means a lot. It seems that Rafael is the one who had 
> more failures?

This most probably is correct and I got a resume failure with that patch
applied, so it evidently doesn't fix the problem. :-(

> > > > Also, I would be happy to actually understand _why_ this happens.
> > >
> > > 100% agreed. I do _not_ see why it should ever matter how we set up a
> > > PCI bridging window - whether prefetchable or not - on a bridge that
> > > should be transparent. It sounds really odd. I'm wondering if there is
> > > something we're missing here.
> > 
> > The theory that it is really a resume issue and not a device layout issue 
> > sounds logical. Especially as everything always works correctly after a 
> > normal boot.
> 
> Yes, that does sound like a convincing argument. Usually real PCI resource 
> clashes result in some kind of run-time problems, and wouldn't necessarily 
> be suspend-specific per se.
> 
> That said, suspend/resume does a lot of unusual things, so it could still 
> be some odd PCI resource clash that only triggers problems in the 
> suspend/resume case. But since the exact layouts and the sizing of the 
> resources doesn't really seem to matter, a simple PCI resource clash seems 
> rather unlikely.

I agree.

That said the "don't bother allocating bridging windows for transparent
bridges" patch resulted in the following layout on my box (from /proc/iomem):

88000000-8807ffff : 0000:00:02.1
88080000-88083fff : 0000:00:1b.0
  88080000-88083fff : ICH HD audio
88084000-88087fff : 0000:03:0b.1
88088000-88088fff : 0000:03:0b.0
  88088000-88088fff : yenta_socket
88089000-880897ff : 0000:03:0b.1
  88089000-880897ff : firewire_ohci
88089800-880898ff : 0000:03:0b.3
  88089800-880898ff : mmc0
8808a000-8808afff : Intel Flush Page
8c000000-8fffffff : PCI CardBus 0000:04
90000000-93ffffff : PCI CardBus 0000:04

while my "don't allocate bridging windows for cardbus bridges behind
transparent bridges" patch I've just sent (appended for easier reference)
results in the layout:

88000000-880fffff : PCI Bus 0000:03
  88000000-88003fff : 0000:03:0b.1
  88004000-88004fff : 0000:03:0b.0
    88004000-88004fff : yenta_socket
  88005000-880057ff : 0000:03:0b.1
    88005000-880057ff : firewire_ohci
  88005800-880058ff : 0000:03:0b.3
    88005800-880058ff : mmc0
88100000-8817ffff : 0000:00:02.1
88180000-88183fff : 0000:00:1b.0
  88180000-88183fff : ICH HD audio
88184000-88184fff : Intel Flush Page
8c000000-8fffffff : PCI CardBus 0000:04
90000000-93ffffff : PCI CardBus 0000:04

where devices behind the transparent bridge (PCI Bus 0000:03) are located
_before_ ICH HD audio in the memory address space, and this one appears to
work.  So there _may_ be an effect of the layout too.

> So some kind of resume-time ordering or timing issue does seem like the 
> most likely thing. But that still leaves us not knowing what the real 
> _root_ cause of this all is - very irritating. Even if not allocating the 
> unnecessary bridging windows "fixes" things, it would be really really 
> good to know exactly what it is that causes problems.

Well, given that both affected boxes have the same chipset (945GM), I seriously
suspect a nastiness in that chipset we're not aware of.  Especially that
the problem is not reproducible without snd_hda_intel (at least on my box).

> > Below info from 3 kernels, all based on 2.6.28-rc7-91:
> > A) unpatched
> > B) with the revert/debug patch
> > C) with the oneliner "ignore transparent bridges" patch
> > 
> > AFAICT all results are probably as expected.
> > 
> > From lspci -vvxxx:
> > 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge
> > - for A)
> > 	I/O behind bridge: 00003000-00003fff
> > 	Memory behind bridge: e0100000-e03fffff
> > 	Prefetchable memory behind bridge: 0000000080000000-0000000083ffffff
> > - for B)
> > 	I/O behind bridge: 00003000-00003fff
> > 	Memory behind bridge: e0100000-e03fffff
> > - for C)
> > 	Memory behind bridge: e0100000-e03fffff
> 
> And this all makes total sense. The e0100000-e03fffff MMIO bridge range is 
> apparently set up by the firmware, which is why it shows up in all cases. 
> And the (A) case has that prefetchable memory range, because that's the 
> only case that finds - and cares about - the prefetch window for the 
> CardBus controller. 
> 
> And both (A) and (B) have the IO bridging window, because regardless of 
> whether we see a valid CardBus prefetchable memory window with good 
> alignment, we'll always see the IO ports, so we'll try to allocate that 
> bridging window, except in (C) when we decide that due to the transparent 
> nature, we simply don't care.
> 
> So the PCI resources make sense in all three cases, and we understand 
> those. The differences in the actual Cardbus ranges also all make sense. 
> So it all still boils down to the PCI layer doing everything right in 
> _all_ cases, just making slightly different - but all valid - choices 
> depending on essentially random details (eg the revert/debug patch case 
> the "random detail" is just enabling a small incorrect alignment).
> 
> IOW, it really doesn't look like a PCI resource allocator bug. Quite the 
> reverse, I'd say that in the end this whole thread points out just how 
> robust the whole PCI and cardbus resource allocation is, with the code 
> really very gracefully just adjusting in a sane manner to all these 
> different cases.
> 
> Of course, none of that helps us with any kind of idea of what the real 
> problem is. Device ordering bug in setting up PCI resources at resume? 
> Perhaps just a plain bug in PCI bridge resume code (even when you resume 
> things in the right order)?
> 
> And I still worry that perhaps it's just a timing bug, where having a PCI 
> bridging window changes timing of various PCI accesses, and the _real_ bug 
> is actually in the sound card or ethernet driver resume, which happens to 
> work with one timing and not with another.
> 
> Since it's apparently STR, has anybody gotten _anything_ sane out of 
> trying to enable PM_TRACE_RTC, and then doing that 
> 
> 	echo 1 > /sys/power/pm_trace
> 
> because even with the (very limited) set of standard trace-points, it 
> should still be able to tell which device we were trying to resume last in 
> the failure case Maybe that gives some hint?

Well, I think more fine-grained debugging will be necessary.

I've already checked the resume ordering of PCI devices on my box and it
is the following:

pci:0000:00:00.0
pci:0000:00:02.0 <- graphics
pci:0000:00:02.1 <- graphics
pci:0000:00:1b.0 <- snd_hda_intel
pci:0000:00:1c.0 <- PCI Express port 1
pci:0000:00:1c.2 <- PCI Express port 3
pci:0000:00:1d.0 <- USB UHCI
pci:0000:00:1d.1 <- USB UHCI
pci:0000:00:1d.2 <- USB UHCI
pci:0000:00:1d.3 <- USB UHCI
pci:0000:00:1d.7 <- USB EHCI
pci:0000:00:1e.0 <- transparent bridge (Intel Corporation 82801 Mobile PCI Bridge)
pci:0000:00:1f.0 <- ISA bridge
pci:0000:00:1f.2 <- SATA (ahci)
pci:0000:01:00.0 <- e1000e
No Bus:0000:01
pci:0000:02:00.0 <- wireless (iwlagn)
No Bus:0000:02
pci:0000:03:0b.0 <- cardbus bridge
pci:0000:03:0b.1 <- FireWire
pci:0000:03:0b.3 <- SD Host controller (Texas Instruments)
No Bus:0000:04
No Bus:0000:03

So, snd_hda_intel resumes before all of the bridges and the layout of devices
_behind_ the transparent bridge shouldn't affect it at all.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Thu, 4 Dec 2008, Rafael J. Wysocki wrote:
> 
> However, this one appears to work reliably for me (on top of vanilla current
> mainline):

Not very interesting. It just does the same thing your previous patches 
have done - ignores the cardbus slot for sizing. It just does it 
differently and more explicitly.

Your original patch did it by simply giving the resources invalid 
alignments (in a very non-obvious way). This one does it by being explicit 
and saying "we won't care about cardbus resources behind transparent 
bridges". But it's still a very hacky thing, and thus not really 
interesting at all as a patch.

IOW, it's not a patch that makes sense - it's just a patch that ON YOUR 
PARTICULAR MACHINE causes us to get the layout you want in order to hide 
the bug. And it doesn't really even do anything new - it's just doing the 
same thing in an old way.

But it's interesting that the "don't size _anything_ behind a transparent 
bridge" apparently made no difference for you.

Can you send "lspci -vv" and "dmesg" output for that kernel? Even if it 
failed the suspend/resume, it's interesting, because I would actually have 
expected that one to have the same layout as the successful ones.

			Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Thursday, 4 of December 2008, Frans Pop wrote:
> On Wednesday 03 December 2008, Linus Torvalds wrote:
> > Well, I think that what _would_ be generally correct, and actually
> > pretty simple, is a rather different approach: just not sizing things
> > behind a transparent bridge AT ALL, since it really shouldn't matter.
> 
> I've given your patch a try and the few resumes from STR I've done were 
> all successful. That's not 100% conclusive yet, but a nice start.
> Some info from logs etc. below.

It doesn't help on my box, though.  I've got a failure to resume from
hibernation on the first attempt.

However, this one appears to work reliably for me (on top of vanilla current
mainline):

--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -350,6 +350,11 @@ static int pbus_size_mem(struct pci_bus 
 
 			if (r->parent || (r->flags & mask) != type)
 				continue;
+
+			if ((dev->class >> 8) == PCI_CLASS_BRIDGE_CARDBUS
+			    && bus->self->transparent)
+				continue;
+
 			r_size = resource_size(r);
 			/* For bridges size != alignment */
 			align = resource_alignment(r);

> > > Also, I would be happy to actually understand _why_ this happens.
> >
> > 100% agreed. I do _not_ see why it should ever matter how we set up a
> > PCI bridging window - whether prefetchable or not - on a bridge that
> > should be transparent. It sounds really odd. I'm wondering if there is
> > something we're missing here.
> 
> The theory that it is really a resume issue and not a device layout issue 
> sounds logical. Especially as everything always works correctly after a 
> normal boot.

Well, in fact I'm pretty sure this is the case.  By changing memory address
space layout we effectively change conditions during suspend-resume and
apparently we can choose one for which the failure condition doesn't trigger
(or, IOW, the probability of it is _so_ small that we just can't see it).

There seems to be a race of some kind or a missing delay or something similar.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Thursday, 4 of December 2008, Linus Torvalds wrote:
> 
> On Thu, 4 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > Well, in principle it may be related to the way we handle bridges during
> > resume
> 
> Ahh. Yes, that's possible. It's quite possible that the problem isn't 
> resource allocation per se, but just the bigger complexity at resume time.
> 
> This is a hibernate-only issue for you, right? Or is it about regular 
> suspend-to-ram too?

It is suspend to RAM too, from what I can tell.

> > but I really need to read some docs and compare them with the code 
> > before I can say anything more about that.  Surely, nothing like this 
> > issue has ever been reported before.
> 
> Well, how stable has hibernate been on that particular machine 
> historically?
> 
> Because the half-revert alignment patch (ie reverting part of 5f17cf) that 
> made it work for you would actually have been a non-issue in the original 
> code that was pre-PCI-resource-alignment cleanup (commit 88452565).
> 
> So the patch you partially reverted was literally the one that made the 
> Cardbus allocation work the _same_ way as it did historically, before 
> 88452565. So if the new code breaks for you, then so should the "old" code 
> (ie 2.6.25 and earlier).
> 
> So the "hasn't been reported before" case may well be just another way of 
> saying "hibernate has never been very reliable".

This is a new box and the kernels earlier than 2.6.27-rc3 have not been tested
on it.  So, in fact, it's quite possible that hibernation would fail on it with
earlier kernels as well.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

Ingo, Len, can you check the end of the email about the apparent 
very-early interrupt issue? Can we get into acpi_ec_gpe_handler() without 
interrupts being enabled some way?

Greg, Jesse, can you think about and look at the USB PCI resume ordering?

On Thu, 4 Dec 2008, Frans Pop wrote:
> 
> Well, I had a failure rate of about 1 in 5-10 resumes originally.
> See: http://bugzilla.kernel.org/show_bug.cgi?id=11545

Ok, very interesting. Thanks for the pointer.

> Then I found the 2 workarounds and *with those in place* I got almost 100% 
> reliable resumes. Now I've removed those workarounds and with either the 
> revert or your oneliner I still get 100% success.
> From my PoV that is a very definite improvement: the machine now "feels" a 
> hell of a lot more reliable for critical use.

Sure. I'd love to apply the "transparency fix" (the last patch), but my 
main worry is that while it feels really right, and it fixes things for 
you and Rafael, these kinds of changes historically _always_ end up biting 
us. Because even if it's 100% the correct thing to do, it will show up 
some problem for somebody else just because we're really unlucky, and it 
just ends up exposing some totally unrelated bug.

Exactly the same way that this whole PCI resource setting thing was 100% 
correct in the first place, but exposed some other bug.

> So I _could_ reproduce it reliably given enough suspend/resume cycles.
> But I guess this does support your suspicion that it may be a timing 
> issue: if the timing happens to be right, the resume succeeds; if it's 
> wrong I get a dead box.

Yes.

> I did try that at the beginning. That's how I ended up removing e1000e 
> before suspend. See http://bugzilla.kernel.org/show_bug.cgi?id=11545.

What is interesting is that it's apparently not reliably that e1000e thing 
that is being resumed when it fails. You have another report there that 
says that it's a match on PNP0C0A.

Of course, the way that hash works, we only have a few bits to create it, 
and sometimes you just get false positives (there's not a whole lot you 
can reliably do with about 24 bits of information ;(

So it would be interesting to get a few more debug traces of that lockup.

HOWEVER. Having now looked through your fuller dmesg output even for the 
_successful_ case, I actually find a few things that are a bit worrying.

Looking at the unpatched dmesg, since that's the most interesting one 
(since it's the one that should hopefully show behaviour that is 
potentially triggering the problem), I see two worrying things:

	pci 0000:00:1e.0: restoring config space at offset 0x9 (was 0x10001, writing 0x83f18001)
	pci 0000:00:1e.0: restoring config space at offset 0x8 (was 0x0, writing 0xe030e010)
	pci 0000:00:1e.0: restoring config space at offset 0x7 (was 0x228000f0, writing 0x22803030)
	pci 0000:00:1e.0: restoring config space at offset 0x1 (was 0x100007, writing 0x100107)
	pci 0000:00:1e.0: setting latency timer to 64

That "offset 0x9/0x8/0x7" are the PCI bridge window prefetchable memory, 
non-prefetchable memory, and IO bases respectively (when it says '0x9', 
it's counting in quad-words, so it's really config space offset 0x24L 
PCI_PREF_MEMORY_BASE).

Now, that really means:
 - 0x9 prefetchable window: was disabled, is now 0x80000000-0x83ffffff
 - 0x8 nonprefetch window: was disabled, is now  0xe0100000-0xe03fffff
 - 0x7 IO window: was disabled, is noe 0x3000-0x3fff

That all looks correct, BUT the IO base reprogramming actually worries me. 
It's correct only because it's a 16-bit range. For a 32-bit range (which 
is not supported on an x86 platform, since IO ports are always just 16 
bits), the ordering would be very different, and we'd have to make sure 
that we write the upper bits in a special order to avoid problems.

With the "revert fix", the sequence is essentially the same, just 
different values:

	pci 0000:00:1e.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
	pci 0000:00:1e.0: restoring config space at offset 0x8 (was 0x0, writing 0xe030e010)
	pci 0000:00:1e.0: restoring config space at offset 0x7 (was 0x228000f0, writing 0x22803030)
	pci 0000:00:1e.0: restoring config space at offset 0x1 (was 0x100007, writing 0x100107)
	pci 0000:00:1e.0: setting latency timer to 64

the difference is that we now disable the prefetchable window (since we 
never allocated it), we just disable it with a different value than the 
one the BIOS used (0x10001 _could_ be imagined to mean "bridge the range 
0x00000000-0x0000ffff, while the kernel disables the IO region by setting 
the lower range higher than the high range, which is why you see those 
fff's there).

But the "revert fix" still has the IO range restore. It's still correct in 
this case (no 32-bit IO bits set), but still has the 32-bit range worry 
for non-x86.

With the "fix transparent bridges", the sequence is different:

	pci 0000:00:1e.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
	pci 0000:00:1e.0: restoring config space at offset 0x8 (was 0x0, writing 0xe030e010)
	pci 0000:00:1e.0: restoring config space at offset 0x1 (was 0x100007, writing 0x100107)
	pci 0000:00:1e.0: setting latency timer to 64

ie now we don't even touch the IO window, since we agree with the BIOS on 
how to disable it (ie the kernel also disables it by writing 0x00f0 to the 
low 16 bits).

Anyway, the bridge reprogramming itself all looks correct, and the only 
worry really is that I'm not sure our PCI resume code really stricly 
speaking does the right thing for 32-bit IO resources for other non-x86
architectures.

The "transparent bridge" fix results in the simplest resume sequence for 
that bridge, but the "revert" fix really makes almost no difference at 
all, and again should not matter in the _least_ from a resume standpoint!

So there is a _small_ worry there, but it's not relevant for PC platforms, 
and in no case does it look like the programming of the transparent bridge 
should matter in any way what-so-ever for the resume code.

In many ways the bigger worry is actually in the totally unrelated USB 
UHCI and EHCI drivers that resume _before_ the bridge does:

	uhci_hcd 0000:00:1d.2: enabling device (0000 -> 0001)
	uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
	uhci_hcd 0000:00:1d.2: setting latency timer to 64
	uhci_hcd 0000:00:1d.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
	uhci_hcd 0000:00:1d.2: restoring config space at offset 0x8 (was 0x1, writing 0x2101)
	usb usb7: root hub lost power or was reset
	ehci_hcd 0000:00:1d.7: enabling device (0000 -> 0002)
	ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20
	ehci_hcd 0000:00:1d.7: setting latency timer to 64
	ehci_hcd 0000:00:1d.7: restoring config space at offset 0xf (was 0x100, writing 0x10a)
	ehci_hcd 0000:00:1d.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0648000)

and the worry I have here is that we actually enable the device _before_ 
we've restored the BAR information. That sounds very iffy. It sounds 
doubly iffy in the 'resume from hibernate' case, where we are going to 
have an already-set-up PCI bus and the config space values are going to 
all be live as we reprogram them.

That "restoring config space at offset 0x8" thing is where we restore 
the BAR (dword 0x8 = offset 0x20 = PCI_BASE_ADDRESS_4), and we're changing 
it from 0x1 to 0x2101, with the IO BAR enabled. In this case, the old 
value meant that the BAR started out disabled, but hibernate would have 
been different.

So I'd _much_ rather have seen the sequence have the BAR restore sequence 
be something like

	uhci_hcd 0000:00:1d.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
	uhci_hcd 0000:00:1d.2: restoring config space at offset 0x8 (was 0x1, writing 0x2101)
	uhci_hcd 0000:00:1d.2: enabling device (0000 -> 0001)
	uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
	uhci_hcd 0000:00:1d.2: setting latency timer to 64

instead. Possibly even with an explicit disable of the memory/IO/busmaster 
bits before the whole sequence.

That said, I don't think this is the cause of the problem either. For one 
thing, the USB resume happens after the e1000e resume, so since you've 
apparently seen it hang in the e1000e driver, the real problem must have 
occurred earlier. And e1000e is resumed not just before USB on your 
machine, but even before the PCI bridge is (since it's on the root bus).

For another, in your case, the BAR really was disabled, so there was 
nothing "live" going on here anyway.

The third thing that worries me is the _very_ early occurrence of

	ACPI: Waking up from system sleep state S3
	APIC error on CPU1: 00(40)
	ACPI: EC: non-query interrupt received, switching to interrupt mode

Now, that "APIC error" thing is worrisome. It's worrisome for multiple 
reasons:

 - errors are never good (0x40 means "received illegal vector", whatever 
   caused _that_)

 - more importantly, it seems to imply that interrupts are enabled on 
   CPU1, and they sure as hell shouldn't be enabled at this stage!

   Do we perhaps have a SMP resume bug where we resume the other CPU's 
   with interrupts enabled?

 - the "ACPI: EC: non-query interrupt received, switching to interrupt 
   mode" thing is from ACPI, and _also_ implies that interrupts are on. 

Why are interrupts enabled that early? I really don't like seeing 
interrupts enabled before we've even done the basic PCI resume. 

I'd really like to resume the other CPU's much later (last in the whole 
sequnce, long after we've set up devices), but the f'ing ACPI rules seem 
to be against that. And maybe some setup actually needs the CPU's alive to 
act as a bridge for IO (eg with HT or CSI).

And interrupts happening at random times could certainly cause 
"interesting" and timing-dependent resume problems. Hmm...

The problem with the whole interrupt issue is that it seems to have 
nothing what-so-ever to do with the programming of that bridge in any way, 
shape or form. The timing issues/problems it could introduce should be 
totally irrelevant to anything else.

> I'd be happy to run with unpatched kernels for a while and do some more 
> pm_traces, but only if someone is going to follow up and interpret the 
> results for me or provide suggestions for targeted additional debugging.

I don't really have any better patches to try right now. But as usual, 
from everything I can see, the actual bridge setup itself should be 
totally irrelevant to the problem you see. Which is really irritating, 
since the only patches we _do_ have that seem to matter are purely about 
that bridge resource that shouldn't matter at all!

			Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

On Thursday 04 December 2008, Linus Torvalds wrote:
> On Thu, 4 Dec 2008, Frans Pop wrote:
> > I've given your patch a try and the few resumes from STR I've done
> > were all successful. That's not 100% conclusive yet, but a nice
> > start. Some info from logs etc. below.
>
> Ok, but I thought you had a hard time reproducing this _anyway_, even
> with just plain -rc7. No?

Well, I had a failure rate of about 1 in 5-10 resumes originally.
See: http://bugzilla.kernel.org/show_bug.cgi?id=11545

Then I found the 2 workarounds and *with those in place* I got almost 100% 
reliable resumes. Now I've removed those workarounds and with either the 
revert or your oneliner I still get 100% success.
>From my PoV that is a very definite improvement: the machine now "feels" a 
hell of a lot more reliable for critical use.

So I _could_ reproduce it reliably given enough suspend/resume cycles.
But I guess this does support your suspicion that it may be a timing 
issue: if the timing happens to be right, the resume succeeds; if it's 
wrong I get a dead box.

> Since it's apparently STR, has anybody gotten _anything_ sane out of
> trying to enable PM_TRACE_RTC, and then doing that
>
> 	echo 1 > /sys/power/pm_trace

I did try that at the beginning. That's how I ended up removing e1000e 
before suspend. See http://bugzilla.kernel.org/show_bug.cgi?id=11545.

My next hint was that Matthew Garret, who has the same notebook, was 
surprised at my resume problems as he did not see them. So I did a 
comparison of our kernel configs and made some changes to mine. From
that I found that a very low value for SND_HDA_POWER_SAVE_DEFAULT (5) 
reduced the failure rate to practically zero.

At some point I tried keeping e1000e loaded for a bit, but that quickly 
gave me a failure again, so I starting removing it again during suspend.

So I did have some data, but as I got no response on my BR I had no idea 
where to go from there. I was really very happy to see Rafael's mail as 
his description almost exactly matched what I had been seeing.

I'd be happy to run with unpatched kernels for a while and do some more 
pm_traces, but only if someone is going to follow up and interpret the 
results for me or provide suggestions for targeted additional debugging.

Cheers,
FJP

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Thu, 4 Dec 2008, Frans Pop wrote:

> On Wednesday 03 December 2008, Linus Torvalds wrote:
> > Well, I think that what _would_ be generally correct, and actually
> > pretty simple, is a rather different approach: just not sizing things
> > behind a transparent bridge AT ALL, since it really shouldn't matter.
> 
> I've given your patch a try and the few resumes from STR I've done were 
> all successful. That's not 100% conclusive yet, but a nice start.
> Some info from logs etc. below.

Ok, but I thought you had a hard time reproducing this _anyway_, even with 
just plain -rc7. No?

That said, of the various patches posted, the "don't bother allocating 
bridging windows for transparent bridges" one is not just the simplest, 
but the only one that actually makes sense so far.

So I'm happy it's apparently working for you, I'm just wondering about 
whather your success means a lot. It seems that Rafael is the one who had 
more failures?

> > > Also, I would be happy to actually understand _why_ this happens.
> >
> > 100% agreed. I do _not_ see why it should ever matter how we set up a
> > PCI bridging window - whether prefetchable or not - on a bridge that
> > should be transparent. It sounds really odd. I'm wondering if there is
> > something we're missing here.
> 
> The theory that it is really a resume issue and not a device layout issue 
> sounds logical. Especially as everything always works correctly after a 
> normal boot.

Yes, that does sound like a convincing argument. Usually real PCI resource 
clashes result in some kind of run-time problems, and wouldn't necessarily 
be suspend-specific per se.

That said, suspend/resume does a lot of unusual things, so it could still 
be some odd PCI resource clash that only triggers problems in the 
suspend/resume case. But since the exact layouts and the sizing of the 
resources doesn't really seem to matter, a simple PCI resource clash seems 
rather unlikely.

So some kind of resume-time ordering or timing issue does seem like the 
most likely thing. But that still leaves us not knowing what the real 
_root_ cause of this all is - very irritating. Even if not allocating the 
unnecessary bridging windows "fixes" things, it would be really really 
good to know exactly what it is that causes problems.

> Below info from 3 kernels, all based on 2.6.28-rc7-91:
> A) unpatched
> B) with the revert/debug patch
> C) with the oneliner "ignore transparent bridges" patch
> 
> AFAICT all results are probably as expected.
> 
> From lspci -vvxxx:
> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge
> - for A)
> 	I/O behind bridge: 00003000-00003fff
> 	Memory behind bridge: e0100000-e03fffff
> 	Prefetchable memory behind bridge: 0000000080000000-0000000083ffffff
> - for B)
> 	I/O behind bridge: 00003000-00003fff
> 	Memory behind bridge: e0100000-e03fffff
> - for C)
> 	Memory behind bridge: e0100000-e03fffff

And this all makes total sense. The e0100000-e03fffff MMIO bridge range is 
apparently set up by the firmware, which is why it shows up in all cases. 
And the (A) case has that prefetchable memory range, because that's the 
only case that finds - and cares about - the prefetch window for the 
CardBus controller. 

And both (A) and (B) have the IO bridging window, because regardless of 
whether we see a valid CardBus prefetchable memory window with good 
alignment, we'll always see the IO ports, so we'll try to allocate that 
bridging window, except in (C) when we decide that due to the transparent 
nature, we simply don't care.

So the PCI resources make sense in all three cases, and we understand 
those. The differences in the actual Cardbus ranges also all make sense. 
So it all still boils down to the PCI layer doing everything right in 
_all_ cases, just making slightly different - but all valid - choices 
depending on essentially random details (eg the revert/debug patch case 
the "random detail" is just enabling a small incorrect alignment).

IOW, it really doesn't look like a PCI resource allocator bug. Quite the 
reverse, I'd say that in the end this whole thread points out just how 
robust the whole PCI and cardbus resource allocation is, with the code 
really very gracefully just adjusting in a sane manner to all these 
different cases.

Of course, none of that helps us with any kind of idea of what the real 
problem is. Device ordering bug in setting up PCI resources at resume? 
Perhaps just a plain bug in PCI bridge resume code (even when you resume 
things in the right order)?

And I still worry that perhaps it's just a timing bug, where having a PCI 
bridging window changes timing of various PCI accesses, and the _real_ bug 
is actually in the sound card or ethernet driver resume, which happens to 
work with one timing and not with another.

Since it's apparently STR, has anybody gotten _anything_ sane out of 
trying to enable PM_TRACE_RTC, and then doing that 

	echo 1 > /sys/power/pm_trace

because even with the (very limited) set of standard trace-points, it 
should still be able to tell which device we were trying to resume last in 
the failure case Maybe that gives some hint?

				Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

[-- Attachment #1: Type: text/plain, Size: 3636 bytes --]

On Wednesday 03 December 2008, Linus Torvalds wrote:
> Well, I think that what _would_ be generally correct, and actually
> pretty simple, is a rather different approach: just not sizing things
> behind a transparent bridge AT ALL, since it really shouldn't matter.

I've given your patch a try and the few resumes from STR I've done were 
all successful. That's not 100% conclusive yet, but a nice start.
Some info from logs etc. below.

> > Also, I would be happy to actually understand _why_ this happens.
>
> 100% agreed. I do _not_ see why it should ever matter how we set up a
> PCI bridging window - whether prefetchable or not - on a bridge that
> should be transparent. It sounds really odd. I'm wondering if there is
> something we're missing here.

The theory that it is really a resume issue and not a device layout issue 
sounds logical. Especially as everything always works correctly after a 
normal boot.

Cheers,
FJP

Below info from 3 kernels, all based on 2.6.28-rc7-91:
A) unpatched
B) with the revert/debug patch
C) with the oneliner "ignore transparent bridges" patch

AFAICT all results are probably as expected.

From lspci -vvxxx:
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge
- for A)
	I/O behind bridge: 00003000-00003fff
	Memory behind bridge: e0100000-e03fffff
	Prefetchable memory behind bridge: 0000000080000000-0000000083ffffff
- for B)
	I/O behind bridge: 00003000-00003fff
	Memory behind bridge: e0100000-e03fffff
- for C)
	Memory behind bridge: e0100000-e03fffff
02:06.0 CardBus bridge: Ricoh Co Ltd RL5c476 II
- for A)
	Memory window 0: 80000000-83fff000 (prefetchable)
	Memory window 1: 84000000-87fff000
	I/O window 0: 00003000-000030ff
	I/O window 1: 00003400-000034ff
- for B)
	Memory window 0: 84400000-847ff000 (prefetchable)
	Memory window 1: 80000000-83fff000
	I/O window 0: 00003000-000030ff
	I/O window 1: 00003400-000034ff
- for C)
	Memory window 0: 80000000-83fff000 (prefetchable)
	Memory window 1: 84000000-87fff000
	I/O window 0: 00001400-000014ff
	I/O window 1: 00001800-000018ff

From /proc/iomem:
- for A)
80000000-83ffffff : PCI Bus 0000:02
  80000000-83ffffff : PCI CardBus 0000:03
84000000-87ffffff : PCI CardBus 0000:03
88000000-88000fff : Intel Flush Page
- for B)
80000000-83ffffff : PCI CardBus 0000:03
84000000-84000fff : Intel Flush Page
84400000-847fffff : PCI CardBus 0000:03
- for C)
80000000-83ffffff : PCI CardBus 0000:03
84000000-87ffffff : PCI CardBus 0000:03
88000000-88000fff : Intel Flush Page

Attached a tarball with dmesg for all 3 kernel, including a successful 
STR/resume cycle for each (not cleaned up this time).
A) 2.6.28-rc7_nofix
B) 2.6.28-rc7_revert
C) 2.6.28-rc7_resumefix

From the last one:
pci 0000:02:06.0: CardBus bridge, secondary bus 0000:03
pci 0000:02:06.0:   IO window: 0x001400-0x0014ff
pci 0000:02:06.0:   IO window: 0x001800-0x0018ff
pci 0000:02:06.0:   PREFETCH window: 0x80000000-0x83ffffff
pci 0000:02:06.0:   MEM window: 0x84000000-0x87ffffff
pci 0000:00:1e.0: PCI bridge, secondary bus 0000:02
pci 0000:00:1e.0:   IO window: disabled
pci 0000:00:1e.0:   MEM window: 0xe0100000-0xe03fffff
pci 0000:00:1e.0:   PREFETCH window: disabled
[...]
bus: 02 index 0 mmio: [0x0-0x0]
bus: 02 index 1 mmio: [0xe0100000-0xe03fffff]
bus: 02 index 2 mmio: [0x0-0x0]
bus: 02 index 3 io port: [0x00-0xffff]
bus: 02 index 4 mmio: [0x000000-0xffffffffffffffff]
bus: 03 index 0 io port: [0x1400-0x14ff]
bus: 03 index 1 io port: [0x1800-0x18ff]
bus: 03 index 2 mmio: [0x80000000-0x83ffffff]
bus: 03 index 3 mmio: [0x84000000-0x87ffffff]


[-- Attachment #2: dmesg.tgz --]
[-- Type: application/x-tgz, Size: 32289 bytes --]

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

OOn Thursday 04 December 2008, you wrote:
> On Thu, 4 Dec 2008, Rafael J. Wysocki wrote:
> > Well, in principle it may be related to the way we handle bridges
> > during resume
>
> This is a hibernate-only issue for you, right? Or is it about regular
> suspend-to-ram too?

It is regular suspend to ram.

I feel now confident in saying that with the debug patch resume from STR 
is 100% reliable. And the two workarounds I was using to improve resume 
reliability are no longer needed:
- unloading e1000e before suspend
- using aggressive powersave setting on snd_hda_intel to ensure that
  sound controller was already sleeping before entering suspend

I don't think we have any theory yet on how those workarounds were helping 
to improve things, right?

> Well, how stable has hibernate been on that particular machine
> historically?

I cannot comment on this as I have not owned this laptop long enough.


One other thing: the ohci1394 "irq 19: nobody cared" issue is definitely 
unrelated as I just got one during a resume with the debug patch.

Cheers,
FJP

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Thu, 4 Dec 2008, Rafael J. Wysocki wrote:
> 
> Well, in principle it may be related to the way we handle bridges during
> resume

Ahh. Yes, that's possible. It's quite possible that the problem isn't 
resource allocation per se, but just the bigger complexity at resume time.

This is a hibernate-only issue for you, right? Or is it about regular 
suspend-to-ram too?

> but I really need to read some docs and compare them with the code 
> before I can say anything more about that.  Surely, nothing like this 
> issue has ever been reported before.

Well, how stable has hibernate been on that particular machine 
historically?

Because the half-revert alignment patch (ie reverting part of 5f17cf) that 
made it work for you would actually have been a non-issue in the original 
code that was pre-PCI-resource-alignment cleanup (commit 88452565).

So the patch you partially reverted was literally the one that made the 
Cardbus allocation work the _same_ way as it did historically, before 
88452565. So if the new code breaks for you, then so should the "old" code 
(ie 2.6.25 and earlier).

So the "hasn't been reported before" case may well be just another way of 
saying "hibernate has never been very reliable".

			Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Wednesday, 3 of December 2008, Linus Torvalds wrote:
> 
> On Wed, 3 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > Then, voila!, I'm not able to reproduce the hibernation-resume failure.
> > 
> > This appears to mean that:
> > (1) The sizes of the allocations and the locations of devices in the memory
> >     address space don't matter here.
> > (2) The presence and size of the prefetchable memory window don't matter here.
> > (3) What matters is the presence of non-prefetchable memory window on the
> >     supposedly transparent bridge.  Namely, if the window is there, resume from
> >     hibernation occasionally fails (again, the size of the window and the
> >     location of it in the memory address space doesn't seem to matter).
> 
> That is indeed rather odd, and very interesting. 
> 
> > So, apparently, on this box (and I guess on Frans' too) we could avoid the
> > problem if we didn't allocate the non-prefetchable memory window in
> > pci_bus_size_cardbus(), but I guess that wouldn't be generally correct.
> 
> Well, I think that what _would_ be generally correct, and actually pretty 
> simple, is a rather different approach: just not sizing things behind a 
> transparent bridge AT ALL, since it really shouldn't matter.
> 
> So if the appended patch fixes things for you, I think this might 
> potentially be the right approach.
> 
> NOTE NOTE NOTE! This patch is entirely untested, as usual. I didn't check 
> that this is necessarily the correct place to test for this, but it 
> does make sense. IOW, it _feels_ like the rigth thing.

Yes, it _looks_ sane.

> However, even if it fixes things for you, I think we're too late in the
> 2.6.28 cycle to really apply this.

Absolutely.

> So it really does make sense to consider a root bridge and a transparent 
> one to be equivalent here, since in both cases any bridge windows should 
> be irrelevant. Which is why I think this patch is interesting.
> 
> > Also, I would be happy to actually understand _why_ this happens.
> 
> 100% agreed. I do _not_ see why it should ever matter how we set up a PCI 
> bridging window - whether prefetchable or not - on a bridge that should be 
> transparent. It sounds really odd. I'm wondering if there is something 
> we're missing here.
> 
> But apart from the existence of the bridging window, the only thing that 
> it seems to affect is really just a minor layour issue. So it does seem 
> like it matters. Odd.

Well, in principle it may be related to the way we handle bridges during
resume, but I really need to read some docs and compare them with the code
before I can say anything more about that.  Surely, nothing like this issue has
ever been reported before.

Anyway, thanks for the patch, I'm going to try it tomorrow.

Best,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Wed, 3 Dec 2008, Rafael J. Wysocki wrote:
> 
> Then, voila!, I'm not able to reproduce the hibernation-resume failure.
> 
> This appears to mean that:
> (1) The sizes of the allocations and the locations of devices in the memory
>     address space don't matter here.
> (2) The presence and size of the prefetchable memory window don't matter here.
> (3) What matters is the presence of non-prefetchable memory window on the
>     supposedly transparent bridge.  Namely, if the window is there, resume from
>     hibernation occasionally fails (again, the size of the window and the
>     location of it in the memory address space doesn't seem to matter).

That is indeed rather odd, and very interesting. 

> So, apparently, on this box (and I guess on Frans' too) we could avoid the
> problem if we didn't allocate the non-prefetchable memory window in
> pci_bus_size_cardbus(), but I guess that wouldn't be generally correct.

Well, I think that what _would_ be generally correct, and actually pretty 
simple, is a rather different approach: just not sizing things behind a 
transparent bridge AT ALL, since it really shouldn't matter.

So if the appended patch fixes things for you, I think this might 
potentially be the right approach.

NOTE NOTE NOTE! This patch is entirely untested, as usual. I didn't check 
that this is necessarily the correct place to test for this, but it 
does make sense. IOW, it _feels_ like the rigth thing. However, even if it 
fixes things for you, I think we're too late in the 2.6.28 cycle to really 
apply this.

So it really does make sense to consider a root bridge and a transparent 
one to be equivalent here, since in both cases any bridge windows should 
be irrelevant. Which is why I think this patch is interesting.

> Also, I would be happy to actually understand _why_ this happens.

100% agreed. I do _not_ see why it should ever matter how we set up a PCI 
bridging window - whether prefetchable or not - on a bridge that should be 
transparent. It sounds really odd. I'm wondering if there is something 
we're missing here.

But apart from the existence of the bridging window, the only thing that 
it seems to affect is really just a minor layour issue. So it does seem 
like it matters. Odd.

			Linus

---
 drivers/pci/setup-bus.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index ea979f2..586451c 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -467,8 +467,12 @@ void __ref pci_bus_size_bridges(struct pci_bus *bus)
 		}
 	}
 
-	/* The root bus? */
-	if (!bus->self)
+	/*
+	 * We don't need to allocate PCI bridging windows
+	 * for a root bus (everything bridged) or for a
+	 * transparent one.
+	 */
+	if (!bus->self || bus->self->transparent)
 		return;
 
 	switch (bus->self->class >> 8) {

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Wednesday, 3 of December 2008, Rafael J. Wysocki wrote:
> On Wednesday, 3 of December 2008, Rafael J. Wysocki wrote:
> > On Wednesday, 3 of December 2008, Linus Torvalds wrote:
> > > 
> > > On Wed, 3 Dec 2008, Rafael J. Wysocki wrote:
> > > > 
> > > > Here's the output of 'lspci -vvxxx':
> > > 
> > > Ok, I'm not finding any documented quirks that would be memory regions, 
> > > and in fact it doesn't look like there is even any remotely likely 32-bit 
> > > valies that might be pointers in your PCI config space that look remotely 
> > > like they might be conflicting in the area of MMIO space that we allocate 
> > > PCI resources from (ie 0x88000000-0x92000000).
> > > 
> > > Of course, any odd MMIO regions might be descibed by some insane model 
> > > that doesn't look like an aligned 32-bit value, but that's unlikely.
> > > 
> > > So I'm still not seeing anything wrong in there.
> > > 
> > > > I'll run the 'pci=cbmemsize=4M' test tomorrow (need to have some sleep).
> > > 
> > > Sure. It will be interesting to see if it makes any difference.
> > 
> > It didn't help (failure in the 4th consecutive hibernation/resume cycle).
> 
> Moreover, to check if the problem may be related to the prefetch window,
> I added the appended patch on top of -rc7 (instead of the previous debug
> patch), which resulted in the following layout in /proc/iomem:
> 
> 88000000-8dffffff : PCI Bus 0000:03
>   88000000-8bffffff : PCI CardBus 0000:04
>   8c000000-8c003fff : 0000:03:0b.1
>   8c004000-8c004fff : 0000:03:0b.0
>     8c004000-8c004fff : yenta_socket
>   8c005000-8c0057ff : 0000:03:0b.1
>     8c005000-8c0057ff : firewire_ohci
>   8c005800-8c0058ff : 0000:03:0b.3
>     8c005800-8c0058ff : mmc0
>   8c400000-8c7fffff : PCI CardBus 0000:04
> 
> and the first hibernation-resume cycle failed.
> 
> Thanks,
> Rafael
> 
> ---
>  drivers/pci/setup-bus.c |   19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> Index: linux-2.6/drivers/pci/setup-bus.c
> ===================================================================
> --- linux-2.6.orig/drivers/pci/setup-bus.c
> +++ linux-2.6/drivers/pci/setup-bus.c
> @@ -353,6 +353,25 @@ static int pbus_size_mem(struct pci_bus 
>  			r_size = resource_size(r);
>  			/* For bridges size != alignment */
>  			align = resource_alignment(r);
> +			if (r->flags & IORESOURCE_PREFETCH) {
> +				resource_size_t expected_align;
> +
> +				expected_align = (i < PCI_BRIDGE_RESOURCES) ?
> +							r_size : r->start;
> +				if (align != expected_align) {
> +					dev_warn(&dev->dev,
> +						"BAR %d [%llx-%llx] "
> +						"alignment issue: flags=%lx "
> +						"align=%llx (%llx)\n", i,
> +						(unsigned long long)r->start,
> +						(unsigned long long)r->end,
> +						r->flags,
> +						(unsigned long long)align,
> +						(unsigned long long)expected_align);
> +					/* Hacky and wrong, but trying to keep things */
> +					align = expected_align;
> +				}
> +			}
>  			order = __ffs(align) - 20;
>  			if (order > 11) {
>  				dev_warn(&dev->dev, "BAR %d bad alignment %llx: "
> --

Now _that_ seems interesting.

I noticed that on this particular box my first patch is equivalent to replacing
IORESOURCE_SIZEALIGN with IORESOURCE_STARTALIGN in two places under the last
'if()' in pci_bus_size_cardbus(), so I wondered what would happen if we only
allocated the prefetchable region in there.  Following that, I did:

--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -432,12 +432,14 @@ static void pci_bus_size_cardbus(struct 
 	 */
 	if (ctrl & PCI_CB_BRIDGE_CTL_PREFETCH_MEM0) {
 		b_res[2].start = 0;
-		b_res[2].end = pci_cardbus_mem_size - 1;
+		b_res[2].end = pci_cardbus_mem_size * 2 - 1;
 		b_res[2].flags |= IORESOURCE_MEM | IORESOURCE_PREFETCH | IORESOURCE_SIZEALIGN;
 
+#if 0
 		b_res[3].start = 0;
 		b_res[3].end = pci_cardbus_mem_size - 1;
 		b_res[3].flags |= IORESOURCE_MEM | IORESOURCE_SIZEALIGN;
+#endif
 	} else {
 		b_res[3].start = 0;
 		b_res[3].end = pci_cardbus_mem_size * 2 - 1;

(well, I didn't have to allocate twice the size but that was to check if the
size of the allocation was going to matter), which resulted in the appended
/proc/iomem.

Then, voila!, I'm not able to reproduce the hibernation-resume failure.

This appears to mean that:
(1) The sizes of the allocations and the locations of devices in the memory
    address space don't matter here.
(2) The presence and size of the prefetchable memory window don't matter here.
(3) What matters is the presence of non-prefetchable memory window on the
    supposedly transparent bridge.  Namely, if the window is there, resume from
    hibernation occasionally fails (again, the size of the window and the
    location of it in the memory address space doesn't seem to matter).

So, apparently, on this box (and I guess on Frans' too) we could avoid the
problem if we didn't allocate the non-prefetchable memory window in
pci_bus_size_cardbus(), but I guess that wouldn't be generally correct.

Also, I would be happy to actually understand _why_ this happens.

Thanks,
Rafael

---
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000e0000-000eedff : reserved
000eee00-000eefff : ACPI Non-volatile Storage
000ef000-000fffff : reserved
00100000-7f74ffff : System RAM
  00200000-00450486 : Kernel code
  00450487-00603c37 : Kernel data
  00678000-00784d3b : Kernel bss
7f750000-7fffffff : reserved
  7f750000-7f75ffff : pnp 00:00
  7f760000-7f7fffff : pnp 00:00
  7f800000-7fffffff : pnp 00:00
88000000-8fffffff : PCI Bus 0000:03 <-- the prefetchable window
  88000000-8fffffff : PCI CardBus 0000:04 <-- the prefetchable window
90000000-900fffff : PCI Bus 0000:03
  90000000-90003fff : 0000:03:0b.1
  90004000-90004fff : 0000:03:0b.0
    90004000-90004fff : yenta_socket
  90005000-900057ff : 0000:03:0b.1
    90005000-900057ff : firewire_ohci
  90005800-900058ff : 0000:03:0b.3
    90005800-900058ff : mmc0
90100000-9017ffff : 0000:00:02.1
90180000-90183fff : 0000:00:1b.0
  90180000-90183fff : ICH HD audio
90184000-90184fff : Intel Flush Page
90400000-907fffff : PCI CardBus 0000:04 <-- last interesting line
e0000000-efffffff : 0000:00:02.0
  e0000000-e07affff : vesafb
f0000000-f3ffffff : PCI MMCONFIG 0
  f0000000-f3ffffff : pnp 00:01
fec00000-fec17fff : reserved
  fec00000-fec17fff : pnp 00:00
    fec00000-fec00fff : IOAPIC 0
fec20000-fec27fff : reserved
  fec20000-fec27fff : pnp 00:00
fed00000-fed003ff : HPET 0
  fed00000-fed003ff : reserved
fed14000-fed19fff : reserved
  fed14000-fed19fff : pnp 00:00
fed1c000-fed8ffff : reserved
  fed1c000-fed1ffff : pnp 00:00
  fed20000-fed3ffff : pnp 00:00
  fed45000-fed8ffff : pnp 00:00
feda0000-fedbffff : reserved
  feda0000-fedbffff : pnp 00:00
fee00000-fee00fff : Local APIC
  fee00000-fee00fff : reserved
    fee00000-fee00fff : pnp 00:00
ff800000-ff8fffff : PCI Bus 0000:02
  ff8fe000-ff8fffff : 0000:02:00.0
    ff8fe000-ff8fffff : iwlagn
ff900000-ff9fffff : PCI Bus 0000:01
  ff9e0000-ff9fffff : 0000:01:00.0
    ff9e0000-ff9fffff : e1000e
ffa00000-ffbfffff : reserved
  ffa00000-ffbfffff : pnp 00:00
ffc3f800-ffc3fbff : 0000:00:1f.2
  ffc3f800-ffc3fbff : ahci
ffc3fc00-ffc3ffff : 0000:00:1d.7
  ffc3fc00-ffc3ffff : ehci_hcd
ffc40000-ffc7ffff : 0000:00:02.0
ffc80000-ffcfffff : 0000:00:02.0
ffd00000-ffffffff : reserved
  ffd00000-ffffffff : pnp 00:00

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Wednesday, 3 of December 2008, Rafael J. Wysocki wrote:
> On Wednesday, 3 of December 2008, Linus Torvalds wrote:
> > 
> > On Wed, 3 Dec 2008, Rafael J. Wysocki wrote:
> > > 
> > > Here's the output of 'lspci -vvxxx':
> > 
> > Ok, I'm not finding any documented quirks that would be memory regions, 
> > and in fact it doesn't look like there is even any remotely likely 32-bit 
> > valies that might be pointers in your PCI config space that look remotely 
> > like they might be conflicting in the area of MMIO space that we allocate 
> > PCI resources from (ie 0x88000000-0x92000000).
> > 
> > Of course, any odd MMIO regions might be descibed by some insane model 
> > that doesn't look like an aligned 32-bit value, but that's unlikely.
> > 
> > So I'm still not seeing anything wrong in there.
> > 
> > > I'll run the 'pci=cbmemsize=4M' test tomorrow (need to have some sleep).
> > 
> > Sure. It will be interesting to see if it makes any difference.
> 
> It didn't help (failure in the 4th consecutive hibernation/resume cycle).

Moreover, to check if the problem may be related to the prefetch window,
I added the appended patch on top of -rc7 (instead of the previous debug
patch), which resulted in the following layout in /proc/iomem:

88000000-8dffffff : PCI Bus 0000:03
  88000000-8bffffff : PCI CardBus 0000:04
  8c000000-8c003fff : 0000:03:0b.1
  8c004000-8c004fff : 0000:03:0b.0
    8c004000-8c004fff : yenta_socket
  8c005000-8c0057ff : 0000:03:0b.1
    8c005000-8c0057ff : firewire_ohci
  8c005800-8c0058ff : 0000:03:0b.3
    8c005800-8c0058ff : mmc0
  8c400000-8c7fffff : PCI CardBus 0000:04

and the first hibernation-resume cycle failed.

Thanks,
Rafael

---
 drivers/pci/setup-bus.c |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

Index: linux-2.6/drivers/pci/setup-bus.c
===================================================================
--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -353,6 +353,25 @@ static int pbus_size_mem(struct pci_bus 
 			r_size = resource_size(r);
 			/* For bridges size != alignment */
 			align = resource_alignment(r);
+			if (r->flags & IORESOURCE_PREFETCH) {
+				resource_size_t expected_align;
+
+				expected_align = (i < PCI_BRIDGE_RESOURCES) ?
+							r_size : r->start;
+				if (align != expected_align) {
+					dev_warn(&dev->dev,
+						"BAR %d [%llx-%llx] "
+						"alignment issue: flags=%lx "
+						"align=%llx (%llx)\n", i,
+						(unsigned long long)r->start,
+						(unsigned long long)r->end,
+						r->flags,
+						(unsigned long long)align,
+						(unsigned long long)expected_align);
+					/* Hacky and wrong, but trying to keep things */
+					align = expected_align;
+				}
+			}
 			order = __ffs(align) - 20;
 			if (order > 11) {
 				dev_warn(&dev->dev, "BAR %d bad alignment %llx: "

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Wednesday, 3 of December 2008, Linus Torvalds wrote:
> 
> On Wed, 3 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > Here's the output of 'lspci -vvxxx':
> 
> Ok, I'm not finding any documented quirks that would be memory regions, 
> and in fact it doesn't look like there is even any remotely likely 32-bit 
> valies that might be pointers in your PCI config space that look remotely 
> like they might be conflicting in the area of MMIO space that we allocate 
> PCI resources from (ie 0x88000000-0x92000000).
> 
> Of course, any odd MMIO regions might be descibed by some insane model 
> that doesn't look like an aligned 32-bit value, but that's unlikely.
> 
> So I'm still not seeing anything wrong in there.
> 
> > I'll run the 'pci=cbmemsize=4M' test tomorrow (need to have some sleep).
> 
> Sure. It will be interesting to see if it makes any difference.

It didn't help (failure in the 4th consecutive hibernation/resume cycle).

The patched kernel still hibernates and resumes without problems.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Wed, 3 Dec 2008, Rafael J. Wysocki wrote:
> 
> Here's the output of 'lspci -vvxxx':

Ok, I'm not finding any documented quirks that would be memory regions, 
and in fact it doesn't look like there is even any remotely likely 32-bit 
valies that might be pointers in your PCI config space that look remotely 
like they might be conflicting in the area of MMIO space that we allocate 
PCI resources from (ie 0x88000000-0x92000000).

Of course, any odd MMIO regions might be descibed by some insane model 
that doesn't look like an aligned 32-bit value, but that's unlikely.

So I'm still not seeing anything wrong in there.

> I'll run the 'pci=cbmemsize=4M' test tomorrow (need to have some sleep).

Sure. It will be interesting to see if it makes any difference.

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Wednesday, 3 of December 2008, Linus Torvalds wrote:
> 
> On Wed, 3 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > > So are you saying that the unpatched kernel still reliably doesn't 
> > > hibernate for you, while the (arguably _incorrect_) patched kernel 
> > > reliably does hibernate?
> > 
> > Yes, I am.
> 
> So see what happens if you add
> 
> 	pci=cbmemsize=4M
> 
> to make the cardbus allocations smaller. Perhaps that will just change the 
> allocations enough that now it doesn't cover something else.
> 
> Oh, and please do a "lspci -vvxxx" (as root) too so that I can see the 
> actual values in your PCI config space. We have two quirks already 
> triggering for you:
> 
>   pci 0000:00:1f.0: quirk: region d800-d87f claimed by ICH6 ACPI/GPIO/TCO
>   pci 0000:00:1f.0: quirk: region eec0-eeff claimed by ICH6 GPIO
> 
> but I'm maybe there's another one missing.

Here's the output of 'lspci -vvxxx':

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: [e0] Vendor Specific Information <?>
	Kernel driver in use: agpgart-intel
	Kernel modules: intel-agp
00: 86 80 a0 27 06 00 90 20 03 00 00 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
40: 01 90 d1 fe 01 40 d1 fe 05 00 00 f0 01 80 d1 fe
50: 00 00 30 00 19 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 10 11 11 00 00 11 33 00 ff 03 00 00 80 4a b8 00
a0: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 09 00 09 71 23 25 0a a1 0e 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 05 00 10 00 00 00

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
	Subsystem: Toshiba America Info Systems Device 0022
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at ffc80000 (32-bit, non-prefetchable) [size=512K]
	Region 1: I/O ports at cff8 [size=8]
	Region 2: Memory at e0000000 (32-bit, prefetchable) [size=256M]
	Region 3: Memory at ffc40000 (32-bit, non-prefetchable) [size=256K]
	Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
		Address: 00000000  Data: 0000
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel modules: intelfb
00: 86 80 a2 27 07 00 90 00 03 00 00 03 00 00 80 00
10: 00 00 c8 ff f9 cf 00 00 08 00 00 e0 00 00 c4 ff
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 22 00
30: 00 00 00 00 90 00 00 00 00 00 00 00 0a 01 00 00
40: 00 00 00 00 48 00 00 00 09 00 09 71 23 25 0a a1
50: 0e 00 30 00 19 00 00 00 00 00 00 00 00 00 80 7f
60: 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 05 d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 01 00 22 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 64 34 00 00 00 00 86 0f 05 00 00 00 00 00

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
	Subsystem: Toshiba America Info Systems Device 0022
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Region 0: Memory at 88100000 (32-bit, non-prefetchable) [disabled] [size=512K]
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 86 80 a6 27 00 00 90 00 03 00 80 03 00 00 80 00
10: 00 00 10 88 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 22 00
30: 00 00 00 00 d0 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 48 00 00 00 09 00 09 71 23 25 0a a1
50: 0e 00 30 00 19 00 00 00 00 00 00 00 00 00 80 7f
60: 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 01 00 22 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 64 34 00 00 00 00 86 0f 05 00 00 00 00 00

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 22
	Region 0: Memory at 88180000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100] Virtual Channel <?>
	Capabilities: [130] Root Complex Link <?>
	Kernel driver in use: HDA Intel
	Kernel modules: snd-hda-intel
00: 86 80 d8 27 06 00 10 00 02 00 03 04 08 00 00 00
10: 04 00 18 88 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 01 00 00
40: 01 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00
50: 01 60 42 c8 00 00 00 00 00 00 00 00 00 00 00 00
60: 05 70 80 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 10 00 91 00 00 00 00 00 00 08 10 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00

00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 0000b000-0000bfff
	Memory behind bridge: ff900000-ff9fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v1) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
			ExtTag- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
			ClockPM- Suprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
		Address: fee0300c  Data: 4161
	Capabilities: [90] Subsystem: Toshiba America Info Systems Device 0001
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [100] Virtual Channel <?>
	Capabilities: [180] Root Complex Link <?>
	Kernel driver in use: pcieport-driver
	Kernel modules: shpchp
00: 86 80 d0 27 07 04 10 00 02 00 04 06 08 00 81 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 b0 b0 00 00
20: 90 ff 90 ff f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 00 00
40: 10 80 41 00 c0 0f 00 00 00 00 10 00 11 2c 11 01
50: 40 00 11 30 60 05 00 00 00 00 40 01 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 05 90 01 00 0c 30 e0 fe 61 41 00 00 00 00 00 00
90: 0d a0 00 00 79 11 01 00 00 00 00 00 00 00 00 00
a0: 01 00 02 c8 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 80 00 11 80 00 00 00 00
e0: 00 0f c7 00 06 07 08 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00

00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	Memory behind bridge: ff800000-ff8fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v1) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
			ExtTag- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #3, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
			ClockPM- Suprise- LLActRep+ BwNot-
		LnkCtl:	ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
		Address: fee0300c  Data: 4169
	Capabilities: [90] Subsystem: Toshiba America Info Systems Device 0001
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [100] Virtual Channel <?>
	Capabilities: [180] Root Complex Link <?>
	Kernel driver in use: pcieport-driver
	Kernel modules: shpchp
00: 86 80 d4 27 07 04 10 00 02 00 04 06 08 00 81 00
10: 00 00 00 00 00 00 00 00 00 02 02 00 f0 00 00 20
20: 80 ff 80 ff f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 03 00 00
40: 10 80 41 00 c0 0f 00 00 00 00 11 00 11 2c 11 03
50: 43 00 11 30 60 05 00 00 00 00 40 01 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 05 90 01 00 0c 30 e0 fe 69 41 00 00 00 00 00 00
90: 0d a0 00 00 79 11 01 00 00 00 00 00 00 00 00 00
a0: 01 00 02 c8 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 80 00 11 80 00 00 00 00
e0: 00 0f c7 00 06 07 08 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00

00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 23
	Region 4: I/O ports at afe0 [size=32]
	Kernel driver in use: uhci_hcd
	Kernel modules: uhci-hcd
00: 86 80 c8 27 05 00 80 02 02 00 03 0c 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: e1 af 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 2f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00

00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 19
	Region 4: I/O ports at af80 [size=32]
	Kernel driver in use: uhci_hcd
	Kernel modules: uhci-hcd
00: 86 80 c9 27 05 00 80 02 02 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 81 af 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 02 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 2f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00

00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin C routed to IRQ 18
	Region 4: I/O ports at af60 [size=32]
	Kernel driver in use: uhci_hcd
	Kernel modules: uhci-hcd
00: 86 80 ca 27 05 00 80 02 02 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 61 af 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 03 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 2f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00

00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin D routed to IRQ 16
	Region 4: I/O ports at af40 [size=32]
	Kernel driver in use: uhci_hcd
	Kernel modules: uhci-hcd
00: 86 80 cb 27 05 00 80 02 02 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 41 af 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 04 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 2f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00

00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 23
	Region 0: Memory at ffc3fc00 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Debug port: BAR=1 offset=00a0
	Kernel driver in use: ehci_hcd
	Kernel modules: ehci-hcd
00: 86 80 cc 27 06 00 90 02 02 20 03 0c 00 00 00 00
10: 00 fc c3 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 01 58 c2 c9 00 00 00 00 0a 00 a0 20 00 00 00 00
60: 20 20 ff 01 00 00 00 00 01 00 00 00 00 00 08 c0
70: 00 00 d7 3f 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 11 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 aa ff 00 ff 00 ff 00 20 00 00 88
e0: 00 00 00 00 db b6 6d 00 00 00 00 00 00 00 00 00
f0: 00 80 00 09 88 85 40 00 86 0f 02 00 06 17 02 20

00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) (prog-if 01 [Subtractive decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Bus: primary=00, secondary=03, subordinate=07, sec-latency=32
	I/O behind bridge: 00001000-00001fff
	Memory behind bridge: 88000000-880fffff
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [50] Subsystem: Toshiba America Info Systems Device 0001
00: 86 80 48 24 07 00 10 00 e2 01 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 03 07 20 10 10 80 22
20: 00 88 00 88 f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 12 00 00
50: 0d 00 00 00 79 11 01 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00

00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: [e0] Vendor Specific Information <?>
	Kernel modules: iTCO_wdt
00: 86 80 b9 27 07 00 10 02 02 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
40: 01 d8 00 00 80 00 00 00 c1 ee 00 00 10 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 80 80 80 80 91 00 00 00 80 80 80 80 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 2c 81 06 7c 00 00 00 00 00 00 00 00 00
90: e1 01 0c 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 80 06 00 00 00 00 00 00 13 1c 0a 00 00 03 00 00
b0: 00 00 f0 00 00 00 00 00 00 00 01 04 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 33 22 11 00 67 45 00 00 c0 f0 00 00 00 00 00 00
e0: 09 00 0c 10 b4 02 24 17 00 00 00 00 00 00 00 00
f0: 01 c0 d1 fe 00 00 00 00 86 0f 02 00 00 00 00 00

00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 02) (prog-if 01 [AHCI 1.0])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 317
	Region 0: I/O ports at af38 [size=8]
	Region 1: I/O ports at af34 [size=4]
	Region 2: I/O ports at af28 [size=8]
	Region 3: I/O ports at af24 [size=4]
	Region 4: I/O ports at af10 [size=16]
	Region 5: Memory at ffc3f800 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
		Address: fee0300c  Data: 4179
	Capabilities: [70] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: ahci
	Kernel modules: ahci
00: 86 80 c5 27 07 04 b0 02 02 01 06 01 00 00 00 00
10: 39 af 00 00 35 af 00 00 29 af 00 00 25 af 00 00
20: 11 af 00 00 00 f8 c3 ff 00 00 00 00 79 11 01 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 02 00 00
40: 07 a3 00 00 00 00 00 00 01 00 01 00 00 00 00 00
50: 00 00 00 00 10 10 04 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 01 00 02 40 00 00 00 00 00 00 00 00 00 00 00 00
80: 05 70 01 00 0c 30 e0 fe 79 41 00 00 00 00 00 00
90: 40 00 11 10 80 01 00 5a 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00

01:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 316
	Region 0: Memory at ff9e0000 (32-bit, non-prefetchable) [size=128K]
	Region 2: I/O ports at bfe0 [size=32]
	Capabilities: [c8] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
		Address: 00000000fee0100c  Data: 41d1
	Capabilities: [e0] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <128ns, L1 <64us
			ClockPM+ Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100] Advanced Error Reporting <?>
	Capabilities: [140] Device Serial Number ac-dd-af-ff-ff-7e-1c-00
	Kernel driver in use: e1000e
	Kernel modules: e1000e
00: 86 80 9a 10 07 04 10 00 00 00 00 02 10 00 00 00
10: 00 00 9e ff 00 00 00 00 e1 bf 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 c8 00 00 00 00 00 00 00 0a 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 01 d0 22 c8 00 20 00 0f
d0: 05 e0 81 00 0c 10 e0 fe 00 00 00 00 d1 41 00 00
e0: 10 00 01 00 c1 0c 00 00 10 28 1a 00 11 1c 07 00
f0: 40 01 11 10 00 00 00 00 00 00 00 00 00 00 00 00

02:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)
	Subsystem: Intel Corporation Device 1101
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 315
	Region 0: Memory at ff8fe000 (64-bit, non-prefetchable) [size=8K]
	Capabilities: [c8] Power Management version 3
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
		Address: 00000000fee0100c  Data: 41d9
	Capabilities: [e0] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 unlimited
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <128ns, L1 <64us
			ClockPM+ Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100] Advanced Error Reporting <?>
	Capabilities: [140] Device Serial Number e7-38-c3-ff-ff-3b-1f-00
	Kernel driver in use: iwlagn
	Kernel modules: iwlagn
00: 86 80 29 42 06 00 10 00 61 00 80 02 08 00 00 00
10: 04 e0 8f ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 01 11
30: 00 00 00 00 c8 00 00 00 00 00 00 00 0b 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 01 d0 23 c8 00 00 00 0d
d0: 05 e0 81 00 0c 10 e0 fe 00 00 00 00 d9 41 00 00
e0: 10 00 01 00 c0 8e 00 00 10 08 19 00 11 1c 07 00
f0: 43 01 11 10 00 00 00 00 00 00 00 00 00 00 00 00

03:0b.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 168, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 21
	Region 0: Memory at 88004000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=03, secondary=04, subordinate=07, sec-latency=176
	Memory window 0: 88400000-887ff000 (prefetchable)
	Memory window 1: 88800000-88bff000
	I/O window 0: 00001000-000010ff
	I/O window 1: 00001400-000014ff
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
	16-bit legacy interface ports at 0001
	Kernel driver in use: yenta_cardbus
	Kernel modules: yenta_socket
00: 4c 10 39 80 07 00 10 02 00 00 07 06 10 a8 82 00
10: 00 40 00 88 a0 00 00 02 03 04 07 b0 00 00 40 88
20: 00 f0 7f 88 00 00 80 88 00 f0 bf 88 00 10 00 00
30: fc 10 00 00 00 14 00 00 fc 14 00 00 ff 01 c0 05
40: 79 11 01 00 01 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 60 d0 00 08 19 00 b3 02 00 00 0f 00 22 10 aa 01
90: c0 04 64 60 00 00 00 00 00 00 00 00 00 00 00 00
a0: 01 00 02 7e 00 00 c0 00 00 00 00 00 00 00 00 00
b0: 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 08 3e c5 ef a8 9e 01 c2 00 00 00 00 00 00 00 00

03:0b.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller (prog-if 10 [OHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (500ns min, 1000ns max), Cache Line Size: 32 bytes
	Interrupt: pin B routed to IRQ 20
	Region 0: Memory at 88005000 (32-bit, non-prefetchable) [size=2K]
	Region 1: Memory at 88000000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME+
	Kernel driver in use: firewire_ohci
	Kernel modules: firewire-ohci
00: 4c 10 3a 80 06 00 10 02 00 10 00 0c 08 40 80 00
10: 00 50 00 88 00 00 00 88 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 44 00 00 00 00 00 00 00 ff 02 02 04
40: 00 00 00 00 01 00 02 7e 00 80 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00
f0: 10 08 00 00 82 00 00 00 79 11 01 00 00 00 00 00

03:0b.3 SD Host controller: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller (prog-if 01)
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (1750ns min, 1000ns max), Cache Line Size: 32 bytes
	Interrupt: pin D routed to IRQ 23
	Region 0: Memory at 88005800 (32-bit, non-prefetchable) [size=256]
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: sdhci-pci
	Kernel modules: sdhci-pci
00: 4c 10 3c 80 06 00 10 02 00 01 05 08 08 40 80 00
10: 00 58 00 88 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 ff 04 07 04
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 01 00 02 7e 00 00 00 00 63 00 00 00 79 11 01 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I'll run the 'pci=cbmemsize=4M' test tomorrow (need to have some sleep).

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Wed, 3 Dec 2008, Rafael J. Wysocki wrote:
> 
> Hm, what about (from the copy of /proc/iomem without the patch at
> http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/rc7-nopatch/iomem):
> 
> 88000000-8bffffff : PCI Bus 0000:03
>   88000000-8bffffff : PCI CardBus 0000:04
> 8c000000-91ffffff : PCI Bus 0000:03
>   8c000000-8fffffff : PCI CardBus 0000:04
> 
> (1) Why two ranges are allocated for 0000:03 without the patch while there is
>     only one range with the patch:
> 
> 88000000-880fffff : PCI Bus 0000:03

So look at the lspci information that has more details for info on this.

Basically, a Cardbus controller (as well as a PCI bridge) has _two_ very 
different MMIO windows - one for prefetchable MMIO, and one for 
non-prefetchable.

And the windows should match up, although it's always ok to map a 
prefetchable region in a non-prefetchable window (although you may lose 
some performance, since the upstream will now not be able to prefetch).

And it's not really different, exactly because 00:1e.0 is a transparent 
bridge. That "transparency" means that there is an implied decoding window 
DESPITE a lack of an explicit one - it may just be a few PCI cycles slower 
(or not, depending on how the bridge is implemented. It's probably 
technically quite ok for a transparent bridge to ignore its IO/MEM window 
contents entirely).

So those "PCI Bus 0000:03" windows are technically irrelevant, except as a 
possible performance improvement. The bridge will forward PCI cycles 
whether they are there or not. That is what "transparent" means.

> (2) Why are they so large without the patch while with the patch they are much
>     smaller (O(2^28) vs O(2^21) if I'm not mistaken)?

Because without the patch, we'll size the PCI bridge windows according to 
the default setup of the CardBus controller, namely:

 - two IO regions of size 'pci_cardbus_io_size' (256 bytes)

 - one prefetchable and one non-prefetchable IO region of size 
   'pci_cardbus_mem_size' (64MB by default, you can change it with 
   the 'pci=cbmemsize=xyz' kernel command line parameter but nobody ever 
   does)

See pci_bus_size_cardbus() in drivers/pci/setup-bus.c for details.

HOWEVER - when the alignment is wrong, we skip all that, and don't set up 
the CardBus regions there at all, because the whole "pbus_size_mem()" 
thing will just give up.

And then what happens is that we won't set up the CardBus bridge during 
PCI bus setup AT ALL, but later, by the Yenta code. And that one will try 
to do something else entirely.

[ And yes, if you think that it might be a good idea to try to share the 
  code and not have two different cardbus sizing logics, I'm not going to 
  argue against that AT ALL! ]

In the yenta code, we don't try to to just have a fixed maximum size, 
because that code is literally designed to be a fallback case for when the 
PCI sizing fails (ie literally "oops, we had so little space that we 
couldn't use the default max size!" case).

For the yenta code, see drivers/pcmcia/yenta_socket.c ("Yenta" is just the 
name for the CardBus standard programming model), and notice all the logic 
there, see:

 - BRIDGE_MEM_MAX/ACC/MIN and BRIDGE_IO_MAX/ACC/MIN for "max", 
   "acceptable" and "minimum" values respectively.

   Realize thatt he "MAX" value is just 4MB, which is obviously smaller 
   than the 64MB mentioned above, and that's exactly because this is 
   assumed to be a "uhhuh, we ran out of space" case.

 - See yenta_allocate_res() and the helper functions above it that in 
   addition try to shrink the window further if it doesn't fit.

 - Notice how the Yenta code - unlike the generic PCI code - does _not_ 
   try to allocate parent PCI bridge memory window resources, so if we 
   fall into this case, we're going to depend on previously set up windows 
   and/or the fact that a transparent bridge doesn't need them.

So this explains why in one case you'd see a 64M resource, and in another 
just a 4M resource.

_Most_ cardbus cards by far only need a few kB of IOMEM resources, but 
there are some crazy people who do CardBus graphics cards and/or video 
capture cards, and they really do want 32MB+ of MMIO, which is why we try 
to get such a big CardBus MMIO window by default.

As mentioned, you could try to just use

	pci=cbmemsize=4M

on the kernel command line, and see if that also hides the bug. It's 
entirely possible that your suspend/resume problem is not so much about 
the cardbus allocation itself, as about some other memory area that wants 
to use it (eg hidden RAM used by the bios SMM code, whatever).

> (3) Why are they overlapping with the ranges for CardBus 0000:04, although
>     without the patch they aren't?  Is that actually correct at all?

See the earlier explanation of the topology, and realize the 
overlappingness is actually _required_ in order for a PCI bridge to work, 
and forward the PCI cycles to the right lower bus.

But then, with a transparent bridge, if nobody else overlaps, it will 
do what's called "negative decode", which just means that "if nobody else 
said they wanted this PCI cycle, I'll decode it and forward it to the 
lower bus", so a transparent bridge doesn't _need_ the overlap.

Do

	/sbin/lspci -t

to understand the relationship, in particular see how device 0:1e.0 is the 
one that bridges _to_ that CardBus controller.

See the comments about "topology" in my previous email.

> > So in many ways, the debug patch that gets the alignment wrong (on 
> > purpose) is really the inferior one. Plain -rc7 seems to do everything 
> > right.
> 
> Well, I'm not sure ...

I'm pretty sure. 

The fact that you then have hibernation issues is almost certainly due to 
something else. Most likely something else that we don't know about from a 
resource angle that now got "hidden" by the fact that we programmed the 
0:1e.0 bridge to forward to the cardbus controller rather than to some 
insane power management chip.

It's why we have all those quirks in drivers/pci/quirks.c. It's very 
possible that your chipset is missing some quirk.

> > So are you saying that the unpatched kernel still reliably doesn't 
> > hibernate for you, while the (arguably _incorrect_) patched kernel 
> > reliably does hibernate?
> 
> Yes, I am.

So see what happens if you add

	pci=cbmemsize=4M

to make the cardbus allocations smaller. Perhaps that will just change the 
allocations enough that now it doesn't cover something else.

Oh, and please do a "lspci -vvxxx" (as root) too so that I can see the 
actual values in your PCI config space. We have two quirks already 
triggering for you:

  pci 0000:00:1f.0: quirk: region d800-d87f claimed by ICH6 ACPI/GPIO/TCO
  pci 0000:00:1f.0: quirk: region eec0-eeff claimed by ICH6 GPIO

but I'm maybe there's another one missing.

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Wednesday, 3 of December 2008, Rafael J. Wysocki wrote:
> On Wednesday, 3 of December 2008, Linus Torvalds wrote:
> > 
> > On Tue, 2 Dec 2008, Rafael J. Wysocki wrote:
> > > 
> > > * dmesg output including one hibernation-resume cycle from 2.6.28-rc7 with the
> > >   debug patch (appended for completness):
> > > 
> > >   http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7-patched-prep.log
> > > 
> > > * dmesg output including one hibernation-resume cycle from 2.6.28-rc7 without
> > >   the debug patch:
> > > 
> > >   http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7-nopatch-prep.log
> > 
> > As with Frans, the debug patch seems to make no difference what-so-ever. 
> > Yes, the cardbus regions get allocated differently, but they're fine in 
> > either case, and arguably (exactly as with Frans) the debug patch actually 
> > makes things uglier by actively getting the alignment wrong, and skipping 
> > cardbus setup until later.
> 
> Hm, what about (from the copy of /proc/iomem without the patch at
> http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/rc7-nopatch/iomem):
> 
> 88000000-8bffffff : PCI Bus 0000:03
>   88000000-8bffffff : PCI CardBus 0000:04
> 8c000000-91ffffff : PCI Bus 0000:03
>   8c000000-8fffffff : PCI CardBus 0000:04
> 
> (1) Why two ranges are allocated for 0000:03 without the patch while there is
>     only one range with the patch:
> 
> 88000000-880fffff : PCI Bus 0000:03
> 
>     (copy of the file at
>     http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/rc7-patched/iomem)?
>     That seems to look like a difference to me.

OK, I see why this happens.

> (2) Why are they so large without the patch while with the patch they are much
>     smaller (O(2^28) vs O(2^21) if I'm not mistaken)?

I don't see why this should happen, though.  Even if the prefetch window is
discarded, the MEM window seems to be much wider without the patch.

> (3) Why are they overlapping with the ranges for CardBus 0000:04, although
>     without the patch they aren't?  Is that actually correct at all?

OK, I see why this happens too.

Sorry for the noise,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Wednesday, 3 of December 2008, Rafael J. Wysocki wrote:
> On Wednesday, 3 of December 2008, Linus Torvalds wrote:
> > 
> > So are you saying that the unpatched kernel still reliably doesn't 
> > hibernate for you, while the (arguably _incorrect_) patched kernel 
> > reliably does hibernate?
> 
> Yes, I am.

To be more precise, the patched kernel resumes reliably (100% of the time)
while the plain -rc7 doesn't.  Both hibernate (ie. create the image and save
it) reliably.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Wednesday, 3 of December 2008, Linus Torvalds wrote:
> 
> On Tue, 2 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > * dmesg output including one hibernation-resume cycle from 2.6.28-rc7 with the
> >   debug patch (appended for completness):
> > 
> >   http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7-patched-prep.log
> > 
> > * dmesg output including one hibernation-resume cycle from 2.6.28-rc7 without
> >   the debug patch:
> > 
> >   http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7-nopatch-prep.log
> 
> As with Frans, the debug patch seems to make no difference what-so-ever. 
> Yes, the cardbus regions get allocated differently, but they're fine in 
> either case, and arguably (exactly as with Frans) the debug patch actually 
> makes things uglier by actively getting the alignment wrong, and skipping 
> cardbus setup until later.

Hm, what about (from the copy of /proc/iomem without the patch at
http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/rc7-nopatch/iomem):

88000000-8bffffff : PCI Bus 0000:03
  88000000-8bffffff : PCI CardBus 0000:04
8c000000-91ffffff : PCI Bus 0000:03
  8c000000-8fffffff : PCI CardBus 0000:04

(1) Why two ranges are allocated for 0000:03 without the patch while there is
    only one range with the patch:

88000000-880fffff : PCI Bus 0000:03

    (copy of the file at
    http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/rc7-patched/iomem)?
    That seems to look like a difference to me.

(2) Why are they so large without the patch while with the patch they are much
    smaller (O(2^28) vs O(2^21) if I'm not mistaken)?

(3) Why are they overlapping with the ranges for CardBus 0000:04, although
    without the patch they aren't?  Is that actually correct at all?

> That's what your patch (without debugging) should have resulted in too, 
> except you'd not have seen the "bad alignment flags" printout, of course 
> (but you probably would have seen the "bad alignment 0: [...]" one).

Yes, I saw that:

bad alignment flags 21200 4000000 (0)
pci 0000:03:0b.0: BAR 9 bad alignment 0: [0x000000-0x3ffffff]
bad alignment flags 20200 4000000 (0)
pci 0000:03:0b.0: BAR 10 bad alignment 0: [0x000000-0x3ffffff]

> In fact, I'm starting to think I know why we set up the prefetch window 
> without the patch, and why we don't with it - because with the patch, the 
> PCI code ends up never seeing any valid prefetchable region for the 
> cardbus controller at all, so it never even bothers to try to set up a 
> prefetchable window.
> 
> So in many ways, the debug patch that gets the alignment wrong (on 
> purpose) is really the inferior one. Plain -rc7 seems to do everything 
> right.

Well, I'm not sure ...

> > * diff between the two:
> > 
> >   http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7_nopatch-rc7_patched.diff
> 
> Gaah. Using "-U 0" is likely the least readable form of diffs there 
> exists, even if it makes the diff smaller.

Sorry.

To me it's more readable this way, but well.

> > This part of the diff  (+ is the patched one) seems to be particularly
> > interesting to me, especially the overlapping MEM windows for 0000:00:1e.0 and
> > 0000:03:0b.0 (may that be the reason for the observed failures?):
> 
> No, those are very much on purpose. 
> 
> Device 0000:00:1e.0 is the PCI bridge that bridges to PCI bus#3, so the 
> MEM window is very much intentional - exactly because MMIO goes through 
> that PCI bridge bus to get to bus#3, which is where the cardbus controller 
> is.
> 
> IOW, the topology is as follows: 
>  - CPU is on the root bus (bus #0)
>  - device 00:1e.0 is the PCI bridge to bus #3
>  - device 03:0b.0 is the CardBus bridge (to bus #4)
> and any actual cardbus cards (if you had any) would be on that bus #4, so 
> they'd be named "04:xx.y".
> 
> Now, that PCI bridge 00:1e.0 is a transparent bridge (aka "[Subtractive 
> decode]" in your lspci output - as compared to the other bridges that say 
> "[Normal decode]"), which means that you don't actually _have_ to set up 
> any MMIO window on them, since the bridge will forward _any_ PCI cycles 
> that don't get responded to by any other PCI device.
> 
> But having an explicit window is still generally a good idea, since it 
> should allow the PCI bridge to pick up the PCI cycles earlier (no need to 
> wait to see if others respond to it), and possibly allows for better 
> prefetching behavior. So again, the dmesg and the PCI layout actually 
> looks _better_ without the hacky patch.
> 
> So are you saying that the unpatched kernel still reliably doesn't 
> hibernate for you, while the (arguably _incorrect_) patched kernel 
> reliably does hibernate?

Yes, I am.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Tue, 2 Dec 2008, Rafael J. Wysocki wrote:
> 
> * dmesg output including one hibernation-resume cycle from 2.6.28-rc7 with the
>   debug patch (appended for completness):
> 
>   http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7-patched-prep.log
> 
> * dmesg output including one hibernation-resume cycle from 2.6.28-rc7 without
>   the debug patch:
> 
>   http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7-nopatch-prep.log

As with Frans, the debug patch seems to make no difference what-so-ever. 
Yes, the cardbus regions get allocated differently, but they're fine in 
either case, and arguably (exactly as with Frans) the debug patch actually 
makes things uglier by actively getting the alignment wrong, and skipping 
cardbus setup until later.

That's what your patch (without debugging) should have resulted in too, 
except you'd not have seen the "bad alignment flags" printout, of course 
(but you probably would have seen the "bad alignment 0: [...]" one).

In fact, I'm starting to think I know why we set up the prefetch window 
without the patch, and why we don't with it - because with the patch, the 
PCI code ends up never seeing any valid prefetchable region for the 
cardbus controller at all, so it never even bothers to try to set up a 
prefetchable window.

So in many ways, the debug patch that gets the alignment wrong (on 
purpose) is really the inferior one. Plain -rc7 seems to do everything 
right.

> * diff between the two:
> 
>   http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7_nopatch-rc7_patched.diff

Gaah. Using "-U 0" is likely the least readable form of diffs there 
exists, even if it makes the diff smaller.

> This part of the diff  (+ is the patched one) seems to be particularly
> interesting to me, especially the overlapping MEM windows for 0000:00:1e.0 and
> 0000:03:0b.0 (may that be the reason for the observed failures?):

No, those are very much on purpose. 

Device 0000:00:1e.0 is the PCI bridge that bridges to PCI bus#3, so the 
MEM window is very much intentional - exactly because MMIO goes through 
that PCI bridge bus to get to bus#3, which is where the cardbus controller 
is.

IOW, the topology is as follows: 
 - CPU is on the root bus (bus #0)
 - device 00:1e.0 is the PCI bridge to bus #3
 - device 03:0b.0 is the CardBus bridge (to bus #4)
and any actual cardbus cards (if you had any) would be on that bus #4, so 
they'd be named "04:xx.y".

Now, that PCI bridge 00:1e.0 is a transparent bridge (aka "[Subtractive 
decode]" in your lspci output - as compared to the other bridges that say 
"[Normal decode]"), which means that you don't actually _have_ to set up 
any MMIO window on them, since the bridge will forward _any_ PCI cycles 
that don't get responded to by any other PCI device.

But having an explicit window is still generally a good idea, since it 
should allow the PCI bridge to pick up the PCI cycles earlier (no need to 
wait to see if others respond to it), and possibly allows for better 
prefetching behavior. So again, the dmesg and the PCI layout actually 
looks _better_ without the hacky patch.

So are you saying that the unpatched kernel still reliably doesn't 
hibernate for you, while the (arguably _incorrect_) patched kernel 
reliably does hibernate? 

			Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Tuesday, 2 of December 2008, Linus Torvalds wrote:
> 
> That's why I'd like to see what the layout differences are for Rafael with 
> and without his patch (and also both before and after hibernate/resume). 
> Maybe both layouts are "correct", but the non-working one can give us a 
> clue about what may be triggering the problem.

OK

Sorry for the delay, it took me more time than expected to generate all the
data.

* dmesg output including one hibernation-resume cycle from 2.6.28-rc7 with the
  debug patch (appended for completness):

  http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7-patched-prep.log

* dmesg output including one hibernation-resume cycle from 2.6.28-rc7 without
  the debug patch:

  http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7-nopatch-prep.log

* diff between the two:

  http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7_nopatch-rc7_patched.diff

This part of the diff  (+ is the patched one) seems to be particularly
interesting to me, especially the overlapping MEM windows for 0000:00:1e.0 and
0000:03:0b.0 (may that be the reason for the observed failures?):

@@ -276,0 +277,4 @@
+bad alignment flags 21200 4000000 (0)
+pci 0000:03:0b.0: BAR 9 bad alignment 0: [0x000000-0x3ffffff]
+bad alignment flags 20200 4000000 (0)
+pci 0000:03:0b.0: BAR 10 bad alignment 0: [0x000000-0x3ffffff]
@@ -288,2 +291,0 @@
-pci 0000:03:0b.0:   PREFETCH window: 0x88000000-0x8bffffff
-pci 0000:03:0b.0:   MEM window: 0x8c000000-0x8fffffff
@@ -292,2 +294,2 @@
-pci 0000:00:1e.0:   MEM window: 0x8c000000-0x91ffffff
-pci 0000:00:1e.0:   PREFETCH window: 0x00000088000000-0x0000008bffffff
+pci 0000:00:1e.0:   MEM window: 0x88000000-0x880fffff
+pci 0000:00:1e.0:   PREFETCH window: disabled
@@ -312,2 +314,2 @@
-bus: 03 index 1 mmio: [0x8c000000-0x91ffffff]
-bus: 03 index 2 mmio: [0x88000000-0x8bffffff]
+bus: 03 index 1 mmio: [0x88000000-0x880fffff]
+bus: 03 index 2 mmio: [0x0-0x0]
@@ -318,2 +320,2 @@
-bus: 04 index 2 mmio: [0x88000000-0x8bffffff]
-bus: 04 index 3 mmio: [0x8c000000-0x8fffffff]
+bus: 04 index 2 mmio: [0x0-0x3ffffff]
+bus: 04 index 3 mmio: [0x0-0x3ffffff]

* the output of 'lspci -vv'

  http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/lspci-vv.txt

* diff between /proc/iomem between 2.6.28-rc7 without and with the patch
  (+ is from the patched kernel):

diff -U 0 -r rc7-nopatch//iomem rc7-patched//iomem
--- rc7-nopatch//iomem	2008-12-02 22:57:34.000000000 +0100
+++ rc7-patched//iomem	2008-12-02 23:07:02.000000000 +0100
@@ -7,2 +7,2 @@
-  00200000-00450496 : Kernel code
-  00450497-00603c37 : Kernel data
+  00200000-00450526 : Kernel code
+  00450527-00603c37 : Kernel data
@@ -14,15 +14,14 @@
-88000000-8bffffff : PCI Bus 0000:03
-  88000000-8bffffff : PCI CardBus 0000:04
-8c000000-91ffffff : PCI Bus 0000:03
-  8c000000-8fffffff : PCI CardBus 0000:04
-  90000000-90003fff : 0000:03:0b.1
-  90004000-90004fff : 0000:03:0b.0
-    90004000-90004fff : yenta_socket
-  90005000-900057ff : 0000:03:0b.1
-    90005000-900057ff : firewire_ohci
-  90005800-900058ff : 0000:03:0b.3
-    90005800-900058ff : mmc0
-92000000-9207ffff : 0000:00:02.1
-92080000-92083fff : 0000:00:1b.0
-  92080000-92083fff : ICH HD audio
-92084000-92084fff : Intel Flush Page
+88000000-880fffff : PCI Bus 0000:03
+  88000000-88003fff : 0000:03:0b.1
+  88004000-88004fff : 0000:03:0b.0
+    88004000-88004fff : yenta_socket
+  88005000-880057ff : 0000:03:0b.1
+    88005000-880057ff : firewire_ohci
+  88005800-880058ff : 0000:03:0b.3
+    88005800-880058ff : mmc0
+88100000-8817ffff : 0000:00:02.1
+88180000-88183fff : 0000:00:1b.0
+  88180000-88183fff : ICH HD audio
+88184000-88184fff : Intel Flush Page
+88400000-887fffff : PCI CardBus 0000:04
+88800000-88bfffff : PCI CardBus 0000:04

All of the files above plus some more data are available from
http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/

HTH

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Tue, 2 Dec 2008, Frans Pop wrote:
> 
> I could reinstall some intermediate versions and check when that change 
> got introduced if that would help, or revert to the kernel I was using 
> before I did the pull today and applied the debug patch (which was plain 
> rc6 + a few selected bug fix patches that had not yet been merged).

It might be interesting, but probably not very relevant. I don't really 
think that the resume problem is related to this.

> It did happen once a few days ago, but with the workarounds I had resume 
> failures were extremely rare. I'll see if I can work out which boot it 
> was, but that could well be very tricky as a failed resume leaves no 
> trace.

If you just save the dmesg before each resume try, you'd have at least the 
dmesg of the bootup that leads to failure. It's _likely_ exactly the same 
as the ones that don't lead to failures, but..

> The way I "see" the failure is that the wireless led does not come on

Quite frankly, from everything I hear, I personally strongly suspect that 
it's something timing-related to some driver, and most likely totally 
unrelated to any PCI resource allocation in any other way. IOW, _if_ the 
resource allocation makes a difference, it's more likely through just 
mattering from a timing standpoint.

For example, the bad alignment you get from picking the alignment from the 
wrong place (with Rafael's patch or with my debugging patch) results in 
this:

 - PCI init time:

	+pci 0000:02:06.0: BAR 9 0-3ffffff wrong alignment flags 21200 4000000 (0)
	+pci 0000:02:06.0: BAR 9 bad alignment 0: [0x000000-0x3ffffff]

 - CardBus init time:

	+yenta_cardbus 0000:02:06.0: CardBus bridge, secondary bus 0000:03
	+yenta_cardbus 0000:02:06.0:   IO window: 0x003000-0x0030ff
	+yenta_cardbus 0000:02:06.0:   IO window: 0x003400-0x0034ff
	+yenta_cardbus 0000:02:06.0:   PREFETCH window: 0x84400000-0x847fffff
	+yenta_cardbus 0000:02:06.0:   MEM window: 0x80000000-0x83ffffff

ie what happened is that when using the wrong alignment, the PCI bus setup 
code would fail to set up the memory windows (bar 9), but then the cardbus 
init which happens later will fix that, since it re-does the setup (see 
"yenta_allocate_resources()": it will re-do "pci_setup_cardbus()" if the 
resources didn't get set up earlier)

End result? There should be no real difference, but timing does change.

Now, there are _some_ subtle issues that change depending on whether we do 
the "failure case" in yenta_allocate_resources() or not: for example, the 
code in yenta_allocate_res() actually knows about the fact that CardBus 
memory resources have a 4kB granularity, while the generic PCI code uses 
the resource size as the alignment.

The yenta code also tries to potentially find a smaller resource than the 
generic PCI resource code did (the generic PCI code just tries to use 
2*pci_cardbus_io_size and 2*pci_cardbus_mem_size for sizing, while the 
Yenta code tries to aim for BRIDGE_IO/MEM_MAX but knows to try to make 
them smaller if it cannot fit.

So the resources can end up being laid out at different points as a 
result, and again, that can lead to totally independent bugs showing up 
(overlap with random unknown motherboard resources set up by firmware). 
But more relevantly, it can simply just cause some timing differences.

Anyway, I'm not at all sure that you and Rafael even necessarily see 
exactly the same thing. It doesn't look like my debug patch (which tries 
to emulate Rafael's patch in behavior, in addition to adding the debug 
printouts) really even matters for you. Because you seemed to be 
hibernating ok even without that "break alignment in PCI layer" thing.

			Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

On Tuesday 02 December 2008, Linus Torvalds wrote:
> So, it looks like you have MSI enabled in -rc6, and not in -rc3. And
> yes, for some reason -rc3 will create the prefetchable memory range
> windows, but -rc6 won't.

I have no changes in my config that would explain that (checked the diff). 
The only changes are simple 'make oldconfig' updates.

> I have to admit that I'm not seeing _why_ to that latter one. I don't
> think we've done any resource allocation changes since -rc3 (the "clean
> up late e820 resource allocation" thing happened just _before_ -rc3),
> so I'm really not seeing why -rc3 would act differently from -rc6..

I could reinstall some intermediate versions and check when that change 
got introduced if that would help, or revert to the kernel I was using 
before I did the pull today and applied the debug patch (which was plain 
rc6 + a few selected bug fix patches that had not yet been merged).

> > At the bottom there's a fairly long addition from the few
> > suspend/resume cycles I did (again, running with the debug patch).
>
> Sure. Quite frankly, from these messages, I'm not seeing anything
> really even remotely wrong. And apparently it does actually work for
> you.

Right. All these resumes were perfect.

> It would perhaps be more interesting to see if there is some dmesg
> difference in a boot that then ends up _not_ able to resume from
> hibernation? But apparently that hasn't happened to you lately?

It did happen once a few days ago, but with the workarounds I had resume 
failures were extremely rare. I'll see if I can work out which boot it 
was, but that could well be very tricky as a failed resume leaves no 
trace.

The way I "see" the failure is that the wireless led does not come on

> I don't like not knowing why you have prefetchable windows in one, and
> not in the other, but it is indeed a transparent bridge and so that
> difference really shouldn't even matter.

/me always likes the use of "should" in such situations ;-)

> Do you perhaps dual-boot that laptop? What can sometimes happen is that
> PCI resources do not get totally reset over a warm-boot.

No. I only run Debian testing on that machine. As Debian Lenny is getting 
close to release there are very few changes in userland ATM. For kernels 
I essentially follow git starting with -rc2/3 or so of each new minor.

> We've (very occasionally) had situations where PCI resource bugs only
> happen when you warm-boot from another OS (generally Windows), or when
> you warm-boot from an earlier version of Linux. Exactly because some
> firmware didn't fully re-initialize the state of the PCI bus, and
> because Linux will try to honor everything that the firmware set up..

Given the above that does not seem relevant.

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Tuesday, 2 of December 2008, Linus Torvalds wrote:
> 
> On Tue, 2 Dec 2008, Rafael J. Wysocki wrote:
> >  			r_size = resource_size(r);
> >  			/* For bridges size != alignment */
> > -			align = resource_alignment(r);
> > +			align = (i < PCI_BRIDGE_RESOURCES) ? r_size : r->start;
> 
> Hmm. This means that something set the alignment flags incorrectly. The 
> resource _should_ have IORESOURCE_SIZEALIGN set for a resource with size 
> alignment, and IORESOURCE_STARTALIGN for one that has start alignment.
> 
> Your patch doesn't fix anything, it just hides the bug.

Well, it's just a partial revert of commit
5f17cfce5776c566d64430f543a289e5cfa4538b ("PCI: fix pbus_size_mem() resource
alignment for CardBus controllers"). 

> It would be good to hear what resource this is, and where it got set. So 
> instead of that broken patch that just hides the problem, please try to 
> debug it with something like
> 
> 	resource_size_t expected_align;
> 
> 	expected_align = (i < PCI_BRIDGE_RESOURCES) ? r_size : r->start;
> 	align = resource_alignment(r);
> 	if (align != expected_align) {
> 		dev_warn(&dev->dev,
> 			"BAR %d %llx-%llx wrong alignment flags %lx %llx (%llx)\n",
> 			i,
> 			(unsigned long long) r->start,
> 			(unsigned long long) r->end,
> 			r->flags,
> 			(unsigned long long) align,
> 			(unsigned long long) expected_align);
> 		/* Hacky and wrong, but trying to keep things 
> 		align = expected_align;
> 	}
> 
> or something like that. And then we just need to figure out which setup 
> routine sets the wrong alignment flag,.

Yeah, I'll give it a try later today, when I get back from the Uni.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Tue, 2 Dec 2008, Frans Pop wrote:
> 
> Attached is a full diff between dmesg from -rc3 and -rc6 with your debug 
> patch.
> 
> I've cleaned up the diff a bit to make it more readable (mostly removal of 
> changes that I always get due to random USB load order changes - UHCI 
> still frequently loads before EHCI).
> 
> The most interesting points are probably at lines 298-346 and 639-649.

So, it looks like you have MSI enabled in -rc6, and not in -rc3. And yes, 
for some reason -rc3 will create the prefetchable memory range windows, 
but -rc6 won't.

I have to admit that I'm not seeing _why_ to that latter one. I don't 
think we've done any resource allocation changes since -rc3 (the "clean up 
late e820 resource allocation" thing happened just _before_ -rc3), so I'm 
really not seeing why -rc3 would act differently from -rc6..

> At the bottom there's a fairly long addition from the few suspend/resume 
> cycles I did (again, running with the debug patch).

Sure. Quite frankly, from these messages, I'm not seeing anything really 
even remotely wrong. And apparently it does actually work for you.

It would perhaps be more interesting to see if there is some dmesg 
difference in a boot that then ends up _not_ able to resume from 
hibernation? But apparently that hasn't happened to you lately?

I don't like not knowing why you have prefetchable windows in one, and not 
in the other, but it is indeed a transparent bridge and so that difference 
really shouldn't even matter.

Do you perhaps dual-boot that laptop? What can sometimes happen is that 
PCI resources do not get totally reset over a warm-boot.

We've (very occasionally) had situations where PCI resource bugs only 
happen when you warm-boot from another OS (generally Windows), or when you 
warm-boot from an earlier version of Linux. Exactly because some firmware 
didn't fully re-initialize the state of the PCI bus, and because Linux 
will try to honor everything that the firmware set up..

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

On Tuesday 02 December 2008, Frans Pop wrote:
> +yenta_cardbus 0000:02:06.0: CardBus bridge, secondary bus 0000:03
> +yenta_cardbus 0000:02:06.0:   IO window: 0x003000-0x0030ff
> +yenta_cardbus 0000:02:06.0:   IO window: 0x003400-0x0034ff
> +yenta_cardbus 0000:02:06.0:   PREFETCH window: 0x84400000-0x847fffff
> +yenta_cardbus 0000:02:06.0:   MEM window: 0x80000000-0x83ffffff

Wild speculation, but could all this possibly also be related to occasional
"irq 19: nobody cared" errors I'm seeing on resume for ohci1394?

My FireWire controller is sitting behind this bridge after all.

Here's an example:
Dec  2 04:57:32 aragorn kernel: irq 19: nobody cared (try booting with the "irqpoll" option)
Dec  2 04:57:32 aragorn kernel: Pid: 0, comm: swapper Not tainted 2.6.28-rc6 #57
Dec  2 04:57:32 aragorn kernel: Call Trace:
Dec  2 04:57:32 aragorn kernel:  <IRQ>  [<ffffffffa01009e1>] ? ohci_irq_handler+0x60/0x7e9 [ohci1394]
Dec  2 04:57:32 aragorn kernel:  [<ffffffff8026aa29>] __report_bad_irq+0x38/0x87
Dec  2 04:57:32 aragorn kernel:  [<ffffffff8026ab86>] note_interrupt+0x10e/0x174
Dec  2 04:57:32 aragorn kernel:  [<ffffffff8026b23e>] handle_fasteoi_irq+0xa7/0xd1
Dec  2 04:57:32 aragorn kernel:  [<ffffffff8020eb87>] do_IRQ+0x73/0xe4
Dec  2 04:57:32 aragorn kernel:  [<ffffffff8020c626>] ret_from_intr+0x0/0xa
Dec  2 04:57:32 aragorn kernel:  <EOI>  [<ffffffffa0012606>] ? acpi_idle_enter_bm+0x26b/0x2b2 [processor]
Dec  2 04:57:32 aragorn kernel:  [<ffffffffa00125fc>] ? acpi_idle_enter_bm+0x261/0x2b2 [processor]
Dec  2 04:57:32 aragorn kernel:  [<ffffffff8024f33b>] ? notifier_call_chain+0x33/0x5b
Dec  2 04:57:32 aragorn kernel:  [<ffffffff803b9ca4>] ? cpuidle_idle_call+0x8c/0xc4
Dec  2 04:57:32 aragorn kernel:  [<ffffffff8020b312>] ? cpu_idle+0x4a/0x9a
Dec  2 04:57:32 aragorn kernel:  [<ffffffff8042c528>] ? rest_init+0x5c/0x5e
Dec  2 04:57:32 aragorn kernel: handlers:
Dec  2 04:57:32 aragorn kernel: [<ffffffffa0100981>] (ohci_irq_handler+0x0/0x7e9 [ohci1394])
Dec  2 04:57:32 aragorn kernel: Disabling IRQ #19

I can send full kernel log from the start of that boot if desired.

Cheers,
FJP

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

On Tuesday 02 December 2008, Linus Torvalds wrote:
> That said, if you can show the differences in dmesg from the two cases,
> it would probably be interesting to see why it happens that way.  Why
> did we bother setting up that PCI bus window in -rc3 at all? Was it
> there from the beginning?

Attached is a full diff between dmesg from -rc3 and -rc6 with your debug 
patch.

I've cleaned up the diff a bit to make it more readable (mostly removal of 
changes that I always get due to random USB load order changes - UHCI 
still frequently loads before EHCI).

The most interesting points are probably at lines 298-346 and 639-649.

At the bottom there's a fairly long addition from the few suspend/resume 
cycles I did (again, running with the debug patch).


[-- Attachment #2: rc3-rc6.diff --]
[-- Type: text/x-diff, Size: 94937 bytes --]

--- 2.6.28-rc3	2008-11-03 10:51:51.000000000 +0100
+++ 2.6.28-rc6_linus	2008-12-02 06:12:15.000000000 +0100
@@ -1,676 +1,1625 @@
 BIOS EBDA/lowmem at: 0009fc00/0009fc00
-Linux version 2.6.28-rc3 (root@faramir) (gcc version 4.3.2 (Debian 4.3.2-1) ) #47 SMP Mon Nov 3 10:30:30 CET 2008
+Linux version 2.6.28-rc6 (root@faramir) (gcc version 4.3.2 (Debian 4.3.2-1) ) #58 SMP Tue Dec 2 04:56:59 CET 2008
 Command line: root=/dev/mapper/main-root ro vga=791 quiet
 KERNEL supported cpus:
   Intel GenuineIntel
   AMD AuthenticAMD
   Centaur CentaurHauls
 BIOS-provided physical RAM map:
  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
  BIOS-e820: 0000000000100000 - 000000007e7b0000 (usable)
  BIOS-e820: 000000007e7b0000 - 000000007e7c5400 (reserved)
  BIOS-e820: 000000007e7c5400 - 000000007e7e7fb8 (ACPI NVS)
  BIOS-e820: 000000007e7e7fb8 - 000000007f000000 (reserved)
  BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
  BIOS-e820: 00000000fed20000 - 00000000fed9a000 (reserved)
  BIOS-e820: 00000000feda0000 - 00000000fedc0000 (reserved)
  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
  BIOS-e820: 00000000ffb00000 - 00000000ffc00000 (reserved)
  BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
 DMI 2.4 present.
 last_pfn = 0x7e7b0 max_arch_pfn = 0x3ffffffff
 x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
 init_memory_mapping: 0000000000000000-000000007e7b0000
  0000000000 - 007e600000 page 2M
  007e600000 - 007e7b0000 page 4k
 kernel direct mapping tables up to 7e7b0000 @ 8000-c000
 last_map_addr: 7e7b0000 end: 7e7b0000
-RAMDISK: 37ab8000 - 37fef345
+RAMDISK: 37ab8000 - 37fefbd6
 ACPI: RSDP 000F7960, 0024 (r2 HP    )
 ACPI: XSDT 7E7C81C8, 007C (r1 HPQOEM SLIC-MPC        1 HP          1)
 ACPI: FACP 7E7C8084, 00F4 (r4 HP     30C9            3 HP          1)
 ACPI: DSDT 7E7C8538, 13484 (r1 HP       nc2500    10000 MSFT  3000001)
 ACPI: FACS 7E7E7D80, 0040
 ACPI: SLIC 7E7C8244, 0176 (r1 HPQOEM SLIC-MPC        1 HP          1)
 ACPI: HPET 7E7C83BC, 0038 (r1 HP     30C9            1 HP          1)
 ACPI: APIC 7E7C83F4, 0068 (r1 HP     30C9            1 HP          1)
 ACPI: MCFG 7E7C845C, 003C (r1 HP     30C9            1 HP          1)
 ACPI: TCPA 7E7C8498, 0032 (r2 HP     30C9            1 HP          1)
 ACPI: ASF! 7E7C84CC, 0069 (r16 HP     CHIMAYU         1 HP          0)
 ACPI: SSDT 7E7DB9BC, 02BE (r1 HP       HPQPAT        1 MSFT  3000001)
 ACPI: SSDT 7E7DC640, 025F (r1 HP      Cpu0Tst     3000 INTL 20060317)
 ACPI: SSDT 7E7DC89F, 00A6 (r1 HP      Cpu1Tst     3000 INTL 20060317)
 ACPI: SSDT 7E7DC945, 04D7 (r1 HP        CpuPm     3000 INTL 20060317)
-ACPI: DMI detected: Hewlett-Packard
 ACPI: Local APIC address 0xfee00000
 (6 early reservations) ==> bootmem [0000000000 - 007e7b0000]
   #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 0000001000]
   #1 [0000006000 - 0000008000]       TRAMPOLINE ==> [0000006000 - 0000008000]
-  #2 [0000200000 - 000074e550]    TEXT DATA BSS ==> [0000200000 - 000074e550]
-  #3 [0037ab8000 - 0037fef345]          RAMDISK ==> [0037ab8000 - 0037fef345]
+  #2 [0000200000 - 000074c510]    TEXT DATA BSS ==> [0000200000 - 000074c510]
+  #3 [0037ab8000 - 0037fefbd6]          RAMDISK ==> [0037ab8000 - 0037fefbd6]
   #4 [000009fc00 - 0000100000]    BIOS reserved ==> [000009fc00 - 0000100000]
   #5 [0000008000 - 000000a000]          PGTABLE ==> [0000008000 - 000000a000]
  [ffffe20000000000-ffffe20001ffffff] PMD -> [ffff880001200000-ffff8800031fffff] on node 0
 Zone PFN ranges:
   DMA      0x00000000 -> 0x00001000
   DMA32    0x00001000 -> 0x00100000
   Normal   0x00100000 -> 0x00100000
 Movable zone start PFN for each node
 early_node_map[2] active PFN ranges
     0: 0x00000000 -> 0x0000009f
     0: 0x00000100 -> 0x0007e7b0
 On node 0 totalpages: 517967
   DMA zone: 64 pages used for memmap
-  DMA zone: 1459 pages reserved
-  DMA zone: 2476 pages, LIFO batch:0
+  DMA zone: 1457 pages reserved
+  DMA zone: 2478 pages, LIFO batch:0
   DMA32 zone: 8031 pages used for memmap
   DMA32 zone: 505937 pages, LIFO batch:31
   Normal zone: 0 pages used for memmap
   Movable zone: 0 pages used for memmap
 ACPI: PM-Timer IO Port: 0x1008
 ACPI: Local APIC address 0xfee00000
 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
 ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
 ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
 ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
 IOAPIC[0]: apic_id 1, version 0, address 0xfec00000, GSI 0-23
 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
 ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
 ACPI: IRQ0 used by override.
 ACPI: IRQ2 used by override.
 ACPI: IRQ9 used by override.
 ACPI: HPET id: 0x8086a201 base: 0xfed00000
 SMP: Allowing 2 CPUs, 0 hotplug CPUs
 PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
 PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
 PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
 Allocating PCI resources starting at 80000000 (gap: 7f000000:7fc00000)
 PERCPU: Allocating 49152 bytes of per cpu data
 NR_CPUS: 8, nr_cpu_ids: 2, nr_node_ids 1
-Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 508413
+Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 508415
 Kernel command line: root=/dev/mapper/main-root ro vga=791 quiet
 Initializing CPU#0
 PID hash table entries: 4096 (order: 12, 32768 bytes)
 Extended CMOS year: 2000
 Fast TSC calibration using PIT
-Detected 1330.160 MHz processor.
+Detected 1330.139 MHz processor.
 Console: colour dummy device 80x25
 console [tty0] enabled
 Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
 Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
 Checking aperture...
 No AGP bridge found
-Memory: 2024344k/2072256k available (2300k kernel code, 388k absent, 46900k reserved, 1509k data, 324k init)
+Memory: 2024352k/2072256k available (2302k kernel code, 388k absent, 46892k reserved, 1507k data, 316k init)
 SLUB: Genslabs=12, HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
 hpet clockevent registered
 HPET: 3 timers in total, 0 timers will be used for per-cpu timer
-Calibrating delay loop (skipped), value calculated using timer frequency.. 2660.32 BogoMIPS (lpj=5320640)
+Calibrating delay loop (skipped), value calculated using timer frequency.. 2660.27 BogoMIPS (lpj=5320556)
 Security Framework initialized
 SELinux:  Disabled at boot.
 Mount-cache hash table entries: 256
 CPU: L1 I cache: 32K, L1 D cache: 32K
 CPU: L2 cache: 2048K
 CPU: Physical Processor ID: 0
 CPU: Processor Core ID: 0
 CPU0: Thermal monitoring handled by SMI
 using mwait in idle threads.
 ACPI: Core revision 20080926
 Setting APIC routing to flat
 ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
 CPU0: Intel(R) Core(TM)2 Duo CPU     U7700  @ 1.33GHz stepping 0d
 Booting processor 1 APIC 0x1 ip 0x6000
 Initializing CPU#1
-Calibrating delay using timer specific routine.. 2659.99 BogoMIPS (lpj=5319980)
+Calibrating delay using timer specific routine.. 2659.98 BogoMIPS (lpj=5319962)
 CPU: L1 I cache: 32K, L1 D cache: 32K
 CPU: L2 cache: 2048K
 CPU: Physical Processor ID: 0
 CPU: Processor Core ID: 1
 CPU1: Thermal monitoring enabled (TM2)
 x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
 CPU1: Intel(R) Core(TM)2 Duo CPU     U7700  @ 1.33GHz stepping 0d
 checking TSC synchronization [CPU#0 -> CPU#1]: passed.
 Brought up 2 CPUs
-Total of 2 processors activated (5320.31 BogoMIPS).
+Total of 2 processors activated (5320.25 BogoMIPS).
 CPU0 attaching sched-domain:
  domain 0: span 0-1 level MC
   groups: 0 1
 CPU1 attaching sched-domain:
  domain 0: span 0-1 level MC
   groups: 1 0
 net_namespace: 1400 bytes
 NET: Registered protocol family 16
 ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
 ACPI: bus type pci registered
 PCI: MCFG configuration 0: base f8000000 segment 0 buses 0 - 63
 PCI: Not using MMCONFIG.
 PCI: Using configuration type 1 for base access
 ACPI: EC: Look up EC in DSDT
 ACPI: EC: non-query interrupt received, switching to interrupt mode
 ACPI: Interpreter enabled
 ACPI: (supports S0 S3 S4 S5)
 ACPI: Using IOAPIC for interrupt routing
 PCI: MCFG configuration 0: base f8000000 segment 0 buses 0 - 63
 PCI: MCFG area at f8000000 reserved in ACPI motherboard resources
 PCI: Using MMCONFIG at f8000000 - fbffffff
 ACPI: EC: GPE = 0x16, I/O: command/status = 0x66, data = 0x62
 ACPI: EC: driver started in interrupt mode
 ACPI: No dock devices found.
 ACPI: PCI Root Bridge [C003] (0000:00)
 pci 0000:00:02.0: reg 10 64bit mmio: [0xe0400000-0xe04fffff]
 pci 0000:00:02.0: reg 18 64bit mmio: [0xd0000000-0xdfffffff]
 pci 0000:00:02.0: reg 20 io port: [0x2000-0x2007]
 pci 0000:00:02.1: reg 10 64bit mmio: [0xe0500000-0xe05fffff]
 pci 0000:00:03.0: reg 10 64bit mmio: [0xe0600000-0xe060000f]
 pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
 pci 0000:00:03.0: PME# disabled
 pci 0000:00:03.2: reg 10 io port: [0x2008-0x200f]
 pci 0000:00:03.2: reg 14 io port: [0x2010-0x2013]
 pci 0000:00:03.2: reg 18 io port: [0x2018-0x201f]
 pci 0000:00:03.2: reg 1c io port: [0x2020-0x2023]
 pci 0000:00:03.2: reg 20 io port: [0x2030-0x203f]
 pci 0000:00:03.3: reg 10 io port: [0x2040-0x2047]
 pci 0000:00:03.3: reg 14 32bit mmio: [0xe0601000-0xe0601fff]
 pci 0000:00:19.0: reg 10 32bit mmio: [0xe0620000-0xe063ffff]
 pci 0000:00:19.0: reg 14 32bit mmio: [0xe0640000-0xe0640fff]
 pci 0000:00:19.0: reg 18 io port: [0x2060-0x207f]
 pci 0000:00:19.0: PME# supported from D0 D3hot D3cold
 pci 0000:00:19.0: PME# disabled
 pci 0000:00:1a.0: reg 20 io port: [0x2080-0x209f]
 pci 0000:00:1a.1: reg 20 io port: [0x20a0-0x20bf]
 pci 0000:00:1a.7: reg 10 32bit mmio: [0xe0641000-0xe06413ff]
 pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
 pci 0000:00:1a.7: PME# disabled
 pci 0000:00:1b.0: reg 10 64bit mmio: [0xe0644000-0xe0647fff]
 pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
 pci 0000:00:1b.0: PME# disabled
 pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
 pci 0000:00:1c.0: PME# disabled
 pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold
 pci 0000:00:1c.1: PME# disabled
 pci 0000:00:1d.0: reg 20 io port: [0x20c0-0x20df]
 pci 0000:00:1d.1: reg 20 io port: [0x20e0-0x20ff]
 pci 0000:00:1d.2: reg 20 io port: [0x2100-0x211f]
 pci 0000:00:1d.7: reg 10 32bit mmio: [0xe0648000-0xe06483ff]
 pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
 pci 0000:00:1d.7: PME# disabled
 pci 0000:00:1f.0: quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
 pci 0000:00:1f.0: quirk: region 1100-113f claimed by ICH6 GPIO
 pci 0000:00:1f.1: reg 10 io port: [0x00-0x07]
 pci 0000:00:1f.1: reg 14 io port: [0x00-0x03]
 pci 0000:00:1f.1: reg 18 io port: [0x00-0x07]
 pci 0000:00:1f.1: reg 1c io port: [0x00-0x03]
 pci 0000:00:1f.1: reg 20 io port: [0x2120-0x212f]
 pci 0000:10:00.0: reg 10 64bit mmio: [0xe0000000-0xe0001fff]
 pci 0000:10:00.0: PME# supported from D0 D3hot D3cold
 pci 0000:10:00.0: PME# disabled
 pci 0000:00:1c.1: bridge 32bit mmio: [0xe0000000-0xe00fffff]
 pci 0000:02:06.0: reg 10 32bit mmio: [0xe0100000-0xe0100fff]
 pci 0000:02:06.0: supports D1 D2
 pci 0000:02:06.0: PME# supported from D0 D1 D2 D3hot D3cold
 pci 0000:02:06.0: PME# disabled
 pci 0000:02:06.1: reg 10 32bit mmio: [0xe0101000-0xe01017ff]
 pci 0000:02:06.1: supports D1 D2
 pci 0000:02:06.1: PME# supported from D0 D1 D2 D3hot D3cold
 pci 0000:02:06.1: PME# disabled
 pci 0000:02:06.2: reg 10 32bit mmio: [0xe0102000-0xe01020ff]
 pci 0000:02:06.2: supports D1 D2
 pci 0000:02:06.2: PME# supported from D0 D1 D2 D3hot D3cold
 pci 0000:02:06.2: PME# disabled
 pci 0000:02:06.3: reg 10 32bit mmio: [0xe0103000-0xe01030ff]
 pci 0000:02:06.3: supports D1 D2
 pci 0000:02:06.3: PME# supported from D0 D1 D2 D3hot D3cold
 pci 0000:02:06.3: PME# disabled
 pci 0000:00:1e.0: transparent bridge
 pci 0000:00:1e.0: bridge 32bit mmio: [0xe0100000-0xe03fffff]
 bus 00 -> node 0
 ACPI: PCI Interrupt Routing Table [\_SB_.C003._PRT]
 ACPI: PCI Interrupt Routing Table [\_SB_.C003.C0B2._PRT]
 ACPI: PCI Interrupt Routing Table [\_SB_.C003.C11F._PRT]
 ACPI: PCI Interrupt Routing Table [\_SB_.C003.C133._PRT]
 ACPI: PCI Interrupt Link [C12F] (IRQs *10 11)
 ACPI: PCI Interrupt Link [C130] (IRQs *10 11)
 ACPI: PCI Interrupt Link [C131] (IRQs 10 *11)
 ACPI: PCI Interrupt Link [C132] (IRQs 10 11) *5
 ACPI: PCI Interrupt Link [C142] (IRQs *10 11)
 ACPI: PCI Interrupt Link [C143] (IRQs 10 11) *0, disabled.
 ACPI: PCI Interrupt Link [C144] (IRQs 10 *11)
 ACPI Exception (pci_link-0189): AE_NOT_FOUND, Evaluating _PRS [20080926]
 ACPI: Power Resource [C29F] (on)
 ACPI: Power Resource [C1C7] (off)
 ACPI: Power Resource [C3AD] (off)
 ACPI: Power Resource [C3B0] (off)
 ACPI: Power Resource [C3C3] (off)
 ACPI: Power Resource [C3C4] (off)
 ACPI: Power Resource [C3C5] (off)
 ACPI: Power Resource [C3C6] (off)
 ACPI: Power Resource [C3C7] (off)
 usbcore: registered new interface driver usbfs
 usbcore: registered new interface driver hub
 usbcore: registered new device driver usb
 PCI: Using ACPI for IRQ routing
 PCI-GART: No AMD GART found.
 hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
 hpet0: 3 comparators, 64-bit 14.318180 MHz counter
 pnp: PnP ACPI init
 ACPI: bus type pnp registered
 pnp: PnP ACPI: found 14 devices
 ACPI: ACPI bus type pnp unregistered
 system 00:00: iomem range 0x0-0x9ffff could not be reserved
 system 00:00: iomem range 0xe0000-0xfffff could not be reserved
 system 00:00: iomem range 0x100000-0x7e7fffff could not be reserved
 system 00:0a: ioport range 0x500-0x55f has been reserved
 system 00:0a: ioport range 0x800-0x80f has been reserved
 system 00:0a: iomem range 0xffb00000-0xffbfffff has been reserved
 system 00:0a: iomem range 0xfff00000-0xffffffff has been reserved
 system 00:0c: ioport range 0x4d0-0x4d1 has been reserved
 system 00:0c: ioport range 0x2f8-0x2ff has been reserved
 system 00:0c: ioport range 0x3f8-0x3ff has been reserved
 system 00:0c: ioport range 0x1000-0x107f has been reserved
 system 00:0c: ioport range 0x1100-0x113f has been reserved
 system 00:0c: ioport range 0x1200-0x121f has been reserved
 system 00:0c: iomem range 0xf8000000-0xfbffffff has been reserved
 system 00:0c: iomem range 0xfec00000-0xfec000ff has been reserved
 system 00:0c: iomem range 0xfed20000-0xfed3ffff has been reserved
 system 00:0c: iomem range 0xfed45000-0xfed8ffff has been reserved
 system 00:0c: iomem range 0xfed90000-0xfed99fff has been reserved
 system 00:0d: iomem range 0xcee00-0xcffff has been reserved
 system 00:0d: iomem range 0xd2000-0xd3fff has been reserved
 system 00:0d: iomem range 0xfeda0000-0xfedbffff has been reserved
 system 00:0d: iomem range 0xfee00000-0xfee00fff has been reserved
+pci 0000:02:06.0: BAR 9 0-3ffffff wrong alignment flags 21200 4000000 (0)
+pci 0000:02:06.0: BAR 9 bad alignment 0: [0x000000-0x3ffffff]
 pci 0000:00:1c.0: PCI bridge, secondary bus 0000:08
 pci 0000:00:1c.0:   IO window: disabled
 pci 0000:00:1c.0:   MEM window: disabled
 pci 0000:00:1c.0:   PREFETCH window: disabled
 pci 0000:00:1c.1: PCI bridge, secondary bus 0000:10
 pci 0000:00:1c.1:   IO window: disabled
 pci 0000:00:1c.1:   MEM window: 0xe0000000-0xe00fffff
 pci 0000:00:1c.1:   PREFETCH window: disabled
 pci 0000:02:06.0: CardBus bridge, secondary bus 0000:03
 pci 0000:02:06.0:   IO window: 0x003000-0x0030ff
 pci 0000:02:06.0:   IO window: 0x003400-0x0034ff
-pci 0000:02:06.0:   PREFETCH window: 0x80000000-0x83ffffff
-pci 0000:02:06.0:   MEM window: 0x84000000-0x87ffffff
+pci 0000:02:06.0:   MEM window: 0x80000000-0x83ffffff
 pci 0000:00:1e.0: PCI bridge, secondary bus 0000:02
 pci 0000:00:1e.0:   IO window: 0x3000-0x3fff
 pci 0000:00:1e.0:   MEM window: 0xe0100000-0xe03fffff
-pci 0000:00:1e.0:   PREFETCH window: 0x00000080000000-0x00000083ffffff
+pci 0000:00:1e.0:   PREFETCH window: disabled
 pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
 pci 0000:00:1c.0: setting latency timer to 64
 pci 0000:00:1c.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
 pci 0000:00:1c.1: setting latency timer to 64
 pci 0000:00:1e.0: setting latency timer to 64
 pci 0000:02:06.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
 bus: 00 index 0 io port: [0x00-0xffff]
 bus: 00 index 1 mmio: [0x000000-0xffffffffffffffff]
 bus: 08 index 0 mmio: [0x0-0x0]
 bus: 08 index 1 mmio: [0x0-0x0]
 bus: 08 index 2 mmio: [0x0-0x0]
 bus: 08 index 3 mmio: [0x0-0x0]
 bus: 10 index 0 mmio: [0x0-0x0]
 bus: 10 index 1 mmio: [0xe0000000-0xe00fffff]
 bus: 10 index 2 mmio: [0x0-0x0]
 bus: 10 index 3 mmio: [0x0-0x0]
 bus: 02 index 0 io port: [0x3000-0x3fff]
 bus: 02 index 1 mmio: [0xe0100000-0xe03fffff]
-bus: 02 index 2 mmio: [0x80000000-0x83ffffff]
+bus: 02 index 2 mmio: [0x0-0x0]
 bus: 02 index 3 io port: [0x00-0xffff]
 bus: 02 index 4 mmio: [0x000000-0xffffffffffffffff]
 bus: 03 index 0 io port: [0x3000-0x30ff]
 bus: 03 index 1 io port: [0x3400-0x34ff]
-bus: 03 index 2 mmio: [0x80000000-0x83ffffff]
-bus: 03 index 3 mmio: [0x84000000-0x87ffffff]
+bus: 03 index 2 mmio: [0x0-0x3ffffff]
+bus: 03 index 3 mmio: [0x80000000-0x83ffffff]
 NET: Registered protocol family 2
-Switched to high resolution mode on CPU 1
 IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
 TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
-Switched to high resolution mode on CPU 0
 TCP bind hash table entries: 65536 (order: 9, 2097152 bytes)
 TCP: Hash tables configured (established 262144 bind 65536)
 TCP reno registered
+Switched to high resolution mode on CPU 1
+Switched to high resolution mode on CPU 0
 NET: Registered protocol family 1
 checking if image is initramfs... it is
-Freeing initrd memory: 5340k freed
+Freeing initrd memory: 5342k freed
 audit: initializing netlink socket (disabled)
-type=2000 audit(1225705229.141:1): initialized
+type=2000 audit(1228190448.133:1): initialized
 VFS: Disk quotas dquot_6.5.1
 Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
 msgmni has been set to 3965
 alg: No test for stdrng (krng)
 io scheduler noop registered
 io scheduler anticipatory registered
 io scheduler deadline registered
 io scheduler cfq registered (default)
 pci 0000:00:02.0: Boot video device
 pcieport-driver 0000:00:1c.0: setting latency timer to 64
 pcieport-driver 0000:00:1c.0: found MSI capability
-pcieport-driver 0000:00:1c.0: irq 47 for MSI/MSI-X
+pcieport-driver 0000:00:1c.0: irq 511 for MSI/MSI-X
 pci_express 0000:00:1c.0:pcie00: allocate port service
 pci_express 0000:00:1c.0:pcie03: allocate port service
 pcieport-driver 0000:00:1c.1: setting latency timer to 64
 pcieport-driver 0000:00:1c.1: found MSI capability
-pcieport-driver 0000:00:1c.1: irq 46 for MSI/MSI-X
+pcieport-driver 0000:00:1c.1: irq 510 for MSI/MSI-X
 pci_express 0000:00:1c.1:pcie00: allocate port service
 pci_express 0000:00:1c.1:pcie03: allocate port service
 vesafb: framebuffer at 0xd0000000, mapped to 0xffffc20004100000, using 3072k, total 7616k
 vesafb: mode is 1024x768x16, linelength=2048, pages=3
 vesafb: scrolling: redraw
 vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
 Console: switching to colour frame buffer device 128x48
 fb0: VESA VGA frame buffer device
 Linux agpgart interface v0.103
 Serial: 8250/16550 driver4 ports, IRQ sharing enabled
 serial 0000:00:03.3: PCI INT B -> GSI 17 (level, low) -> IRQ 17
 0000:00:03.3: ttyS0 at I/O 0x2040 (irq = 17) is a 16550A
 brd: module loaded
 PNP: PS/2 Controller [PNP0303:C29C,PNP0f13:C29D] at 0x60,0x64 irq 1,12
 i8042.c: Detected active multiplexing controller, rev 1.1.
 serio: i8042 KBD port at 0x60,0x64 irq 1
 serio: i8042 AUX0 port at 0x60,0x64 irq 12
 serio: i8042 AUX1 port at 0x60,0x64 irq 12
 serio: i8042 AUX2 port at 0x60,0x64 irq 12
 serio: i8042 AUX3 port at 0x60,0x64 irq 12
 mice: PS/2 mouse device common for all mice
 rtc_cmos 00:06: RTC can wake from S4
 rtc_cmos 00:06: rtc core: registered rtc_cmos as rtc0
-rtc0: alarms up to one month, y3k, 114 bytes nvram, , hpet irqs irqs
+rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
 cpuidle: using governor ladder
 cpuidle: using governor menu
 TCP bic registered
 NET: Registered protocol family 17
-rtc_cmos 00:06: setting system clock to 2008-11-03 09:40:30 UTC (1225705230)
-Freeing unused kernel memory: 324k freed
+rtc_cmos 00:06: setting system clock to 2008-12-02 04:00:49 UTC (1228190449)
+Freeing unused kernel memory: 316k freed
 input: AT Translated Set 2 keyboard as /class/input/input0
-ACPI: Transitioning device [C3B1] to D3
 fan PNP0C0B:00: registered as cooling_device0
 ACPI: Fan [C3B1] (off)
-ACPI: Transitioning device [C3B2] to D3
 fan PNP0C0B:01: registered as cooling_device1
 ACPI: Fan [C3B2] (off)
-ACPI: Transitioning device [C3C8] to D3
 fan PNP0C0B:02: registered as cooling_device2
 ACPI: Fan [C3C8] (off)
-ACPI: Transitioning device [C3C9] to D3
 fan PNP0C0B:03: registered as cooling_device3
 ACPI: Fan [C3C9] (off)
-ACPI: Transitioning device [C3CA] to D3
 fan PNP0C0B:04: registered as cooling_device4
 ACPI: Fan [C3CA] (off)
-ACPI: Transitioning device [C3CB] to D3
 fan PNP0C0B:05: registered as cooling_device5
 ACPI: Fan [C3CB] (off)
-ACPI: Transitioning device [C3CC] to D3
 fan PNP0C0B:06: registered as cooling_device6
 ACPI: Fan [C3CC] (off)
 ACPI: SSDT 7E7DBD42, 027F (r1 HP      Cpu0Ist     3000 INTL 20060317)
 ACPI: SSDT 7E7DC046, 05FA (r1 HP      Cpu0Cst     3001 INTL 20060317)
 Monitor-Mwait will be used to enter C-1 state
 Monitor-Mwait will be used to enter C-2 state
 Monitor-Mwait will be used to enter C-3 state
 ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
-processor ACPI0007:00: registered as cooling_device7
+processor ACPI_CPU:00: registered as cooling_device7
 ACPI: Processor [CPU0] (supports 8 throttling states)
 ACPI: SSDT 7E7DBC7A, 00C8 (r1 HP      Cpu1Ist     3000 INTL 20060317)
 ACPI: SSDT 7E7DBFC1, 0085 (r1 HP      Cpu1Cst     3000 INTL 20060317)
 Marking TSC unstable due to TSC halts in idle
 ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3])
-processor ACPI0007:01: registered as cooling_device8
+processor ACPI_CPU:01: registered as cooling_device8
 ACPI: Processor [CPU1] (supports 8 throttling states)
 thermal LNXTHERM:01: registered as thermal_zone0
 ACPI: Thermal Zone [TZ6] (25 C)
 thermal LNXTHERM:02: registered as thermal_zone1
-ACPI: Thermal Zone [TZ0] (45 C)
+ACPI: Thermal Zone [TZ0] (36 C)
 thermal LNXTHERM:03: registered as thermal_zone2
-ACPI: Thermal Zone [TZ1] (47 C)
+ACPI: Thermal Zone [TZ1] (39 C)
 thermal LNXTHERM:04: registered as thermal_zone3
-ACPI: Thermal Zone [TZ3] (36 C)
+ACPI: Thermal Zone [TZ3] (26 C)
 thermal LNXTHERM:05: registered as thermal_zone4
-ACPI: Thermal Zone [TZ4] (30 C)
+ACPI: Thermal Zone [TZ4] (21 C)
 thermal LNXTHERM:06: registered as thermal_zone5
-ACPI: Thermal Zone [TZ5] (26 C)
+ACPI: Thermal Zone [TZ5] (0 C)
 e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k6
 e1000e: Copyright (c) 1999-2008 Intel Corporation.
 libata version 3.00 loaded.
 e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
 e1000e 0000:00:19.0: setting latency timer to 64
-e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
+e1000e 0000:00:19.0: irq 509 for MSI/MSI-X
 SCSI subsystem initialized
 ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
 uhci_hcd: USB Universal Host Controller Interface driver
 ricoh-mmc: Ricoh MMC Controller disabling driver
 ricoh-mmc: Copyright(c) Philip Langdale
 ricoh-mmc: Ricoh MMC controller found at 0000:02:06.3 [1180:0843] (rev 11)
 ricoh-mmc: Controller is now disabled.
 sdhci: Secure Digital Host Controller Interface driver
 sdhci: Copyright(c) Pierre Ossman
 sdhci-pci 0000:02:06.2: SDHCI controller found [1180:0822] (rev 21)
 sdhci-pci 0000:02:06.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20
 mmc0: SDHCI controller on PCI [0000:02:06.2] using PIO
 ohci1394 0000:02:06.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
 ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19]  MMIO=[e0101000-e01017ff]  Max Packet=[2048]  IR/IT contexts=[4/4]
 0000:00:19.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:1e:68:5e:3b:04
 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
 0000:00:19.0: eth0: MAC: 5, PHY: 6, PBA No: ffffff-0ff
 ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18
 ehci_hcd 0000:00:1a.7: setting latency timer to 64
 ehci_hcd 0000:00:1a.7: EHCI Host Controller
 ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1
 ehci_hcd 0000:00:1a.7: debug port 1
 ehci_hcd 0000:00:1a.7: cache line size of 32 is not supported
 ehci_hcd 0000:00:1a.7: irq 18, io mem 0xe0641000
 ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00
 usb usb1: configuration #1 chosen from 1 choice
 hub 1-0:1.0: USB hub found
 hub 1-0:1.0: 4 ports detected
 uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
 uhci_hcd 0000:00:1a.0: setting latency timer to 64
 uhci_hcd 0000:00:1a.0: UHCI Host Controller
 uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 2
 uhci_hcd 0000:00:1a.0: irq 16, io base 0x00002080
 usb usb2: configuration #1 chosen from 1 choice
 hub 2-0:1.0: USB hub found
 hub 2-0:1.0: 2 ports detected
 ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20
 ehci_hcd 0000:00:1d.7: setting latency timer to 64
 ehci_hcd 0000:00:1d.7: EHCI Host Controller
 ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 3
 ehci_hcd 0000:00:1d.7: debug port 1
 ehci_hcd 0000:00:1d.7: cache line size of 32 is not supported
 ehci_hcd 0000:00:1d.7: irq 20, io mem 0xe0648000
 ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
 usb usb3: configuration #1 chosen from 1 choice
 hub 3-0:1.0: USB hub found
 hub 3-0:1.0: 6 ports detected
 uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
 uhci_hcd 0000:00:1a.1: setting latency timer to 64
 uhci_hcd 0000:00:1a.1: UHCI Host Controller
 uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4
 uhci_hcd 0000:00:1a.1: irq 17, io base 0x000020a0
 usb usb4: configuration #1 chosen from 1 choice
 hub 4-0:1.0: USB hub found
 hub 4-0:1.0: 2 ports detected
 uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
 uhci_hcd 0000:00:1d.0: setting latency timer to 64
 uhci_hcd 0000:00:1d.0: UHCI Host Controller
 uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 5
 uhci_hcd 0000:00:1d.0: irq 20, io base 0x000020c0
 usb usb5: configuration #1 chosen from 1 choice
 hub 5-0:1.0: USB hub found
 hub 5-0:1.0: 2 ports detected
 uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 22 (level, low) -> IRQ 22
 uhci_hcd 0000:00:1d.1: setting latency timer to 64
 uhci_hcd 0000:00:1d.1: UHCI Host Controller
 uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 6
 uhci_hcd 0000:00:1d.1: irq 22, io base 0x000020e0
 usb usb6: configuration #1 chosen from 1 choice
 hub 6-0:1.0: USB hub found
 hub 6-0:1.0: 2 ports detected
 uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
 uhci_hcd 0000:00:1d.2: setting latency timer to 64
 uhci_hcd 0000:00:1d.2: UHCI Host Controller
 uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 7
 uhci_hcd 0000:00:1d.2: irq 18, io base 0x00002100
 usb usb7: configuration #1 chosen from 1 choice
 hub 7-0:1.0: USB hub found
 hub 7-0:1.0: 2 ports detected
 pata_acpi 0000:00:03.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
 pata_acpi 0000:00:03.2: setting latency timer to 64
 pata_acpi 0000:00:03.2: PCI INT C disabled
 pata_acpi 0000:00:1f.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
 pata_acpi 0000:00:1f.1: setting latency timer to 64
 pata_acpi 0000:00:1f.1: PCI INT A disabled
 ata_piix 0000:00:1f.1: version 2.12
 ata_piix 0000:00:1f.1: quirky BIOS, skipping spindown on poweroff and hibernation
 ata_piix 0000:00:1f.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
 ata_piix 0000:00:1f.1: setting latency timer to 64
 Uniform Multi-Platform E-IDE driver
 scsi0 : ata_piix
 scsi1 : ata_piix
 ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x2120 irq 14
 ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x2128 irq 15
 ata1.00: ATA-7: SAMSUNG HS122JC, GQ100-04, max UDMA/100
 ata1.00: 234441648 sectors, multi 16: LBA 
 ata1.01: ATAPI: MATSHITADVD-RAM UJ-852S, 1.02, max MWDMA2
 ata1.00: configured for UDMA/100
 ata1.01: configured for MWDMA2
 ata2: port disabled. ignoring.
 isa bounce pool size: 16 pages
 scsi 0:0:0:0: Direct-Access     ATA      SAMSUNG HS122JC  GQ10 PQ: 0 ANSI: 5
 scsi 0:0:1:0: CD-ROM            MATSHITA DVD-RAM UJ-852S  1.02 PQ: 0 ANSI: 5
 Driver 'sd' needs updating - please use bus_type methods
 sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
 sd 0:0:0:0: [sda] Write Protect is off
 sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
 sd 0:0:0:0: [sda] Write Protect is off
 sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
  sda: sda1 sda2 sda3 sda4 <<4>Driver 'sr' needs updating - please use bus_type methods
  sda5 sda6 sda7 >
 sd 0:0:0:0: [sda] Attached SCSI disk
 sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
 Uniform CD-ROM driver Revision: 3.20
 sr 0:0:1:0: Attached scsi CD-ROM sr0
 sd 0:0:0:0: Attached scsi generic sg0 type 0
 sr 0:0:1:0: Attached scsi generic sg1 type 5
 Clocksource tsc unstable (delta = -96409064 ns)
 usb 5-2: new full speed USB device using uhci_hcd and address 2
 usb 5-2: configuration #1 chosen from 1 choice
 device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com
 usb 2-1: new full speed USB device using uhci_hcd and address 2
 ieee1394: Host added: ID:BUS[0-00:1023]  GUID[001b249929192210]
 usb 2-1: configuration #1 chosen from 1 choice
 PM: Starting manual resume from disk
 kjournald starting.  Commit interval 5 seconds
 EXT3-fs: mounted filesystem with ordered data mode.
 udevd version 125 started
 input: Power Button (FF) as /class/input/input1
 ACPI: Power Button (FF) [PWRF]
 input: Sleep Button (CM) as /class/input/input2
 ACPI: Sleep Button (CM) [C2BF]
 ACPI: AC Adapter [C23B] (off-line)
 input: Lid Switch as /class/input/input3
 ACPI: Lid Switch [C155]
 Registered led device: hp:red:hddprotection
 leds-hp-disk driver loaded.
 acpi device:02: registered as cooling_device9
 input: Video Bus as /class/input/input4
 ACPI: WMI: Mapper loaded
 ACPI: Video Device [C09A] (multi-head: yes  rom: no  post: no)
 ACPI: Battery Slot [C23D] (battery present)
 agpgart-intel 0000:00:00.0: Intel 965GM Chipset
 agpgart-intel 0000:00:00.0: detected 7676K stolen memory
 agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000
 cfg80211: Using static regulatory domain info
 cfg80211: Regulatory domain: EU
 	(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
 	(2402000 KHz - 2482000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
 	(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
 	(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
 	(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
 	(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
 	(5490000 KHz - 5710000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
 yenta_cardbus 0000:02:06.0: CardBus bridge found [103c:30c9]
 iTCO_wdt: Intel TCO WatchDog Timer Driver v1.03 (30-Apr-2008)
 iTCO_wdt: Found a ICH8M-E TCO device (Version=2, TCOBASE=0x1060)
 iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
+yenta_cardbus 0000:02:06.0: CardBus bridge, secondary bus 0000:03
+yenta_cardbus 0000:02:06.0:   IO window: 0x003000-0x0030ff
+yenta_cardbus 0000:02:06.0:   IO window: 0x003400-0x0034ff
+yenta_cardbus 0000:02:06.0:   PREFETCH window: 0x84400000-0x847fffff
+yenta_cardbus 0000:02:06.0:   MEM window: 0x80000000-0x83ffffff
 yenta_cardbus 0000:02:06.0: ISA IRQ mask 0x0cb8, PCI irq 18
 yenta_cardbus 0000:02:06.0: Socket status: 30000006
 pci_bus 0000:02: Raising subordinate bus# of parent bus (#02) from #03 to #06
 yenta_cardbus 0000:02:06.0: pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff
 yenta_cardbus 0000:02:06.0: pcmcia: parent PCI bridge Memory window: 0xe0100000 - 0xe03fffff
-yenta_cardbus 0000:02:06.0: pcmcia: parent PCI bridge Memory window: 0x80000000 - 0x83ffffff
 input: PC Speaker as /class/input/input5
 input: PS/2 Generic Mouse as /class/input/input6
 iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks
 iwlagn: Copyright(c) 2003-2008 Intel Corporation
 iwlagn 0000:10:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
 iwlagn 0000:10:00.0: setting latency timer to 64
 iwlagn: Detected Intel Wireless WiFi Link 4965AGN REV=0x4
 iwlagn: Tunable channels: 11 802.11bg, 13 802.11a channels
 iwlagn 0000:10:00.0: PCI INT A disabled
 phy0: Selected rate control algorithm 'iwl-agn-rs'
 HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
 HDA Intel 0000:00:1b.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
 HDA Intel 0000:00:1b.0: setting latency timer to 64
 Synaptics Touchpad, model: 1, fw: 6.3, id: 0x1a0b1, caps: 0xa04711/0xa00000
 input: SynPS/2 Synaptics TouchPad as /class/input/input7
 EXT3 FS on dm-1, internal journal
 loop: module loaded
 kjournald starting.  Commit interval 5 seconds
 EXT3 FS on dm-5, internal journal
 EXT3-fs: mounted filesystem with ordered data mode.
 kjournald starting.  Commit interval 5 seconds
 EXT3 FS on dm-6, internal journal
 EXT3-fs: mounted filesystem with ordered data mode.
 kjournald starting.  Commit interval 5 seconds
 EXT3 FS on dm-4, internal journal
 EXT3-fs: mounted filesystem with ordered data mode.
 kjournald starting.  Commit interval 5 seconds
 EXT3 FS on dm-2, internal journal
 EXT3-fs: mounted filesystem with ordered data mode.
 kjournald starting.  Commit interval 5 seconds
 EXT3 FS on dm-3, internal journal
 EXT3-fs: mounted filesystem with ordered data mode.
 Adding 2097144k swap on /dev/mapper/main-swap.  Priority:-1 extents:1 across:2097144k
 iwlagn 0000:10:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
 iwlagn 0000:10:00.0: restoring config space at offset 0x1 (was 0x100002, writing 0x100006)
-iwlagn 0000:10:00.0: irq 44 for MSI/MSI-X
+iwlagn 0000:10:00.0: irq 508 for MSI/MSI-X
 iwlagn 0000:10:00.0: firmware: requesting iwlwifi-4965-2.ucode
 Registered led device: iwl-phy0:radio
 Registered led device: iwl-phy0:assoc
 Registered led device: iwl-phy0:RX
 Registered led device: iwl-phy0:TX
 wlan0: authenticate with AP 00:14:c1:38:e5:15
 wlan0: authenticated
 wlan0: associate with AP 00:14:c1:38:e5:15
 wlan0: RX AssocResp from 00:14:c1:38:e5:15 (capab=0x411 status=0 aid=1)
 wlan0: associated
 NET: Registered protocol family 10
 lo: Disabled Privacy Extensions
 RPC: Registered udp transport module.
 RPC: Registered tcp transport module.
 wlan0: no IPv6 routers present
 [drm] Initialized drm 1.1.0 20060810
 pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
 pci 0000:00:02.0: setting latency timer to 64
 [drm] Initialized i915 1.6.0 20080730 on minor 0
 CPU0 attaching NULL sched-domain.
 CPU1 attaching NULL sched-domain.
 CPU0 attaching sched-domain:
  domain 0: span 0-1 level MC
   groups: 0 1
   domain 1: span 0-1 level CPU
    groups: 0-1
 CPU1 attaching sched-domain:
  domain 0: span 0-1 level MC
   groups: 1 0
   domain 1: span 0-1 level CPU
    groups: 0-1
-hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x006f0900
+e1000e 0000:00:19.0: PCI INT A disabled
+PM: Syncing filesystems ... done.
+Freezing user space processes ... (elapsed 0.00 seconds) done.
+Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
+Suspending console(s) (use no_console_suspend to debug)
+pci 0000:00:02.0: PCI INT A disabled
+sd 0:0:0:0: [sda] Synchronizing SCSI cache
+sd 0:0:0:0: [sda] Stopping disk
+ACPI handle has no context!
+ACPI handle has no context!
+sdhci-pci 0000:02:06.2: PCI INT C disabled
+ACPI handle has no context!
+ACPI handle has no context!
+iwlagn 0000:10:00.0: PCI INT A disabled
+ata2: port disabled. ignoring.
+ata_piix 0000:00:1f.1: PCI INT A disabled
+ehci_hcd 0000:00:1d.7: PCI INT A disabled
+uhci_hcd 0000:00:1d.2: PCI INT C disabled
+uhci_hcd 0000:00:1d.1: PCI INT B disabled
+uhci_hcd 0000:00:1d.0: PCI INT A disabled
+HDA Intel 0000:00:1b.0: PCI INT A disabled
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D3
+ehci_hcd 0000:00:1a.7: PCI INT C disabled
+uhci_hcd 0000:00:1a.1: PCI INT B disabled
+uhci_hcd 0000:00:1a.0: PCI INT A disabled
+ACPI handle has no context!
+ACPI: Preparing to enter system sleep state S3
+Disabling non-boot CPUs ...
+CPU 1 is now offline
+SMP alternatives: switching to UP code
+CPU0 attaching NULL sched-domain.
+CPU1 attaching NULL sched-domain.
+CPU0 attaching NULL sched-domain.
+CPU1 is down
+ricoh-mmc: Suspending.
+ricoh-mmc: Controller is now re-enabled.
+Extended CMOS year: 2000
+x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
+Back to C!
+Extended CMOS year: 2000
+ricoh-mmc: Resuming.
+ricoh-mmc: Controller is now disabled.
+Enabling non-boot CPUs ...
+SMP alternatives: switching to SMP code
+Booting processor 1 APIC 0x1 ip 0x6000
+Initializing CPU#1
+Calibrating delay using timer specific routine.. 2660.01 BogoMIPS (lpj=5320031)
+CPU: L1 I cache: 32K, L1 D cache: 32K
+CPU: L2 cache: 2048K
+CPU: Physical Processor ID: 0
+CPU: Processor Core ID: 1
+x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
+CPU1: Intel(R) Core(TM)2 Duo CPU     U7700  @ 1.33GHz stepping 0d
+CPU0 attaching NULL sched-domain.
+Switched to high resolution mode on CPU 1
+CPU0 attaching sched-domain:
+ domain 0: span 0-1 level MC
+  groups: 0 1
+  domain 1: span 0-1 level CPU
+   groups: 0-1
+CPU1 attaching sched-domain:
+ domain 0: span 0-1 level MC
+  groups: 1 0
+  domain 1: span 0-1 level CPU
+   groups: 0-1
+CPU1 is up
+ACPI: Waking up from system sleep state S3
+APIC error on CPU1: 00(40)
+ACPI: EC: non-query interrupt received, switching to interrupt mode
+pci 0000:00:02.0: restoring config space at offset 0x8 (was 0x1, writing 0x2001)
+pci 0000:00:02.1: restoring config space at offset 0x4 (was 0x4, writing 0xe0500004)
+pci 0000:00:02.1: restoring config space at offset 0x1 (was 0x900000, writing 0x900007)
+pci 0000:00:03.0: restoring config space at offset 0xf (was 0x100, writing 0x1ff)
+pci 0000:00:03.0: restoring config space at offset 0x4 (was 0xfed12004, writing 0xe0600004)
+pci 0000:00:03.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+pci 0000:00:03.2: restoring config space at offset 0x8 (was 0x1, writing 0x2031)
+pci 0000:00:03.2: restoring config space at offset 0x7 (was 0x1, writing 0x2021)
+pci 0000:00:03.2: restoring config space at offset 0x6 (was 0x1, writing 0x2019)
+pci 0000:00:03.2: restoring config space at offset 0x5 (was 0x1, writing 0x2011)
+pci 0000:00:03.2: restoring config space at offset 0x4 (was 0x1, writing 0x2009)
+pci 0000:00:03.2: restoring config space at offset 0x1 (was 0xb00000, writing 0xb00001)
+serial 0000:00:03.3: restoring config space at offset 0xf (was 0x200, writing 0x20a)
+serial 0000:00:03.3: restoring config space at offset 0x5 (was 0x0, writing 0xe0601000)
+serial 0000:00:03.3: restoring config space at offset 0x4 (was 0x1, writing 0x2041)
+serial 0000:00:03.3: restoring config space at offset 0x1 (was 0xb00000, writing 0xb00007)
+pci 0000:00:19.0: restoring config space at offset 0xf (was 0x100, writing 0x10b)
+pci 0000:00:19.0: restoring config space at offset 0x6 (was 0x1, writing 0x2061)
+pci 0000:00:19.0: restoring config space at offset 0x5 (was 0x0, writing 0xe0640000)
+pci 0000:00:19.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100003)
+uhci_hcd 0000:00:1a.0: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+uhci_hcd 0000:00:1a.0: setting latency timer to 64
+uhci_hcd 0000:00:1a.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+uhci_hcd 0000:00:1a.0: restoring config space at offset 0x8 (was 0x1, writing 0x2081)
+usb usb2: root hub lost power or was reset
+uhci_hcd 0000:00:1a.1: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
+uhci_hcd 0000:00:1a.1: setting latency timer to 64
+uhci_hcd 0000:00:1a.1: restoring config space at offset 0xf (was 0x200, writing 0x20a)
+uhci_hcd 0000:00:1a.1: restoring config space at offset 0x8 (was 0x1, writing 0x20a1)
+usb usb4: root hub lost power or was reset
+ehci_hcd 0000:00:1a.7: enabling device (0000 -> 0002)
+ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18
+ehci_hcd 0000:00:1a.7: setting latency timer to 64
+ehci_hcd 0000:00:1a.7: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+ehci_hcd 0000:00:1a.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0641000)
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
+HDA Intel 0000:00:1b.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+HDA Intel 0000:00:1b.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
+HDA Intel 0000:00:1b.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100002)
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
+HDA Intel 0000:00:1b.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
+HDA Intel 0000:00:1b.0: setting latency timer to 64
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0xf (was 0x100, writing 0x4010a)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x8 (was 0x0, writing 0xfff0)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x7 (was 0x0, writing 0x200000f0)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x6 (was 0x0, writing 0x80800)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x3 (was 0x810000, writing 0x810010)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100407)
+pcieport-driver 0000:00:1c.0: setting latency timer to 64
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0xf (was 0x200, writing 0x4020a)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x8 (was 0x0, writing 0xe000e000)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x7 (was 0x0, writing 0xf0)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x3 (was 0x810000, writing 0x810010)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x1 (was 0x100000, writing 0x100407)
+pcieport-driver 0000:00:1c.1: setting latency timer to 64
+uhci_hcd 0000:00:1d.0: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
+uhci_hcd 0000:00:1d.0: setting latency timer to 64
+uhci_hcd 0000:00:1d.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+uhci_hcd 0000:00:1d.0: restoring config space at offset 0x8 (was 0x1, writing 0x20c1)
+usb usb5: root hub lost power or was reset
+uhci_hcd 0000:00:1d.1: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 22 (level, low) -> IRQ 22
+uhci_hcd 0000:00:1d.1: setting latency timer to 64
+uhci_hcd 0000:00:1d.1: restoring config space at offset 0xf (was 0x200, writing 0x20b)
+uhci_hcd 0000:00:1d.1: restoring config space at offset 0x8 (was 0x1, writing 0x20e1)
+usb usb6: root hub lost power or was reset
+uhci_hcd 0000:00:1d.2: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
+uhci_hcd 0000:00:1d.2: setting latency timer to 64
+uhci_hcd 0000:00:1d.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+uhci_hcd 0000:00:1d.2: restoring config space at offset 0x8 (was 0x1, writing 0x2101)
+usb usb7: root hub lost power or was reset
+ehci_hcd 0000:00:1d.7: enabling device (0000 -> 0002)
+ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20
+ehci_hcd 0000:00:1d.7: setting latency timer to 64
+ehci_hcd 0000:00:1d.7: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+ehci_hcd 0000:00:1d.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0648000)
+pci 0000:00:1e.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pci 0000:00:1e.0: restoring config space at offset 0x8 (was 0x0, writing 0xe030e010)
+pci 0000:00:1e.0: restoring config space at offset 0x7 (was 0x228000f0, writing 0x22803030)
+pci 0000:00:1e.0: restoring config space at offset 0x1 (was 0x100007, writing 0x100107)
+pci 0000:00:1e.0: setting latency timer to 64
+ata_piix 0000:00:1f.1: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+ata_piix 0000:00:1f.1: restoring config space at offset 0x8 (was 0xc01, writing 0x2121)
+ata_piix 0000:00:1f.1: restoring config space at offset 0x1 (was 0x2800005, writing 0x2880005)
+ata_piix 0000:00:1f.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+ata_piix 0000:00:1f.1: setting latency timer to 64
+ata2: port disabled. ignoring.
+ACPI Exception (exoparg2-0444): AE_AML_PACKAGE_LIMIT, Index (000000005) is beyond end of object [20080926]
+ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.C2C3] (Node ffff88007e01de80), AE_AML_PACKAGE_LIMIT
+ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.C003.C0F6.C3F3._STM] (Node ffff88007e043dc0), AE_AML_PACKAGE_LIMIT
+ata1: ACPI set timing mode failed (status=0x300b)
+iwlagn 0000:10:00.0: enabling device (0000 -> 0002)
+iwlagn 0000:10:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
+iwlagn 0000:10:00.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+iwlagn 0000:10:00.0: restoring config space at offset 0x4 (was 0x4, writing 0xe0000004)
+iwlagn 0000:10:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
+iwlagn 0000:10:00.0: restoring config space at offset 0x1 (was 0x100002, writing 0x100006)
+iwlagn 0000:10:00.0: irq 509 for MSI/MSI-X
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xf (was 0x3000100, writing 0x580010b)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xe (was 0x0, writing 0x34fc)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xd (was 0x0, writing 0x3400)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xc (was 0x0, writing 0x30fc)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xb (was 0x0, writing 0x3000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xa (was 0x0, writing 0x83fff000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x9 (was 0x0, writing 0x80000000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x8 (was 0x0, writing 0x847ff000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x7 (was 0x0, writing 0x84400000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x6 (was 0x0, writing 0xb0060302)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x4 (was 0x0, writing 0xe0100000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x3 (was 0x820000, writing 0x82a800)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100007)
+ohci1394 0000:02:06.1: restoring config space at offset 0xf (was 0x4020200, writing 0x4020205)
+ohci1394 0000:02:06.1: restoring config space at offset 0x4 (was 0x0, writing 0xe0101000)
+ohci1394 0000:02:06.1: restoring config space at offset 0x3 (was 0x800000, writing 0x804010)
+ohci1394 0000:02:06.1: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006)
+Registered led device: iwl-phy0:radio
+Registered led device: iwl-phy0:assoc
+Registered led device: iwl-phy0:RX
+Registered led device: iwl-phy0:TX
+ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19]  MMIO=[e0101000-e01017ff]  Max Packet=[2048]  IR/IT contexts=[4/4]
+sdhci-pci 0000:02:06.2: restoring config space at offset 0xf (was 0x300, writing 0x30a)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x4 (was 0x0, writing 0xe0102000)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x3 (was 0x800000, writing 0x804010)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006)
+sdhci-pci 0000:02:06.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20
+sd 0:0:0:0: [sda] Starting disk
+ata1.01: ACPI cmd ef/03:0c:00:00:00:b0 filtered out
+ata1.01: ACPI cmd ef/03:40:00:00:00:b0 filtered out
+ata1.00: ACPI cmd ef/03:01:00:00:00:a0 filtered out
+ata1.00: ACPI cmd ef/03:45:00:00:00:a0 filtered out
+ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
+ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 filtered out
+ata1.00: ACPI cmd c6/00:10:00:00:00:a0 succeeded
+ata1.00: configured for UDMA/100
+ata1.01: configured for MWDMA2
+ata1.00: configured for UDMA/100
+ata1.01: configured for MWDMA2
+ata1: EH complete
+sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
+sd 0:0:0:0: [sda] Write Protect is off
+sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
+sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
+sd 0:0:0:0: [sda] Write Protect is off
+sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
+sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+usb 5-2: reset full speed USB device using uhci_hcd and address 2
+usb 2-1: reset full speed USB device using uhci_hcd and address 2
+pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+pci 0000:00:02.0: setting latency timer to 64
+Restarting tasks ... done.
+e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k6
+e1000e: Copyright (c) 1999-2008 Intel Corporation.
+e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
+e1000e 0000:00:19.0: setting latency timer to 64
+e1000e 0000:00:19.0: irq 508 for MSI/MSI-X
+0000:00:19.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:1e:68:5e:3b:04
+0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
+0000:00:19.0: eth0: MAC: 5, PHY: 6, PBA No: ffffff-0ff
+PM: Syncing filesystems ... done.
+Freezing user space processes ... (elapsed 0.00 seconds) done.
+Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
+Suspending console(s) (use no_console_suspend to debug)
+pci 0000:00:02.0: PCI INT A disabled
+sd 0:0:0:0: [sda] Synchronizing SCSI cache
+sd 0:0:0:0: [sda] Stopping disk
+ACPI handle has no context!
+ACPI handle has no context!
+sdhci-pci 0000:02:06.2: PCI INT C disabled
+ACPI handle has no context!
+ACPI handle has no context!
+iwlagn 0000:10:00.0: PCI INT A disabled
+ata2: port disabled. ignoring.
+ata_piix 0000:00:1f.1: PCI INT A disabled
+ehci_hcd 0000:00:1d.7: PCI INT A disabled
+uhci_hcd 0000:00:1d.2: PCI INT C disabled
+uhci_hcd 0000:00:1d.1: PCI INT B disabled
+uhci_hcd 0000:00:1d.0: PCI INT A disabled
+HDA Intel 0000:00:1b.0: PCI INT A disabled
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D3
+ehci_hcd 0000:00:1a.7: PCI INT C disabled
+uhci_hcd 0000:00:1a.1: PCI INT B disabled
+uhci_hcd 0000:00:1a.0: PCI INT A disabled
+e1000e 0000:00:19.0: PME# enabled
+e1000e 0000:00:19.0: wake-up capability enabled by ACPI
+e1000e 0000:00:19.0: PME# enabled
+e1000e 0000:00:19.0: wake-up capability enabled by ACPI
+e1000e 0000:00:19.0: PCI INT A disabled
+ACPI handle has no context!
+ACPI: Preparing to enter system sleep state S3
+Disabling non-boot CPUs ...
+CPU 1 is now offline
+SMP alternatives: switching to UP code
+CPU0 attaching NULL sched-domain.
+CPU1 attaching NULL sched-domain.
+CPU0 attaching NULL sched-domain.
+CPU1 is down
+ricoh-mmc: Suspending.
+ricoh-mmc: Controller is now re-enabled.
+Extended CMOS year: 2000
+x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
+Back to C!
+Extended CMOS year: 2000
+ricoh-mmc: Resuming.
+ricoh-mmc: Controller is now disabled.
+Enabling non-boot CPUs ...
+SMP alternatives: switching to SMP code
+Booting processor 1 APIC 0x1 ip 0x6000
+Initializing CPU#1
+Calibrating delay using timer specific routine.. 2660.06 BogoMIPS (lpj=5320131)
+CPU: L1 I cache: 32K, L1 D cache: 32K
+CPU: L2 cache: 2048K
+CPU: Physical Processor ID: 0
+CPU: Processor Core ID: 1
+x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
+CPU1: Intel(R) Core(TM)2 Duo CPU     U7700  @ 1.33GHz stepping 0d
+CPU0 attaching NULL sched-domain.
+Switched to high resolution mode on CPU 1
+CPU0 attaching sched-domain:
+ domain 0: span 0-1 level MC
+  groups: 0 1
+  domain 1: span 0-1 level CPU
+   groups: 0-1
+CPU1 attaching sched-domain:
+ domain 0: span 0-1 level MC
+  groups: 1 0
+  domain 1: span 0-1 level CPU
+   groups: 0-1
+CPU1 is up
+ACPI: Waking up from system sleep state S3
+APIC error on CPU1: 00(40)
+ACPI: EC: non-query interrupt received, switching to interrupt mode
+pci 0000:00:02.0: restoring config space at offset 0x8 (was 0x1, writing 0x2001)
+pci 0000:00:02.1: restoring config space at offset 0x4 (was 0x4, writing 0xe0500004)
+pci 0000:00:02.1: restoring config space at offset 0x1 (was 0x900000, writing 0x900007)
+pci 0000:00:03.0: restoring config space at offset 0xf (was 0x100, writing 0x1ff)
+pci 0000:00:03.0: restoring config space at offset 0x4 (was 0xfed12004, writing 0xe0600004)
+pci 0000:00:03.0: restoring config space at offset 0x1 (was 0x100006, writing 0x180006)
+pci 0000:00:03.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+pci 0000:00:03.2: restoring config space at offset 0x8 (was 0x1, writing 0x2031)
+pci 0000:00:03.2: restoring config space at offset 0x7 (was 0x1, writing 0x2021)
+pci 0000:00:03.2: restoring config space at offset 0x6 (was 0x1, writing 0x2019)
+pci 0000:00:03.2: restoring config space at offset 0x5 (was 0x1, writing 0x2011)
+pci 0000:00:03.2: restoring config space at offset 0x4 (was 0x1, writing 0x2009)
+pci 0000:00:03.2: restoring config space at offset 0x1 (was 0xb00000, writing 0xb00001)
+serial 0000:00:03.3: restoring config space at offset 0xf (was 0x200, writing 0x20a)
+serial 0000:00:03.3: restoring config space at offset 0x5 (was 0x0, writing 0xe0601000)
+serial 0000:00:03.3: restoring config space at offset 0x4 (was 0x1, writing 0x2041)
+serial 0000:00:03.3: restoring config space at offset 0x1 (was 0xb00000, writing 0xb00007)
+e1000e 0000:00:19.0: restoring config space at offset 0xf (was 0x100, writing 0x10b)
+e1000e 0000:00:19.0: restoring config space at offset 0x6 (was 0x1, writing 0x2061)
+e1000e 0000:00:19.0: restoring config space at offset 0x5 (was 0x0, writing 0xe0640000)
+e1000e 0000:00:19.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100007)
+e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
+e1000e 0000:00:19.0: setting latency timer to 64
+e1000e 0000:00:19.0: wake-up capability disabled by ACPI
+e1000e 0000:00:19.0: PME# disabled
+e1000e 0000:00:19.0: wake-up capability disabled by ACPI
+e1000e 0000:00:19.0: PME# disabled
+e1000e 0000:00:19.0: irq 509 for MSI/MSI-X
+uhci_hcd 0000:00:1a.0: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+uhci_hcd 0000:00:1a.0: setting latency timer to 64
+uhci_hcd 0000:00:1a.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+uhci_hcd 0000:00:1a.0: restoring config space at offset 0x8 (was 0x1, writing 0x2081)
+usb usb2: root hub lost power or was reset
+uhci_hcd 0000:00:1a.1: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
+uhci_hcd 0000:00:1a.1: setting latency timer to 64
+uhci_hcd 0000:00:1a.1: restoring config space at offset 0xf (was 0x200, writing 0x20a)
+uhci_hcd 0000:00:1a.1: restoring config space at offset 0x8 (was 0x1, writing 0x20a1)
+usb usb4: root hub lost power or was reset
+ehci_hcd 0000:00:1a.7: enabling device (0000 -> 0002)
+ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18
+ehci_hcd 0000:00:1a.7: setting latency timer to 64
+ehci_hcd 0000:00:1a.7: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+ehci_hcd 0000:00:1a.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0641000)
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
+HDA Intel 0000:00:1b.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+HDA Intel 0000:00:1b.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
+HDA Intel 0000:00:1b.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100002)
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
+HDA Intel 0000:00:1b.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
+HDA Intel 0000:00:1b.0: setting latency timer to 64
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0xf (was 0x100, writing 0x4010a)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x8 (was 0x0, writing 0xfff0)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x7 (was 0x0, writing 0xf0)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x6 (was 0x0, writing 0x80800)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x3 (was 0x810000, writing 0x810010)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100407)
+pcieport-driver 0000:00:1c.0: setting latency timer to 64
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0xf (was 0x200, writing 0x4020a)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x8 (was 0x0, writing 0xe000e000)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x7 (was 0x0, writing 0xf0)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x3 (was 0x810000, writing 0x810010)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x1 (was 0x100000, writing 0x100407)
+pcieport-driver 0000:00:1c.1: setting latency timer to 64
+uhci_hcd 0000:00:1d.0: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
+uhci_hcd 0000:00:1d.0: setting latency timer to 64
+uhci_hcd 0000:00:1d.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+uhci_hcd 0000:00:1d.0: restoring config space at offset 0x8 (was 0x1, writing 0x20c1)
+usb usb5: root hub lost power or was reset
+uhci_hcd 0000:00:1d.1: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 22 (level, low) -> IRQ 22
+uhci_hcd 0000:00:1d.1: setting latency timer to 64
+uhci_hcd 0000:00:1d.1: restoring config space at offset 0xf (was 0x200, writing 0x20b)
+uhci_hcd 0000:00:1d.1: restoring config space at offset 0x8 (was 0x1, writing 0x20e1)
+usb usb6: root hub lost power or was reset
+uhci_hcd 0000:00:1d.2: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
+uhci_hcd 0000:00:1d.2: setting latency timer to 64
+uhci_hcd 0000:00:1d.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+uhci_hcd 0000:00:1d.2: restoring config space at offset 0x8 (was 0x1, writing 0x2101)
+usb usb7: root hub lost power or was reset
+ehci_hcd 0000:00:1d.7: enabling device (0000 -> 0002)
+ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20
+ehci_hcd 0000:00:1d.7: setting latency timer to 64
+ehci_hcd 0000:00:1d.7: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+ehci_hcd 0000:00:1d.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0648000)
+pci 0000:00:1e.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pci 0000:00:1e.0: restoring config space at offset 0x8 (was 0x0, writing 0xe030e010)
+pci 0000:00:1e.0: restoring config space at offset 0x7 (was 0x228000f0, writing 0x22803030)
+pci 0000:00:1e.0: restoring config space at offset 0x1 (was 0x100007, writing 0x100107)
+pci 0000:00:1e.0: setting latency timer to 64
+ata_piix 0000:00:1f.1: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+ata_piix 0000:00:1f.1: restoring config space at offset 0x8 (was 0xc01, writing 0x2121)
+ata_piix 0000:00:1f.1: restoring config space at offset 0x1 (was 0x2800005, writing 0x2880005)
+ata_piix 0000:00:1f.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+ata_piix 0000:00:1f.1: setting latency timer to 64
+ata2: port disabled. ignoring.
+ACPI Exception (exoparg2-0444): AE_AML_PACKAGE_LIMIT, Index (000000005) is beyond end of object [20080926]
+ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.C2C3] (Node ffff88007e01de80), AE_AML_PACKAGE_LIMIT
+ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.C003.C0F6.C3F3._STM] (Node ffff88007e043dc0), AE_AML_PACKAGE_LIMIT
+ata1: ACPI set timing mode failed (status=0x300b)
+iwlagn 0000:10:00.0: enabling device (0000 -> 0002)
+iwlagn 0000:10:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
+iwlagn 0000:10:00.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+iwlagn 0000:10:00.0: restoring config space at offset 0x4 (was 0x4, writing 0xe0000004)
+iwlagn 0000:10:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
+iwlagn 0000:10:00.0: restoring config space at offset 0x1 (was 0x100002, writing 0x100006)
+iwlagn 0000:10:00.0: irq 508 for MSI/MSI-X
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xf (was 0x3000100, writing 0x580010b)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xe (was 0x0, writing 0x34fc)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xd (was 0x0, writing 0x3400)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xc (was 0x0, writing 0x30fc)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xb (was 0x0, writing 0x3000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xa (was 0x0, writing 0x83fff000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x9 (was 0x0, writing 0x80000000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x8 (was 0x0, writing 0x847ff000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x7 (was 0x0, writing 0x84400000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x6 (was 0x0, writing 0xb0060302)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x4 (was 0x0, writing 0xe0100000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x3 (was 0x820000, writing 0x82a800)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100007)
+ohci1394 0000:02:06.1: restoring config space at offset 0xf (was 0x4020200, writing 0x4020205)
+ohci1394 0000:02:06.1: restoring config space at offset 0x4 (was 0x0, writing 0xe0101000)
+ohci1394 0000:02:06.1: restoring config space at offset 0x3 (was 0x800000, writing 0x804010)
+ohci1394 0000:02:06.1: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006)
+ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19]  MMIO=[e0101000-e01017ff]  Max Packet=[2048]  IR/IT contexts=[4/4]
+sdhci-pci 0000:02:06.2: restoring config space at offset 0xf (was 0x300, writing 0x30a)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x4 (was 0x0, writing 0xe0102000)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x3 (was 0x800000, writing 0x804010)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006)
+sdhci-pci 0000:02:06.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20
+Registered led device: iwl-phy0:radio
+Registered led device: iwl-phy0:assoc
+Registered led device: iwl-phy0:RX
+Registered led device: iwl-phy0:TX
+sd 0:0:0:0: [sda] Starting disk
+ata1.01: ACPI cmd ef/03:0c:00:00:00:b0 filtered out
+ata1.01: ACPI cmd ef/03:40:00:00:00:b0 filtered out
+ata1.00: ACPI cmd ef/03:01:00:00:00:a0 filtered out
+ata1.00: ACPI cmd ef/03:45:00:00:00:a0 filtered out
+ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
+ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 filtered out
+ata1.00: ACPI cmd c6/00:10:00:00:00:a0 succeeded
+ata1.00: configured for UDMA/100
+ata1.01: configured for MWDMA2
+ata1.00: configured for UDMA/100
+ata1.01: configured for MWDMA2
+ata1: EH complete
+sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
+sd 0:0:0:0: [sda] Write Protect is off
+sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
+sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
+sd 0:0:0:0: [sda] Write Protect is off
+sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
+sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+usb 5-2: reset full speed USB device using uhci_hcd and address 2
+usb 2-1: reset full speed USB device using uhci_hcd and address 2
+pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+pci 0000:00:02.0: setting latency timer to 64
+Restarting tasks ... done.
+PM: Syncing filesystems ... done.
+Freezing user space processes ... (elapsed 0.00 seconds) done.
+Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
+Suspending console(s) (use no_console_suspend to debug)
+pci 0000:00:02.0: PCI INT A disabled
+sd 0:0:0:0: [sda] Synchronizing SCSI cache
+sd 0:0:0:0: [sda] Stopping disk
+ACPI handle has no context!
+ACPI handle has no context!
+sdhci-pci 0000:02:06.2: PCI INT C disabled
+ACPI handle has no context!
+ACPI handle has no context!
+iwlagn 0000:10:00.0: PCI INT A disabled
+ata2: port disabled. ignoring.
+ata_piix 0000:00:1f.1: PCI INT A disabled
+ehci_hcd 0000:00:1d.7: PCI INT A disabled
+uhci_hcd 0000:00:1d.2: PCI INT C disabled
+uhci_hcd 0000:00:1d.1: PCI INT B disabled
+uhci_hcd 0000:00:1d.0: PCI INT A disabled
+HDA Intel 0000:00:1b.0: PCI INT A disabled
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D3
+ehci_hcd 0000:00:1a.7: PCI INT C disabled
+uhci_hcd 0000:00:1a.1: PCI INT B disabled
+uhci_hcd 0000:00:1a.0: PCI INT A disabled
+e1000e 0000:00:19.0: PME# enabled
+e1000e 0000:00:19.0: wake-up capability enabled by ACPI
+e1000e 0000:00:19.0: PME# enabled
+e1000e 0000:00:19.0: wake-up capability enabled by ACPI
+e1000e 0000:00:19.0: PCI INT A disabled
+ACPI handle has no context!
+ACPI: Preparing to enter system sleep state S3
+Disabling non-boot CPUs ...
+CPU 1 is now offline
+SMP alternatives: switching to UP code
+CPU0 attaching NULL sched-domain.
+CPU1 attaching NULL sched-domain.
+CPU0 attaching NULL sched-domain.
+CPU1 is down
+ricoh-mmc: Suspending.
+ricoh-mmc: Controller is now re-enabled.
+Extended CMOS year: 2000
+x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
+Back to C!
+Extended CMOS year: 2000
+ricoh-mmc: Resuming.
+ricoh-mmc: Controller is now disabled.
+Enabling non-boot CPUs ...
+SMP alternatives: switching to SMP code
+Booting processor 1 APIC 0x1 ip 0x6000
+Initializing CPU#1
+Calibrating delay using timer specific routine.. 2660.08 BogoMIPS (lpj=5320176)
+CPU: L1 I cache: 32K, L1 D cache: 32K
+CPU: L2 cache: 2048K
+CPU: Physical Processor ID: 0
+CPU: Processor Core ID: 1
+x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
+CPU1: Intel(R) Core(TM)2 Duo CPU     U7700  @ 1.33GHz stepping 0d
+CPU0 attaching NULL sched-domain.
+Switched to high resolution mode on CPU 1
+CPU0 attaching sched-domain:
+ domain 0: span 0-1 level MC
+  groups: 0 1
+  domain 1: span 0-1 level CPU
+   groups: 0-1
+CPU1 attaching sched-domain:
+ domain 0: span 0-1 level MC
+  groups: 1 0
+  domain 1: span 0-1 level CPU
+   groups: 0-1
+CPU1 is up
+ACPI: Waking up from system sleep state S3
+APIC error on CPU1: 00(40)
+ACPI: EC: non-query interrupt received, switching to interrupt mode
+pci 0000:00:02.0: restoring config space at offset 0x8 (was 0x1, writing 0x2001)
+pci 0000:00:02.1: restoring config space at offset 0x4 (was 0x4, writing 0xe0500004)
+pci 0000:00:02.1: restoring config space at offset 0x1 (was 0x900000, writing 0x900007)
+pci 0000:00:03.0: restoring config space at offset 0xf (was 0x100, writing 0x1ff)
+pci 0000:00:03.0: restoring config space at offset 0x4 (was 0xfed12004, writing 0xe0600004)
+pci 0000:00:03.0: restoring config space at offset 0x1 (was 0x100006, writing 0x180006)
+pci 0000:00:03.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+pci 0000:00:03.2: restoring config space at offset 0x8 (was 0x1, writing 0x2031)
+pci 0000:00:03.2: restoring config space at offset 0x7 (was 0x1, writing 0x2021)
+pci 0000:00:03.2: restoring config space at offset 0x6 (was 0x1, writing 0x2019)
+pci 0000:00:03.2: restoring config space at offset 0x5 (was 0x1, writing 0x2011)
+pci 0000:00:03.2: restoring config space at offset 0x4 (was 0x1, writing 0x2009)
+pci 0000:00:03.2: restoring config space at offset 0x1 (was 0xb00000, writing 0xb00001)
+serial 0000:00:03.3: restoring config space at offset 0xf (was 0x200, writing 0x20a)
+serial 0000:00:03.3: restoring config space at offset 0x5 (was 0x0, writing 0xe0601000)
+serial 0000:00:03.3: restoring config space at offset 0x4 (was 0x1, writing 0x2041)
+serial 0000:00:03.3: restoring config space at offset 0x1 (was 0xb00000, writing 0xb00007)
+e1000e 0000:00:19.0: restoring config space at offset 0xf (was 0x100, writing 0x10b)
+e1000e 0000:00:19.0: restoring config space at offset 0x6 (was 0x1, writing 0x2061)
+e1000e 0000:00:19.0: restoring config space at offset 0x5 (was 0x0, writing 0xe0640000)
+e1000e 0000:00:19.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100007)
+e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
+e1000e 0000:00:19.0: setting latency timer to 64
+e1000e 0000:00:19.0: wake-up capability disabled by ACPI
+e1000e 0000:00:19.0: PME# disabled
+e1000e 0000:00:19.0: wake-up capability disabled by ACPI
+e1000e 0000:00:19.0: PME# disabled
+e1000e 0000:00:19.0: irq 509 for MSI/MSI-X
+uhci_hcd 0000:00:1a.0: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+uhci_hcd 0000:00:1a.0: setting latency timer to 64
+uhci_hcd 0000:00:1a.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+uhci_hcd 0000:00:1a.0: restoring config space at offset 0x8 (was 0x1, writing 0x2081)
+usb usb2: root hub lost power or was reset
+uhci_hcd 0000:00:1a.1: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
+uhci_hcd 0000:00:1a.1: setting latency timer to 64
+uhci_hcd 0000:00:1a.1: restoring config space at offset 0xf (was 0x200, writing 0x20a)
+uhci_hcd 0000:00:1a.1: restoring config space at offset 0x8 (was 0x1, writing 0x20a1)
+usb usb4: root hub lost power or was reset
+ehci_hcd 0000:00:1a.7: enabling device (0000 -> 0002)
+ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18
+ehci_hcd 0000:00:1a.7: setting latency timer to 64
+ehci_hcd 0000:00:1a.7: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+ehci_hcd 0000:00:1a.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0641000)
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
+HDA Intel 0000:00:1b.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+HDA Intel 0000:00:1b.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
+HDA Intel 0000:00:1b.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100002)
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
+HDA Intel 0000:00:1b.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
+HDA Intel 0000:00:1b.0: setting latency timer to 64
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0xf (was 0x100, writing 0x4010a)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x8 (was 0x0, writing 0xfff0)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x7 (was 0x0, writing 0xf0)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x6 (was 0x0, writing 0x80800)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x3 (was 0x810000, writing 0x810010)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100407)
+pcieport-driver 0000:00:1c.0: setting latency timer to 64
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0xf (was 0x200, writing 0x4020a)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x8 (was 0x0, writing 0xe000e000)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x7 (was 0x0, writing 0xf0)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x3 (was 0x810000, writing 0x810010)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x1 (was 0x100000, writing 0x100407)
+pcieport-driver 0000:00:1c.1: setting latency timer to 64
+uhci_hcd 0000:00:1d.0: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
+uhci_hcd 0000:00:1d.0: setting latency timer to 64
+uhci_hcd 0000:00:1d.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+uhci_hcd 0000:00:1d.0: restoring config space at offset 0x8 (was 0x1, writing 0x20c1)
+usb usb5: root hub lost power or was reset
+uhci_hcd 0000:00:1d.1: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 22 (level, low) -> IRQ 22
+uhci_hcd 0000:00:1d.1: setting latency timer to 64
+uhci_hcd 0000:00:1d.1: restoring config space at offset 0xf (was 0x200, writing 0x20b)
+uhci_hcd 0000:00:1d.1: restoring config space at offset 0x8 (was 0x1, writing 0x20e1)
+usb usb6: root hub lost power or was reset
+uhci_hcd 0000:00:1d.2: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
+uhci_hcd 0000:00:1d.2: setting latency timer to 64
+uhci_hcd 0000:00:1d.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+uhci_hcd 0000:00:1d.2: restoring config space at offset 0x8 (was 0x1, writing 0x2101)
+usb usb7: root hub lost power or was reset
+ehci_hcd 0000:00:1d.7: enabling device (0000 -> 0002)
+ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20
+ehci_hcd 0000:00:1d.7: setting latency timer to 64
+ehci_hcd 0000:00:1d.7: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+ehci_hcd 0000:00:1d.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0648000)
+pci 0000:00:1e.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pci 0000:00:1e.0: restoring config space at offset 0x8 (was 0x0, writing 0xe030e010)
+pci 0000:00:1e.0: restoring config space at offset 0x7 (was 0x228000f0, writing 0x22803030)
+pci 0000:00:1e.0: restoring config space at offset 0x1 (was 0x100007, writing 0x100107)
+pci 0000:00:1e.0: setting latency timer to 64
+ata_piix 0000:00:1f.1: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+ata_piix 0000:00:1f.1: restoring config space at offset 0x8 (was 0xc01, writing 0x2121)
+ata_piix 0000:00:1f.1: restoring config space at offset 0x1 (was 0x2800005, writing 0x2880005)
+ata_piix 0000:00:1f.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+ata_piix 0000:00:1f.1: setting latency timer to 64
+ata2: port disabled. ignoring.
+ACPI Exception (exoparg2-0444): AE_AML_PACKAGE_LIMIT, Index (000000005) is beyond end of object [20080926]
+ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.C2C3] (Node ffff88007e01de80), AE_AML_PACKAGE_LIMIT
+ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.C003.C0F6.C3F3._STM] (Node ffff88007e043dc0), AE_AML_PACKAGE_LIMIT
+ata1: ACPI set timing mode failed (status=0x300b)
+iwlagn 0000:10:00.0: enabling device (0000 -> 0002)
+iwlagn 0000:10:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
+iwlagn 0000:10:00.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+iwlagn 0000:10:00.0: restoring config space at offset 0x4 (was 0x4, writing 0xe0000004)
+iwlagn 0000:10:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
+iwlagn 0000:10:00.0: restoring config space at offset 0x1 (was 0x100002, writing 0x100006)
+iwlagn 0000:10:00.0: irq 508 for MSI/MSI-X
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xf (was 0x3000100, writing 0x580010b)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xe (was 0x0, writing 0x34fc)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xd (was 0x0, writing 0x3400)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xc (was 0x0, writing 0x30fc)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xb (was 0x0, writing 0x3000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xa (was 0x0, writing 0x83fff000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x9 (was 0x0, writing 0x80000000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x8 (was 0x0, writing 0x847ff000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x7 (was 0x0, writing 0x84400000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x6 (was 0x0, writing 0xb0060302)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x4 (was 0x0, writing 0xe0100000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x3 (was 0x820000, writing 0x82a800)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100007)
+ohci1394 0000:02:06.1: restoring config space at offset 0xf (was 0x4020200, writing 0x4020205)
+ohci1394 0000:02:06.1: restoring config space at offset 0x4 (was 0x0, writing 0xe0101000)
+ohci1394 0000:02:06.1: restoring config space at offset 0x3 (was 0x800000, writing 0x804010)
+ohci1394 0000:02:06.1: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006)
+Registered led device: iwl-phy0:radio
+Registered led device: iwl-phy0:assoc
+Registered led device: iwl-phy0:RX
+Registered led device: iwl-phy0:TX
+ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19]  MMIO=[e0101000-e01017ff]  Max Packet=[2048]  IR/IT contexts=[4/4]
+sdhci-pci 0000:02:06.2: restoring config space at offset 0xf (was 0x300, writing 0x30a)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x4 (was 0x0, writing 0xe0102000)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x3 (was 0x800000, writing 0x804010)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006)
+sdhci-pci 0000:02:06.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20
+sd 0:0:0:0: [sda] Starting disk
+ata1.01: ACPI cmd ef/03:0c:00:00:00:b0 filtered out
+ata1.01: ACPI cmd ef/03:40:00:00:00:b0 filtered out
+ata1.00: ACPI cmd ef/03:01:00:00:00:a0 filtered out
+ata1.00: ACPI cmd ef/03:45:00:00:00:a0 filtered out
+ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
+ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 filtered out
+ata1.00: ACPI cmd c6/00:10:00:00:00:a0 succeeded
+ata1.00: configured for UDMA/100
+ata1.01: configured for MWDMA2
+ata1.00: configured for UDMA/100
+ata1.01: configured for MWDMA2
+ata1: EH complete
+sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
+sd 0:0:0:0: [sda] Write Protect is off
+sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
+sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
+sd 0:0:0:0: [sda] Write Protect is off
+sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
+sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+usb 5-2: reset full speed USB device using uhci_hcd and address 2
+usb 2-1: reset full speed USB device using uhci_hcd and address 2
+pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+pci 0000:00:02.0: setting latency timer to 64
+Restarting tasks ... done.
+PM: Syncing filesystems ... done.
+Freezing user space processes ... (elapsed 0.01 seconds) done.
+Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
+Suspending console(s) (use no_console_suspend to debug)
+pci 0000:00:02.0: PCI INT A disabled
+sd 0:0:0:0: [sda] Synchronizing SCSI cache
+sd 0:0:0:0: [sda] Stopping disk
+ACPI handle has no context!
+ACPI handle has no context!
+sdhci-pci 0000:02:06.2: PCI INT C disabled
+ACPI handle has no context!
+ACPI handle has no context!
+iwlagn 0000:10:00.0: PCI INT A disabled
+ata2: port disabled. ignoring.
+ata_piix 0000:00:1f.1: PCI INT A disabled
+ehci_hcd 0000:00:1d.7: PCI INT A disabled
+uhci_hcd 0000:00:1d.2: PCI INT C disabled
+uhci_hcd 0000:00:1d.1: PCI INT B disabled
+uhci_hcd 0000:00:1d.0: PCI INT A disabled
+HDA Intel 0000:00:1b.0: PCI INT A disabled
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D3
+ehci_hcd 0000:00:1a.7: PCI INT C disabled
+uhci_hcd 0000:00:1a.1: PCI INT B disabled
+uhci_hcd 0000:00:1a.0: PCI INT A disabled
+e1000e 0000:00:19.0: PME# enabled
+e1000e 0000:00:19.0: wake-up capability enabled by ACPI
+e1000e 0000:00:19.0: PME# enabled
+e1000e 0000:00:19.0: wake-up capability enabled by ACPI
+e1000e 0000:00:19.0: PCI INT A disabled
+ACPI handle has no context!
+ACPI: Preparing to enter system sleep state S3
+Disabling non-boot CPUs ...
+CPU 1 is now offline
+SMP alternatives: switching to UP code
+CPU0 attaching NULL sched-domain.
+CPU1 attaching NULL sched-domain.
+CPU0 attaching NULL sched-domain.
+CPU1 is down
+ricoh-mmc: Suspending.
+ricoh-mmc: Controller is now re-enabled.
+Extended CMOS year: 2000
+x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
+Back to C!
+Extended CMOS year: 2000
+ricoh-mmc: Resuming.
+ricoh-mmc: Controller is now disabled.
+Enabling non-boot CPUs ...
+SMP alternatives: switching to SMP code
+Booting processor 1 APIC 0x1 ip 0x6000
+Initializing CPU#1
+Calibrating delay using timer specific routine.. 2659.98 BogoMIPS (lpj=5319972)
+CPU: L1 I cache: 32K, L1 D cache: 32K
+CPU: L2 cache: 2048K
+CPU: Physical Processor ID: 0
+CPU: Processor Core ID: 1
+x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
+CPU1: Intel(R) Core(TM)2 Duo CPU     U7700  @ 1.33GHz stepping 0d
+CPU0 attaching NULL sched-domain.
+Switched to high resolution mode on CPU 1
+CPU0 attaching sched-domain:
+ domain 0: span 0-1 level MC
+  groups: 0 1
+  domain 1: span 0-1 level CPU
+   groups: 0-1
+CPU1 attaching sched-domain:
+ domain 0: span 0-1 level MC
+  groups: 1 0
+  domain 1: span 0-1 level CPU
+   groups: 0-1
+CPU1 is up
+ACPI: Waking up from system sleep state S3
+APIC error on CPU1: 00(40)
+ACPI: EC: non-query interrupt received, switching to interrupt mode
+pci 0000:00:02.0: restoring config space at offset 0x8 (was 0x1, writing 0x2001)
+pci 0000:00:02.1: restoring config space at offset 0x4 (was 0x4, writing 0xe0500004)
+pci 0000:00:02.1: restoring config space at offset 0x1 (was 0x900000, writing 0x900007)
+pci 0000:00:03.0: restoring config space at offset 0xf (was 0x100, writing 0x1ff)
+pci 0000:00:03.0: restoring config space at offset 0x4 (was 0xfed12004, writing 0xe0600004)
+pci 0000:00:03.0: restoring config space at offset 0x1 (was 0x100006, writing 0x180006)
+pci 0000:00:03.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+pci 0000:00:03.2: restoring config space at offset 0x8 (was 0x1, writing 0x2031)
+pci 0000:00:03.2: restoring config space at offset 0x7 (was 0x1, writing 0x2021)
+pci 0000:00:03.2: restoring config space at offset 0x6 (was 0x1, writing 0x2019)
+pci 0000:00:03.2: restoring config space at offset 0x5 (was 0x1, writing 0x2011)
+pci 0000:00:03.2: restoring config space at offset 0x4 (was 0x1, writing 0x2009)
+pci 0000:00:03.2: restoring config space at offset 0x1 (was 0xb00000, writing 0xb00001)
+serial 0000:00:03.3: restoring config space at offset 0xf (was 0x200, writing 0x20a)
+serial 0000:00:03.3: restoring config space at offset 0x5 (was 0x0, writing 0xe0601000)
+serial 0000:00:03.3: restoring config space at offset 0x4 (was 0x1, writing 0x2041)
+serial 0000:00:03.3: restoring config space at offset 0x1 (was 0xb00000, writing 0xb00007)
+e1000e 0000:00:19.0: restoring config space at offset 0xf (was 0x100, writing 0x10b)
+e1000e 0000:00:19.0: restoring config space at offset 0x6 (was 0x1, writing 0x2061)
+e1000e 0000:00:19.0: restoring config space at offset 0x5 (was 0x0, writing 0xe0640000)
+e1000e 0000:00:19.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100007)
+e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
+e1000e 0000:00:19.0: setting latency timer to 64
+e1000e 0000:00:19.0: wake-up capability disabled by ACPI
+e1000e 0000:00:19.0: PME# disabled
+e1000e 0000:00:19.0: wake-up capability disabled by ACPI
+e1000e 0000:00:19.0: PME# disabled
+e1000e 0000:00:19.0: irq 509 for MSI/MSI-X
+uhci_hcd 0000:00:1a.0: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+uhci_hcd 0000:00:1a.0: setting latency timer to 64
+uhci_hcd 0000:00:1a.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+uhci_hcd 0000:00:1a.0: restoring config space at offset 0x8 (was 0x1, writing 0x2081)
+usb usb2: root hub lost power or was reset
+uhci_hcd 0000:00:1a.1: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
+uhci_hcd 0000:00:1a.1: setting latency timer to 64
+uhci_hcd 0000:00:1a.1: restoring config space at offset 0xf (was 0x200, writing 0x20a)
+uhci_hcd 0000:00:1a.1: restoring config space at offset 0x8 (was 0x1, writing 0x20a1)
+usb usb4: root hub lost power or was reset
+ehci_hcd 0000:00:1a.7: enabling device (0000 -> 0002)
+ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18
+ehci_hcd 0000:00:1a.7: setting latency timer to 64
+ehci_hcd 0000:00:1a.7: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+ehci_hcd 0000:00:1a.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0641000)
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
+HDA Intel 0000:00:1b.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+HDA Intel 0000:00:1b.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
+HDA Intel 0000:00:1b.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100002)
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
+HDA Intel 0000:00:1b.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
+HDA Intel 0000:00:1b.0: setting latency timer to 64
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0xf (was 0x100, writing 0x4010a)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x8 (was 0x0, writing 0xfff0)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x7 (was 0x0, writing 0xf0)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x6 (was 0x0, writing 0x80800)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x3 (was 0x810000, writing 0x810010)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100407)
+pcieport-driver 0000:00:1c.0: setting latency timer to 64
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0xf (was 0x200, writing 0x4020a)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x8 (was 0x0, writing 0xe000e000)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x7 (was 0x0, writing 0xf0)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x3 (was 0x810000, writing 0x810010)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x1 (was 0x100000, writing 0x100407)
+pcieport-driver 0000:00:1c.1: setting latency timer to 64
+uhci_hcd 0000:00:1d.0: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
+uhci_hcd 0000:00:1d.0: setting latency timer to 64
+uhci_hcd 0000:00:1d.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+uhci_hcd 0000:00:1d.0: restoring config space at offset 0x8 (was 0x1, writing 0x20c1)
+usb usb5: root hub lost power or was reset
+uhci_hcd 0000:00:1d.1: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 22 (level, low) -> IRQ 22
+uhci_hcd 0000:00:1d.1: setting latency timer to 64
+uhci_hcd 0000:00:1d.1: restoring config space at offset 0xf (was 0x200, writing 0x20b)
+uhci_hcd 0000:00:1d.1: restoring config space at offset 0x8 (was 0x1, writing 0x20e1)
+usb usb6: root hub lost power or was reset
+uhci_hcd 0000:00:1d.2: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
+uhci_hcd 0000:00:1d.2: setting latency timer to 64
+uhci_hcd 0000:00:1d.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+uhci_hcd 0000:00:1d.2: restoring config space at offset 0x8 (was 0x1, writing 0x2101)
+usb usb7: root hub lost power or was reset
+ehci_hcd 0000:00:1d.7: enabling device (0000 -> 0002)
+ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20
+ehci_hcd 0000:00:1d.7: setting latency timer to 64
+ehci_hcd 0000:00:1d.7: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+ehci_hcd 0000:00:1d.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0648000)
+pci 0000:00:1e.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pci 0000:00:1e.0: restoring config space at offset 0x8 (was 0x0, writing 0xe030e010)
+pci 0000:00:1e.0: restoring config space at offset 0x7 (was 0x228000f0, writing 0x22803030)
+pci 0000:00:1e.0: restoring config space at offset 0x1 (was 0x100007, writing 0x100107)
+pci 0000:00:1e.0: setting latency timer to 64
+ata_piix 0000:00:1f.1: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+ata_piix 0000:00:1f.1: restoring config space at offset 0x8 (was 0xc01, writing 0x2121)
+ata_piix 0000:00:1f.1: restoring config space at offset 0x1 (was 0x2800005, writing 0x2880005)
+ata_piix 0000:00:1f.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+ata_piix 0000:00:1f.1: setting latency timer to 64
+ata2: port disabled. ignoring.
+ACPI Exception (exoparg2-0444): AE_AML_PACKAGE_LIMIT, Index (000000005) is beyond end of object [20080926]
+ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.C2C3] (Node ffff88007e01de80), AE_AML_PACKAGE_LIMIT
+ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.C003.C0F6.C3F3._STM] (Node ffff88007e043dc0), AE_AML_PACKAGE_LIMIT
+ata1: ACPI set timing mode failed (status=0x300b)
+iwlagn 0000:10:00.0: enabling device (0000 -> 0002)
+iwlagn 0000:10:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
+iwlagn 0000:10:00.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+iwlagn 0000:10:00.0: restoring config space at offset 0x4 (was 0x4, writing 0xe0000004)
+iwlagn 0000:10:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
+iwlagn 0000:10:00.0: restoring config space at offset 0x1 (was 0x100002, writing 0x100006)
+iwlagn 0000:10:00.0: irq 508 for MSI/MSI-X
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xf (was 0x3000100, writing 0x580010b)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xe (was 0x0, writing 0x34fc)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xd (was 0x0, writing 0x3400)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xc (was 0x0, writing 0x30fc)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xb (was 0x0, writing 0x3000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xa (was 0x0, writing 0x83fff000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x9 (was 0x0, writing 0x80000000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x8 (was 0x0, writing 0x847ff000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x7 (was 0x0, writing 0x84400000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x6 (was 0x0, writing 0xb0060302)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x4 (was 0x0, writing 0xe0100000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x3 (was 0x820000, writing 0x82a800)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100007)
+ohci1394 0000:02:06.1: restoring config space at offset 0xf (was 0x4020200, writing 0x4020205)
+ohci1394 0000:02:06.1: restoring config space at offset 0x4 (was 0x0, writing 0xe0101000)
+ohci1394 0000:02:06.1: restoring config space at offset 0x3 (was 0x800000, writing 0x804010)
+ohci1394 0000:02:06.1: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006)
+ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19]  MMIO=[e0101000-e01017ff]  Max Packet=[2048]  IR/IT contexts=[4/4]
+sdhci-pci 0000:02:06.2: restoring config space at offset 0xf (was 0x300, writing 0x30a)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x4 (was 0x0, writing 0xe0102000)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x3 (was 0x800000, writing 0x804010)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006)
+sdhci-pci 0000:02:06.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20
+Registered led device: iwl-phy0:radio
+Registered led device: iwl-phy0:assoc
+Registered led device: iwl-phy0:RX
+Registered led device: iwl-phy0:TX
+sd 0:0:0:0: [sda] Starting disk
+ata1.01: ACPI cmd ef/03:0c:00:00:00:b0 filtered out
+ata1.01: ACPI cmd ef/03:40:00:00:00:b0 filtered out
+ata1.00: ACPI cmd ef/03:01:00:00:00:a0 filtered out
+ata1.00: ACPI cmd ef/03:45:00:00:00:a0 filtered out
+ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
+ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 filtered out
+ata1.00: ACPI cmd c6/00:10:00:00:00:a0 succeeded
+ata1.00: configured for UDMA/100
+ata1.01: configured for MWDMA2
+ata1.00: configured for UDMA/100
+ata1.01: configured for MWDMA2
+ata1: EH complete
+sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
+sd 0:0:0:0: [sda] Write Protect is off
+sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
+sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
+sd 0:0:0:0: [sda] Write Protect is off
+sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
+sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+usb 5-2: reset full speed USB device using uhci_hcd and address 2
+usb 2-1: reset full speed USB device using uhci_hcd and address 2
+pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+pci 0000:00:02.0: setting latency timer to 64
+Restarting tasks ... <7>wlan0: deauthenticated
+done.
+wlan0: direct probe to AP 00:14:c1:38:e5:15 try 1
+wlan0 direct probe responded
+wlan0: authenticate with AP 00:14:c1:38:e5:15
+wlan0: authenticated
+wlan0: associate with AP 00:14:c1:38:e5:15
+wlan0: RX ReassocResp from 00:14:c1:38:e5:15 (capab=0x411 status=0 aid=1)
+wlan0: associated

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Tue, 2 Dec 2008, Frans Pop wrote:
> 
> You're in luck. I still had /proc/io* contents from .28-rc3 lying around 
> from working on some other issue.
> 
> Here's the relevant diff for iomem; there's no diff for ioports.
> 
> --- iomem_2.6.28-rc3    2008-11-03 10:59:37.000000000 +0100
> +++ iomem_2.6.28-rc6_linus      2008-12-02 05:20:31.000000000 +0100
> @@ -10,10 +10,9 @@
>  7e7b0000-7e7c53ff : reserved
>  7e7c5400-7e7e7fb7 : ACPI Non-volatile Storage
>  7e7e7fb8-7effffff : reserved
> -80000000-83ffffff : PCI Bus 0000:02
> -  80000000-83ffffff : PCI CardBus 0000:03
> -84000000-87ffffff : PCI CardBus 0000:03
> -88000000-88000fff : Intel Flush Page
> +80000000-83ffffff : PCI CardBus 0000:03
> +84000000-84000fff : Intel Flush Page
> +84400000-847fffff : PCI CardBus 0000:03
>  d0000000-dfffffff : 0000:00:02.0
>    d0000000-d076ffff : vesafb
>  e0000000-e00fffff : PCI Bus 0000:10

I'm not seeing how this could matter. In the latter one, we apparently 
don't set up any PCI bus memory window, but I bet it's a transparent 
bridge, and it shouldn't matter. IOW, your dmesg probably has a line like 
this somewhere:

	pci 0000:00:1e.0: transparent bridge

and whether there is an explicit bus window or not is simply immaterial.

That said, if you can show the differences in dmesg from the two cases, it 
would probably be interesting to see why it happens that way.  Why did we 
bother setting up that PCI bus window in -rc3 at all? Was it there from 
the beginning?

> I've tried a few quick suspend/resume cycles and no failures so far, but 
> that's not really conclusive yet.
> 
> Besides snd_hda_intel I've also been unloading e1000e before suspend 
> because I thought it contributed to resume failures. I'm now keeping that 
> loaded as well. Will report results.

There were some HDA fixes recently, although I don't think they should 
matter for suspend/resume (well, at least a couple of them should fix the 
case of sound being _silent_ on resume, but shouldn't have caused any 
other issues).

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Tue, 2 Dec 2008, Frans Pop wrote:
> 
> Your debug patch gives me on boot (hp 2510p; x86_64; current git head):
> 
> ! pci 0000:02:06.0: BAR 9 0-3ffffff wrong alignment flags 21200 4000000 (0)
> ! pci 0000:02:06.0: BAR 9 bad alignment 0: [0x000000-0x3ffffff]

Hmm. flags 21200 means that IORESOURCE_SIZEALIGN is set, and 'align' is 
_correct_ (0x4000000==size), while 'expected_align' is total crap (0).

So at least on your machine, using the expected_align value (which is 
effectively what Rafael's patch does) would definitely be the wrong thing.

Of course, it might then happen to work (because the thing doesn't 
actually need that big alignment at all).

Also:

> From lspci -vv:
> 02:06.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba)
>         Subsystem: Hewlett-Packard Company Device 30c9
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 168
>         Interrupt: pin A routed to IRQ 18
>         Region 0: Memory at e0100000 (32-bit, non-prefetchable) [size=4K]
>         Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
>         Memory window 0: 84400000-847ff000 (prefetchable)
>         Memory window 1: 80000000-83fff000
>         I/O window 0: 00003000-000030ff
>         I/O window 1: 00003400-000034ff

the above all looks fine, and it apparently works for you.

I'd like to see what Rafael's machine does.

Of course, the thing to keep in mind here is that resource alignment is 
one of those things that changes how PCI resources get laid out, and two 
different layouts may well _both_ be correct - but then one of them may 
not work, because there is some hidden SMI resource that we don't know 
about, or some other stupid BIOS issue where the BIOS is unhappy about how 
we laid things out.

We've had many of those before. And they can easily result in "innocent" 
changes (including real fixes) just then exposing problems that were 
hidden before due to just a subtly different layout.

That's why I'd like to see what the layout differences are for Rafael with 
and without his patch (and also both before and after hibernate/resume). 
Maybe both layouts are "correct", but the non-working one can give us a 
clue about what may be triggering the problem.

			Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

> Oh, btw, one more thing: since it apparently sometimes _does_ resume
> from hibernation without all this, I'd also like to see the actual
> differences in /proc/ioports and /proc/iomem that happen as a result of
> the different alignment.

You're in luck. I still had /proc/io* contents from .28-rc3 lying around 
from working on some other issue.

Here's the relevant diff for iomem; there's no diff for ioports.

--- iomem_2.6.28-rc3    2008-11-03 10:59:37.000000000 +0100
+++ iomem_2.6.28-rc6_linus      2008-12-02 05:20:31.000000000 +0100
@@ -10,10 +10,9 @@
 7e7b0000-7e7c53ff : reserved
 7e7c5400-7e7e7fb7 : ACPI Non-volatile Storage
 7e7e7fb8-7effffff : reserved
-80000000-83ffffff : PCI Bus 0000:02
-  80000000-83ffffff : PCI CardBus 0000:03
-84000000-87ffffff : PCI CardBus 0000:03
-88000000-88000fff : Intel Flush Page
+80000000-83ffffff : PCI CardBus 0000:03
+84000000-84000fff : Intel Flush Page
+84400000-847fffff : PCI CardBus 0000:03
 d0000000-dfffffff : 0000:00:02.0
   d0000000-d076ffff : vesafb
 e0000000-e00fffff : PCI Bus 0000:10

I've tried a few quick suspend/resume cycles and no failures so far, but 
that's not really conclusive yet.

Besides snd_hda_intel I've also been unloading e1000e before suspend 
because I thought it contributed to resume failures. I'm now keeping that 
loaded as well. Will report results.

Cheers,
FJP

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

Hi Linus,

> Your patch doesn't fix anything, it just hides the bug.

> It would be good to hear what resource this is, and where it got set. So 
> instead of that broken patch that just hides the problem, please try to 
> debug it with something like

Your debug patch gives me on boot (hp 2510p; x86_64; current git head):

  system 00:00: iomem range 0x0-0x9ffff could not be reserved
  system 00:00: iomem range 0xe0000-0xfffff could not be reserved
  system 00:00: iomem range 0x100000-0x7e7fffff could not be reserved
  system 00:0a: ioport range 0x500-0x55f has been reserved
  system 00:0a: ioport range 0x800-0x80f has been reserved
  system 00:0a: iomem range 0xffb00000-0xffbfffff has been reserved
  system 00:0a: iomem range 0xfff00000-0xffffffff has been reserved
  system 00:0c: ioport range 0x4d0-0x4d1 has been reserved
  system 00:0c: ioport range 0x2f8-0x2ff has been reserved
  system 00:0c: ioport range 0x3f8-0x3ff has been reserved
  system 00:0c: ioport range 0x1000-0x107f has been reserved
  system 00:0c: ioport range 0x1100-0x113f has been reserved
  system 00:0c: ioport range 0x1200-0x121f has been reserved
  system 00:0c: iomem range 0xf8000000-0xfbffffff has been reserved
  system 00:0c: iomem range 0xfec00000-0xfec000ff has been reserved
  system 00:0c: iomem range 0xfed20000-0xfed3ffff has been reserved
  system 00:0c: iomem range 0xfed45000-0xfed8ffff has been reserved
  system 00:0c: iomem range 0xfed90000-0xfed99fff has been reserved
  system 00:0d: iomem range 0xcee00-0xcffff has been reserved
  system 00:0d: iomem range 0xd2000-0xd3fff has been reserved
  system 00:0d: iomem range 0xfeda0000-0xfedbffff has been reserved
  system 00:0d: iomem range 0xfee00000-0xfee00fff has been reserved
! pci 0000:02:06.0: BAR 9 0-3ffffff wrong alignment flags 21200 4000000 (0)
! pci 0000:02:06.0: BAR 9 bad alignment 0: [0x000000-0x3ffffff]
  pci 0000:00:1c.0: PCI bridge, secondary bus 0000:08
  pci 0000:00:1c.0:   IO window: disabled
  pci 0000:00:1c.0:   MEM window: disabled
  pci 0000:00:1c.0:   PREFETCH window: disabled
  pci 0000:00:1c.1: PCI bridge, secondary bus 0000:10
  pci 0000:00:1c.1:   IO window: disabled
  pci 0000:00:1c.1:   MEM window: 0xe0000000-0xe00fffff
  pci 0000:00:1c.1:   PREFETCH window: disabled
  pci 0000:02:06.0: CardBus bridge, secondary bus 0000:03
  pci 0000:02:06.0:   IO window: 0x003000-0x0030ff
  pci 0000:02:06.0:   IO window: 0x003400-0x0034ff
  pci 0000:02:06.0:   MEM window: 0x80000000-0x83ffffff
  pci 0000:00:1e.0: PCI bridge, secondary bus 0000:02
  pci 0000:00:1e.0:   IO window: 0x3000-0x3fff
  pci 0000:00:1e.0:   MEM window: 0xe0100000-0xe03fffff
  pci 0000:00:1e.0:   PREFETCH window: disabled
  pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
  pci 0000:00:1c.0: setting latency timer to 64
  pci 0000:00:1c.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
  pci 0000:00:1c.1: setting latency timer to 64
  pci 0000:00:1e.0: setting latency timer to 64
  pci 0000:02:06.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18

>From lspci -vv:
02:06.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba)
        Subsystem: Hewlett-Packard Company Device 30c9
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 168
        Interrupt: pin A routed to IRQ 18
        Region 0: Memory at e0100000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
        Memory window 0: 84400000-847ff000 (prefetchable)
        Memory window 1: 80000000-83fff000
        I/O window 0: 00003000-000030ff
        I/O window 1: 00003400-000034ff
        BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
        16-bit legacy interface ports at 0001
        Kernel driver in use: yenta_cardbus
        Kernel modules: yenta_socket

02:06.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04) (prog-if 10 [OHCI])
        Subsystem: Hewlett-Packard Company Device 30c9
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64 (500ns min, 1000ns max), Cache Line Size: 64 bytes
        Interrupt: pin B routed to IRQ 19
        Region 0: Memory at e0101000 (32-bit, non-prefetchable) [size=2K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME+
        Kernel driver in use: ohci1394
        Kernel modules: ohci1394

02:06.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21)
        Subsystem: Hewlett-Packard Company Device 30c9
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64, Cache Line Size: 64 bytes
        Interrupt: pin C routed to IRQ 20
        Region 0: Memory at e0102000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-
        Kernel driver in use: sdhci-pci
        Kernel modules: sdhci-pci

02:06.3 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev ff) (prog-if ff)
        !!! Unknown header type 7f
        Kernel driver in use: ricoh-mmc
        Kernel modules: ricoh_mmc

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Mon, 1 Dec 2008, Linus Torvalds wrote:
> 
> or something like that. And then we just need to figure out which setup 
> routine sets the wrong alignment flag,.

Oh, btw, one more thing: since it apparently sometimes _does_ resume 
from hibernation without all this, I'd also like to see the actual 
differences in /proc/ioports and /proc/iomem that happen as a result of 
the different alignment. 

I also really suspect we should add a whole "alignment" field to "struct 
resource", instead of the size-vs-start flags. The fact is, some PCI 
devices have alignment that is neither tied to size or anything else: I 
think some PCI bus resources are really always 4kB-aligned, for example 
(and aligning them by size will give a bigger alignment than actually 
required).

			Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Tue, 2 Dec 2008, Rafael J. Wysocki wrote:
>  			r_size = resource_size(r);
>  			/* For bridges size != alignment */
> -			align = resource_alignment(r);
> +			align = (i < PCI_BRIDGE_RESOURCES) ? r_size : r->start;

Hmm. This means that something set the alignment flags incorrectly. The 
resource _should_ have IORESOURCE_SIZEALIGN set for a resource with size 
alignment, and IORESOURCE_STARTALIGN for one that has start alignment.

Your patch doesn't fix anything, it just hides the bug.

It would be good to hear what resource this is, and where it got set. So 
instead of that broken patch that just hides the problem, please try to 
debug it with something like

	resource_size_t expected_align;

	expected_align = (i < PCI_BRIDGE_RESOURCES) ? r_size : r->start;
	align = resource_alignment(r);
	if (align != expected_align) {
		dev_warn(&dev->dev,
			"BAR %d %llx-%llx wrong alignment flags %lx %llx (%llx)\n",
			i,
			(unsigned long long) r->start,
			(unsigned long long) r->end,
			r->flags,
			(unsigned long long) align,
			(unsigned long long) expected_align);
		/* Hacky and wrong, but trying to keep things 
		align = expected_align;
	}

or something like that. And then we just need to figure out which setup 
routine sets the wrong alignment flag,.

		Linus

Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

Hi Linus,

For some time I've been having problems with resume from hibernation and
suspend on Toshiba Portege R500 I'm currently testing.  Initially I thought
that was a regression from 2.6.27, because some 2.6.27-based kernels appeared
to work correctly on this box, but today I realized that in fact 2.6.27-rc6
failed too and then I confirmed that the problem was also present in 2.6.27
and in all of the -stable 2.6.27.y kernels.  Still, I was unable to reproduce
the problem with the 2.6.27-rc3 kernel and that made me carry out bisection
between 2.6.27-rc3 and 2.6.27-rc6 that turned up the following commit of yours:

commit 5f17cfce5776c566d64430f543a289e5cfa4538b
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Sep 4 01:33:59 2008 -0700

    PCI: fix pbus_size_mem() resource alignment for CardBus controllers

Following this, I applied the appended patch on top of the current mainline
and it appears to have fixed my hibernation/resume problems on this box
(at least, with the patch applied the box have survived ~20 hibernation/resume
and suspend/resume cycles in a row, which was not achievable with the mainline
without the patch).

The symptoms of the breakage are that sometimes the box hangs solid during
resume, sometimes it hangs but can be rebooted by pressing Alt-SysRq-b, and
sometimes it just powers off while resuming.  Still, it resumes correctly in
about 75% of cases and that made the issue very hard to debug.  [Interestingly
enough, it was not reproducible with snd_hda_intel unloaded, which made me
think it was related to the driver, but evidently it wasn't.]  Also, I'm sure
hibernation is affected, but recently there have been some other sources of
breakage of resume from suspend to RAM, so I'm not so sure to what extent it
is affected too.

Please let me know if you need debug information from the affected box.

Thanks,
Rafael


Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/pci/setup-bus.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6/drivers/pci/setup-bus.c
===================================================================
--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -352,7 +352,7 @@ static int pbus_size_mem(struct pci_bus 
 				continue;
 			r_size = resource_size(r);
 			/* For bridges size != alignment */
-			align = resource_alignment(r);
+			align = (i < PCI_BRIDGE_RESOURCES) ? r_size : r->start;
 			order = __ffs(align) - 20;
 			if (order > 11) {
 				dev_warn(&dev->dev, "BAR %d bad alignment %llx: "