LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   'add-delay-before-data-write' patch for Slackware 14 kernel (http://www.linuxquestions.org/questions/slackware-14/add-delay-before-data-write-patch-for-slackware-14-kernel-4175440552/)

saivnoba 12-08-2012 05:26 AM

'add-delay-before-data-write' patch for Slackware 14 kernel
 
Hi all,

I have issue with ACPI related thing in kernel (ec.c). It is discussed here (https://bugs.launchpad.net/ubuntu/+s...ux/+bug/578506) and here (https://bugzilla.kernel.org/show_bug.cgi?id=14733). I tried patches from here (https://bugzilla.kernel.org/attachment.cgi?id=73510) and here (https://bugzilla.kernel.org/attachment.cgi?id=25261) which seems latest. But both fail. Can you please help me with correct patch file for Slackware 14 kernel?

The long story for the interested :-p
=====================================
I have this issue for a long time (about 2yrs :-) now. I have Acer Aspire-4741 with standard configuration: 2.13GHz, 3MB L3 Cache i3 330M processor, 2GB RAM, Intel HD Graphics.

My problem is, if I use my laptop for long time (may be a usage which involves supend/resume?) and reboot, it takes ages to boot up. Not just the OS boot up. It takes about 4m to show the BIOS/Acer-logo screen. Then it takes about 8m to show the Grub screen. So, a typical (re)boot time is about 12-13m.

The solution, or rather a frustrating hack, is to remove the battery, power up the laptop with AC. If this fails, pull AC cord while it is only on AC (with battery removed) and insert again. If I insert battery again it will boot up normal first time until another long (enough) usage. I'm currently forced to use my laptop as a desktop.

I first noticed it in Ubuntu (forgot the version). Inspired(?) by all the *buntu bashing online, I also cursed it whole heartedly. I got the shock of my life when this happened with my Slackware install as well :-( I immediately repented my cursing of Ubuntu and started looking why it is happening.

After that I have noticed that this strange behavior is seen with both 32-bit and 64-bit linux and practically with all the distros I have used long enough (Debian, Ubuntu, Mint, Fedora, CentOS, openSUSE, Arch, Slackware).

I now know that this is related to ACPI and battery state. The dmesg spews a lot of message related to this. Here is an excerpt:
Code:

[45533.544483] ACPI Error: Evaluating _BCM failed (20110623/video-364)
[45832.406114] ACPI: EC: input buffer is not empty, aborting transaction
[45832.406123] ACPI Exception: AE_TIME, Returned by Handler for
[EmbeddedControl] (20110623/evregion-478)
[45832.406139] ACPI Error: Method parse/execution failed
[\_SB_.PCI0.GFX0.DD02._BCM] (Node ffff88006c85e050), AE_TIME
(20110623/psparse-536)
[45832.406164] ACPI Error: Evaluating _BCM failed (20110623/video-364)
[45832.905907] ACPI: EC: input buffer is not empty, aborting transaction
[45832.905915] ACPI Exception: AE_TIME, Returned by Handler for
[EmbeddedControl] (20110623/evregion-478)
[45832.905930] ACPI Error: Method parse/execution failed
[\_SB_.PCI0.GFX0.DD02._BCM] (Node ffff88006c85e050), AE_TIME
(20110623/psparse-536)
[45832.905953] ACPI Error: Evaluating _BCM failed (20110623/video-364)
[48843.274900] ACPI: EC: input buffer is not empty, aborting transaction
[48843.274906] ACPI Exception: AE_TIME, Returned by Handler for
[EmbeddedControl] (20110623/evregion-478)
[48843.274915] ACPI Error: Method parse/execution failed
[\_SB_.PCI0.GFX0.DD02._BCM] (Node ffff88006c85e050), AE_TIME
(20110623/psparse-536)
[48843.274932] ACPI Error: Evaluating _BCM failed (20110623/video-364)
[48843.775732] ACPI: EC: input buffer is not empty, aborting transaction
[48843.775739] ACPI Exception: AE_TIME, Returned by Handler for
[EmbeddedControl] (20110623/evregion-478)
[48843.775752] ACPI Error: Method parse/execution failed
[\_SB_.PCI0.GFX0.DD02._BCM] (Node ffff88006c85e050), AE_TIME
(20110623/psparse-536)
[48843.775770] ACPI Error: Evaluating _BCM failed (20110623/video-364)
[48844.275520] ACPI: EC: input buffer is not empty, aborting transaction
[48844.275525] ACPI Exception: AE_TIME, Returned by Handler for
[EmbeddedControl] (20110623/evregion-478)
[48844.275535] ACPI Error: Method parse/execution failed
[\_SB_.PCI0.GFX0.DD02._BCM] (Node ffff88006c85e050), AE_TIME
(20110623/psparse-536)
[48844.275549] ACPI Error: Evaluating _BCM failed (20110623/video-364)

This is not the full error message all the time but one common sentence in all of them is "[numbers.numbers] ACPI: EC: input buffer is not empty, aborting transaction"

As stated above, there is a discussion on launchpad and kernel bugzilla regarding this issue. As per discussion we need to patch ec.c file with a 'Add delay before data write' patch. Some report success. Some other report success as for this problem is concerned but say it breaks other parts of the system.

Anyway, I decided to try my luck with the patch. I obtained the diff from https://bugzilla.kernel.org/attachment.cgi?id=25261. It seems to be latest but don't know how to check if it applies to 3.2 kernel.

I tried
Code:

patch -p1 < ~/Downloads/ec-add-delay-patch.diff
but it fails with error
Code:

bash-4.2$ patch -p1 < ~/Documents/ec-add-delay-patch.diff
patching file drivers/acpi/ec.c
Hunk #1 succeeded at 222 (offset -4 lines).
Hunk #2 succeeded at 230 (offset -4 lines).
Hunk #3 FAILED at 272.
1 out of 3 hunks FAILED -- saving rejects to file drivers/acpi/ec.c.rej

My ec.c.rej file reads as
Code:

--- drivers/acpi/ec.c
+++ drivers/acpi/ec.c
@@ -272,15 +273,25 @@
        return (status & ACPI_EC_FLAG_IBF) == 0;
 }
 
+/* try to clean input buffer with burst_disable transaction */
+static int acpi_ec_clean_buffer(struct acpi_ec *ec)
+{
+        struct transaction t = {.command = ACPI_EC_BURST_DISABLE,
+                                .wdata = NULL, .rdata = NULL,
+                                .wlen = 0, .rlen = 0};
+        return acpi_ec_transaction_unlocked(ec, &t);
+}
+
 static int ec_wait_ibf0(struct acpi_ec *ec)
 {
+       
        unsigned long delay = jiffies + msecs_to_jiffies(ACPI_EC_DELAY);
        /* interrupt wait manually if GPE mode is not active */
        while (time_before(jiffies, delay))
                if (wait_event_timeout(ec->wait, ec_check_ibf0(ec),
                                        msecs_to_jiffies(1)))
                        return 0;
-        return -ETIME;
+        return acpi_ec_clean_buffer(ec);
 }
 
 static int acpi_ec_transaction(struct acpi_ec *ec, struct transaction *t)

Request help with obtaining correct patch file for Slackware 14 kernel. Also, any tips on patching. I've compiled kernels before but this would be my first patching.

Thanks,
SV

ml4711 12-08-2012 08:33 AM

drivers/acpi/ec.c

in the function
static int ec_wait_ibf0(struct acpi_ec *ec)

unsigned long delay = jiffies + msecs_to_jiffies(ACPI_EC_DELAY);

has been changed to:

unsigned long delay = jiffies + msecs_to_jiffies(ec_delay);

(Se definition of ec_delay in line 86)

Just run this on your patch, and you can apply it without errors

Code:

sed -i 's|ACPI_EC_DELAY|ec_delay|g' ec-add-delay-patch.diff

saivnoba 12-13-2012 11:40 AM

Hi ml4711, sorry for the late reply. I tried your method. Instead of failing saying "Hunk #3 FAILED at 272." it now fails at 271.

ml4711 12-13-2012 01:15 PM

Strange, after running the sed command on the patch
I get this when I apply the patch

Code:

ml4711@ml9:/usr/src/linux-3.2.29$ patch -p1 </usr/local/src/ec-add-delay-patch.diff
patching file drivers/acpi/ec.c
Hunk #1 succeeded at 222 (offset -4 lines).
Hunk #2 succeeded at 230 (offset -4 lines).
Hunk #3 succeeded at 268 (offset -4 lines).

The sed command,
the only thing it does is replacing ACPI_EC_DELAY with ec_delay
at line 40 in the patch

Tried both with kernel 3.2.23 and 3.2.29

saivnoba 12-14-2012 01:24 AM

This is strange. I tried it today (almost) exactly the way I tried before and this time it succeeded just as in your post.
Code:

root@slackware:/usr/src/linux# patch -p1 < /home/saivnoba/Documents/ec-add-delay-patch.diff
patching file drivers/acpi/ec.c
Hunk #1 succeeded at 222 (offset -4 lines).
Hunk #2 succeeded at 230 (offset -4 lines).
Hunk #3 succeeded at 268 (offset -4 lines).

The only difference is, last time I tried from my home directory as myself and this time I tried from /usr/src/linux as root. Does that make a big difference? It is 'recommended' to compile kernel from $HOME as $USER right?!

I'm compiling the patched kernel now and will update you if this fixes my problem.

Thanks, SV

saivnoba 12-15-2012 02:18 AM

Hi, this is to update on previous post. I'm currently running my patched kernel named 3.2.29-sv and the ACPI issue has disappeared. Atlast, I'm able to use my laptop as laptop and not just as desktop running on AC power.

But my original question still remains. Where do I get the correct patch for every kernel release? Slackware does not keep updating kernels much so no problem here. But I multiboot and have the same issue with all other distros on this laptop. From where can I get the relevant patches for those kernels?

Thanks, SV

ml4711 12-15-2012 06:16 AM

At the bottom af this link:

https://bugzilla.kernel.org/show_bug.cgi?id=14733

Quote:

Comment #83 From pcxz 2012-06-05 08:38:28
Created an attachment (id=73510) [details]
ec.diff patch

work with all 3.3.* version, apply ok also in 3.4.1
But It's not different from the one that worked for you, so you now already have a patch, that works for at least up to kernel 3.4.1, and for old kernels, the original patch (the one with "ACPI_EC_DELAY" instead of "ec_delay") may work for those.

saivnoba 12-20-2012 08:52 AM

Hi ml4711,

Just was curious how those guys generate the diff for each kernel release. Not all of them are coders who wrote that patch. Anyway, I've subscribed to those bug-reports and following them. That way I can get patches from there. Thanks for your help.

-SV


All times are GMT -5. The time now is 01:57 PM.