Re: 2.6.13-rc3-mm1: a regression
On Saturday, 16 of July 2005 23:39, Andrew Morton wrote: > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > > On Friday, 15 of July 2005 10:36, Andrew Morton wrote: > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ > > > > > > (http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until > > > kernel.org syncs up) > > > > There seems to be a regression wrt 2.6.13-rc3 which causes my box (Asus > > L5D, > > Athlon 64 + nForce3) to hang solid during resume from disk on battery > > power. > > > > First, 2.6.13-rc3-mm1 is affected by the problems described at: > > http://bugzilla.kernel.org/show_bug.cgi?id=4416 > > http://bugzilla.kernel.org/show_bug.cgi?id=4665 > > These problems go away after applying the two attached patches. Then, the > > box resumes on AC power but hangs solid during resume on battery power. > > The problem is 100% reproducible and I think it's related to ACPI. > > That recent acpi merge seems to have damaged a number of people... > > Are you able to test Linus's latest -git spanshot? See if there's a > difference between -linus and -mm behaviour? I was afraid you would say so. ;-) The -rc3-git-[2-4] kernels are unaffected by the problem described, so it seems to be specific to -rc3-mm1. 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.13-rc3-mm1: a regression
On Saturday, 16 of July 2005 23:39, Andrew Morton wrote: Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Friday, 15 of July 2005 10:36, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ (http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until kernel.org syncs up) There seems to be a regression wrt 2.6.13-rc3 which causes my box (Asus L5D, Athlon 64 + nForce3) to hang solid during resume from disk on battery power. First, 2.6.13-rc3-mm1 is affected by the problems described at: http://bugzilla.kernel.org/show_bug.cgi?id=4416 http://bugzilla.kernel.org/show_bug.cgi?id=4665 These problems go away after applying the two attached patches. Then, the box resumes on AC power but hangs solid during resume on battery power. The problem is 100% reproducible and I think it's related to ACPI. That recent acpi merge seems to have damaged a number of people... Are you able to test Linus's latest -git spanshot? See if there's a difference between -linus and -mm behaviour? I was afraid you would say so. ;-) The -rc3-git-[2-4] kernels are unaffected by the problem described, so it seems to be specific to -rc3-mm1. 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.13-rc3-mm1: a regression
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > On Friday, 15 of July 2005 10:36, Andrew Morton wrote: > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ > > > > (http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until > > kernel.org syncs up) > > There seems to be a regression wrt 2.6.13-rc3 which causes my box (Asus L5D, > Athlon 64 + nForce3) to hang solid during resume from disk on battery power. > > First, 2.6.13-rc3-mm1 is affected by the problems described at: > http://bugzilla.kernel.org/show_bug.cgi?id=4416 > http://bugzilla.kernel.org/show_bug.cgi?id=4665 > These problems go away after applying the two attached patches. Then, the > box resumes on AC power but hangs solid during resume on battery power. > The problem is 100% reproducible and I think it's related to ACPI. That recent acpi merge seems to have damaged a number of people... Are you able to test Linus's latest -git spanshot? See if there's a difference between -linus and -mm behaviour? - 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.13-rc3-mm1: a regression
On Friday, 15 of July 2005 10:36, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
>
> (http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until
> kernel.org syncs up)
There seems to be a regression wrt 2.6.13-rc3 which causes my box (Asus L5D,
Athlon 64 + nForce3) to hang solid during resume from disk on battery power.
First, 2.6.13-rc3-mm1 is affected by the problems described at:
http://bugzilla.kernel.org/show_bug.cgi?id=4416
http://bugzilla.kernel.org/show_bug.cgi?id=4665
These problems go away after applying the two attached patches. Then, the
box resumes on AC power but hangs solid during resume on battery power.
The problem is 100% reproducible and I think it's related to ACPI.
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"
--- linux-2.6.13-rc3-mm1/drivers/acpi/pci_link.c 2005-07-15 13:18:24.0 +0200
+++ new/drivers/acpi/pci_link.c 2005-07-15 13:19:30.0 +0200
@@ -72,12 +72,10 @@
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 {
@@ -532,10 +530,6 @@
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);
@@ -719,21 +713,34 @@
return_VALUE(result);
}
-static int irqrouter_suspend(struct sys_device *dev, pm_message_t state)
+
+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)
{
struct list_head*node = NULL;
struct acpi_pci_link*link = NULL;
- ACPI_FUNCTION_TRACE("irqrouter_suspend");
+ ACPI_FUNCTION_TRACE("irqrouter_resume");
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;
}
- if (link->irq.active && link->irq.initialized)
- link->irq.suspend_resume = 1;
+
+ acpi_pci_link_resume(link);
}
return_VALUE(0);
}
@@ -848,7 +855,7 @@
static struct sysdev_class irqrouter_sysdev_class = {
set_kset_name("irqrouter"),
-.suspend = irqrouter_suspend,
+.resume = irqrouter_resume,
};
--- 2.6.12-rc3-mm2-old/drivers/acpi/ec.c 2005-05-01 13:13:43.0 +0200
+++ linux-2.6.12-rc3-mm2/drivers/acpi/ec.c 2005-05-01 14:08:12.0 +0200
@@ -31,7 +31,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -50,19 +49,17 @@ ACPI_MODULE_NAME ("acpi_ec")
#define ACPI_EC_FLAG_OBF 0x01 /* Output buffer full */
#define ACPI_EC_FLAG_IBF 0x02 /* Input buffer full */
-#define ACPI_EC_FLAG_BURST 0x10 /* burst mode */
#define ACPI_EC_FLAG_SCI 0x20 /* EC-SCI occurred */
#define ACPI_EC_EVENT_OBF 0x01 /* Output buffer full */
#define ACPI_EC_EVENT_IBE 0x02 /* Input buffer empty */
-#define ACPI_EC_DELAY 50 /* Wait 50ms max. during EC ops */
+#define ACPI_EC_UDELAY 100 /* Poll @ 100us increments */
+#define ACPI_EC_UDELAY_COUNT 1000 /* Wait 10ms max. during EC ops */
#define ACPI_EC_UDELAY_GLK 1000 /* Wait 1ms max. to get global lock */
#define ACPI_EC_COMMAND_READ 0x80
#define ACPI_EC_COMMAND_WRITE 0x81
-#define ACPI_EC_BURST_ENABLE 0x82
-#define ACPI_EC_BURST_DISABLE 0x83
#define ACPI_EC_COMMAND_QUERY 0x84
static int acpi_ec_add (struct acpi_device *device);
@@ -90,11 +87,7 @@ struct acpi_ec {
struct acpi_generic_address command_addr;
struct acpi_generic_address data_addr;
unsigned long global_lock;
- unsigned int expect_event;
- atomic_t leaving_burst; /* 0 : No, 1 : Yes, 2: abort*/
- atomic_t pending_gpe;
- struct semaphore sem;
- wait_queue_head_t wait;
+ spinlock_t lock;
};
/* If we find an EC via the ECDT, we need to keep a ptr to its context */
@@ -107,138 +100,59 @@ static struct acpi_device *first_ec;
Transaction Management
-- */
-static inline u32 acpi_ec_read_status(struct acpi_ec *ec)
-{
- u32 status = 0;
-
- acpi_hw_low_level_read(8, , >status_addr);
- return status;
-}
-
-static int acpi_ec_wait(struct acpi_ec *ec, unsigned int event)
+static int
+acpi_ec_wait (
+ struct acpi_ec *ec,
+ u8 event)
{
- int result = 0;
-
- ACPI_FUNCTION_TRACE("acpi_ec_wait");
+ u32 acpi_ec_status = 0;
+ u32
Re: 2.6.13-rc3-mm1: a regression
On Friday, 15 of July 2005 10:36, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
(http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until
kernel.org syncs up)
There seems to be a regression wrt 2.6.13-rc3 which causes my box (Asus L5D,
Athlon 64 + nForce3) to hang solid during resume from disk on battery power.
First, 2.6.13-rc3-mm1 is affected by the problems described at:
http://bugzilla.kernel.org/show_bug.cgi?id=4416
http://bugzilla.kernel.org/show_bug.cgi?id=4665
These problems go away after applying the two attached patches. Then, the
box resumes on AC power but hangs solid during resume on battery power.
The problem is 100% reproducible and I think it's related to ACPI.
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
--- linux-2.6.13-rc3-mm1/drivers/acpi/pci_link.c 2005-07-15 13:18:24.0 +0200
+++ new/drivers/acpi/pci_link.c 2005-07-15 13:19:30.0 +0200
@@ -72,12 +72,10 @@
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 {
@@ -532,10 +530,6 @@
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);
@@ -719,21 +713,34 @@
return_VALUE(result);
}
-static int irqrouter_suspend(struct sys_device *dev, pm_message_t state)
+
+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)
{
struct list_head*node = NULL;
struct acpi_pci_link*link = NULL;
- ACPI_FUNCTION_TRACE(irqrouter_suspend);
+ ACPI_FUNCTION_TRACE(irqrouter_resume);
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;
}
- if (link-irq.active link-irq.initialized)
- link-irq.suspend_resume = 1;
+
+ acpi_pci_link_resume(link);
}
return_VALUE(0);
}
@@ -848,7 +855,7 @@
static struct sysdev_class irqrouter_sysdev_class = {
set_kset_name(irqrouter),
-.suspend = irqrouter_suspend,
+.resume = irqrouter_resume,
};
--- 2.6.12-rc3-mm2-old/drivers/acpi/ec.c 2005-05-01 13:13:43.0 +0200
+++ linux-2.6.12-rc3-mm2/drivers/acpi/ec.c 2005-05-01 14:08:12.0 +0200
@@ -31,7 +31,6 @@
#include linux/delay.h
#include linux/proc_fs.h
#include linux/seq_file.h
-#include linux/interrupt.h
#include asm/io.h
#include acpi/acpi_bus.h
#include acpi/acpi_drivers.h
@@ -50,19 +49,17 @@ ACPI_MODULE_NAME (acpi_ec)
#define ACPI_EC_FLAG_OBF 0x01 /* Output buffer full */
#define ACPI_EC_FLAG_IBF 0x02 /* Input buffer full */
-#define ACPI_EC_FLAG_BURST 0x10 /* burst mode */
#define ACPI_EC_FLAG_SCI 0x20 /* EC-SCI occurred */
#define ACPI_EC_EVENT_OBF 0x01 /* Output buffer full */
#define ACPI_EC_EVENT_IBE 0x02 /* Input buffer empty */
-#define ACPI_EC_DELAY 50 /* Wait 50ms max. during EC ops */
+#define ACPI_EC_UDELAY 100 /* Poll @ 100us increments */
+#define ACPI_EC_UDELAY_COUNT 1000 /* Wait 10ms max. during EC ops */
#define ACPI_EC_UDELAY_GLK 1000 /* Wait 1ms max. to get global lock */
#define ACPI_EC_COMMAND_READ 0x80
#define ACPI_EC_COMMAND_WRITE 0x81
-#define ACPI_EC_BURST_ENABLE 0x82
-#define ACPI_EC_BURST_DISABLE 0x83
#define ACPI_EC_COMMAND_QUERY 0x84
static int acpi_ec_add (struct acpi_device *device);
@@ -90,11 +87,7 @@ struct acpi_ec {
struct acpi_generic_address command_addr;
struct acpi_generic_address data_addr;
unsigned long global_lock;
- unsigned int expect_event;
- atomic_t leaving_burst; /* 0 : No, 1 : Yes, 2: abort*/
- atomic_t pending_gpe;
- struct semaphore sem;
- wait_queue_head_t wait;
+ spinlock_t lock;
};
/* If we find an EC via the ECDT, we need to keep a ptr to its context */
@@ -107,138 +100,59 @@ static struct acpi_device *first_ec;
Transaction Management
-- */
-static inline u32 acpi_ec_read_status(struct acpi_ec *ec)
-{
- u32 status = 0;
-
- acpi_hw_low_level_read(8, status, ec-status_addr);
- return status;
-}
-
-static int acpi_ec_wait(struct acpi_ec *ec, unsigned int event)
+static int
+acpi_ec_wait (
+ struct acpi_ec *ec,
+ u8 event)
{
- int result =
Re: 2.6.13-rc3-mm1: a regression
Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Friday, 15 of July 2005 10:36, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ (http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until kernel.org syncs up) There seems to be a regression wrt 2.6.13-rc3 which causes my box (Asus L5D, Athlon 64 + nForce3) to hang solid during resume from disk on battery power. First, 2.6.13-rc3-mm1 is affected by the problems described at: http://bugzilla.kernel.org/show_bug.cgi?id=4416 http://bugzilla.kernel.org/show_bug.cgi?id=4665 These problems go away after applying the two attached patches. Then, the box resumes on AC power but hangs solid during resume on battery power. The problem is 100% reproducible and I think it's related to ACPI. That recent acpi merge seems to have damaged a number of people... Are you able to test Linus's latest -git spanshot? See if there's a difference between -linus and -mm behaviour? - 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/
