Re: HPET regression in 2.6.26 versus 2.6.25 -- experimental revert for 2.6.27 failed

Re: HPET regression in 2.6.26 versus 2.6.25 -- experimental revert for 2.6.27 failed

[David Witbrodt]

SUMMARY

1.  Ran 'git remote update', then built kernels for origin/master
(Linus' linux-2.6 tree) and tip/master.  Both froze.

2.  Attempted a revert against tip/master, but the files involved
changed quite a bit.  I _was_ able to build the kernel successfully,
but it froze.  There have simply been too many changes since Feb. 22
for my naive approach to work.

3.  When the revert failed, I panicked:  I thought that I might
truly have made a mistake with the original 'git bisect' process
I carried out.  After retracing the last few iterations of the
process -- building and checking the last 3 kernels -- I found
that the information I posted here WAS correct:  the problem
commit # was the one I had found the first time.

4.  To see if I am totally incompetent, I used git to checkout the
version of the sources at the problem commit, and then reverted
those changes (same method used in step 2).  The kernel built
and ran just fine:  no freeze, no need for "hpet=disabled".


DETAILS

Here is some git output showing the changes I made.  My approach was
extremely naive, but since I have very little or no understanding of
the code itself, no other approach was possible for me:

====== BEGIN git OUTPUT ==========

$ git show
commit e10eb6518a3a08598344d477137cbdd25e85571d
Merge: b4141ac... 45fc3c4...
Author: Ingo Molnar <mingo@elte.hu>
Date:   Tue Aug 12 19:43:39 2008 +0200

    Merge branch 'linus'

$ git diff
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 9af8907..131d6f7 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1267,7 +1267,9 @@ static inline const char *e820_type_to_string(int e820_type)
 /*
  * Mark e820 reserved areas as busy for the resource manager.
  */
-void __init e820_reserve_resources(void)
+/* void __init e820_reserve_resources(void) */
+void __init e820_reserve_resources(struct resource *code_resource,
+        struct resource *data_resource, struct resource *bss_resource)
 {
     int i;
     struct resource *res;
@@ -1287,7 +1289,22 @@ void __init e820_reserve_resources(void)
         res->end = end;
 
         res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
-        insert_resource(&iomem_resource, res);
+        request_resource(&iomem_resource, res);
+        if (e820.map[i].type == E820_RAM) {
+            /*
+             * We don't know which RAM region contains kernel data,
+             * so we try it repeatedly and let the resource manager
+             * test it.
+             */
+            request_resource(res, code_resource);
+            request_resource(res, data_resource);
+            request_resource(res, bss_resource);
+#ifdef CONFIG_KEXEC
+            if (crashk_res.start != crashk_res.end)
+                request_resource(res, &crashk_res);
+#endif
+        }
+        /* insert_resource(&iomem_resource, res); */
         res++;
     }
 
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 59f07e1..5972d13 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -517,7 +517,7 @@ static void __init reserve_crashkernel(void)
 
     crashk_res.start = crash_base;
     crashk_res.end   = crash_base + crash_size - 1;
-    insert_resource(&iomem_resource, &crashk_res);
+    /* insert_resource(&iomem_resource, &crashk_res); */
 }
 #else
 static void __init reserve_crashkernel(void)
@@ -700,9 +700,9 @@ void __init setup_arch(char **cmdline_p)
 #endif
 
     /* after parse_early_param, so could debug it */
-    insert_resource(&iomem_resource, &code_resource);
-    insert_resource(&iomem_resource, &data_resource);
-    insert_resource(&iomem_resource, &bss_resource);
+    /* insert_resource(&iomem_resource, &code_resource); */
+    /* insert_resource(&iomem_resource, &data_resource); */
+    /* insert_resource(&iomem_resource, &bss_resource); */
 
     if (efi_enabled)
         efi_init();
@@ -865,7 +865,7 @@ void __init setup_arch(char **cmdline_p)
 
     kvm_guest_init();
 
-    e820_reserve_resources();
+    e820_reserve_resources(&code_resource, &data_resource, &bss_resource);
     e820_mark_nosave_regions(max_low_pfn);
 
 #ifdef CONFIG_X86_32
diff --git a/include/asm-x86/e820.h b/include/asm-x86/e820.h
index f52daf1..57f0c67 100644
--- a/include/asm-x86/e820.h
+++ b/include/asm-x86/e820.h
@@ -47,6 +47,8 @@
 /* reserved RAM used by kernel itself */
 #define E820_RESERVED_KERN        128
 
+#include <linux/ioport.h>
+
 #ifndef __ASSEMBLY__
 struct e820entry {
     __u64 addr;    /* start of memory segment */
@@ -120,7 +122,8 @@ extern void e820_register_active_regions(int nid, unsigned long start_pfn,
                      unsigned long end_pfn);
 extern u64 e820_hole_size(u64 start, u64 end);
 extern void finish_e820_parsing(void);
-extern void e820_reserve_resources(void);
+extern void e820_reserve_resources(struct resource *code_resource,
+        struct resource *data_resource, struct resource *bss_resource);
 extern void setup_memory_map(void);
 extern char *default_machine_specific_memory_setup(void);
 extern char *machine_specific_memory_setup(void);
====== END git OUTPUT ==========


The #include of linux/ioport.h was not part of the problem commit, but
the changes since Feb. 22 were such that I was forced to add that line
myself to make it possible to build.

In many cases the lines near the changes in this attempted revert were
quite different from those in the diff from the problem commit, so there
was very little chance for me to succeed, I suspect.


For my own peace of mind, I went back to the bisecting to verify that the
commit I have previously identified was really correct.  Results:

==========
$ git checkout 1e934dda0c77c8ad13fdda02074f2cfcea118a56
Previous HEAD position was e10eb65... Merge branch 'linus'
Checking out files: 100% (17901/17901), done.
HEAD is now at 1e934dd... x86: insert_resorce for lapic addr after e820_reserve_resources

$ git bisect start
$ git bisect bad
$ git checkout 322850af8d93735f67b8ebf84bb1350639be3f34
Previous HEAD position was 1e934dd... x86: insert_resorce for lapic addr after e820_reserve_resources
HEAD is now at 322850a... x86: make amd quad core 8 socket system not be clustered_box, #2

$ git bisect good
Bisecting: 1 revisions left to test after this
[3def3d6ddf43dbe20c00c3cbc38dfacc8586998f] x86: clean up e820_reserve_resources on 64-bit

$ git bisect bad
Bisecting: 0 revisions left to test after this
[700efc1b9f6afe34caae231b87d129ad8ffb559f] x86: introduce kernel/head32.c
dawitbro@fileserver:~/sandbox/git-kernel/linux-2.6$ git bisect good
3def3d6ddf43dbe20c00c3cbc38dfacc8586998f is first bad commit
commit 3def3d6ddf43dbe20c00c3cbc38dfacc8586998f
Author: Yinghai Lu <Yinghai.Lu@Sun.COM>
Date:   Fri Feb 22 17:07:16 2008 -0800

    x86: clean up e820_reserve_resources on 64-bit
    
    e820_resource_resources could use insert_resource instead of request_resource
    also move code_resource, data_resource, bss_resource, and crashk_res
    out of e820_reserve_resources.
    
    Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

:040000 040000 79fea1b27a7affdf269cd55f633d495d1cac9513 abcad2c76947ba30fa0c94e0a9dcabd5d8666d28 M    arch
:040000 040000 5d0b70980ad3692c9fa75ab67a3a43f1aa7807ce a5714997f2337541581dee96f19b7fe86c7941dc M    include
==========

I cannot describe how much relief I felt upon seeing that.

Since my main goal was to troubleshoot the Debian 2.6.26 stock kernel, my
next experiments will be to see if I can get a reversion to work against
any version in the 2.6.26-rc* line, and hopefully the 2.6.26 release 
itself.


DW

Re: HPET regression in 2.6.26 versus 2.6.25 -- experimental revert for 2.6.27 failed

[Yinghai Lu]

On Tue, Aug 12, 2008 at 5:00 PM, David Witbrodt <dawitbro@sbcglobal.net> wrote:
> SUMMARY
>
> 1.  Ran 'git remote update', then built kernels for origin/master
> (Linus' linux-2.6 tree) and tip/master.  Both froze.
>
> 2.  Attempted a revert against tip/master, but the files involved
> changed quite a bit.  I _was_ able to build the kernel successfully,
> but it froze.  There have simply been too many changes since Feb. 22
> for my naive approach to work.
>
> 3.  When the revert failed, I panicked:  I thought that I might
> truly have made a mistake with the original 'git bisect' process
> I carried out.  After retracing the last few iterations of the
> process -- building and checking the last 3 kernels -- I found
> that the information I posted here WAS correct:  the problem
> commit # was the one I had found the first time.
>
> 4.  To see if I am totally incompetent, I used git to checkout the
> version of the sources at the problem commit, and then reverted
> those changes (same method used in step 2).  The kernel built
> and ran just fine:  no freeze, no need for "hpet=disabled".

can you post /proc/iomem?

YH

Re: HPET regression in 2.6.26 versus 2.6.25 -- experimental revert for 2.6.27 failed

[David Witbrodt]

> can you post /proc/iomem?

Gladly.

I wasn't sure which kernel you would like me to use, so I chose a 
sample of 3:

1.  linux-2.6.25 (from git) just before the commit causing the lockups
2.  linux-2.6.26 (with "hpet=disabled")
3.  Debian stock 2.6.26 ("linux-image-2.6.26-1-amd64", also with HPET
disabled)


Using 2.6.25 at the commit before the one that caused lockups:

$ cat /proc/iomem
00000000-0009f3ff : System RAM
0009f400-0009ffff : reserved
000f0000-000fffff : reserved
00100000-77fdffff : System RAM
  00200000-0056ca21 : Kernel code
  0056ca22-006ce3d7 : Kernel data
  00753000-0079a3c7 : Kernel bss
77fe0000-77fe2fff : ACPI Non-volatile Storage
77fe3000-77feffff : ACPI Tables
77ff0000-77ffffff : reserved
78000000-7fffffff : pnp 00:0d
d8000000-dfffffff : PCI Bus #01
  d8000000-dfffffff : 0000:01:05.0
    d8000000-d8ffffff : uvesafb
e0000000-efffffff : PCI MMCONFIG 0
  e0000000-efffffff : reserved
fdc00000-fdcfffff : PCI Bus #02
  fdcff000-fdcff0ff : 0000:02:05.0
    fdcff000-fdcff0ff : r8169
fdd00000-fdefffff : PCI Bus #01
  fdd00000-fddfffff : 0000:01:05.0
  fdee0000-fdeeffff : 0000:01:05.0
  fdefc000-fdefffff : 0000:01:05.2
    fdefc000-fdefffff : ICH HD audio
fdf00000-fdffffff : PCI Bus #02
fe020000-fe023fff : 0000:00:14.2
  fe020000-fe023fff : ICH HD audio
fe029000-fe0290ff : 0000:00:13.5
  fe029000-fe0290ff : ehci_hcd
fe02a000-fe02afff : 0000:00:13.4
  fe02a000-fe02afff : ohci_hcd
fe02b000-fe02bfff : 0000:00:13.3
  fe02b000-fe02bfff : ohci_hcd
fe02c000-fe02cfff : 0000:00:13.2
  fe02c000-fe02cfff : ohci_hcd
fe02d000-fe02dfff : 0000:00:13.1
  fe02d000-fe02dfff : ohci_hcd
fe02e000-fe02efff : 0000:00:13.0
  fe02e000-fe02efff : ohci_hcd
fe02f000-fe02f3ff : 0000:00:12.0
  fe02f000-fe02f3ff : ahci
fec00000-fec00fff : IOAPIC 0
  fec00000-fec00fff : pnp 00:0d
fed00000-fed003ff : HPET 0
  fed00000-fed003ff : 0000:00:14.0
fee00000-fee00fff : Local APIC
fff80000-fffeffff : pnp 00:0d
ffff0000-ffffffff : pnp 00:0d


Using 2.6.26 (custom compiled) with "hpet=disabled"

00000000-0009f3ff : System RAM
0009f400-0009ffff : reserved
000f0000-000fffff : reserved
00100000-77fdffff : System RAM
  00200000-0057358d : Kernel code
  0057358e-006d8e9f : Kernel data
  0076e000-007b7447 : Kernel bss
77fe0000-77fe2fff : ACPI Non-volatile Storage
77fe3000-77feffff : ACPI Tables
77ff0000-77ffffff : reserved
78000000-7fffffff : pnp 00:0d
80000000-800003ff : 0000:00:14.0
d8000000-dfffffff : PCI Bus 0000:01
  d8000000-dfffffff : 0000:01:05.0
    d8000000-d8ffffff : uvesafb
e0000000-efffffff : PCI MMCONFIG 0
  e0000000-efffffff : reserved
fdc00000-fdcfffff : PCI Bus 0000:02
  fdcff000-fdcff0ff : 0000:02:05.0
    fdcff000-fdcff0ff : r8169
fdd00000-fdefffff : PCI Bus 0000:01
  fdd00000-fddfffff : 0000:01:05.0
  fdee0000-fdeeffff : 0000:01:05.0
  fdefc000-fdefffff : 0000:01:05.2
    fdefc000-fdefffff : ICH HD audio
fdf00000-fdffffff : PCI Bus 0000:02
  fdf00000-fdf1ffff : 0000:02:05.0
fe020000-fe023fff : 0000:00:14.2
  fe020000-fe023fff : ICH HD audio
fe029000-fe0290ff : 0000:00:13.5
  fe029000-fe0290ff : ehci_hcd
fe02a000-fe02afff : 0000:00:13.4
  fe02a000-fe02afff : ohci_hcd
fe02b000-fe02bfff : 0000:00:13.3
  fe02b000-fe02bfff : ohci_hcd
fe02c000-fe02cfff : 0000:00:13.2
  fe02c000-fe02cfff : ohci_hcd
fe02d000-fe02dfff : 0000:00:13.1
  fe02d000-fe02dfff : ohci_hcd
fe02e000-fe02efff : 0000:00:13.0
  fe02e000-fe02efff : ohci_hcd
fe02f000-fe02f3ff : 0000:00:12.0
  fe02f000-fe02f3ff : ahci
fec00000-ffffffff : reserved
  fec00000-fec00fff : IOAPIC 0
  fed00000-fed003ff : HPET 0
  fee00000-fee00fff : Local APIC


Using Debian stock kernel

00000000-0009f3ff : System RAM
0009f400-0009ffff : reserved
000f0000-000fffff : reserved
00100000-77fdffff : System RAM
  00200000-0042c443 : Kernel code
  0042c444-0053a677 : Kernel data
  005de000-00673317 : Kernel bss
77fe0000-77fe2fff : ACPI Non-volatile Storage
77fe3000-77feffff : ACPI Tables
77ff0000-77ffffff : reserved
78000000-7fffffff : pnp 00:0d
80000000-800003ff : 0000:00:14.0
d8000000-dfffffff : PCI Bus 0000:01
  d8000000-dfffffff : 0000:01:05.0
e0000000-efffffff : PCI MMCONFIG 0
  e0000000-efffffff : reserved
fdc00000-fdcfffff : PCI Bus 0000:02
  fdcff000-fdcff0ff : 0000:02:05.0
    fdcff000-fdcff0ff : r8169
fdd00000-fdefffff : PCI Bus 0000:01
  fdd00000-fddfffff : 0000:01:05.0
  fdee0000-fdeeffff : 0000:01:05.0
  fdefc000-fdefffff : 0000:01:05.2
    fdefc000-fdefffff : ICH HD audio
fdf00000-fdffffff : PCI Bus 0000:02
  fdf00000-fdf1ffff : 0000:02:05.0
fe020000-fe023fff : 0000:00:14.2
  fe020000-fe023fff : ICH HD audio
fe029000-fe0290ff : 0000:00:13.5
  fe029000-fe0290ff : ehci_hcd
fe02a000-fe02afff : 0000:00:13.4
  fe02a000-fe02afff : ohci_hcd
fe02b000-fe02bfff : 0000:00:13.3
  fe02b000-fe02bfff : ohci_hcd
fe02c000-fe02cfff : 0000:00:13.2
  fe02c000-fe02cfff : ohci_hcd
fe02d000-fe02dfff : 0000:00:13.1
  fe02d000-fe02dfff : ohci_hcd
fe02e000-fe02efff : 0000:00:13.0
  fe02e000-fe02efff : ohci_hcd
fe02f000-fe02f3ff : 0000:00:12.0
  fe02f000-fe02f3ff : ahci
fec00000-ffffffff : reserved
  fec00000-fec00fff : IOAPIC 0
  fed00000-fed003ff : HPET 0
  fee00000-fee00fff : Local APIC


Please let me know anything else I can provide, and which kernels you
would like me to run to provide it.


Dave W.

Re: HPET regression in 2.6.26 versus 2.6.25 -- experimental revert for 2.6.27 failed

[Yinghai Lu]

[-- Attachment #1: Type: text/plain, Size: 62 bytes --]

please try attached patch with 2.6.27-rc3

Thanks

Yinghai Lu

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: revert_back_to_request.patch --]
[-- Type: text/x-patch; name=revert_back_to_request.patch, Size: 3716 bytes --]

[PATCH] x86: revert back to use request_resource to reserve kernel res

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>

---
 arch/x86/kernel/e820.c  |   17 +++++++++++++++--
 arch/x86/kernel/setup.c |   22 +++++++++++++++-------
 include/asm-x86/e820.h  |    3 ++-
 3 files changed, 32 insertions(+), 10 deletions(-)

Index: linux-2.6/arch/x86/kernel/e820.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820.c
+++ linux-2.6/arch/x86/kernel/e820.c
@@ -1267,7 +1267,7 @@ static inline const char *e820_type_to_s
 /*
  * Mark e820 reserved areas as busy for the resource manager.
  */
-void __init e820_reserve_resources(void)
+void __init e820_reserve_resources(struct resource **res_kernel, int nr_res_k)
 {
 	int i;
 	struct resource *res;
@@ -1287,7 +1287,20 @@ void __init e820_reserve_resources(void)
 		res->end = end;
 
 		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
-		insert_resource(&iomem_resource, res);
+		request_resource(&iomem_resource, res);
+		if (e820.map[i].type == E820_RAM) {
+			int j;
+			/*
+			* We don't know which RAM region contains kernel data,
+			* so we try it repeatedly and let the resource manager
+			* test it.
+			*/
+			for (j = 0; j < nr_res_k; j++) {
+				if (!res_kernel[j])
+					continue;
+				request_resource(res, res_kernel[j]);
+			}
+		}
 		res++;
 	}
 
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -437,6 +437,7 @@ static void __init reserve_early_setup_d
  * --------- Crashkernel reservation ------------------------------
  */
 
+static struct resource *crashk_res_ptr;
 #ifdef CONFIG_KEXEC
 
 /**
@@ -517,7 +518,7 @@ static void __init reserve_crashkernel(v
 
 	crashk_res.start = crash_base;
 	crashk_res.end   = crash_base + crash_size - 1;
-	insert_resource(&iomem_resource, &crashk_res);
+	crashk_res_ptr = &crashk_res;
 }
 #else
 static void __init reserve_crashkernel(void)
@@ -593,6 +594,9 @@ struct x86_quirks *x86_quirks __initdata
 
 void __init setup_arch(char **cmdline_p)
 {
+	struct resource *res_kernel[4];
+	int num_res;
+
 #ifdef CONFIG_X86_32
 	memcpy(&boot_cpu_data, &new_cpu_data, sizeof(new_cpu_data));
 	visws_early_detect();
@@ -699,11 +703,6 @@ void __init setup_arch(char **cmdline_p)
 	probe_roms();
 #endif
 
-	/* after parse_early_param, so could debug it */
-	insert_resource(&iomem_resource, &code_resource);
-	insert_resource(&iomem_resource, &data_resource);
-	insert_resource(&iomem_resource, &bss_resource);
-
 	if (efi_enabled)
 		efi_init();
 
@@ -865,7 +864,16 @@ void __init setup_arch(char **cmdline_p)
 
 	kvm_guest_init();
 
-	e820_reserve_resources();
+	res_kernel[0] = &code_resource;
+	res_kernel[1] = &data_resource;
+	res_kernel[2] = &bss_resource;
+	num_res = 3;
+	if (crashk_res_ptr) {
+		res_kernel[num_res] = crashk_res_ptr;
+		num_res++;
+	}
+	e820_reserve_resources(res_kernel, num_res);
+
 	e820_mark_nosave_regions(max_low_pfn);
 
 #ifdef CONFIG_X86_32
Index: linux-2.6/include/asm-x86/e820.h
===================================================================
--- linux-2.6.orig/include/asm-x86/e820.h
+++ linux-2.6/include/asm-x86/e820.h
@@ -120,7 +120,8 @@ extern void e820_register_active_regions
 					 unsigned long end_pfn);
 extern u64 e820_hole_size(u64 start, u64 end);
 extern void finish_e820_parsing(void);
-extern void e820_reserve_resources(void);
+struct resource;
+extern void e820_reserve_resources(struct resource **res, int num);
 extern void setup_memory_map(void);
 extern char *default_machine_specific_memory_setup(void);
 extern char *machine_specific_memory_setup(void);

Re: HPET regression in 2.6.26 versus 2.6.25 -- experimental revert for 2.6.27 failed

[David Witbrodt]

> please try attached patch with 2.6.27-rc3

Thx for the patch... and for providing it as an attachment.  My email
situation is less than optimal, and I am stuck using my ISP's web 
interface for the present.

I used 'git apply --check <patchfilename>' first, and got no errors, so
I applied it, built, installed, and rebooted.

The kernel froze in the same way as the others.


BTW, I saw a new last line of output -- which may or may not be
relevant -- but I thought I should mention it since I had never seen 
it before:

With the patched 2.6.27-rc3 kernel, I thought I saw some different 
output during the boot.  The messages were from pnp_system_init(), and 
had to do with not being able to use iomem ranges.  I rebooted one of 
my 2.6.26 kernels (with HPET enabled so it would freeze) so I could
compare the messages, and found that I was wrong:  the messages were not
new, and are probably normal.

However, each time one of these 2.6.2[67] kernels locks up, the last 
line on the screen is the (now familiar) inet_init() message:

NET: Registered protocol family 2


When I booted the older 2.6.26 kernel, I saw something I haven't seen
before:

Clocksource tsc unstable (delta = 4398046170281 ns)


Now, I have experienced aggravating TSC messages at boot ever since I built
my first AMD dual-core machine last year.  I researched the issue, I found
that I could use "notsc" to suppress the messages.  I have GRUB
automatically add the "notsc" parameter for my everyday-usage kernels, but
I have intentionally NOT been using "notsc" for any of the freezing kernels
about which I have been reporting information here.  (I have tried "notsc"
before as an experiment, but it does not prevent freezing.)

Getting a TSC message when not using "notsc" is no surprise.  I only mention
it because this is the first time I have seen that message as the last 
output line during a freeze.

Beware:  this TSC output happened just now with an older 2.6.26 kernel, not
with the patched 2.6.27-rc3 kernel... so it has nothing to do with the new
patch.  That time "delta" is ridiculous:  4398 seconds.  Total time from
GRUB to freeze is < 3 seconds.  It reminds me of info I posted before about
the pci_bios_assign_resources() initcall falsely reporting a return in 
285000+ msecs.


Thanks,
Dave W.

Re: HPET regression in 2.6.26 versus 2.6.25 -- experimental revert for 2.6.27 failed

[Yinghai Lu]

On Wed, Aug 13, 2008 at 5:03 AM, David Witbrodt <dawitbro@sbcglobal.net> wrote:
>
>
>> please try attached patch with 2.6.27-rc3
>
> Thx for the patch... and for providing it as an attachment.  My email
> situation is less than optimal, and I am stuck using my ISP's web
> interface for the present.
>
> I used 'git apply --check <patchfilename>' first, and got no errors, so
> I applied it, built, installed, and rebooted.

that patch revert to use request_resource, so there is some other problem

YH

Re: HPET regression in 2.6.26 versus 2.6.25 -- experimental revert for 2.6.27 failed

[Yinghai Lu]

On Wed, Aug 13, 2008 at 5:03 AM, David Witbrodt <dawitbro@sbcglobal.net> wrote:
>
>
>> please try attached patch with 2.6.27-rc3
>
> Thx for the patch... and for providing it as an attachment.  My email
> situation is less than optimal, and I am stuck using my ISP's web
> interface for the present.
>
> I used 'git apply --check <patchfilename>' first, and got no errors, so
> I applied it, built, installed, and rebooted.

could apply with
cat revert_*.;patch | patch -p1

YH

Re: HPET regression in 2.6.26 versus 2.6.25 -- experimental revert for 2.6.27 failed

[David Witbrodt]

> that patch revert to use request_resource, so there is some other problem

I agree.  I have already begun to bisect to find where the other problem,
which prevents reverting, might have been introduced.  Unfortunately, I'm
on my way to work as soon as I hit the "Send" button on this msg, so I
will be offline for the next 8 hours.


> could apply with
> cat revert_*.;patch | patch -p1

I assumed I should use 'git' to apply the patch.  Using 'git apply' worked
perfectly, though -- 'git status' reported that the files had changed, and
I looked over the files to see if the changes were what were intended by
the patch.  Also, the kernel built without errors.

I'll check it again when I get home, just to be sure, but I think it applied
just fine.


Thanks,
Dave W.