* 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: jjDaNiMoTh @ 2010-07-13 14:03 UTC (permalink / raw)
To: xorg-driver-ati; +Cc: linuxppc-dev
Hello to all.
Sorry if these aren't right place, please point me to the right
direction if you can :)
When trying new 2.6.35-rc4, our kernel team (ArchLinuxPPC) has tried
to setup KMS acceleration for radeon based machine.
We have removed radeonfb, and all others framebuffer driver, and added
fbcon and KMS enabled by default for radeon driver.
With a clean start, the screen freeze, when the control pass from
yaboot to kernel.
If we start with video=fbcon (or video=radeondrmfb), we could reach
the loading modules point, but after the loading of radeon, the screen
goes black, without any log information.
Loading kernel with video=fbcon radeon.modeset=0 allow us to reach the
end of init stage, and we could load X.org. In this case, acceleration
is disabled.
If we log out and do the following command:
modprobe -r radeon drm
modprobe drm debug=1
modprobe radeon modeset=1
The screen goes black, but at next boot we have found the logs. Any hint?
System information:
Xorg server: 1.8.1
xf86-video-ati 6.13.0
ati-dri 7.8.1
mesa 7.8.1
linux 2.6.35-rc4-00131-ge467e10
There are logs (most relevant part):
[...]
Jul 13 15:29:50 jim kernel: Caused by (from SRR1=149030): Transfer
error ack signal
Jul 13 15:29:50 jim kernel: Machine check in kernel mode.
Jul 13 15:29:50 jim kernel: Caused by (from SRR1=149030): Transfer
error ack signal
Jul 13 15:29:50 jim kernel: Machine check in kernel mode.
Jul 13 15:29:50 jim kernel: Caused by (from SRR1=149030): Transfer
error ack signal
Jul 13 15:29:50 jim kernel: Machine check in kernel mode.
Jul 13 15:29:50 jim kernel: Caused by (from SRR1=149030): Transfer
error ack signal
[....]
Jul 13 15:31:28 jim kernel: [drm] Module unloaded
Jul 13 15:31:39 jim kernel: [drm] Initialized drm 1.1.0 20060810
Jul 13 15:31:39 jim kernel: [drm] radeon kernel modesetting enabled.
Jul 13 15:31:39 jim kernel: [drm] initializing kernel modesetting
(RV350 0x1002:0x4E50).
Jul 13 15:31:39 jim kernel: [drm] register mmio base: 0xB0000000
Jul 13 15:31:39 jim kernel: [drm] register mmio size: 65536
Jul 13 15:31:39 jim kernel: [drm] Using generic clock info
Jul 13 15:31:39 jim kernel: agpgart-uninorth 0000:00:0b.0: putting AGP
V2 device into 4x mode
Jul 13 15:31:39 jim kernel: radeon 0000:00:10.0: putting AGP V2 device
into 4x mode
Jul 13 15:31:39 jim kernel: radeon 0000:00:10.0: GTT: 256M 0x00000000
- 0x0FFFFFFF
Jul 13 15:31:39 jim kernel: [drm] Generation 2 PCI interface, using
max accessible memory
Jul 13 15:31:39 jim kernel: radeon 0000:00:10.0: VRAM: 64M 0xB8000000
- 0xBBFFFFFF (64M used)
Jul 13 15:31:39 jim kernel: [drm] radeon: irq initialized.
Jul 13 15:31:39 jim kernel: [drm] Detected VRAM RAM=64M, BAR=128M
Jul 13 15:31:39 jim kernel: [drm] RAM width 128bits DDR
Jul 13 15:31:39 jim kernel: [TTM] Zone kernel: Available graphics
memory: 384990 kiB.
Jul 13 15:31:39 jim kernel: [TTM] Zone highmem: Available graphics
memory: 516062 kiB.
Jul 13 15:31:39 jim kernel: [TTM] Initializing pool allocator.
Jul 13 15:31:39 jim kernel: [drm] radeon: 64M of VRAM memory ready
Jul 13 15:31:39 jim kernel: [drm] radeon: 256M of GTT memory ready.
Jul 13 15:31:39 jim kernel: [drm] radeon: 1 quad pipes, 1 Z pipes initialized.
Jul 13 15:31:39 jim kernel: [drm] Loading R300 Microcode
Jul 13 15:31:39 jim kernel: [drm] radeon: ring at 0x0000000000000000
Jul 13 15:31:39 jim kernel: [drm] ring test succeeded in 3 usecs
Jul 13 15:31:39 jim kernel: [drm] radeon: ib pool ready.
Jul 13 15:31:40 jim kernel: GPU lockup (waiting for 0x00000001 last
fence id 0x00000000)
Jul 13 15:31:40 jim kernel: NIP: f260fda4 LR: f260fda4 CTR: 00000001
Jul 13 15:31:40 jim kernel: REGS: ef3a3b90 TRAP: 0700 Not tainted
(2.6.35-rc4-NAT-00131-ge467e10)
Jul 13 15:31:40 jim kernel: MSR: 00029032 <EE,ME,CE,IR,DR> CR:
22822484 XER: 20000000
Jul 13 15:31:40 jim kernel: TASK = eedb9ac0[2066] 'modprobe' THREAD: ef3a2000
Jul 13 15:31:40 jim kernel: GPR00: f260fda4 ef3a3c40 eedb9ac0 00000040
416d5d8c ffffffff c04db984 416d5d09
Jul 13 15:31:40 jim kernel: GPR08: 416d5d8c 00000001 00000000 0000000a
22822482 100238a8 00000000 00000000
Jul 13 15:31:40 jim kernel: GPR16: 00000000 0000007d c04a0000 f26a1d54
00000001 00000000 00000000 ef3a2000
Jul 13 15:31:40 jim kernel: GPR24: c005f328 ef3a3c54 00000000 eed386cc
ef3a3c48 00000000 eed38000 ef085d40
Jul 13 15:31:40 jim kernel: NIP [f260fda4]
radeon_fence_wait+0x28c/0x2f4 [radeon]
Jul 13 15:31:40 jim kernel: LR [f260fda4] radeon_fence_wait+0x28c/0x2f4 [radeon]
Jul 13 15:31:40 jim kernel: Call Trace:
Jul 13 15:31:40 jim kernel: [ef3a3c40] [f260fda4]
radeon_fence_wait+0x28c/0x2f4 [radeon] (unreliable)
Jul 13 15:31:40 jim kernel: [ef3a3cb0] [f2638234]
r100_ib_test+0x158/0x280 [radeon]
Jul 13 15:31:40 jim kernel: [ef3a3ce0] [f26383a4]
r100_ib_init+0x28/0xc8 [radeon]
Jul 13 15:31:40 jim kernel: [ef3a3cf0] [f263f65c]
r300_startup+0xd4/0x1e4 [radeon]
Jul 13 15:31:40 jim kernel: [ef3a3d00] [f263fb3c] r300_init+0x150/0x334 [radeon]
Jul 13 15:31:40 jim kernel: [ef3a3d10] [f25fc514]
radeon_device_init+0x2b0/0x418 [radeon]
Jul 13 15:31:40 jim kernel: [ef3a3d30] [f25fdc0c]
radeon_driver_load_kms+0xa4/0x1f4 [radeon]
Jul 13 15:31:40 jim kernel: [ef3a3d60] [f2444c4c] drm_get_dev+0x284/0x43c [drm]
Jul 13 15:31:40 jim kernel: [ef3a3d90] [f268d75c]
radeon_pci_probe+0x18/0x28 [radeon]
Jul 13 15:31:40 jim kernel: [ef3a3da0] [c01f6f20] pci_device_probe+0x80/0xa4
Jul 13 15:31:40 jim kernel: [ef3a3dc0] [c025cf2c] driver_probe_device+0xc0/0x208
Jul 13 15:31:40 jim kernel: [ef3a3de0] [c025d130] __driver_attach+0xbc/0xc0
Jul 13 15:31:40 jim kernel: [ef3a3e00] [c025bd28] bus_for_each_dev+0x64/0xa0
Jul 13 15:31:40 jim kernel: [ef3a3e30] [c025cb58] driver_attach+0x24/0x34
Jul 13 15:31:40 jim kernel: [ef3a3e40] [c025c618] bus_add_driver+0xd8/0x308
Jul 13 15:31:40 jim kernel: [ef3a3e70] [c025d418] driver_register+0x88/0x154
Jul 13 15:31:40 jim kernel: [ef3a3e90] [c01f7200]
__pci_register_driver+0x4c/0xdc
Jul 13 15:31:40 jim kernel: [ef3a3eb0] [f243ee50] drm_init+0x120/0x134 [drm]
Jul 13 15:31:40 jim kernel: [ef3a3ed0] [f26c00e4]
radeon_init+0xe4/0x128 [radeon]
Jul 13 15:31:40 jim kernel: [ef3a3ef0] [c0003ff4] do_one_initcall+0x3c/0x1d8
Jul 13 15:31:40 jim kernel: [ef3a3f20] [c007b434] sys_init_module+0xdc/0x1e0
Jul 13 15:31:40 jim kernel: [ef3a3f40] [c0017f84] ret_from_syscall+0x0/0x40
Jul 13 15:31:40 jim kernel: --- Exception: c01 at 0xff62b58
Jul 13 15:31:40 jim kernel: LR = 0x10002c7c
Jul 13 15:31:40 jim kernel: Instruction dump:
Jul 13 15:31:40 jim kernel: 4bffffc4 813e0a18 7fc3f378 80090014
7c0903a6 4e800421 2f830000 419eff78
Jul 13 15:31:40 jim kernel: 809f0010 7e639b78 7ec5b378 4807dc59
<0fe00000> 9a9e16a8 7fc3f378 4bfecd41
Jul 13 15:31:40 jim kernel: radeon 0000:00:10.0: GPU reset succeed
Jul 13 15:31:40 jim kernel: [drm] radeon: 1 quad pipes, 1 Z pipes initialized.
Jul 13 15:31:40 jim kernel: [drm] radeon: ring at 0x0000000000000000
Jul 13 15:31:41 jim kernel: Oops: Kernel access of bad area, sig: 11 [#1]
Jul 13 15:31:41 jim kernel: PREEMPT PowerMac
Jul 13 15:31:41 jim kernel: Modules linked in: radeon(+) ttm
drm_kms_helper drm i2c_algo_bit hid_apple appletouch usbhid arc4 ecb
b43 mac80211 cfg80211 ohci_hcd snd_seq_oss snd_seq_midi_event snd_seq
snd_seq_device therm_adt746x snd_pcm_oss snd_aoa_codec_tas
snd_mixer_oss snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_pcm
snd_timer snd_page_alloc snd ehci_hcd ohci1394 ssb ams input_polldev
yenta_socket soundcore pcmcia usbcore ide_cd_mod pcmcia_rsrc ieee1394
cpufreq_userspace snd_aoa_soundbus i2c_powermac pcmcia_core evdev
cdrom uninorth_agp sungem sungem_phy [last unloaded: i2c_algo_bit]
Jul 13 15:31:41 jim kernel: NIP: f2482248 LR: f25fcb88 CTR: 00000000
Jul 13 15:31:41 jim kernel: REGS: ef3a3b50 TRAP: 0300 Tainted: G
W (2.6.35-rc4-NAT-00131-ge467e10)
Jul 13 15:31:41 jim kernel: MSR: 00009032 <EE,ME,IR,DR> CR: 22822484
XER: 20000000
Jul 13 15:31:41 jim kernel: DAR: 00000000, DSISR: 40000000
Jul 13 15:31:41 jim kernel: TASK = eedb9ac0[2066] 'modprobe' THREAD: ef3a2000
Jul 13 15:31:41 jim kernel: GPR00: f25fcb88 ef3a3c00 eedb9ac0 ef2c8c00
416d67bb ffffffff c04db97e 416d66f1
Jul 13 15:31:41 jim kernel: GPR08: 416d67bb 00000030 f28e002c eed39670
22822482 100238a8 00000000 00000000
Jul 13 15:31:41 jim kernel: GPR16: 00000000 0000007d c04a0000 f26a1d54
00000001 00000000 00000000 ef3a2000
Jul 13 15:31:41 jim kernel: GPR24: c005f328 ef3a3c54 f2484054 f2483878
ef2c8c00 ef2c8ea4 ef2c8e98 fffffffc
Jul 13 15:31:41 jim kernel: NIP [f2482248]
drm_helper_resume_force_mode+0x38/0x16c [drm_kms_helper]
Jul 13 15:31:41 jim kernel: LR [f25fcb88] radeon_gpu_reset+0x98/0x104 [radeon]
Jul 13 15:31:41 jim kernel: Call Trace:
Jul 13 15:31:41 jim kernel: [ef3a3c00] [ffffffea] 0xffffffea (unreliable)
Jul 13 15:31:41 jim kernel: [ef3a3c30] [f25fcb88]
radeon_gpu_reset+0x98/0x104 [radeon]
Jul 13 15:31:41 jim kernel: [ef3a3c40] [f260fdb4]
radeon_fence_wait+0x29c/0x2f4 [radeon]
Jul 13 15:31:41 jim kernel: [ef3a3cb0] [f2638234]
r100_ib_test+0x158/0x280 [radeon]
Jul 13 15:31:41 jim kernel: [ef3a3ce0] [f26383a4]
r100_ib_init+0x28/0xc8 [radeon]
Jul 13 15:31:41 jim kernel: [ef3a3cf0] [f263f65c]
r300_startup+0xd4/0x1e4 [radeon]
Jul 13 15:31:41 jim kernel: [ef3a3d00] [f263fb3c] r300_init+0x150/0x334 [radeon]
Jul 13 15:31:41 jim kernel: [ef3a3d10] [f25fc514]
radeon_device_init+0x2b0/0x418 [radeon]
Jul 13 15:31:41 jim kernel: [ef3a3d30] [f25fdc0c]
radeon_driver_load_kms+0xa4/0x1f4 [radeon]
Jul 13 15:31:41 jim kernel: [ef3a3d60] [f2444c4c] drm_get_dev+0x284/0x43c [drm]
Jul 13 15:31:41 jim kernel: [ef3a3d90] [f268d75c]
radeon_pci_probe+0x18/0x28 [radeon]
Jul 13 15:31:41 jim kernel: [ef3a3da0] [c01f6f20] pci_device_probe+0x80/0xa4
Jul 13 15:31:41 jim kernel: [ef3a3dc0] [c025cf2c] driver_probe_device+0xc0/0x208
Jul 13 15:31:41 jim kernel: [ef3a3de0] [c025d130] __driver_attach+0xbc/0xc0
Jul 13 15:31:41 jim kernel: [ef3a3e00] [c025bd28] bus_for_each_dev+0x64/0xa0
Jul 13 15:31:41 jim kernel: [ef3a3e30] [c025cb58] driver_attach+0x24/0x34
Jul 13 15:31:41 jim kernel: [ef3a3e40] [c025c618] bus_add_driver+0xd8/0x308
Jul 13 15:31:41 jim kernel: [ef3a3e70] [c025d418] driver_register+0x88/0x154
Jul 13 15:31:41 jim kernel: [ef3a3e90] [c01f7200]
__pci_register_driver+0x4c/0xdc
Jul 13 15:31:41 jim kernel: [ef3a3eb0] [f243ee50] drm_init+0x120/0x134 [drm]
Jul 13 15:31:41 jim kernel: [ef3a3ed0] [f26c00e4]
radeon_init+0xe4/0x128 [radeon]
Jul 13 15:31:41 jim kernel: [ef3a3ef0] [c0003ff4] do_one_initcall+0x3c/0x1d8
Jul 13 15:31:41 jim kernel: [ef3a3f20] [c007b434] sys_init_module+0xdc/0x1e0
Jul 13 15:31:41 jim kernel: [ef3a3f40] [c0017f84] ret_from_syscall+0x0/0x40
Jul 13 15:31:41 jim kernel: --- Exception: c01 at 0xff62b58
Jul 13 15:31:41 jim kernel: LR = 0x10002c7c
Jul 13 15:31:41 jim kernel: Instruction dump:
Jul 13 15:31:41 jim kernel: bf010010 7c7d1b78 3f60f248 90010034
3f40f248 3b7b382c 7c7c1b78 3bc30298
Jul 13 15:31:41 jim kernel: 3b5a4054 3b7b004c 87fd02a4 3bfffffc
<813f0004> 2f890000 419e0008 7c004a2c
Jul 13 15:31:41 jim kernel: ---[ end trace 9928f19443a4dfb8 ]---
Jul 13 15:31:48 jim kernel: Oops: Kernel access of bad area, sig: 11 [#2]
Jul 13 15:31:48 jim kernel: PREEMPT PowerMac
Jul 13 15:31:48 jim kernel: Modules linked in: radeon(+) ttm
drm_kms_helper drm i2c_algo_bit hid_apple appletouch usbhid arc4 ecb
b43 mac80211 cfg80211 ohci_hcd snd_seq_oss snd_seq_midi_event snd_seq
snd_seq_device therm_adt746x snd_pcm_oss snd_aoa_codec_tas
snd_mixer_oss snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_pcm
snd_timer snd_page_alloc snd ehci_hcd ohci1394 ssb ams input_polldev
yenta_socket soundcore pcmcia usbcore ide_cd_mod pcmcia_rsrc ieee1394
cpufreq_userspace snd_aoa_soundbus i2c_powermac pcmcia_core evdev
cdrom uninorth_agp sungem sungem_phy [last unloaded: i2c_algo_bit]
Jul 13 15:31:48 jim kernel: NIP: c0382df4 LR: c0382de0 CTR: 00000000
Jul 13 15:31:48 jim kernel: REGS: eed7dd80 TRAP: 0300 Tainted: G
D W (2.6.35-rc4-NAT-00131-ge467e10)
Jul 13 15:31:48 jim kernel: MSR: 00001032 <ME,IR,DR> CR: 24000424
XER: 20000000
Jul 13 15:31:48 jim kernel: DAR: 00000000, DSISR: 42000000
Jul 13 15:31:48 jim kernel: TASK = efb46820[2095] 'X' THREAD: eed7c000
Jul 13 15:31:48 jim kernel: GPR00: ffffffff eed7de30 efb46820 ef2c8e3c
eed7de38 eed7c000 eed7de44 0000082f
Jul 13 15:31:48 jim kernel: GPR08: 0000e200 00000000 0000007f c0382fc8
24000422 101d3ea8 101cbed4 00000000
Jul 13 15:31:48 jim kernel: GPR16: 10478758 00000000 00000001 101d3c0c
00000000 101cb8c8 ef2c8c00 00009032
Jul 13 15:31:48 jim kernel: GPR24: ef2c8dc0 ef2c8e40 eed7de38 efb46820
c04d0000 00009032 eed7c000 ef2c8e3c
Jul 13 15:31:48 jim kernel: NIP [c0382df4] __mutex_lock_slowpath+0xa0/0x274
Jul 13 15:31:48 jim kernel: LR [c0382de0] __mutex_lock_slowpath+0x8c/0x274
Jul 13 15:31:48 jim kernel: Call Trace:
Jul 13 15:31:48 jim kernel: [eed7de30] [c0382dd0]
__mutex_lock_slowpath+0x7c/0x274 (unreliable)
Jul 13 15:31:48 jim kernel: [eed7de70] [c0382fe0] mutex_lock+0x18/0x34
Jul 13 15:31:48 jim kernel: [eed7de80] [f244d010] drm_fb_release+0x28/0xac [drm]
Jul 13 15:31:48 jim kernel: [eed7dea0] [f243fab8] drm_release+0x674/0x770 [drm]
Jul 13 15:31:48 jim kernel: [eed7dee0] [c00fc410] fput+0x118/0x264
Jul 13 15:31:48 jim kernel: [eed7df00] [c00f87d0] filp_close+0x6c/0x98
Jul 13 15:31:48 jim kernel: [eed7df20] [c00f88ac] sys_close+0xb0/0x12c
Jul 13 15:31:48 jim kernel: [eed7df40] [c0017f84] ret_from_syscall+0x0/0x40
Jul 13 15:31:48 jim kernel: --- Exception: c01 at 0xfec3730
Jul 13 15:31:48 jim kernel: LR = 0xf8b9340
Jul 13 15:31:48 jim kernel: Instruction dump:
Jul 13 15:31:48 jim kernel: 7f44d378 3b3f0004 4bcee849 80bb0004
7fe3fb78 7f44d378 4bcee9e5 813f0008
Jul 13 15:31:48 jim kernel: 3800ffff 93210008 935f0008 9121000c
<93490000> 93610010 7d20f828 7c00f92d
Jul 13 15:31:48 jim kernel: ---[ end trace 9928f19443a4dfb9 ]---
Jul 13 15:31:48 jim kernel: note: X[2095] exited with preempt_count 2
Jul 13 15:31:48 jim kernel: Modules linked in: radeon(+) ttm
drm_kms_helper drm i2c_algo_bit hid_apple appletouch usbhid arc4 ecb
b43 mac80211 cfg80211 ohci_hcd snd_seq_oss snd_seq_midi_event snd_seq
snd_seq_device therm_adt746x snd_pcm_oss snd_aoa_codec_tas
snd_mixer_oss snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_pcm
snd_timer snd_page_alloc snd ehci_hcd ohci1394 ssb ams input_polldev
yenta_socket soundcore pcmcia usbcore ide_cd_mod pcmcia_rsrc ieee1394
cpufreq_userspace snd_aoa_soundbus i2c_powermac pcmcia_core evdev
cdrom uninorth_agp sungem sungem_phy [last unloaded: i2c_algo_bit]
Jul 13 15:31:48 jim kernel: Call Trace:
Jul 13 15:31:48 jim kernel: [eed7da50] [c000a6e8]
show_stack+0x50/0x158 (unreliable)
Jul 13 15:31:48 jim kernel: [eed7da90] [c00369bc] __schedule_bug+0x64/0x68
Jul 13 15:31:48 jim kernel: [eed7daa0] [c03816a0] schedule+0x360/0x428
Jul 13 15:31:48 jim kernel: [eed7dae0] [c0382068] schedule_timeout+0x1c0/0x304
Jul 13 15:31:48 jim kernel: [eed7db30] [c0381b7c] wait_for_common+0xd4/0x1c8
Jul 13 15:31:48 jim kernel: [eed7db70] [c005a0b8] flush_cpu_workqueue+0xdc/0x110
Jul 13 15:31:48 jim kernel: [eed7dbb0] [c022fc7c] tty_ldisc_release+0x2c/0x84
Jul 13 15:31:48 jim kernel: [eed7dbd0] [c0228374] tty_release+0x428/0x5b0
Jul 13 15:31:48 jim kernel: [eed7dc70] [c00fc410] fput+0x118/0x264
Jul 13 15:31:48 jim kernel: [eed7dc90] [c00f87d0] filp_close+0x6c/0x98
Jul 13 15:31:48 jim kernel: [eed7dcb0] [c0042958] put_files_struct+0x12c/0x158
Jul 13 15:31:48 jim kernel: [eed7dce0] [c0042b7c] do_exit+0x118/0x708
Jul 13 15:31:48 jim kernel: [eed7dd30] [c0015560] die+0x100/0x2c0
Jul 13 15:31:48 jim kernel: [eed7dd60] [c001f350] bad_page_fault+0x90/0xc8
Jul 13 15:31:48 jim kernel: [eed7dd70] [c001843c] handle_page_fault+0x7c/0x80
Jul 13 15:31:48 jim kernel: --- Exception: 300 at
__mutex_lock_slowpath+0xa0/0x274
Jul 13 15:31:48 jim kernel: LR = __mutex_lock_slowpath+0x8c/0x274
Jul 13 15:31:48 jim kernel: [eed7de30] [c0382dd0]
__mutex_lock_slowpath+0x7c/0x274 (unreliable)
Jul 13 15:31:48 jim kernel: [eed7de70] [c0382fe0] mutex_lock+0x18/0x34
Jul 13 15:31:48 jim kernel: [eed7de80] [f244d010] drm_fb_release+0x28/0xac [drm]
Jul 13 15:31:48 jim kernel: [eed7dea0] [f243fab8] drm_release+0x674/0x770 [drm]
Jul 13 15:31:48 jim kernel: [eed7dee0] [c00fc410] fput+0x118/0x264
Jul 13 15:31:48 jim kernel: [eed7df00] [c00f87d0] filp_close+0x6c/0x98
Jul 13 15:31:48 jim kernel: [eed7df20] [c00f88ac] sys_close+0xb0/0x12c
Jul 13 15:31:48 jim kernel: [eed7df40] [c0017f84] ret_from_syscall+0x0/0x40
Jul 13 15:31:48 jim kernel: --- Exception: c01 at 0xfec3730
Jul 13 15:31:48 jim kernel: LR = 0xf8b9340
Jul 13 15:33:09 jim kernel: Using PowerMac machine description
[Next boot..]
Many thanks
^ permalink raw reply
* Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: Michel Dänzer @ 2010-07-13 14:19 UTC (permalink / raw)
To: jjDaNiMoTh; +Cc: linuxppc-dev, xorg-driver-ati
In-Reply-To: <AANLkTikdlwl6VxdbkHP0TveQ3SPO0w4RD-onoG3QPyCO@mail.gmail.com>
On Die, 2010-07-13 at 16:03 +0200, jjDaNiMoTh wrote:=20
>=20
> When trying new 2.6.35-rc4, our kernel team (ArchLinuxPPC) has tried
> to setup KMS acceleration for radeon based machine.
> We have removed radeonfb, and all others framebuffer driver, and added
> fbcon and KMS enabled by default for radeon driver.
>=20
> With a clean start, the screen freeze, when the control pass from
> yaboot to kernel.
>=20
> If we start with video=3Dfbcon (or video=3Dradeondrmfb), we could reach
> the loading modules point, [...]
Which framebuffer device (if any) is it trying to initialize otherwise?
OFfb? The first paragraph above implies none, but then I'm not sure why
the video=3D parameters would make any difference.
> Jul 13 15:31:39 jim kernel: [drm] Initialized drm 1.1.0 20060810
> Jul 13 15:31:39 jim kernel: [drm] radeon kernel modesetting enabled.
> Jul 13 15:31:39 jim kernel: [drm] initializing kernel modesetting
> (RV350 0x1002:0x4E50).
> Jul 13 15:31:39 jim kernel: [drm] register mmio base: 0xB0000000
> Jul 13 15:31:39 jim kernel: [drm] register mmio size: 65536
> Jul 13 15:31:39 jim kernel: [drm] Using generic clock info
> Jul 13 15:31:39 jim kernel: agpgart-uninorth 0000:00:0b.0: putting AGP
> V2 device into 4x mode
> Jul 13 15:31:39 jim kernel: radeon 0000:00:10.0: putting AGP V2 device
> into 4x mode
> Jul 13 15:31:39 jim kernel: radeon 0000:00:10.0: GTT: 256M 0x00000000
> - 0x0FFFFFFF
> Jul 13 15:31:39 jim kernel: [drm] Generation 2 PCI interface, using
> max accessible memory
> Jul 13 15:31:39 jim kernel: radeon 0000:00:10.0: VRAM: 64M 0xB8000000
> - 0xBBFFFFFF (64M used)
> Jul 13 15:31:39 jim kernel: [drm] radeon: irq initialized.
> Jul 13 15:31:39 jim kernel: [drm] Detected VRAM RAM=3D64M, BAR=3D128M
> Jul 13 15:31:39 jim kernel: [drm] RAM width 128bits DDR
> Jul 13 15:31:39 jim kernel: [TTM] Zone kernel: Available graphics
> memory: 384990 kiB.
> Jul 13 15:31:39 jim kernel: [TTM] Zone highmem: Available graphics
> memory: 516062 kiB.
> Jul 13 15:31:39 jim kernel: [TTM] Initializing pool allocator.
> Jul 13 15:31:39 jim kernel: [drm] radeon: 64M of VRAM memory ready
> Jul 13 15:31:39 jim kernel: [drm] radeon: 256M of GTT memory ready.
> Jul 13 15:31:39 jim kernel: [drm] radeon: 1 quad pipes, 1 Z pipes initial=
ized.
> Jul 13 15:31:39 jim kernel: [drm] Loading R300 Microcode
> Jul 13 15:31:39 jim kernel: [drm] radeon: ring at 0x0000000000000000
> Jul 13 15:31:39 jim kernel: [drm] ring test succeeded in 3 usecs
> Jul 13 15:31:39 jim kernel: [drm] radeon: ib pool ready.
So far, so good.
> Jul 13 15:31:40 jim kernel: GPU lockup (waiting for 0x00000001 last
> fence id 0x00000000)
The GPU locks up, and things go downhill from there...
Does KMS work better with radeon.agpmode=3D1 (or 2 or -1)?
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* [PATCH] powerpc: Add vmcoreinfo symbols to allow makdumpfile to filter core files properly
From: Neil Horman @ 2010-07-13 13:46 UTC (permalink / raw)
To: linux-kernel, kexec, vgoyal, hbabu, benh, paulus, linuxppc-dev; +Cc: nhorman
Hey all-
About 2 years ago now, I sent this patch upstream to allow makedumpfile
to properly filter cores on ppc64:
http://www.mail-archive.com/kexec@lists.infradead.org/msg02426.html
It got acks from the kexec folks so I pulled it into RHEL, but I never checked
back here to make sure it ever made it in, which apparently it didn't. It still
needs to be included, so I'm reposting it here, making sure to copy all the ppc
folks this time. I've retested it on the latest linus kernel and it works fine,
allowing makedumpfile to find all the symbols it needs to properly strip a
vmcore on ppc64.
Neil
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
machine_kexec.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
index bb3d893..0df7031 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -45,6 +45,18 @@ void machine_kexec_cleanup(struct kimage *image)
ppc_md.machine_kexec_cleanup(image);
}
+void arch_crash_save_vmcoreinfo(void)
+{
+
+#ifdef CONFIG_NEED_MULTIPLE_NODES
+ VMCOREINFO_SYMBOL(node_data);
+ VMCOREINFO_LENGTH(node_data, MAX_NUMNODES);
+#endif
+#ifndef CONFIG_NEED_MULTIPLE_NODES
+ VMCOREINFO_SYMBOL(contig_page_data);
+#endif
+}
+
/*
* Do not allocate memory (or fail in any way) in machine_kexec().
* We are past the point of no return, committed to rebooting now.
^ permalink raw reply related
* Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: jjDaNiMoTh @ 2010-07-13 14:51 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev, xorg-driver-ati
In-Reply-To: <1279030767.515.15.camel@thor.local>
2010/7/13 Michel D=C3=A4nzer <michel@daenzer.net>:
[cut]
> Which framebuffer device (if any) is it trying to initialize otherwise?
> OFfb? The first paragraph above implies none, but then I'm not sure why
> the video=3D parameters would make any difference.
We tried and with 2.6.35-rc4 we could boot without video=3D. First good new=
s :)
[cut]
> Does KMS work better with radeon.agpmode=3D1 (or 2 or -1)?
with radeon.agpmode=3D-1, we could start X server (no black screen),
with both radeon.modeset=3D{0,1}. In all cases, Xorg works fine, except
when we try to load an OpenGL application (like glxgears), Xorg
freeze, we could move only the mouse, we couldn't switch to a backup
console. Same situations with glxgears in both modeset=3D0 and =3D1. In
the log (Xorg.0.log) we have found:
[.. other xorg log, no EE only WW]
[ 65.238] (II) RADEON(0): Panel infos found from DDC detailed: 1280x854
[ 65.238] (II) RADEON(0): EDID vendor "APP", prod id 39968
[ 65.249] (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0
[ 65.249] Unhandled monitor type 0
[ 65.249] (II) RADEON(0): Output: S-video, Detected Monitor Type: 0
[ 137.813] [mi] EQ overflowing. The server is probably stuck in an
infinite loop.
[ 137.813]
Backtrace:
[ 137.814] 0: /usr/bin/X (xorg_backtrace+0x58) [0x100582cc]
[ 137.814] 1: /usr/bin/X (mieqEnqueue+0x1c8) [0x1004e5d8]
[ 137.814] 2: /usr/bin/X (xf86PostButtonEventP+0xf4) [0x10061be8]
[ 137.814] 3: /usr/bin/X (xf86PostButtonEvent+0xb4) [0x10061d2c]
[ 137.814] 4: /usr/lib/xorg/modules/input/evdev_drv.so
(0xf380000+0x3d88) [0xf383d88]
[ 137.814] 5: /usr/bin/X (0x10000000+0x68784) [0x10068784]
[ 137.814] 6: /usr/bin/X (0x10000000+0x11a7e4) [0x1011a7e4]
[ 137.814] 7: (vdso) (__kernel_sigtramp32+0x0) [0x100344]
[ 137.814] 8: /usr/lib/xorg/modules/dri/r300_dri.so
(0xf3f5000+0x48534) [0xf43d534]
[ 137.814] 9: /usr/lib/libdrm.so.2 (drmIoctl+0x40) [0xf8b8f64]
[ 137.814] 10: /usr/lib/libdrm.so.2 (drmCommandWrite+0x24) [0xf8bbe60]
[ 137.814] 11: /usr/lib/xorg/modules/dri/r300_dri.so
(0xf3f5000+0x46944) [0xf43b944]
[ 137.814] 12: /usr/lib/xorg/modules/dri/r300_dri.so
(0xf3f5000+0x64d8c) [0xf459d8c]
[ 137.814] 13: /usr/lib/xorg/modules/extensions/libglx.so
(0xf930000+0x40f78) [0xf970f78]
[ 137.814] 14: /usr/lib/xorg/modules/extensions/libglx.so
(0xf930000+0x44be4) [0xf974be4]
[ 137.814] 15: /usr/bin/X (0x10000000+0x34a24) [0x10034a24]
[ 137.815] 16: /usr/bin/X (0x10000000+0x18bc4) [0x10018bc4]
[ 137.815] 17: /lib/libc.so.6 (0xfb39000+0x1f544) [0xfb58544]
[ 137.815] 18: /lib/libc.so.6 (0xfb39000+0x1f6d0) [0xfb586d0]
Do we need to compile mesa, ati-dri, x.org and xf86-video-ati from git?
Many thanks
^ permalink raw reply
* Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: Michel Dänzer @ 2010-07-13 14:59 UTC (permalink / raw)
To: jjDaNiMoTh; +Cc: linuxppc-dev, xorg-driver-ati
In-Reply-To: <AANLkTilk4-gIiJPQb5aqZ5v4YvgzsddexnsmrFBER5HO@mail.gmail.com>
On Die, 2010-07-13 at 16:51 +0200, jjDaNiMoTh wrote:=20
> 2010/7/13 Michel D=C3=A4nzer <michel@daenzer.net>:
> > Does KMS work better with radeon.agpmode=3D1 (or 2 or -1)?
>=20
> with radeon.agpmode=3D-1, we could start X server (no black screen),
> with both radeon.modeset=3D{0,1}.
Note that radeon.agpmode is only effective with radeon.modeset=3D1,
otherwise you need to use Option "AGPMode" in xorg.conf (and vice
versa).
> In all cases, Xorg works fine, except when we try to load an OpenGL
> application (like glxgears), Xorg freeze, we could move only the
> mouse, we couldn't switch to a backup console.
Could be a GPU lockup again, possibly due to still using AGP 4x with
modeset=3D0.
> Same situations with glxgears in both modeset=3D0 and =3D1. In the log
> (Xorg.0.log) we have found:=20
>=20
> [.. other xorg log, no EE only WW]
> [ 65.238] (II) RADEON(0): Panel infos found from DDC detailed: 1280x85=
4
> [ 65.238] (II) RADEON(0): EDID vendor "APP", prod id 39968
> [ 65.249] (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0
> [ 65.249] Unhandled monitor type 0
> [ 65.249] (II) RADEON(0): Output: S-video, Detected Monitor Type: 0
> [ 137.813] [mi] EQ overflowing. The server is probably stuck in an
> infinite loop.
> [ 137.813]
> Backtrace:
> [ 137.814] 0: /usr/bin/X (xorg_backtrace+0x58) [0x100582cc]
> [ 137.814] 1: /usr/bin/X (mieqEnqueue+0x1c8) [0x1004e5d8]
> [ 137.814] 2: /usr/bin/X (xf86PostButtonEventP+0xf4) [0x10061be8]
> [ 137.814] 3: /usr/bin/X (xf86PostButtonEvent+0xb4) [0x10061d2c]
> [ 137.814] 4: /usr/lib/xorg/modules/input/evdev_drv.so
> (0xf380000+0x3d88) [0xf383d88]
> [ 137.814] 5: /usr/bin/X (0x10000000+0x68784) [0x10068784]
> [ 137.814] 6: /usr/bin/X (0x10000000+0x11a7e4) [0x1011a7e4]
> [ 137.814] 7: (vdso) (__kernel_sigtramp32+0x0) [0x100344]
> [ 137.814] 8: /usr/lib/xorg/modules/dri/r300_dri.so
> (0xf3f5000+0x48534) [0xf43d534]
> [ 137.814] 9: /usr/lib/libdrm.so.2 (drmIoctl+0x40) [0xf8b8f64]
> [ 137.814] 10: /usr/lib/libdrm.so.2 (drmCommandWrite+0x24) [0xf8bbe60]
> [ 137.814] 11: /usr/lib/xorg/modules/dri/r300_dri.so
> (0xf3f5000+0x46944) [0xf43b944]
> [ 137.814] 12: /usr/lib/xorg/modules/dri/r300_dri.so
> (0xf3f5000+0x64d8c) [0xf459d8c]
> [ 137.814] 13: /usr/lib/xorg/modules/extensions/libglx.so
> (0xf930000+0x40f78) [0xf970f78]
> [ 137.814] 14: /usr/lib/xorg/modules/extensions/libglx.so
> (0xf930000+0x44be4) [0xf974be4]
> [ 137.814] 15: /usr/bin/X (0x10000000+0x34a24) [0x10034a24]
> [ 137.815] 16: /usr/bin/X (0x10000000+0x18bc4) [0x10018bc4]
> [ 137.815] 17: /lib/libc.so.6 (0xfb39000+0x1f544) [0xfb58544]
> [ 137.815] 18: /lib/libc.so.6 (0xfb39000+0x1f6d0) [0xfb586d0]
What does the log file contain with modeset=3D1?
> Do we need to compile mesa, ati-dri, x.org and xf86-video-ati from git?
Shouldn't be necessary.
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: section .data..init_task
From: Sean MacLennan @ 2010-07-13 15:26 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Denys Vlasenko, linuxppc-dev, Tim Abbott
In-Reply-To: <20100713085419.GA5826@merkur.ravnborg.org>
On Tue, 13 Jul 2010 10:54:19 +0200
Sam Ravnborg <sam@ravnborg.org> wrote:
> It looks like a missing AT() in the output section.
> The following patch should also fix it.
>
> Please test and let us know.
>
> Thanks,
> Sam
Applied the patch and it solves the problem. Thanks.
Cheers,
Sean
^ permalink raw reply
* Re: section .data..init_task
From: Sam Ravnborg @ 2010-07-13 15:33 UTC (permalink / raw)
To: Sean MacLennan; +Cc: Denys Vlasenko, linuxppc-dev, Tim Abbott
In-Reply-To: <20100713112610.30b66318@lappy.seanm.ca>
On Tue, Jul 13, 2010 at 11:26:10AM -0400, Sean MacLennan wrote:
> On Tue, 13 Jul 2010 10:54:19 +0200
> Sam Ravnborg <sam@ravnborg.org> wrote:
>
> > It looks like a missing AT() in the output section.
> > The following patch should also fix it.
> >
> > Please test and let us know.
> >
> > Thanks,
> > Sam
>
> Applied the patch and it solves the problem. Thanks.
Thanks for the quick feedback!
Sam
^ permalink raw reply
* Re: [PATCH 1/7] Split the memory_block structure
From: Nathan Fontenot @ 2010-07-13 15:44 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20100713151855.3d56242d.kamezawa.hiroyu@jp.fujitsu.com>
Thanks for the review, answers below...
-Nathan
On 07/13/2010 01:18 AM, KAMEZAWA Hiroyuki wrote:
>
> plz cc linux-mm in the next time...
> And please incudes updates for Documentation/memory-hotplug.txt.
>
will do.
>
> On Mon, 12 Jul 2010 10:42:06 -0500
> Nathan Fontenot <nfont@austin.ibm.com> wrote:
>
>> This patch splits the memory_block struct into a memory_block
>> struct to cover each sysfs directory and a new memory_block_section
>> struct for each memory section covered by the sysfs directory.
>>
>> This also updates the routine handling memory_block creation
>> and manipulation to use these updated structures.
>>
>
> Could you clarify the number of memory_block_section per memory_block ?
The default number of memory_block_sections per memory block is 1. The
memory_block_size() routine (defined as __weak) sets the size of the
memory block, and thus the number of memory_block_sections.
The current view of memory in sysfs where each directory covers a single
memory section should still hold for everyone, unless a arch defines
their own memory_section_size routine to alter the behavior.
>
>
>> Signed -off-by: Nathan Fontenot <nfont@austin.ibm.com>
>> ---
>> drivers/base/memory.c | 228 +++++++++++++++++++++++++++++++++++--------------
>> include/linux/memory.h | 11 +-
>> 2 files changed, 172 insertions(+), 67 deletions(-)
>>
>> Index: linux-2.6/drivers/base/memory.c
>> ===================================================================
>> --- linux-2.6.orig/drivers/base/memory.c 2010-07-08 11:27:21.000000000 -0500
>> +++ linux-2.6/drivers/base/memory.c 2010-07-09 14:23:09.000000000 -0500
>> @@ -28,6 +28,14 @@
>> #include <asm/uaccess.h>
>>
>> #define MEMORY_CLASS_NAME "memory"
>> +#define MIN_MEMORY_BLOCK_SIZE (1 << SECTION_SIZE_BITS)
>> +
>> +static int sections_per_block;
>> +
> some default value, plz. Does this can be determined only by .config ?
The default is 1. This is determined in the get_memory_block_size() which
is called from the memory sysfs init routine.
>
>
>> +static inline int base_memory_block_id(int section_nr)
>> +{
>> + return (section_nr / sections_per_block) * sections_per_block;
>> +}
>>
>> static struct sysdev_class memory_sysdev_class = {
>> .name = MEMORY_CLASS_NAME,
>> @@ -94,10 +102,9 @@
>> }
>>
>> static void
>> -unregister_memory(struct memory_block *memory, struct mem_section *section)
>> +unregister_memory(struct memory_block *memory)
>> {
>> BUG_ON(memory->sysdev.cls != &memory_sysdev_class);
>> - BUG_ON(memory->sysdev.id != __section_nr(section));
>>
>> /* drop the ref. we got in remove_memory_block() */
>> kobject_put(&memory->sysdev.kobj);
>> @@ -123,13 +130,20 @@
>> static ssize_t show_mem_removable(struct sys_device *dev,
>> struct sysdev_attribute *attr, char *buf)
>> {
>> - unsigned long start_pfn;
>> - int ret;
>> - struct memory_block *mem =
>> - container_of(dev, struct memory_block, sysdev);
>> + struct list_head *pos, *tmp;
>> + struct memory_block *mem;
>> + int ret = 1;
>> +
>> + mem = container_of(dev, struct memory_block, sysdev);
>> + list_for_each_safe(pos, tmp, &mem->sections) {
>> + struct memory_block_section *mbs;
>> + unsigned long start_pfn;
>> +
>> + mbs = list_entry(pos, struct memory_block_section, next);
>
> list_for_each_entry ?
I went with list_for_each_safe() here since I am not holding the mutex
while walking the list. Perhaps this should be changed to take the
mutex and use list_for_each_entry().
>
>
>
>> + start_pfn = section_nr_to_pfn(mbs->phys_index);
>> + ret &= is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
>> + }
>
> Hmm, them, only when the whole memory block is removable, it's shown as
> removable. Right ?
> Does it meets ppc guy's requirements ?
Yes, and yes.
>
>>
>> - start_pfn = section_nr_to_pfn(mem->phys_index);
>> - ret = is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
>> return sprintf(buf, "%d\n", ret);
>> }
>
> Hmm...can't you print removable information as bitmap, here ?
> overkill ?
We could print it as a bitmap, but I think it would be overkill. The
memory add/remove routines work on a memory_block such that all
memory_block_sections in the memory_block are added/removed as a whole.
Given this, I figured we only needed to know if the entire memory_block
is removable.
>
>
>>
>> @@ -182,16 +196,16 @@
>> * OK to have direct references to sparsemem variables in here.
>> */
>> static int
>> -memory_block_action(struct memory_block *mem, unsigned long action)
>> +memory_block_action(struct memory_block_section *mbs, unsigned long action)
>> {
>> int i;
>> unsigned long psection;
>> unsigned long start_pfn, start_paddr;
>> struct page *first_page;
>> int ret;
>> - int old_state = mem->state;
>> ot-option-to-disable-memory-hotplug.patch
>> + int old_state = mbs->state;
>
> Where is this noise from ?
Yuck! I'll take a look. That shouldn't be there obviously.
>
>>
>> - psection = mem->phys_index;
>> + psection = mbs->phys_index;
>> first_page = pfn_to_page(psection << PFN_SECTION_SHIFT);
>>
>> /*
>> @@ -217,18 +231,18 @@
>> ret = online_pages(start_pfn, PAGES_PER_SECTION);
>> break;
>> case MEM_OFFLINE:
>> - mem->state = MEM_GOING_OFFLINE;
>> + mbs->state = MEM_GOING_OFFLINE;
>> start_paddr = page_to_pfn(first_page) << PAGE_SHIFT;
>> ret = remove_memory(start_paddr,
>> PAGES_PER_SECTION << PAGE_SHIFT);
>> if (ret) {
>> - mem->state = old_state;
>> + mbs->state = old_state;
>> break;
>> }
>> break;
>> default:
>> WARN(1, KERN_WARNING "%s(%p, %ld) unknown action: %ld\n",
>> - __func__, mem, action, action);
>> + __func__, mbs, action, action);
>> ret = -EINVAL;
>> }
>>
>> @@ -238,19 +252,40 @@
>> static int memory_block_change_state(struct memory_block *mem,
>> unsigned long to_state, unsigned long from_state_req)
>> {
>> + struct memory_block_section *mbs;
>> + struct list_head *pos;
>> int ret = 0;
>> +
>> mutex_lock(&mem->state_mutex);
>>
>> - if (mem->state != from_state_req) {
>> - ret = -EINVAL;
>> - goto out;
>> + list_for_each(pos, &mem->sections) {
>> + mbs = list_entry(pos, struct memory_block_section, next);
>> +
>
> list_for_each_entry() ?
That could be done here.
>
>> + if (mbs->state != from_state_req)
>> + continue;
>> +
>> + ret = memory_block_action(mbs, to_state);
>> + if (ret)
>> + break;
>> + }
>
> Then, all actions will be affect all memory sections under memory block ?
> (Hmm..maybe have to see following patches ?)
Correct. Add/remove actions will work on a memory_block as a whole.
>
>
>> +
>> + if (ret) {
>> + list_for_each(pos, &mem->sections) {
>> + mbs = list_entry(pos, struct memory_block_section,
>> + next);
>> +
> list_for_each_entry() ?
got it. :)
>
>> + if (mbs->state == from_state_req)
>> + continue;
>> +
>> + if (memory_block_action(mbs, to_state))
>> + printk(KERN_ERR "Could not re-enable memory "
>> + "section %lx\n", mbs->phys_index);
>> + }
>> }
>>
>> - ret = memory_block_action(mem, to_state);
>> if (!ret)
>> mem->state = to_state;
>>
>> -out:
>> mutex_unlock(&mem->state_mutex);
>> return ret;
>> }
>> @@ -260,20 +295,15 @@
>> struct sysdev_attribute *attr, const char *buf, size_t count)
>> {
>
> Hmm, store_mem_state() ? What diff option are you using ?
Yes, this is store_mem_state.
Patches were generated with quilt.
>
>
>> struct memory_block *mem;
>> - unsigned int phys_section_nr;
>> int ret = -EINVAL;
>>
>> mem = container_of(dev, struct memory_block, sysdev);
>> - phys_section_nr = mem->phys_index;
>> -
>> - if (!present_section_nr(phys_section_nr))
>> - goto out;
>>
>> if (!strncmp(buf, "online", min((int)count, 6)))
>> ret = memory_block_change_state(mem, MEM_ONLINE, MEM_OFFLINE);
>> else if(!strncmp(buf, "offline", min((int)count, 7)))
>> ret = memory_block_change_state(mem, MEM_OFFLINE, MEM_ONLINE);
>> -out:
>> +
>> if (ret)
>> return ret;
>> return count;
>> @@ -435,39 +465,6 @@
>> return 0;
>> }
>>
>> -static int add_memory_block(int nid, struct mem_section *section,
>> - unsigned long state, enum mem_add_context context)
>> -{
>> - struct memory_block *mem = kzalloc(sizeof(*mem), GFP_KERNEL);
>> - unsigned long start_pfn;
>> - int ret = 0;
>> -
>> - if (!mem)
>> - return -ENOMEM;
>> -
>> - mem->phys_index = __section_nr(section);
>> - mem->state = state;
>> - mutex_init(&mem->state_mutex);
>> - start_pfn = section_nr_to_pfn(mem->phys_index);
>> - mem->phys_device = arch_get_memory_phys_device(start_pfn);
>> -
>> - ret = register_memory(mem, section);
>> - if (!ret)
>> - ret = mem_create_simple_file(mem, phys_index);
>> - if (!ret)
>> - ret = mem_create_simple_file(mem, state);
>> - if (!ret)
>> - ret = mem_create_simple_file(mem, phys_device);
>> - if (!ret)
>> - ret = mem_create_simple_file(mem, removable);
>> - if (!ret) {
>> - if (context == HOTPLUG)
>> - ret = register_mem_sect_under_node(mem, nid);
>> - }
>> -
>> - return ret;
>> -}
>> -
>
>
> please divide clean-up and logic-change patches into their own..
ok.
>
>
>> /*
>> * For now, we have a linear search to go find the appropriate
>> * memory_block corresponding to a particular phys_index. If
>> @@ -482,12 +479,13 @@
>> struct sys_device *sysdev;
>> struct memory_block *mem;
>> char name[sizeof(MEMORY_CLASS_NAME) + 9 + 1];
>> + int block_id = base_memory_block_id(__section_nr(section));
>>
>> /*
>> * This only works because we know that section == sysdev->id
>> * slightly redundant with sysdev_register()
>> */
>> - sprintf(&name[0], "%s%d", MEMORY_CLASS_NAME, __section_nr(section));
>> + sprintf(&name[0], "%s%d", MEMORY_CLASS_NAME, block_id);
>
> Hmm. Then, the user has to calculate block-id in addtion to section-id.
> Can't we use memory block name as memory%d-%d(start-end) ?
I am not attached to a particular name for the directories. I think
keeping the memory%d, where %d is the starting id makes the code that splits
the directory cleaner.
In a later patch I add a new file for each directory that has the ending
id in it so users can easily determine the start and end id's of the
memory block.
>
>
>
>>
>> kobj = kset_find_obj(&memory_sysdev_class.kset, name);
>> if (!kobj)
>> @@ -498,19 +496,97 @@
>>
>> return mem;
>> }
>> +static int add_mem_block_section(struct memory_block *mem,
>> + int section_nr, unsigned long state)
>> +{
>> + struct memory_block_section *mbs;
>> +
>> + mbs = kzalloc(sizeof(*mbs), GFP_KERNEL);
>> + if (!mbs)
>> + return -ENOMEM;
>> +
>> + mbs->phys_index = section_nr;
>> + mbs->state = state;
>> +
>> + list_add(&mbs->next, &mem->sections);
>> + return 0;
>> +}
>> +
>> +static int add_memory_block(int nid, struct mem_section *section,
>> + unsigned long state, enum mem_add_context context)
>> +{
>> + struct memory_block *mem;
>> + int ret = 0;
>> +
>> + mem = find_memory_block(section);
>
> I guess you need to add changes to find_memory_block. section-ID != block-ID.
That is above, see the line
>> + int block_id = base_memory_block_id(__section_nr(section));
>
>
>> + if (!mem) {
>> + unsigned long start_pfn;
>> +
>> + mem = kzalloc(sizeof(*mem), GFP_KERNEL);
>> + if (!mem)
>> + return -ENOMEM;
>> +
>> + mem->state = state;
>> + mutex_init(&mem->state_mutex);
>> + start_pfn = section_nr_to_pfn(__section_nr(section));
>> + mem->phys_device = arch_get_memory_phys_device(start_pfn);
>> + INIT_LIST_HEAD(&mem->sections);
>
> I'm not sure this phys_device is properly set in any arch...but this changes in
> granule will not affect ?
I don't think so, hopefully someone will speak up if this causes an issue.
>
>> +
>> + ret = register_memory(mem, section);
>> + if (!ret)
>> + ret = mem_create_simple_file(mem, phys_index);
>> + if (!ret)
>> + ret = mem_create_simple_file(mem, state);
>> + if (!ret)
>> + ret = mem_create_simple_file(mem, phys_device);
>> + if (!ret)
>> + ret = mem_create_simple_file(mem, removable);
>> + if (!ret) {
>> + if (context == HOTPLUG)
>> + ret = register_mem_sect_under_node(mem, nid);
>> + }
>> + } else {
>> + kobject_put(&mem->sysdev.kobj);
>> + }
>> +
>> + if (!ret)
>> + ret = add_mem_block_section(mem, __section_nr(section), state);
>> +
>> + return ret;
>> +}
>
>
>
>
>
>>
>> int remove_memory_block(unsigned long node_id, struct mem_section *section,
>> int phys_device)
>> {
>> struct memory_block *mem;
>> + struct memory_block_section *mbs;
>> + struct list_head *pos, *tmp;
>> + int section_nr = __section_nr(section);
>>
>> mem = find_memory_block(section);
>
> ditto.
>
>> - unregister_mem_sect_under_nodes(mem);
>> - mem_remove_simple_file(mem, phys_index);
>> - mem_remove_simple_file(mem, state);
>> - mem_remove_simple_file(mem, phys_device);
>> - mem_remove_simple_file(mem, removable);
>> - unregister_memory(mem, section);
>> + mutex_lock(&mem->state_mutex);
>> +
>> + /* remove the specified section */
>> + list_for_each_safe(pos, tmp, &mem->sections) {
>> + mbs = list_entry(pos, struct memory_block_section, next);
>> +
> list_for_each_entry_safe ?
yep. :)
>
>> + if (mbs->phys_index == section_nr) {
>> + list_del(&mbs->next);
>> + kfree(mbs);
>> + }
>> + }
>> +
>> + mutex_unlock(&mem->state_mutex);
>> +
>> + if (list_empty(&mem->sections)) {
>> + unregister_mem_sect_under_nodes(mem);
>> + mem_remove_simple_file(mem, phys_index);
>> + mem_remove_simple_file(mem, state);
>> + mem_remove_simple_file(mem, phys_device);
>> + mem_remove_simple_file(mem, removable);
>> + unregister_memory(mem);
>> + kfree(mem);
>> + }
>>
>> return 0;
>> }
>> @@ -532,6 +608,24 @@
>> return remove_memory_block(0, section, 0);
>> }
>>
>> +u32 __weak memory_block_size(void)
>> +{
>> + return MIN_MEMORY_BLOCK_SIZE;
>> +}
>> +
>> +static u32 get_memory_block_size(void)
>> +{
>> + u32 blk_sz;
>> +
>> + blk_sz = memory_block_size();
>> +
>> + /* Validate blk_sz is a power of 2 and not less than section size */
>> + if ((blk_sz & (blk_sz - 1)) || (blk_sz < MIN_MEMORY_BLOCK_SIZE))
>> + blk_sz = MIN_MEMORY_BLOCK_SIZE;
>> +
>> + return blk_sz;
>> +}
>> +
>> /*
>> * Initialize the sysfs support for memory devices...
>> */
>> @@ -540,12 +634,16 @@
>> unsigned int i;
>> int ret;
>> int err;
>> + int block_sz;
>>
>> memory_sysdev_class.kset.uevent_ops = &memory_uevent_ops;
>> ret = sysdev_class_register(&memory_sysdev_class);
>> if (ret)
>> goto out;
>>
>> + block_sz = get_memory_block_size();
>> + sections_per_block = block_sz / MIN_MEMORY_BLOCK_SIZE;
>> +
>> /*
>> * Create entries for memory sections that were found
>> * during boot and have been initialized
>> Index: linux-2.6/include/linux/memory.h
>> ===================================================================
>> --- linux-2.6.orig/include/linux/memory.h 2010-07-08 11:27:21.000000000 -0500
>> +++ linux-2.6/include/linux/memory.h 2010-07-09 14:22:44.000000000 -0500
>> @@ -19,9 +19,15 @@
>> #include <linux/node.h>
>> #include <linux/compiler.h>
>> #include <linux/mutex.h>
>> +#include <linux/list.h>
>>
>> -struct memory_block {
>> +struct memory_block_section {
>> + unsigned long state;
>> unsigned long phys_index;
>> + struct list_head next;
>> +};
>> +
>> +struct memory_block {
>> unsigned long state;
>> /*
>> * This serializes all state change requests. It isn't
>> @@ -34,6 +40,7 @@
>> void *hw; /* optional pointer to fw/hw data */
>> int (*phys_callback)(struct memory_block *);
>> struct sys_device sysdev;
>> + struct list_head sections;
>> };
>>
>> int arch_get_memory_phys_device(unsigned long start_pfn);
>> @@ -113,7 +120,7 @@
>> extern int remove_memory_block(unsigned long, struct mem_section *, int);
>> extern int memory_notify(unsigned long val, void *v);
>> extern int memory_isolate_notify(unsigned long val, void *v);
>> -extern struct memory_block *find_memory_block(unsigned long);
>> +extern struct memory_block *find_memory_block(struct mem_section *);
>> extern int memory_is_hidden(struct mem_section *);
>> #define CONFIG_MEM_BLOCK_SIZE (PAGES_PER_SECTION<<PAGE_SHIFT)
>> enum mem_add_context { BOOT, HOTPLUG };
>> --
>> 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
* Re: [PATCH 3/7] Update the [register,unregister]_memory routines
From: Nathan Fontenot @ 2010-07-13 15:46 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20100713152044.7ec8c9ae.kamezawa.hiroyu@jp.fujitsu.com>
On 07/13/2010 01:20 AM, KAMEZAWA Hiroyuki wrote:
> On Mon, 12 Jul 2010 10:44:10 -0500
> Nathan Fontenot <nfont@austin.ibm.com> wrote:
>
>> This patch moves the register/unregister_memory routines to
>> avoid a forward declaration. It also moves the sysfs file
>> creation and deletion for each directory into the register/
>> unregister routines to avoid duplicating it with these updates.
>>
>> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
>> ---
>> drivers/base/memory.c | 93 +++++++++++++++++++++++++-------------------------
>> 1 file changed, 48 insertions(+), 45 deletions(-)
>>
>> Index: linux-2.6/drivers/base/memory.c
>> ===================================================================
>> --- linux-2.6.orig/drivers/base/memory.c 2010-07-09 14:23:17.000000000 -0500
>> +++ linux-2.6/drivers/base/memory.c 2010-07-09 14:23:20.000000000 -0500
>> @@ -87,31 +87,6 @@
>> EXPORT_SYMBOL(unregister_memory_isolate_notifier);
>>
>> /*
>> - * register_memory - Setup a sysfs device for a memory block
>> - */
>> -static
>> -int register_memory(struct memory_block *memory, struct mem_section *section)
>> -{
>> - int error;
>> -
>> - memory->sysdev.cls = &memory_sysdev_class;
>> - memory->sysdev.id = __section_nr(section);
>> -
>> - error = sysdev_register(&memory->sysdev);
>> - return error;
>> -}
>> -
>> -static void
>> -unregister_memory(struct memory_block *memory)
>> -{
>> - BUG_ON(memory->sysdev.cls != &memory_sysdev_class);
>> -
>> - /* drop the ref. we got in remove_memory_block() */
>> - kobject_put(&memory->sysdev.kobj);
>> - sysdev_unregister(&memory->sysdev);
>> -}
>> -
>> -/*
>> * use this as the physical section index that this memsection
>> * uses.
>> */
>> @@ -346,6 +321,53 @@
>> sysdev_remove_file(&mem->sysdev, &attr_##attr_name)
>>
>> /*
>> + * register_memory - Setup a sysfs device for a memory block
>> + */
>> +static
>> +int register_memory(struct memory_block *memory, struct mem_section *section,
>> + int nid, enum mem_add_context context)
>> +{
>> + int ret;
>> +
>> + memory->sysdev.cls = &memory_sysdev_class;
>> + memory->sysdev.id = __section_nr(section);
>> +
> Why not block-ID but section-ID ?
Using the beginning section id as the id here makes the splitting of
memory_block's easier since we can assume that the id is unique.
>
> -Kame
>
^ permalink raw reply
* Re: [PATCH 4/7] Allow sysfs memory directories to be split
From: Nathan Fontenot @ 2010-07-13 15:51 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20100713152854.ec1f4d6a.kamezawa.hiroyu@jp.fujitsu.com>
On 07/13/2010 01:28 AM, KAMEZAWA Hiroyuki wrote:
> On Mon, 12 Jul 2010 10:45:25 -0500
> Nathan Fontenot <nfont@austin.ibm.com> wrote:
>
>> This patch introduces the new 'split' file in each memory sysfs
>> directory and the associated routines needed to handle splitting
>> a directory.
>>
>> Signed-off-by; Nathan Fontenot <nfont@austin.ibm.com>
>> ---
>
> pleae check diff option...
>
>
>> drivers/base/memory.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 98 insertions(+), 1 deletion(-)
>>
>> Index: linux-2.6/drivers/base/memory.c
>> ===================================================================
>> --- linux-2.6.orig/drivers/base/memory.c 2010-07-09 14:23:20.000000000 -0500
>> +++ linux-2.6/drivers/base/memory.c 2010-07-09 14:38:09.000000000 -0500
>> @@ -32,6 +32,9 @@
>>
>> static int sections_per_block;
>>
>> +static int register_memory(struct memory_block *, struct mem_section *,
>> + int, enum mem_add_context);
>> +
>> static inline int base_memory_block_id(int section_nr)
>> {
>> return (section_nr / sections_per_block) * sections_per_block;
>> @@ -309,11 +312,100 @@
>> return sprintf(buf, "%d\n", mem->phys_device);
>> }
>>
>> +static void update_memory_block_phys_indexes(struct memory_block *mem)
>> +{
>> + struct list_head *pos;
>> + struct memory_block_section *mbs;
>> + unsigned long min_index = 0xffffffff;
>> + unsigned long max_index = 0;
>> +
>> + list_for_each(pos, &mem->sections) {
>> + mbs = list_entry(pos, struct memory_block_section, next);
>> +
>> + if (mbs->phys_index < min_index)
>> + min_index = mbs->phys_index;
>> +
>> + if (mbs->phys_index > max_index)
>> + max_index = mbs->phys_index;
>> + }
>> +
>> + mem->start_phys_index = min_index;
>> + mem->end_phys_index = max_index;
>> +}
>> +
>> +static ssize_t
>> +store_mem_split_block(struct sys_device *dev, struct sysdev_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + struct memory_block *mem, *new_mem_blk;
>> + struct memory_block_section *mbs;
>> + struct list_head *pos, *tmp;
>> + struct mem_section *section;
>> + int min_scn_nr = 0;
>> + int max_scn_nr = 0;
>> + int total_scns = 0;
>> + int new_blk_min, new_blk_total;
>> + int ret = -EINVAL;
>> +
>> + mem = container_of(dev, struct memory_block, sysdev);
>> +
>> + if (list_is_singular(&mem->sections))
>> + return -EINVAL;
>
> What this means ?
list_is_singular() will return true if there is only one item
on the list. In this case we cannot split a memory_block with
only one memory_block_section.
>
>
>> +
>> + mutex_lock(&mem->state_mutex);
>> +
>> + list_for_each(pos, &mem->sections) {
>> + mbs = list_entry(pos, struct memory_block_section, next);
>> +
>> + total_scns++;
>> +
>> + if (min_scn_nr > mbs->phys_index)
>> + min_scn_nr = mbs->phys_index;
>> +
>> + if (max_scn_nr < mbs->phys_index)
>> + max_scn_nr = mbs->phys_index;
>> + }
>> +
>> + new_mem_blk = kzalloc(sizeof(*new_mem_blk), GFP_KERNEL);
>> + if (!new_mem_blk)
>> + return -ENOMEM;
>> +
>> + mutex_init(&new_mem_blk->state_mutex);
>> + INIT_LIST_HEAD(&new_mem_blk->sections);
>> + new_mem_blk->state = mem->state;
>> +
>> + mutex_lock(&new_mem_blk->state_mutex);
>> +
>> + new_blk_total = total_scns / 2;
>> + new_blk_min = max_scn_nr - new_blk_total + 1;
>> +
>> + section = __nr_to_section(new_blk_min);
>> + ret = register_memory(new_mem_blk, section, 0, HOTPLUG);
>> +
> 'nid' is always 0 ?
Ahh.. good catch. it may not be. I'll look into finding the correct nid.
>
> And for what purpose this interface is ? Does this split memory block into 2 pieces
> of the same size ?? sounds __very__ strange interface to me.
Yes, this splits the memory_block into two blocks of the same size. This was
suggested as something we may want to do. From ppc perspective I am not sure we
would use this.
The split functionality is not required. The main goal of the patch set is to
reduce the number of memory sysfs directories created. From a ppc perspective
the split functionality is not really needed.
>
> If this is necessary, I hope move the whole things to configfs rather than
> something tricky.
>
> Bye.
> -Kame
>
^ permalink raw reply
* Re: [PATCH 1/7] Split the memory_block structure
From: Nathan Fontenot @ 2010-07-13 15:59 UTC (permalink / raw)
To: Brian King; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4C3C718C.6080402@linux.vnet.ibm.com>
On 07/13/2010 09:00 AM, Brian King wrote:
> On 07/12/2010 10:42 AM, Nathan Fontenot wrote:
>> @@ -123,13 +130,20 @@
>> static ssize_t show_mem_removable(struct sys_device *dev,
>> struct sysdev_attribute *attr, char *buf)
>> {
>> - unsigned long start_pfn;
>> - int ret;
>> - struct memory_block *mem =
>> - container_of(dev, struct memory_block, sysdev);
>> + struct list_head *pos, *tmp;
>> + struct memory_block *mem;
>> + int ret = 1;
>> +
>> + mem = container_of(dev, struct memory_block, sysdev);
>> + list_for_each_safe(pos, tmp, &mem->sections) {
>> + struct memory_block_section *mbs;
>> + unsigned long start_pfn;
>> +
>> + mbs = list_entry(pos, struct memory_block_section, next);
>> + start_pfn = section_nr_to_pfn(mbs->phys_index);
>> + ret &= is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
>> + }
>
> I don't see you deleting anyting from the list in this loop. Why do you need
> to use list_for_each_safe? That won't protect you if someone else is messing
> with the list.
Yes, Kame pointed this out too. I think I'll need to update the patches to
always take the mutex when walking the list and use list_for_each_entry
>
>>
>> - start_pfn = section_nr_to_pfn(mem->phys_index);
>> - ret = is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
>> return sprintf(buf, "%d\n", ret);
>> }
>>
>
>
>> @@ -238,19 +252,40 @@
>> static int memory_block_change_state(struct memory_block *mem,
>> unsigned long to_state, unsigned long from_state_req)
>> {
>> + struct memory_block_section *mbs;
>> + struct list_head *pos;
>> int ret = 0;
>> +
>> mutex_lock(&mem->state_mutex);
>>
>> - if (mem->state != from_state_req) {
>> - ret = -EINVAL;
>> - goto out;
>> + list_for_each(pos, &mem->sections) {
>> + mbs = list_entry(pos, struct memory_block_section, next);
>> +
>> + if (mbs->state != from_state_req)
>> + continue;
>> +
>> + ret = memory_block_action(mbs, to_state);
>> + if (ret)
>> + break;
>> + }
>
> Would it be better here to loop through all the sections and ensure they
> are in the proper state first before starting to change the state of any
> of them? Then you could easily return -EINVAL if one or more is in
> the incorrect state and wouldn't need to the code below.
The code below is needed in cases where the add/remove of one of the
memory_block_sections fails. The code can then return all of the
memory_block_sections in the memory_block to the original state.
>
>> + if (ret) {
>> + list_for_each(pos, &mem->sections) {
>> + mbs = list_entry(pos, struct memory_block_section,
>> + next);
>> +
>> + if (mbs->state == from_state_req)
>> + continue;
>> +
>> + if (memory_block_action(mbs, to_state))
>> + printk(KERN_ERR "Could not re-enable memory "
>> + "section %lx\n", mbs->phys_index);
>> + }
>> }
>>
>> - ret = memory_block_action(mem, to_state);
>> if (!ret)
>> mem->state = to_state;
>>
>> -out:
>> mutex_unlock(&mem->state_mutex);
>> return ret;
>> }
>
>
>> @@ -498,19 +496,97 @@
>>
>> return mem;
>> }
>> +static int add_mem_block_section(struct memory_block *mem,
>> + int section_nr, unsigned long state)
>> +{
>> + struct memory_block_section *mbs;
>> +
>> + mbs = kzalloc(sizeof(*mbs), GFP_KERNEL);
>> + if (!mbs)
>> + return -ENOMEM;
>> +
>> + mbs->phys_index = section_nr;
>> + mbs->state = state;
>> +
>> + list_add(&mbs->next, &mem->sections);
>
> I don't think there is sufficient protection for this list. Don't we
> need to be holding a lock of some sort when adding/deleting/iterating
> through this list?
You're right. we should be holding the mutex.
I think there are a couple other places that I missed with this. I'll fix
it for a v2 of the patches.
>
>> + return 0;
>> +}
>
^ permalink raw reply
* Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: jjDaNiMoTh @ 2010-07-13 16:02 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev, xorg-driver-ati
In-Reply-To: <1279033177.515.16.camel@thor.local>
2010/7/13 Michel D=C3=A4nzer <michel@daenzer.net>:
[cut]
> Could be a GPU lockup again, possibly due to still using AGP 4x with
> modeset=3D0.
[cut]
> What does the log file contain with modeset=3D1?
We have no message, after the X.org freeze.
messages.log:
[...]
Jul 13 17:11:01 jim kernel: [drm] Num pipes: 1
Jul 13 17:13:39 jim kernel: Using PowerMac machine description
(we have rebooted)
In Xorg.0.log there aren't information after the crash, only a right startu=
p.
Maybe I could try to connect via ssh and see if there are some
informations which aren't written to disk...
At this time, I think it isn't a kernel problem, am I right? Also, we
have the same problem (freeze in glxgears or other program using glx)
both from normal user and from root.
Thank you again
^ permalink raw reply
* Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: Michel Dänzer @ 2010-07-13 16:09 UTC (permalink / raw)
To: jjDaNiMoTh; +Cc: linuxppc-dev, xorg-driver-ati
In-Reply-To: <AANLkTik154EFPIzMZy5v-Mj6mhWt-hCaFYvLPi5oLWFD@mail.gmail.com>
On Die, 2010-07-13 at 18:02 +0200, jjDaNiMoTh wrote:=20
> 2010/7/13 Michel D=C3=A4nzer <michel@daenzer.net>:
> > What does the log file contain with modeset=3D1?
>=20
> We have no message, after the X.org freeze.
>=20
> messages.log:
> [...]
> Jul 13 17:11:01 jim kernel: [drm] Num pipes: 1
> Jul 13 17:13:39 jim kernel: Using PowerMac machine description
>=20
> (we have rebooted)
>=20
> In Xorg.0.log there aren't information after the crash, only a right star=
tup.
Are you looking at the right log file, not the one from the new X server
after the reboot?
Maybe you could post the full dmesg, Xorg.0.log and X server stderr
output (should be captured in the gdm/kdm log file) from trying with
modeset=3D1.
> At this time, I think it isn't a kernel problem, am I right?
With modeset=3D1 it most likely is a kernel (configuration) problem.
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: jjDaNiMoTh @ 2010-07-13 17:05 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev, xorg-driver-ati
In-Reply-To: <1279037396.515.19.camel@thor.local>
2010/7/13 Michel D=C3=A4nzer <michel@daenzer.net>:
[cut]
> Are you looking at the right log file, not the one from the new X server
> after the reboot?
Yes, I looked to .old, when referring to Xorg.0.log.
> Maybe you could post the full dmesg, Xorg.0.log and X server stderr
> output (should be captured in the gdm/kdm log file) from trying with
> modeset=3D1.
>
>> At this time, I think it isn't a kernel problem, am I right?
>
> With modeset=3D1 it most likely is a kernel (configuration) problem.
So, I've now the acceleration. The main problem was radeon.agpmode,
setting it to -1 (and removing all files in xorg.conf.d related to
radeon) fixes all issue (also the freeze on glxgears). Now I have
~1500 FPS, and I'm fine with it (before I got 100 FPS).
I get the acceleration also with a non-KMS capable kernel, so I think
we got the point. I will add the option to modprobe.conf for archPPC.
I tried a program which use a lot opengl, the only thing I see is
ERROR: GL error 1282
ERROR: Ignoring 1 openGL errors
but the topic-error is fixed.
Thank you.
^ permalink raw reply
* Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: Michel Dänzer @ 2010-07-13 17:22 UTC (permalink / raw)
To: jjDaNiMoTh; +Cc: linuxppc-dev, xorg-driver-ati
In-Reply-To: <AANLkTikR0HRoBawbUJyS_cEkhEu9Sj6q8hR2F0v6CLDK@mail.gmail.com>
On Die, 2010-07-13 at 19:05 +0200, jjDaNiMoTh wrote:=20
>=20
> So, I've now the acceleration. The main problem was radeon.agpmode,
> setting it to -1 (and removing all files in xorg.conf.d related to
> radeon) fixes all issue (also the freeze on glxgears). Now I have
> ~1500 FPS, and I'm fine with it (before I got 100 FPS).
>=20
> I get the acceleration also with a non-KMS capable kernel, so I think
> we got the point. I will add the option to modprobe.conf for archPPC.
Note that e.g. on my PowerBook agpmode=3D1 works (mostly) stable, and if
AGP works it performs significantly better than PCI.
> I tried a program which use a lot opengl, the only thing I see is
> ERROR: GL error 1282
> ERROR: Ignoring 1 openGL errors
Something the app does causes Mesa to raise a GL_INVALID_OPERATION
error. This may be a bug in the app or in Mesa.
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: optimized script [Was: ARM defconfig files]
From: Olof Johansson @ 2010-07-13 18:04 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Stephen Rothwell, Daniel Walker, Russell King - ARM Linux,
Nicolas Pitre, Kevin Hilman, linux-arm-msm, linuxppc-dev,
Linux Kernel Mailing List, Eric Miao, linux-omap, Linus Torvalds,
linux-arm-kernel
In-Reply-To: <20100713080705.GA20978@pengutronix.de>
On Tue, Jul 13, 2010 at 10:07:05AM +0200, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-König wrote:
> > Hi
> >
> > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote:
> > > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
> > > <torvalds@linux-foundation.org> wrote:
> > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > > >> I think Uwe could provide his script and add it to the kernel tree.
> > > >> Then all architectures could benefit from it. Having the defconfig
> > > >> files contain only those options which are different from the defaults
> > > >> is certainly more readable, even on x86.
> > > >
> > > > Quite possible. But maintainers would need to be on the lookout of
> > > > people actually using the script, and refusing to apply patches that
> > > > re-introduce the whole big thing.
> > >
> > > I can (partially) speak for powerpc. If ARM uses this approach, then
> > > I think we can do the same. After the defconfigs are trimmed, I
> > > certainly won't pick up any more full defconfigs.
> > I just restarted my script on the powerpc defconfigs basing on rc5, I
> > assume they complete in a few days time.
> So Stephen was faster than me. I don't know yet how he optimised my
> script, meanwhile I put some efforts into it, too by just checking lines
> that match "^(# )?CONFIG_".
>
> Find it attached.
>
> I will start to reduce the remaining configs (i.e. all but arm and
> powerpc).
I added just a simple heuristic: If I could remove a line, I attempted
to remove twice the amount next time around (and fall back to 1 if it failed).
I.e. main loop:
i = 0
lines = 1
while i < len(config):
print 'test for %r + %d' % (config[i], lines)
defconfig = open(defconfig_src, 'w')
defconfig.writelines(config[:i])
defconfig.writelines(config[i + lines:])
defconfig.close()
subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target])
if os.stat('.config').st_size == config_size and list(open('.config')) == origconfig:
del config[i:i+lines]
lines *= 2
else:
if lines > 1:
lines = 1
else:
i += 1
I didn't measure what the actual improvement was, but I saw a fair amount
of 2/4/8-attempts passing, so I let it run. Stephen beat me to posting
the resulting patch though. :P
While this script is great, it is somewhat painful to run given that it
attempts one config per line. Even on a fast machine that tends to take
a while.
-Olof
^ permalink raw reply
* [PATCH] powerpc:prom Export device tree physical address via proc
From: Matthew McClintock @ 2010-07-13 18:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Matthew McClintock, Kumar Gala
To build a proper flat device tree for kexec we need to know which
memreserve region was used for the device tree for the currently
running kernel, so we can remove it and replace it with the new
memreserve for the kexec'ed kernel
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
arch/powerpc/kernel/prom.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index fd9359a..6a8400e 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -32,6 +32,7 @@
#include <linux/debugfs.h>
#include <linux/irq.h>
#include <linux/lmb.h>
+#include <linux/bootmem.h>
#include <asm/prom.h>
#include <asm/rtas.h>
@@ -911,3 +912,46 @@ static int __init export_flat_device_tree(void)
}
__initcall(export_flat_device_tree);
#endif
+
+#ifdef CONFIG_KEXEC
+static phys_addr_t flat_dt_start;
+static phys_addr_t flat_dt_end;
+
+static struct property flat_dt_start_prop = {
+ .name = "linux,devicetree-start",
+ .length = sizeof(phys_addr_t),
+ .value = &flat_dt_start,
+};
+
+static struct property flat_dt_end_prop = {
+ .name = "linux,devicetree-end",
+ .length = sizeof(phys_addr_t),
+ .value = &flat_dt_end,
+};
+
+static int __init export_flat_device_tree_phys_addr(void)
+{
+ struct property *prop;
+ struct device_node *node;
+
+ node = of_find_node_by_path("/chosen");
+ if (!node)
+ return -ENOENT;
+
+ prop = of_find_property(node, "linux,devicetree-start", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+ prop = of_find_property(node, "linux,devietree-end", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ flat_dt_start = (unsigned long)virt_to_phys(initial_boot_params);
+ flat_dt_end = (unsigned long)virt_to_phys(initial_boot_params)
+ + initial_boot_params->totalsize;
+ prom_add_property(node, &flat_dt_start_prop);
+ prom_add_property(node, &flat_dt_end_prop);
+
+ return 0;
+}
+__initcall(export_flat_device_tree_phys_addr);
+#endif
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH] powerpc:prom Export device tree physical address via proc
From: Timur Tabi @ 2010-07-13 18:55 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1279047011-28989-1-git-send-email-msm@freescale.com>
Matthew McClintock wrote:
> + if (prop)
> + prom_remove_property(node, prop);
> + prop = of_find_property(node, "linux,devietree-end", NULL);
Either the indentation is wrong, or you're missing some braces here.
> + if (prop)
> + prom_remove_property(node, prop);
> +
> + flat_dt_start = (unsigned long)virt_to_phys(initial_boot_params);
> + flat_dt_end = (unsigned long)virt_to_phys(initial_boot_params)
> + + initial_boot_params->totalsize;
I think these should be u64, not unsigned long, to ensure support for 64-bit
physical addresses.
^ permalink raw reply
* [PATCH V2] powerpc:prom Export device tree physical address via proc
From: Matthew McClintock @ 2010-07-13 19:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Matthew McClintock, Kumar Gala
To build a proper flat device tree for kexec we need to know which
memreserve region was used for the device tree for the currently
running kernel, so we can remove it and replace it with the new
memreserve for the kexec'ed kernel
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
Removed unneeded cast, and fixed indentation screwup
arch/powerpc/kernel/prom.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index fd9359a..6a8400e 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -32,6 +32,7 @@
#include <linux/debugfs.h>
#include <linux/irq.h>
#include <linux/lmb.h>
+#include <linux/bootmem.h>
#include <asm/prom.h>
#include <asm/rtas.h>
@@ -911,3 +912,46 @@ static int __init export_flat_device_tree(void)
}
__initcall(export_flat_device_tree);
#endif
+
+#ifdef CONFIG_KEXEC
+static phys_addr_t flat_dt_start;
+static phys_addr_t flat_dt_end;
+
+static struct property flat_dt_start_prop = {
+ .name = "linux,devicetree-start",
+ .length = sizeof(phys_addr_t),
+ .value = &flat_dt_start,
+};
+
+static struct property flat_dt_end_prop = {
+ .name = "linux,devicetree-end",
+ .length = sizeof(phys_addr_t),
+ .value = &flat_dt_end,
+};
+
+static int __init export_flat_device_tree_phys_addr(void)
+{
+ struct property *prop;
+ struct device_node *node;
+
+ node = of_find_node_by_path("/chosen");
+ if (!node)
+ return -ENOENT;
+
+ prop = of_find_property(node, "linux,devicetree-start", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+ prop = of_find_property(node, "linux,devietree-end", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ flat_dt_start = (unsigned long)virt_to_phys(initial_boot_params);
+ flat_dt_end = (unsigned long)virt_to_phys(initial_boot_params)
+ + initial_boot_params->totalsize;
+ prom_add_property(node, &flat_dt_start_prop);
+ prom_add_property(node, &flat_dt_end_prop);
+
+ return 0;
+}
+__initcall(export_flat_device_tree_phys_addr);
+#endif
--
1.6.6.1
^ permalink raw reply related
* [PATCH V3] powerpc:prom Export device tree physical address via proc
From: Matthew McClintock @ 2010-07-13 19:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Matthew McClintock, Kumar Gala
To build a proper flat device tree for kexec we need to know which
memreserve region was used for the device tree for the currently
running kernel, so we can remove it and replace it with the new
memreserve for the kexec'ed kernel
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
V3: Remove unneeded cast, and fixed indentation screw up
V2: messed up changes
arch/powerpc/kernel/prom.c | 45 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index fd9359a..79c1f35 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -32,6 +32,7 @@
#include <linux/debugfs.h>
#include <linux/irq.h>
#include <linux/lmb.h>
+#include <linux/bootmem.h>
#include <asm/prom.h>
#include <asm/rtas.h>
@@ -911,3 +912,47 @@ static int __init export_flat_device_tree(void)
}
__initcall(export_flat_device_tree);
#endif
+
+#ifdef CONFIG_KEXEC
+static phys_addr_t flat_dt_start;
+static phys_addr_t flat_dt_end;
+
+static struct property flat_dt_start_prop = {
+ .name = "linux,devicetree-start",
+ .length = sizeof(phys_addr_t),
+ .value = &flat_dt_start,
+};
+
+static struct property flat_dt_end_prop = {
+ .name = "linux,devicetree-end",
+ .length = sizeof(phys_addr_t),
+ .value = &flat_dt_end,
+};
+
+static int __init export_flat_device_tree_phys_addr(void)
+{
+ struct property *prop;
+ struct device_node *node;
+
+ node = of_find_node_by_path("/chosen");
+ if (!node)
+ return -ENOENT;
+
+ prop = of_find_property(node, "linux,devicetree-start", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ prop = of_find_property(node, "linux,devietree-end", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ flat_dt_start = virt_to_phys(initial_boot_params);
+ flat_dt_end = virt_to_phys(initial_boot_params)
+ + initial_boot_params->totalsize;
+ prom_add_property(node, &flat_dt_start_prop);
+ prom_add_property(node, &flat_dt_end_prop);
+
+ return 0;
+}
+__initcall(export_flat_device_tree_phys_addr);
+#endif
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH] kbuild: Enable building defconfigs from Kconfig files
From: Michal Marek @ 2010-07-13 20:22 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, Andrew Morton, Linus, LKML, Catalin Marinas
In-Reply-To: <20100713114322.57c8b166.sfr@canb.auug.org.au>
On 07/13/2010 03:43 AM, Stephen Rothwell wrote:
> After this change, doing a "make xxx_defconfig" will check first for
> a file called arch/<arch>/configs/Kconfig.xxx and use that to generate
> the .config (effectively starting from an allnoconfig). If that file
> doesn't exist, it will use arch/<ARCH>/configs/xxx_defconfig as now.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> scripts/kconfig/Makefile | 14 +++++++++++++-
> 1 files changed, 13 insertions(+), 1 deletions(-)
>
> Hi Linus,
>
> Is this more the direction you want to take?
>
> There are still 2 main problems with is approach:
>
> - there are some config options that are globally and
> unconditionally enabled that some platforms may not want. The only way
> currently to turn them off is to reproduce the config entry with the
> different default. I am not sure if we need a wa to turn them off or to
> just change them to being neede to be selected by those that do want them.
> - we have no way to select options that are neither bool or
> tristate to suitable values. Again the only way to do that currently is
> to reproduce the config entry with a different default value.
Hi Stephen,
how are these Kconfig.xxx files going look like? A list of 'select FOO'
and 'include "Kconfig.other"' statements?
What about adding support for an include statement to the .config file
format and using that in the defconfigs instead? The VARIABLE=VALUE
grammar seems much more suitable for this than the kconfig language.
Michal
^ permalink raw reply
* Re: [PATCH 1/9 v1.01] Add Synopsys DesignWare HS USB OTG Controller driver.
From: fushen chen @ 2010-07-13 22:13 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, chuck, linux-usb, Mark Miesfeld, gregkh
In-Reply-To: <582531.52335.qm@web180310.mail.gq1.yahoo.com>
On Mon, 2010-07-12 at 16:55 -0700, David Brownell wrote:
> Please remove all the changes not related to
> this Synopsis IP ...
Could you clarify what is not Synopsis IP related in the patch?
> and make the OTG functionality
> key on the generic OTG symbol, not a DW-specific one.
>
>
Use "drivers/usb/otg/otg.c and include/linux/usb/otg.h"?
Thanks,
Fushen
^ permalink raw reply
* Re: [PATCH 1/9 v1.01] Add Synopsys DesignWare HS USB OTG Controller driver.
From: Chuck Meade @ 2010-07-13 22:16 UTC (permalink / raw)
To: Fushen Chen; +Cc: linuxppc-dev, chuck, linux-usb, Mark Miesfeld, gregkh
In-Reply-To: <12789766042434-git-send-email-fchen@apm.com>
On 07/12/2010 07:16 PM, Fushen Chen wrote:
> The DWC OTG driver module provides the initialization and cleanup
> entry points for the DWC OTG USB driver.
>
> Signed-off-by: Fushen Chen <fchen@apm.com>
> Signed-off-by: Mark Miesfeld <mmiesfeld@apm.com>
> ---
This reply is to the patch series, not just this 1/9 patch section.
Fushen, why did you pick and choose which fixes to incorporate from the Denx
tree's version of the dwc_otg driver?
I'm not taking the time here to go through this multipart patch and check that
you incorporated every fix, but I *did* randomly pick one fix that I made to that
driver, to see if you incorporated it, and it appears you did not.
I would have expected that you would have incorporated the fixes that were made
to this driver in the Denx tree.
The one that I checked is in the data toggle error interrupt handling, in
handle_hc_chhltd_intr_dma() (see your 5/9 email in this patch series). It looks
like you left out the fix I made to this logic that averts an interrupt storm.
I assume that since I checked one particular fix, and it was missing from your
patch series, that there are likely more fixes you omitted. Can you explain why
you would leave this out, after Stefan asked you to incorporate the code changes
made in the Denx tree's version of the driver?
Chuck
^ permalink raw reply
* Re: [PATCH 1/9 v1.01] Add Synopsys DesignWare HS USB OTG Controller driver.
From: David Brownell @ 2010-07-13 22:50 UTC (permalink / raw)
To: fushen chen; +Cc: linuxppc-dev, chuck, linux-usb, Mark Miesfeld, gregkh
In-Reply-To: <1279059214.29212.13.camel@localhost.localdomain>
> > and make the OTG functionality
> > key on the generic OTG symbol, not a DW-specific one.
> >
> >
> Use "drivers/usb/otg/otg.c and include/linux/usb/otg.h"?
Maybe; CONFIG_USB_OTG specifically, though
(or whatever that generic symbol is) ...
^ permalink raw reply
* [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Grant Likely @ 2010-07-13 23:04 UTC (permalink / raw)
To: linuxppc-dev, Nicolas Pitre, Benjamin Herrenschmidt, linux-kbuild,
linux-kernel, linux-arm-kernel, Linus Torvalds, Russell King
Cc: Tony Lindgren, Daniel Walker, Uwe Kleine-König
This is a proof of concept at the moment, but if the corner cases
can be sorted out, then this might be the best way to replace
the defconfig functionality. This patch implements Linus' idea
for using Kconfig fragments to replicate the *_defconfig functionality
Essentially, this patch adds a new <board>_defconfig target that is
processed if a <board>.Kconfig file is present in the $(ARCH)/configs
directory instead of the current <board>_defconfig file. The target
works by passing the $(ARCH)/configs/<board>.Kconfig to Kconfig
instead of the architecture's default $(ARCH)/Kconfig file.
<board>.Kconfig defines new board specific config items (prefixed with
"generateconfig_" which default to 'y' or 'm' and select the options
that the platform cares about. It also then either the architecture
default Kconfig, or another Kconfig fragment that includes the default
one (therefore the fragments can be 'stacked' to include, say, default
options for the architecture, or particular chipset).
This patch includes sample Kconfig fragments for the PowerPC 83xx and
5200 platforms to demonstrate the concept, but it should work in exactly
the same way for ARM or any other architecture. With the sample,
'mpc5200_defconfig', 'mpc83xx_defconfig' and even 'ppc32_defconfig' are
all valid targets (although the ppc32_defconfig won't actually include
any particular board support).
An interesting side effect of this approach is that it can be used to
'overlay' the configuration for a board over top of the existing config.
I went ahead and added the %_oldconfig option to do this which could
be useful for building a kernel that supports multiple boards, or for
adding in a set of debug options.
Another advantage of this approach is that it doesn't immediately
eliminate the old defconfig files so that platforms can be migrated to
this new method one at a time.
Current problems:
- I haven't figured out a way for the fragment to force an option to
be "n", or to set a value, for example "CONFIG_LOG_BUF_SHIFT=16".
This may require changing the syntax.
- It still doesn't resolve dependencies. A solver would help with this.
For the time being I work around the problem by running the generated
config through 'oldconfig' and looking for differences. If the files
differ (ignoring comments and generateconfig_* options) after oldconfig,
then the <board>_defconfig target returns a failure. (but leaves the
new .config intact so the user can resolve it with menuconfig). This
way at least the user is told when a Kconfig fragment is invalid.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/configs/mpc5200.Kconfig | 24 +++++++++++++++++++++
arch/powerpc/configs/mpc83xx.Kconfig | 35 +++++++++++++++++++++++++++++++
arch/powerpc/configs/ppc32.Kconfig | 39 ++++++++++++++++++++++++++++++++++
scripts/kconfig/Makefile | 18 +++++++++++++++-
4 files changed, 115 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/configs/mpc5200.Kconfig
create mode 100644 arch/powerpc/configs/mpc83xx.Kconfig
create mode 100644 arch/powerpc/configs/ppc32.Kconfig
diff --git a/arch/powerpc/configs/mpc5200.Kconfig b/arch/powerpc/configs/mpc5200.Kconfig
new file mode 100644
index 0000000..1281dd1
--- /dev/null
+++ b/arch/powerpc/configs/mpc5200.Kconfig
@@ -0,0 +1,24 @@
+config generateconfig_MPC5200_YES
+ def_bool y
+ select PPC_MPC52xx
+ select PPC_MPC5200_SIMPLE
+ select PPC_EFIKA
+ select PPC_LITE5200
+ select PPC_MEDIA5200
+ select PPC_MPC5200_BUGFIX
+ select PPC_MPC5200_GPIO
+ select PPC_MPC5200_LPBFIFO
+ select PPC_BESTCOMM
+ select SIMPLE_GPIO
+ select SERIAL_MPC52xx
+ select SERIAL_MPC52xx_CONSOLE
+ select MTD
+ select PATA_MPC52xx
+ select SPI_MPC52xx
+ select SPI_MPC52xx_PSC
+ select I2C_MPC
+ select FEC_MPC52xx
+ select LXT_PHY
+ select WATCHDOG
+
+source arch/powerpc/configs/ppc32.Kconfig
diff --git a/arch/powerpc/configs/mpc83xx.Kconfig b/arch/powerpc/configs/mpc83xx.Kconfig
new file mode 100644
index 0000000..818fdec
--- /dev/null
+++ b/arch/powerpc/configs/mpc83xx.Kconfig
@@ -0,0 +1,35 @@
+config generateconfig_MPC83xx_YES
+ def_bool y
+ select PPC_83xx
+ select EMBEDDED
+ select MPC831x_RDB
+ select MPC832x_MDS
+ select MPC832x_RDB
+ select MPC834x_MDS
+ select MPC834x_ITX
+ select MPC836x_MDS
+ select MPC836x_RDK
+ select MPC837x_MDS
+ select MPC837x_RDB
+ select SBC834x
+ select ASP834x
+ select QUICC_ENGINE
+ select OE_GPIO
+ select MATH_EMULATION
+ select SATA_FSL
+ select SATA_SIL
+ select MARVELL_PHY
+ select DAVICOM_PHY
+ select VITESSE_PHY
+ select ICPLUS_PHY
+ select FIXED_PHY
+ select FSL_PQ_MDIO
+ select GIANFAR
+ select UCC_GETH
+ select SERIAL_8250
+ select SERIAL_8250_CONSOLE
+ select I2C_MPC
+ select GPIOLIB
+ select WATCHDOG
+
+source arch/powerpc/configs/ppc32.Kconfig
diff --git a/arch/powerpc/configs/ppc32.Kconfig b/arch/powerpc/configs/ppc32.Kconfig
new file mode 100644
index 0000000..66e39f0
--- /dev/null
+++ b/arch/powerpc/configs/ppc32.Kconfig
@@ -0,0 +1,39 @@
+config generateconfig_PPC32_YES
+ def_bool y
+ select EXPERIMENTAL
+ select DEVTMPFS
+ select PPC32
+ select SYSVIPC
+ select BLK_DEV_INITRD
+ select NO_HZ
+ select HIGH_RES_TIMERS
+ select GPIO
+ select SPI
+ select SPI_SPIDEV
+ select I2C
+ select I2C_CHARDEV
+ select USB
+ select NET
+ select SCSI
+ select BLK_DEV_SD
+ select ATA
+ select PACKET
+ select UNIX
+ select INET
+ select IP_MULTICAST
+ select IP_PNP
+ select IP_PNP_DHCP
+ select NETDEVICES
+ select NET_ETHERNET
+ select PROC_DEVICETREE
+ select INOTIFY
+ select TMPFS
+ select NFS_FS
+ select ROOT_NFS
+ select PRINTK_TIME
+
+config generateconfig_PPC32_MODULE
+ def_tristate m
+
+source arch/powerpc/Kconfig
+
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 7ea649d..4e9afd9 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -117,7 +117,23 @@ else
$(Q)$< -D arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG) $(Kconfig)
endif
-%_defconfig: $(obj)/conf
+# New-style defconfig using Kconfig fragments
+%_defconfig: $(obj)/conf arch/$(SRCARCH)/configs/%.Kconfig
+ $(Q)$< -D /dev/null arch/$(SRCARCH)/configs/$*.Kconfig
+ $(Q)sed '/^#/d;/^CONFIG_generateconfig_/d' $(objtree)/.config > $(objtree)/.config-diff1
+ $(Q)$< -o $(Kconfig) > /dev/null # oldconfig test to make sure it doesn't change
+ $(Q)sed '/^#/d' $(objtree)/.config > $(objtree)/.config-diff2
+ $(Q)diff -u $(objtree)/.config-diff1 $(objtree)/.config-diff2
+
+# This is kind of useful. The new-style defconfig using Kconfig fragments
+# can also be used to successively pull in the options a defconfig cares
+# about overtop of the current config.
+%_oldconfig: $(obj)/conf arch/$(SRCARCH)/configs/%.Kconfig
+ $(Q)$< -o arch/$(SRCARCH)/configs/$*.Kconfig
+ $(Q)$< -o $(Kconfig) > /dev/null # oldconfig to clear out the temporary items
+
+# Old-style defconfig using full (or trimmed) .config files.
+%_defconfig: $(obj)/conf arch/$(SRCARCH)/configs/%_defconfig
$(Q)$< -D arch/$(SRCARCH)/configs/$@ $(Kconfig)
# Help text used by make help
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox