* sparc64 bootup regression...
@ 2008-04-30 6:12 David Miller
2008-04-30 6:38 ` Andrew Morton
2008-05-01 5:13 ` powerpc boot regression Tony Breeds
0 siblings, 2 replies; 22+ messages in thread
From: David Miller @ 2008-04-30 6:12 UTC (permalink / raw)
To: linux-kernel; +Cc: y-goto, akpm
[-- Attachment #1: Type: Text/Plain, Size: 1577 bytes --]
This commit causes bootup failures on sparc64:
commit 86f6dae1377523689bd8468fed2f2dd180fc0560
Author: Yasunori Goto <y-goto@jp.fujitsu.com>
Date: Mon Apr 28 02:13:33 2008 -0700
memory hotplug: allocate usemap on the section with pgdat
Usemaps are allocated on the section which has pgdat by this.
Because usemap size is very small, many other sections usemaps are allocated
on only one page. If a section has usemap, it can't be removed until removing
other sections. This dependency is not desirable for memory removing.
Pgdat has similar feature. When a section has pgdat area, it must be the last
section for removing on the node. So, if section A has pgdat and section B
has usemap for section A, Both sections can't be removed due to dependency
each other.
To solve this issue, this patch collects usemap on same section with pgdat.
If other sections doesn't have any dependency, this section will be able to be
removed finally.
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: Badari Pulavarty <pbadari@us.ibm.com>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: Yasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The machine in question has 64 cpus, and 16GB of ram. CONFIG_NUMA is
not set, and this platform uses sparsemem and vmemmap.
I attach two boot logs. The first is a successful boot, the second one
is a failing one due to the above commit:
[-- Attachment #2: good_boot.log --]
[-- Type: Text/Plain, Size: 20576 bytes --]
[ 0.000000] PROMLIB: Sun IEEE Boot Prom 'OBP 4.27.1 2007/09/14 15:17'
[ 0.000000] PROMLIB: Root node compatible: sun4v
[ 0.000000] Linux version 2.6.25 (davem@huronp11) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #124 SMP Tue Apr 29 22:43:36 PDT 2008
[ 0.000000] console [earlyprom0] enabled
[ 0.000000] ARCH: SUN4V
[ 0.000000] Ethernet address: 00:14:4f:3e:cb:f4
[ 0.000000] Kernel: Using 2 locked TLB entries for main kernel image.
[ 0.000000] Remapping the kernel... done.
[ 0.000000] OF stdout device is: /virtual-devices@100/console@1
[ 0.000000] PROM: Built device tree with 124723 bytes of memory.
[ 0.000000] MDESC: Size is 59392 bytes.
[ 0.000000] PLATFORM: banner-name [SPARC Enterprise T5220]
[ 0.000000] PLATFORM: name [SUNW,SPARC-Enterprise-T5220]
[ 0.000000] PLATFORM: hostid [803ecbf4]
[ 0.000000] PLATFORM: serial# [00ab4130]
[ 0.000000] PLATFORM: stick-frequency [546e74c8]
[ 0.000000] PLATFORM: mac-address [144f3ecbf4]
[ 0.000000] PLATFORM: watchdog-resolution [1000 ms]
[ 0.000000] PLATFORM: watchdog-max-timeout [31536000000 ms]
[ 0.000000] PLATFORM: max-cpus [64]
[ 0.000000] Top of RAM: 0x3ffb22000, Total RAM: 0x3f76c6000
[ 0.000000] Memory hole size: 132MB
[ 0.000000] Entering add_active_range(0, 16896, 2096466) 0 entries of 256 used
[ 0.000000] Entering add_active_range(0, 2096467, 2096477) 1 entries of 256 used
[ 0.000000] Entering add_active_range(0, 2096522, 2096529) 2 entries of 256 used
[ 0.000000] [0000000200000000-fffff80009000000] page_structs=131072 node=0 entry=0/0
[ 0.000000] [0000000200000000-fffff80009400000] page_structs=131072 node=0 entry=1/0
[ 0.000000] [0000000200700000-fffff80009800000] page_structs=131072 node=0 entry=2/0
[ 0.000000] [0000000200700000-fffff80009c00000] page_structs=131072 node=0 entry=3/0
[ 0.000000] [0000000200e00000-fffff8000a000000] page_structs=131072 node=0 entry=4/0
[ 0.000000] [0000000200e00000-fffff8000a400000] page_structs=131072 node=0 entry=5/0
[ 0.000000] [0000000201500000-fffff8000a800000] page_structs=131072 node=0 entry=6/0
[ 0.000000] [0000000201c00000-fffff8000ac00000] page_structs=131072 node=0 entry=7/0
[ 0.000000] [0000000201c00000-fffff8000b000000] page_structs=131072 node=0 entry=8/0
[ 0.000000] [0000000202300000-fffff8000b400000] page_structs=131072 node=0 entry=9/0
[ 0.000000] [0000000202300000-fffff8000b800000] page_structs=131072 node=0 entry=10/0
[ 0.000000] [0000000202a00000-fffff8000bc00000] page_structs=131072 node=0 entry=11/0
[ 0.000000] [0000000202a00000-fffff8000c000000] page_structs=131072 node=0 entry=12/0
[ 0.000000] [0000000203100000-fffff8000c400000] page_structs=131072 node=0 entry=13/0
[ 0.000000] [0000000203800000-fffff8000c800000] page_structs=131072 node=0 entry=14/0
[ 0.000000] [0000000203800000-fffff8000cc00000] page_structs=131072 node=0 entry=15/0
[ 0.000000] [0000000203f00000-fffff8000d000000] page_structs=131072 node=0 entry=16/0
[ 0.000000] [0000000203f00000-fffff8000d400000] page_structs=131072 node=0 entry=17/0
[ 0.000000] [0000000204600000-fffff8000d800000] page_structs=131072 node=0 entry=18/0
[ 0.000000] [0000000204600000-fffff8000dc00000] page_structs=131072 node=0 entry=19/0
[ 0.000000] [0000000204d00000-fffff8000e000000] page_structs=131072 node=0 entry=20/0
[ 0.000000] [0000000205400000-fffff8000e400000] page_structs=131072 node=0 entry=21/0
[ 0.000000] [0000000205400000-fffff8000e800000] page_structs=131072 node=0 entry=22/0
[ 0.000000] [0000000205b00000-fffff8000ec00000] page_structs=131072 node=0 entry=23/0
[ 0.000000] [0000000205b00000-fffff8000f000000] page_structs=131072 node=0 entry=24/0
[ 0.000000] [0000000206200000-fffff8000f400000] page_structs=131072 node=0 entry=25/0
[ 0.000000] [0000000206200000-fffff8000f800000] page_structs=131072 node=0 entry=26/0
[ 0.000000] [0000000206900000-fffff8000fc00000] page_structs=131072 node=0 entry=27/0
[ 0.000000] Zone PFN ranges:
[ 0.000000] Normal 16896 -> 2096529
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[3] active PFN ranges
[ 0.000000] 0: 16896 -> 2096466
[ 0.000000] 0: 2096467 -> 2096477
[ 0.000000] 0: 2096522 -> 2096529
[ 0.000000] On node 0 totalpages: 2079587
[ 0.000000] Normal zone: 14216 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 2065371 pages, LIFO batch:15
[ 0.000000] Movable zone: 0 pages used for memmap
[ 0.000000] Booting Linux...
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 2065371
[ 0.000000] Kernel command line: root=/dev/sda2 ro
[ 0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes)
[ 0.010000] clocksource: mult[b4b9] shift[16]
[ 0.010000] clockevent: mult[b550b0f2] shift[31]
[ 0.010000] Console: colour dummy device 80x25
[ 0.010000] console handover: boot [earlyprom0] -> real [tty0]
[ 0.011057] Dentry cache hash table entries: 2097152 (order: 11, 16777216 bytes)
[ 0.065074] Inode-cache hash table entries: 1048576 (order: 10, 8388608 bytes)
[ 0.623518] Memory: 16390776k available (2760k kernel code, 1048k data, 176k init) [fffff80000000000,00000003ffb22000]
[ 0.623658] SLUB: Genslabs=13, HWalign=32, Order=0-2, MinObjects=8, CPUs=64, Nodes=1
[ 0.770005] Calibrating delay using timer specific routine.. 2835.74 BogoMIPS (lpj=14178739)
[ 0.770222] Mount-cache hash table entries: 512
[ 0.795043] Brought up 64 CPUs
[ 0.803207] net_namespace: 584 bytes
[ 0.803236] ldc.c:v1.0 (June 25, 2007)
[ 0.805043] NET: Registered protocol family 16
[ 0.827893] VIO: Adding device channel-devices
[ 0.828084] VIO: Adding device vldc-port-3-0
[ 0.828257] VIO: Adding device vldc-port-3-1
[ 0.828426] VIO: Adding device vldc-port-3-2
[ 0.828605] VIO: Adding device vldc-port-3-3
[ 0.828776] VIO: Adding device vldc-port-3-4
[ 0.828951] VIO: Adding device vldc-port-3-5
[ 0.829123] VIO: Adding device vldc-port-3-8
[ 0.830000] VIO: Adding device vldc-port-2-0
[ 0.830183] VIO: Adding device vldc-port-0-0
[ 0.830366] VIO: Adding device vldc-port-0-1
[ 0.830544] VIO: Adding device vldc-port-0-2
[ 0.830721] VIO: Adding device vldc-port-1-0
[ 0.830916] VIO: Adding device ds-1
[ 0.831096] VIO: Adding device ds-0
[ 0.841623] PCI: Probing for controllers.
[ 0.841674] SUN4V_PCI: Registered hvapi major[1] minor[0]
[ 0.841954] /pci@0: SUN4V PCI Bus Module
[ 0.841974] /pci@0: On NUMA node -1
[ 0.841994] /pci@0: PCI IO[c810000000] MEM[ca00000000]
[ 0.886174] /pci@0: Imported 3 TSB entries from OBP
[ 0.887006] /pci@0: MSI Queue first[0] num[36] count[128] devino[0x18]
[ 0.887034] /pci@0: MSI first[0] num[256] mask[0xff] width[32]
[ 0.887059] /pci@0: MSI addr32[0x7fff0000:0x10000] addr64[0x3ffff0000:0x10000]
[ 0.887088] /pci@0: MSI queues at RA [00000003fe580000]
[ 0.887211] PCI: Scanning PBM /pci@0
[ 0.897158] ebus: No EBus's found.
[ 0.897733] ds.c:v1.0 (Jul 11, 2007)
[ 0.911670] SCSI subsystem initialized
[ 0.912152] usbcore: registered new interface driver usbfs
[ 0.912644] usbcore: registered new interface driver hub
[ 0.912938] usbcore: registered new device driver usb
[ 0.962602] NET: Registered protocol family 2
[ 0.970014] Switched to high resolution mode on CPU 0
[ 0.970026] Switched to high resolution mode on CPU 23
[ 0.970036] Switched to high resolution mode on CPU 50
[ 0.970376] Switched to high resolution mode on CPU 24
[ 0.970387] Switched to high resolution mode on CPU 51
[ 0.972938] ds-1: Registered pri service.
[ 0.972938] ds-1: Registered var-config-backup service.
[ 0.990010] Switched to high resolution mode on CPU 25
[ 0.990021] Switched to high resolution mode on CPU 52
[ 0.990031] Switched to high resolution mode on CPU 26
[ 0.990041] Switched to high resolution mode on CPU 53
[ 0.990052] Switched to high resolution mode on CPU 27
[ 0.990062] Switched to high resolution mode on CPU 54
[ 0.990366] Switched to high resolution mode on CPU 1
[ 0.990376] Switched to high resolution mode on CPU 28
[ 0.990386] Switched to high resolution mode on CPU 55
[ 0.991177] Switched to high resolution mode on CPU 2
[ 0.991186] Switched to high resolution mode on CPU 29
[ 0.991197] Switched to high resolution mode on CPU 56
[ 0.991207] Switched to high resolution mode on CPU 3
[ 0.991218] Switched to high resolution mode on CPU 30
[ 0.991228] Switched to high resolution mode on CPU 57
[ 0.991239] Switched to high resolution mode on CPU 4
[ 0.991249] Switched to high resolution mode on CPU 31
[ 0.991259] Switched to high resolution mode on CPU 58
[ 0.991269] Switched to high resolution mode on CPU 5
[ 0.991281] Switched to high resolution mode on CPU 32
[ 0.991291] Switched to high resolution mode on CPU 59
[ 0.991301] Switched to high resolution mode on CPU 6
[ 0.991312] Switched to high resolution mode on CPU 33
[ 0.991322] Switched to high resolution mode on CPU 60
[ 0.993265] Switched to high resolution mode on CPU 7
[ 0.993275] Switched to high resolution mode on CPU 34
[ 0.993286] Switched to high resolution mode on CPU 61
[ 0.993296] Switched to high resolution mode on CPU 8
[ 0.993307] Switched to high resolution mode on CPU 35
[ 0.993318] Switched to high resolution mode on CPU 62
[ 0.993882] Switched to high resolution mode on CPU 9
[ 0.993891] Switched to high resolution mode on CPU 36
[ 1.003899] Switched to high resolution mode on CPU 63
[ 1.003909] Switched to high resolution mode on CPU 10
[ 1.003919] Switched to high resolution mode on CPU 37
[ 1.003929] Switched to high resolution mode on CPU 11
[ 1.003940] Switched to high resolution mode on CPU 38
[ 1.003950] Switched to high resolution mode on CPU 12
[ 1.003961] Switched to high resolution mode on CPU 39
[ 1.003971] Switched to high resolution mode on CPU 13
[ 1.003982] Switched to high resolution mode on CPU 40
[ 1.003992] Switched to high resolution mode on CPU 14
[ 1.004003] Switched to high resolution mode on CPU 41
[ 1.004013] Switched to high resolution mode on CPU 15
[ 1.004024] Switched to high resolution mode on CPU 42
[ 1.004035] Switched to high resolution mode on CPU 16
[ 1.004045] Switched to high resolution mode on CPU 43
[ 1.004056] Switched to high resolution mode on CPU 17
[ 1.004066] Switched to high resolution mode on CPU 44
[ 1.004076] Switched to high resolution mode on CPU 18
[ 1.004086] Switched to high resolution mode on CPU 45
[ 1.004096] Switched to high resolution mode on CPU 19
[ 1.004106] Switched to high resolution mode on CPU 46
[ 1.004116] Switched to high resolution mode on CPU 20
[ 1.004126] Switched to high resolution mode on CPU 47
[ 1.004136] Switched to high resolution mode on CPU 21
[ 1.004147] Switched to high resolution mode on CPU 48
[ 1.004157] Switched to high resolution mode on CPU 22
[ 1.004168] Switched to high resolution mode on CPU 49
[ 1.105491] IP route cache hash table entries: 524288 (order: 9, 4194304 bytes)
[ 1.107748] TCP established hash table entries: 524288 (order: 10, 8388608 bytes)
[ 1.133623] TCP bind hash table entries: 65536 (order: 7, 1048576 bytes)
[ 1.138828] TCP: Hash tables configured (established 524288 bind 65536)
[ 1.138856] TCP reno registered
[ 1.166617] NET: Registered protocol family 1
[ 1.167464] Mini RTC Driver
[ 1.171082] Total HugeTLB memory allocated, 0
[ 1.197344] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
[ 1.197460] io scheduler noop registered
[ 1.197479] io scheduler anticipatory registered (default)
[ 1.197501] io scheduler deadline registered
[ 1.197830] io scheduler cfq registered
[ 1.198015] proc_dir_entry '00.0' already registered
[ 1.198036] Call Trace:
[ 1.198052] [00000000004f2534] create_proc_entry+0x7c/0x98
[ 1.198092] [00000000005719e4] pci_proc_attach_device+0xa4/0xd4
[ 1.198126] [00000000007d991c] pci_proc_init+0x64/0x88
[ 1.198158] [00000000007c62a4] kernel_init+0x190/0x330
[ 1.198183] [0000000000426cf8] kernel_thread+0x38/0x48
[ 1.198210] [00000000006a0d90] rest_init+0x18/0x5c
[ 1.212477] f0279bbc: ttyS0 at I/O 0x0 (irq = 17) is a SUN4V HCONS
[ 1.212506] console [ttyHV0] enabled
[ 1.695793] proc_dir_entry 'serial' already registered
[ 1.695839] Call Trace:
[ 1.831891] [00000000004f2534] create_proc_entry+0x7c/0x98
[ 1.833608] [00000000004f3a58] proc_tty_register_driver+0x40/0x70
[ 1.833663] [0000000000594700] tty_register_driver+0x1fc/0x208
[ 1.835371] [00000000005aade4] uart_register_driver+0x134/0x16c
[ 1.841762] [00000000005ac274] sunserial_register_minors+0x34/0x68
[ 1.841818] [00000000007db2a4] sunsu_init+0xf8/0x150
[ 1.867697] [00000000007c62a4] kernel_init+0x190/0x330
[ 1.939147] [0000000000426cf8] kernel_thread+0x38/0x48
[ 1.939198] [00000000006a0d90] rest_init+0x18/0x5c
[ 1.953254] f0288ed4: ttyS0 at MMIO 0xfff0ca0000 (irq = 24) is a 16550A
[ 1.959818] Uniform Multi-Platform E-IDE driver
[ 1.959857] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
[ 1.964215] Driver 'sd' needs updating - please use bus_type methods
[ 1.964681] Fusion MPT base driver 3.04.06
[ 1.964714] Copyright (c) 1999-2007 LSI Corporation
[ 1.964759] Fusion MPT SPI Host driver 3.04.06
[ 1.965026] Fusion MPT FC Host driver 3.04.06
[ 2.038302] Fusion MPT SAS Host driver 3.04.06
[ 2.038453] mptbase: ioc0: Initiating bringup
[ 3.598289] ioc0: LSISAS1068E B1: Capabilities={Initiator}
[ 3.608654] mptbase: ioc0: PCI-MSI enabled
[ 15.773660] scsi0 : ioc0: LSISAS1068E B1, FwRev=011400dbh, Ports=1, MaxQ=511, IRQ=89
[ 15.802521] scsi 0:0:0:0: Direct-Access SEAGATE ST973401LSUN72G 0556 PQ: 0 ANSI: 3
[ 15.805902] sd 0:0:0:0: [sda] 143374738 512-byte hardware sectors (73408 MB)
[ 15.807287] sd 0:0:0:0: [sda] Write Protect is off
[ 15.807403] sd 0:0:0:0: [sda] Mode Sense: e3 00 10 08
[ 15.808800] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
[ 15.809645] sd 0:0:0:0: [sda] 143374738 512-byte hardware sectors (73408 MB)
[ 15.813249] sd 0:0:0:0: [sda] Write Protect is off
[ 15.813386] sd 0:0:0:0: [sda] Mode Sense: e3 00 10 08
[ 15.814777] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
[ 15.814994] sda: sda1 sda2 sda3 sda4
[ 15.825854] sd 0:0:0:0: [sda] Attached SCSI disk
[ 15.829301] scsi 0:0:1:0: Direct-Access FUJITSU MAY2073RCSUN72G 0501 PQ: 0 ANSI: 4
[ 15.835766] sd 0:0:1:0: [sdb] 143374738 512-byte hardware sectors (73408 MB)
[ 15.837800] sd 0:0:1:0: [sdb] Write Protect is off
[ 15.837838] sd 0:0:1:0: [sdb] Mode Sense: d3 00 00 08
[ 15.839148] sd 0:0:1:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 15.839984] sd 0:0:1:0: [sdb] 143374738 512-byte hardware sectors (73408 MB)
[ 15.850987] sd 0:0:1:0: [sdb] Write Protect is off
[ 15.851024] sd 0:0:1:0: [sdb] Mode Sense: d3 00 00 08
[ 15.852328] sd 0:0:1:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 15.852546] sdb: sdb1 sdb2 sdb3
[ 15.868166] sd 0:0:1:0: [sdb] Attached SCSI disk
[ 15.872190] Fusion MPT misc device (ioctl) driver 3.04.06
[ 15.872571] mptctl: Registered with Fusion MPT base driver
[ 15.872698] mptctl: /dev/mptctl @ (major,minor=10,220)
[ 15.872965] ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
[ 15.873064] ohci_hcd 0000:07:00.0: OHCI Host Controller
[ 15.873338] ohci_hcd 0000:07:00.0: new USB bus registered, assigned bus number 1
[ 15.873441] ohci_hcd 0000:07:00.0: irq 22, io mem 0xca00300000
[ 15.933070] usb usb1: configuration #1 chosen from 1 choice
[ 15.933498] hub 1-0:1.0: USB hub found
[ 15.933639] hub 1-0:1.0: 3 ports detected
[ 16.040653] ohci_hcd 0000:07:00.1: OHCI Host Controller
[ 16.041055] ohci_hcd 0000:07:00.1: new USB bus registered, assigned bus number 2
[ 16.041227] ohci_hcd 0000:07:00.1: irq 23, io mem 0xca00302000
[ 16.102874] usb usb2: configuration #1 chosen from 1 choice
[ 16.103286] hub 2-0:1.0: USB hub found
[ 16.103422] hub 2-0:1.0: 2 ports detected
[ 16.211334] mice: PS/2 mouse device common for all mice
[ 16.213075] usbcore: registered new interface driver hiddev
[ 16.213457] usbcore: registered new interface driver usbhid
[ 16.213587] usbhid: v2.6:USB HID core driver
[ 16.215535] TCP cubic registered
[ 16.215648] NET: Registered protocol family 17
[ 16.244787] kjournald starting. Commit interval 5 seconds
[ 16.244787] EXT3-fs: mounted filesystem with ordered data mode.
[ 16.244817] VFS: Mounted root (ext3 filesystem) readonly.
[ 21.640822] e1000e: Intel(R) PRO/1000 Network Driver - 0.2.1
[ 21.641049] e1000e: Copyright (c) 1999-2008 Intel Corporation.
[ 21.641341] PCI: Enabling device: (0000:08:00.0), cmd 147
[ 21.655904] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 21.656265] sd 0:0:1:0: Attached scsi generic sg1 type 0
[ 21.852257] eth0: (PCI Express:2.5GB/s:Width x4) 00:14:4f:3e:cb:f4
[ 21.852479] eth0: Intel(R) PRO/1000 Network Connection
[ 21.852676] eth0: MAC: 0, PHY: 4, PBA No: ffffff-0ff
[ 21.852820] PCI: Enabling device: (0000:07:00.2), cmd 2
[ 21.852856] ehci_hcd 0000:07:00.2: EHCI Host Controller
[ 21.852998] ehci_hcd 0000:07:00.2: new USB bus registered, assigned bus number 3
[ 21.853234] PCI: Enabling device: (0000:08:00.1), cmd 147
[ 21.878911] ehci_hcd 0000:07:00.2: irq 20, io mem 0xca00304000
[ 21.898819] ehci_hcd 0000:07:00.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
[ 21.899394] usb usb3: configuration #1 chosen from 1 choice
[ 21.899614] hub 3-0:1.0: USB hub found
[ 21.899670] hub 3-0:1.0: 5 ports detected
[ 22.098571] eth1: (PCI Express:2.5GB/s:Width x4) 00:14:4f:3e:cb:f5
[ 22.098794] eth1: Intel(R) PRO/1000 Network Connection
[ 22.098992] eth1: MAC: 0, PHY: 4, PBA No: ffffff-0ff
[ 22.099132] PCI: Enabling device: (0000:09:00.0), cmd 147
[ 22.262472] warning: `dhclient3' uses 32-bit capabilities (legacy support in use)
[ 22.368271] eth1: (PCI Express:2.5GB/s:Width x4) 00:14:4f:3e:cb:f6
[ 22.368487] eth1: Intel(R) PRO/1000 Network Connection
[ 22.368685] eth1: MAC: 0, PHY: 4, PBA No: ffffff-0ff
[ 22.368840] PCI: Enabling device: (0000:09:00.1), cmd 147
[ 22.568009] usb 3-2: new high speed USB device using ehci_hcd and address 2
[ 22.591599] eth2: (PCI Express:2.5GB/s:Width x4) 00:14:4f:3e:cb:f7
[ 22.591808] eth2: Intel(R) PRO/1000 Network Connection
[ 22.592008] eth2: MAC: 0, PHY: 4, PBA No: ffffff-0ff
[ 22.736807] usb 3-2: configuration #1 chosen from 1 choice
[ 22.787592] Initializing USB Mass Storage driver...
[ 23.011308] usb 3-4: new high speed USB device using ehci_hcd and address 3
[ 23.162939] usb 3-4: configuration #1 chosen from 1 choice
[ 23.163641] hub 3-4:1.0: USB hub found
[ 23.164294] hub 3-4:1.0: 4 ports detected
[ 23.280914] scsi1 : SCSI emulation for USB Mass Storage devices
[ 23.281474] usb-storage: device found at 2
[ 23.281483] usb-storage: waiting for device to settle before scanning
[ 23.283015] usbcore: registered new interface driver usb-storage
[ 23.283273] USB Mass Storage support registered.
[ 23.726635] loop: module loaded
[ 23.975477] Adding 3084464k swap on /dev/sda4. Priority:-1 extents:1 across:3084464k
[ 24.242876] EXT3 FS on sda2, internal journal
[ 24.505868] eth0: Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[ 24.600589] kjournald starting. Commit interval 5 seconds
[ 24.605044] EXT3 FS on sda1, internal journal
[ 24.605063] EXT3-fs: mounted filesystem with ordered data mode.
[ 26.705883] NET: Registered protocol family 10
[ 26.709144] lo: Disabled Privacy Extensions
[ 28.835118] scsi 1:0:0:0: CD-ROM TSSTcorp CD/DVDW TS-T632A SR02 PQ: 0 ANSI: 0
[ 28.835666] scsi 1:0:0:0: Attached scsi generic sg2 type 5
[ 28.837821] usb-storage: device scan complete
[ 28.886072] Driver 'sr' needs updating - please use bus_type methods
[ 28.894477] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
[ 28.899626] Uniform CD-ROM driver Revision: 3.20
[ 28.899792] sr 1:0:0:0: Attached scsi CD-ROM sr0
[ 37.472196] eth0: no IPv6 routers present
[-- Attachment #3: failed_boot.log --]
[-- Type: Text/Plain, Size: 3881 bytes --]
[ 0.000000] PROMLIB: Sun IEEE Boot Prom 'OBP 4.27.1 2007/09/14 15:17'
[ 0.000000] PROMLIB: Root node compatible: sun4v
[ 0.000000] Linux version 2.6.25 (davem@huronp11) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #108 SMP Tue Apr 29 20:54:20 PDT 2008
[ 0.000000] console [earlyprom0] enabled
[ 0.000000] ARCH: SUN4V
[ 0.000000] Ethernet address: 00:14:4f:3e:cb:f4
[ 0.000000] Kernel: Using 2 locked TLB entries for main kernel image.
[ 0.000000] Remapping the kernel... done.
[ 0.000000] OF stdout device is: /virtual-devices@100/console@1
[ 0.000000] PROM: Built device tree with 124723 bytes of memory.
[ 0.000000] MDESC: Size is 59392 bytes.
[ 0.000000] PLATFORM: banner-name [SPARC Enterprise T5220]
[ 0.000000] PLATFORM: name [SUNW,SPARC-Enterprise-T5220]
[ 0.000000] PLATFORM: hostid [803ecbf4]
[ 0.000000] PLATFORM: serial# [00ab4130]
[ 0.000000] PLATFORM: stick-frequency [546e74c8]
[ 0.000000] PLATFORM: mac-address [144f3ecbf4]
[ 0.000000] PLATFORM: watchdog-resolution [1000 ms]
[ 0.000000] PLATFORM: watchdog-max-timeout [31536000000 ms]
[ 0.000000] PLATFORM: max-cpus [64]
[ 0.000000] Top of RAM: 0x3ffb22000, Total RAM: 0x3f76c6000
[ 0.000000] Memory hole size: 132MB
[ 0.000000] alloc_bootmem failed on section 8192.
[ 0.000000] sparse_early_usemap_alloc: allocation failed
[ 0.000000] alloc_bootmem failed on section 8192.
[ 0.000000] sparse_early_usemap_alloc: allocation failed
[ 0.000000] alloc_bootmem failed on section 8192.
[ 0.000000] sparse_early_usemap_alloc: allocation failed
[ 0.000000] alloc_bootmem failed on section 8192.
[ 0.000000] sparse_early_usemap_alloc: allocation failed
[ 0.000000] alloc_bootmem failed on section 8192.
[ 0.000000] sparse_early_usemap_alloc: allocation failed
[ 0.000000] alloc_bootmem failed on section 8192.
[ 0.000000] sparse_early_usemap_alloc: allocation failed
[ 0.000000] alloc_bootmem failed on section 8192.
[ 0.000000] sparse_early_usemap_alloc: allocation failed
[ 0.000000] alloc_bootmem failed on section 8192.
[ 0.000000] sparse_early_usemap_alloc: allocation failed
[ 0.000000] alloc_bootmem failed on section 8192.
[ 0.000000] sparse_early_usemap_alloc: allocation failed
[ 0.000000] alloc_bootmem failed on section 8192.
[ 0.000000] sparse_early_usemap_alloc: allocation failed
[ 0.000000] alloc_bootmem failed on section 8192.
[ 0.000000] sparse_early_usemap_alloc: allocation failed
[ 0.000000] alloc_bootmem failed on section 8192.
[ 0.000000] sparse_early_usemap_alloc: allocation failed
[ 0.000000] alloc_bootmem failed on section 8192.
[ 0.000000] sparse_early_usemap_alloc: allocation failed
[ 0.000000] alloc_bootmem failed on section 8192.
[ 0.000000] sparse_early_usemap_alloc: allocation failed
[ 0.000000] alloc_bootmem failed on section 8192.
[ 0.000000] sparse_early_usemap_alloc: allocation failed
[ 0.000000] alloc_bootmem failed on section 8192.
[ 0.000000] sparse_early_usemap_alloc: allocation failed
[ 0.000000] Zone PFN ranges:
[ 0.000000] Normal 16896 -> 2096529
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[3] active PFN ranges
[ 0.000000] 0: 16896 -> 2096466
[ 0.000000] 0: 2096467 -> 2096477
[ 0.000000] 0: 2096522 -> 2096529
[ 0.000000] Booting Linux...
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 2065371
[ 0.000000] Kernel command line: root=/dev/sda2 ro
[ 0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes)
[ 0.010000] clocksource: mult[b4b9] shift[16]
[ 0.010000] clockevent: mult[b550b0f2] shift[31]
[ 0.010000] Console: colour dummy device 80x25
[ 0.010000] console handover: boot [earlyprom0] -> real [tty0]
Program terminated
{0} ok
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: sparc64 bootup regression...
2008-04-30 6:12 sparc64 bootup regression David Miller
@ 2008-04-30 6:38 ` Andrew Morton
2008-04-30 6:46 ` KAMEZAWA Hiroyuki
` (3 more replies)
2008-05-01 5:13 ` powerpc boot regression Tony Breeds
1 sibling, 4 replies; 22+ messages in thread
From: Andrew Morton @ 2008-04-30 6:38 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, y-goto
On Tue, 29 Apr 2008 23:12:41 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> This commit causes bootup failures on sparc64:
>
> commit 86f6dae1377523689bd8468fed2f2dd180fc0560
> Author: Yasunori Goto <y-goto@jp.fujitsu.com>
> Date: Mon Apr 28 02:13:33 2008 -0700
>
> memory hotplug: allocate usemap on the section with pgdat
>
> Usemaps are allocated on the section which has pgdat by this.
>
> Because usemap size is very small, many other sections usemaps are allocated
> on only one page. If a section has usemap, it can't be removed until removing
> other sections. This dependency is not desirable for memory removing.
>
> Pgdat has similar feature. When a section has pgdat area, it must be the last
> section for removing on the node. So, if section A has pgdat and section B
> has usemap for section A, Both sections can't be removed due to dependency
> each other.
>
> To solve this issue, this patch collects usemap on same section with pgdat.
> If other sections doesn't have any dependency, this section will be able to be
> removed finally.
Thanks. Does a straightforward revert fix it? If so, we could do that while heads
are being scratched.
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: sparc64 bootup regression...
2008-04-30 6:38 ` Andrew Morton
@ 2008-04-30 6:46 ` KAMEZAWA Hiroyuki
2008-04-30 7:15 ` KAMEZAWA Hiroyuki
` (2 subsequent siblings)
3 siblings, 0 replies; 22+ messages in thread
From: KAMEZAWA Hiroyuki @ 2008-04-30 6:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Miller, linux-kernel, y-goto
On Tue, 29 Apr 2008 23:38:32 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Tue, 29 Apr 2008 23:12:41 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> >
> > This commit causes bootup failures on sparc64:
> >
> > commit 86f6dae1377523689bd8468fed2f2dd180fc0560
> > Author: Yasunori Goto <y-goto@jp.fujitsu.com>
> > Date: Mon Apr 28 02:13:33 2008 -0700
> >
> > memory hotplug: allocate usemap on the section with pgdat
> >
> > Usemaps are allocated on the section which has pgdat by this.
> >
> > Because usemap size is very small, many other sections usemaps are allocated
> > on only one page. If a section has usemap, it can't be removed until removing
> > other sections. This dependency is not desirable for memory removing.
> >
> > Pgdat has similar feature. When a section has pgdat area, it must be the last
> > section for removing on the node. So, if section A has pgdat and section B
> > has usemap for section A, Both sections can't be removed due to dependency
> > each other.
> >
> > To solve this issue, this patch collects usemap on same section with pgdat.
> > If other sections doesn't have any dependency, this section will be able to be
> > removed finally.
>
> Thanks. Does a straightforward revert fix it? If so, we could do that while heads
> are being scratched.
I'm now digging. plz wait a bit.
Thanks,
-Kame
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: sparc64 bootup regression...
2008-04-30 6:38 ` Andrew Morton
2008-04-30 6:46 ` KAMEZAWA Hiroyuki
@ 2008-04-30 7:15 ` KAMEZAWA Hiroyuki
2008-04-30 7:25 ` David Miller
2008-04-30 7:30 ` Heiko Carstens
2008-04-30 7:19 ` David Miller
2008-05-07 22:09 ` Rafael J. Wysocki
3 siblings, 2 replies; 22+ messages in thread
From: KAMEZAWA Hiroyuki @ 2008-04-30 7:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Miller, linux-kernel, y-goto
On Tue, 29 Apr 2008 23:38:32 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Tue, 29 Apr 2008 23:12:41 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> >
> > This commit causes bootup failures on sparc64:
> >
> > commit 86f6dae1377523689bd8468fed2f2dd180fc0560
> > Author: Yasunori Goto <y-goto@jp.fujitsu.com>
> > Date: Mon Apr 28 02:13:33 2008 -0700
> >
> > memory hotplug: allocate usemap on the section with pgdat
> >
> > Usemaps are allocated on the section which has pgdat by this.
> >
> > Because usemap size is very small, many other sections usemaps are allocated
> > on only one page. If a section has usemap, it can't be removed until removing
> > other sections. This dependency is not desirable for memory removing.
> >
> > Pgdat has similar feature. When a section has pgdat area, it must be the last
> > section for removing on the node. So, if section A has pgdat and section B
> > has usemap for section A, Both sections can't be removed due to dependency
> > each other.
> >
> > To solve this issue, this patch collects usemap on same section with pgdat.
> > If other sections doesn't have any dependency, this section will be able to be
> > removed finally.
>
> Thanks. Does a straightforward revert fix it? If so, we could do that while heads
> are being scratched.
How about this ? If this is messy (or doesn't work), Goto-san will rework
his own patch by himself. (this patch is against -mm but I think no HUNK to
git tree)
==
This kind of page allocation, which specifies the address range,
can fail easily.
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiruyo@jp.fujitsu.com>
Index: mm-2.6.25-mm1/mm/sparse.c
===================================================================
--- mm-2.6.25-mm1.orig/mm/sparse.c
+++ mm-2.6.25-mm1/mm/sparse.c
@@ -264,10 +264,16 @@ static unsigned long *__init sparse_earl
* To solve above issue, this collects all usemap on the same section
* which has pgdat.
*/
+#ifdef CONFIG_NUMA /* contig_page_data for !NUMA case is not good to do this */
section_nr = pfn_to_section_nr(__pa(pgdat) >> PAGE_SHIFT);
usemap = alloc_bootmem_section(usemap_size(), section_nr);
if (usemap)
return usemap;
+#endif
+ /* above allocation can fail. */
+ usemap = alloc_bootmem_node(NODE_DATA(nid), usemap_size());
+ if (usemap)
+ return usemap;
/* Stupid: suppress gcc warning for SPARSEMEM && !NUMA */
nid = 0;
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: sparc64 bootup regression...
2008-04-30 7:15 ` KAMEZAWA Hiroyuki
@ 2008-04-30 7:25 ` David Miller
2008-04-30 7:33 ` KAMEZAWA Hiroyuki
2008-04-30 7:30 ` Heiko Carstens
1 sibling, 1 reply; 22+ messages in thread
From: David Miller @ 2008-04-30 7:25 UTC (permalink / raw)
To: kamezawa.hiroyu; +Cc: akpm, linux-kernel, y-goto
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Date: Wed, 30 Apr 2008 16:15:40 +0900
> How about this ? If this is messy (or doesn't work), Goto-san will rework
> his own patch by himself. (this patch is against -mm but I think no HUNK to
> git tree)
This makes the original change pointless.
If the goal is to put the usemap in the same section as the memory
itself, in order to allow for it to be freed during memory hotplug,
this new change just makes the facility not work some of the time.
Now maybe sometimes it will work, maybe sometimes it will not.
It's not the end of the world if this change is reverted for a few
days while we work out what to do about this.
Really, it does not reflect badly upon you or Goto-san, if the change
is reverted temporarily.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: sparc64 bootup regression...
2008-04-30 7:25 ` David Miller
@ 2008-04-30 7:33 ` KAMEZAWA Hiroyuki
2008-04-30 12:53 ` Yasunori Goto
0 siblings, 1 reply; 22+ messages in thread
From: KAMEZAWA Hiroyuki @ 2008-04-30 7:33 UTC (permalink / raw)
To: David Miller; +Cc: akpm, linux-kernel, y-goto
On Wed, 30 Apr 2008 00:25:30 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> Date: Wed, 30 Apr 2008 16:15:40 +0900
>
> > How about this ? If this is messy (or doesn't work), Goto-san will rework
> > his own patch by himself. (this patch is against -mm but I think no HUNK to
> > git tree)
>
> This makes the original change pointless.
>
It seems the orignal change expects NODE_DATA() is allocated at boottime.
not in .bss section.
> If the goal is to put the usemap in the same section as the memory
> itself, in order to allow for it to be freed during memory hotplug,
> this new change just makes the facility not work some of the time.
>
yes, at least, WARNING is necessary.
> Now maybe sometimes it will work, maybe sometimes it will not.
>
> It's not the end of the world if this change is reverted for a few
> days while we work out what to do about this.
>
yes ;)
> Really, it does not reflect badly upon you or Goto-san, if the change
> is reverted temporarily.
>
Okay, I agree to revert it.
Thanks,
-Kame
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: sparc64 bootup regression...
2008-04-30 7:33 ` KAMEZAWA Hiroyuki
@ 2008-04-30 12:53 ` Yasunori Goto
2008-06-03 22:14 ` David Miller
0 siblings, 1 reply; 22+ messages in thread
From: Yasunori Goto @ 2008-04-30 12:53 UTC (permalink / raw)
To: David Miller; +Cc: akpm, linux-kernel, KAMEZAWA Hiroyuki
> On Wed, 30 Apr 2008 00:25:30 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
>
> > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > Date: Wed, 30 Apr 2008 16:15:40 +0900
> >
> > > How about this ? If this is messy (or doesn't work), Goto-san will rework
> > > his own patch by himself. (this patch is against -mm but I think no HUNK to
> > > git tree)
> >
> > This makes the original change pointless.
> >
> It seems the orignal change expects NODE_DATA() is allocated at boottime.
> not in .bss section.
>
> > If the goal is to put the usemap in the same section as the memory
> > itself, in order to allow for it to be freed during memory hotplug,
> > this new change just makes the facility not work some of the time.
> >
> yes, at least, WARNING is necessary.
>
> > Now maybe sometimes it will work, maybe sometimes it will not.
> >
> > It's not the end of the world if this change is reverted for a few
> > days while we work out what to do about this.
> >
> yes ;)
>
> > Really, it does not reflect badly upon you or Goto-san, if the change
> > is reverted temporarily.
> >
> Okay, I agree to revert it.
David-san.
Thanks for your report. I agree to revert it too.
I'll reconsider around here.
Unfortunately, I can't access my box to make newer patch until 5/11,
because I'm on vacation. Probably, I'm not able to post
newer patch in merge window.... Oh my..... :-(
Bye.
--
Yasunori Goto
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: sparc64 bootup regression...
2008-04-30 12:53 ` Yasunori Goto
@ 2008-06-03 22:14 ` David Miller
2008-06-04 5:05 ` Yasunori Goto
0 siblings, 1 reply; 22+ messages in thread
From: David Miller @ 2008-06-03 22:14 UTC (permalink / raw)
To: y-goto; +Cc: akpm, linux-kernel, kamezawa.hiroyu
From: Yasunori Goto <y-goto@jp.fujitsu.com>
Date: Wed, 30 Apr 2008 21:53:18 +0900
> I'll reconsider around here.
I think I know at least one of the problems in this change.
This code assumes that it can take __pa() on NODE_DATA().
But, if NUMA is disabled, NODE_DATA() is &contig_page_data which is a
kernel image symbol. __pa() is not supported for such addresses.
It happens to work on x86, but it will not work on just about every
other platform.
There are several things to consider to fix this changeset and
get it back into a state where it can be resubmitted into the
tree:
1) What is the goal here wrt. allocating the usemap when NUMA
is disabled.
2) What is appropriate if section_nr targetted allocation of
the usemap fails.
It seems to me that the pgdat and usemap should be allocated
together if putting them into the same section is important.
This allows us to avoid case #2 completely, and therefore we
don't even need to consider how to handle such a failure.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: sparc64 bootup regression...
2008-06-03 22:14 ` David Miller
@ 2008-06-04 5:05 ` Yasunori Goto
0 siblings, 0 replies; 22+ messages in thread
From: Yasunori Goto @ 2008-06-04 5:05 UTC (permalink / raw)
To: David Miller; +Cc: akpm, linux-kernel, kamezawa.hiroyu
David-san.
Thank you for your concern. I'm very glad.
> > I'll reconsider around here.
>
> I think I know at least one of the problems in this change.
>
> This code assumes that it can take __pa() on NODE_DATA().
>
> But, if NUMA is disabled, NODE_DATA() is &contig_page_data which is a
> kernel image symbol. __pa() is not supported for such addresses.
>
> It happens to work on x86, but it will not work on just about every
> other platform.
>
> There are several things to consider to fix this changeset and
> get it back into a state where it can be resubmitted into the
> tree:
>
> 1) What is the goal here wrt. allocating the usemap when NUMA
> is disabled.
>
> 2) What is appropriate if section_nr targetted allocation of
> the usemap fails.
>
> It seems to me that the pgdat and usemap should be allocated
> together if putting them into the same section is important.
> This allows us to avoid case #2 completely, and therefore we
> don't even need to consider how to handle such a failure.
Basically, this is for memory hot-remove feature.
Pgdat's section and usemap section can't be removed until
that all other section are removed.
If usemap is allocated another section from pgdat,
both section's can't be removed due to each other dependency.
So, I would like to allocate them on the same section to
remove whole of node completely.
IIRC, some of architecture (like powerpc) allow un-removable section,
because its box will gather -removable- sections and pass them to
other "partition" via "dynamic logical partitioning" feature.
Especially, powerpc's section size is very small, this allocation failure
may often occur than I thought.
In this case, usemap should be allocated on another section and
kernel should just show message of unremovable sections.
I think it would be simple workaround.
Just I didn't notice the case of sparsemem with non-NUMA.
So, it should be fixed.
Ok. Now I have some internal works for my company in this week.
And I would like to help clean up of bootmem before this.
But, I'll fix this next week. Sorry for late.
Thanks.
--
Yasunori Goto
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: sparc64 bootup regression...
2008-04-30 7:15 ` KAMEZAWA Hiroyuki
2008-04-30 7:25 ` David Miller
@ 2008-04-30 7:30 ` Heiko Carstens
2008-04-30 7:44 ` KAMEZAWA Hiroyuki
1 sibling, 1 reply; 22+ messages in thread
From: Heiko Carstens @ 2008-04-30 7:30 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: Andrew Morton, David Miller, linux-kernel, y-goto
On Wed, Apr 30, 2008 at 04:15:40PM +0900, KAMEZAWA Hiroyuki wrote:
> On Tue, 29 Apr 2008 23:38:32 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
> > On Tue, 29 Apr 2008 23:12:41 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
> > > This commit causes bootup failures on sparc64:
> > >
> > > commit 86f6dae1377523689bd8468fed2f2dd180fc0560
> > > Author: Yasunori Goto <y-goto@jp.fujitsu.com>
> > > Date: Mon Apr 28 02:13:33 2008 -0700
> > >
> > > memory hotplug: allocate usemap on the section with pgdat
> > Thanks. Does a straightforward revert fix it? If so, we could do that while heads
> > are being scratched.
That patch broke the s390 port to SPARSEMEM (not upstream yet) as well.
Reverting it does help.
However increasing SECTION_SIZE_BITS to 25 (was: 20) does help too.
But that doesn't seem to help on sparc64 where it is already 30, strange.
> How about this ? If this is messy (or doesn't work), Goto-san will rework
> his own patch by himself. (this patch is against -mm but I think no HUNK to
> git tree)
>
> ==
> This kind of page allocation, which specifies the address range,
> can fail easily.
>
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiruyo@jp.fujitsu.com>
>
> Index: mm-2.6.25-mm1/mm/sparse.c
> ===================================================================
> --- mm-2.6.25-mm1.orig/mm/sparse.c
> +++ mm-2.6.25-mm1/mm/sparse.c
> @@ -264,10 +264,16 @@ static unsigned long *__init sparse_earl
> * To solve above issue, this collects all usemap on the same section
> * which has pgdat.
> */
> +#ifdef CONFIG_NUMA /* contig_page_data for !NUMA case is not good to do this */
> section_nr = pfn_to_section_nr(__pa(pgdat) >> PAGE_SHIFT);
> usemap = alloc_bootmem_section(usemap_size(), section_nr);
> if (usemap)
> return usemap;
> +#endif
> + /* above allocation can fail. */
> + usemap = alloc_bootmem_node(NODE_DATA(nid), usemap_size());
> + if (usemap)
> + return usemap;
>
> /* Stupid: suppress gcc warning for SPARSEMEM && !NUMA */
> nid = 0;
Fixes it on s390 at least.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: sparc64 bootup regression...
2008-04-30 7:30 ` Heiko Carstens
@ 2008-04-30 7:44 ` KAMEZAWA Hiroyuki
2008-04-30 7:45 ` Heiko Carstens
0 siblings, 1 reply; 22+ messages in thread
From: KAMEZAWA Hiroyuki @ 2008-04-30 7:44 UTC (permalink / raw)
To: Heiko Carstens; +Cc: Andrew Morton, David Miller, linux-kernel, y-goto
On Wed, 30 Apr 2008 09:30:52 +0200
Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> > How about this ? If this is messy (or doesn't work), Goto-san will rework
> > his own patch by himself. (this patch is against -mm but I think no HUNK to
> > git tree)
> >
> > ==
> > This kind of page allocation, which specifies the address range,
> > can fail easily.
> >
> > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiruyo@jp.fujitsu.com>
> >
> > Index: mm-2.6.25-mm1/mm/sparse.c
> > ===================================================================
> > --- mm-2.6.25-mm1.orig/mm/sparse.c
> > +++ mm-2.6.25-mm1/mm/sparse.c
> > @@ -264,10 +264,16 @@ static unsigned long *__init sparse_earl
> > * To solve above issue, this collects all usemap on the same section
> > * which has pgdat.
> > */
> > +#ifdef CONFIG_NUMA /* contig_page_data for !NUMA case is not good to do this */
> > section_nr = pfn_to_section_nr(__pa(pgdat) >> PAGE_SHIFT);
> > usemap = alloc_bootmem_section(usemap_size(), section_nr);
> > if (usemap)
> > return usemap;
> > +#endif
> > + /* above allocation can fail. */
> > + usemap = alloc_bootmem_node(NODE_DATA(nid), usemap_size());
> > + if (usemap)
> > + return usemap;
> >
> > /* Stupid: suppress gcc warning for SPARSEMEM && !NUMA */
> > nid = 0;
>
> Fixes it on s390 at least.
>
Thanks, much help to understand what happens.
BTW, s390 is CONFIG_NUMA or not ?
Regards,
-Kame
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: sparc64 bootup regression...
2008-04-30 7:44 ` KAMEZAWA Hiroyuki
@ 2008-04-30 7:45 ` Heiko Carstens
0 siblings, 0 replies; 22+ messages in thread
From: Heiko Carstens @ 2008-04-30 7:45 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: Andrew Morton, David Miller, linux-kernel, y-goto
On Wed, Apr 30, 2008 at 04:44:44PM +0900, KAMEZAWA Hiroyuki wrote:
> On Wed, 30 Apr 2008 09:30:52 +0200
> Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> > > +#endif
> > > + /* above allocation can fail. */
> > > + usemap = alloc_bootmem_node(NODE_DATA(nid), usemap_size());
> > > + if (usemap)
> > > + return usemap;
> > >
> > > /* Stupid: suppress gcc warning for SPARSEMEM && !NUMA */
> > > nid = 0;
> >
> > Fixes it on s390 at least.
> >
> Thanks, much help to understand what happens.
> BTW, s390 is CONFIG_NUMA or not ?
We don't set CONFIG_NUMA on s390.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: sparc64 bootup regression...
2008-04-30 6:38 ` Andrew Morton
2008-04-30 6:46 ` KAMEZAWA Hiroyuki
2008-04-30 7:15 ` KAMEZAWA Hiroyuki
@ 2008-04-30 7:19 ` David Miller
2008-05-07 22:09 ` Rafael J. Wysocki
3 siblings, 0 replies; 22+ messages in thread
From: David Miller @ 2008-04-30 7:19 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel, y-goto
From: Andrew Morton <akpm@linux-foundation.org>
Date: Tue, 29 Apr 2008 23:38:32 -0700
> Does a straightforward revert fix it?
Yes.
> If so, we could do that while heads are being scratched.
I want to make a note to everyone that this is the first time this
whole merge window that someone who submitted a regression causing
commit even remotely suggested that it be reverted.
I think Andrew should be commended.
This is tons better than the "revert? no way, that makes me look bad
and makes more work for me!" methodology that others seem to
subscribe to.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: sparc64 bootup regression...
2008-04-30 6:38 ` Andrew Morton
` (2 preceding siblings ...)
2008-04-30 7:19 ` David Miller
@ 2008-05-07 22:09 ` Rafael J. Wysocki
2008-05-07 22:25 ` Andrew Morton
2008-05-07 22:46 ` David Miller
3 siblings, 2 replies; 22+ messages in thread
From: Rafael J. Wysocki @ 2008-05-07 22:09 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Miller, linux-kernel, y-goto
On Wednesday, 30 of April 2008, Andrew Morton wrote:
> On Tue, 29 Apr 2008 23:12:41 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> >
> > This commit causes bootup failures on sparc64:
> >
> > commit 86f6dae1377523689bd8468fed2f2dd180fc0560
> > Author: Yasunori Goto <y-goto@jp.fujitsu.com>
> > Date: Mon Apr 28 02:13:33 2008 -0700
> >
> > memory hotplug: allocate usemap on the section with pgdat
> >
> > Usemaps are allocated on the section which has pgdat by this.
> >
> > Because usemap size is very small, many other sections usemaps are allocated
> > on only one page. If a section has usemap, it can't be removed until removing
> > other sections. This dependency is not desirable for memory removing.
> >
> > Pgdat has similar feature. When a section has pgdat area, it must be the last
> > section for removing on the node. So, if section A has pgdat and section B
> > has usemap for section A, Both sections can't be removed due to dependency
> > each other.
> >
> > To solve this issue, this patch collects usemap on same section with pgdat.
> > If other sections doesn't have any dependency, this section will be able to be
> > removed finally.
>
> Thanks. Does a straightforward revert fix it? If so, we could do that while heads
> are being scratched.
Has that been reverted already?
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: sparc64 bootup regression...
2008-05-07 22:09 ` Rafael J. Wysocki
@ 2008-05-07 22:25 ` Andrew Morton
2008-05-07 22:32 ` Rafael J. Wysocki
2008-05-07 22:46 ` David Miller
1 sibling, 1 reply; 22+ messages in thread
From: Andrew Morton @ 2008-05-07 22:25 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: davem, linux-kernel, y-goto
On Thu, 8 May 2008 00:09:45 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> On Wednesday, 30 of April 2008, Andrew Morton wrote:
> > On Tue, 29 Apr 2008 23:12:41 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
> >
> > >
> > > This commit causes bootup failures on sparc64:
> > >
> > > commit 86f6dae1377523689bd8468fed2f2dd180fc0560
> > > Author: Yasunori Goto <y-goto@jp.fujitsu.com>
> > > Date: Mon Apr 28 02:13:33 2008 -0700
> > >
> > > memory hotplug: allocate usemap on the section with pgdat
> > >
> > > Usemaps are allocated on the section which has pgdat by this.
> > >
> > > Because usemap size is very small, many other sections usemaps are allocated
> > > on only one page. If a section has usemap, it can't be removed until removing
> > > other sections. This dependency is not desirable for memory removing.
> > >
> > > Pgdat has similar feature. When a section has pgdat area, it must be the last
> > > section for removing on the node. So, if section A has pgdat and section B
> > > has usemap for section A, Both sections can't be removed due to dependency
> > > each other.
> > >
> > > To solve this issue, this patch collects usemap on same section with pgdat.
> > > If other sections doesn't have any dependency, this section will be able to be
> > > removed finally.
> >
> > Thanks. Does a straightforward revert fix it? If so, we could do that while heads
> > are being scratched.
>
> Has that been reverted already?
yes, it has.
commit 5167464446e527b5a3b5618ba0baff93048bcbbe
Author: Andrew Morton <akpm@linux-foundation.org>
Date: Wed Apr 30 00:55:17 2008 -0700
revert "memory hotplug: allocate usemap on the section with pgdat"
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: sparc64 bootup regression...
2008-05-07 22:25 ` Andrew Morton
@ 2008-05-07 22:32 ` Rafael J. Wysocki
0 siblings, 0 replies; 22+ messages in thread
From: Rafael J. Wysocki @ 2008-05-07 22:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: davem, linux-kernel, y-goto
On Thursday, 8 of May 2008, Andrew Morton wrote:
> On Thu, 8 May 2008 00:09:45 +0200
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
> > On Wednesday, 30 of April 2008, Andrew Morton wrote:
> > > On Tue, 29 Apr 2008 23:12:41 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
> > >
> > > >
> > > > This commit causes bootup failures on sparc64:
> > > >
> > > > commit 86f6dae1377523689bd8468fed2f2dd180fc0560
> > > > Author: Yasunori Goto <y-goto@jp.fujitsu.com>
> > > > Date: Mon Apr 28 02:13:33 2008 -0700
> > > >
> > > > memory hotplug: allocate usemap on the section with pgdat
> > > >
> > > > Usemaps are allocated on the section which has pgdat by this.
> > > >
> > > > Because usemap size is very small, many other sections usemaps are allocated
> > > > on only one page. If a section has usemap, it can't be removed until removing
> > > > other sections. This dependency is not desirable for memory removing.
> > > >
> > > > Pgdat has similar feature. When a section has pgdat area, it must be the last
> > > > section for removing on the node. So, if section A has pgdat and section B
> > > > has usemap for section A, Both sections can't be removed due to dependency
> > > > each other.
> > > >
> > > > To solve this issue, this patch collects usemap on same section with pgdat.
> > > > If other sections doesn't have any dependency, this section will be able to be
> > > > removed finally.
> > >
> > > Thanks. Does a straightforward revert fix it? If so, we could do that while heads
> > > are being scratched.
> >
> > Has that been reverted already?
>
> yes, it has.
>
> commit 5167464446e527b5a3b5618ba0baff93048bcbbe
> Author: Andrew Morton <akpm@linux-foundation.org>
> Date: Wed Apr 30 00:55:17 2008 -0700
>
> revert "memory hotplug: allocate usemap on the section with pgdat"
OK, thanks.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: sparc64 bootup regression...
2008-05-07 22:09 ` Rafael J. Wysocki
2008-05-07 22:25 ` Andrew Morton
@ 2008-05-07 22:46 ` David Miller
1 sibling, 0 replies; 22+ messages in thread
From: David Miller @ 2008-05-07 22:46 UTC (permalink / raw)
To: rjw; +Cc: akpm, linux-kernel, y-goto
From: "Rafael J. Wysocki" <rjw@sisk.pl>
Date: Thu, 8 May 2008 00:09:45 +0200
> On Wednesday, 30 of April 2008, Andrew Morton wrote:
> > On Tue, 29 Apr 2008 23:12:41 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
> >
> > >
> > > This commit causes bootup failures on sparc64:
> > >
> > > commit 86f6dae1377523689bd8468fed2f2dd180fc0560
> > > Author: Yasunori Goto <y-goto@jp.fujitsu.com>
> > > Date: Mon Apr 28 02:13:33 2008 -0700
> > >
> > > memory hotplug: allocate usemap on the section with pgdat
> > >
> > > Usemaps are allocated on the section which has pgdat by this.
> > >
> > > Because usemap size is very small, many other sections usemaps are allocated
> > > on only one page. If a section has usemap, it can't be removed until removing
> > > other sections. This dependency is not desirable for memory removing.
> > >
> > > Pgdat has similar feature. When a section has pgdat area, it must be the last
> > > section for removing on the node. So, if section A has pgdat and section B
> > > has usemap for section A, Both sections can't be removed due to dependency
> > > each other.
> > >
> > > To solve this issue, this patch collects usemap on same section with pgdat.
> > > If other sections doesn't have any dependency, this section will be able to be
> > > removed finally.
> >
> > Thanks. Does a straightforward revert fix it? If so, we could do that while heads
> > are being scratched.
>
> Has that been reverted already?
Yes.
^ permalink raw reply [flat|nested] 22+ messages in thread
* powerpc boot regression
2008-04-30 6:12 sparc64 bootup regression David Miller
2008-04-30 6:38 ` Andrew Morton
@ 2008-05-01 5:13 ` Tony Breeds
2008-05-01 14:51 ` Badari Pulavarty
1 sibling, 1 reply; 22+ messages in thread
From: Tony Breeds @ 2008-05-01 5:13 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, y-goto, akpm, LinuxPPC-dev, Benjamin Herrenschmidt,
Geoff Levand
On Tue, Apr 29, 2008 at 11:12:41PM -0700, David Miller wrote:
>
> This commit causes bootup failures on sparc64:
>
> commit 86f6dae1377523689bd8468fed2f2dd180fc0560
> Author: Yasunori Goto <y-goto@jp.fujitsu.com>
> Date: Mon Apr 28 02:13:33 2008 -0700
>
> memory hotplug: allocate usemap on the section with pgdat
<snip>
We're seeing a boot failure on powerpc. git bisect points the problem
at this commit. However reverting just this one comitt doesn't fix the
regression. I also needed to revert
04753278769f3b6c3b79a080edb52f21d83bf6e2 (memory hotplug: register
section/node id to free")
Problem seen on power4, power5 and ps3.
If the fix isn't trivial, can we get that patch series reverted?
FWIW a boot looks like:
zImage starting: loaded at 0x00400000 (sp: 0x02f5fea0)
Allocating 0xa2d4c8 bytes for kernel ...
OF version = 'IBM,SF240_332'
gunzipping (0x01400000 <- 0x00407000:0x0079aa5d)...done 0x9a8ee0 bytes
Linux/PowerPC load: root=/dev/sdc3 ro
Finalizing device tree... using OF tree (promptr=02039a68)
OF stdout device is: /vdevice/vty@30000000
Hypertas detected, assuming LPAR !
command line: root=/dev/sdc3 ro
memory layout at init:
alloc_bottom : 0000000001e32000
alloc_top : 0000000008000000
alloc_top_hi : 0000000080000000
rmo_top : 0000000008000000
ram_top : 0000000080000000
Looking for displays
instantiating rtas at 0x00000000076a1000 ... done
0000000000000000 : boot cpu 0000000000000000
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000001e33000 -> 0x0000000001e3417c
Device tree struct 0x0000000001e35000 -> 0x0000000001e3d000
Calling quiesce ...
returning from prom_init
Crash kernel location must be 0x2000000
Reserving 0MB of memory at 32MB for crashkernel (System RAM: 2048MB)
Using pSeries machine description
console [udbg0] enabled
Partition configured for 20 cpus.
CPU maps initialized for 2 threads per core
Starting Linux PPC64 #52 SMP Thu May 1 14:04:46 EST 2008
-----------------------------------------------------
ppc64_pft_size = 0x19
physicalMemorySize = 0x80000000
htab_hash_mask = 0x3ffff
-----------------------------------------------------
Initializing cgroup subsys cpuset
Linux version 2.6.25 (tony@Sprygo) (gcc version 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)) #52 SMP Thu May 1 14:04:46 EST 2008
[boot]0012 Setup Arch
sparse_early_usemap_alloc: allocation failed
<snip 127 more>
EEH: No capable adapters found
PPC64 nvram contains 7168 bytes
Zone PFN ranges:
DMA 0 -> 524288
Normal 524288 -> 524288
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 524288
[boot]0015 Setup Done
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 517120
Kernel command line: root=/dev/sdc3 ro
[boot]0020 XICS Init
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 32768 bytes)
clocksource: timebase mult[1545815] shift[22] registered
Console: colour dummy device 80x25
console handover: boot [udbg0] -> real [hvc0]
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Unable to handle kernel paging request for data at address 0xcf00000000030858
Faulting instruction address: 0xc0000000000c4530
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=32 pSeries
Modules linked in:
NIP: c0000000000c4530 LR: c0000000007e8790 CTR: 80000000001af404
REGS: c000000000987ae0 TRAP: 0300 Not tainted (2.6.25)
MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24000088 XER: 20000002
DAR: cf00000000030858, DSISR: 0000000040010000
TASK = c000000000862650[0] 'swapper' THREAD: c000000000984000 CPU: 0
GPR00: 0000000020000000 c000000000987d60 c000000000981f18 cf00000000030858
GPR04: 0000000000000000 0000000000000001 0000000000000000 c0000000009f2a68
GPR08: c0000000009f2a58 00000000000001b8 0000000000000000 cf00000000030858
GPR12: 0000000000004000 c0000000009ae400 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
GPR20: c00000007ffe8000 0000000000080000 0000000000000001 c0000000009f2848
GPR24: cf00000000030200 0000000040000000 0000000000000dc0 000000000000001d
GPR28: ffffffffe0000000 cf00000000030890 c0000000008e5088 0000000000000dde
NIP [c0000000000c4530] .__free_pages_bootmem+0xc/0xa8
LR [c0000000007e8790] .free_all_bootmem_core+0x140/0x218
Call Trace:
[c000000000987d60] [0000000001c0a438] 0x1c0a438 (unreliable)
[c000000000987e40] [c0000000007d29c8] .mem_init+0x68/0x1b0
[c000000000987ed0] [c0000000007c091c] .start_kernel+0x34c/0x45c
[c000000000987f90] [c00000000000859c] .start_here_common+0x4c/0xb0
Instruction dump:
780007c6 792907c6 7c630214 38000038 7863a302 7c6301d2 4d820020 7c634a14
4bffffa0 7c862379 7c6b1b78 40820028 <e8030000> 39200000 7800a842 78005800
---[ end trace 8640abe69a316dee ]---
Kernel panic - not syncing: Attempted to kill the idle task!
Rebooting in 180 seconds..
Yours Tony
linux.conf.au http://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux Technical Conference!
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: powerpc boot regression
2008-05-01 5:13 ` powerpc boot regression Tony Breeds
@ 2008-05-01 14:51 ` Badari Pulavarty
2008-05-01 19:01 ` Geoff Levand
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: Badari Pulavarty @ 2008-05-01 14:51 UTC (permalink / raw)
To: Tony Breeds
Cc: David Miller, linux-kernel, y-goto, akpm, LinuxPPC-dev,
Benjamin Herrenschmidt, Geoff Levand
On Thu, 2008-05-01 at 15:13 +1000, Tony Breeds wrote:
> On Tue, Apr 29, 2008 at 11:12:41PM -0700, David Miller wrote:
> >
> > This commit causes bootup failures on sparc64:
> >
> > commit 86f6dae1377523689bd8468fed2f2dd180fc0560
> > Author: Yasunori Goto <y-goto@jp.fujitsu.com>
> > Date: Mon Apr 28 02:13:33 2008 -0700
> >
> > memory hotplug: allocate usemap on the section with pgdat
>
>
> <snip>
>
> We're seeing a boot failure on powerpc. git bisect points the problem
> at this commit. However reverting just this one comitt doesn't fix the
> regression. I also needed to revert
> 04753278769f3b6c3b79a080edb52f21d83bf6e2 (memory hotplug: register
> section/node id to free")
>
> Problem seen on power4, power5 and ps3.
I don't see the problem on my power5 machine. Can you send the
config ? Is CONFIG_SPARSEMEM_VMEMMAP enabled ?
Please let me know.
Thanks,
Badari
>
> If the fix isn't trivial, can we get that patch series reverted?
>
> FWIW a boot looks like:
> zImage starting: loaded at 0x00400000 (sp: 0x02f5fea0)
> Allocating 0xa2d4c8 bytes for kernel ...
> OF version = 'IBM,SF240_332'
> gunzipping (0x01400000 <- 0x00407000:0x0079aa5d)...done 0x9a8ee0 bytes
>
> Linux/PowerPC load: root=/dev/sdc3 ro
> Finalizing device tree... using OF tree (promptr=02039a68)
> OF stdout device is: /vdevice/vty@30000000
> Hypertas detected, assuming LPAR !
> command line: root=/dev/sdc3 ro
> memory layout at init:
> alloc_bottom : 0000000001e32000
> alloc_top : 0000000008000000
> alloc_top_hi : 0000000080000000
> rmo_top : 0000000008000000
> ram_top : 0000000080000000
> Looking for displays
> instantiating rtas at 0x00000000076a1000 ... done
> 0000000000000000 : boot cpu 0000000000000000
> copying OF device tree ...
> Building dt strings...
> Building dt structure...
> Device tree strings 0x0000000001e33000 -> 0x0000000001e3417c
> Device tree struct 0x0000000001e35000 -> 0x0000000001e3d000
> Calling quiesce ...
> returning from prom_init
> Crash kernel location must be 0x2000000
> Reserving 0MB of memory at 32MB for crashkernel (System RAM: 2048MB)
> Using pSeries machine description
> console [udbg0] enabled
> Partition configured for 20 cpus.
> CPU maps initialized for 2 threads per core
> Starting Linux PPC64 #52 SMP Thu May 1 14:04:46 EST 2008
> -----------------------------------------------------
> ppc64_pft_size = 0x19
> physicalMemorySize = 0x80000000
> htab_hash_mask = 0x3ffff
> -----------------------------------------------------
> Initializing cgroup subsys cpuset
> Linux version 2.6.25 (tony@Sprygo) (gcc version 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)) #52 SMP Thu May 1 14:04:46 EST 2008
> [boot]0012 Setup Arch
> sparse_early_usemap_alloc: allocation failed
> <snip 127 more>
> EEH: No capable adapters found
> PPC64 nvram contains 7168 bytes
> Zone PFN ranges:
> DMA 0 -> 524288
> Normal 524288 -> 524288
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0 -> 524288
> [boot]0015 Setup Done
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 517120
> Kernel command line: root=/dev/sdc3 ro
> [boot]0020 XICS Init
> [boot]0021 XICS Done
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> clocksource: timebase mult[1545815] shift[22] registered
> Console: colour dummy device 80x25
> console handover: boot [udbg0] -> real [hvc0]
> Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
> Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
> Unable to handle kernel paging request for data at address 0xcf00000000030858
> Faulting instruction address: 0xc0000000000c4530
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=32 pSeries
> Modules linked in:
> NIP: c0000000000c4530 LR: c0000000007e8790 CTR: 80000000001af404
> REGS: c000000000987ae0 TRAP: 0300 Not tainted (2.6.25)
> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24000088 XER: 20000002
> DAR: cf00000000030858, DSISR: 0000000040010000
> TASK = c000000000862650[0] 'swapper' THREAD: c000000000984000 CPU: 0
> GPR00: 0000000020000000 c000000000987d60 c000000000981f18 cf00000000030858
> GPR04: 0000000000000000 0000000000000001 0000000000000000 c0000000009f2a68
> GPR08: c0000000009f2a58 00000000000001b8 0000000000000000 cf00000000030858
> GPR12: 0000000000004000 c0000000009ae400 0000000000000000 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
> GPR20: c00000007ffe8000 0000000000080000 0000000000000001 c0000000009f2848
> GPR24: cf00000000030200 0000000040000000 0000000000000dc0 000000000000001d
> GPR28: ffffffffe0000000 cf00000000030890 c0000000008e5088 0000000000000dde
> NIP [c0000000000c4530] .__free_pages_bootmem+0xc/0xa8
> LR [c0000000007e8790] .free_all_bootmem_core+0x140/0x218
> Call Trace:
> [c000000000987d60] [0000000001c0a438] 0x1c0a438 (unreliable)
> [c000000000987e40] [c0000000007d29c8] .mem_init+0x68/0x1b0
> [c000000000987ed0] [c0000000007c091c] .start_kernel+0x34c/0x45c
> [c000000000987f90] [c00000000000859c] .start_here_common+0x4c/0xb0
> Instruction dump:
> 780007c6 792907c6 7c630214 38000038 7863a302 7c6301d2 4d820020 7c634a14
> 4bffffa0 7c862379 7c6b1b78 40820028 <e8030000> 39200000 7800a842 78005800
> ---[ end trace 8640abe69a316dee ]---
> Kernel panic - not syncing: Attempted to kill the idle task!
> Rebooting in 180 seconds..
>
> Yours Tony
>
> linux.conf.au http://www.marchsouth.org/
> Jan 19 - 24 2009 The Australian Linux Technical Conference!
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: powerpc boot regression
2008-05-01 14:51 ` Badari Pulavarty
@ 2008-05-01 19:01 ` Geoff Levand
2008-05-01 23:07 ` Tony Breeds
2008-05-03 12:05 ` Yasunori Goto
2 siblings, 0 replies; 22+ messages in thread
From: Geoff Levand @ 2008-05-01 19:01 UTC (permalink / raw)
To: Badari Pulavarty
Cc: Tony Breeds, David Miller, linux-kernel, y-goto, akpm,
LinuxPPC-dev, Benjamin Herrenschmidt
Badari Pulavarty wrote:
> On Thu, 2008-05-01 at 15:13 +1000, Tony Breeds wrote:
>> On Tue, Apr 29, 2008 at 11:12:41PM -0700, David Miller wrote:
>> >
>> > This commit causes bootup failures on sparc64:
>> >
>> > commit 86f6dae1377523689bd8468fed2f2dd180fc0560
>> > Author: Yasunori Goto <y-goto@jp.fujitsu.com>
>> > Date: Mon Apr 28 02:13:33 2008 -0700
>> >
>> > memory hotplug: allocate usemap on the section with pgdat
>>
>>
>> <snip>
>>
>> We're seeing a boot failure on powerpc. git bisect points the problem
>> at this commit. However reverting just this one comitt doesn't fix the
>> regression. I also needed to revert
>> 04753278769f3b6c3b79a080edb52f21d83bf6e2 (memory hotplug: register
>> section/node id to free")
>>
>> Problem seen on power4, power5 and ps3.
>
> I don't see the problem on my power5 machine. Can you send the
> config ? Is CONFIG_SPARSEMEM_VMEMMAP enabled ?
The bug is hit with ps3_defconfig. It does not have
CONFIG_SPARSEMEM_VMEMMAP set.
-Geoff
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: powerpc boot regression
2008-05-01 14:51 ` Badari Pulavarty
2008-05-01 19:01 ` Geoff Levand
@ 2008-05-01 23:07 ` Tony Breeds
2008-05-03 12:05 ` Yasunori Goto
2 siblings, 0 replies; 22+ messages in thread
From: Tony Breeds @ 2008-05-01 23:07 UTC (permalink / raw)
To: Badari Pulavarty
Cc: David Miller, linux-kernel, y-goto, akpm, LinuxPPC-dev,
Benjamin Herrenschmidt, Geoff Levand
On Thu, May 01, 2008 at 07:51:47AM -0700, Badari Pulavarty wrote:
> I don't see the problem on my power5 machine. Can you send the
> config ? Is CONFIG_SPARSEMEM_VMEMMAP enabled ?
Yes. I'm just using ppc64_defconfig.
Yours Tony
linux.conf.au http://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux Technical Conference!
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: powerpc boot regression
2008-05-01 14:51 ` Badari Pulavarty
2008-05-01 19:01 ` Geoff Levand
2008-05-01 23:07 ` Tony Breeds
@ 2008-05-03 12:05 ` Yasunori Goto
2 siblings, 0 replies; 22+ messages in thread
From: Yasunori Goto @ 2008-05-03 12:05 UTC (permalink / raw)
To: Badari Pulavarty, Tony Breeds
Cc: David Miller, linux-kernel, akpm, LinuxPPC-dev,
Benjamin Herrenschmidt, Geoff Levand, Hiroyuki KAMEZAWA
>
> On Thu, 2008-05-01 at 15:13 +1000, Tony Breeds wrote:
> > On Tue, Apr 29, 2008 at 11:12:41PM -0700, David Miller wrote:
> > >
> > > This commit causes bootup failures on sparc64:
> > >
> > > commit 86f6dae1377523689bd8468fed2f2dd180fc0560
> > > Author: Yasunori Goto <y-goto@jp.fujitsu.com>
> > > Date: Mon Apr 28 02:13:33 2008 -0700
> > >
> > > memory hotplug: allocate usemap on the section with pgdat
> >
> >
> > <snip>
> >
> > We're seeing a boot failure on powerpc. git bisect points the problem
> > at this commit. However reverting just this one comitt doesn't fix the
> > regression. I also needed to revert
> > 04753278769f3b6c3b79a080edb52f21d83bf6e2 (memory hotplug: register
> > section/node id to free")
> >
> > Problem seen on power4, power5 and ps3.
>
> I don't see the problem on my power5 machine. Can you send the
> config ? Is CONFIG_SPARSEMEM_VMEMMAP enabled ?
>
> Please let me know.
I heard sparc has the similar regression.
http://marc.info/?l=linux-kernel&m=120953950332044&w=2
If Kame-san's temporary patch fixes your problems, its cause may be same.
Thanks.
--
Yasunori Goto
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2008-06-04 5:06 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-30 6:12 sparc64 bootup regression David Miller
2008-04-30 6:38 ` Andrew Morton
2008-04-30 6:46 ` KAMEZAWA Hiroyuki
2008-04-30 7:15 ` KAMEZAWA Hiroyuki
2008-04-30 7:25 ` David Miller
2008-04-30 7:33 ` KAMEZAWA Hiroyuki
2008-04-30 12:53 ` Yasunori Goto
2008-06-03 22:14 ` David Miller
2008-06-04 5:05 ` Yasunori Goto
2008-04-30 7:30 ` Heiko Carstens
2008-04-30 7:44 ` KAMEZAWA Hiroyuki
2008-04-30 7:45 ` Heiko Carstens
2008-04-30 7:19 ` David Miller
2008-05-07 22:09 ` Rafael J. Wysocki
2008-05-07 22:25 ` Andrew Morton
2008-05-07 22:32 ` Rafael J. Wysocki
2008-05-07 22:46 ` David Miller
2008-05-01 5:13 ` powerpc boot regression Tony Breeds
2008-05-01 14:51 ` Badari Pulavarty
2008-05-01 19:01 ` Geoff Levand
2008-05-01 23:07 ` Tony Breeds
2008-05-03 12:05 ` Yasunori Goto
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox