login
Search
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/ - git-cryptodev has things in it again - Re-added git-e1000: a large amount of e1000 driver work - git-net has a huge amount of material in it, but I dropped it because it went oops. - git-block is back, minus the problematic unplugging rework. - Lots of x86 updates. - lguest is being redone and has been dropped - The IDE development tree has been restored Boilerplate: - See the `hot-fixes' directory for any important updates to this patchset. - To fetch an -mm tree using git, use (for example) git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1 git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1 - -mm kernel commit activity can be reviewed by subscribing to the mm-commits mailing list. echo "subscribe mm-commits" | mail majordomo@vger.kernel.org - If you hit a bug in -mm and it is not obvious which patch caused it, it is most valuable if you can perform a bisection search to identify which patch introduced the bug. Instructions for this process are at http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt But beware that this process takes some time (around ten rebuilds and reboots), so consider reporting the bug first and if we cannot immediately identify the faulty patch, then perform the bisection search. - When reporting bugs, please try to Cc: the relevant maintainer and mailing list on any email. - When reporting bugs in this kernel via email, please also rewrite the email Subject: in some manner to reflect the nature of the bug. Some developers filter by Subject: when looking for messages to read. - Occasional snapshots of the -mm lineup are uploaded to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on the mm-commits list. Changes since 2.6.21-rc5-mm2: origin.patch git-acpi.patch ...
On my system (x86_64) 'make install_modules' produces a lot of warning messages: if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map 2.6.21-rc5-mm3; fi WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol __nf_ct_l4proto_find WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol nf_conntrack_find_get WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol nf_conntrack_l4proto_register WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol nf_conntrack_l4proto_udp6 WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol nf_conntrack_checksum WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol __nfa_fill WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol nf_ct_get_tuple WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol __nf_ct_event_cache_init WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol nf_conntrack_l3proto_register WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol nf_ct_log_invalid WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol nf_conntrack_l4proto_tcp6 WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol need_conntrack WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol nf_conntrack_l4proto_unregister WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol per_cpu__nf_conntrack_stat WARNING: ...
5/2.6.21-rc5-mm3/ Building with CONFIG_MAC80211_DEBUGFS=3Dy but CONFIG_MAC80211_DEBUG_COUNT= ERS=3Dn blows chunks on my box: CC =5BM=5D net/mac80211/debugfs.o net/mac80211/debugfs.c: In function =E2=80=98stats_wme_rx_queue_read=E2= =80=99: net/mac80211/debugfs.c:266: error: =E2=80=98struct ieee80211_local=E2=80= =99 has no member named =E2=80=98wme_rx_queue=E2=80=99 net/mac80211/debugfs.c: In function =E2=80=98stats_wme_tx_queue_read=E2= =80=99: net/mac80211/debugfs.c:286: error: =E2=80=98struct ieee80211_local=E2=80= =99 has no member named =E2=80=98wme_tx_queue=E2=80=99 make=5B2=5D: *** =5Bnet/mac80211/debugfs.o=5D Error 1
Yeah, my mistake. I posted a patch to fix it to wireless-dev but John is on vacation, below is a copy. If you want to put it anywhere here's my Signed-off-by: Johannes Berg <johannes@sipsolutions.net> --- net/mac80211/debugfs.c | 20 ++++++++++---------- net/mac80211/debugfs_sta.c | 4 ++++ net/mac80211/ieee80211_i.h | 4 ++-- net/mac80211/sta_info.h | 2 ++ 4 files changed, 18 insertions(+), 12 deletions(-) --- wireless-dev.orig/net/mac80211/debugfs.c 2007-03-28 22:57:03.937731699 +0200 +++ wireless-dev/net/mac80211/debugfs.c 2007-03-28 22:59:12.287731699 +0200 @@ -246,12 +246,6 @@ DEBUGFS_STATS_FILE(rx_handlers_fragments local->rx_handlers_fragments); DEBUGFS_STATS_FILE(tx_status_drop, 20, "%u", local->tx_status_drop); -#endif - -DEBUGFS_DEVSTATS_FILE(dot11ACKFailureCount); -DEBUGFS_DEVSTATS_FILE(dot11RTSFailureCount); -DEBUGFS_DEVSTATS_FILE(dot11FCSErrorCount); -DEBUGFS_DEVSTATS_FILE(dot11RTSSuccessCount); static ssize_t stats_wme_rx_queue_read(struct file *file, char __user *userbuf, @@ -292,6 +286,12 @@ static const struct file_operations stat .read = stats_wme_tx_queue_read, .open = mac80211_open_file_generic, }; +#endif + +DEBUGFS_DEVSTATS_FILE(dot11ACKFailureCount); +DEBUGFS_DEVSTATS_FILE(dot11RTSFailureCount); +DEBUGFS_DEVSTATS_FILE(dot11FCSErrorCount); +DEBUGFS_DEVSTATS_FILE(dot11RTSSuccessCount); void debugfs_hw_add(struct ieee80211_local *local) @@ -360,13 +360,13 @@ void debugfs_hw_add(struct ieee80211_loc DEBUGFS_STATS_ADD(rx_expand_skb_head2); DEBUGFS_STATS_ADD(rx_handlers_fragments); DEBUGFS_STATS_ADD(tx_status_drop); + DEBUGFS_STATS_ADD(wme_tx_queue); + DEBUGFS_STATS_ADD(wme_rx_queue); #endif DEBUGFS_STATS_ADD(dot11ACKFailureCount); DEBUGFS_STATS_ADD(dot11RTSFailureCount); DEBUGFS_STATS_ADD(dot11FCSErrorCount); DEBUGFS_STATS_ADD(dot11RTSSuccessCount); - DEBUGFS_STATS_ADD(wme_tx_queue); - DEBUGFS_STATS_ADD(wme_rx_queue); } void debugfs_hw_del(struct ...
A new error for me: loading 2.6.21rc5mm3 Bios data check successful Destination address not 2M aligned -- System halted This is using the same lilo that loads 2.6.18rc5mm1 fine. x86-64 Helge Hafting -
That's new. Does changing the value of CONFIG_RELOCATABLE change anything? Please send the .config. -
From: Andrew Morton <akpm@linux-foundation.org> I had the same with this .config from 2.6.21-rc3-mm2 after running 'make oldconfig' and answering N to all new questions. Then, I tweaked some items, mostly to see if there was an 'align kernel' item in there somewhere. Diff between _working_ 2.6.21-rc5-mm3 .config and this 2.6.21-rc3-mm2 .config at the end. Somehow that seems to have adapted 'CONFIG_PHYSICAL_START', maybe that's it? # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc3-mm2 # Tue Mar 13 18:35:46 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_EMBEDDED=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # ...
That looks like it. Does anyone know how to express the constraint of a 2M aligned number in Kconfig? The original plan was to remove CONFIG_PHYSICAL_START and CONFIG_RELOCATABLE on x86_64 because after this series they have no cost and thus just lead to a little more confusion. However because we don't tag vmlinux as ET_DYN and Xen has some use for kernel built at different physical addresses (or at least loaded at them), and because Xen directly loads vmlinux he kept those options. If we can find a place to stick it into the build doing a little post processing of vmlinux so that it has the proper ELF header type (ET_DYN not ET_EXEC) would be useful and allow us to remove those extra confusing options. If I have a spare moment I will take a look. Since there is confusion it is probably worth removing the unnecessary confusing options if we can instead of supporting the full confusion. Doing the same for i386 would be a little harder but with Dave Miller's suggestions for Xen and leaving the functions to be replaced unlinked so the compiler generates efficient calls and then doing linking magic to fill in the pieces at boot looks about as tricky as moving the relocation logic for i386 into vmlinux as well. So it seems feasible and possibly worth doing. Eric -
Nope, but we could make CONFIG_PHYSICAL_START be in units of 2MB, which would be a bit hard to use. Adding a BUILD_BUG_ON which checks this constraint might help. Plus a useful comment right at the BUILD_BUG_ON site explaining what to do about it. -
How about attached patch?
Thanks
Vivek
o X86_64 kernel should run from 2MB aligned address for two reasons.
- Performance.
- For relocatable kernels, page tables are updated based on difference
between compile time address and load time physical address.
This difference should be multiple of 2MB as kernel text and data
is mapped using 2MB pages and PMD should be pointing to a 2MB
aligned address. Life is simpler if both compile time and load time
kernel addresses are 2MB aligned.
o Flag the error at compile time if one is trying to build a kernel which
does not meet alignment restrictions.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
---
arch/x86_64/kernel/head64.c | 8 ++++++++
include/asm-x86_64/page.h | 1 +
2 files changed, 9 insertions(+)
diff -puN arch/x86_64/kernel/head64.c~x86_64-check-for-config-physical-start-aligned-2M arch/x86_64/kernel/head64.c
--- linux-2.6.21-rc5-mm3-vanilla/arch/x86_64/kernel/head64.c~x86_64-check-for-config-physical-start-aligned-2M 2007-04-02 20:46:43.000000000 +0530
+++ linux-2.6.21-rc5-mm3-vanilla-root/arch/x86_64/kernel/head64.c 2007-04-02 21:20:45.000000000 +0530
@@ -62,6 +62,14 @@ void __init x86_64_start_kernel(char * r
{
int i;
+ /*
+ * Make sure kernel is aligned to 2MB address. Catching it at compile
+ * time is better. Change your config file and compile the kernel
+ * for a 2MB aligned address (CONFIG_PHYSICAL_START)
+ */
+ BUILD_BUG_ON(ALIGN(CONFIG_PHYSICAL_START, __KERNEL_ALIGN)
+ != CONFIG_PHYSICAL_START);
+
/* clear bss before set_intr_gate with early_idt_handler */
clear_bss();
diff -puN include/asm-x86_64/page.h~x86_64-check-for-config-physical-start-aligned-2M include/asm-x86_64/page.h
--- linux-2.6.21-rc5-mm3-vanilla/include/asm-x86_64/page.h~x86_64-check-for-config-physical-start-aligned-2M 2007-04-02 20:50:55.000000000 +0530
+++ linux-2.6.21-rc5-mm3-vanilla-root/include/asm-x86_64/page.h 2007-04-02 20:51:34.000000000 +0530
@@ -79,6 +79,7 @@ extern ...From: Vivek Goyal <vgoyal@in.ibm.com> I'm only a user, so I'm not uptodate on these addresses and how they work. However, how does this solve the problem that running make oldconfig on a working 2.6.21-rc3-mm2 .config gives an unbootable 2.6.21-rc5-mm3 kernel? If I read things correctly, you now get a BUG, but the kernel still won't boot. If that is correct, than I, as a user, don't think that this is the solution that I feel comfortable with. If the kernel only boots CONFIG_PHYSICAL_START is aligned on a 2MB address, then we should align it, not BUG out when it's not, and especially not when it's unaligned through no fault of the user. Kind regards, Jurriaan -- Debian (Unstable) GNU/Linux 2.6.21-rc5-mm3 2x2010 bogomips load 0.89 the Jack Vance Integral Edition: http://www.integralarchive.org -
On Mon, Apr 02, 2007 at 01:17:45PM +0200, thunder7@xs4all.nl wrote: You will get a compile time error and your compilation will not be through if your physical address is not 2MB aligned. Just give it a try. Thanks Vivek -
From: Vivek Goyal <vgoyal@in.ibm.com> Just gave it a try, but I'm not convinced yet :-) I used a working 2.6.21-rc3-mm2 tree, patched it up to 2.6.21-rc5-mm3 and applied your patch. I ended up with the .config later in this email, and got this error: CC arch/x86_64/kernel/head64.o arch/x86_64/kernel/head64.c: In function 'x86_64_start_kernel': arch/x86_64/kernel/head64.c:70: error: size of array 'type name' is negative make[1]: *** [arch/x86_64/kernel/head64.o] Error 1 make: *** [arch/x86_64/kernel] Error 2 After reverting your patch, the build didn't fail, but of course the kernel won't build. Good luck, Jurriaan # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc5-mm3 # Mon Apr 2 16:38:50 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not ...
From: thunder7@xs4all.nl <thunder7@xs4all.nl> That should, of course, read 'kernel won't boot'. Sorry, Jurriaan -- Debian (Unstable) GNU/Linux 2.6.21-rc5-mm3 2x4826 bogomips load 0.92 the Jack Vance Integral Edition: http://www.integralarchive.org -
I agree that error message is not very clear. It is just an indication that there is a problem on line 70 in head64.c. That's why I have put a commet there so that anybody can make out that CONFIG_PHYSICAL_START is not 2MB aligned hence the failure. Unfortunately, Kconfig infrastrucutre does not allow to place alignment restrictions on the values. Otherwise that would have been the best solution. So we still have detected the problem at compilation time in a little indirect manner though. Thanks Vivek -
Looks like that will work.
Vivek. If I can get the x86_64 vmlinux to have type ET_DYN (to mark
it as relocatable) is there any reason to keep CONFIG_PHYSICAL_START?
I think I can switch the vmlinux header type in about 100 lines or so
of code. Assuming I can ever get 30 minutes with the appropriate
Just as a nit.
BUILD_BUG_ON(CONFIG_PHYSICAL_START & (__KERNEL_ALIGN - 1))
Do we want to use the __KERNEL_ALIGN directive in the test in misc.c?
Eric
-
Only advantage of CONFIG_PHYSICAL_START seems to be that one has got capability to run the kernel from other addresses without modifying the boot-loader. One can argue that now people should use a relocatable kernel for such a feature. But for using relocatable kenrel, one needs to modify grub, lilo and I am not sure if somebody is going to do that. Secondly, how would one specify an address to a boot-loader to load image at? On i386, somebody already found an interesting usage of CONFIG_PHYSICAL_START where he was running his kernel above 16MB so that he can maximize on DMA ZONE. Can't think of any usage for x86_64 at the moment but I think down the line people might come up with such usages. To me, retaining CONFIG_PHYSICAL_START gives added flexibility to the user, at the expense of reduced simplicity. We should definitely change the type of vmlinux to ET_DYN but at the same time it might still be worth to retain That would be awesome. Then vmlinux will be relocatable too. (Officially). Thanks. I changed it in misc.c too. Thanks Vivek o X86_64 kernel should run from 2MB aligned address for two reasons. - Performance. - For relocatable kernels, page tables are updated based on difference between compile time address and load time physical address. This difference should be multiple of 2MB as kernel text and data is mapped using 2MB pages and PMD should be pointing to a 2MB aligned address. Life is simpler if both compile time and load time kernel addresses are 2MB aligned. o Flag the error at compile time if one is trying to build a kernel which does not meet alignment restrictions. Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> --- arch/x86_64/boot/compressed/misc.c | 2 +- arch/x86_64/kernel/head64.c | 7 +++++++ include/asm-x86_64/page.h | 1 + 3 files changed, 9 insertions(+), 1 deletion(-) diff -puN arch/x86_64/kernel/head64.c~x86_64-check-for-config-physical-start-aligned-2M ...
I thought this was important for vmlinux and Xen? I guess at this point the easy case is that we modify /sbin/kexec to support it. And the other bootloaders can come be upgraded if the feature is Agreed. We do have CONFIG_PHYSICAL_ALIGN that can handle that case, I think something like CONFIG_PHYSICAL_START currently gives us very little gain, and is hard to use correctly, and there are alternative solutions. So if we can get rid of it, by only inconveniencing users Yes. For x86_64 I can do this. i386 is more difficult. (Although with a little cleverness we can move the code that processes relocations into vmlinux). Eric -
Yes it is. Actually you had already mentioned it in the previous mail that's why I did not repeat it here. Xen folks wanted to continue using vmlinux for capturing dump. I am not sure if there is any technical limitation in using relocatable bzImage or just that they wanted to continue using existing working interface and did not want to switch to new interface. Magnus, Horms, do you want to add to it? Is there a reason that relocatable bzImage will not work in Xen env and we need to retain CONFIG_PHYSICAL_START Yes, but x86_64 will not have any of those options and only way to run kernel will be either use kexec or modify your boot-loader to so that Performing relocations in vmlinux will be interesting. That way i386 vmlinux too will become relocatable and only piece of puzzle to solve will be to make vmlinux of type ET_DYN. Thanks Vivek -
Actually making vmlinux have type ET_DYN is the easier piece. Basically the quick way to do this is to have an arch specific: "cmd_vmlinux__" like uml does so we can edit things after the make. Changing an integer in an ELF header is simple. Inserting the code to perform the relocations feels a bit trickier but we can probably just dump it in head.S like we do on x86_64. We still need to insert the actual relocations to process though. Which requires all of the post processing we currently do just called at a slightly different location. Eric -
Something like what kallsyms does? Read .tmp_vmlinux2, extract and filter relocations, pack them in relocs.S, build reloc.o and relink it back to .tmp_vmlinux2 to make vmlinux. Then arch/i386/kernel/head.S can perform the relocations. But any additiona step of re-linking after final kallsyms information has been generated can potentially spoil kallsyms data? Thanks Vivek -
Currently because vmlinux does not reflect that the kernel is relocatable we still have to support CONFIG_PHYSICAL_START. So this patch adds a small c program to do what we cannot do with a linker script, set the elf header type to ET_DYN. This should remove the last obstacle to removing CONFIG_PHYSICAL_START on x86_64. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> --- arch/x86_64/Kconfig | 4 +++ arch/x86_64/Makefile | 10 +++++++ scripts/Makefile | 11 ++++--- scripts/mketrel.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 90 insertions(+), 5 deletions(-) create mode 100644 scripts/mketrel.c diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig index 16d9bf3..773b487 100644 --- a/arch/x86_64/Kconfig +++ b/arch/x86_64/Kconfig @@ -121,6 +121,10 @@ config ARCH_HAS_ILOG2_U64 bool default n +config ELF_RELOCATABLE + bool + default y + source "init/Kconfig" diff --git a/arch/x86_64/Makefile b/arch/x86_64/Makefile index 9dd91b2..5ae79ab 100644 --- a/arch/x86_64/Makefile +++ b/arch/x86_64/Makefile @@ -124,6 +124,16 @@ define archhelp echo ' isoimage - Create a boot CD-ROM image' endef +ifeq ($(CONFIG_RELOCATABLE),y) +define cmd_vmlinux__ + $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) -o $@ \ + -T $(vmlinux-lds) $(vmlinux-init) \ + --start-group $(vmlinux-main) --end-group \ + $(filter-out $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) FORCE ,$^) \ + && scripts/mketrel $@ +endef +endif + CLEAN_FILES += arch/$(ARCH)/boot/fdimage \ arch/$(ARCH)/boot/image.iso \ arch/$(ARCH)/boot/mtools.conf diff --git a/scripts/Makefile b/scripts/Makefile index 1c73c5a..ddba550 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -7,11 +7,12 @@ # conmakehash: Create chartable # conmakehash: Create arrays for initializing the kernel console tables -hostprogs-$(CONFIG_KALLSYMS) += kallsyms -hostprogs-$(CONFIG_LOGO) += ...
Now that the vmlinux is marked as relocatable there is no reason to
retain the CONFIG_PHYSICAL_START option, as we can put the binary we
have at any 2MB aligned address in memory.
With CONFIG_PHYSICAL_START gone the handful of code lines that depend
on CONFIG_RELOCATABLE no longer make sense to be conditional and can
be removed.
The big win of this patch (besides Kconfig simplicity) is that the
nasty BUILD_BUG_ON test for people misaligning their kernel when using
CONFIG_PHYSICAL_START can be removed as this case can only happen with
CONFIG_PHYSICAL_START selected.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86_64/Kconfig | 55 +-----------------------------------
arch/x86_64/Makefile | 2 -
arch/x86_64/boot/compressed/head.S | 13 +--------
arch/x86_64/boot/setup.S | 4 --
arch/x86_64/defconfig | 2 -
arch/x86_64/kernel/head64.c | 7 ----
include/asm-x86_64/page.h | 2 +-
7 files changed, 3 insertions(+), 82 deletions(-)
diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig
index 773b487..713c1ad 100644
--- a/arch/x86_64/Kconfig
+++ b/arch/x86_64/Kconfig
@@ -565,62 +565,9 @@ config CRASH_DUMP
which are loaded in the main kernel with kexec-tools into
a specially reserved region and then later executed after
a crash by kdump/kexec. The crash dump kernel must be compiled
- to a memory address not used by the main kernel or BIOS using
- PHYSICAL_START.
+ to a memory address not used by the main kernel or BIOS
For more details see Documentation/kdump/kdump.txt
-config RELOCATABLE
- bool "Build a relocatable kernel(EXPERIMENTAL)"
- depends on EXPERIMENTAL
- help
- Builds a relocatable kernel. This enables loading and running
- a kernel binary from a different physical address than it has
- been compiled for.
-
- One use is for the kexec on panic case where the recovery kernel
- must live at a ...Hi Eric, I think "must be compiled" should be replaced with "must be loaded" now. Otherwise both the patches look fine. I am planning to test these. This change will also require modifications to Documentation/kdump/kdump.txt file. Thanks Vivek -
Yes, that sounds right. Ugh. I didn't look at enough context to read Do you think you can generate the patch fix up the CONFIG_CRASH_DUMP and kdump.txt documentation. I was just interested enough to spend the 15 minutes needed to generate this patch. I don't think I care enough to dot the i's and cross the t's in the documentation. Eric -
[Dropping fastboot mailing list from CC as kexec mailing list is new list for this discussion] Hi Eric, Should this be ET_REL or ET_DYN? kexec refuses to load this vmlinux as it does not find it to be executable type. I am not well versed with various conventions but if I go through "Executable and Linking Format" document, this is what it says about various file types. • A relocatable file holds code and data suitable for linking with other object files to create an executable or a shared object file. • An executable file holds a program suitable for execution. • A shared object file holds code and data suitable for linking in two contexts. First, the link editor may process it with other relocatable and shared object files to create another object file. Second, the dynamic linker combines it with an executable file and other shared objects to create a process image. So above does not seem to fit in the ET_REL type. We can't relink this vmlinux? And it does not seem to fit in ET_DYN definition too. We are not relinking this vmlinux with another executable or other relocatable files. I remember once you mentioned the term dynamic executable which can be loaded at a non-compiled address and let run without requiring any relocation processing. This vmlinux will fall in that category but can't relate it to standard elf file definitions. Thanks Vivek -
Doh. It should be ET_DYN. I had relocatable much to much on the brain, Sorry about that. ET_DYN without a PT_DYNAMIC segment, without a PT_INTERP segment, and with a valid entry point is exactly that. Loaders never perform relocation processing on a ET_DYN executable but they are allowed to shift all of the addresses by a single delta so long as all of the alignment restrictions are honored. Relocation processing when it happens comes from the dynamic linker, which is set in PT_INTERP and the dynamic linker looks a PT_DYNAMIC to figure out what relocations are available for processing. The basic issue is that ld don't really comprehend what we are doing since we are building a position independent executable in a way that the normal tools don't allow, so we have to poke the header. If we had compiled with -fPIC we could have specified -pie or --pic-executable to ld and it would have done the right thing. But as it is our executable only changes physical addresses and not virtual addresses something completely foreign to ld. Eric -
I will have to dig a little deeper but this certainly sounds like the x86_64 relocatable kernel patches. I believe the check is in arch/x86_64/boot/compressed/misc.c I think the interesting .config variable is going to be CONFIG_PHYSICAL_START. I suspect that isn't going to be 2M aligned, like the kernel requires Please. Eric -
Here is my .config Sorry for the late reply, I have been on a holiday.
Sorry, that was a wrong .config file. Here is the right one, form the amd64 box:
Somebody is confused (possibly me). Running an x86_64 kernel, and I have:
% cat /proc/acpi/processor/CPU0/power
active state: C0
max_cstate: C8
bus master activity: 00000000
maximum allowed latency: 2000 usec
states:
C1: type[C1] promotion[--] demotion[--] latency[001] usage[00000003] duration[00000000000000000000]
C2: type[C2] promotion[--] demotion[--] latency[001] usage[00166266] duration[00000000000000000000]
C3: type[C3] promotion[--] demotion[--] latency[057] usage[02045938] duration[00000000000000000000]
Wow. Lots of zeros in that last column..
The 'duration' is output by this code in drivers/acpi/processor_idle.c that
thinks the value is an 'unsigned long long':
seq_printf(seq, "latency[%03d] usage[%08d] duration[%020llu]\n",
pr->power.states[i].latency,
pr->power.states[i].usage,
(unsigned long long)pr->power.states[i].time);
However, over in /sys, we have non-zero values for the usage/time:
% cat /sys/devices/system/cpu/cpu0/cpuidle/state?/time
0
110861364
-2091818383
That's because in drivers/cpuidle/sysfs.c, we have this code that thinks
a %d is suitable to output that number:
#define define_show_state_function(_name) static ssize_t show_state_##_name(struct cpuidle_state *state, char *buf) { \
return sprintf(buf, "%d\n", state->_name);\
}
...
define_one_state_ro(time, show_state_time);
But the negative number for state2/time indicates that *this* isn't right either....
Please give me a clue:
- This patch is not merged into the netdev tree as included in -mm and
- it still applies fine against 2.6.21-rc5-mm3 and
- it still compiles fine with 2.6.21-rc5-mm3.
TIA
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
This patch makes the needlesly global ali_tf_load() static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
--- linux-2.6.21-rc5-mm3/drivers/ata/pata_ali.c.old 2007-03-31 21:06:19.000000000 +0200
+++ linux-2.6.21-rc5-mm3/drivers/ata/pata_ali.c 2007-03-31 21:06:33.000000000 +0200
@@ -288,7 +288,7 @@
* Inherited from caller.
*/
-void ali_tf_load(struct ata_port *ap, const struct ata_taskfile *tf)
+static void ali_tf_load(struct ata_port *ap, const struct ata_taskfile *tf)
{
struct ata_ioports *ioaddr = &ap->ioaddr;
unsigned int is_addr = tf->flags & ATA_TFLAG_ISADDR;
-
Acked-by: Tejun Heo <htejun@gmail.com> -- tejun -
OMG - I'll never understand how someone could initially start doing this hiding of a small fixup behind a config option. Instead of cleaning up this mess, please replace this patch with the patch below. cu Adrian <-- snip --> A config option for hiding one small hardware specific fixup is overkill. Signed-off-by: Adrian Bunk <bunk@stusta.de> --- arch/i386/Kconfig | 18 ---------- arch/i386/kernel/Makefile | 1 arch/i386/kernel/reboot.c | 43 +++++++++++++++++++++++- arch/i386/kernel/reboot_fixups.c | 55 ------------------------------- include/linux/reboot_fixups.h | 10 ----- 5 files changed, 42 insertions(+), 85 deletions(-) --- linux-2.6.21-rc5-mm3/arch/i386/Kconfig.old 2007-03-31 20:50:28.000000000 +0200 +++ linux-2.6.21-rc5-mm3/arch/i386/Kconfig 2007-03-31 20:50:43.000000000 +0200 @@ -426,24 +426,6 @@ Say Y if you intend to run this kernel on a Dell Inspiron 8000. Say N otherwise. -config X86_REBOOTFIXUPS - bool "Enable X86 board specific fixups for reboot" - depends on X86 - default n - ---help--- - This enables chipset and/or board specific fixups to be done - in order to get reboot to work correctly. This is only needed on - some combinations of hardware and BIOS. The symptom, for which - this config is intended, is when reboot ends with a stalled/hung - system. - - Currently, the only fixup is for the Geode GX1/CS5530A/TROM2.1. - combination. - - Say Y if you want to enable the fixup. Currently, it's safe to - enable this option even if you don't need it. - Say N otherwise. - config MICROCODE tristate "/dev/cpu/microcode - Intel IA32 CPU microcode support" select FW_LOADER --- linux-2.6.21-rc5-mm3/arch/i386/kernel/Makefile.old 2007-03-31 20:51:03.000000000 +0200 +++ linux-2.6.21-rc5-mm3/arch/i386/kernel/Makefile 2007-03-31 20:51:28.000000000 +0200 @@ -23,7 +23,6 @@ obj-$(CONFIG_X86_MPPARSE) += mpparse.o obj-$(CONFIG_X86_LOCAL_APIC) += apic.o ...
Yeah, I considered that patch as a placeholder; I'd been wondering if it
can be completely removed.
But this patch looks fine, though I'd go further - the lookup table of
pci ids is overkill since it only has one entry (and doesn't look likely
to grow any more).
J
-
I have no strong opinion regarding this - if it's agreed upon that it's
unlikely it will ever grow, I can also send an additional patch
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
I haven't got any response from the original person who submitted this
patch. It isn't clear to me whether this is a fix for some machine
that's in wide use, or a workaround for a prototype sitting on someone's
bench.
Andi has already accepted my more general patch which allows
intercepting the halt/reboot process in arbitrary ways (the machine_ops
patch), so that would seem to be a better way of handling this problem
if more cases arise.
J
-
This patch makes the needlessly global PHY_DEVICES[] static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
BTW: Why is the name uppercase?
--- linux-2.6.21-rc5-mm3/drivers/net/qla3xxx.c.old 2007-03-31 21:30:20.000000000 +0200
+++ linux-2.6.21-rc5-mm3/drivers/net/qla3xxx.c 2007-03-31 22:02:00.000000000 +0200
@@ -88,7 +88,7 @@
char *name;
} PHY_DEVICE_INFO_t;
-const PHY_DEVICE_INFO_t PHY_DEVICES[] =
+static const PHY_DEVICE_INFO_t PHY_DEVICES[] =
{{PHY_TYPE_UNKNOWN, 0x000000, 0x0, "PHY_TYPE_UNKNOWN"},
{PHY_VITESSE_VSC8211, 0x0003f1, 0xb, "PHY_VITESSE_VSC8211"},
{PHY_AGERE_ET1011C, 0x00a0bc, 0x1, "PHY_AGERE_ET1011C"},
-
This patch makes the needlessly global
struct proc_fdinfo_file_operations static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.21-rc5-mm3/fs/proc/base.c.old 2007-03-31 22:07:21.000000000 +0200
+++ linux-2.6.21-rc5-mm3/fs/proc/base.c 2007-03-31 22:07:30.000000000 +0200
@@ -1515,7 +1515,7 @@
return err;
}
-const struct file_operations proc_fdinfo_file_operations = {
+static const struct file_operations proc_fdinfo_file_operations = {
.open = nonseekable_open,
.read = proc_fdinfo_read,
};
-
BUG: at /mnt/md0/devel/linux-mm/arch/i386/kernel/smp.c:571 native_smp_call_function_mask() [<c01051a1>] dump_trace+0x63/0x1eb [<c0105343>] show_trace_log_lvl+0x1a/0x30 [<c0105f8a>] show_trace+0x12/0x14 [<c0106027>] dump_stack+0x16/0x18 [<c0113a92>] native_smp_call_function_mask+0x57/0x14b [<c0113c9b>] smp_call_function+0x1e/0x22 [<c0129a60>] on_each_cpu+0x2a/0x73 [<c013a12d>] clock_was_set+0x1b/0x1d [<c013b99d>] timekeeping_resume+0xb5/0xbb [<c027af35>] __sysdev_resume+0x17/0x5d [<c027b2aa>] sysdev_resume+0x19/0x4b [<c027fd12>] device_power_up+0xb/0x12 [<c014f30b>] swsusp_suspend+0x55/0x63 [<c014fad0>] pm_suspend_disk+0x163/0x28f [<c014e7be>] enter_state+0x54/0x1d5 [<c014e9c5>] state_store+0x86/0x9c [<c01bfe47>] subsys_attr_store+0x23/0x2b [<c01bff89>] sysfs_write_file+0xc1/0xe9 [<c0186485>] vfs_write+0xd1/0x15a [<c0186ab7>] sys_write+0x3d/0x72 [<c010424c>] syscall_call+0x7/0xb [<b7f9b410>] 0xb7f9b410 ======================= BUG: using smp_processor_id() in preemptible [00000001] code: swsusp_shutdown/3246 caller is setup_apic_nmi_watchdog+0x13/0x423 [<c01051a1>] dump_trace+0x63/0x1eb [<c0105343>] show_trace_log_lvl+0x1a/0x30 [<c0105f8a>] show_trace+0x12/0x14 [<c0106027>] dump_stack+0x16/0x18 [<c021a0ff>] debug_smp_processor_id+0xb3/0xc8 [<c011633d>] setup_apic_nmi_watchdog+0x13/0x423 [<c0116871>] lapic_nmi_resume+0x16/0x1f [<c027af35>] __sysdev_resume+0x17/0x5d [<c027b2aa>] sysdev_resume+0x19/0x4b [<c027fd12>] device_power_up+0xb/0x12 [<c014f30b>] swsusp_suspend+0x55/0x63 [<c014fad0>] pm_suspend_disk+0x163/0x28f [<c014e7be>] enter_state+0x54/0x1d5 [<c014e9c5>] state_store+0x86/0x9c [<c01bfe47>] subsys_attr_store+0x23/0x2b [<c01bff89>] sysfs_write_file+0xc1/0xe9 [<c0186485>] vfs_write+0xd1/0x15a [<c0186ab7>] sys_write+0x3d/0x72 [<c010424c>] syscall_call+0x7/0xb [<b7f9b410>] 0xb7f9b410 l *setup_apic_nmi_watchdog+0x13 0xc011633d is in setup_apic_nmi_watchdog (/mnt/md0/devel/linux-mm/arch/i386/kernel/nmi.c:793). 788 ...
We're calling smp_call_function() with local interrupts disabled, which is deadlockable. This, I expect, is because swsusp_suspend() optimistically tries to run everything with local interrupts disabled. I don't know why this has suddenly started happening - timekeeping_resume()->clock_was_set()->on_each_cpu() has been there for a while. Doesn't mainline do the same thing? Not sure what to do about this. The best fix would be to teach swsusp to not be so optmistic: resume functions are called with local irqs _enabled_ - that's part of their call environment. swsusp tries to call them with local irqs disabled and bad things happen. -
Well, not everything, but device_power_down()/device_power_up() which only Yes, and it has always done it. It even is documented in I think timekeeping_resume() shouldn't call smp_call_function() ... -
Some clarification is necessary, I suppose: I meant that the mainline had always called device_power_up() with IRQs disabled, which was documented. _OTOH_ the clock_was_set() was added to timekeeping_resume() after 2.6.20 and it shouldn't call on_each_cpu(), because it is run on one CPU. Greetings, Rafael (who's apparently too tired to read email now) -
It's my lucky Friday, kernel hangs shortly after PM: Removing info for No Bus:vcsa1 PM: Adding info for No Bus:vcs1 PM: Adding info for No Bus:vcsa1 PM: Removing info for No Bus:vcs1 PM: Removing info for No Bus:vcsa1 PM: Adding info for No Bus:vcs1 PM: Adding info for No Bus:vcsa1 PM: Adding info for No Bus:rtc Real Time Clock Driver v1.12ac due to GOOD mm-only-hrtimers-debug-patch.patch mm-only-hrtimers-debug-patch-fix.patch BAD patches. Both patches works fine for me in vanilla tree. http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5-mm3/mm-config http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5-mm3/mm-console.log Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) -
hm. now that's a mystery ... Any way to figure out where it hangs? nmi_watchdog=1/2, softlockup, etc? Ingo -
nmi_watchdog=1 boots fine
nmi_watchdog=2 shows this
BUG: NMI Watchdog detected LOCKUP on CPU0, eip c014ce9c, registers:
Modules linked in: ide_cd cdrom rtc unix
CPU: 0
EIP: 0060:[<c014ce9c>] Not tainted VLI
EFLAGS: 00000093 (2.6.21-rc5-mm3 #10)
EIP is at read_pointer+0x49/0x2d8
eax: c7a8dd04 ebx: 00000000 ecx: 00000000 edx: c043d19c
esi: c043d184 edi: c043d19c ebp: c7a8dbf4 esp: c7a8dbbc
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process udevd (pid: 864, ti=c7a8c000 task=c97cd4d0 task.ti=c7a8c000)
Stack: 0000000b c7a8dc70 c7a8dbf4 c014d6d0 c7a8dd04 c043e454 c7a8dbf4 c011fdd1
c043e404 c043e454 c043d190 0005cd94 c043d184 c7a8dd04 c7a8dd14 c014dd3a
00000000 00000000 00000000 00000000 c7a8df44 c7a8dd74 c741eefb 00000008
Call Trace:
[<c014dd3a>] unwind+0x414/0xfa2
[<c010510d>] dump_trace_unwind+0xb4/0xe5
[<c014ce4d>] unwind_init_running+0x25/0x2b
[<c01051a1>] dump_trace+0x63/0x1eb
[<c010ad39>] save_stack_trace+0x23/0x42
[<c01393c9>] update_cpu_base_expires_next+0x56/0x5a
[<c013a475>] hrtimer_interrupt+0x17c/0x1b8
[<c0115e8e>] smp_apic_timer_interrupt+0x72/0x85
[<c0104bef>] apic_timer_interrupt+0x33/0x38
[<c014320c>] lock_release+0x1d2/0x1da
[<c013a7ef>] up_read+0x19/0x2e
[<c011b800>] do_page_fault+0x28f/0x55b
[<c034d191>] error_code+0x79/0x80
[<c020c23e>] __put_user_4+0x12/0x18
DWARF2 unwinder stuck at __put_user_4+0x12/0x18
Leftover inexact backtrace:
[<c01040d6>] ret_from_fork+0x6/0x1c
=======================
Code: a8 47 83 c0 00 0f 84 a3 02 00 00 8b 55 d8 8b 02 89 7c 24 0c 89 44 24 08 89 5c 24 04 c7 04 24 7c 54 3f c0 e9 75 02 00 00 8b 45 d8 <8b> 08 89 4d f0 89 d8 83 e0 07 83 f8 01 74 7f 7f 04 85 c0 eb 08
l *0xc014ce9c
0xc014ce9c is in read_pointer (/mnt/md0/devel/linux-mm/kernel/unwind.c:526).
521
522 if (ptrType < 0 || ptrType == DW_EH_PE_omit) {
523 dprintk(1, "Invalid pointer encoding %02X (%p,%p).", ptrType, *pLoc, end);
524 return 0;
525 ...