Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re:2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi,
On Friday, 25 of March 2005 01:49, you wrote:
]--snip--[
> > > I actually added such calls in uhci, ehci and yenta. It's ok for S3 (and
> > > definitely required for S3). Unclear if it's ok for S4, so please try
> > > revert the patch.
> >
> > 2.6.11-rc1-mm1 with the patch reverted works fine. :-)
> So just remove the pci_enable/disable_device call in the driver makes
> the system work?
I'm a bit confused. :-) I'm not sure if the patch that I have reverted is
related
to pci_enable/disable_device. It's this one:
diff -Naru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
--- a/drivers/acpi/pci_link.c 2005-03-24 04:57:27 -08:00
+++ b/drivers/acpi/pci_link.c 2005-03-24 04:57:27 -08:00
@@ -72,10 +72,12 @@
u8 active; /* Current IRQ */
u8 edge_level; /* All IRQs */
u8 active_high_low;/* All IRQs */
- u8 initialized;
u8 resource_type;
u8 possible_count;
u8 possible[ACPI_PCI_LINK_MAX_POSSIBLE];
+ u8 initialized:1;
+ u8 suspend_resume:1;
+ u8 reserved:6;
};
struct acpi_pci_link {
@@ -530,6 +532,10 @@
ACPI_FUNCTION_TRACE("acpi_pci_link_allocate");
+ if (link->irq.suspend_resume) {
+ acpi_pci_link_set(link, link->irq.active);
+ link->irq.suspend_resume = 0;
+ }
if (link->irq.initialized)
return_VALUE(0);
@@ -713,38 +719,24 @@
return_VALUE(result);
}
-
-static int
-acpi_pci_link_resume (
- struct acpi_pci_link*link)
-{
- ACPI_FUNCTION_TRACE("acpi_pci_link_resume");
-
- if (link->irq.active && link->irq.initialized)
- return_VALUE(acpi_pci_link_set(link, link->irq.active));
- else
- return_VALUE(0);
-}
-
-
static int
-irqrouter_resume(
- struct sys_device *dev)
+irqrouter_suspend(
+ struct sys_device *dev,
+ u32 state)
{
struct list_head*node = NULL;
struct acpi_pci_link*link = NULL;
- ACPI_FUNCTION_TRACE("irqrouter_resume");
+ ACPI_FUNCTION_TRACE("irqrouter_suspend");
list_for_each(node, _link.entries) {
-
link = list_entry(node, struct acpi_pci_link, node);
if (!link) {
ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Invalid link
context\n"));
continue;
}
-
- acpi_pci_link_resume(link);
+ if (link->irq.active && link->irq.initialized)
+ link->irq.suspend_resume = 1;
}
return_VALUE(0);
}
@@ -856,7 +848,7 @@
static struct sysdev_class irqrouter_sysdev_class = {
set_kset_name("irqrouter"),
-.resume = irqrouter_resume,
+.suspend = irqrouter_suspend,
};
Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re:2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi,
On Friday, 25 of March 2005 01:49, you wrote:
]--snip--[
I actually added such calls in uhci, ehci and yenta. It's ok for S3 (and
definitely required for S3). Unclear if it's ok for S4, so please try
revert the patch.
2.6.11-rc1-mm1 with the patch reverted works fine. :-)
So just remove the pci_enable/disable_device call in the driver makes
the system work?
I'm a bit confused. :-) I'm not sure if the patch that I have reverted is
related
to pci_enable/disable_device. It's this one:
diff -Naru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
--- a/drivers/acpi/pci_link.c 2005-03-24 04:57:27 -08:00
+++ b/drivers/acpi/pci_link.c 2005-03-24 04:57:27 -08:00
@@ -72,10 +72,12 @@
u8 active; /* Current IRQ */
u8 edge_level; /* All IRQs */
u8 active_high_low;/* All IRQs */
- u8 initialized;
u8 resource_type;
u8 possible_count;
u8 possible[ACPI_PCI_LINK_MAX_POSSIBLE];
+ u8 initialized:1;
+ u8 suspend_resume:1;
+ u8 reserved:6;
};
struct acpi_pci_link {
@@ -530,6 +532,10 @@
ACPI_FUNCTION_TRACE(acpi_pci_link_allocate);
+ if (link-irq.suspend_resume) {
+ acpi_pci_link_set(link, link-irq.active);
+ link-irq.suspend_resume = 0;
+ }
if (link-irq.initialized)
return_VALUE(0);
@@ -713,38 +719,24 @@
return_VALUE(result);
}
-
-static int
-acpi_pci_link_resume (
- struct acpi_pci_link*link)
-{
- ACPI_FUNCTION_TRACE(acpi_pci_link_resume);
-
- if (link-irq.active link-irq.initialized)
- return_VALUE(acpi_pci_link_set(link, link-irq.active));
- else
- return_VALUE(0);
-}
-
-
static int
-irqrouter_resume(
- struct sys_device *dev)
+irqrouter_suspend(
+ struct sys_device *dev,
+ u32 state)
{
struct list_head*node = NULL;
struct acpi_pci_link*link = NULL;
- ACPI_FUNCTION_TRACE(irqrouter_resume);
+ ACPI_FUNCTION_TRACE(irqrouter_suspend);
list_for_each(node, acpi_link.entries) {
-
link = list_entry(node, struct acpi_pci_link, node);
if (!link) {
ACPI_DEBUG_PRINT((ACPI_DB_ERROR, Invalid link
context\n));
continue;
}
-
- acpi_pci_link_resume(link);
+ if (link-irq.active link-irq.initialized)
+ link-irq.suspend_resume = 1;
}
return_VALUE(0);
}
@@ -856,7 +848,7 @@
static struct sysdev_class irqrouter_sysdev_class = {
set_kset_name(irqrouter),
-.resume = irqrouter_resume,
+.suspend = irqrouter_suspend,
};
Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll Alice's Adventures in Wonderland
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re:2.6.12-rc1-mm1: Kernel BUG at pci:389)
On Thu, 2005-03-24 at 21:42, Rafael J. Wysocki wrote: > Hi, > > On Thursday, 24 of March 2005 02:27, Li Shaohua wrote: > > On Thu, 2005-03-24 at 09:03, Len Brown wrote: > > > On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote: > > > > Hi, > > > > > > > > On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote: > > > > > Hi! > > > > > > > > > > > > > > Will this do it for the moment? > > > > > > > > > > > > > > > > Its certainly better. > > > > > > > > > > > > > > With the Len's patch applied I have to unload the modules: > > > > > > > > > > > > > > ohci_hcd > > > > > > > ehci_hcd > > > > > > > yenta_socket > > > > > > > > > > > > > > before suspend as each of them hangs the box solid during > > > either > > > > > > > suspend or resume. Moreover, when I tried to load the > > > ehci_hcd > > > > > > > module back after resume, it hanged the box solid too. > > > > > > Is this failure with suspend to RAM or to disk? > > > > > > How about if you try this patch? > > > > > > http://linux-acpi.bkbits.net:8080/to-akpm/[EMAIL PROTECTED] > > > > > > patch -Rp1 from 2.6.12-rc1-mm1 and see if it stops being broken > > > or patch -Np1 to 2.6.12-rc and see if it starts being broken. > > > > > > This one removes an earlier attempt at resuming PCI links -- now > > > putting the onus on the drivers to be properly written > > > to release and acquire their interrupt for a successful > > > suspend/resume. > > > > > > > > > In theory, this is taken care of something like this: > > > driver.resume > > > pci_enable_device > > > pci_enable_device_bars > > > pcibios_enable_device > > > pcibios_enable_irq > > > acpi_pci_irq_enable > > > > > > but if the patch above makes a difference, then theory != practice:-) > > It looks like that. ;-) > > > > I'd believe that ohci_hcd and ehci_hcd are fragile since glancing > > > at their lengthy .resume routines it isn't immediately obvious > > > that they do this. But yenta_dev_resume has a pci_enable_device(), > > > so that failure may be less straightforward. > > > > > > cheers, > > > -Len > > > > > > ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled > > > boot, that would help -- for it will show if we're even using pci > > > interrupt links (and programming them) for these devices on this box. > > Yes, we changed the behavior of device suspend/resume. Every PCI device > > should call 'pci_disable_device' at suspend and call 'pci_enable_device' > > at resume. It fixes a bug and more important thing is it's safer (Eg. it > > disable interrupts, bus master and etc). > > I actually added such calls in uhci, ehci and yenta. It's ok for S3 (and > > definitely required for S3). Unclear if it's ok for S4, so please try > > revert the patch. > > 2.6.11-rc1-mm1 with the patch reverted works fine. :-) So just remove the pci_enable/disable_device call in the driver makes the system work? Strange, I tried them on two laptops (one HP nx5000, and one Toshiba M2N), both works (no hang, and USB mouse works after S3/S4. I didn't try yenta, since I have no pc card) for S3/S4. Is it possible it's another bug or just because of different BIOS? Thanks, Shaohua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi, On Thursday, 24 of March 2005 02:03, Len Brown wrote: > On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote: ]-- snip --[ > I'd believe that ohci_hcd and ehci_hcd are fragile since glancing > at their lengthy .resume routines it isn't immediately obvious > that they do this. But yenta_dev_resume has a pci_enable_device(), > so that failure may be less straightforward. > > cheers, > -Len > > ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled > boot, that would help -- for it will show if we're even using pci > interrupt links (and programming them) for these devices on this box. The dmesg output is at: http://www.sisk.pl/kernel/050325/2.6.11-rc1-dmesg.log Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re:2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi, On Thursday, 24 of March 2005 02:27, Li Shaohua wrote: > On Thu, 2005-03-24 at 09:03, Len Brown wrote: > > On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote: > > > Hi, > > > > > > On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote: > > > > Hi! > > > > > > > > > > > > Will this do it for the moment? > > > > > > > > > > > > > > Its certainly better. > > > > > > > > > > > > With the Len's patch applied I have to unload the modules: > > > > > > > > > > > > ohci_hcd > > > > > > ehci_hcd > > > > > > yenta_socket > > > > > > > > > > > > before suspend as each of them hangs the box solid during > > either > > > > > > suspend or resume. Moreover, when I tried to load the > > ehci_hcd > > > > > > module back after resume, it hanged the box solid too. > > > > Is this failure with suspend to RAM or to disk? > > > > How about if you try this patch? > > > > http://linux-acpi.bkbits.net:8080/to-akpm/[EMAIL PROTECTED] > > > > patch -Rp1 from 2.6.12-rc1-mm1 and see if it stops being broken > > or patch -Np1 to 2.6.12-rc and see if it starts being broken. > > > > This one removes an earlier attempt at resuming PCI links -- now > > putting the onus on the drivers to be properly written > > to release and acquire their interrupt for a successful > > suspend/resume. > > > > > > In theory, this is taken care of something like this: > > driver.resume > > pci_enable_device > > pci_enable_device_bars > > pcibios_enable_device > > pcibios_enable_irq > > acpi_pci_irq_enable > > > > but if the patch above makes a difference, then theory != practice:-) It looks like that. ;-) > > I'd believe that ohci_hcd and ehci_hcd are fragile since glancing > > at their lengthy .resume routines it isn't immediately obvious > > that they do this. But yenta_dev_resume has a pci_enable_device(), > > so that failure may be less straightforward. > > > > cheers, > > -Len > > > > ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled > > boot, that would help -- for it will show if we're even using pci > > interrupt links (and programming them) for these devices on this box. > Yes, we changed the behavior of device suspend/resume. Every PCI device > should call 'pci_disable_device' at suspend and call 'pci_enable_device' > at resume. It fixes a bug and more important thing is it's safer (Eg. it > disable interrupts, bus master and etc). > I actually added such calls in uhci, ehci and yenta. It's ok for S3 (and > definitely required for S3). Unclear if it's ok for S4, so please try > revert the patch. 2.6.11-rc1-mm1 with the patch reverted works fine. :-) Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re:2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi, On Thursday, 24 of March 2005 02:27, Li Shaohua wrote: On Thu, 2005-03-24 at 09:03, Len Brown wrote: On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote: Hi, On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote: Hi! Will this do it for the moment? Its certainly better. With the Len's patch applied I have to unload the modules: ohci_hcd ehci_hcd yenta_socket before suspend as each of them hangs the box solid during either suspend or resume. Moreover, when I tried to load the ehci_hcd module back after resume, it hanged the box solid too. Is this failure with suspend to RAM or to disk? How about if you try this patch? http://linux-acpi.bkbits.net:8080/to-akpm/[EMAIL PROTECTED] patch -Rp1 from 2.6.12-rc1-mm1 and see if it stops being broken or patch -Np1 to 2.6.12-rc and see if it starts being broken. This one removes an earlier attempt at resuming PCI links -- now putting the onus on the drivers to be properly written to release and acquire their interrupt for a successful suspend/resume. In theory, this is taken care of something like this: driver.resume pci_enable_device pci_enable_device_bars pcibios_enable_device pcibios_enable_irq acpi_pci_irq_enable but if the patch above makes a difference, then theory != practice:-) It looks like that. ;-) I'd believe that ohci_hcd and ehci_hcd are fragile since glancing at their lengthy .resume routines it isn't immediately obvious that they do this. But yenta_dev_resume has a pci_enable_device(), so that failure may be less straightforward. cheers, -Len ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled boot, that would help -- for it will show if we're even using pci interrupt links (and programming them) for these devices on this box. Yes, we changed the behavior of device suspend/resume. Every PCI device should call 'pci_disable_device' at suspend and call 'pci_enable_device' at resume. It fixes a bug and more important thing is it's safer (Eg. it disable interrupts, bus master and etc). I actually added such calls in uhci, ehci and yenta. It's ok for S3 (and definitely required for S3). Unclear if it's ok for S4, so please try revert the patch. 2.6.11-rc1-mm1 with the patch reverted works fine. :-) Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi, On Thursday, 24 of March 2005 02:03, Len Brown wrote: On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote: ]-- snip --[ I'd believe that ohci_hcd and ehci_hcd are fragile since glancing at their lengthy .resume routines it isn't immediately obvious that they do this. But yenta_dev_resume has a pci_enable_device(), so that failure may be less straightforward. cheers, -Len ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled boot, that would help -- for it will show if we're even using pci interrupt links (and programming them) for these devices on this box. The dmesg output is at: http://www.sisk.pl/kernel/050325/2.6.11-rc1-dmesg.log Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re:2.6.12-rc1-mm1: Kernel BUG at pci:389)
On Thu, 2005-03-24 at 21:42, Rafael J. Wysocki wrote: Hi, On Thursday, 24 of March 2005 02:27, Li Shaohua wrote: On Thu, 2005-03-24 at 09:03, Len Brown wrote: On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote: Hi, On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote: Hi! Will this do it for the moment? Its certainly better. With the Len's patch applied I have to unload the modules: ohci_hcd ehci_hcd yenta_socket before suspend as each of them hangs the box solid during either suspend or resume. Moreover, when I tried to load the ehci_hcd module back after resume, it hanged the box solid too. Is this failure with suspend to RAM or to disk? How about if you try this patch? http://linux-acpi.bkbits.net:8080/to-akpm/[EMAIL PROTECTED] patch -Rp1 from 2.6.12-rc1-mm1 and see if it stops being broken or patch -Np1 to 2.6.12-rc and see if it starts being broken. This one removes an earlier attempt at resuming PCI links -- now putting the onus on the drivers to be properly written to release and acquire their interrupt for a successful suspend/resume. In theory, this is taken care of something like this: driver.resume pci_enable_device pci_enable_device_bars pcibios_enable_device pcibios_enable_irq acpi_pci_irq_enable but if the patch above makes a difference, then theory != practice:-) It looks like that. ;-) I'd believe that ohci_hcd and ehci_hcd are fragile since glancing at their lengthy .resume routines it isn't immediately obvious that they do this. But yenta_dev_resume has a pci_enable_device(), so that failure may be less straightforward. cheers, -Len ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled boot, that would help -- for it will show if we're even using pci interrupt links (and programming them) for these devices on this box. Yes, we changed the behavior of device suspend/resume. Every PCI device should call 'pci_disable_device' at suspend and call 'pci_enable_device' at resume. It fixes a bug and more important thing is it's safer (Eg. it disable interrupts, bus master and etc). I actually added such calls in uhci, ehci and yenta. It's ok for S3 (and definitely required for S3). Unclear if it's ok for S4, so please try revert the patch. 2.6.11-rc1-mm1 with the patch reverted works fine. :-) So just remove the pci_enable/disable_device call in the driver makes the system work? Strange, I tried them on two laptops (one HP nx5000, and one Toshiba M2N), both works (no hang, and USB mouse works after S3/S4. I didn't try yenta, since I have no pc card) for S3/S4. Is it possible it's another bug or just because of different BIOS? Thanks, Shaohua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re:2.6.12-rc1-mm1: Kernel BUG at pci:389)
On Thu, 2005-03-24 at 09:03, Len Brown wrote: > On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote: > > Hi, > > > > On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote: > > > Hi! > > > > > > > > > > Will this do it for the moment? > > > > > > > > > > > > Its certainly better. > > > > > > > > > > With the Len's patch applied I have to unload the modules: > > > > > > > > > > ohci_hcd > > > > > ehci_hcd > > > > > yenta_socket > > > > > > > > > > before suspend as each of them hangs the box solid during > either > > > > > suspend or resume. Moreover, when I tried to load the > ehci_hcd > > > > > module back after resume, it hanged the box solid too. > > Is this failure with suspend to RAM or to disk? > > How about if you try this patch? > > http://linux-acpi.bkbits.net:8080/to-akpm/[EMAIL PROTECTED] > > patch -Rp1 from 2.6.12-rc1-mm and see if it stops being broken > or patch -Np1 to 2.6.12-rc and see if it starts being broken. > > This one removes an earlier attempt at resuming PCI links -- now > putting the onus on the drivers to be properly written > to release and acquire their interrupt for a successful > suspend/resume. > > > In theory, this is taken care of something like this: > driver.resume > pci_enable_device > pci_enable_device_bars > pcibios_enable_device > pcibios_enable_irq > acpi_pci_irq_enable > > but if the patch above makes a difference, then theory != practice:-) > > I'd believe that ohci_hcd and ehci_hcd are fragile since glancing > at their lengthy .resume routines it isn't immediately obvious > that they do this. But yenta_dev_resume has a pci_enable_device(), > so that failure may be less straightforward. > > cheers, > -Len > > ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled > boot, that would help -- for it will show if we're even using pci > interrupt links (and programming them) for these devices on this box. Yes, we changed the behavior of device suspend/resume. Every PCI device should call 'pci_disable_device' at suspend and call 'pci_enable_device' at resume. It fixes a bug and more important thing is it's safer (Eg. it disable interrupts, bus master and etc). I actually added such calls in uhci, ehci and yenta. It's ok for S3 (and definitely required for S3). Unclear if it's ok for S4, so please try revert the patch. Thanks, Shaohua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)
On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote: > Hi, > > On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote: > > Hi! > > > > > > > > Will this do it for the moment? > > > > > > > > > > Its certainly better. > > > > > > > > With the Len's patch applied I have to unload the modules: > > > > > > > > ohci_hcd > > > > ehci_hcd > > > > yenta_socket > > > > > > > > before suspend as each of them hangs the box solid during either > > > > suspend or resume. Moreover, when I tried to load the ehci_hcd > > > > module back after resume, it hanged the box solid too. Is this failure with suspend to RAM or to disk? How about if you try this patch? http://linux-acpi.bkbits.net:8080/to-akpm/[EMAIL PROTECTED] patch -Rp1 from 2.6.12-rc1-mm and see if it stops being broken or patch -Np1 to 2.6.12-rc and see if it starts being broken. This one removes an earlier attempt at resuming PCI links -- now putting the onus on the drivers to be properly written to release and acquire their interrupt for a successful suspend/resume. In theory, this is taken care of something like this: driver.resume pci_enable_device pci_enable_device_bars pcibios_enable_device pcibios_enable_irq acpi_pci_irq_enable but if the patch above makes a difference, then theory != practice:-) I'd believe that ohci_hcd and ehci_hcd are fragile since glancing at their lengthy .resume routines it isn't immediately obvious that they do this. But yenta_dev_resume has a pci_enable_device(), so that failure may be less straightforward. cheers, -Len ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled boot, that would help -- for it will show if we're even using pci interrupt links (and programming them) for these devices on this box. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi, On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote: > Hi! > > > > > > Will this do it for the moment? > > > > > > > > Its certainly better. > > > > > > With the Len's patch applied I have to unload the modules: > > > > > > ohci_hcd > > > ehci_hcd > > > yenta_socket > > > > > > before suspend as each of them hangs the box solid during either > > > suspend or resume. Moreover, when I tried to load the ehci_hcd > > > module back after resume, it hanged the box solid too. > > > > This behavior is apparently caused by the call to pci_write_config_word() > > with > > pmcsr = 0 in drivers/pci/pci.c:pci_set_power_state(). > > > > Well, I don't think I can do anything more about it myself. :-) > > Can you just revert those two patches from Len, and see what happens? Reverting them doesn't change anything, so there's something else that breaks things, apparently. Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi! > > > > Will this do it for the moment? > > > > > > Its certainly better. > > > > With the Len's patch applied I have to unload the modules: > > > > ohci_hcd > > ehci_hcd > > yenta_socket > > > > before suspend as each of them hangs the box solid during either > > suspend or resume. Moreover, when I tried to load the ehci_hcd > > module back after resume, it hanged the box solid too. > > This behavior is apparently caused by the call to pci_write_config_word() with > pmcsr = 0 in drivers/pci/pci.c:pci_set_power_state(). > > Well, I don't think I can do anything more about it myself. :-) Can you just revert those two patches from Len, and see what happens? Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi, On Tuesday, 22 of March 2005 22:49, Rafael J. Wysocki wrote: > Hi, > > On Tuesday, 22 of March 2005 12:01, Pavel Machek wrote: > > Hi! > > > > > Will this do it for the moment? > > > > Its certainly better. > > With the Len's patch applied I have to unload the modules: > > ohci_hcd > ehci_hcd > yenta_socket > > before suspend as each of them hangs the box solid during either > suspend or resume. Moreover, when I tried to load the ehci_hcd > module back after resume, it hanged the box solid too. This behavior is apparently caused by the call to pci_write_config_word() with pmcsr = 0 in drivers/pci/pci.c:pci_set_power_state(). Well, I don't think I can do anything more about it myself. :-) Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi, On Tuesday, 22 of March 2005 22:49, Rafael J. Wysocki wrote: Hi, On Tuesday, 22 of March 2005 12:01, Pavel Machek wrote: Hi! Will this do it for the moment? Its certainly better. With the Len's patch applied I have to unload the modules: ohci_hcd ehci_hcd yenta_socket before suspend as each of them hangs the box solid during either suspend or resume. Moreover, when I tried to load the ehci_hcd module back after resume, it hanged the box solid too. This behavior is apparently caused by the call to pci_write_config_word() with pmcsr = 0 in drivers/pci/pci.c:pci_set_power_state(). Well, I don't think I can do anything more about it myself. :-) Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi! Will this do it for the moment? Its certainly better. With the Len's patch applied I have to unload the modules: ohci_hcd ehci_hcd yenta_socket before suspend as each of them hangs the box solid during either suspend or resume. Moreover, when I tried to load the ehci_hcd module back after resume, it hanged the box solid too. This behavior is apparently caused by the call to pci_write_config_word() with pmcsr = 0 in drivers/pci/pci.c:pci_set_power_state(). Well, I don't think I can do anything more about it myself. :-) Can you just revert those two patches from Len, and see what happens? Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)
On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote: Hi, On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote: Hi! Will this do it for the moment? Its certainly better. With the Len's patch applied I have to unload the modules: ohci_hcd ehci_hcd yenta_socket before suspend as each of them hangs the box solid during either suspend or resume. Moreover, when I tried to load the ehci_hcd module back after resume, it hanged the box solid too. Is this failure with suspend to RAM or to disk? How about if you try this patch? http://linux-acpi.bkbits.net:8080/to-akpm/[EMAIL PROTECTED] patch -Rp1 from 2.6.12-rc1-mm and see if it stops being broken or patch -Np1 to 2.6.12-rc and see if it starts being broken. This one removes an earlier attempt at resuming PCI links -- now putting the onus on the drivers to be properly written to release and acquire their interrupt for a successful suspend/resume. In theory, this is taken care of something like this: driver.resume pci_enable_device pci_enable_device_bars pcibios_enable_device pcibios_enable_irq acpi_pci_irq_enable but if the patch above makes a difference, then theory != practice:-) I'd believe that ohci_hcd and ehci_hcd are fragile since glancing at their lengthy .resume routines it isn't immediately obvious that they do this. But yenta_dev_resume has a pci_enable_device(), so that failure may be less straightforward. cheers, -Len ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled boot, that would help -- for it will show if we're even using pci interrupt links (and programming them) for these devices on this box. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re:2.6.12-rc1-mm1: Kernel BUG at pci:389)
On Thu, 2005-03-24 at 09:03, Len Brown wrote: On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote: Hi, On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote: Hi! Will this do it for the moment? Its certainly better. With the Len's patch applied I have to unload the modules: ohci_hcd ehci_hcd yenta_socket before suspend as each of them hangs the box solid during either suspend or resume. Moreover, when I tried to load the ehci_hcd module back after resume, it hanged the box solid too. Is this failure with suspend to RAM or to disk? How about if you try this patch? http://linux-acpi.bkbits.net:8080/to-akpm/[EMAIL PROTECTED] patch -Rp1 from 2.6.12-rc1-mm and see if it stops being broken or patch -Np1 to 2.6.12-rc and see if it starts being broken. This one removes an earlier attempt at resuming PCI links -- now putting the onus on the drivers to be properly written to release and acquire their interrupt for a successful suspend/resume. In theory, this is taken care of something like this: driver.resume pci_enable_device pci_enable_device_bars pcibios_enable_device pcibios_enable_irq acpi_pci_irq_enable but if the patch above makes a difference, then theory != practice:-) I'd believe that ohci_hcd and ehci_hcd are fragile since glancing at their lengthy .resume routines it isn't immediately obvious that they do this. But yenta_dev_resume has a pci_enable_device(), so that failure may be less straightforward. cheers, -Len ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled boot, that would help -- for it will show if we're even using pci interrupt links (and programming them) for these devices on this box. Yes, we changed the behavior of device suspend/resume. Every PCI device should call 'pci_disable_device' at suspend and call 'pci_enable_device' at resume. It fixes a bug and more important thing is it's safer (Eg. it disable interrupts, bus master and etc). I actually added such calls in uhci, ehci and yenta. It's ok for S3 (and definitely required for S3). Unclear if it's ok for S4, so please try revert the patch. Thanks, Shaohua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
