ACPI patches for 2.6.28-rc3

From: Alexey Starikovskiy <[email protected]>

breakage introduced by following patch
commit 27663c5855b10af9ec67bc7dfba001426ba21222

Author: Matthew Wilcox <[email protected]>
Date:   Fri Oct 10 02:22:59 2008 -0400

acpi_evaluate_integer() does not clear passed variable if there is an error at evaluation.
So if we ignore error, we must supply initialized variable.

References: http://bugzilla.kernel.org/show_bug.cgi?id=11917

	    http://bugzilla.kernel.org/show_bug.cgi?id=11896

Signed-off-by Alexey Starikovskiy <[email protected]>

Tested-by Alan Jenkins <[email protected]>

Signed-off-by Len Brown <[email protected]>

---
 drivers/acpi/ec.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

drivers/acpi/ec.c +2 -1

index ef42316..523ac5b 100644
@@ -736,7 +736,7 @@ static acpi_status
 ec_parse_device(acpi_handle handle, u32 Level, void *context, void **retval)
 {
 	acpi_status status;
-	unsigned long long tmp;
+	unsigned long long tmp = 0;
 
 	struct acpi_ec *ec = context;
 	status = acpi_walk_resources(handle, METHOD_NAME__CRS,

@@ -751,6 +751,7 @@ ec_parse_device(acpi_handle handle, u32 Level, void *context, void **retval)
 		return status;
 	ec->gpe = tmp;
 	/* Use the global lock for all EC transactions? */
+	tmp = 0;
 	acpi_evaluate_integer(handle, "_GLK", NULL, &tmp);
 	ec->global_lock = tmp;
 	ec->handle = handle;

Quoted 13 lines

From: Alexey Starikovskiy <[email protected]>

breakage introduced by following patch
commit 27663c5855b10af9ec67bc7dfba001426ba21222

Author: Matthew Wilcox <[email protected]>
Date:   Fri Oct 10 02:22:59 2008 -0400

acpi_evaluate_integer() does not clear passed variable if there is an error at evaluation.
So if we ignore error, we must supply initialized variable.

Quoted 2 lines

References: http://bugzilla.kernel.org/show_bug.cgi?id=11917

	    http://bugzilla.kernel.org/show_bug.cgi?id=11896

The bug references for 11896 should be deleted.
The bug for 11896 can't be resolved by this patch.
Thanks.

Hi, Alexey
After checking the EC working flowchart I find a fatal logic error that exists in EC write transaction. The issue happens on most laptops. The following is the detailed explanation about this issue:
According to the ACPI the EC write transaction is divided into the following three phases: (Seen in the section 12.6.2 of ACPI 3.0b)
a. Byte #1: Host Writes the EC command to EC CMD I/O PORT. Interrupt is triggered after EC reads the command byte
b. Byte #2: Host writes the address index to EC data I/O port. Interrupt is triggered after EC reads the address index byte
c. Byte #3: Host writes the Data to EC data I/O port. Interrupt is triggered after EC reads the data byte

When the function of acpi_ec_transaction_unlocked is called for EC write transaction, the wlen variable is initialized as 2 and the rlen variable is initialized as zero. Then EC transaction follows the below three steps.
1. OS writes the EC command to EC CMD I/O port
2. EC GPE interrupt is triggered and then the address index is written into EC data I/O port. (The wlen is decreased to 1.This is executed in EC GPE handler)
3. EC GPE interrupt is triggered again and then the data is written into the EC data I/O port. The wlen is decreased to 0.(This is also executed in EC GPE handler). As the wlen is decreased to zero, it means that the EC transaction is finished(True is returned by the function of ec_transaction_done).
>status = acpi_ec_read_status(ec);
>gpe_transaction(ec, status);
> if (ec_transaction_done(ec) && (status & ACPI_EC_FLAG_IBF) == 0)
wake_up(&ec->wait);
In this step the status variable only indicates that EC controller already reads the address index written by OS(It can’t indicate that EC controller already reads the data byte written by Host). As the IBF flag is zero, the waiting process is waked up and EC mutex lock is released. In such case it means that OS can begin another EC transaction. But in fact in such case EC transaction is not really finished. After the EC data is written into EC Data I/O port, no flag indicates whether EC transaction is finished. Only when the IBF bit becomes zero again, we can say that EC transaction is really finished. If OS begins another EC transaction before previous EC transaction is really finished, we can't imagine what will happen.
　　IMO Based on the above analysis there exists the fatal logic error in the EC write transaction after the patch from Alexey is shipped. Although now no one reports this issue, it is still an unstable factor. After all it is the fatal logic error. 　　 　　 At the same time there exists the similar logic error when OS begins an EC transaction to disable the EC burst mode.

　　Welcome the comments.

　　Best regards
　　 Yakui

Hi, Alexey
After checking the EC working flowchart I find a fatal logic error that exists in EC write transaction. The issue happens on most laptops. The following is the detailed explanation about this issue:
According to the ACPI the EC write transaction is divided into the following three phases: (Seen in the section 12.6.2 of ACPI 3.0b)
a. Byte #1: Host Writes the EC command to EC CMD I/O PORT. Interrupt is triggered after EC reads the command byte
b. Byte #2: Host writes the address index to EC data I/O port. Interrupt is triggered after EC reads the address index byte
c. Byte #3: Host writes the Data to EC data I/O port. Interrupt is triggered after EC reads the data byte

When the function of acpi_ec_transaction_unlocked is called for EC write transaction, the wlen variable is initialized as 2 and the rlen variable is initialized as zero. Then EC transaction follows the below three steps.
1. OS writes the EC command to EC CMD I/O port
2. EC GPE interrupt is triggered and then the address index is written into EC data I/O port. (The wlen is decreased to 1.This is executed in EC GPE handler)
3. EC GPE interrupt is triggered again and then the data is written into the EC data I/O port. The wlen is decreased to 0.(This is also executed in EC GPE handler). As the wlen is decreased to zero, it means that the EC transaction is finished(True is returned by the function of ec_transaction_done).
>status = acpi_ec_read_status(ec);
>gpe_transaction(ec, status);
> if (ec_transaction_done(ec) && (status & ACPI_EC_FLAG_IBF) == 0)
wake_up(&ec->wait);
In this step the status variable only indicates that EC controller already reads the address index written by OS(It can’t indicate that EC controller already reads the data byte written by Host). As the IBF flag is zero, the waiting process is waked up and EC mutex lock is released. In such case it means that OS can begin another EC transaction. But in fact in such case EC transaction is not really finished. After the EC data is written into EC Data I/O port, no flag indicates whether EC transaction is finished. Only when the IBF bit becomes zero again, we can say that EC transaction is really finished. If OS begins another EC transaction before previous EC transaction is really finished, we can't imagine what will happen.
　　IMO Based on the above analysis there exists the fatal logic error in the EC write transaction after the patch from Alexey is shipped. Although now no one reports this issue, it is still an unstable factor. After all it is the fatal logic error.

　　 At the same time there exists the similar logic error when OS begins an EC transaction to disable the EC burst mode.

　　Welcome the comments.

　　Best regards
　　 Yakui

a. When the host writes data to the command or data register of the embedded controller, the input buffer flag (IBF) in the status register is set within 1 microsecond.( Please see it in the section 12.7 of ACPI 3.0b. This should be paid attention to). So If another EC transaction is started in 1 microsecond, maybe the EC status is not updated. In such case the problem will appear.
At the same time we can't expect that all the EC follows the spec strictly. Maybe on some EC controllers more time is needed.
b. Why not wait before the EC transaction is finished? If it fails, it can't be caught in time. From the programming viewpoint the logic is incorrect. If you insist that viewpoint is correct, IMO this issue can be discussed in the wider range.

In my email I raise the issue about your patch. If your patch can work well, no one is willing to raise any issue about your patch.

-----Original Message-----
From: Alexey Starikovskiy [mailto:[email protected]] Sent: 2008年11月8日 23:34
To: Zhao, Yakui
Cc: LenBrown; [email protected]; Brown, Len; Li, Shaohua; Zhang, Rui; Lin, Ming M
Subject: Re: The fatal logic error in EC write transaction(EC transaction is done in interrupt context)

Hi Yakui,

Just don't know how I would have lived without your valuable analisys...
Do you remember that ec_transaction starts by waiting for IBF to become 0?
Thus not any new transaction should begin before previous write or burst-disable command completes. So, fatal logic error exists only in your head.

Now, let me explain why it is better to wait for last IBF=0 event at beginning of transaction, rather than at the end of previous one.
Look at the flow chart from different angle -- as fast transaction patch does it:
EC sends interrupt to OS then it is ready for us to proceed. It will send us interrupt marking IBF=0 transition if it expects us to write byte and it will send us interrupt marking OBF=1 transition if it expects us to read byte. It does not ever send us IBF=1 or OBF=0 interrupts just because there is nothing we could of should do in such a case. After we completed write sequence, we don't need to wait for last IBF=0 transition, as we don't know if we will have anything else to write -- it might be last transaction for quite a while. But next transaction knows that it should not start before IBF is cleared, thus it waits for it (and expects possible interrupt).

Regards,
Alex.

Quoted 26 lines · Yakui

Hi, Alexey
After checking the EC working flowchart I find a fatal logic error that exists in EC write transaction. The issue happens on most laptops. The following is the detailed explanation about this issue:
According to the ACPI the EC write transaction is divided into the following three phases: (Seen in the section 12.6.2 of ACPI 3.0b)
a. Byte #1: Host Writes the EC command to EC CMD I/O PORT. Interrupt is triggered after EC reads the command byte
b. Byte #2: Host writes the address index to EC data I/O port. Interrupt is triggered after EC reads the address index byte
c. Byte #3: Host writes the Data to EC data I/O port. Interrupt is triggered after EC reads the data byte

When the function of acpi_ec_transaction_unlocked is called for EC write transaction, the wlen variable is initialized as 2 and the rlen variable is initialized as zero. Then EC transaction follows the below three steps.
1. OS writes the EC command to EC CMD I/O port
2. EC GPE interrupt is triggered and then the address index is written into EC data I/O port. (The wlen is decreased to 1.This is executed in EC GPE handler)
3. EC GPE interrupt is triggered again and then the data is written into the EC data I/O port. The wlen is decreased to 0.(This is also executed in EC GPE handler). As the wlen is decreased to zero, it means that the EC transaction is finished(True is returned by the function of ec_transaction_done).
>status = acpi_ec_read_status(ec);
>gpe_transaction(ec, status);
> if (ec_transaction_done(ec) && (status & ACPI_EC_FLAG_IBF) == 0)
wake_up(&ec->wait);
In this step the status variable only indicates that EC controller already reads the address index written by OS(It can’t indicate that EC controller already reads the data byte written by Host). As the IBF flag is zero, the waiting process is waked up and EC mutex lock is released. In such case it means that OS can begin another EC transaction. But in fact in such case EC transaction is not really finished. After the EC data is written into EC Data I/O port, no flag indicates whether EC transaction is finished. Only when the IBF bit becomes zero again, we can say that EC transaction is really finished. If OS begins another EC transaction before previous EC transaction is really finished, we can't imagine what will happen.
　　IMO Based on the above analysis there exists the fatal logic error in the EC write transaction after the patch from Alexey is shipped. Although now no one reports this issue, it is still an unstable factor. After all it is the fatal logic error. 　　 　　 At the same time there exists the similar logic error when OS begins an EC transaction to disable the EC burst mode.

　　Welcome the comments.

　　Best regards
　　 Yakui

There is a possibility that EC might break if next command is issued within 1 us after write or burst-disable command. This "possibility" was in EC driver for 3.5 years, after 451566f45a2e6cd10ba56e7220a9dd84ba3ef550.

References: http://marc.info/?l=linux-acpi&m=122616284402886&w=4

Cc Zhao Yakui <[email protected]>

Signed-off-by Alexey Starikovskiy <[email protected]>

---

 drivers/acpi/ec.c |   21 +++++++++++++--------
 1 files changed, 13 insertions(+), 8 deletions(-)

drivers/acpi/ec.c +13 -9

index e5dbe21..d6007ac 100644
@@ -102,6 +102,7 @@ struct transaction {
 	u8 command;
 	u8 wlen;
 	u8 rlen;
+	bool done;
 };
 
 static struct acpi_ec {

@@ -178,7 +179,7 @@ static int ec_transaction_done(struct acpi_ec *ec)
 	unsigned long flags;
 	int ret = 0;
 	spin_lock_irqsave(&ec->curr_lock, flags);
-	if (!ec->curr || (!ec->curr->wlen && !ec->curr->rlen))
+	if (!ec->curr || ec->curr->done)
 		ret = 1;
 	spin_unlock_irqrestore(&ec->curr_lock, flags);
 	return ret;

@@ -195,17 +196,20 @@ static void gpe_transaction(struct acpi_ec *ec, u8 status)
 			acpi_ec_write_data(ec, *(ec->curr->wdata++));
 			--ec->curr->wlen;
 		} else
-			/* false interrupt, state didn't change */
-			++ec->curr->irq_count;
-
+			goto err;
 	} else if (ec->curr->rlen > 0) {
 		if ((status & ACPI_EC_FLAG_OBF) == 1) {
 			*(ec->curr->rdata++) = acpi_ec_read_data(ec);
-			--ec->curr->rlen;
+			if (--ec->curr->rlen == 0)
+				ec->curr->done = true;
 		} else
-			/* false interrupt, state didn't change */
-			++ec->curr->irq_count;
-	}
+			goto err;
+	} else if (ec->curr->wlen == 0 && (status & ACPI_EC_FLAG_IBF) == 0)
+		ec->curr->done = true;
+	goto unlock;
+err:
+	/* false interrupt, state didn't change */
+	++ec->curr->irq_count;
 unlock:
 	spin_unlock_irqrestore(&ec->curr_lock, flags);
 }

@@ -265,6 +269,7 @@ static int acpi_ec_transaction_unlocked(struct acpi_ec *ec,
 	spin_lock_irqsave(&ec->curr_lock, tmp);
 	/* following two actions should be kept atomic */
 	t->irq_count = 0;
+	t->done = false;
 	ec->curr = t;
 	acpi_ec_write_cmd(ec, ec->curr->command);
 	if (ec->curr->command == ACPI_EC_COMMAND_QUERY)
 
--

To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Yakui,
This is not about my patch, this is about your ego...

My patch did not introduce this behaviour, it was there since "burst mode" was introduced, and may be even earlier. You may ask Luming Yu, why he was so optimistic about 1 microsecond (is he still around? you did not include him into CC yet...).

R egards,
Alex.

Quoted 27 lines · Yakui

a. When the host writes data to the command or data register of the embedded controller, the input buffer flag (IBF) in the status register is set within 1 microsecond.( Please see it in the section 12.7 of ACPI 3.0b. This should be paid attention to). So If another EC transaction is started in 1 microsecond, maybe the EC status is not updated. In such case the problem will appear.
At the same time we can't expect that all the EC follows the spec strictly. Maybe on some EC controllers more time is needed.
b. Why not wait before the EC transaction is finished? If it fails, it can't be caught in time. From the programming viewpoint the logic is incorrect. If you insist that viewpoint is correct, IMO this issue can be discussed in the wider range.

In my email I raise the issue about your patch. If your patch can work well, no one is willing to raise any issue about your patch.

-----Original Message-----
From: Alexey Starikovskiy [mailto:[email protected]]
Sent: 2008年11月8日 23:34
To: Zhao, Yakui
Cc: LenBrown; [email protected]; Brown, Len; Li, Shaohua; Zhang, Rui; Lin, Ming M
Subject: Re: The fatal logic error in EC write transaction(EC transaction is done in interrupt context)

Hi Yakui,

Just don't know how I would have lived without your valuable analisys...
Do you remember that ec_transaction starts by waiting for IBF to become 0?
Thus not any new transaction should begin before previous write or burst-disable command completes. So, fatal logic error exists only in your head.

Now, let me explain why it is better to wait for last IBF=0 event at beginning of transaction, rather than at the end of previous one.
Look at the flow chart from different angle -- as fast transaction patch does it:
EC sends interrupt to OS then it is ready for us to proceed. It will send us interrupt marking IBF=0 transition if it expects us to write byte and it will send us interrupt marking OBF=1 transition if it expects us to read byte. It does not ever send us IBF=1 or OBF=0 interrupts just because there is nothing we could of should do in such a case. After we completed write sequence, we don't need to wait for last IBF=0 transition, as we don't know if we will have anything else to write -- it might be last transaction for quite a while. But next transaction knows that it should not start before IBF is cleared, thus it waits
for it (and expects possible interrupt).

Quoted 33 lines

Regards,
Alex.

Quoted 28 lines · Yakui

Hi, Alexey
After checking the EC working flowchart I find a fatal logic error that exists in EC write transaction. The issue happens on most laptops. The following is the detailed explanation about this issue:
According to the ACPI the EC write transaction is divided into the following three phases: (Seen in the section 12.6.2 of ACPI 3.0b)
a. Byte #1: Host Writes the EC command to EC CMD I/O PORT. Interrupt is triggered after EC reads the command byte
b. Byte #2: Host writes the address index to EC data I/O port. Interrupt is triggered after EC reads the address index byte
c. Byte #3: Host writes the Data to EC data I/O port. Interrupt is triggered after EC reads the data byte

When the function of acpi_ec_transaction_unlocked is called for EC write transaction, the wlen variable is initialized as 2 and the rlen variable is initialized as zero. Then EC transaction follows the below three steps.
1. OS writes the EC command to EC CMD I/O port
2. EC GPE interrupt is triggered and then the address index is written into EC data I/O port. (The wlen is decreased to 1.This is executed in EC GPE handler)
3. EC GPE interrupt is triggered again and then the data is written into the EC data I/O port. The wlen is decreased to 0.(This is also executed in EC GPE handler). As the wlen is decreased to zero, it means that the EC transaction is finished(True is returned by the function of ec_transaction_done).
>status = acpi_ec_read_status(ec);
>gpe_transaction(ec, status);
> if (ec_transaction_done(ec) && (status & ACPI_EC_FLAG_IBF) == 0)
wake_up(&ec->wait);
In this step the status variable only indicates that EC controller already reads the address index written by OS(It can’t indicate that EC controller already reads the data byte written by Host). As the IBF flag is zero, the waiting process is waked up and EC mutex lock is released. In such case it means that OS can begin another EC transaction. But in fact in such case EC transaction is not really finished. After the EC data is written into EC Data I/O port, no flag indicates whether EC transaction is finished. Only when the IBF bit becomes zero again, we can say that EC transaction is really finished. If OS begins another EC transaction before previous EC transaction is really finished, we can't imagine what will happen.
　　IMO Based on the above analysis there exists the fatal logic error in the EC write transaction after the patch from Alexey is shipped. Although now no one reports this issue, it is still an unstable factor. After all it is the fatal logic error.

　　 At the same time there exists the similar logic error when OS begins an EC transaction to disable the EC burst mode.

　　Welcome the comments.

　　Best regards
　　 Yakui

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 3 lines · Alexey Starikovskiy

Yakui,
This is not about my patch, this is about your ego...

Thanks for the reply. I know that this is not introduced by your patch. In the previous kernel the EC transaction is explicitly divided into several phases. Only when EC transaction is really finished, the EC mutex lock is released. In such case the previous EC transaction is already finished when OS begins another EC transaction. So the issue about "1 microsecond" won't appear.

But in your patch(EC transaction is
done in interrupt context) when EC mutex is released , maybe the previous EC transaction is not really finished. In such case the issue of "1 microsecond" will appear.
Is what I said right?

Quoted 4 lines

My patch did not introduce this behaviour, it was there since "burst mode" was introduced, and may be even earlier. You may ask Luming Yu, why he was so optimistic about 1 microsecond (is he still around? you did not include him into CC yet...).

In my email what I said is only to point out the logic error. Maybe

there is no problem that the EC mutex is released before EC transaction is really finished. IMO this is still a logic error. The program logic states that EC transaction is already finished but the EC transaction is not really finished. They are inconsistent..
The more important is that the failure in EC transaction can't be
detected in time.

Do you agree with my analysis?

Yakui,

Please take a look at the subject of the thread -- notice words "fatal" and "(EC transaction is done in interrupt context)".
Looks horrible, isn't it? Now we begin to get into details, and it appears that it is not fatal, introduced 3.5 years ago, and has nothing to do with interrupt context transaction patch.
So, the whole point of your message is to spread FUD about "fast transaction" patch,
and show how great you are. I would guess that you've failed in achieving both goals.

If you cry "wolf!" too often, you'll get ignored, when the real wolf appears.

Now, for a positive example, the same message without exclamation marks...
---------------------------------------------------------------------------------------------------------------------------------
Subject: difference in EC transaction protocol
Hi Alex,
I've noticed difference in EC transaction protocol for write and burst-disable commands,
namely all that end with writing byte to EC -- they don't wait for last confirmation interrupt and
next transaction might start before current one completes.
May be this is the "root cause" we are looking for.
Regards,
Yakui
---------------------------------------------------------------------------------------------------------------------------------
Note that this message is shorter, and is not offensive. Smile, and people may start to like you...

Regards,
Alex.

P.S. And I don't agree with your analysis as you still believe that before the fast transaction mutex was
not released at the same time as it is now.

Quoted 11 lines · Zhao Yakui

Quoted 3 lines · Alexey Starikovskiy

Yakui,
This is not about my patch, this is about your ego...

Thanks for the reply. I know that this is not introduced by your patch. In the previous kernel the EC transaction is explicitly divided into several phases. Only when EC transaction is really finished, the EC mutex lock is released. In such case the previous EC transaction is already finished when OS begins another EC transaction. So the issue about "1 microsecond" won't appear.

No. No matter how many phases, transaction is done and EC mutex is released as soon as last write happens. EC driver never waited for confirmation for last written byte.

Quoted 5 lines

But in your patch(EC transaction is
done in interrupt context) when EC mutex is released , maybe the previous EC transaction is not really finished. In such case the issue of "1 microsecond" will appear.
Is what I said right?

No. my patch has same "optimization" as appeared in EC driver since introduction of interrupt mode.
May be it is more visible now, and you managed to notice it, while still failing to see it in earlier EC driver versions?
I agree that there are some benefits in not doing this optimization, thus I made the patch to drop it.

Quoted 4 lines

Quoted 4 lines

My patch did not introduce this behaviour, it was there since "burst mode" was introduced, and may be even earlier. You may ask Luming Yu, why he was so optimistic about 1 microsecond (is he still around? you did not include him into CC yet...).

Actually, I gave too much credit to Shanghai office... Interrupt mode patch was written by Dmitry Torokhov, not Luming Yu.

Quoted 2 lines

In my email what I said is only to point out the logic error. Maybe

No, see above.

Quoted 10 lines

there is no problem that the EC mutex is released before EC transaction is really finished. IMO this is still a logic error. The program logic states that EC transaction is already finished but the EC transaction is not really finished. They are inconsistent..
The more important is that the failure in EC transaction can't be
detected in time.

Do you agree with my analysis?

No, see above.

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 10 lines · Alexey Starikovskiy

Yakui,

Please take a look at the subject of the thread -- notice words "fatal" and "(EC transaction is done in interrupt context)".
Looks horrible, isn't it? Now we begin to get into details, and it appears that it is not fatal, introduced 3.5 years ago, and has nothing to do with interrupt context transaction patch.
So, the whole point of your message is to spread FUD about "fast transaction" patch, and show how great you are. I would guess that you've failed in achieving both goals.

I won't argue with you about this issue.

In your patch the program logic states that the EC transaction is
already finished. But in fact the EC transaction is not really finished. They are inconsistent. Why can't call this a fatal logic error?
The more important is that the failure in EC transaction can't be
detected in time.
Why can't call this a fatal logic error?

If this is not a fatal logic error, what can be called fatal? Like that Several commits are reverted each other as the following three commits.

    a.7c010de7506954e973abfab5c5999c5a97f7a73e
    b.4c611060660f0de3e9b8f02df207312bc6f5c331
    c.f9319f903f898dd4b15dbc386499725ce6c59776

If you still reply the subject so impolitely, Don't blame that I will forward the similar error to wider range.

From: Alan Jenkins <[email protected]>

Make sure we can tell if the GPE storm workaround gets activated, and avoid flooding the logs afterwards.

http://bugzilla.kernel.org/show_bug.cgi?id=11841
"plenty of line "ACPI: EC: non-query interrupt received,
switching to interrupt mode" in dmesg"

Signed-off-by Alan Jenkins <[email protected]>

Acked-by Alexey Starikovskiy <[email protected]>

Signed-off-by Len Brown <[email protected]>

Quoted 9 lines · Len Brown

From: Alan Jenkins <[email protected]>

Make sure we can tell if the GPE storm workaround gets activated, and avoid flooding the logs afterwards.

http://bugzilla.kernel.org/show_bug.cgi?id=11841
"plenty of line "ACPI: EC: non-query interrupt received,
switching to interrupt mode" in dmesg"

Quoted 4 lines

Signed-off-by Alan Jenkins <[email protected]>

Acked-by Alexey Starikovskiy <[email protected]>

Signed-off-by Len Brown <[email protected]>

I see the EC patches that cause this issue are part of 2.6.27-stable. So I think this patch should also be applied to the -stable tree.

Quoted 10 lines · Alan Jenkins

Quoted 9 lines · Len Brown

From: Alan Jenkins <[email protected]>

Make sure we can tell if the GPE storm workaround gets activated, and avoid flooding the logs afterwards.

http://bugzilla.kernel.org/show_bug.cgi?id=11841
"plenty of line "ACPI: EC: non-query interrupt received,
switching to interrupt mode" in dmesg"

Quoted 6 lines

Quoted 4 lines

Signed-off-by Alan Jenkins <[email protected]>

Acked-by Alexey Starikovskiy <[email protected]>

Signed-off-by Len Brown <[email protected]>

I see the EC patches that cause this issue are part of 2.6.27-stable. So I think this patch should also be applied to the -stable tree.

Good point, it should.

Quoted 15 lines · Rafael J. Wysocki

Quoted 14 lines · Alan Jenkins

Quoted 13 lines · Len Brown

From: Alan Jenkins <[email protected]>

Make sure we can tell if the GPE storm workaround gets activated, and avoid flooding the logs afterwards.

http://bugzilla.kernel.org/show_bug.cgi?id=11841
"plenty of line "ACPI: EC: non-query interrupt received,
switching to interrupt mode" in dmesg"

Signed-off-by Alan Jenkins <[email protected]>

Acked-by Alexey Starikovskiy <[email protected]>

Signed-off-by Len Brown <[email protected]>

Quoted 4 lines

Quoted 2 lines

I see the EC patches that cause this issue are part of 2.6.27-stable. So I think this patch should also be applied to the -stable tree.

Good point, it should.

Ok, what is the git commit id that should be added to the .27-stable tree?

Quoted 19 lines · Greg KH

Quoted 18 lines · Rafael J. Wysocki

Quoted 16 lines · Alan Jenkins

Quoted 5 lines · Len Brown

From: Alan Jenkins <[email protected]>

Make sure we can tell if the GPE storm workaround gets activated, and avoid flooding the logs afterwards.

Quoted 8 lines

http://bugzilla.kernel.org/show_bug.cgi?id=11841
"plenty of line "ACPI: EC: non-query interrupt received,
switching to interrupt mode" in dmesg"

Signed-off-by Alan Jenkins <[email protected]>

Acked-by Alexey Starikovskiy <[email protected]>

Signed-off-by Len Brown <[email protected]>

I see the EC patches that cause this issue are part of 2.6.27-stable. So I think this patch should also be applied to the -stable tree.

Quoted 4 lines

Quoted 1 line

Good point, it should.

Ok, what is the git commit id that should be added to the .27-stable tree?

Not yet in the Linus' tree, I'll let you know when it's merged.

Quoted 20 lines · Rafael J. Wysocki

Quoted 19 lines · Greg KH

Quoted 18 lines · Rafael J. Wysocki

Quoted 16 lines · Alan Jenkins

Quoted 5 lines · Len Brown

From: Alan Jenkins <[email protected]>

Make sure we can tell if the GPE storm workaround gets activated, and avoid flooding the logs afterwards.

Quoted 8 lines

http://bugzilla.kernel.org/show_bug.cgi?id=11841
"plenty of line "ACPI: EC: non-query interrupt received,
switching to interrupt mode" in dmesg"

Signed-off-by Alan Jenkins <[email protected]>

Acked-by Alexey Starikovskiy <[email protected]>

Signed-off-by Len Brown <[email protected]>

I see the EC patches that cause this issue are part of 2.6.27-stable. So I think this patch should also be applied to the -stable tree.

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

Good point, it should.

Ok, what is the git commit id that should be added to the .27-stable tree?

Not yet in the Linus' tree, I'll let you know when it's merged.

Thank you for doing this.

Quoted 21 lines · Greg KH

Quoted 20 lines · Rafael J. Wysocki

Quoted 19 lines · Greg KH

Quoted 18 lines · Rafael J. Wysocki

Quoted 16 lines · Alan Jenkins

Quoted 5 lines · Len Brown

From: Alan Jenkins <[email protected]>

Make sure we can tell if the GPE storm workaround gets activated, and avoid flooding the logs afterwards.

Quoted 8 lines

http://bugzilla.kernel.org/show_bug.cgi?id=11841
"plenty of line "ACPI: EC: non-query interrupt received,
switching to interrupt mode" in dmesg"

Signed-off-by Alan Jenkins <[email protected]>

Acked-by Alexey Starikovskiy <[email protected]>

Signed-off-by Len Brown <[email protected]>

I see the EC patches that cause this issue are part of 2.6.27-stable. So I think this patch should also be applied to the -stable tree.

Quoted 8 lines

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

Good point, it should.

Ok, what is the git commit id that should be added to the .27-stable tree?

Not yet in the Linus' tree, I'll let you know when it's merged.

Thank you for doing this.

Here:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f8248434e6a11d7cd314281be3b39bbcf82fc243

The other EC patches in this merge are also regarded as -stable material, but let's wait a couple of days to avoid possible regressions (although Alex thinks there sould be none ;-)).

please speak up if you see any reason these
pathces should not go into 2.6.28-rc3.

You still did not include video brightness patches from Thomas; nor are they in acpi-test. Are they delayed for -29 or rejected? If they are rejected it would be nice to know why so we could fix them ...