Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
Sorry, that was a wrong .config file. Here is the right one, form the amd64 box: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc5-mm3 # Sat Mar 31 09:01:57 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_BROKEN_ON_SMP=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=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # 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_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set CONFIG_PAGE_GROUP_BY_MOBILITY=y # # Loadable module support # # CONFIG_MODULES is not set # # Process debugging support # CONFIG_UTRACE=y CONFIG_PTRACE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y # CONFIG_X86_CPUID is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ADAPTIVE_READAHEAD=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y CONFIG_X86_MCE_AMD=y CONFIG_KEXEC=y # CONFIG_CRASH_DUMP is not set # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_START=0x10 CONFIG_SECCOMP=y # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300 CONFIG_REORDER=y CONFIG_K8_NB=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y # # Power management options # CONFIG_PM=y # CONFIG_PM_LEGACY is not set # CONFIG_PM_DEBUG is not set # CONFIG_PM_SYSFS_DEPRECATED is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y # CONFIG_ACPI_SLEEP is not set # CONFIG_ACPI_PROCFS is not set # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y # CONFIG_ACPI_VIDEO is not set CONFIG_ACPI_FAN=y # CONFIG_ACPI_DOCK is not set CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y # CONFIG_ACPI_CONTAINER is not set # CONFIG_ACPI_SBS is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=y CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_US
Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
Here is my .config Sorry for the late reply, I have been on a holiday. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc5-mm2 # Wed Mar 28 12:18:09 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=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=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # 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_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set CONFIG_PAGE_GROUP_BY_MOBILITY=y # # Loadable module support # # CONFIG_MODULES is not set # # Process debugging support # CONFIG_UTRACE=y CONFIG_PTRACE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set CONFIG_MICROCODE=y CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # # Firmware Drivers # CONFIG_EDD=y # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_3G_OPT is not set # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xC000 CONFIG_NEED_NODE_MEMMAP_SIZE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_SELECT_MEMORY_MODEL=y # CONFIG_FLATMEM_MANUAL is not set # CONFIG_DISCONTIGMEM_MANUAL is not set CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_STATIC=y CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_RESOURCES_64BIT is not set CONFIG_Z
Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
On Mon, Apr 02, 2007 at 11:23:17PM -0600, Eric W. Biederman wrote: > Vivek Goyal <[EMAIL PROTECTED]> writes: > > >> 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 > >> interesting enough. > >> > >> > 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. > >> > >> Agreed. We do have CONFIG_PHYSICAL_ALIGN that can handle that case, > >> although I admit that is a bit of a hack. > >> > > > > 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 > > it can handle relocatable images. > > True. > > >> > 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 > >> > CONFIG_PHYSICAL_START option. > >> > >> 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 > >> who want load their kernels at a weird address it is worth it. > >> > >> >> 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 > >> >> kernel. > >> >> > >> > > >> > That would be awesome. Then vmlinux will be relocatable too. > >> > (Officially). > >> > >> 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). > >> > > > > 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. > > 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. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
Vivek Goyal <[EMAIL PROTECTED]> writes: >> 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 >> interesting enough. >> >> > 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. >> >> Agreed. We do have CONFIG_PHYSICAL_ALIGN that can handle that case, >> although I admit that is a bit of a hack. >> > > 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 > it can handle relocatable images. True. >> > 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 >> > CONFIG_PHYSICAL_START option. >> >> 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 >> who want load their kernels at a weird address it is worth it. >> >> >> 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 >> >> kernel. >> >> >> > >> > That would be awesome. Then vmlinux will be relocatable too. (Officially). >> >> 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). >> > > 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. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
On Mon, Apr 02, 2007 at 04:59:26PM +0200, [EMAIL PROTECTED] wrote: > From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> > Date: Mon, Apr 02, 2007 at 04:49:14PM +0200 > > > > 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. > > > That should, of course, read 'kernel won't boot'. > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
On Mon, Apr 02, 2007 at 11:26:38AM -0600, Eric W. Biederman wrote: > Vivek Goyal <[EMAIL PROTECTED]> writes: > > > 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? > > I thought this was important for vmlinux and Xen? > 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 option in x86_64? > 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 > interesting enough. > > > 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. > > Agreed. We do have CONFIG_PHYSICAL_ALIGN that can handle that case, > although I admit that is a bit of a hack. > 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 it can handle relocatable images. > > 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 > > CONFIG_PHYSICAL_START option. > > 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 > who want load their kernels at a weird address it is worth it. > > >> 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 > >> kernel. > >> > > > > That would be awesome. Then vmlinux will be relocatable too. (Officially). > > 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). > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
Vivek Goyal <[EMAIL PROTECTED]> writes: > 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? 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 interesting enough. > 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. Agreed. We do have CONFIG_PHYSICAL_ALIGN that can handle that case, although I admit that is a bit of a hack. > 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 > CONFIG_PHYSICAL_START option. 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 who want load their kernels at a weird address it is worth it. >> 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 >> kernel. >> > > That would be awesome. Then vmlinux will be relocatable too. (Officially). 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Mon, Apr 02, 2007 at 04:49:14PM +0200 > > 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. > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
From: Vivek Goyal <[EMAIL PROTECTED]> Date: Mon, Apr 02, 2007 at 05:06:39PM +0530 > On Mon, Apr 02, 2007 at 01:17:45PM +0200, [EMAIL PROTECTED] wrote: > [..] > > > + /* > > > + * 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.0 +0530 > > > +++ linux-2.6.21-rc5-mm3-vanilla-root/include/asm-x86_64/page.h > > > 2007-04-02 20:51:34.0 +0530 > > > @@ -79,6 +79,7 @@ extern unsigned long phys_base; > > > #endif /* !__ASSEMBLY__ */ > > > > > > #define __PHYSICAL_START CONFIG_PHYSICAL_START > > > +#define __KERNEL_ALIGN 0x20 > > > #define __START_KERNEL (__START_KERNEL_map + __PHYSICAL_START) > > > #define __START_KERNEL_map 0x8000 > > > #define __PAGE_OFFSET 0x8100 > > > _ > > > 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. > 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 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 # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y # CONFIG_VM_EVENT_COUNTERS is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set CONFIG_PAGE_GROUP_BY_MOBILITY=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Process debugging support # CONFIG_UTRACE=y CONFIG_PTRACE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y # CONFIG_IOSCHED_DEADLINE is not set # CONFIG_IOSCHED_CFQ is not set CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64
Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
On Mon, Apr 02, 2007 at 01:17:45PM +0200, [EMAIL PROTECTED] wrote: [..] > > + /* > > +* 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.0 +0530 > > +++ linux-2.6.21-rc5-mm3-vanilla-root/include/asm-x86_64/page.h > > 2007-04-02 20:51:34.0 +0530 > > @@ -79,6 +79,7 @@ extern unsigned long phys_base; > > #endif /* !__ASSEMBLY__ */ > > > > #define __PHYSICAL_START CONFIG_PHYSICAL_START > > +#define __KERNEL_ALIGN 0x20 > > #define __START_KERNEL (__START_KERNEL_map + __PHYSICAL_START) > > #define __START_KERNEL_map 0x8000 > > #define __PAGE_OFFSET 0x8100 > > _ > > 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. > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
From: Vivek Goyal <[EMAIL PROTECTED]>
Date: Mon, Apr 02, 2007 at 01:11:59PM +0530
>
> How about attached patch?
>
> 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 <[EMAIL PROTECTED]>
> ---
>
> 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.0 +0530
> +++ linux-2.6.21-rc5-mm3-vanilla-root/arch/x86_64/kernel/head64.c
> 2007-04-02 21:20:45.0 +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.0 +0530
> +++ linux-2.6.21-rc5-mm3-vanilla-root/include/asm-x86_64/page.h
> 2007-04-02 20:51:34.0 +0530
> @@ -79,6 +79,7 @@ extern unsigned long phys_base;
> #endif /* !__ASSEMBLY__ */
>
> #define __PHYSICAL_START CONFIG_PHYSICAL_START
> +#define __KERNEL_ALIGN 0x20
> #define __START_KERNEL (__START_KERNEL_map + __PHYSICAL_START)
> #define __START_KERNEL_map 0x8000
> #define __PAGE_OFFSET 0x8100
> _
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
On Mon, Apr 02, 2007 at 02:43:56AM -0600, Eric W. Biederman wrote:
> Vivek Goyal <[EMAIL PROTECTED]> writes:
>
> > On Sat, Mar 31, 2007 at 11:29:57PM -0700, Andrew Morton wrote:
> >> On Sun, 01 Apr 2007 00:15:51 -0600 [EMAIL PROTECTED] (Eric W. Biederman)
> > wrote:
> >>
> >> > Does anyone know how to express the constraint of a 2M aligned number in
> > Kconfig?
> >>
> >> 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?
>
> 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?
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
CONFIG_PHYSICAL_START option.
> 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
> kernel.
>
That would be awesome. Then vmlinux will be relocatable too. (Officially).
[..]
> > @@ -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);
>
> Just as a nit.
> BUILD_BUG_ON(CONFIG_PHYSICAL_START & (__KERNEL_ALIGN - 1))
> is a little shorter... Although maybe not quite as readable.
This looks better. I changed it in attached patch.
> > +
> > /* 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.0 +0530
> > +++ linux-2.6.21-rc5-mm3-vanilla-root/include/asm-x86_64/page.h 2007-04-02
> > 20:51:34.0 +0530
> > @@ -79,6 +79,7 @@ extern unsigned long phys_base;
> > #endif /* !__ASSEMBLY__ */
> >
> > #define __PHYSICAL_START CONFIG_PHYSICAL_START
> > +#define __KERNEL_ALIGN 0x20
> > #define __START_KERNEL (__START_KERNEL_map + __PHYSICAL_START)
> > #define __START_KERNEL_map 0x8000
> > #define __PAGE_OFFSET 0x8100
>
> Do we want to use the __KERNEL_ALIGN directive in the test in misc.c?
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 <[EMAIL PROTECTED]>
---
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
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.0 +0530
+++ linux-2.6.21-rc5-mm3-vanilla-root/arch/x86_64/kernel/head64.c
2007-04-02 23:03:08.0 +0530
@@ -62,6 +62,13 @@ void __init x86_
Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
Vivek Goyal <[EMAIL PROTECTED]> writes:
> On Sat, Mar 31, 2007 at 11:29:57PM -0700, Andrew Morton wrote:
>> On Sun, 01 Apr 2007 00:15:51 -0600 [EMAIL PROTECTED] (Eric W. Biederman)
> wrote:
>>
>> > Does anyone know how to express the constraint of a 2M aligned number in
> Kconfig?
>>
>> 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?
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
kernel.
> 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 <[EMAIL PROTECTED]>
> ---
>
> 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.0 +0530
> +++ linux-2.6.21-rc5-mm3-vanilla-root/arch/x86_64/kernel/head64.c 2007-04-02
> 21:20:45.0 +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);
Just as a nit.
BUILD_BUG_ON(CONFIG_PHYSICAL_START & (__KERNEL_ALIGN - 1))
is a little shorter... Although maybe not quite as readable.
> +
> /* 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.0 +0530
> +++ linux-2.6.21-rc5-mm3-vanilla-root/include/asm-x86_64/page.h 2007-04-02
> 20:51:34.0 +0530
> @@ -79,6 +79,7 @@ extern unsigned long phys_base;
> #endif /* !__ASSEMBLY__ */
>
> #define __PHYSICAL_START CONFIG_PHYSICAL_START
> +#define __KERNEL_ALIGN 0x20
> #define __START_KERNEL (__START_KERNEL_map + __PHYSICAL_START)
> #define __START_KERNEL_map 0x8000
> #define __PAGE_OFFSET 0x8100
Do we want to use the __KERNEL_ALIGN directive in the test in misc.c?
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
On Sat, Mar 31, 2007 at 11:29:57PM -0700, Andrew Morton wrote:
> On Sun, 01 Apr 2007 00:15:51 -0600 [EMAIL PROTECTED] (Eric W. Biederman)
> wrote:
>
> > Does anyone know how to express the constraint of a 2M aligned number in
> > Kconfig?
>
> 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 <[EMAIL PROTECTED]>
---
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.0 +0530
+++ linux-2.6.21-rc5-mm3-vanilla-root/arch/x86_64/kernel/head64.c
2007-04-02 21:20:45.0 +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.0 +0530
+++ linux-2.6.21-rc5-mm3-vanilla-root/include/asm-x86_64/page.h 2007-04-02
20:51:34.0 +0530
@@ -79,6 +79,7 @@ extern unsigned long phys_base;
#endif /* !__ASSEMBLY__ */
#define __PHYSICAL_START CONFIG_PHYSICAL_START
+#define __KERNEL_ALIGN 0x20
#define __START_KERNEL (__START_KERNEL_map + __PHYSICAL_START)
#define __START_KERNEL_map 0x8000
#define __PAGE_OFFSET 0x8100
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: Re: 2.6.21-rc5-mm3
>> [] __put_user_4+0x12/0x18 >> DWARF2 unwinder stuck at __put_user_4+0x12/0x18 >> Leftover inexact backtrace: >> [] ret_from_fork+0x6/0x1c > >Hmpf. I saw it once in child_rip here too. Then I wanted to reproduce it to >report >properly and couldn't again. I had a few other backtraces that were all non >stuck >with child_rip then on essentially the same kernel. Something weird is going >on. > >> [] hrtimer_interrupt+0x17c/0x1b8 >> [] smp_apic_timer_interrupt+0x72/0x85 >> [] apic_timer_interrupt+0x33/0x38 >> [] __get_user_4+0x14/0x17 >> DWARF2 unwinder stuck at __get_user_4+0x14/0x17 >> Leftover inexact backtrace: > >Now that is weird. Never seen before. Jan, any ideas? Not weird at all - these functions simply aren't annotated (i.e. I assume you forgot to apply the respective patch when you re-added the unwinder). As I don't have this as a standalone patch anymore, I'll include the full diff for arch/i386/lib/ below - this is likely to apply. Jan Index: head-2007-03-19/arch/i386/lib/checksum.S === --- head-2007-03-19.orig/arch/i386/lib/checksum.S 2007-02-04 19:44:54.0 +0100 +++ head-2007-03-19/arch/i386/lib/checksum.S2007-03-21 12:29:15.0 +0100 @@ -25,6 +25,8 @@ * 2 of the License, or (at your option) any later version. */ +#include +#include #include /* @@ -36,8 +38,6 @@ unsigned int csum_partial(const unsigned */ .text -.align 4 -.globl csum_partial #ifndef CONFIG_X86_USE_PPRO_CHECKSUM @@ -48,9 +48,14 @@ unsigned int csum_partial(const unsigned * Fortunately, it is easy to convert 2-byte alignment to 4-byte * alignment for the unrolled loop. */ -csum_partial: +ENTRY(csum_partial) + CFI_STARTPROC pushl %esi + CFI_ADJUST_CFA_OFFSET 4 + CFI_REL_OFFSET esi, 0 pushl %ebx + CFI_ADJUST_CFA_OFFSET 4 + CFI_REL_OFFSET ebx, 0 movl 20(%esp),%eax # Function arg: unsigned int sum movl 16(%esp),%ecx # Function arg: int len movl 12(%esp),%esi # Function arg: unsigned char *buff @@ -128,16 +133,27 @@ csum_partial: roll $8, %eax 8: popl %ebx + CFI_ADJUST_CFA_OFFSET -4 + CFI_RESTORE ebx popl %esi + CFI_ADJUST_CFA_OFFSET -4 + CFI_RESTORE esi ret + CFI_ENDPROC +ENDPROC(csum_partial) #else /* Version for PentiumII/PPro */ -csum_partial: +ENTRY(csum_partial) + CFI_STARTPROC pushl %esi + CFI_ADJUST_CFA_OFFSET 4 + CFI_REL_OFFSET esi, 0 pushl %ebx + CFI_ADJUST_CFA_OFFSET 4 + CFI_REL_OFFSET ebx, 0 movl 20(%esp),%eax # Function arg: unsigned int sum movl 16(%esp),%ecx # Function arg: int len movl 12(%esp),%esi # Function arg: const unsigned char *buf @@ -245,8 +261,14 @@ csum_partial: roll $8, %eax 90: popl %ebx + CFI_ADJUST_CFA_OFFSET -4 + CFI_RESTORE ebx popl %esi + CFI_ADJUST_CFA_OFFSET -4 + CFI_RESTORE esi ret + CFI_ENDPROC +ENDPROC(csum_partial) #endif @@ -278,19 +300,24 @@ unsigned int csum_partial_copy_generic ( .long b, 6002f ; \ .previous -.align 4 -.globl csum_partial_copy_generic - #ifndef CONFIG_X86_USE_PPRO_CHECKSUM #define ARGBASE 16 #define FP 12 -csum_partial_copy_generic: +ENTRY(csum_partial_copy_generic) + CFI_STARTPROC subl $4,%esp + CFI_ADJUST_CFA_OFFSET 4 pushl %edi + CFI_ADJUST_CFA_OFFSET 4 + CFI_REL_OFFSET edi, 0 pushl %esi + CFI_ADJUST_CFA_OFFSET 4 + CFI_REL_OFFSET esi, 0 pushl %ebx + CFI_ADJUST_CFA_OFFSET 4 + CFI_REL_OFFSET ebx, 0 movl ARGBASE+16(%esp),%eax # sum movl ARGBASE+12(%esp),%ecx # len movl ARGBASE+4(%esp),%esi # src @@ -400,10 +427,19 @@ DST( movb %cl, (%edi)) .previous popl %ebx + CFI_ADJUST_CFA_OFFSET -4 + CFI_RESTORE ebx popl %esi + CFI_ADJUST_CFA_OFFSET -4 + CFI_RESTORE esi popl %edi + CFI_ADJUST_CFA_OFFSET -4 + CFI_RESTORE edi popl %ecx # equivalent to addl $4,%esp + CFI_ADJUST_CFA_OFFSET -4 ret + CFI_ENDPROC +ENDPROC(csum_partial_copy_generic) #else @@ -421,10 +457,17 @@ DST( movb %cl, (%edi)) #define ARGBASE 12 -csum_partial_copy_generic: +ENTRY(csum_partial_copy_generic) + CFI_STARTPROC pushl %ebx + CFI_ADJUST_CFA_OFFSET 4 + CFI_REL_OFFSET ebx, 0 pushl %edi + CFI_ADJUST_CFA_OFFSET 4 + CFI_REL_OFFSET edi, 0
Re: 2.6.21-rc5-mm3
On Sunday, 1 April 2007 22:39, Rafael J. Wysocki wrote: > On Sunday, 1 April 2007 21:03, Andrew Morton wrote: > > On Sun, 01 Apr 2007 18:00:12 +0200 Michal Piotrowski <[EMAIL PROTECTED]> > > wrote: > > > > > Andrew Morton napisał(a): > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/ > > > > > > > > > > BUG: at /mnt/md0/devel/linux-mm/arch/i386/kernel/smp.c:571 > > > native_smp_call_function_mask() > > > [] dump_trace+0x63/0x1eb > > > [] show_trace_log_lvl+0x1a/0x30 > > > [] show_trace+0x12/0x14 > > > [] dump_stack+0x16/0x18 > > > [] native_smp_call_function_mask+0x57/0x14b > > > [] smp_call_function+0x1e/0x22 > > > [] on_each_cpu+0x2a/0x73 > > > [] clock_was_set+0x1b/0x1d > > > [] timekeeping_resume+0xb5/0xbb > > > [] __sysdev_resume+0x17/0x5d > > > [] sysdev_resume+0x19/0x4b > > > [] device_power_up+0xb/0x12 > > > [] swsusp_suspend+0x55/0x63 > > > [] pm_suspend_disk+0x163/0x28f > > > [] enter_state+0x54/0x1d5 > > > [] state_store+0x86/0x9c > > > [] subsys_attr_store+0x23/0x2b > > > [] sysfs_write_file+0xc1/0xe9 > > > [] vfs_write+0xd1/0x15a > > > [] sys_write+0x3d/0x72 > > > [] syscall_call+0x7/0xb > > > [] 0xb7f9b410 > > > > 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. > > Well, not everything, but device_power_down()/device_power_up() which only > handle sysdevs. > > > 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? > > Yes, and it has always done it. It even is documented in > Documentation/power/devices.txt:System Devices . ;-) 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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3
On Sunday, 1 April 2007 22:39, Rafael J. Wysocki wrote: > On Sunday, 1 April 2007 21:03, Andrew Morton wrote: > > On Sun, 01 Apr 2007 18:00:12 +0200 Michal Piotrowski <[EMAIL PROTECTED]> > > wrote: > > > > > Andrew Morton napisał(a): > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/ > > > > > > > > > > BUG: at /mnt/md0/devel/linux-mm/arch/i386/kernel/smp.c:571 > > > native_smp_call_function_mask() > > > [] dump_trace+0x63/0x1eb > > > [] show_trace_log_lvl+0x1a/0x30 > > > [] show_trace+0x12/0x14 > > > [] dump_stack+0x16/0x18 > > > [] native_smp_call_function_mask+0x57/0x14b > > > [] smp_call_function+0x1e/0x22 > > > [] on_each_cpu+0x2a/0x73 > > > [] clock_was_set+0x1b/0x1d > > > [] timekeeping_resume+0xb5/0xbb > > > [] __sysdev_resume+0x17/0x5d > > > [] sysdev_resume+0x19/0x4b > > > [] device_power_up+0xb/0x12 > > > [] swsusp_suspend+0x55/0x63 > > > [] pm_suspend_disk+0x163/0x28f > > > [] enter_state+0x54/0x1d5 > > > [] state_store+0x86/0x9c > > > [] subsys_attr_store+0x23/0x2b > > > [] sysfs_write_file+0xc1/0xe9 > > > [] vfs_write+0xd1/0x15a > > > [] sys_write+0x3d/0x72 > > > [] syscall_call+0x7/0xb > > > [] 0xb7f9b410 > > > > 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. > > Well, not everything, but device_power_down()/device_power_up() which only > handle sysdevs. > > > 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? > > Yes, and it has always done it. It even is documented in > Documentation/power/devices.txt:System Devices . ;-) > > > 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. > > I think timekeeping_resume() shouldn't call smp_call_function() ... ... which even is unnecessary, because sysdev_resume() runs on _one_ CPU. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3
On Sunday, 1 April 2007 21:03, Andrew Morton wrote: > On Sun, 01 Apr 2007 18:00:12 +0200 Michal Piotrowski <[EMAIL PROTECTED]> > wrote: > > > Andrew Morton napisał(a): > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/ > > > > > > > BUG: at /mnt/md0/devel/linux-mm/arch/i386/kernel/smp.c:571 > > native_smp_call_function_mask() > > [] dump_trace+0x63/0x1eb > > [] show_trace_log_lvl+0x1a/0x30 > > [] show_trace+0x12/0x14 > > [] dump_stack+0x16/0x18 > > [] native_smp_call_function_mask+0x57/0x14b > > [] smp_call_function+0x1e/0x22 > > [] on_each_cpu+0x2a/0x73 > > [] clock_was_set+0x1b/0x1d > > [] timekeeping_resume+0xb5/0xbb > > [] __sysdev_resume+0x17/0x5d > > [] sysdev_resume+0x19/0x4b > > [] device_power_up+0xb/0x12 > > [] swsusp_suspend+0x55/0x63 > > [] pm_suspend_disk+0x163/0x28f > > [] enter_state+0x54/0x1d5 > > [] state_store+0x86/0x9c > > [] subsys_attr_store+0x23/0x2b > > [] sysfs_write_file+0xc1/0xe9 > > [] vfs_write+0xd1/0x15a > > [] sys_write+0x3d/0x72 > > [] syscall_call+0x7/0xb > > [] 0xb7f9b410 > > 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. Well, not everything, but device_power_down()/device_power_up() which only handle sysdevs. > 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? Yes, and it has always done it. It even is documented in Documentation/power/devices.txt:System Devices . ;-) > 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. I think timekeeping_resume() shouldn't call smp_call_function() ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3
On Sun, 01 Apr 2007 18:00:12 +0200 Michal Piotrowski <[EMAIL PROTECTED]> wrote: > Andrew Morton napisał(a): > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/ > > > > BUG: at /mnt/md0/devel/linux-mm/arch/i386/kernel/smp.c:571 > native_smp_call_function_mask() > [] dump_trace+0x63/0x1eb > [] show_trace_log_lvl+0x1a/0x30 > [] show_trace+0x12/0x14 > [] dump_stack+0x16/0x18 > [] native_smp_call_function_mask+0x57/0x14b > [] smp_call_function+0x1e/0x22 > [] on_each_cpu+0x2a/0x73 > [] clock_was_set+0x1b/0x1d > [] timekeeping_resume+0xb5/0xbb > [] __sysdev_resume+0x17/0x5d > [] sysdev_resume+0x19/0x4b > [] device_power_up+0xb/0x12 > [] swsusp_suspend+0x55/0x63 > [] pm_suspend_disk+0x163/0x28f > [] enter_state+0x54/0x1d5 > [] state_store+0x86/0x9c > [] subsys_attr_store+0x23/0x2b > [] sysfs_write_file+0xc1/0xe9 > [] vfs_write+0xd1/0x15a > [] sys_write+0x3d/0x72 > [] syscall_call+0x7/0xb > [] 0xb7f9b410 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3
Andrew Morton napisał(a):
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/
>
BUG: at /mnt/md0/devel/linux-mm/arch/i386/kernel/smp.c:571
native_smp_call_function_mask()
[] dump_trace+0x63/0x1eb
[] show_trace_log_lvl+0x1a/0x30
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] native_smp_call_function_mask+0x57/0x14b
[] smp_call_function+0x1e/0x22
[] on_each_cpu+0x2a/0x73
[] clock_was_set+0x1b/0x1d
[] timekeeping_resume+0xb5/0xbb
[] __sysdev_resume+0x17/0x5d
[] sysdev_resume+0x19/0x4b
[] device_power_up+0xb/0x12
[] swsusp_suspend+0x55/0x63
[] pm_suspend_disk+0x163/0x28f
[] enter_state+0x54/0x1d5
[] state_store+0x86/0x9c
[] subsys_attr_store+0x23/0x2b
[] sysfs_write_file+0xc1/0xe9
[] vfs_write+0xd1/0x15a
[] sys_write+0x3d/0x72
[] syscall_call+0x7/0xb
[] 0xb7f9b410
===
BUG: using smp_processor_id() in preemptible [0001] code:
swsusp_shutdown/3246
caller is setup_apic_nmi_watchdog+0x13/0x423
[] dump_trace+0x63/0x1eb
[] show_trace_log_lvl+0x1a/0x30
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] debug_smp_processor_id+0xb3/0xc8
[] setup_apic_nmi_watchdog+0x13/0x423
[] lapic_nmi_resume+0x16/0x1f
[] __sysdev_resume+0x17/0x5d
[] sysdev_resume+0x19/0x4b
[] device_power_up+0xb/0x12
[] swsusp_suspend+0x55/0x63
[] pm_suspend_disk+0x163/0x28f
[] enter_state+0x54/0x1d5
[] state_store+0x86/0x9c
[] subsys_attr_store+0x23/0x2b
[] sysfs_write_file+0xc1/0xe9
[] vfs_write+0xd1/0x15a
[] sys_write+0x3d/0x72
[] syscall_call+0x7/0xb
[] 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 release_perfctr_nmi(wd->perfctr_msr);
789 }
790
791 void setup_apic_nmi_watchdog (void *unused)
792 {
793 struct nmi_watchdog_ctlblk *wd =
&__get_cpu_var(nmi_watchdog_ctlblk);
794
795 /* only support LOCAL and IO APICs for now */
796 if ((nmi_watchdog != NMI_LOCAL_APIC) &&
797 (nmi_watchdog != NMI_IO_APIC))
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5-mm3/mm-console3.log
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5-mm3/mm-config2
Regards,
Michal
--
Michal K. K. Piotrowski
Hurd Testers Group
(http://www.hurdtestersgroup.org/)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
On Sun, 01 Apr 2007 00:15:51 -0600 [EMAIL PROTECTED] (Eric W. Biederman) wrote: > Does anyone know how to express the constraint of a 2M aligned number in > Kconfig? 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
[EMAIL PROTECTED] writes: > 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? 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
From: Andrew Morton <[EMAIL PROTECTED]> Date: Sat, Mar 31, 2007 at 12:53:03AM -0700 > On Sat, 31 Mar 2007 09:12:20 +0200 Helge Hafting <[EMAIL PROTECTED]> wrote: > > > 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 > > > > That's new. Does changing the value of CONFIG_RELOCATABLE change anything? > > Please send the .config. > 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 # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y # CONFIG_VM_EVENT_COUNTERS is not set CONFIG_CLASSIC_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_TRACE is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set CONFIG_PAGE_GROUP_BY_MOBILITY=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Process debugging support # CONFIG_UTRACE=y CONFIG_PTRACE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y # CONFIG_IOSCHED_DEADLINE is not set # CONFIG_IOSCHED_CFQ is not set CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y # CONFIG_NUMA is not set CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ADAPTIVE_READAHEAD=y CONFIG_NR_CPUS=2 # CONFIG_HOTPLUG_CPU is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_INTEL is not set CONFIG_X86_MCE_AMD=y # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x10 CONFIG_SECCOMP=y # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # C
Re: Fw: Re: 2.6.21-rc5-mm3
On 31/03/07, Michal Piotrowski <[EMAIL PROTECTED]> wrote: > Were there any strange binutils in use, Michal? I don't remember when I had problems with this compiler. ^^^ (sorry, to many bottles of beer) ld --version GNU ld version 2.17.50.0.6-2.fc6 20061020 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/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: Re: 2.6.21-rc5-mm3
Andi Kleen napisał(a): >> BUG: NMI Watchdog detected LOCKUP on CPU0, eip c014ce9c, registers: > > I suspect it is just because his console is too slow and then unwinding > took too long and it happened to hit the unwinder. > > You did use a slow console, right? console=ttyS0,115200n8 > > I suppose it just needs a strategic touch_nmi_watchdog. Will add that. > >> Modules linked in: ide_cd cdrom rtc unix >> CPU:0 >> EIP:0060:[]Not tainted VLI >> EFLAGS: 0093 (2.6.21-rc5-mm3 #10) >> EIP is at read_pointer+0x49/0x2d8 >> eax: c7a8dd04 ebx: ecx: 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: 000b c7a8dc70 c7a8dbf4 c014d6d0 c7a8dd04 c043e454 c7a8dbf4 >> c011fdd1 >>c043e404 c043e454 c043d190 0005cd94 c043d184 c7a8dd04 c7a8dd14 >> c014dd3a >> c7a8df44 c7a8dd74 c741eefb >> 0008 >> Call Trace: >> [] unwind+0x414/0xfa2 >> [] dump_trace_unwind+0xb4/0xe5 >> [] unwind_init_running+0x25/0x2b >> [] dump_trace+0x63/0x1eb >> [] save_stack_trace+0x23/0x42 >> [] update_cpu_base_expires_next+0x56/0x5a >> [] hrtimer_interrupt+0x17c/0x1b8 >> [] smp_apic_timer_interrupt+0x72/0x85 >> [] apic_timer_interrupt+0x33/0x38 >> [] lock_release+0x1d2/0x1da >> [] up_read+0x19/0x2e >> [] do_page_fault+0x28f/0x55b >> [] error_code+0x79/0x80 >> [] __put_user_4+0x12/0x18 >> DWARF2 unwinder stuck at __put_user_4+0x12/0x18 >> Leftover inexact backtrace: >> [] ret_from_fork+0x6/0x1c > > Hmpf. I saw it once in child_rip here too. Then I wanted to reproduce it to > report > properly and couldn't again. I had a few other backtraces that were all non > stuck > with child_rip then on essentially the same kernel. Something weird is going > on. > >> [] hrtimer_interrupt+0x17c/0x1b8 >> [] smp_apic_timer_interrupt+0x72/0x85 >> [] apic_timer_interrupt+0x33/0x38 >> [] __get_user_4+0x14/0x17 >> DWARF2 unwinder stuck at __get_user_4+0x14/0x17 >> Leftover inexact backtrace: > > Now that is weird. Never seen before. Jan, any ideas? > > What is your gcc/compiler, Michal? gcc --version gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-51) > > -Andi > > > Were there any strange binutils in use, Michal? I don't remember when I had problems with this compiler. > >> [] do_execve+0xdd/0x210 >> [] sys_execve+0x3f/0x62 >> [] sysenter_past_esp+0x5f/0x99 > 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/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: Re: 2.6.21-rc5-mm3
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > [] ret_from_fork+0x6/0x1c
>
> Hmpf. I saw it once in child_rip here too. Then I wanted to reproduce
> it to report properly and couldn't again. I had a few other backtraces
> that were all non stuck with child_rip then on essentially the same
> kernel. Something weird is going on.
find below a colorful unwinder crash, on an i386 UNWIND_STACK +
FRAME_POINTERS kernel. It crashed on the context-> dereference:
/* Should be after the line below, but somewhere
in early boot context comes out corrupted and we
can't reference it -AK */
if (ops->stack(data, "IRQ") < 0)
break;
stack = (unsigned long*)context->previous_esp;
if (!stack)
break;
the comment suggests that such a crash isnt without precedence, but my
crash wasnt during early bootup, it was on a working system.
Ingo
-->
[] dump_trace+0x78/0x210
[] show_trace_log_lvl+0x35/0x54
[] show_trace+0x2c/0x2e
[] dump_stack+0x29/0x2b
[] check_critical_timing+0x26a/0x37e
[] time_hardirqs_on+0xac/0xc2
[] trace_hardirqs_on+0x16b/0x172
[] restore_nocheck+0x12/0x15
[] acpi_rs_get_address_common+0x63/0x71
[] init_thread_union+0x0/0x1000
DWARF2 unwinder stuck at init_thread_union+0x0/0x1000
Leftover inexact backtrace:
BUG: unable to handle kernel paging request at virtual address 70252034
printing eip:
c0106592
*pde =
stopped custom tracer.
Oops: [#1]
PREEMPT SMP
Modules linked in:
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010046 (2.6.21-rc5-rt6 #83)
EIP is at dump_trace+0x1c8/0x210
eax: ebx: c06bce10 ecx: fffd85a4 edx: c064728c
esi: 70252000 edi: 70252070 ebp: c06bce10 esp: c06bcda4
ds: 007b es: 007b fs: 00d8 gs: ss: 0068 preempt:0002
Process swapper (pid: 0, ti=c06bc000 task=c0645280 task.ti=c06bc000)
Stack: c055faad c059b2f4 c06bc000 c02ae350
c4b83528 007b 007b c06bc000 0060
c0645288 0068 c0645280 0835b643 c064728c c055faad c011c8f4
Call Trace:
[] show_trace_log_lvl+0x35/0x54
[] show_trace+0x2c/0x2e
[] dump_stack+0x29/0x2b
[] check_critical_timing+0x26a/0x37e
[] time_hardirqs_on+0xac/0xc2
[] trace_hardirqs_on+0x16b/0x172
[] restore_nocheck+0x12/0x15
[] acpi_rs_get_address_common+0x63/0x71
[] init_thread_union+0x0/0x1000
DWARF2 unwinder stuck at init_thread_union+0x0/0x1000
Leftover inexact backtrace:
BUG: unable to handle kernel paging request at virtual address 70252034
printing eip:
c0106592
*pde =
Oops: [#2]
PREEMPT SMP
Modules linked in:
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010046 (2.6.21-rc5-rt6 #83)
EIP is at dump_trace+0x1c8/0x210
eax: ebx: c06bcc34 ecx: fffd85b7 edx: c064728c
esi: 70252000 edi: 70252070 ebp: c06bcc34 esp: c06bcbc8
ds: 007b es: 007b fs: 00d8 gs: ss: 0068 preempt:0002
Process swapper (pid: 0, ti=c06bc000 task=c0645280 task.ti=c06bc000)
Stack: c0550554 c059b2f4 c06bc000 c02ae350
c4b83528 c064007b fffd007b c06400d8 c06bc000 0060
00010046 c0645288 0068 c0645280 0019 c064728c c0550554 c011c8f4
Call Trace:
[] show_trace_log_lvl+0x35/0x54
[] show_stack_log_lvl+0xad/0xc5
[] show_registers+0x227/0x31d
[] die+0x137/0x21d
[] do_page_fault+0x4c1/0x5a8
[] error_code+0x7c/0x84
[] dump_trace+0x1c8/0x210
[] show_trace_log_lvl+0x35/0x54
[] show_trace+0x2c/0x2e
[] dump_stack+0x29/0x2b
[] check_critical_timing+0x26a/0x37e
[] time_hardirqs_on+0xac/0xc2
[] trace_hardirqs_on+0x16b/0x172
[] restore_nocheck+0x12/0x15
[] acpi_rs_get_address_common+0x63/0x71
[] init_thread_union+0x0/0x1000
DWARF2 unwinder stuck at init_thread_union+0x0/0x1000
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
Andrew Morton <[EMAIL PROTECTED]> writes: > On Sat, 31 Mar 2007 09:12:20 +0200 Helge Hafting <[EMAIL PROTECTED]> wrote: > >> 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 >> > > That's new. Does changing the value of CONFIG_RELOCATABLE change anything? 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 for best performance. > Please send the .config. Please. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
On Sat, 31 Mar 2007 09:12:20 +0200 Helge Hafting <[EMAIL PROTECTED]> wrote: > 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 > That's new. Does changing the value of CONFIG_RELOCATABLE change anything? Please send the .config. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3: fix e1000 compilation
From: "Kok, Auke" <[EMAIL PROTECTED]> Date: Fri, 30 Mar 2007 10:27:50 -0700 > turns out that NETIF_F_TSO6 is defined even if CONFIG_IPV6 is turned > off, which is what broke e1000. That in itself might be a > problem. Perhaps this should be fixed in netdevice.h (gratuitous bad > inline patch below) but I'm not sure if people would appreciate > this, as it's rather ugly, and it gets all horrible when people > disable TCP protocol support... No, I don't think we should do this. We have the vlan acceleration flags available when 802.1Q is disabled, same situation, and just as valid. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: Re: 2.6.21-rc5-mm3
> > BUG: NMI Watchdog detected LOCKUP on CPU0, eip c014ce9c, registers: I suspect it is just because his console is too slow and then unwinding took too long and it happened to hit the unwinder. You did use a slow console, right? I suppose it just needs a strategic touch_nmi_watchdog. Will add that. > Modules linked in: ide_cd cdrom rtc unix > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 0093 (2.6.21-rc5-mm3 #10) > EIP is at read_pointer+0x49/0x2d8 > eax: c7a8dd04 ebx: ecx: 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: 000b c7a8dc70 c7a8dbf4 c014d6d0 c7a8dd04 c043e454 c7a8dbf4 > c011fdd1 >c043e404 c043e454 c043d190 0005cd94 c043d184 c7a8dd04 c7a8dd14 > c014dd3a > c7a8df44 c7a8dd74 c741eefb > 0008 > Call Trace: > [] unwind+0x414/0xfa2 > [] dump_trace_unwind+0xb4/0xe5 > [] unwind_init_running+0x25/0x2b > [] dump_trace+0x63/0x1eb > [] save_stack_trace+0x23/0x42 > [] update_cpu_base_expires_next+0x56/0x5a > [] hrtimer_interrupt+0x17c/0x1b8 > [] smp_apic_timer_interrupt+0x72/0x85 > [] apic_timer_interrupt+0x33/0x38 > [] lock_release+0x1d2/0x1da > [] up_read+0x19/0x2e > [] do_page_fault+0x28f/0x55b > [] error_code+0x79/0x80 > [] __put_user_4+0x12/0x18 > DWARF2 unwinder stuck at __put_user_4+0x12/0x18 > Leftover inexact backtrace: > [] ret_from_fork+0x6/0x1c Hmpf. I saw it once in child_rip here too. Then I wanted to reproduce it to report properly and couldn't again. I had a few other backtraces that were all non stuck with child_rip then on essentially the same kernel. Something weird is going on. > [] hrtimer_interrupt+0x17c/0x1b8 > [] smp_apic_timer_interrupt+0x72/0x85 > [] apic_timer_interrupt+0x33/0x38 > [] __get_user_4+0x14/0x17 > DWARF2 unwinder stuck at __get_user_4+0x14/0x17 > Leftover inexact backtrace: Now that is weird. Never seen before. Jan, any ideas? What is your gcc/compiler, Michal? -Andi Were there any strange binutils in use, Michal? > [] do_execve+0xdd/0x210 > [] sys_execve+0x3f/0x62 > [] sysenter_past_esp+0x5f/0x99 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3
On Fri, 2007-03-30 at 13:23 -0400, [EMAIL PROTECTED] wrote:
> On Fri, 30 Mar 2007 01:05:59 PDT, Andrew Morton said:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/
>
> Building with CONFIG_MAC80211_DEBUGFS=y but CONFIG_MAC80211_DEBUG_COUNTERS=n
> blows chunks on my box:
>
> CC [M] net/mac80211/debugfs.o
> net/mac80211/debugfs.c: In function ‘stats_wme_rx_queue_read’:
> net/mac80211/debugfs.c:266: error: ‘struct ieee80211_local’ has no member
> named ‘wme_rx_queue’
> net/mac80211/debugfs.c: In function ‘stats_wme_tx_queue_read’:
> net/mac80211/debugfs.c:286: error: ‘struct ieee80211_local’ has no member
> named ‘wme_tx_queue’
> make[2]: *** [net/mac80211/debugfs.o] 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 <[EMAIL PROTECTED]>
---
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.c2007-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 ieee80211_local *local)
@@ -419,13 +419,13 @@ void debugfs_hw_del(struct ieee80211_loc
DEBUGFS_STATS_DEL(rx_expand_skb_head2);
DEBUGFS_STATS_DEL(rx_handlers_fragments);
DEBUGFS_STATS_DEL(tx_status_drop);
+ DEBUGFS_STATS_DEL(wme_tx_queue);
+ DEBUGFS_STATS_DEL(wme_rx_queue);
#endif
DEBUGFS_STATS_DEL(dot11ACKFailureCount);
DEBUGFS_STATS_DEL(dot11RTSFailureCount);
DEBUGFS_STATS_DEL(dot11FCSErrorCount);
DEBUGFS_STATS_DEL(dot11RTSSuccessCount);
- DEBUGFS_STATS_DEL(wme_tx_queue);
- DEBUGFS_STATS_DEL(wme_rx_queue);
debugfs_remove(local->debugfs.statistics);
local->debugfs.statistics = NULL;
--- wireless-dev.orig/net/mac80211/ieee80211_i.h2007-03-28
22:58:07.635731699 +0200
+++ wireless-dev/net/mac80211/ieee80211_i.h 2007-03-28 22:58:20.591731699
+0200
@@ -647,13 +647,13 @@ struct ieee80211_local {
struct dentry *rx_expand_skb_head2;
struct dentry *rx_handlers_fragments;
struct dentry *tx_status_drop;
+ struct dentry *wme_tx_queue;
+ struct dentry *wme_rx_queue;
#endif
struct dentry *dot11ACKFailureCount;
struct dentry *dot11RTSFailureCount;
struct dentry *dot11FCSErrorCount;
struct dentry *dot11RTSSuccessCount;
- struct dentry *wme_tx_queue;
- struct dentry *wme_rx_queue;
} stats;
struct dentry *stations;
struct dentry *keys;
--- wireless-dev.orig/net/mac80211/debugfs_sta.c2007-03-28
22:59:49.973731699 +0200
+++ wireless-dev/net/mac80211/debugfs_sta.c 2007-03-28 23:00:22.353731699
+0200
@@ -222,8 +222,10 @@ void ieee80211_sta_debugfs_add(struct st
DEBUGFS_ADD(last_ack_ms);
DEBUGFS_ADD(inactive_ms);
DEBUGFS_ADD(last_seq_ctrl);
+#ifdef CONFIG_MAC80211_DEBUG_COUNTERS
DEBUGFS_ADD(wme_rx_queue);
DEBUGFS_ADD(wme_tx_queue);
+#endif
}
void ieee80211
Re: 2.6.21-rc5-mm3: fix e1000 compilation
Randy Dunlap wrote: On Fri, 30 Mar 2007 10:01:04 -0700 Andrew Morton wrote: On Fri, 30 Mar 2007 07:39:04 -0700 "Kok, Auke" <[EMAIL PROTECTED]> wrote: Alexey Dobriyan wrote: CC [M] drivers/net/e1000/e1000_main.o drivers/net/e1000/e1000_main.c: In function 'e1000_tso': drivers/net/e1000/e1000_main.c:2968: error: dereferencing pointer to incomplete type ... can you send me your config? I'd like to see why nobody here didn't spot this on any of our tests. test.kernel.org got thoroughly broken by e1000, but Alexey's patch fixed things up. My daily/nightly builds were also broken by it... turns out that NETIF_F_TSO6 is defined even if CONFIG_IPV6 is turned off, which is what broke e1000. That in itself might be a problem. Perhaps this should be fixed in netdevice.h (gratuitous bad inline patch below) but I'm not sure if people would appreciate this, as it's rather ugly, and it gets all horrible when people disable TCP protocol support... In any case, I was not suspecting this at all. The patch to e1000 is fine with me. Auke --- diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 1a52854..f077137 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -331,10 +331,16 @@ struct net_device #define NETIF_F_UFO(SKB_GSO_UDP << NETIF_F_GSO_SHIFT) #define NETIF_F_GSO_ROBUST (SKB_GSO_DODGY << NETIF_F_GSO_SHIFT) #define NETIF_F_TSO_ECN(SKB_GSO_TCP_ECN << NETIF_F_GSO_SHIFT) +#ifdef CONFIG_IPV6 #define NETIF_F_TSO6 (SKB_GSO_TCPV6 << NETIF_F_GSO_SHIFT) +#endif /* List of features with software fallbacks. */ +#ifdef CONFIG_IPV6 #define NETIF_F_GSO_SOFTWARE (NETIF_F_TSO | NETIF_F_TSO_ECN | NETIF_F_TSO6) +#else +#define NETIF_F_GSO_SOFTWARE (NETIF_F_TSO | NETIF_F_TSO_ECN) +#endif #define NETIF_F_GEN_CSUM (NETIF_F_NO_CSUM | NETIF_F_HW_CSUM) #define NETIF_F_ALL_CSUM (NETIF_F_IP_CSUM | NETIF_F_GEN_CSUM) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3
On Fri, 30 Mar 2007 01:05:59 PDT, Andrew Morton said: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/ Building with CONFIG_MAC80211_DEBUGFS=y but CONFIG_MAC80211_DEBUG_COUNTERS=n blows chunks on my box: CC [M] net/mac80211/debugfs.o net/mac80211/debugfs.c: In function âstats_wme_rx_queue_readâ: net/mac80211/debugfs.c:266: error: âstruct ieee80211_localâ has no member named âwme_rx_queueâ net/mac80211/debugfs.c: In function âstats_wme_tx_queue_readâ: net/mac80211/debugfs.c:286: error: âstruct ieee80211_localâ has no member named âwme_tx_queueâ make[2]: *** [net/mac80211/debugfs.o] Error 1 pgpIyZRb7esVY.pgp Description: PGP signature
Re: 2.6.21-rc5-mm3
Ingo Molnar napisał(a):
> * Michal Piotrowski <[EMAIL PROTECTED]> wrote:
>
>> 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.
>
> 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:[]Not tainted VLI
EFLAGS: 0093 (2.6.21-rc5-mm3 #10)
EIP is at read_pointer+0x49/0x2d8
eax: c7a8dd04 ebx: ecx: 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: 000b c7a8dc70 c7a8dbf4 c014d6d0 c7a8dd04 c043e454 c7a8dbf4 c011fdd1
c043e404 c043e454 c043d190 0005cd94 c043d184 c7a8dd04 c7a8dd14 c014dd3a
c7a8df44 c7a8dd74 c741eefb 0008
Call Trace:
[] unwind+0x414/0xfa2
[] dump_trace_unwind+0xb4/0xe5
[] unwind_init_running+0x25/0x2b
[] dump_trace+0x63/0x1eb
[] save_stack_trace+0x23/0x42
[] update_cpu_base_expires_next+0x56/0x5a
[] hrtimer_interrupt+0x17c/0x1b8
[] smp_apic_timer_interrupt+0x72/0x85
[] apic_timer_interrupt+0x33/0x38
[] lock_release+0x1d2/0x1da
[] up_read+0x19/0x2e
[] do_page_fault+0x28f/0x55b
[] error_code+0x79/0x80
[] __put_user_4+0x12/0x18
DWARF2 unwinder stuck at __put_user_4+0x12/0x18
Leftover inexact backtrace:
[] 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 }
526 ptr.p8 = *pLoc;
527 switch(ptrType & DW_EH_PE_FORM) {
528 case DW_EH_PE_data2:
529 if (end < (const void *)(ptr.p16u + 1)) {
530 dprintk(1, "Data16 overrun (%p,%p).", ptr.p8,
end);
UNWIND_INFO stuff
BUG: NMI Watchdog detected LOCKUP<0>Kernel panic - not syncing: Aiee, killing
interrupt handler!
on CPU1, eip c014cd37, registers:
Modules linked in: ide_cd cdrom rtc unix
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 0012 (2.6.21-rc5-mm3 #10)
EIP is at cie_for_fde+0x45/0x65
eax: 0001c260 ebx: c04431f4 ecx: 0001c264 edx: 0010
esi: c04431f8 edi: c97f7da4 ebp: c97f7c94 esp: c97f7c8c
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process udevd (pid: 843, ti=c97f6000 task=c97f2ac0 task.ti=c97f6000)
Stack: 0003aac0 c045f458 c97f7db4 c014dd93 c97f3014 01cc
c97f7f0c c97f7e14 c741eefb 0008 c97f7f0c c04431f8 c020c184 c97f7f0c
c97f7f44 c97f7f44 0008 c0834780 c97f7d34 c0142dc8
Call Trace:
[] unwind+0x46d/0xfa2
[] dump_trace_unwind+0xb4/0xe5
[] unwind_init_running+0x25/0x2b
[] dump_trace+0x63/0x1eb
[] save_stack_trace+0x23/0x42
[] update_cpu_base_expires_next+0x56/0x5a
[] hrtimer_interrupt+0x17c/0x1b8
[] smp_apic_timer_interrupt+0x72/0x85
[] apic_timer_interrupt+0x33/0x38
[] __get_user_4+0x14/0x17
DWARF2 unwinder stuck at __get_user_4+0x14/0x17
Leftover inexact backtrace:
[] do_execve+0xdd/0x210
[] sys_execve+0x3f/0x62
[] sysenter_past_esp+0x5f/0x99
===
Code: c9 74 42 f6 c1 03 75 3b b8 04 00 00 00 2b 42 10 01 d8 39 c1 77 2d 89 c8
83 e0 fc 29 c3 8d 73 04 8b 53 04 83 fa 08 76 1b 8d 41 fc <39> c2 73 14 80 e2 03
75 0f 83 7e 04 00 74 0b eb 07 be ac 47 83
l *0xc014cd37
0xc014cd37 is in cie_for_fde (/mnt/md0/devel/linux-mm/kernel/unwind.c:498).
493 return ¬_fde; /* this is a CIE */
494 if ((fde[1] & (sizeof(*fde) - 1))
495 || fde[1] > (unsigned long)(fde + 1) - (unsigned
long)table->address)
496 return NULL; /* this is not a valid FDE */
497 cie = fde + 1 - fde[1] / sizeof(*fde);
498 if (*cie <= sizeof(*cie) + 4
499 || *cie >= fde[1] - sizeof(*fde)
500 || (*cie & (sizeof(*cie) - 1))
501 || cie[1])
502
Re: 2.6.21-rc5-mm3: fix e1000 compilation
On Fri, 30 Mar 2007 10:01:04 -0700 Andrew Morton wrote: > On Fri, 30 Mar 2007 07:39:04 -0700 "Kok, Auke" <[EMAIL PROTECTED]> wrote: > > > Alexey Dobriyan wrote: > > > CC [M] drivers/net/e1000/e1000_main.o > > > drivers/net/e1000/e1000_main.c: In function 'e1000_tso': > > > drivers/net/e1000/e1000_main.c:2968: error: dereferencing pointer to > > > incomplete type > > > ... > > > > > > > can you send me your config? I'd like to see why nobody here didn't spot > > this on > > any of our tests. > > > > test.kernel.org got thoroughly broken by e1000, but Alexey's patch fixed > things > up. My daily/nightly builds were also broken by it... --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3: fix e1000 compilation
On Fri, 30 Mar 2007 07:39:04 -0700 "Kok, Auke" <[EMAIL PROTECTED]> wrote: > Alexey Dobriyan wrote: > > CC [M] drivers/net/e1000/e1000_main.o > > drivers/net/e1000/e1000_main.c: In function 'e1000_tso': > > drivers/net/e1000/e1000_main.c:2968: error: dereferencing pointer to > > incomplete type > > ... > > > > can you send me your config? I'd like to see why nobody here didn't spot this > on > any of our tests. > test.kernel.org got thoroughly broken by e1000, but Alexey's patch fixed things up. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3
On Fri, 30 Mar 2007 12:38:11 -0400 "Dmitry Torokhov" <[EMAIL PROTECTED]> wrote: > On 3/30/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > 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 > > > > Andrew, > > Did you drop git-input? I do not see it anywhere > hm, odd, my git-input pull came up with a short changelog and no diff, so it was decided that the tree was empty. I don't know what could have caused that. Seems OK now though. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3
* Michal Piotrowski <[EMAIL PROTECTED]> wrote: > 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. hm. now that's a mystery ... Any way to figure out where it hangs? nmi_watchdog=1/2, softlockup, etc? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3
On 3/30/07, Andrew Morton <[EMAIL PROTECTED]> wrote: 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 Andrew, Did you drop git-input? I do not see it anywhere -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3
On 30/03/07, Andrew Morton <[EMAIL PROTECTED]> wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/ 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/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3: fix e1000 compilation
On Fri, Mar 30, 2007 at 07:39:04AM -0700, Kok, Auke wrote: > Alexey Dobriyan wrote: > > CC [M] drivers/net/e1000/e1000_main.o > >drivers/net/e1000/e1000_main.c: In function 'e1000_tso': > >drivers/net/e1000/e1000_main.c:2968: error: dereferencing pointer to > >incomplete type > > ... > > > > can you send me your config? I'd like to see why nobody here didn't spot > this on any of our tests. Sure... # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc5-mm3 # Fri Mar 30 13:00:57 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y # CONFIG_SWAP_PREFETCH is not set CONFIG_SYSVIPC=y CONFIG_IPC_NS=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set CONFIG_UTS_NS=y # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # 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 is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # CONFIG_PAGE_GROUP_BY_MOBILITY is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Process debugging support # CONFIG_UTRACE=y CONFIG_PTRACE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_X86_UP_APIC is not set CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_PAGE_OFFSET=0xC000 CONFIG_HIGHMEM=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_M
Re: 2.6.21-rc5-mm3: fix e1000 compilation
Alexey Dobriyan wrote: CC [M] drivers/net/e1000/e1000_main.o drivers/net/e1000/e1000_main.c: In function 'e1000_tso': drivers/net/e1000/e1000_main.c:2968: error: dereferencing pointer to incomplete type ... can you send me your config? I'd like to see why nobody here didn't spot this on any of our tests. thanks, Auke --- a/drivers/net/e1000/e1000_main.c +++ b/drivers/net/e1000/e1000_main.c @@ -32,6 +32,8 @@ #include #include #include #include +#include +#include #include #include #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm3
On Friday, 30 March 2007 10:05, Andrew Morton wrote: > > 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 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: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol __nf_conntrack_confirm WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol nf_ct_invert_tuple WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol per_cpu__nf_conntrack_ecache WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol nf_conntrack_l3proto_unregister WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol nf_ct_deliver_cached_events WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol __nf_ct_refresh_acct WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko needs unknown symbol nf_conntrack_in WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_rt.ko needs unknown symbol xt_register_match WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_rt.ko needs unknown symbol xt_unregister_match WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_owner.ko needs unknown symbol xt_register_match WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_owner.ko needs unknown symbol xt_unregister_match WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_mh.ko needs unknown symbol xt_register_match WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_mh.ko needs unknown symbol xt_unregister_match WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_ipv6header.ko needs unknown symbol xt_register_match WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_ipv6header.ko needs unknown symbol xt_unregister_match WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_hl.ko needs unknown symbol xt_register_match WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_hl.ko needs unknown symbol xt_unregister_match WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_hbh.ko needs unknown symbol xt_unregister_matches WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_hbh.ko needs unknown symbol xt_register_matches WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_frag.ko needs unknown symbol xt_register_match WARNING: /l
