linux-next: Tree for July 30

linux-next: Tree for July 30

[Stephen Rothwell]

[-- 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 --]

Boot failure on x86_64 (OOPS set_cpu_sibling_map() )

[Sachin Sant]

[-- 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

Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() )

[Borislav Petkov]

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

Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() )

[Sachin Sant]

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
---------------------------------

Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() )

[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

Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() )

[Borislav Petkov]

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

Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() )

[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

Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() )

[Borislav Petkov]

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

Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() )

[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

Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() )

[Borislav Petkov]

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

Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() )

[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

Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() )

[Borislav Petkov]

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