* linux-next: Tree for July 30 @ 2009-07-30 8:21 Stephen Rothwell 2009-07-30 11:25 ` Boot failure on x86_64 (OOPS set_cpu_sibling_map() ) Sachin Sant 0 siblings, 1 reply; 12+ messages in thread From: Stephen Rothwell @ 2009-07-30 8:21 UTC (permalink / raw) To: linux-next; +Cc: LKML [-- Attachment #1: Type: text/plain, Size: 8553 bytes --] Hi all, Changes since 20090729: New trees: kmemleak (really this time - it was accidentally left out of yesterday's tree) Dropped tree: kmemleak (build problem) This tree fails to build for powerpc allyesconfig (final link problem). The scsi-rc-fixes tree gained a build failure so I reverted a commit. The i2c series failed to import so I used the version from next-20090729. The edac-amd tree gained a conflict against the rr tree. The fsnotify tree lost its conflict. The drbd tree lost one of its build failures. The kmemleak tree gained a build failure so I dropped it for today as I have no previous version to use. ---------------------------------------------------------------------------- I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES) and i386, sparc and sparc64 defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 135 trees (counting Linus' and 19 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Jan Dittmer for adding the linux-next tree to his build tests at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy Dunlap for doing many randconfig builds. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master Merging fixes/fixes Merging arm-current/master Merging m68k-current/for-linus Merging powerpc-merge/merge Merging sparc-current/master Merging scsi-rc-fixes/master Merging net-current/master Merging sound-current/for-linus Merging pci-current/for-linus Merging wireless-current/master Merging kbuild-current/master Merging quilt/driver-core.current Merging quilt/usb.current Merging cpufreq-current/fixes Merging input-current/for-linus Merging md-current/for-linus Merging audit-current/for-linus Merging crypto-current/master Merging dwmw2/master Merging arm/devel Merging davinci/for-next Merging pxa/for-next Merging thumb-2/thumb-2 Merging avr32/avr32-arch Merging blackfin/for-linus Merging cris/for-next Merging ia64/test Merging m68k/for-next Merging m68knommu/for-next Merging microblaze/next Merging mips/mips-for-linux-next CONFLICT (content): Merge conflict in arch/mips/cavium-octeon/dma-octeon.c CONFLICT (add/add): Merge conflict in arch/mips/cavium-octeon/executive/cvmx-helper-errata.c CONFLICT (content): Merge conflict in arch/mips/mm/tlbex.c CONFLICT (content): Merge conflict in arch/mips/sibyte/swarm/setup.c CONFLICT (content): Merge conflict in drivers/char/hw_random/Kconfig CONFLICT (content): Merge conflict in drivers/char/hw_random/Makefile CONFLICT (add/add): Merge conflict in drivers/dma/txx9dmac.c Merging parisc/master Merging powerpc/next Merging 4xx/next Merging galak/next Merging s390/features Merging sh/master Merging sparc/master Merging xtensa/master Merging cifs/master Merging configfs/linux-next CONFLICT (content): Merge conflict in fs/configfs/dir.c Merging ecryptfs/next Merging ext3/for_next Merging ext4/next Merging fatfs/master Merging fuse/for-next Merging gfs2/master Merging jfs/next Merging nfs/linux-next Merging nfsd/nfsd-next Merging nilfs2/for-next Merging ocfs2/linux-next Merging squashfs/master Merging v9fs/for-next Merging ubifs/linux-next Merging xfs/master Merging reiserfs-bkl/reiserfs/kill-bkl-rc6 CONFLICT (content): Merge conflict in fs/reiserfs/journal.c CONFLICT (content): Merge conflict in fs/reiserfs/super.c Merging vfs/for-next Merging pci/linux-next Merging hid/for-next Merging quilt/i2c CONFLICT (content): Merge conflict in drivers/i2c/chips/tsl2550.c Merging quilt/jdelvare-hwmon Merging quilt/kernel-doc Merging v4l-dvb/master CONFLICT (content): Merge conflict in arch/arm/mach-davinci/board-dm646x-evm.c CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm355.c CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm644x.c CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm646x.c CONFLICT (content): Merge conflict in arch/arm/mach-davinci/include/mach/dm355.h CONFLICT (content): Merge conflict in arch/arm/mach-davinci/include/mach/dm644x.h CONFLICT (content): Merge conflict in drivers/media/dvb/b2c2/flexcop-fe-tuner.c Merging quota/for_next Merging kbuild/master Merging ide/master Merging libata/NEXT Merging infiniband/for-next Merging acpi/test Merging ieee1394/for-next Merging ubi/linux-next Merging kvm/master Merging dlm/next Merging scsi/master Merging async_tx/next Merging udf/for_next Merging net/master CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl-3945.h CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl-tx.c CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl3945-base.c Merging wireless/master Merging mtd/master Merging crypto/master Merging sound/for-next Merging cpufreq/next Merging quilt/rr Merging mmc/next Merging input/next Merging lsm/for-next Merging block/for-next Merging quilt/device-mapper Merging embedded/master Merging firmware/master Merging pcmcia/master Merging battery/master Merging leds/for-mm Merging backlight/for-mm Merging kgdb/kgdb-next Merging slab/for-next Merging uclinux/for-next Merging md/for-next Merging mfd/for-next Merging hdlc/hdlc-next Merging drm/drm-next Merging voltage/for-next Merging security-testing/next Merging lblnet/master Merging agp/agp-next Merging uwb/for-upstream Merging watchdog/master Merging bdev/master Merging dwmw2-iommu/master Merging cputime/cputime Merging osd/linux-next Merging jc_docs/docs-next Merging nommu/master Merging trivial/for-next Merging audit/for-next Merging omap/for-next Merging quilt/aoe Merging suspend/linux-next Merging bluetooth/master Merging edac-amd/for-next CONFLICT (content): Merge conflict in include/linux/topology.h Merging fsnotify/for-next Merging irda/for-next Merging hwlat/for-linus Merging drbd/drbd Applying: drbd: fix for removal of blk_queue_stack_limits Merging kmemleak/kmemleak $ git reset --hard HEAD^ Merging tip/auto-latest CONFLICT (content): Merge conflict in drivers/oprofile/oprofile_stats.c CONFLICT (content): Merge conflict in include/linux/rcupdate.h Merging percpu/for-next CONFLICT (content): Merge conflict in arch/sh/kernel/vmlinux.lds.S CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/perf_counter.c CONFLICT (content): Merge conflict in drivers/cpufreq/cpufreq_ondemand.c Merging sfi/sfi-test Merging asm-generic/next Merging quilt/driver-core CONFLICT (content): Merge conflict in init/main.c Merging quilt/usb CONFLICT (content): Merge conflict in drivers/usb/gadget/m66592-udc.c CONFLICT (content): Merge conflict in drivers/usb/host/r8a66597-hcd.c Merging quilt/staging CONFLICT (delete/modify): drivers/staging/epl/VirtualEthernetLinux.c deleted in quilt/staging and modified in HEAD. Version HEAD of drivers/staging/epl/VirtualEthernetLinux.c left in tree. $ git rm -f drivers/staging/epl/VirtualEthernetLinux.c Merging scsi-post-merge/master [master 469ff03] Revert "[SCSI] libsas: fix wide port hotplug issues" [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Boot failure on x86_64 (OOPS set_cpu_sibling_map() ) 2009-07-30 8:21 linux-next: Tree for July 30 Stephen Rothwell @ 2009-07-30 11:25 ` Sachin Sant 2009-07-30 13:56 ` Borislav Petkov 0 siblings, 1 reply; 12+ messages in thread From: Sachin Sant @ 2009-07-30 11:25 UTC (permalink / raw) To: Stephen Rothwell; +Cc: linux-next, LKML, Ingo Molnar [-- Attachment #1: Type: text/plain, Size: 3477 bytes --] Today's Next failed to boot on a x86_64 box with following traces ACPI: Core revision 20090625 BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff81328c7b>] set_cpu_sibling_map+0x24f/0x353 PGD 0 Oops: 0002 [#1] SMP last sysfs file: CPU 0 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.31-rc4-autotest-next-20090730-5-default #1 BladeCenter LS21 -[79716AA]- RIP: 0010:[<ffffffff81328c7b>] [<ffffffff81328c7b>] set_cpu_sibling_map+0x24f/0x353 RSP: 0018:ffff88012b319e20 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000cbdc RDX: 000000000000cbf0 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88012b319e80 R08: 0000000000000004 R09: ffff880028092bc0 R10: 0000000000000000 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8800280362c0 R14: ffff8800280362c0 R15: 00000000000142c0 FS: 0000000000000000(0000) GS:ffff880028022000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000001001000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 1, threadinfo ffff88012b318000, task ffff88012b316000) Stack: 0000000000000003 000000000000cbe8 000000000000cbf8 000000000000cbf0 <0> 000000000000cbdc 00000000000142c0 0000000000000000 0000000000000003 <0> 0000000000000004 000000000000cbf8 000000000000cbe8 00000000000142c0 Call Trace: [<ffffffff81664c96>] native_smp_prepare_cpus+0x146/0x3b6 [<ffffffff8165b594>] kernel_init+0x84/0x1db [<ffffffff8100ca1a>] child_rip+0xa/0x20 [<ffffffff8165b510>] ? kernel_init+0x0/0x1db [<ffffffff8100ca10>] ? child_rip+0x0/0x20 Code: 00 00 48 89 c2 49 23 85 b0 00 00 00 49 23 96 b0 00 00 00 48 39 c2 75 2b 49 63 c4 48 8b 55 b8 48 8b 04 c5 90 fe 63 81 48 8b 04 02 <f0> 0f ab 18 48 63 c3 48 8b 04 c5 90 fe 63 81 48 8b 04 02 f0 44 RIP [<ffffffff81328c7b>] set_cpu_sibling_map+0x24f/0x353 RSP <ffff88012b319e20> CR2: 0000000000000000 ---[ end trace 4eaa2a86a8e2da22 ]--- Kernel panic - not syncing: Attempted to kill init! Pid: 1, comm: swapper Tainted: G D 2.6.31-rc4-autotest-next-20090730-5-default #1 Call Trace: [<ffffffff8132bc59>] panic+0x75/0x120 [<ffffffff8104f41a>] ? exit_ptrace+0x33/0x12b [<ffffffff810493c0>] do_exit+0x79/0x6c8 [<ffffffff8132f329>] oops_end+0xb3/0xbb [<ffffffff8102934f>] no_context+0x1ed/0x1fc [<ffffffff810294f0>] __bad_area_nosemaphore+0x192/0x1b8 [<ffffffff810ac967>] ? __alloc_pages_nodemask+0x118/0x57d [<ffffffff81029524>] bad_area_nosemaphore+0xe/0x10 [<ffffffff8133077f>] do_page_fault+0x187/0x2c6 [<ffffffff8132e86f>] page_fault+0x1f/0x30 [<ffffffff81328c7b>] ? set_cpu_sibling_map+0x24f/0x353 [<ffffffff81664c96>] native_smp_prepare_cpus+0x146/0x3b6 [<ffffffff8165b594>] kernel_init+0x84/0x1db [<ffffffff8100ca1a>] child_rip+0xa/0x20 [<ffffffff8165b510>] ? kernel_init+0x0/0x1db [<ffffffff8100ca10>] ? child_rip+0x0/0x20 The failure points to the following piece of code : if ((c->phys_proc_id == o->phys_proc_id) && (c->cpu_node_id == o->cpu_node_id)) { cpumask_set_cpu(i, cpu_node_mask(cpu)); << == cpumask_set_cpu(cpu, cpu_node_mask(i)); << == } Yesterday's Next tree worked fine. Have attached the boot log. Thanks -Sachin -- --------------------------------- Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India --------------------------------- [-- Attachment #2: boot-log --] [-- Type: text/plain, Size: 10511 bytes --] Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.31-rc4-autotest-next-20090730-5-default (root@mls21b) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP Thu Jul 30 14:47:18 IST 2009 Command line: root=/dev/sda1 console=tty0 console=ttyS1,19200 resume=/dev/disk/by-id/scsi-3500000e015c26a80-part2 splash=silent crashkernel=256M-:128M@16M IDENT=1248946314 KERNEL supported cpus: Intel GenuineIntel AMD AuthenticAMD Centaur CentaurHauls BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009c000 (usable) BIOS-e820: 000000000009c000 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 00000000cffa3900 (usable) BIOS-e820: 00000000cffa3900 - 00000000cffa7400 (ACPI data) BIOS-e820: 00000000cffa7400 - 00000000d0000000 (reserved) BIOS-e820: 00000000f4000000 - 00000000fc000000 (reserved) BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved) BIOS-e820: 0000000100000000 - 0000000130000000 (usable) DMI 2.4 present. last_pfn = 0x130000 max_arch_pfn = 0x400000000 x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 last_pfn = 0xcffa3 max_arch_pfn = 0x400000000 init_memory_mapping: 0000000000000000-00000000cffa3000 init_memory_mapping: 0000000100000000-0000000130000000 RAMDISK: 3771f000 - 37fef6c7 ACPI: RSDP 00000000000fdfe0 00014 (v00 IBM ) ACPI: RSDT 00000000cffa7380 00038 (v01 IBM SERLEWIS 00001000 IBM 45444F43) ACPI: FACP 00000000cffa72c0 00084 (v02 IBM SERLEWIS 00001000 IBM 45444F43) ACPI: DSDT 00000000cffa3900 036CE (v01 IBM SERLEWIS 00001000 INTL 20060912) ACPI: FACS 00000000cffa7040 00040 ACPI: APIC 00000000cffa7200 00090 (v01 IBM SERLEWIS 00001000 IBM 45444F43) ACPI: SRAT 00000000cffa7100 000E8 (v01 AMD HAMMER 00000001 AMD 00000001) ACPI: HPET 00000000cffa70c0 00038 (v01 IBM SERLEWIS 00001000 IBM 45444F43) ACPI: MCFG 00000000cffa7080 0003C (v01 IBM SERLEWIS 00001000 IBM 45444F43) SRAT: PXM 0 -> APIC 0 -> Node 0 SRAT: PXM 0 -> APIC 1 -> Node 0 SRAT: PXM 1 -> APIC 2 -> Node 1 SRAT: PXM 1 -> APIC 3 -> Node 1 SRAT: Node 0 PXM 0 0-a0000 SRAT: Node 0 PXM 0 100000-d0000000 SRAT: Node 0 PXM 0 100000000-130000000 Bootmem setup node 0 0000000000000000-0000000130000000 NODE_DATA [000000000000f640 - 000000000004363f] bootmap [0000000000044000 - 0000000000069fff] pages 26 (9 early reservations) ==> bootmem [0000000000 - 0130000000] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000] #1 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 - 0000008000] #2 [0001000000 - 0005d186b4] TEXT DATA BSS ==> [0001000000 - 0005d186b4] #3 [003771f000 - 0037fef6c7] RAMDISK ==> [003771f000 - 0037fef6c7] #4 [000009c000 - 0000100000] BIOS reserved ==> [000009c000 - 0000100000] #5 [0005d19000 - 0005d192d0] BRK ==> [0005d19000 - 0005d192d0] #6 [0000008000 - 000000c000] PGTABLE ==> [0000008000 - 000000c000] #7 [000000c000 - 000000d000] PGTABLE ==> [000000c000 - 000000d000] #8 [000000d000 - 000000f640] MEMNODEMAP ==> [000000d000 - 000000f640] found SMP MP-table at [ffff88000009c140] 9c140 crashkernel reservation failed - memory is in use Zone PFN ranges: DMA 0x00000000 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal 0x00100000 -> 0x00130000 Movable zone start PFN for each node early_node_map[3] active PFN ranges 0: 0x00000000 -> 0x0000009c 0: 0x00000100 -> 0x000cffa3 0: 0x00100000 -> 0x00130000 Detected use of extended apic ids on hypertransport bus Detected use of extended apic ids on hypertransport bus ACPI: PM-Timer IO Port: 0x488 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled) ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1]) ACPI: IOAPIC (id[0x0e] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 14, version 17, address 0xfec00000, GSI 0-15 ACPI: IOAPIC (id[0x0d] address[0xfec02000] gsi_base[16]) IOAPIC[1]: apic_id 13, version 17, address 0xfec02000, GSI 16-31 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) Using ACPI (MADT) for SMP configuration information ACPI: HPET id: 0x1166a201 base: 0xfed00000 SMP: Allowing 4 CPUs, 0 hotplug CPUs PM: Registered nosave memory: 000000000009c000 - 00000000000a0000 PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000 PM: Registered nosave memory: 00000000000e0000 - 0000000000100000 PM: Registered nosave memory: 00000000cffa3000 - 00000000cffa4000 PM: Registered nosave memory: 00000000cffa4000 - 00000000cffa7000 PM: Registered nosave memory: 00000000cffa7000 - 00000000cffa8000 PM: Registered nosave memory: 00000000cffa8000 - 00000000d0000000 PM: Registered nosave memory: 00000000d0000000 - 00000000f4000000 PM: Registered nosave memory: 00000000f4000000 - 00000000fc000000 PM: Registered nosave memory: 00000000fc000000 - 00000000fec00000 PM: Registered nosave memory: 00000000fec00000 - 0000000100000000 Allocating PCI resources starting at d0000000 (gap: d0000000:24000000) NR_CPUS:4096 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:2 PERCPU: Embedded 28 pages at ffff880028022000, static data 85408 bytes Built 1 zonelists in Node order, mobility grouping on. Total pages: 1031249 Policy zone: Normal Kernel command line: root=/dev/sda1 console=tty0 console=ttyS1,19200 resume=/dev/disk/by-id/scsi-3500000e015c26a80-part2 splash=silent crashkernel=256M-:128M@16M IDENT=1248946314 PID hash table entries: 4096 (order: 12, 32768 bytes) Initializing CPU#0 Checking aperture... No AGP bridge found Node 0: aperture @ f4000000 size 64 MB Node 1: aperture @ f4000000 size 64 MB Memory: 4045260k/4980736k available (3281k kernel code, 787204k absent, 148272k reserved, 3170k data, 1360k init) start_kernel(): bug: interrupts were enabled *very* early, fixing it Hierarchical RCU implementation. NR_IRQS:4352 Fast TSC calibration using PIT Detected 2199.723 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled console [ttyS1] enabled allocated 41943040 bytes of page_cgroup please try 'cgroup_disable=memory' option if you don't want memory cgroups HPET: 3 timers in total, 0 timers will be used for per-cpu timer Calibrating delay loop (skipped), value calculated using timer frequency.. 4399.44 BogoMIPS (lpj=8798892) Security Framework initialized SELinux: Disabled at boot. Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) Mount-cache hash table entries: 256 Initializing cgroup subsys ns Initializing cgroup subsys cpuacct Initializing cgroup subsys memory Initializing cgroup subsys devices Initializing cgroup subsys freezer CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 0/0x0 -> Node 0 CPU: Physical Processor ID: 0 CPU: Processor Node ID: 0 CPU: Processor Core ID: 0 mce: CPU supports 5 MCE banks using C1E aware idle routine Performance Counters: AMD PMU driver. ... version: 0 ... bit width: 48 ... generic counters: 4 ... value mask: 0000ffffffffffff ... max period: 00007fffffffffff ... fixed-purpose counters: 0 ... counter mask: 000000000000000f ACPI: Core revision 20090625 BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff81328c7b>] set_cpu_sibling_map+0x24f/0x353 PGD 0 Oops: 0002 [#1] SMP last sysfs file: CPU 0 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.31-rc4-autotest-next-20090730-5-default #1 BladeCenter LS21 -[79716AA]- RIP: 0010:[<ffffffff81328c7b>] [<ffffffff81328c7b>] set_cpu_sibling_map+0x24f/0x353 RSP: 0018:ffff88012b319e20 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000cbdc RDX: 000000000000cbf0 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88012b319e80 R08: 0000000000000004 R09: ffff880028092bc0 R10: 0000000000000000 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8800280362c0 R14: ffff8800280362c0 R15: 00000000000142c0 FS: 0000000000000000(0000) GS:ffff880028022000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000001001000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 1, threadinfo ffff88012b318000, task ffff88012b316000) Stack: 0000000000000003 000000000000cbe8 000000000000cbf8 000000000000cbf0 <0> 000000000000cbdc 00000000000142c0 0000000000000000 0000000000000003 <0> 0000000000000004 000000000000cbf8 000000000000cbe8 00000000000142c0 Call Trace: [<ffffffff81664c96>] native_smp_prepare_cpus+0x146/0x3b6 [<ffffffff8165b594>] kernel_init+0x84/0x1db [<ffffffff8100ca1a>] child_rip+0xa/0x20 [<ffffffff8165b510>] ? kernel_init+0x0/0x1db [<ffffffff8100ca10>] ? child_rip+0x0/0x20 Code: 00 00 48 89 c2 49 23 85 b0 00 00 00 49 23 96 b0 00 00 00 48 39 c2 75 2b 49 63 c4 48 8b 55 b8 48 8b 04 c5 90 fe 63 81 48 8b 04 02 <f0> 0f ab 18 48 63 c3 48 8b 04 c5 90 fe 63 81 48 8b 04 02 f0 44 RIP [<ffffffff81328c7b>] set_cpu_sibling_map+0x24f/0x353 RSP <ffff88012b319e20> CR2: 0000000000000000 ---[ end trace 4eaa2a86a8e2da22 ]--- Kernel panic - not syncing: Attempted to kill init! Pid: 1, comm: swapper Tainted: G D 2.6.31-rc4-autotest-next-20090730-5-default #1 Call Trace: [<ffffffff8132bc59>] panic+0x75/0x120 [<ffffffff8104f41a>] ? exit_ptrace+0x33/0x12b [<ffffffff810493c0>] do_exit+0x79/0x6c8 [<ffffffff8132f329>] oops_end+0xb3/0xbb [<ffffffff8102934f>] no_context+0x1ed/0x1fc [<ffffffff810294f0>] __bad_area_nosemaphore+0x192/0x1b8 [<ffffffff810ac967>] ? __alloc_pages_nodemask+0x118/0x57d [<ffffffff81029524>] bad_area_nosemaphore+0xe/0x10 [<ffffffff8133077f>] do_page_fault+0x187/0x2c6 [<ffffffff8132e86f>] page_fault+0x1f/0x30 [<ffffffff81328c7b>] ? set_cpu_sibling_map+0x24f/0x353 [<ffffffff81664c96>] native_smp_prepare_cpus+0x146/0x3b6 [<ffffffff8165b594>] kernel_init+0x84/0x1db [<ffffffff8100ca1a>] child_rip+0xa/0x20 [<ffffffff8165b510>] ? kernel_init+0x0/0x1db [<ffffffff8100ca10>] ? child_rip+0x0/0x20 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() ) 2009-07-30 11:25 ` Boot failure on x86_64 (OOPS set_cpu_sibling_map() ) Sachin Sant @ 2009-07-30 13:56 ` Borislav Petkov 2009-07-31 10:41 ` Sachin Sant 2009-08-03 9:31 ` Ingo Molnar 0 siblings, 2 replies; 12+ messages in thread From: Borislav Petkov @ 2009-07-30 13:56 UTC (permalink / raw) To: Sachin Sant; +Cc: Stephen Rothwell, linux-next, LKML, Ingo Molnar Hi, On Thu, Jul 30, 2009 at 04:55:44PM +0530, Sachin Sant wrote: > Today's Next failed to boot on a x86_64 box with following traces > > ACPI: Core revision 20090625 > BUG: unable to handle kernel NULL pointer dereference at (null) > IP: [<ffffffff81328c7b>] set_cpu_sibling_map+0x24f/0x353 I can't trigger it here, please send me your .config. In the meantime, you could try the following: -- diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index 3ede593..5fd57fe 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -1070,6 +1070,7 @@ void __init native_smp_prepare_cpus(unsigned int max_cpus) for_each_possible_cpu(i) { zalloc_cpumask_var(&per_cpu(cpu_sibling_map, i), GFP_KERNEL); zalloc_cpumask_var(&per_cpu(cpu_core_map, i), GFP_KERNEL); + zalloc_cpumask_var(&per_cpu(cpu_node_map, i), GFP_KERNEL); zalloc_cpumask_var(&cpu_data(i).llc_shared_map, GFP_KERNEL); } set_cpu_sibling_map(0); -- 1.6.3.3 -- Regards/Gruss, Boris. Operating | Advanced Micro Devices GmbH System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München (OSRC) | Registergericht München, HRB Nr. 43632 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() ) 2009-07-30 13:56 ` Borislav Petkov @ 2009-07-31 10:41 ` Sachin Sant 2009-08-03 9:31 ` Ingo Molnar 1 sibling, 0 replies; 12+ messages in thread From: Sachin Sant @ 2009-07-31 10:41 UTC (permalink / raw) To: Borislav Petkov; +Cc: Stephen Rothwell, linux-next, LKML, Ingo Molnar Borislav Petkov wrote: > I can't trigger it here, please send me your .config. In the meantime, > you could try the following: > > -- > diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c > index 3ede593..5fd57fe 100644 > --- a/arch/x86/kernel/smpboot.c > +++ b/arch/x86/kernel/smpboot.c > @@ -1070,6 +1070,7 @@ void __init native_smp_prepare_cpus(unsigned int max_cpus) > for_each_possible_cpu(i) { > zalloc_cpumask_var(&per_cpu(cpu_sibling_map, i), GFP_KERNEL); > zalloc_cpumask_var(&per_cpu(cpu_core_map, i), GFP_KERNEL); > + zalloc_cpumask_var(&per_cpu(cpu_node_map, i), GFP_KERNEL); > zalloc_cpumask_var(&cpu_data(i).llc_shared_map, GFP_KERNEL); > } > set_cpu_sibling_map(0); > Thanks for the patch Borislav. With this patch i can boot next on my x86_64 box. Regards -Sachin -- --------------------------------- Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India --------------------------------- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() ) 2009-07-30 13:56 ` Borislav Petkov 2009-07-31 10:41 ` Sachin Sant @ 2009-08-03 9:31 ` Ingo Molnar 2009-08-03 10:14 ` Borislav Petkov 1 sibling, 1 reply; 12+ messages in thread From: Ingo Molnar @ 2009-08-03 9:31 UTC (permalink / raw) To: Borislav Petkov, H. Peter Anvin, Thomas Gleixner Cc: Sachin Sant, Stephen Rothwell, linux-next, LKML, Ingo Molnar * Borislav Petkov <borislav.petkov@amd.com> wrote: > Hi, > > On Thu, Jul 30, 2009 at 04:55:44PM +0530, Sachin Sant wrote: > > Today's Next failed to boot on a x86_64 box with following traces > > > > ACPI: Core revision 20090625 > > BUG: unable to handle kernel NULL pointer dereference at (null) > > IP: [<ffffffff81328c7b>] set_cpu_sibling_map+0x24f/0x353 > > I can't trigger it here, please send me your .config. In the meantime, > you could try the following: > > -- > diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c > index 3ede593..5fd57fe 100644 > --- a/arch/x86/kernel/smpboot.c > +++ b/arch/x86/kernel/smpboot.c > @@ -1070,6 +1070,7 @@ void __init native_smp_prepare_cpus(unsigned int max_cpus) > for_each_possible_cpu(i) { > zalloc_cpumask_var(&per_cpu(cpu_sibling_map, i), GFP_KERNEL); > zalloc_cpumask_var(&per_cpu(cpu_core_map, i), GFP_KERNEL); > + zalloc_cpumask_var(&per_cpu(cpu_node_map, i), GFP_KERNEL); > zalloc_cpumask_var(&cpu_data(i).llc_shared_map, GFP_KERNEL); > } Borislav, this patch: From 4581c6313c16a38ffcef8bccd6ffbe9598d585b0 Mon Sep 17 00:00:00 2001 From: Andreas Herrmann <andreas.herrmann3@amd.com> Date: Fri, 24 Jul 2009 10:21:06 +0200 Subject: [PATCH] x86: provide CPU topology information for multi-node processors arch/x86/include/asm/processor.h | 2 ++ arch/x86/include/asm/smp.h | 6 ++++++ arch/x86/include/asm/topology.h | 2 ++ arch/x86/kernel/cpu/common.c | 2 ++ arch/x86/kernel/cpu/proc.c | 1 + arch/x86/kernel/smpboot.c | 20 ++++++++++++++++---- 6 files changed, 29 insertions(+), 4 deletions(-) has absolutely _ZERO_ place in the EDAC tree. It was submitted to the x86 tree and was under discussion - i requested changes to it so this current form has my NAK. Please remove it from your tree and generally require your contributors to submit all arch/x86 patches to the x86 maintainers. Thanks, Ingo ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() ) 2009-08-03 9:31 ` Ingo Molnar @ 2009-08-03 10:14 ` Borislav Petkov 2009-08-03 12:07 ` Ingo Molnar 0 siblings, 1 reply; 12+ messages in thread From: Borislav Petkov @ 2009-08-03 10:14 UTC (permalink / raw) To: Ingo Molnar Cc: H. Peter Anvin, Thomas Gleixner, Sachin Sant, Stephen Rothwell, linux-next, LKML, Ingo Molnar Hi Ingo, On Mon, Aug 03, 2009 at 11:31:44AM +0200, Ingo Molnar wrote: > Borislav, this patch: > > From 4581c6313c16a38ffcef8bccd6ffbe9598d585b0 Mon Sep 17 00:00:00 2001 > From: Andreas Herrmann <andreas.herrmann3@amd.com> > Date: Fri, 24 Jul 2009 10:21:06 +0200 > Subject: [PATCH] x86: provide CPU topology information for multi-node processors > > arch/x86/include/asm/processor.h | 2 ++ > arch/x86/include/asm/smp.h | 6 ++++++ > arch/x86/include/asm/topology.h | 2 ++ > arch/x86/kernel/cpu/common.c | 2 ++ > arch/x86/kernel/cpu/proc.c | 1 + > arch/x86/kernel/smpboot.c | 20 ++++++++++++++++---- > 6 files changed, 29 insertions(+), 4 deletions(-) > > has absolutely _ZERO_ place in the EDAC tree. It was submitted to > the x86 tree and was under discussion - i requested changes to it so > this current form has my NAK. I know that, I'm following the discussion. I needed the functionality in EDAC and that's why I added them _temporarily_ to the mix so that the whole series (esp. the MCE bits) can see some testing. Which obviously caught some issues :). But I'm very well aware that the patches are not final and they will go through x86 when done. This is what I told Stephen when upping them for linux-next. Sorry if I've caused any misunderstanding. -- Regards/Gruss, Boris. Operating | Advanced Micro Devices GmbH System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München (OSRC) | Registergericht München, HRB Nr. 43632 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() ) 2009-08-03 10:14 ` Borislav Petkov @ 2009-08-03 12:07 ` Ingo Molnar 2009-08-03 12:50 ` Borislav Petkov 0 siblings, 1 reply; 12+ messages in thread From: Ingo Molnar @ 2009-08-03 12:07 UTC (permalink / raw) To: Borislav Petkov, Andreas Herrmann Cc: H. Peter Anvin, Thomas Gleixner, Sachin Sant, Stephen Rothwell, linux-next, LKML, Ingo Molnar * Borislav Petkov <borislav.petkov@amd.com> wrote: > Hi Ingo, > > On Mon, Aug 03, 2009 at 11:31:44AM +0200, Ingo Molnar wrote: > > Borislav, this patch: > > > > From 4581c6313c16a38ffcef8bccd6ffbe9598d585b0 Mon Sep 17 00:00:00 2001 > > From: Andreas Herrmann <andreas.herrmann3@amd.com> > > Date: Fri, 24 Jul 2009 10:21:06 +0200 > > Subject: [PATCH] x86: provide CPU topology information for multi-node processors > > > > arch/x86/include/asm/processor.h | 2 ++ > > arch/x86/include/asm/smp.h | 6 ++++++ > > arch/x86/include/asm/topology.h | 2 ++ > > arch/x86/kernel/cpu/common.c | 2 ++ > > arch/x86/kernel/cpu/proc.c | 1 + > > arch/x86/kernel/smpboot.c | 20 ++++++++++++++++---- > > 6 files changed, 29 insertions(+), 4 deletions(-) > > > > has absolutely _ZERO_ place in the EDAC tree. It was submitted to > > the x86 tree and was under discussion - i requested changes to it so > > this current form has my NAK. > > I know that, I'm following the discussion. I needed the > functionality in EDAC and that's why I added them _temporarily_ to > the mix so that the whole series (esp. the MCE bits) can see some > testing. Which obviously caught some issues :). > > But I'm very well aware that the patches are not final and they > will go through x86 when done. This is what I told Stephen when > upping them for linux-next. Next time please tell the x86 maintainers too ;-) The thing that was blocking this commit is really the insufficient sched-domains integration of said NUMA bits. I think the NUMA bits look good and if the EDAC tree makes use of it we can merge it in .32. Mind preparing a separate branch for it (.31-rc5 based) and send me a pull request so that we can share the commit between the EDAC tree and the x86 tree? Thanks, Ingo ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() ) 2009-08-03 12:07 ` Ingo Molnar @ 2009-08-03 12:50 ` Borislav Petkov 2009-08-04 13:50 ` Ingo Molnar 0 siblings, 1 reply; 12+ messages in thread From: Borislav Petkov @ 2009-08-03 12:50 UTC (permalink / raw) To: Ingo Molnar Cc: Andreas Herrmann, H. Peter Anvin, Thomas Gleixner, Sachin Sant, Stephen Rothwell, linux-next, LKML, Ingo Molnar Hi Ingo, On Mon, Aug 03, 2009 at 02:07:39PM +0200, Ingo Molnar wrote: > The thing that was blocking this commit is really the insufficient > sched-domains integration of said NUMA bits. I think the NUMA bits > look good and if the EDAC tree makes use of it we can merge it in > .32. > > Mind preparing a separate branch for it (.31-rc5 based) and send me > a pull request so that we can share the commit between the EDAC tree > and the x86 tree? Well, Andreas says the patches need a little polishing and he'll be sending updated versions soon so you can pick them up. And since the EDAC MCE stuff might still change before .32 merge window opens, let's synchronize our pull requests instead. In the meantime, I'll be rediffing the EDAC stuff against -tip for linux-next. -- Regards/Gruss, Boris. Operating | Advanced Micro Devices GmbH System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München (OSRC) | Registergericht München, HRB Nr. 43632 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() ) 2009-08-03 12:50 ` Borislav Petkov @ 2009-08-04 13:50 ` Ingo Molnar 2009-08-04 14:31 ` Borislav Petkov 0 siblings, 1 reply; 12+ messages in thread From: Ingo Molnar @ 2009-08-04 13:50 UTC (permalink / raw) To: Borislav Petkov Cc: Andreas Herrmann, H. Peter Anvin, Thomas Gleixner, Sachin Sant, Stephen Rothwell, linux-next, LKML, Ingo Molnar * Borislav Petkov <borislav.petkov@amd.com> wrote: > Hi Ingo, > > On Mon, Aug 03, 2009 at 02:07:39PM +0200, Ingo Molnar wrote: > > The thing that was blocking this commit is really the insufficient > > sched-domains integration of said NUMA bits. I think the NUMA bits > > look good and if the EDAC tree makes use of it we can merge it in > > .32. > > > > Mind preparing a separate branch for it (.31-rc5 based) and send me > > a pull request so that we can share the commit between the EDAC tree > > and the x86 tree? > > Well, Andreas says the patches need a little polishing and he'll > be sending updated versions soon so you can pick them up. And > since the EDAC MCE stuff might still change before .32 merge > window opens, let's synchronize our pull requests instead. In the > meantime, I'll be rediffing the EDAC stuff against -tip for > linux-next. Would you rebase just due to this commit? No need for that, feel free to carry it until Andreas sends an updated version. Then i can put it into a separate .31-rc5 based topic that you can pull into the EDAC tree. That way there are no rebases really and no dependencies. Ingo ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() ) 2009-08-04 13:50 ` Ingo Molnar @ 2009-08-04 14:31 ` Borislav Petkov 2009-08-04 14:47 ` Ingo Molnar 0 siblings, 1 reply; 12+ messages in thread From: Borislav Petkov @ 2009-08-04 14:31 UTC (permalink / raw) To: Ingo Molnar Cc: Andreas Herrmann, H. Peter Anvin, Thomas Gleixner, Sachin Sant, Stephen Rothwell, linux-next, LKML, Ingo Molnar On Tue, Aug 04, 2009 at 03:50:29PM +0200, Ingo Molnar wrote: > > > Mind preparing a separate branch for it (.31-rc5 based) and send me > > > a pull request so that we can share the commit between the EDAC tree > > > and the x86 tree? > > > > Well, Andreas says the patches need a little polishing and he'll > > be sending updated versions soon so you can pick them up. And > > since the EDAC MCE stuff might still change before .32 merge > > window opens, let's synchronize our pull requests instead. In the > > meantime, I'll be rediffing the EDAC stuff against -tip for > > linux-next. > > Would you rebase just due to this commit? No, I wanted to keep the opportunity to be able to rebase the whole series until the very last minute before the merge window, should anything need to be changed... > No need for that, feel free to carry it until Andreas sends an updated > version. Then i can put it into a separate .31-rc5 based topic that > you can pull into the EDAC tree. ... and this is basically what I had in mind: After you pull them in, I'll rebase my branch against yours for linux-next. I see that Stephen pulls edac before -tip in linux-next so I'll ask him nicely to reorder those. This approach makes most sense anyways since edac relies on a bunch of x86 facilities (topology bits, rd/wrmsr_on_cpus, mcheck etc) and it is only natural that it goes second in linux-next, right? Then the pull requests will go out in the same order during the merge window and we should be fine. -- Regards/Gruss, Boris. Operating | Advanced Micro Devices GmbH System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München (OSRC) | Registergericht München, HRB Nr. 43632 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() ) 2009-08-04 14:31 ` Borislav Petkov @ 2009-08-04 14:47 ` Ingo Molnar 2009-08-04 15:00 ` Borislav Petkov 0 siblings, 1 reply; 12+ messages in thread From: Ingo Molnar @ 2009-08-04 14:47 UTC (permalink / raw) To: Borislav Petkov Cc: Andreas Herrmann, H. Peter Anvin, Thomas Gleixner, Sachin Sant, Stephen Rothwell, linux-next, LKML, Ingo Molnar * Borislav Petkov <borislav.petkov@amd.com> wrote: > On Tue, Aug 04, 2009 at 03:50:29PM +0200, Ingo Molnar wrote: > > > > Mind preparing a separate branch for it (.31-rc5 based) and send me > > > > a pull request so that we can share the commit between the EDAC tree > > > > and the x86 tree? > > > > > > Well, Andreas says the patches need a little polishing and he'll > > > be sending updated versions soon so you can pick them up. And > > > since the EDAC MCE stuff might still change before .32 merge > > > window opens, let's synchronize our pull requests instead. In the > > > meantime, I'll be rediffing the EDAC stuff against -tip for > > > linux-next. > > > > Would you rebase just due to this commit? > > No, I wanted to keep the opportunity to be able to rebase the > whole series until the very last minute before the merge window, > should anything need to be changed... Note that's the wrong workflow. We dont rebase Git trees really just because 'something needs to be changed' - we make sure all commits make sense, we fix bugs and append new changes to the end. That results in a far better end result than a constant rebasing workflow. See various mails from Linus on lkml about this topic. (i have no handy URL for this now - maybe someone else has) > > No need for that, feel free to carry it until Andreas sends an > > updated version. Then i can put it into a separate .31-rc5 based > > topic that you can pull into the EDAC tree. > > ... and this is basically what I had in mind: After you pull them > in, I'll rebase my branch against yours for linux-next. I see that > Stephen pulls edac before -tip in linux-next so I'll ask him > nicely to reorder those. This approach makes most sense anyways > since edac relies on a bunch of x86 facilities (topology bits, > rd/wrmsr_on_cpus, mcheck etc) and it is only natural that it goes > second in linux-next, right? > > Then the pull requests will go out in the same order during the > merge window and we should be fine. ok. I'll wait for Andreas's next version of the patch. Feel free to carry the interim version - just please dont crash the x86 bootup ;-) Ingo ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() ) 2009-08-04 14:47 ` Ingo Molnar @ 2009-08-04 15:00 ` Borislav Petkov 0 siblings, 0 replies; 12+ messages in thread From: Borislav Petkov @ 2009-08-04 15:00 UTC (permalink / raw) To: Ingo Molnar Cc: Andreas Herrmann, H. Peter Anvin, Thomas Gleixner, Sachin Sant, Stephen Rothwell, linux-next, LKML, Ingo Molnar On Tue, Aug 04, 2009 at 04:47:41PM +0200, Ingo Molnar wrote: > > * Borislav Petkov <borislav.petkov@amd.com> wrote: > > > On Tue, Aug 04, 2009 at 03:50:29PM +0200, Ingo Molnar wrote: > > > > > Mind preparing a separate branch for it (.31-rc5 based) and send me > > > > > a pull request so that we can share the commit between the EDAC tree > > > > > and the x86 tree? > > > > > > > > Well, Andreas says the patches need a little polishing and he'll > > > > be sending updated versions soon so you can pick them up. And > > > > since the EDAC MCE stuff might still change before .32 merge > > > > window opens, let's synchronize our pull requests instead. In the > > > > meantime, I'll be rediffing the EDAC stuff against -tip for > > > > linux-next. > > > > > > Would you rebase just due to this commit? > > > > No, I wanted to keep the opportunity to be able to rebase the > > whole series until the very last minute before the merge window, > > should anything need to be changed... > > Note that's the wrong workflow. We dont rebase Git trees really just > because 'something needs to be changed' - we make sure all commits > make sense, we fix bugs and append new changes to the end. That > results in a far better end result than a constant rebasing > workflow. See various mails from Linus on lkml about this topic. (i > have no handy URL for this now - maybe someone else has) Yep, that I know and I agree with completely, I'm simply waiting in case there are more comments on the subject (looka here, the last one was from you :o)). Also, considering that some aspects to the design aren't final, I'd like to be able to rebase. However, I'll make sure I switch to incremental workflow after the majority of the issues are agreed upon. > > > No need for that, feel free to carry it until Andreas sends an > > > updated version. Then i can put it into a separate .31-rc5 based > > > topic that you can pull into the EDAC tree. > > > > ... and this is basically what I had in mind: After you pull them > > in, I'll rebase my branch against yours for linux-next. I see > > that Stephen pulls edac before -tip in linux-next so I'll ask him > > nicely to reorder those. This approach makes most sense anyways > > since edac relies on a bunch of x86 facilities (topology bits, > > rd/wrmsr_on_cpus, mcheck etc) and it is only natural that it goes > > second in linux-next, right? > > > > Then the pull requests will go out in the same order during the > > merge window and we should be fine. > > ok. I'll wait for Andreas's next version of the patch. Feel free to > carry the interim version - just please dont crash the x86 bootup ;-) /me going to kick him to work faster :). -- Regards/Gruss, Boris. Operating | Advanced Micro Devices GmbH System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München (OSRC) | Registergericht München, HRB Nr. 43632 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2009-08-04 15:00 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-07-30 8:21 linux-next: Tree for July 30 Stephen Rothwell 2009-07-30 11:25 ` Boot failure on x86_64 (OOPS set_cpu_sibling_map() ) Sachin Sant 2009-07-30 13:56 ` Borislav Petkov 2009-07-31 10:41 ` Sachin Sant 2009-08-03 9:31 ` Ingo Molnar 2009-08-03 10:14 ` Borislav Petkov 2009-08-03 12:07 ` Ingo Molnar 2009-08-03 12:50 ` Borislav Petkov 2009-08-04 13:50 ` Ingo Molnar 2009-08-04 14:31 ` Borislav Petkov 2009-08-04 14:47 ` Ingo Molnar 2009-08-04 15:00 ` Borislav Petkov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).