LinuxQuestions.org - Patching kernel for Acer Travelmate C100

- Ubuntu (https://www.linuxquestions.org/questions/ubuntu-63/)

- - Patching kernel for Acer Travelmate C100 (https://www.linuxquestions.org/questions/ubuntu-63/patching-kernel-for-acer-travelmate-c100-547332/)

Patching kernel for Acer Travelmate C100

I finally got around to pulling my old Acer Travelmate C100 (an original Tablet PC!) out of storage and installing Kubuntu 6.10 on it, and it works like a charm, tablet functionality and all.

The problem is, the battery status doesn't work-- it says no battery is even connected. I'm apparently not the only person with this problem. On the Acer Travelmate C100 page on the Gentoo wiki, someone said:

Quote:

It was a hard fight to let the kernel accept ACPI support for my C100, it seems that its RSDP checksum is invalid and the kernel refuses to enable ACPI support because of this. Dean Townsley provided a patch forcing the kernel to use a more sophisticated routine to detect the ACPI data tables (it seems that there are two different functions existing) and voila - it works. While Ubuntu 6.06's Live CD accounts for this ACPI problem, an actual installation remains ignorant of the matter.

(emphasis mine) This is exactly what I encountered as well-- it worked on the Live CD, so I assumed it would on the install.

The patch they list to fix it is pretty short, but targeted against an older kernel.

What would be the easiest way to apply a similar fix to a 2.6.17 kernel? I'm good enough at linux to follow the howtos (like this one) to compile my own kernel, but not good enough to author a new diff file.

If anyone can help or has other ideas, I'd love to hear it. Thank you!

--
Paradoxdruid

Quote:

Originally Posted by paradoxdruid

What would be the easiest way to apply a similar fix to a 2.6.17 kernel? I'm good enough at linux to follow the howtos (like this one) to compile my own kernel, but not good enough to author a new diff file.
--
Paradoxdruid

Well, as the patch seems not compatible; either you try on a mailing list related to acpi.
Or ubuntu as you seem to have tracked an easy way?
Or you author a new diff file...
The patch doesn't seem THAT complicated (I know it's relative but here you want to add linux support to something that has windows initially.. it is called hacking.. challenging) If you have a bit of experience in C, it should be possible; the hardest part has been done.
Print the patch, study it. Print the current arch/i386/kernel/acpi/boot.c and see how you can inject the patch in this file.
If you have no experience in C, you need to learn C.
Also you need to understand patch format (not hard at all).
-- means lines removed
++ means lines added
other ones are lines so that patch can resynchronise on fix lines.

Otherwise, keep your running kernel?

Why not just use a 2.6.11 kernel and patch that?

You could try the patch against the 2.6.17 kernel. If the line numbers in the diff file don't match, patch scans both forwards and backwards for a set of lines matching the context given in the hunk. Maybe you'll get lucky and you've got nothing to lose.

The patch is pretty small, you could probably apply it by hand without much problem. This part tells you which file is affected

Code:

+++ linux-2.6.11/arch/i386/kernel/acpi/boot.c

This line tells you which lines in the original file are affected. Lines 506-533 beginning at line 506 in the original file becomes lines 506-512 in the new file. In other words, there were 21 lines removed from the original file.

Code:

@@ -506,27 +506,6 @@

The - shows the lines that were removed from the original file and the + shows what was added.

If you are successful at making the changes to the 2.6.17 kernel code, this will create a new patch that you can then share with the community

Code:

diff -Naur [old_file...] [new_file...] > [patch_name...].patch

Hummm
Try it but I'm pessimistic...

I ignored a bit this part

Quote:

This is exactly what I encountered as well-- it worked on the Live CD, so I assumed it would on the install.

Make a copy of your problematic /boot/vmlinuz... and /lib/modules/2.6xxx
Copy the vmlinuz and /lib/modules/2.6xxx from the CD to the disk.
Pray & Reboot

Quote:

Originally Posted by Arow

You could try the patch against the 2.6.17 kernel. If the line numbers in the diff file don't match, patch scans both forwards and backwards for a set of lines matching the context given in the hunk. Maybe you'll get lucky and you've got nothing to lose.

No luck, unfortunately. Many of the hunks fail.

Quote:

The patch is pretty small, you could probably apply it by hand without much problem. This part tells you which file is affected

Code:

+++ linux-2.6.11/arch/i386/kernel/acpi/boot.c

Code:

@@ -506,27 +506,6 @@

The - shows the lines that were removed from the original file and the + shows what was added.

Thanks for the help. I know most of the diff schema, but I didn't understand the @@ markers. I'll try applying it by hand.

Side note, I double-posted this thread to the Ubuntu subforum because I wasn't sure where the best fit was. A moderator closed that thread, so I can't apologize there. But I didn't mean to forum spam!

Thanks for all the help so far, everyone!

Quote:

Originally Posted by paradoxdruid

A moderator closed that thread, so I can't apologize there. But I didn't mean to forum spam!

Standard rule. They can't differenciate between spam and non-spam..
I thought posting an an ubuntu-only forum. Probably that there are more ubuntu gurus overthere..
An idea (if I understood well that one kernel works)
If you take my debian source kernel, it comes like this:
vanilla kernel
+
list of patches

Try to get the source package of your working kernel, maybe you get the patch already done?

:twocents:

Have fun!

I did it!

I manually applied the patch that Dean Townsley wrote (from the Gentoo Hardware Wiki) to the linux-source-2.6.20 from the Ubuntu repositories.

After making my kernel packages and installing them, it works like a charm-- now I see battery status, and I can control the dynamic CPU frequency changes.

So I followed your instructions to turn my changes into a patch file to share with the community, attached below. I'll see if I can get it to the Acer Travelmate C100 pages across the web.

Quote:

--- linux-source-2.6.20/arch/i386/kernel/acpi/boot.c 2007-04-12 10:15:46.000000000 -0700
+++ linux/arch/i386/kernel/acpi/boot.c 2007-04-22 10:21:34.000000000 -0700
@@ -600,24 +600,7 @@

EXPORT_SYMBOL(acpi_unregister_ioapic);

-static unsigned long __init
-acpi_scan_rsdp(unsigned long start, unsigned long length)
-{
- unsigned long offset = 0;
- unsigned long sig_len = sizeof("RSD PTR ") - 1;

- /*
- * Scan all 16-byte boundaries of the physical memory region for the
- * RSDP signature.
- */
- for (offset = 0; offset < length; offset += 16) {
- if (strncmp((char *)(phys_to_virt(start) + offset), "RSD PTR ", sig_len))
- continue;
- return (start + offset);
- }
-
- return 0;
-}

static int __init acpi_parse_sbf(unsigned long phys_addr, unsigned long size)
{
@@ -753,21 +736,11 @@

unsigned long __init acpi_find_rsdp(void)
{
+ struct acpi_pointer addr;
unsigned long rsdp_phys = 0;

- if (efi_enabled) {
- if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
- return efi.acpi20;
- else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
- return efi.acpi;
- }
- /*
- * Scan memory looking for the RSDP signature. First search EBDA (low
- * memory) paragraphs and then search upper memory (E0000-FFFFF).
- */
- rsdp_phys = acpi_scan_rsdp(0, 0x400);
- if (!rsdp_phys)
- rsdp_phys = acpi_scan_rsdp(0xE0000, 0x20000);
+ if (!ACPI_FAILURE(acpi_find_root_pointer(ACPI_PHYSICAL_ADDRESSING,&addr)))
+ rsdp_phys=addr.pointer.physical;

return rsdp_phys;
}

--- linux-source-2.6.20/arch/i386/mach-es7000/es7000plat.c 2007-04-12 10:15:46.000000000 -0700
+++ linux/arch/i386/mach-es7000/es7000plat.c 2007-04-22 10:25:08.000000000 -0700
@@ -35,6 +35,7 @@
#include <linux/reboot.h>
#include <linux/init.h>
#include <linux/acpi.h>
+#include <linux/efi.h>
#include <asm/io.h>
#include <asm/nmi.h>
#include <asm/smp.h>
@@ -91,6 +92,52 @@
ioapic_renumber_irq = es7000_rename_gsi;
}

+
+ static unsigned long __init
+ es7000_acpi_scan_rsdp (
+ unsigned long start,
+ unsigned long length)
+ {
+ unsigned long offset = 0;
+ unsigned long sig_len = sizeof("RSD PTR ") - 1;
+
+ /*
+ * Scan all 16-byte boundaries of the physical memory region for the
+ * RSDP signature.
+ */
+ for (offset = 0; offset < length; offset += 16) {
+ if (strncmp((char *) (start + offset), "RSD PTR ", sig_len))
+ continue;
+ return (start + offset);
+ }
+
+ return 0;
+ }
+
+
+ unsigned long __init
+ es7000_acpi_find_rsdp (void)
+ {
+ unsigned long rsdp_phys = 0;
+
+ if (efi_enabled) {
+ if (efi.acpi20)
+ return __pa(efi.acpi20);
+ else if (efi.acpi)
+ return __pa(efi.acpi);
+ }
+ /*
+ * Scan memory looking for the RSDP signature. First search EBDA (low
+ * memory) paragraphs and then search upper memory (E0000-FFFFF).
+ */
+ rsdp_phys = es7000_acpi_scan_rsdp (0, 0x400);
+ if (!rsdp_phys)
+ rsdp_phys = es7000_acpi_scan_rsdp (0xE0000, 0xFFFFF);
+
+ return rsdp_phys;
+ }
+
+
/*
* Parse the OEM Table
*/
@@ -166,7 +213,8 @@
int i;
struct acpi_table_sdt sdt;

- rsdp_phys = acpi_find_rsdp();
+ /* FIXME -- can we use the general acpi_find_rsdp() ? */
+ rsdp_phys = es7000_acpi_find_rsdp();
rsdp = __va(rsdp_phys);
if (rsdp->rsdt_address) {
struct acpi_table_rsdt *mapped_rsdt = NULL;

Not really much work at all-- the only reason that Dean's patch wouldn't still work is that the context cues in his patch file aren't current enough for patch to deduce where to make the changes.

Thanks for the help, all!

Told ya'. :) Thanks for helping the community.