Messages in this thread | | | Date | Tue, 01 Jul 2008 04:49:41 -0700 | From | Mike Travis <> | Subject | Re: [crash, bisected] Re: [PATCH 3/4] x86_64: Fold pda into per cpu area |
| |
Eric W. Biederman wrote: > Mike Travis <travis@sgi.com> writes: > >> H. Peter Anvin wrote: >>> Mike Travis wrote: >>>> FYI, I did try this out and it caused the bootloader to scramble the >>>> loaded data. The first corruption I found was the .x86cpuvendor.init >>>> section contained all zeroes. >>>> >>> Explain what you mean with "the bootloader" in this context. >>> >>> -hpa >> >> After the code was loaded (the compressed code, it seems that my GRUB >> doesn't support uncompressed loading), the above section contained >> zeroes. I snapped it fairly early, around secondary_startup_64, and >> then printed it in x86_64_start_kernel. >> >> The object file had the correct data (as displayed by objdump) so I'm >> assuming that the bootloading process didn't load the section correctly. >> >> Below was the linker script I used: >> >> --- linux-2.6.tip.orig/include/asm-generic/vmlinux.lds.h >> +++ linux-2.6.tip/include/asm-generic/vmlinux.lds.h >> @@ -373,9 +373,13 @@ >> >> #ifdef CONFIG_HAVE_ZERO_BASED_PER_CPU >> #define PERCPU(align) \ >> - . = ALIGN(align); \ >> + .data.percpu.abs = .; \ >> percpu : { } :percpu \ >> - __per_cpu_load = .; \ >> + .data.percpu.rel : AT(.data.percpu.abs - LOAD_OFFSET) { \ >> + BYTE(0) \ >> + . = ALIGN(align); \ >> + __per_cpu_load = .; \ >> + } \ >> .data.percpu 0 : AT(__per_cpu_load - LOAD_OFFSET) { \ >> *(.data.percpu.first) \ >> *(.data.percpu.shared_aligned) \ >> @@ -383,8 +387,8 @@ >> *(.data.percpu.page_aligned) \ >> ____per_cpu_size = .; \ >> } \ >> - . = __per_cpu_load + ____per_cpu_size; \ >> - data : { } :data >> + . = __per_cpu_load + ____per_cpu_size; >> + >> #else >> #define PERCPU(align) \ >> . = ALIGN(align); \ >> >> It showed all the correct address in the map and __per_cpu_load was a >> relative symbol (which was the objective.) >> >> Btw, our simulator, which only loads uncompressed code, had the data correct, >> so it *may* only be a result of the code being compressed. > > Weird. Grub doesn't get involved in the decompression the kernel does it > all itself so we should be able to track where things go bad. > > Last I looked the compressed code was formed by essentially. > objcopy vmlinux -O binary vmlinux.bin > gzip vmlinux.bin > And then we take on a magic header to the gzip compressed file. > > Are things only bad with the change above? > > Eric
Yes. The failure was "Unsupported CPU" (or some such) which clued me into the vendor section.
I was able to get the zero-based variables working well for standard configs. It's getting tripped up now by some of Ingo's random configs, in very unusual places... And once again, it only fails on real h/w, not on our simulator, so catching the elusive bugger is tricky.
Thanks, Mike
| |