* Re: [rtc-linux] Re: [PATCH 7/7] powerpc/ps3: Add rtc-ps3
From: Alessandro Zummo @ 2009-03-10 9:39 UTC (permalink / raw)
To: rtc-linux
Cc: linux-m68k, linux-parisc, linux-kernel, Kyle McMartin,
linuxppc-dev, Paul Mundt, Geert.Uytterhoeven, Dann Frazier
In-Reply-To: <alpine.LRH.2.00.0903101015470.24318@vixen.sonytel.be>
On Tue, 10 Mar 2009 10:21:14 +0100 (CET)
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> Alessandro prefers not to have generic RTC drivers on top of some other
> abstraction, but wants platform/chip-specific drivers under drivers/rtc/
> instead. The goal is to convert all RTC drivers buried in platform code
> to separate RTC drivers.
>
> (Alessandro, please correct me if I'm wrong)
yes, that's my dream :)
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
^ permalink raw reply
* Re: [PATCH 7/7] powerpc/ps3: Add rtc-ps3
From: Geert Uytterhoeven @ 2009-03-10 9:21 UTC (permalink / raw)
To: Geoff Levand
Cc: linux-m68k, Alessandro Zummo, rtc-linux, linux-parisc,
linux-kernel, Kyle McMartin, linuxppc-dev, Paul Mundt,
Dann Frazier
In-Reply-To: <49B5618E.9050501@am.sony.com>
On Mon, 9 Mar 2009, Geoff Levand wrote:
> On 03/09/2009 06:26 AM, Geert Uytterhoeven wrote:
> > Create a real RTC driver for PS3, and unhook the deprecated
> > ppc_md.[gs]et_rtc_time.
>
> > 8 files changed, 132 insertions(+), 18 deletions(-)
>
> Sorry, I hadn't been following the discussion closely, but
> could you explain why we are going from a generic framework
> where we hook in our platform specific part to a totally
> independent driver that has such an increase in code size.
Alessandro prefers not to have generic RTC drivers on top of some other
abstraction, but wants platform/chip-specific drivers under drivers/rtc/
instead. The goal is to convert all RTC drivers buried in platform code
to separate RTC drivers.
(Alessandro, please correct me if I'm wrong)
> Why couldn't you fix the generic part so that udev could
> load it automatically?
BTW, I also fixed the generic part, which is now called rtc-generic and
autoloaded (patch 4).
> I much prefer to have this code in the platform support
> code as it was. It is much more effort (a pain) to maintain
> a separate driver were I have to cater to a subsystem's
> maintainer, and with this rtc it seems everyone who was
> using the generic PPC driver will need to do the same.
They can keep on using rtc-generic for now (patch 6).
If you do not want rtc-ps3, you can nak it, and keep on using rtc-generic :-)
But please consider before doing that...
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: 2.6.29-rc7-git2 : crash in kmem_list3_init()
From: Sachin P. Sant @ 2009-03-10 6:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mel Gorman, cl
In-Reply-To: <49B5448B.6030205@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]
Sachin P. Sant wrote:
> sure if this is a new problem or a recurring one. Will try booting
> some older kernels on this box and will report the results.
I tried few older kernels till 2.6.28 and all of them had the
same problem.
I also tried using SLUB instead of SLAB. That also failed to
boot with following trace.
Unable to handle kernel paging request for data at address 0xc000000070001030
Faulting instruction address: 0xc00000000011c7e0
cpu 0x0: Vector: 300 (Data Access) at [c000000000ac39a0]
pc: c00000000011c7e0: .new_slab+0x2b8/0x33c
lr: c00000000011c7dc: .new_slab+0x2b4/0x33c
sp: c000000000ac3c20
msr: 8000000000009032
dar: c000000070001030
dsisr: 42000000
current = 0xc0000000009ea4b0
paca = 0xc000000000b53480
pid = 0, comm = swapper
enter ? for help
[c000000000ac3cc0] c00000000011dc28 .kmem_cache_open+0x1a4/0x448
[c000000000ac3d90] c00000000011f5dc .create_kmalloc_cache+0x78/0x100
[c000000000ac3e40] c000000000948bec .kmem_cache_init+0x8c/0x1c8
[c000000000ac3ee0] c000000000920a5c .start_kernel+0x360/0x480
[c000000000ac3f90] c0000000000083d8 .start_here_common+0x1c/0x44
Complete dmesg log attached. Is there anything else i can try ?
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
[-- Attachment #2: rc7-git2-slub-dmesg-log --]
[-- Type: text/plain, Size: 21429 bytes --]
boot:
Please wait, loading kernel...
Allocated 01500000 bytes for kernel @ 01c00000
Elf64 kernel loaded...
Loading ramdisk...
ramdisk loaded 004f0000 @ 05700000
OF stdout device is: /vdevice/vty@30000000
Hypertas detected, assuming LPAR !
command line: root=/dev/sda5 quiet sysrq=1 loglevel=8 mminit_loglevel=4
memory layout at init:
alloc_bottom : 0000000005bf0000
alloc_top : 0000000008000000
alloc_top_hi : 0000000072000000
rmo_top : 0000000008000000
ram_top : 0000000072000000
Looking for displays
instantiating rtas at 0x00000000077c0000 ... done
boot cpu hw idx 0000000000000000
starting cpu hw idx 0000000000000002... done
starting cpu hw idx 0000000000000004... done
starting cpu hw idx 0000000000000006... done
starting cpu hw idx 0000000000000008... done
starting cpu hw idx 000000000000000a... done
starting cpu hw idx 000000000000000c... done
starting cpu hw idx 000000000000000e... done
starting cpu hw idx 0000000000000010... done
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000006000000 -> 0x00000000060011ed
Device tree struct 0x0000000006010000 -> 0x0000000006020000
Calling quiesce ...
returning from prom_init
Using pSeries machine description
Page orders: linear mapping = 12, virtual = 12, io = 12, vmemmap = 24
Found initrd at 0xc000000005700000:0xc000000005bf0000
console [udbg0] enabled
Partition configured for 18 cpus.
CPU maps initialized for 2 threads per core
(thread shift is 1)
Starting Linux PPC64 #5 SMP Tue Mar 10 10:35:45 IST 2009
-----------------------------------------------------
ppc64_pft_size = 0x19
physicalMemorySize = 0x72000000
htab_hash_mask = 0x3ffff
-----------------------------------------------------
Linux version 2.6.29-rc7-git2 (root@linux-4hy5) (gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (SUSE Linux) ) #5 SMP Tue Mar 10 10:35:45 IST 2009
[boot]0012 Setup Arch
mminit::memory_register Entering add_active_range(1, 0x0, 0x800) 0 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x800, 0xa00) 1 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0xa00, 0xc00) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0xc00, 0xe00) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0xe00, 0x1000) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x1000, 0x1200) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x1200, 0x1400) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x1400, 0x1600) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x1600, 0x1800) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x1800, 0x1a00) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x1a00, 0x1c00) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x1c00, 0x1e00) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x1e00, 0x2000) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x2000, 0x2200) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x2200, 0x2400) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x2400, 0x2600) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x2600, 0x2800) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x2800, 0x2a00) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x2a00, 0x2c00) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x2c00, 0x2e00) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x2e00, 0x3000) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x3000, 0x3200) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x3200, 0x3400) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x3400, 0x3600) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x3600, 0x3800) 2 entries of 256 used
mminit::memory_register Entering add_active_range(0, 0x3800, 0x3a00) 2 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x3a00, 0x3c00) 2 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x3c00, 0x3e00) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x3e00, 0x4000) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x4000, 0x4200) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x4200, 0x4400) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x4400, 0x4600) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x4600, 0x4800) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x4800, 0x4a00) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x4a00, 0x4c00) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x4c00, 0x4e00) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x4e00, 0x5000) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x5000, 0x5200) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x5200, 0x5400) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x5400, 0x5600) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x5600, 0x5800) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x5800, 0x5a00) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x5a00, 0x5c00) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x5c00, 0x5e00) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x5e00, 0x6000) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x6000, 0x6200) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x6200, 0x6400) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x6400, 0x6600) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x6600, 0x6800) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x6800, 0x6a00) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x6a00, 0x6c00) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x6c00, 0x6e00) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x6e00, 0x7000) 3 entries of 256 used
mminit::memory_register Entering add_active_range(1, 0x7000, 0x7200) 3 entries of 256 used
Node 0 Memory: 0x8000000-0x3a000000
Node 1 Memory: 0x0-0x8000000 0x3a000000-0x72000000
PCI host bridge /pci@800000020000003 ranges:
IO 0x000003fe00700000..0x000003fe007fffff -> 0x0000000000000000
MEM 0x00000401c0000000..0x00000401ffffffff -> 0x00000000c0000000
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 7168 bytes
Using shared processor idle loop
Zone PFN ranges:
DMA 0x00000000 -> 0x00007200
Normal 0x00007200 -> 0x00007200
Movable zone start PFN for each node
early_node_map[3] active PFN ranges
1: 0x00000000 -> 0x00000800
0: 0x00000800 -> 0x00003a00
1: 0x00003a00 -> 0x00007200
mminit::pageflags_layout_widths Section 0 Node 4 Zone 2 Flags 22
mminit::pageflags_layout_shifts Section 20 Node 4 Zone 2
mminit::pageflags_layout_offsets Section 0 Node 60 Zone 58
mminit::pageflags_layout_zoneid Zone ID: 58 -> 64
mminit::pageflags_layout_usage location: 64 -> 58 unused 58 -> 22 flags 22 -> 0
On node 0 totalpages: 12800
DMA zone: 18 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 12782 pages, LIFO batch:1
mminit::memmap_init Initialising map node 0 zone 0 pfns 2048 -> 14848
On node 1 totalpages: 16384
DMA zone: 40 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 16344 pages, LIFO batch:1
mminit::memmap_init Initialising map node 1 zone 0 pfns 0 -> 29184
[boot]0015 Setup Done
mminit::zonelist general 0:DMA = 0:DMA 1:DMA
mminit::zonelist thisnode 0:DMA = 0:DMA
mminit::zonelist general 1:DMA = 1:DMA 0:DMA
mminit::zonelist thisnode 1:DMA = 1:DMA
Built 2 zonelists in Node order, mobility grouping on. Total pages: 29126
Policy zone: DMA
Kernel command line: root=/dev/sda5 quiet sysrq=1 loglevel=8 mminit_loglevel=4
[boot]0020 XICS Init
[boot]0021 XICS Done
pic: no ISA interrupt controller
PID hash table entries: 4096 (order: 12, 32768 bytes)
time_init: decrementer frequency = 207.050000 MHz
time_init: processor frequency = 1656.400000 MHz
clocksource: timebase mult[1351aa5] shift[22] registered
clockevent: decrementer mult[3501] shift[16] cpu[0]
Console: colour dummy device 80x25
console handover: boot [udbg0] -> real [hvc0]
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 48
... MAX_LOCKDEP_KEYS: 8191
... CLASSHASH_SIZE: 4096
... MAX_LOCKDEP_ENTRIES: 8192
... MAX_LOCKDEP_CHAINS: 16384
... CHAINHASH_SIZE: 8192
memory used by lock dependency info: 3839 kB
per task-struct memory footprint: 1920 bytes
Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes)
freeing bootmem node 0
freeing bootmem node 1
Memory: 1812032k/1867776k available (9792k kernel code, 57920k reserved, 1216k data, 8025k bss, 448k init)
Unable to handle kernel paging request for data at address 0xc000000070001030
Faulting instruction address: 0xc00000000011c7e0
cpu 0x0: Vector: 300 (Data Access) at [c000000000ac39a0]
pc: c00000000011c7e0: .new_slab+0x2b8/0x33c
lr: c00000000011c7dc: .new_slab+0x2b4/0x33c
sp: c000000000ac3c20
msr: 8000000000009032
dar: c000000070001030
dsisr: 42000000
current = 0xc0000000009ea4b0
paca = 0xc000000000b53480
pid = 0, comm = swapper
enter ? for help
[c000000000ac3cc0] c00000000011dc28 .kmem_cache_open+0x1a4/0x448
[c000000000ac3d90] c00000000011f5dc .create_kmalloc_cache+0x78/0x100
[c000000000ac3e40] c000000000948bec .kmem_cache_init+0x8c/0x1c8
[c000000000ac3ee0] c000000000920a5c .start_kernel+0x360/0x480
[c000000000ac3f90] c0000000000083d8 .start_here_common+0x1c/0x44
0:mon> ls .new_slab
.new_slab: c00000000011c528
0:mon> di c00000000011c528
c00000000011c528 7c0802a6 mflr r0
c00000000011c52c fb41ffd0 std r26,-48(r1)
c00000000011c530 fba1ffe8 std r29,-24(r1)
c00000000011c534 fbc1fff0 std r30,-16(r1)
c00000000011c538 fb61ffd8 std r27,-40(r1)
c00000000011c53c fb81ffe0 std r28,-32(r1)
c00000000011c540 fbe1fff8 std r31,-8(r1)
c00000000011c544 f8010010 std r0,16(r1)
c00000000011c548 ebc2b2a8 ld r30,-19800(r2)
c00000000011c54c 38000000 li r0,0
c00000000011c550 f821ff61 stdu r1,-160(r1)
c00000000011c554 7c7a1b78 mr r26,r3
c00000000011c558 6000ffe0 ori r0,r0,65504
c00000000011c55c 7cbd2b78 mr r29,r5
c00000000011c560 780083e4 rldicr r0,r0,16,47
c00000000011c564 60000006 ori r0,r0,6
0:mon>
c00000000011c568 7c800038 and r0,r4,r0
c00000000011c56c 0b000000 tdnei r0,0
c00000000011c570 3c000007 lis r0,7
c00000000011c574 812300a0 lwz r9,160(r3)
c00000000011c578 2f85ffff cmpwi cr7,r5,-1
c00000000011c57c eb630018 ld r27,24(r3)
c00000000011c580 60001ef0 ori r0,r0,7920
c00000000011c584 7c002038 and r0,r0,r4
c00000000011c588 7b648022 rldicl r4,r27,48,32
c00000000011c58c 7c004b78 or r0,r0,r9
c00000000011c590 781c0020 clrldi r28,r0,32
c00000000011c594 63801200 ori r0,r28,4608
c00000000011c598 78030020 clrldi r3,r0,32
c00000000011c59c 409e0018 bne cr7,c00000000011c5b4 # .new_slab+0x8c/0x33c
c00000000011c5a0 2b840008 cmplwi cr7,r4,8
c00000000011c5a4 419d0074 bgt cr7,c00000000011c618 # .new_slab+0xf0/0x33c
0:mon>
c00000000011c5a8 4bffa561 bl c000000000116b08 # .alloc_pages_current+0x0/0x124
c00000000011c5ac 60000000 nop
c00000000011c5b0 4800005c b c00000000011c60c # .new_slab+0xe4/0x33c
c00000000011c5b4 2b840008 cmplwi cr7,r4,8
c00000000011c5b8 419d0060 bgt cr7,c00000000011c618 # .new_slab+0xf0/0x33c
c00000000011c5bc 2f850000 cmpwi cr7,r5,0
c00000000011c5c0 7ca92b78 mr r9,r5
c00000000011c5c4 409c0014 bge cr7,c00000000011c5d8 # .new_slab+0xb0/0x33c
c00000000011c5c8 a00d000a lhz r0,10(r13)
c00000000011c5cc e93e82a8 ld r9,-32088(r30)
c00000000011c5d0 78001764 rldicr r0,r0,2,61
c00000000011c5d4 7d2902aa lwax r9,r9,r0
c00000000011c5d8 786a77e2 rldicl r10,r3,46,63
c00000000011c5dc e97e8178 ld r11,-32392(r30)
c00000000011c5e0 79291f24 rldicr r9,r9,3,60
c00000000011c5e4 38c00000 li r6,0
0:mon>
c00000000011c5e8 300affff addic r0,r10,-1
c00000000011c5ec 7c000110 subfe r0,r0,r0
c00000000011c5f0 780acf26 rldicr r10,r0,57,60
c00000000011c5f4 7cab482a ldx r5,r11,r9
c00000000011c5f8 794a3f24 rldicr r10,r10,7,60
c00000000011c5fc 394a2308 addi r10,r10,8968
c00000000011c600 7ca55214 add r5,r5,r10
c00000000011c604 4bfce7e1 bl c0000000000eade4 # .__alloc_pages_internal+0x0/0x528
c00000000011c608 60000000 nop
c00000000011c60c 2fa30000 cmpdi cr7,r3,0
c00000000011c610 7c7f1b78 mr r31,r3
c00000000011c614 40fe0090 bne+ cr7,c00000000011c6a4 # .new_slab+0x17c/0x33c
c00000000011c618 2f9dffff cmpwi cr7,r29,-1
c00000000011c61c eb7a0098 ld r27,152(r26)
c00000000011c620 7b648022 rldicl r4,r27,48,32
c00000000011c624 409e001c bne cr7,c00000000011c640 # .new_slab+0x118/0x33c
0:mon>
c00000000011c628 2b840008 cmplwi cr7,r4,8
c00000000011c62c 419d0208 bgt cr7,c00000000011c834 # .new_slab+0x30c/0x33c
c00000000011c630 7f83e378 mr r3,r28
c00000000011c634 4bffa4d5 bl c000000000116b08 # .alloc_pages_current+0x0/0x124
c00000000011c638 60000000 nop
c00000000011c63c 4800005c b c00000000011c698 # .new_slab+0x170/0x33c
c00000000011c640 2b840008 cmplwi cr7,r4,8
c00000000011c644 419d01f0 bgt cr7,c00000000011c834 # .new_slab+0x30c/0x33c
c00000000011c648 2f9d0000 cmpwi cr7,r29,0
c00000000011c64c 409c0014 bge cr7,c00000000011c660 # .new_slab+0x138/0x33c
c00000000011c650 a00d000a lhz r0,10(r13)
c00000000011c654 e93e82a8 ld r9,-32088(r30)
c00000000011c658 78001764 rldicr r0,r0,2,61
c00000000011c65c 7fa902aa lwax r29,r9,r0
c00000000011c660 7b8a77e2 rldicl r10,r28,46,63
c00000000011c664 e97e8178 ld r11,-32392(r30)
0:mon>
c00000000011c668 7ba91f24 rldicr r9,r29,3,60
c00000000011c66c 7f83e378 mr r3,r28
c00000000011c670 38c00000 li r6,0
c00000000011c674 300affff addic r0,r10,-1
c00000000011c678 7c000110 subfe r0,r0,r0
c00000000011c67c 780acf26 rldicr r10,r0,57,60
c00000000011c680 7cab482a ldx r5,r11,r9
c00000000011c684 794a3f24 rldicr r10,r10,7,60
c00000000011c688 394a2308 addi r10,r10,8968
c00000000011c68c 7ca55214 add r5,r5,r10
c00000000011c690 4bfce755 bl c0000000000eade4 # .__alloc_pages_internal+0x0/0x528
c00000000011c694 60000000 nop
c00000000011c698 2fa30000 cmpdi cr7,r3,0
c00000000011c69c 7c7f1b78 mr r31,r3
c00000000011c6a0 419e0198 beq cr7,c00000000011c838 # .new_slab+0x310/0x33c
c00000000011c6a4 b37f000e sth r27,14(r31)
0:mon>
c00000000011c6a8 e87f0000 ld r3,0(r31)
c00000000011c6ac 7b698402 rldicl r9,r27,48,16
c00000000011c6b0 38a00001 li r5,1
c00000000011c6b4 e97e8178 ld r11,-32392(r30)
c00000000011c6b8 7ca54830 slw r5,r5,r9
c00000000011c6bc 78602720 rldicl r0,r3,4,60
c00000000011c6c0 786337a0 rldicl r3,r3,6,62
c00000000011c6c4 7ca507b4 extsw r5,r5
c00000000011c6c8 78001f24 rldicr r0,r0,3,60
c00000000011c6cc 1c630a80 mulli r3,r3,2688
c00000000011c6d0 e89a0000 ld r4,0(r26)
c00000000011c6d4 7c0b002a ldx r0,r11,r0
c00000000011c6d8 78847fe2 rldicl r4,r4,47,63
c00000000011c6dc 7c601a14 add r3,r0,r3
c00000000011c6e0 2084000d subfic r4,r4,13
c00000000011c6e4 4bfdd679 bl c0000000000f9d5c # .mod_zone_page_state+0x0/0x128
0:mon>
c00000000011c6e8 60000000 nop
c00000000011c6ec e93f0000 ld r9,0(r31)
c00000000011c6f0 a01f000e lhz r0,14(r31)
c00000000011c6f4 79292720 rldicl r9,r9,4,60
c00000000011c6f8 39290022 addi r9,r9,34
c00000000011c6fc 79291f24 rldicr r9,r9,3,60
c00000000011c700 7d3a4a14 add r9,r26,r9
c00000000011c704 e9690008 ld r11,8(r9)
c00000000011c708 2fab0000 cmpdi cr7,r11,0
c00000000011c70c 419e0030 beq cr7,c00000000011c73c # .new_slab+0x214/0x33c
c00000000011c710 392b0050 addi r9,r11,80
c00000000011c714 7d4048a8 ldarx r10,0,r9
c00000000011c718 314a0001 addic r10,r10,1
c00000000011c71c 7d4049ad stdcx. r10,0,r9
c00000000011c720 40c2fff4 bne- c00000000011c714 # .new_slab+0x1ec/0x33c
c00000000011c724 392b0058 addi r9,r11,88
0:mon>
c00000000011c728 7c0007b4 extsw r0,r0
c00000000011c72c 7d6048a8 ldarx r11,0,r9
c00000000011c730 7d605a14 add r11,r0,r11
c00000000011c734 7d6049ad stdcx. r11,0,r9
c00000000011c738 40c2fff4 bne- c00000000011c72c # .new_slab+0x204/0x33c
c00000000011c73c e81f0000 ld r0,0(r31)
c00000000011c740 fb5f0010 std r26,16(r31)
c00000000011c744 3d200021 lis r9,33
c00000000011c748 61290d00 ori r9,r9,3328
c00000000011c74c 60000080 ori r0,r0,128
c00000000011c750 f81f0000 std r0,0(r31)
c00000000011c754 e81a0000 ld r0,0(r26)
c00000000011c758 7d280039 and. r8,r9,r0
c00000000011c75c 41820010 beq c00000000011c76c # .new_slab+0x244/0x33c
c00000000011c760 e81f0000 ld r0,0(r31)
c00000000011c764 60000002 ori r0,r0,2
0:mon>
c00000000011c768 f81f0000 std r0,0(r31)
c00000000011c76c 3c001000 lis r0,4096
c00000000011c770 e95e8018 ld r10,-32744(r30)
c00000000011c774 e97a0000 ld r11,0(r26)
c00000000011c778 3920ffff li r9,-1
c00000000011c77c 780007c6 rldicr r0,r0,32,31
c00000000011c780 79290044 rldicr r9,r9,0,1
c00000000011c784 7c1f0214 add r0,r31,r0
c00000000011c788 7968afe3 rldicl. r8,r11,53,63
c00000000011c78c 7c001e74 sradi r0,r0,3
c00000000011c790 7c0051d2 mulld r0,r0,r10
c00000000011c794 780083e4 rldicr r0,r0,16,47
c00000000011c798 7f604a14 add r27,r0,r9
c00000000011c79c 41e20030 beq+ c00000000011c7cc # .new_slab+0x2a4/0x33c
c00000000011c7a0 e81f0000 ld r0,0(r31)
c00000000011c7a4 39200000 li r9,0
0:mon>
c00000000011c7a8 780b9fe3 rldicl. r11,r0,51,63
c00000000011c7ac 41820008 beq c00000000011c7b4 # .new_slab+0x28c/0x33c
c00000000011c7b0 e93f00ae lwa r9,172(r31)
c00000000011c7b4 3ca00001 lis r5,1
c00000000011c7b8 7f63db78 mr r3,r27
c00000000011c7bc 3880005a li r4,90
c00000000011c7c0 7ca54836 sld r5,r5,r9
c00000000011c7c4 4bf1ce29 bl c0000000000395ec # .memset+0x0/0xfc
c00000000011c7c8 60000000 nop
c00000000011c7cc 7f7cdb78 mr r28,r27
c00000000011c7d0 7f7ddb78 mr r29,r27
c00000000011c7d4 4800001c b c00000000011c7f0 # .new_slab+0x2c8/0x33c
c00000000011c7d8 4bffe2e9 bl c00000000011aac0 # .setup_object+0x0/0x9c
c00000000011c7dc e81a0012 lwa r0,16(r26)
c00000000011c7e0 7fbc012a stdx r29,r28,r0
c00000000011c7e4 7fbceb78 mr r28,r29
0:mon> r
R00 = 0000000000000000 R16 = 0000000002561f58
R01 = c000000000ac3c20 R17 = 0000000000000000
R02 = c000000000abc0d8 R18 = c000000000961f58
R03 = c000000000b29480 R19 = 00000000019ffcb0
R04 = f000000000268000 R20 = 0000000000000070
R05 = c000000070001030 R21 = c000000000b294a0
R06 = 0000000000000001 R22 = 0000000000000000
R07 = 0000000000000001 R23 = 0000000000000000
R08 = 0000000000000000 R24 = 00000000000000d0
R09 = 0000000000000000 R25 = c000000000b29480
R10 = 2e8ba2e8ba2e8ba3 R26 = c000000000b29480
R11 = 0000000000000000 R27 = c000000070000000
R12 = 0000000048000024 R28 = c000000070001030
R13 = c000000000b53480 R29 = c0000000700010a0
R14 = c000000000962020 R30 = c000000000a22498
R15 = c000000000847668 R31 = f000000000268000
pc = c00000000011c7e0 .new_slab+0x2b8/0x33c
lr = c00000000011c7dc .new_slab+0x2b4/0x33c
msr = 8000000000009032 cr = 28000022
ctr = 0000000000000000 xer = 000000000000000c trap = 300
dar = c000000070001030 dsisr = 42000000
0:mon>
^ permalink raw reply
* powerpc 405ex emac1 problem connect to single Giga phy
From: zhong wang @ 2009-03-10 5:36 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1.1: Type: text/plain, Size: 3088 bytes --]
Hello all：
We use the AMCC PowerPC 405ex through emac1 way RGMII with realtek RTL8211 Giga phy linked to, At present the PHY Address is: 00110
add delay 2ns for RGMII
CONFIG[8:5]:AUTO_Negotiation
1111=NWay,advertise ，all capabilities,prefer Slave
mode;1=RGMII mode
Clk on the hardware no problem, Mdio, mdc even on, but at Llinux / driver / net / ibm-newemac / core.c discovered phy address, phy ID at .Config file has joined
NETDEVICE = Y
PHYLIB=Y
REALTEK-PHY=Y
But will be compiled under the best Uimage to board, the feeling of the PHY the driver has not been mounted use. The following is a kernel information
PPC 4xx OCP EMAC driver, version 3.54
MAL v2 /plb/mcmal, 2 TX channels, 2 RX channels
RGMII /plb/opb/emac-rgmii@ef600b00 initialized with MDIO support
/plb/opb/emac-rgmii@ef600b00: input 0 in RGMII mode
eth0: EMAC-0 /plb/opb/ethernet@ef600900, MAC 00:47:41:52:52:59
/plb/opb/emac-rgmii@ef600b00: input 1 in RGMII mode
/plb/opb/ethernet@ef600a00: find TRL 821X Giga PHY（0x4）
But also in Llinux / driver / net / ibm-newemac / phy.c also add the operation of RTL8211bg as follows:
#define RTL821x_PHYSR 0x11
#define RTL821x_PHYSR_DUPLEX 0x2000
#define RTL821x_PHYSR_SPEED 0xc000
#define RTL821x_INER 0x12
#define RTL821x_INER_INIT 0x6400
#define RTL821x_INSR 0x13
static int rtl821x_init(struct mii_phy *phy)
{
phy_write(phy, RTL821x_INER, 0x6400); //enable interrupt
return 0;
}
static struct mii_phy_ops rtl821x_phy_ops = {
.init = rtl821x_init,
.setup_aneg = genmii_setup_aneg,
.setup_forced = genmii_setup_forced,
.poll_link = genmii_poll_link,
.read_link = genmii_read_link
};
static struct mii_phy_def rtl821x_phy_def = {
.phy_id = 0x001cc912, // for rtl8211 single phy
// .phy_id = 0x001cc960, for 8366sr inside phy 4
.phy_id_mask = 0x001fffff,
.name = "RTL 821X Giga Phy",
.features = PHY_GBIT_FEATURES,
//.flags = PHY_HAS_INTERRUPT,
.ops = &rtl821x_phy_ops
But will be compiled under the best Uimage to board, the feeling of the PHY the driver has not been mounted use. The following is a kernel information
After IP with a good PC PING board, Return Request Time Out! Troublesome players you look at what questions are
Connection diagram, see attachment
leowang
2009:03:10
___________________________________________________________
好玩贺卡等你发，邮箱贺卡全新上线！
http://card.mail.cn.yahoo.com/
[-- Attachment #1.2: Type: text/html, Size: 16011 bytes --]
[-- Attachment #2: Connection diagram.pdf --]
[-- Type: application/pdf, Size: 11298 bytes --]
^ permalink raw reply
* [PATCH] efp: Fix efp dependence
From: Liu Yu @ 2009-03-10 3:09 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: Liu Yu
There is no dependece between efp and math-emu.
But when disalbe math-emu, the efp code cannot be built.
This patch fixes it.
Signed-off-by: Liu Yu <yu.liu@freescale.com>
---
It would be nice to see this patch go along with 2.6.29
arch/powerpc/Makefile | 4 ++--
arch/powerpc/math-emu/Makefile | 5 ++---
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 72d17f5..551fc58 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -147,8 +147,8 @@ core-y += arch/powerpc/kernel/ \
arch/powerpc/mm/ \
arch/powerpc/lib/ \
arch/powerpc/sysdev/ \
- arch/powerpc/platforms/
-core-$(CONFIG_MATH_EMULATION) += arch/powerpc/math-emu/
+ arch/powerpc/platforms/ \
+ arch/powerpc/math-emu/
core-$(CONFIG_XMON) += arch/powerpc/xmon/
core-$(CONFIG_KVM) += arch/powerpc/kvm/
diff --git a/arch/powerpc/math-emu/Makefile b/arch/powerpc/math-emu/Makefile
index f9e506a..0c16ab9 100644
--- a/arch/powerpc/math-emu/Makefile
+++ b/arch/powerpc/math-emu/Makefile
@@ -1,6 +1,4 @@
-obj-y := math.o fmr.o lfd.o stfd.o
-
obj-$(CONFIG_MATH_EMULATION) += fabs.o fadd.o fadds.o fcmpo.o fcmpu.o \
fctiw.o fctiwz.o fdiv.o fdivs.o \
fmadd.o fmadds.o fmsub.o fmsubs.o \
@@ -9,7 +7,8 @@ obj-$(CONFIG_MATH_EMULATION) += fabs.o fadd.o fadds.o fcmpo.o fcmpu.o \
fres.o frsp.o frsqrte.o fsel.o lfs.o \
fsqrt.o fsqrts.o fsub.o fsubs.o \
mcrfs.o mffs.o mtfsb0.o mtfsb1.o \
- mtfsf.o mtfsfi.o stfiwx.o stfs.o
+ mtfsf.o mtfsfi.o stfiwx.o stfs.o \
+ math.o fmr.o lfd.o stfd.o
obj-$(CONFIG_SPE) += math_efp.o
--
1.5.4
^ permalink raw reply related
* Re: GPIO and SPI on CPM2 (8260)?
From: Daniel Ng @ 2009-03-10 1:15 UTC (permalink / raw)
To: Stepanov, Sergej, linuxppc-dev
In-Reply-To: <4206182445660643B9AEB8D4E55BBD0A02B57F6F18@HERMES2>
Hi Sergej,
On Fri, Mar 6, 2009 at 9:07 PM, Stepanov, Sergej <Sergej.Stepanov@ids.de> wrote:
> gpio - driver functions pretty well for a pin-setup, but uninitialized/unexported pins have undefined states
-did you achieve this using gpiolib.c? If not, then what files and
what kernel are you using? We are trying to get it working for 2.6.27.
> I found no spi-support for 8260-based boards with CPM2/1.
This is unfortunate. I guess this means SPI on these boards is not
used by many engineers...
> P.s. Have you seen cpm2-spi-support in u-boot?
No, sorry- not in u-boot.
^ permalink raw reply
* Re: Oops with 2.6.29-rc7 on POWER5
From: Benjamin Herrenschmidt @ 2009-03-10 0:36 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Alan Cox
In-Reply-To: <20090310000559.GD2256@yoda.jdub.homelinux.org>
On Mon, 2009-03-09 at 20:05 -0400, Josh Boyer wrote:
> [c00000000fffb830] [c0000000005fe504] .mutex_lock_nested+0x78/0x4b0
> (unreliable)
> [c00000000fffb950] [c00000000039d520] .echo_char_raw+0x40/0x98
> [c00000000fffb9f0] [c00000000039fd68] .n_tty_receive_buf+0xb48/0x1104
> [c00000000fffbbb0] [c0000000003a3a08] .flush_to_ldisc+0x160/0x244
> [c00000000fffbc80] [c0000000003a3b5c] .tty_flip_buffer_push+0x70/0x9c
> [c00000000fffbd10] [c0000000003b9e94] .hvsi_interrupt+0x464/0x590
> [c00000000fffbe50] [c000000000119168] .handle_IRQ_event+0x60/0xdc
> [c00000000fffbef0] [c00000000011baf0] .handle_fasteoi_irq+0x108/0x1a8
>
Do that patch help ?
Alan, any comment about the races talked about in those comments ? Are
they still something I should worry about ?
hvc: Remove tty->low_latency on pseries backends
The hvcs and hvsi backends both set tty->low_latency to one, along
with more or less scary comments regarding bugs or races that would
happen if not doing so.
However, they also both call tty_flip_buffer_push() in conexts where
it's illegal to do so since some recent tty changes (or at least it
may have been illegal always but it nows blows) when low_latency is
set (ie, hard interrupt or with spinlock held and irqs disabled).
This removes the setting for now to get them back to working condition,
we'll have to address the races described in the comments separately
if they are still an issue (some of this might have been fixed already).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Index: linux-work/drivers/char/hvcs.c
===================================================================
--- linux-work.orig/drivers/char/hvcs.c 2009-03-10 11:28:03.000000000 +1100
+++ linux-work/drivers/char/hvcs.c 2009-03-10 11:28:08.000000000 +1100
@@ -1139,15 +1139,6 @@ static int hvcs_open(struct tty_struct *
hvcsd->tty = tty;
tty->driver_data = hvcsd;
- /*
- * Set this driver to low latency so that we actually have a chance at
- * catching a throttled TTY after we flip_buffer_push. Otherwise the
- * flush_to_async may not execute until after the kernel_thread has
- * yielded and resumed the next flip_buffer_push resulting in data
- * loss.
- */
- tty->low_latency = 1;
-
memset(&hvcsd->buffer[0], 0x00, HVCS_BUFF_LEN);
/*
Index: linux-work/drivers/char/hvsi.c
===================================================================
--- linux-work.orig/drivers/char/hvsi.c 2009-03-10 11:27:19.000000000 +1100
+++ linux-work/drivers/char/hvsi.c 2009-03-10 11:27:22.000000000 +1100
@@ -810,7 +810,6 @@ static int hvsi_open(struct tty_struct *
hp = &hvsi_ports[line];
tty->driver_data = hp;
- tty->low_latency = 1; /* avoid throttle/tty_flip_buffer_push race */
mb();
if (hp->state == HVSI_FSP_DIED)
^ permalink raw reply
* Re: Please pull mpc52xx-next
From: Michael Neuling @ 2009-03-10 0:16 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40903091714h529a8546s982156fac349c426@mail.gmail.com>
> > Grant,
> >
> > Can you grab this guy too?
> >
> > http://patchwork.ozlabs.org/patch/24082/
>
> Oops, forgot to email you about this one. I actually wrote another
> patch the eliminates the sysfs attributes entirely which also
> eliminates the problem. It will be in my next pull request to Ben
> (any day now; just waiting for an ack on another patch).
OK, sounds good.
Mikey
^ permalink raw reply
* Re: Please pull mpc52xx-next
From: Grant Likely @ 2009-03-10 0:14 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <1001.1236642379@neuling.org>
Hey Mikey,
On Mon, Mar 9, 2009 at 5:46 PM, Michael Neuling <mikey@neuling.org> wrote:
> Grant,
>
> Can you grab this guy too?
>
> http://patchwork.ozlabs.org/patch/24082/
Oops, forgot to email you about this one. I actually wrote another
patch the eliminates the sysfs attributes entirely which also
eliminates the problem. It will be in my next pull request to Ben
(any day now; just waiting for an ack on another patch).
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Oops with 2.6.29-rc7 on POWER5
From: Josh Boyer @ 2009-03-10 0:05 UTC (permalink / raw)
To: linuxppc-dev
I get the following oops on a ppc64 machine using a Fedora rawhide kernel,
which is very close to 2.6.29-rc7.
It's a POWER5, pSeries CHRP IBM,9123-710.
Haven't looked into it just quite yet, but I found it interesting and was
wondering if anyone had seen anything like this or could recreate.
josh
BUG: sleeping function called from invalid context at kernel/mutex.c:207
in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper
------------[ cut here ]------------
Badness at kernel/mutex.c:135
NIP: c0000000005fe54c LR: c0000000005fe530 CTR: 0000000000000001
REGS: c00000000fffb5b0 TRAP: 0700 Not tainted (2.6.29-0.215.rc7.fc11.ppc64)
MSR: 8000000000021032 <ME,CE,IR,DR> CR: 28000082 XER: 0000000f
TASK = c000000000f69e90[0] 'swapper' THREAD: c000000001010000 CPU: 0
GPR00: 0000000000000000 c00000000fffb830 c0000000010106b8 0000000000000001
GPR04: c000000000f69e90 0000000000000070 0000000000000000 0000000000000002
GPR08: 0000000000000000 c00000000179a3b8 c00000000104cb58 c000000001086a10
GPR12: 000000000000003c c000000001058400 c00000006f09b4d0 c00000006f09b270
GPR16: c00000006f09b408 c00000000fffba60 0000000000000001 c00000006f09b3c8
GPR20: 0000000000000001 c00000006e570129 0000000000000000 c00000006f09b8c0
GPR24: 0000000000000000 c00000000039d520 c00000006f09b248 c000000000f69e90
GPR28: c00000006f09b8c0 c00000006f09b8c0 c000000000fa15c0 c00000000fffb830
NIP [c0000000005fe54c] .mutex_lock_nested+0xc0/0x4b0
LR [c0000000005fe530] .mutex_lock_nested+0xa4/0x4b0
Call Trace:
[c00000000fffb830] [c0000000005fe504] .mutex_lock_nested+0x78/0x4b0 (unreliable)
[c00000000fffb950] [c00000000039d520] .echo_char_raw+0x40/0x98
[c00000000fffb9f0] [c00000000039fd68] .n_tty_receive_buf+0xb48/0x1104
[c00000000fffbbb0] [c0000000003a3a08] .flush_to_ldisc+0x160/0x244
[c00000000fffbc80] [c0000000003a3b5c] .tty_flip_buffer_push+0x70/0x9c
[c00000000fffbd10] [c0000000003b9e94] .hvsi_interrupt+0x464/0x590
[c00000000fffbe50] [c000000000119168] .handle_IRQ_event+0x60/0xdc
[c00000000fffbef0] [c00000000011baf0] .handle_fasteoi_irq+0x108/0x1a8
[c00000000fffbf90] [c00000000002f1c4] .call_handle_irq+0x1c/0x2c
[c000000001013970] [c00000000000e0ac] .do_IRQ+0x144/0x258
[c000000001013a30] [c000000000004d28] hardware_interrupt_entry+0x28/0x2c
--- Exception: 501 at .raw_local_irq_restore+0xa4/0xc0
LR = .cpu_idle+0x13c/0x1e0
[c000000001013d20] [c000000000f9af28] mv88e6131_switch_driver+0x8d08/0x275f8 (unreliable)
[c000000001013dc0] [c000000000014d34] .cpu_idle+0x13c/0x1e0
[c000000001013e60] [c0000000006062b8] .rest_init+0x94/0xb0
[c000000001013ee0] [c00000000088bd08] .start_kernel+0x4a4/0x4c8
[c000000001013f90] [c000000000008408] .start_here_common+0x2c/0xa4
Instruction dump:
78290464 80090014 5409012f 41a20028 4bcb199d 60000000 2fa30000 419e0018
e93e8008 80090000 2f800000 409e0008 <0fe00000> 38000000 8b8d01da 980d01da
^ permalink raw reply
* Re: Does DRI/DRM still work on non-coherent DMA platforms?
From: Benjamin Herrenschmidt @ 2009-03-10 0:07 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev list
In-Reply-To: <20090309213034.192330@gmx.net>
On Mon, 2009-03-09 at 22:30 +0100, Gerhard Pircher wrote:
> Hi,
>
> I heard rumors that DRI doesn't work on SAM440EP (onboard Radeon GPU)
> boards. I had DRI halfway working on my AmigaOne (Radeon 9250) with an
> early release candidate of the 2.6.25 kernel and IIRC this patch here
> (manually applied):
> http://kerneltrap.org/index.php?q=mailarchive/git-commits-head/2008/3/30/1301044
>
> I just tested DRI again on my A1 (I don't have a SAM board) with
> v2.6.29-rc6 and the machine looks up while starting the X server.
> Curiously DRI seems to work, if I specify "udbg-immortal" on the
> kernel command line and enable DRM debugging.
> Did anyone try out DRI on a non-coherent DMA PPC platform and can
> confirm that it still works?
It should work... try using dri-next branch from airlied tree, I had
that working on a Canyonlands after DaveM and I fixed a whole bunch of
issues. Also make sure you use the latest X side driver too.
Cheers,
Ben.
^ permalink raw reply
* Re: Please pull mpc52xx-next
From: Michael Neuling @ 2009-03-09 23:46 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40903061008u707b0988s32f04d757d3feb16@mail.gmail.com>
> Hey Ben,
>
> Here are some more for -next.
>
> The following changes since commit 652e8f8d579d61745094e36b4ff085026a332e73:
> Benjamin Herrenschmidt (1):
> Merge commit 'jwb/next' into next
>
> are available in the git repository at:
>
> git://git.secretlab.ca/git/linux-2.6-mpc52xx next
Grant,
Can you grab this guy too?
http://patchwork.ozlabs.org/patch/24082/
Mikey
>
> Grant Likely (2):
> powerpc/5200: Add 'simple-bus' to the of_platform probe list.
> powerpc/4xx: update ml507 .dts file to release reference design
>
> Grzegorz Bernacki (2):
> powerpc/5200: Add digsy-mtc support to mpc5200_defconfig
> powerpc/5200: On the digsy-mtc, configure PSC4 and PSC5 as UARTs
>
> arch/powerpc/boot/dts/digsy_mtc.dts | 12 ++--
> arch/powerpc/boot/dts/virtex440-ml507.dts | 124 +++++++++++++++++++++++-
--
> arch/powerpc/configs/mpc5200_defconfig | 71 +++++++++++++--
> arch/powerpc/platforms/52xx/mpc52xx_common.c | 3 +-
> 4 files changed, 184 insertions(+), 26 deletions(-)
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Does DRI/DRM still work on non-coherent DMA platforms?
From: Gerhard Pircher @ 2009-03-09 21:30 UTC (permalink / raw)
To: linuxppc-dev list
Hi,
I heard rumors that DRI doesn't work on SAM440EP (onboard Radeon GPU)
boards. I had DRI halfway working on my AmigaOne (Radeon 9250) with an
early release candidate of the 2.6.25 kernel and IIRC this patch here
(manually applied):
http://kerneltrap.org/index.php?q=mailarchive/git-commits-head/2008/3/30/1301044
I just tested DRI again on my A1 (I don't have a SAM board) with
v2.6.29-rc6 and the machine looks up while starting the X server.
Curiously DRI seems to work, if I specify "udbg-immortal" on the
kernel command line and enable DRM debugging.
Did anyone try out DRI on a non-coherent DMA PPC platform and can
confirm that it still works?
best regards,
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
^ permalink raw reply
* Re: [PATCH] powerpc 4xx: DDR0_14[REDUC] decoded incorrectly
From: Mikhail Zolotaryov @ 2009-03-09 21:17 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20090309171243.GA26415@zod.rchland.ibm.com>
>> However, "1" is decoded as 64 bit (8 byte), "0" - as 32 bit (4 byte) bus
>> by the kernel code. My understanding is this is not correct - patch
>> attached.
>
> You are missing the Signed-off-by tag that is needed.
>
I'm sorry.
Signed-off-by: Mikhail Zolotaryov <lebon@lebon.org.ua>
> Aside from that, I'm curious if you found this just through inspection, or
> if you actually had a problem because of it. Your fix seems correct, yet
> I've had no problems with my boards at all.
>
I'm actually working on custom PowerPC 440EPX board development here and
have found the problem: without applying changes described, Linux
detects memory size incorrectly and is unable to start. The rest of
memory size computation process seems to be correct.
I have checked Sequoia evaluation board with U-Boot 2009.1 and confirm
that original kernel code reported memory size correctly. So, for my
understanding, if computation algorithm was wrong but result was correct
- the problem is source data i.e. initial DDR configuration parameters
loaded by U-Boot (please don't give a damn that memory size is always
reported correctly by U-Boot - it's hard-coded constant there). I have
checked Sequoia board schematics (DES0211_11_SCH_11.pdf, page 5, unit
U1D) and noted that BankSel#1 is not connected, while bootloader memory
configuration is (board/amcc/sequoia/sdram.c):
mtsdram(DDR0_10, 0x00000300);
i.e. both Chip Selects used.
If I change this line to:
mtsdram(DDR0_10, 0x00000100);
memory is accessible, patched kernel detects memory size correctly and
kernel seems to be working well.
Please check my considerations, possibly it may be necessary to request
additional information from board manufacturer.
^ permalink raw reply
* Re: [rtc-linux] Re: [PATCH 7/7] powerpc/ps3: Add rtc-ps3
From: Joe Perches @ 2009-03-09 19:18 UTC (permalink / raw)
To: Geoff Levand
Cc: linux-m68k, Alessandro Zummo, rtc-linux, linux-parisc,
linux-kernel, Kyle McMartin, linuxppc-dev, Paul Mundt,
Geert.Uytterhoeven, Andrew Morton, Linus Torvalds, Dann Frazier
In-Reply-To: <49B568D0.5000901@am.sony.com>
On Mon, 2009-03-09 at 12:06 -0700, Geoff Levand wrote:
> There was some work by Joe Perches to list the files a maintainer is
> responsible for into the MAINTAINERS file. I think that would give
> you what you want, a way to automatically get the maintainer of a
> file.
>
> Joe, could you let us know the status of that work?
I think it works fine, and is an acceptable
approach to finding a maintainer for either a
patch or a specific file.
The changes I've posted are probably not suitable
for merging by anyone other than Linus as
MAINTAINERS is the most heavily modified file
in the kernel tree.
I've submitted it several times after merging it
with the latest kernel without response from Linus.
I'd merge and submit it again if it could be accepted.
If someone would propose a mechanism that would
improve the possibility to get it merged, I'd
also appreciate that.
^ permalink raw reply
* Re: [rtc-linux] Re: [PATCH 7/7] powerpc/ps3: Add rtc-ps3
From: Geoff Levand @ 2009-03-09 19:06 UTC (permalink / raw)
To: Alessandro Zummo, Joe Perches
Cc: linux-m68k, rtc-linux, linux-parisc, linux-kernel, Kyle McMartin,
linuxppc-dev, Paul Mundt, Geert.Uytterhoeven, Dann Frazier
In-Reply-To: <20090309194307.154f3e95@i1501.lan.towertech.it>
Hi,
On 03/09/2009 11:43 AM, Alessandro Zummo wrote:
> Geoff Levand <geoffrey.levand@am.sony.com> wrote:
>> On 03/09/2009 07:12 AM, Alessandro Zummo wrote:
>> > On Mon, 9 Mar 2009 14:26:23 +0100
>> > Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
>> >> +
>> >> +MODULE_AUTHOR("Sony Corporation");
>> >
>> > real name, if possible and a contact address
>> > here . Just in case I need someone to bother :)
>>
>> Please look at the MAINTAINERS file, that will give
>> the contact for PS3. It is much easier to maintain
>> a single place for the contact than many spread
>> throughout the kernel sources.
>
> Having it in MODULE_AUTHOR allow my scripts to automatically
> send an email when appropriate.
>
> MAINTAINERS lists the files with an arbitrary
> driver title so that the search must be made by an human and there's
> no field that links a person to a specific .c .
>
> so every time I want to address someone I need to check MODULE_AUTHOR,
> the git log and the MAINTAINERS file.
I see. It seems what you want is MODULE_MAINTAINER, as author is
the author, who after some time, may not be the maintainer any more.
There was some work by Joe Perches to list the files a maintainer is
responsible for into the MAINTAINERS file. I think that would give
you what you want, a way to automatically get the maintainer of a
file.
Joe, could you let us know the status of that work?
-Geoff
^ permalink raw reply
* Re: [PATCH 7/7] powerpc/ps3: Add rtc-ps3
From: Geoff Levand @ 2009-03-09 18:35 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-m68k, Alessandro Zummo, rtc-linux, linux-parisc,
linux-kernel, Kyle McMartin, linuxppc-dev, Paul Mundt,
Dann Frazier
In-Reply-To: <1236605183-22718-8-git-send-email-Geert.Uytterhoeven@sonycom.com>
On 03/09/2009 06:26 AM, Geert Uytterhoeven wrote:
> Create a real RTC driver for PS3, and unhook the deprecated
> ppc_md.[gs]et_rtc_time.
> 8 files changed, 132 insertions(+), 18 deletions(-)
Sorry, I hadn't been following the discussion closely, but
could you explain why we are going from a generic framework
where we hook in our platform specific part to a totally
independent driver that has such an increase in code size.
Why couldn't you fix the generic part so that udev could
load it automatically?
I much prefer to have this code in the platform support
code as it was. It is much more effort (a pain) to maintain
a separate driver were I have to cater to a subsystem's
maintainer, and with this rtc it seems everyone who was
using the generic PPC driver will need to do the same.
-Geoff
^ permalink raw reply
* Re: [rtc-linux] Re: [PATCH 7/7] powerpc/ps3: Add rtc-ps3
From: Alessandro Zummo @ 2009-03-09 18:43 UTC (permalink / raw)
To: rtc-linux
Cc: linux-m68k, linux-parisc, Dann, Kyle, linux-kernel, McMartin,
linuxppc-dev, Paul Mundt, Geert.Uytterhoeven, Frazier
In-Reply-To: <49B55A21.2010801@am.sony.com>
On Mon, 9 Mar 2009 11:04:17 -0700
Geoff Levand <geoffrey.levand@am.sony.com> wrote:
>
> Hi,
>
> On 03/09/2009 07:12 AM, Alessandro Zummo wrote:
> > On Mon, 9 Mar 2009 14:26:23 +0100
> > Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> >> +
> >> +MODULE_AUTHOR("Sony Corporation");
> >
> > real name, if possible and a contact address
> > here . Just in case I need someone to bother :)
>
> Please look at the MAINTAINERS file, that will give
> the contact for PS3. It is much easier to maintain
> a single place for the contact than many spread
> throughout the kernel sources.
Having it in MODULE_AUTHOR allow my scripts to automatically
send an email when appropriate.
MAINTAINERS lists the files with an arbitrary
driver title so that the search must be made by an human and there's
no field that links a person to a specific .c .
so every time I want to address someone I need to check MODULE_AUTHOR,
the git log and the MAINTAINERS file.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
^ permalink raw reply
* Re: [rtc-linux] [PATCH 7/7] powerpc/ps3: Add rtc-ps3
From: Geoff Levand @ 2009-03-09 18:04 UTC (permalink / raw)
To: Alessandro Zummo
Cc: linux-m68k, rtc-linux, linux-parisc, linux-kernel, Kyle McMartin,
linuxppc-dev, Paul Mundt, Geert.Uytterhoeven, Dann Frazier
In-Reply-To: <20090309151216.17f13862@i1501.lan.towertech.it>
Hi,
On 03/09/2009 07:12 AM, Alessandro Zummo wrote:
> On Mon, 9 Mar 2009 14:26:23 +0100
> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
>> +
>> +MODULE_AUTHOR("Sony Corporation");
>
> real name, if possible and a contact address
> here . Just in case I need someone to bother :)
Please look at the MAINTAINERS file, that will give
the contact for PS3. It is much easier to maintain
a single place for the contact than many spread
throughout the kernel sources.
-Geoff
^ permalink raw reply
* [PATCH] powerpc udbg: fix lost byte during console handover; change LFCR to CRLF
From: Andrew Klossner @ 2009-03-09 17:52 UTC (permalink / raw)
To: linuxppc-dev
When the console is on a serial port to be driven by serial8250, a
character can be lost from the end of the first line in the two-line
sequence
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42) is a 16550A
console handover: boot [udbg0] -> real [ttyS0]
This happens because udbg_puts or udbg_write stuff the last byte of
the line into the Tx FIFO and return, whereupon the serial8250
initialization code immediately empties that FIFO. The fix: udbg_puts
and udbg_write now wait for the Tx FIFO to clear before returning.
This delays the system by one additional serial frame time for each
line written by udbg, but the effect is not noticeable, a cumulative
17 milliseconds for 200 lines of early printk output at 115200 baud.
Also, the routines in udbg_16550.c now emit CRLF instead of LFCR.
Linux makes a point of emitting CRLF because, when serial output is
captured to a file, LFCR sequences can confuse text editors. See
http://lkml.org/lkml/2006/2/4/50 for some history.
Signed-off-by: Andrew Klossner <andrew@cesa.opbu.xerox.com>
---
arch/powerpc/include/asm/udbg.h | 1 +
arch/powerpc/kernel/udbg.c | 7 ++++
arch/powerpc/kernel/udbg_16550.c | 60 +++++++++++++++++++++++++++++++------
3 files changed, 58 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/udbg.h b/arch/powerpc/include/asm/udbg.h
index 6418cee..cd21e5e 100644
--- a/arch/powerpc/include/asm/udbg.h
+++ b/arch/powerpc/include/asm/udbg.h
@@ -15,6 +15,7 @@
#include <linux/init.h>
extern void (*udbg_putc)(char c);
+extern void (*udbg_flush)(void);
extern int (*udbg_getc)(void);
extern int (*udbg_getc_poll)(void);
diff --git a/arch/powerpc/kernel/udbg.c b/arch/powerpc/kernel/udbg.c
index 7d6c9bb..fc9af47 100644
--- a/arch/powerpc/kernel/udbg.c
+++ b/arch/powerpc/kernel/udbg.c
@@ -18,6 +18,7 @@
#include <asm/udbg.h>
void (*udbg_putc)(char c);
+void (*udbg_flush)(void);
int (*udbg_getc)(void);
int (*udbg_getc_poll)(void);
@@ -76,6 +77,9 @@ void udbg_puts(const char *s)
while ((c = *s++) != '\0')
udbg_putc(c);
}
+
+ if (udbg_flush)
+ udbg_flush();
}
#if 0
else {
@@ -98,6 +102,9 @@ int udbg_write(const char *s, int n)
}
}
+ if (udbg_flush)
+ udbg_flush();
+
return n - remain;
}
diff --git a/arch/powerpc/kernel/udbg_16550.c b/arch/powerpc/kernel/udbg_16550.c
index 7b7da8c..0362a89 100644
--- a/arch/powerpc/kernel/udbg_16550.c
+++ b/arch/powerpc/kernel/udbg_16550.c
@@ -48,14 +48,21 @@ struct NS16550 {
static struct NS16550 __iomem *udbg_comport;
-static void udbg_550_putc(char c)
+static void udbg_550_flush(void)
{
if (udbg_comport) {
while ((in_8(&udbg_comport->lsr) & LSR_THRE) == 0)
/* wait for idle */;
- out_8(&udbg_comport->thr, c);
+ }
+}
+
+static void udbg_550_putc(char c)
+{
+ if (udbg_comport) {
if (c == '\n')
udbg_550_putc('\r');
+ udbg_550_flush();
+ out_8(&udbg_comport->thr, c);
}
}
@@ -108,6 +115,7 @@ void udbg_init_uart(void __iomem *comport, unsigned int speed,
/* Clear & enable FIFOs */
out_8(&udbg_comport->fcr ,0x07);
udbg_putc = udbg_550_putc;
+ udbg_flush = udbg_550_flush;
udbg_getc = udbg_550_getc;
udbg_getc_poll = udbg_550_getc_poll;
}
@@ -149,14 +157,21 @@ unsigned int udbg_probe_uart_speed(void __iomem *comport, unsigned int clock)
}
#ifdef CONFIG_PPC_MAPLE
-void udbg_maple_real_putc(char c)
+void udbg_maple_real_flush(void)
{
if (udbg_comport) {
while ((real_readb(&udbg_comport->lsr) & LSR_THRE) == 0)
/* wait for idle */;
- real_writeb(c, &udbg_comport->thr); eieio();
+ }
+}
+
+void udbg_maple_real_putc(char c)
+{
+ if (udbg_comport) {
if (c == '\n')
udbg_maple_real_putc('\r');
+ udbg_maple_real_flush();
+ real_writeb(c, &udbg_comport->thr); eieio();
}
}
@@ -165,20 +180,28 @@ void __init udbg_init_maple_realmode(void)
udbg_comport = (struct NS16550 __iomem *)0xf40003f8;
udbg_putc = udbg_maple_real_putc;
+ udbg_flush = udbg_maple_real_flush;
udbg_getc = NULL;
udbg_getc_poll = NULL;
}
#endif /* CONFIG_PPC_MAPLE */
#ifdef CONFIG_PPC_PASEMI
-void udbg_pas_real_putc(char c)
+void udbg_pas_real_flush(void)
{
if (udbg_comport) {
while ((real_205_readb(&udbg_comport->lsr) & LSR_THRE) == 0)
/* wait for idle */;
- real_205_writeb(c, &udbg_comport->thr); eieio();
+ }
+}
+
+void udbg_pas_real_putc(char c)
+{
+ if (udbg_comport) {
if (c == '\n')
udbg_pas_real_putc('\r');
+ udbg_pas_real_flush();
+ real_205_writeb(c, &udbg_comport->thr); eieio();
}
}
@@ -187,6 +210,7 @@ void udbg_init_pas_realmode(void)
udbg_comport = (struct NS16550 __iomem *)0xfcff03f8UL;
udbg_putc = udbg_pas_real_putc;
+ udbg_flush = udbg_pas_real_flush;
udbg_getc = NULL;
udbg_getc_poll = NULL;
}
@@ -195,14 +219,21 @@ void udbg_init_pas_realmode(void)
#ifdef CONFIG_PPC_EARLY_DEBUG_44x
#include <platforms/44x/44x.h>
-static void udbg_44x_as1_putc(char c)
+static int udbg_44x_as1_flush(void)
{
if (udbg_comport) {
while ((as1_readb(&udbg_comport->lsr) & LSR_THRE) == 0)
/* wait for idle */;
- as1_writeb(c, &udbg_comport->thr); eieio();
+ }
+}
+
+static void udbg_44x_as1_putc(char c)
+{
+ if (udbg_comport) {
if (c == '\n')
udbg_44x_as1_putc('\r');
+ udbg_44x_as1_flush();
+ as1_writeb(c, &udbg_comport->thr); eieio();
}
}
@@ -222,19 +253,27 @@ void __init udbg_init_44x_as1(void)
(struct NS16550 __iomem *)PPC44x_EARLY_DEBUG_VIRTADDR;
udbg_putc = udbg_44x_as1_putc;
+ udbg_flush = udbg_44x_as1_flush;
udbg_getc = udbg_44x_as1_getc;
}
#endif /* CONFIG_PPC_EARLY_DEBUG_44x */
#ifdef CONFIG_PPC_EARLY_DEBUG_40x
-static void udbg_40x_real_putc(char c)
+static void udbg_40x_real_flush(void)
{
if (udbg_comport) {
while ((real_readb(&udbg_comport->lsr) & LSR_THRE) == 0)
/* wait for idle */;
- real_writeb(c, &udbg_comport->thr); eieio();
+ }
+}
+
+static void udbg_40x_real_putc(char c)
+{
+ if (udbg_comport) {
if (c == '\n')
udbg_40x_real_putc('\r');
+ udbg_40x_real_flush();
+ real_writeb(c, &udbg_comport->thr); eieio();
}
}
@@ -254,6 +293,7 @@ void __init udbg_init_40x_realmode(void)
CONFIG_PPC_EARLY_DEBUG_40x_PHYSADDR;
udbg_putc = udbg_40x_real_putc;
+ udbg_flush = udbg_40x_real_flush;
udbg_getc = udbg_40x_real_getc;
udbg_getc_poll = NULL;
}
--
1.6.1.3
^ permalink raw reply related
* Re: 2.6.29-rc7-git2 : crash in kmem_list3_init()
From: Mel Gorman @ 2009-03-09 17:46 UTC (permalink / raw)
To: Sachin P. Sant; +Cc: linuxppc-dev, cl
In-Reply-To: <49B5448B.6030205@in.ibm.com>
On Mon, Mar 09, 2009 at 10:02:11PM +0530, Sachin P. Sant wrote:
> While trying to boot 2.6.29-rc7-git2 on a power5 box ran into
> following crash.
>
> Unable to handle kernel paging request for data at address 0xc000000070001008
> Faulting instruction address: 0xc000000000119070
> cpu 0x0: Vector: 300 (Data Access) at [c000000000ac3980]
> pc: c000000000119070: .kmem_list3_init+0x68/0x8c
> lr: c00000000011906c: .kmem_list3_init+0x64/0x8c
> sp: c000000000ac3c00
> msr: 8000000000009032
> dar: c000000070001008
> dsisr: 42000000
> current = 0xc0000000009ea610
> paca = 0xc000000000b43480
> pid = 0, comm = swapper
> enter ? for help
> [c000000000ac3c90] c00000000068b788 .setup_cpu_cache+0xf8/0x1e8
> [c000000000ac3d20] c00000000011c8a0 .kmem_cache_create+0x43c/0x500
> [c000000000ac3e20] c000000000948c54 .kmem_cache_init+0x284/0x640
> [c000000000ac3ee0] c000000000920a5c .start_kernel+0x360/0x480
> [c000000000ac3f90] c0000000000083d8 .start_here_common+0x1c/0x44
>
> Attached here is the dmesg log with loglevel=8 mminit_loglevel=4
> as well as .config used.
>
> Tried to boot a kernel.org kernel on this box for first time so not
> sure if this is a new problem or a recurring one. Will try booting
> some older kernels on this box and will report the results.
>
> Node 0 Memory: 0x8000000-0x3a000000
> Node 1 Memory: 0x0-0x8000000 0x3a000000-0x72000000
> PCI host bridge /pci@800000020000003 ranges:
> IO 0x000003fe00700000..0x000003fe007fffff -> 0x0000000000000000
> MEM 0x00000401c0000000..0x00000401ffffffff -> 0x00000000c0000000
> EEH: PCI Enhanced I/O Error Handling Enabled
> PPC64 nvram contains 7168 bytes
> Using shared processor idle loop
> Zone PFN ranges:
> DMA 0x00000000 -> 0x00007200
> Normal 0x00007200 -> 0x00007200
> Movable zone start PFN for each node
> early_node_map[3] active PFN ranges
> 1: 0x00000000 -> 0x00000800
> 0: 0x00000800 -> 0x00003a00
> 1: 0x00003a00 -> 0x00007200
What's interesting about this machine is that the nodes are interleaving. It's
possible someone is double initialising incorrectly.
> mminit::pageflags_layout_widths Section 0 Node 4 Zone 2 Flags 22
> mminit::pageflags_layout_shifts Section 20 Node 4 Zone 2
> mminit::pageflags_layout_offsets Section 0 Node 60 Zone 58
> mminit::pageflags_layout_zoneid Zone ID: 58 -> 64
> mminit::pageflags_layout_usage location: 64 -> 58 unused 58 -> 22 flags 22 -> 0
> On node 0 totalpages: 12800
> DMA zone: 18 pages used for memmap
> DMA zone: 0 pages reserved
> DMA zone: 12782 pages, LIFO batch:1
> mminit::memmap_init Initialising map node 0 zone 0 pfns 2048 -> 14848
> On node 1 totalpages: 16384
> DMA zone: 40 pages used for memmap
> DMA zone: 0 pages reserved
> DMA zone: 16344 pages, LIFO batch:1
> mminit::memmap_init Initialising map node 1 zone 0 pfns 0 -> 29184
See, the core initialising at least goes over both nodes when
initialising node 1. The page mappings should be ok because this
situation is checked for but it's possible the SLAB allocator is missing
something.
> [boot]0015 Setup Done
> mminit::zonelist general 0:DMA = 0:DMA 1:DMA
> mminit::zonelist thisnode 0:DMA = 0:DMA
> mminit::zonelist general 1:DMA = 1:DMA 0:DMA
> mminit::zonelist thisnode 1:DMA = 1:DMA
> Built 2 zonelists in Node order, mobility grouping on. Total pages: 29126
> Policy zone: DMA
> Kernel command line: root=/dev/sda5 quiet sysrq=1 loglevel=8 mminit_loglevel=4
> [boot]0020 XICS Init
> [boot]0021 XICS Done
> pic: no ISA interrupt controller
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> time_init: decrementer frequency = 207.050000 MHz
> time_init: processor frequency = 1656.400000 MHz
> clocksource: timebase mult[1351aa5] shift[22] registered
> clockevent: decrementer mult[3501] shift[16] cpu[0]
> Console: colour dummy device 80x25
> console handover: boot [udbg0] -> real [hvc0]
> Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
> ... MAX_LOCKDEP_SUBCLASSES: 8
> ... MAX_LOCK_DEPTH: 48
> ... MAX_LOCKDEP_KEYS: 8191
> ... CLASSHASH_SIZE: 4096
> ... MAX_LOCKDEP_ENTRIES: 8192
> ... MAX_LOCKDEP_CHAINS: 16384
> ... CHAINHASH_SIZE: 8192
> memory used by lock dependency info: 3839 kB
> per task-struct memory footprint: 1920 bytes
> Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes)
> Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes)
> freeing bootmem node 0
> freeing bootmem node 1
> Memory: 1812096k/1867776k available (9792k kernel code, 57856k reserved, 1216k data, 8025k bss, 448k init)
> Unable to handle kernel paging request for data at address 0xc000000070001008
What is meant to be stored at this address 0xc000000070001008? Because the
error occurs aftre freeing bootmem memory, I wonder with the interleaving
node if memory is getting inappropriately freed.
> Faulting instruction address: 0xc000000000119070
> cpu 0x0: Vector: 300 (Data Access) at [c000000000ac3980]
> pc: c000000000119070: .kmem_list3_init+0x68/0x8c
> lr: c00000000011906c: .kmem_list3_init+0x64/0x8c
> sp: c000000000ac3c00
> msr: 8000000000009032
> dar: c000000070001008
> dsisr: 42000000
> current = 0xc0000000009ea610
> paca = 0xc000000000b43480
> pid = 0, comm = swapper
> enter ? for help
> [c000000000ac3c90] c00000000068b788 .setup_cpu_cache+0xf8/0x1e8
> [c000000000ac3d20] c00000000011c8a0 .kmem_cache_create+0x43c/0x500
> [c000000000ac3e20] c000000000948c54 .kmem_cache_init+0x284/0x640
> [c000000000ac3ee0] c000000000920a5c .start_kernel+0x360/0x480
> [c000000000ac3f90] c0000000000083d8 .start_here_common+0x1c/0x44
> 0:mon>
> 0:mon> ls .kmem_list3_init
> .kmem_list3_init: c000000000119008
> 0:mon> di c000000000119008
> c000000000119008 7c0802a6 mflr r0
> c00000000011900c fb81ffe0 std r28,-32(r1)
> c000000000119010 fba1ffe8 std r29,-24(r1)
> c000000000119014 fbc1fff0 std r30,-16(r1)
> c000000000119018 ebc2b2a0 ld r30,-19808(r2)
> c00000000011901c 7c7d1b78 mr r29,r3
> c000000000119020 f8010010 std r0,16(r1)
> c000000000119024 3b800000 li r28,0
> c000000000119028 38030010 addi r0,r3,16
> c00000000011902c 39230020 addi r9,r3,32
> c000000000119030 f821ff71 stdu r1,-144(r1)
> c000000000119034 f87d0000 std r3,0(r29)
> c000000000119038 f8030018 std r0,24(r3)
> c00000000011903c e8be8000 ld r5,-32768(r30)
> c000000000119040 f8030010 std r0,16(r3)
> c000000000119044 f87d0008 std r3,8(r29)
> 0:mon>
> c000000000119048 fb830070 std r28,112(r3)
> c00000000011904c fb830078 std r28,120(r3)
> c000000000119050 9383003c stw r28,60(r3)
> c000000000119054 f9230028 std r9,40(r3)
> c000000000119058 f9230020 std r9,32(r3)
> c00000000011905c e89e8100 ld r4,-32512(r30)
> c000000000119060 38630040 addi r3,r3,64
> c000000000119064 38a50020 addi r5,r5,32
> c000000000119068 482b7b3d bl c0000000003d0ba4 # .__spin_lock_init+0x0/0x84
> c00000000011906c 60000000 nop
> c000000000119070 939d0088 stw r28,136(r29)
>
> ^^^^^^ fails here
> This probably corresponds to the following line from kmem_list3_init()
>
> parent->free_objects = 0;
>
If parent is NULL, it would have crashed before this but no worries
about that, it's NULL
> c000000000119074 fb9d0030 std r28,48(r29)
> c000000000119078 38210090 addi r1,r1,144
> c00000000011907c e8010010 ld r0,16(r1)
> c000000000119080 eb81ffe0 ld r28,-32(r1)
> c000000000119084 eba1ffe8 ld r29,-24(r1)
> 0:mon> r
> R00 = c00000000011906c R16 = 0000000000000000
> R01 = c000000000ac3c00 R17 = c000000000ac3d98
> R02 = c000000000abb3e0 R18 = c000000000ac3d90
> R03 = 0000000000000001 R19 = 0000000000010000
> R04 = c000000000862718 R20 = 0000000000046000
> R05 = c0000000011b99a8 R21 = c000000000862a08
> R06 = 0000000000000000 R22 = 00000000000003f4
> R07 = c000000070000000 R23 = ffffffffffffff80
> R08 = c0000000009ea638 R24 = 0000000000001000
> R09 = ffffffffffffffff R25 = 0000000000000000
> R10 = 0000000000000002 R26 = 0000000000000f80
> R11 = c0000000009ea638 R27 = 0000000000000080
> R12 = 0000000044022044 R28 = 0000000000000000
> R13 = c000000000b43480 R29 = c000000070000f80
> R14 = c000000000962338 R30 = c000000000a224a8
> R15 = c000000000845d68 R31 = c000000038004200
> pc = c000000000119070 .kmem_list3_init+0x68/0x8c
> lr = c00000000011906c .kmem_list3_init+0x64/0x8c
> msr = 8000000000009032 cr = 44022042
> ctr = 0000000000000000 xer = 000000000000000c trap = 300
> dar = c000000070001008 dsisr = 42000000
> 0:mon>
>
^ permalink raw reply
* Re: [PATCH] ps3/block: Replace mtd/ps3vram by block/ps3vram
From: Geoff Levand @ 2009-03-09 17:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Arnd Bergmann, Linus Torvalds, Linux Kernel Development,
Jim Paris, Linux/PPC Development, linux-mtd, Jens Axboe,
Geert Uytterhoeven, Vivien Chappelier, David Woodhouse,
Cell Broadband Engine OSS Development
In-Reply-To: <alpine.LRH.2.00.0903061349010.16809@vixen.sonytel.be>
On 03/06/2009 04:54 AM, Geert Uytterhoeven wrote:
> Convert the PS3 Video RAM Storage Driver from an MTD driver to a plain block
> device driver.
>
> The ps3vram driver exposes unused video RAM on the PS3 as a block device
> suitable for storage or swap. Fast data transfer is achieved using a local
> cache in system RAM and DMA transfers via the GPU.
>
> The new driver is ca. 50% faster for reading, and ca. 10% for writing.
>
> arch/powerpc/platforms/ps3/Kconfig | 7 +
> drivers/block/Makefile | 1 +
> drivers/block/ps3vram.c | 865 ++++++++++++++++++++++++++++++++++++
> drivers/mtd/devices/Kconfig | 7 -
> drivers/mtd/devices/Makefile | 1 -
> drivers/mtd/devices/ps3vram.c | 768 --------------------------------
> 6 files changed, 873 insertions(+), 776 deletions(-)
> create mode 100644 drivers/block/ps3vram.c
> delete mode 100644 drivers/mtd/devices/ps3vram.c
Looks good, certainly an improvement.
Acked-by: Geoff Levand <geoffrey.levand@am.sony.com>
^ permalink raw reply
* Re: [PATCH] powerpc 4xx: DDR0_14[REDUC] decoded incorrectly
From: Josh Boyer @ 2009-03-09 17:12 UTC (permalink / raw)
To: Mikhail Zolotaryov; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <49B54210.5040709@lebon.org.ua>
On Mon, Mar 09, 2009 at 06:21:36PM +0200, Mikhail Zolotaryov wrote:
> Hi,
>
> according to the PPC440EPx Embedded Processor User Manual (rev 1.14)
> DDR0_14[REDUC] bit has the following meaning:
>
> REDUC - Enable the half data path feature of the controller
> 0 = Standard operation using full 64/72-bit memory bus
> 1 = Memory data path width is 32/40 bits
>
> However, "1" is decoded as 64 bit (8 byte), "0" - as 32 bit (4 byte) bus
> by the kernel code. My understanding is this is not correct - patch
> attached.
You are missing the Signed-off-by tag that is needed.
Aside from that, I'm curious if you found this just through inspection, or
if you actually had a problem because of it. Your fix seems correct, yet
I've had no problems with my boards at all.
josh
^ permalink raw reply
* Re: [PATCH] powerpc/86xx: Correct local bus registers in GE Fanuc SBC610 dts file
From: Kumar Gala @ 2009-03-09 16:56 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev
In-Reply-To: <20090227155310.7771.96519.stgit@ubuntu8041.localdomain>
On Feb 27, 2009, at 9:53 AM, Martyn Welch wrote:
> The registers for the local bus are incorrectly set to 0xf8005000
> rather
> than there actual location of 0xfef05000.
>
> Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
> ---
>
> arch/powerpc/boot/dts/gef_sbc610.dts | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH resend 0/6] OpenFirmware support for the spi_mpc83xx driver
From: Kumar Gala @ 2009-03-09 16:53 UTC (permalink / raw)
To: avorontsov
Cc: David Brownell, linux-kernel, linuxppc-dev, spi-devel-general,
Andrew Morton
In-Reply-To: <20090123194958.GA17355@oksana.dev.rtsoft.ru>
On Jan 23, 2009, at 1:49 PM, Anton Vorontsov wrote:
> On Tue, Jan 06, 2009 at 10:28:10PM -0600, Kumar Gala wrote:
>> On Dec 5, 2008, at 2:09 PM, Anton Vorontsov wrote:
>>> Hi all,
>>>
>>> The patch series are used to support SPI via the OF SPI subsystem
>>> (driver/of/of_spi.c). Now the driver is able to manage its own
>>> chip selects, and doesn't need any auxiliary support from the
>>> board files or fsl_soc constructors.
>>>
>>> The series also contains PowerPC portions of the MMC SPI support.
>>>
>>> Since the series touches spi and powerpc trees, I think it would
>>> be most convenient to pass it via one of these trees. The patches
>>> doesn't touch any SPI functionality, only some probe routines, so
>>> I believe powerpc.git is the best candidate...
>>>
>>> The other reason for powerpc tree is that the patches depends on
>>> other patches as found in paulus/powerpc.git + of_gpio_count()
>>> as found here:
>>> http://ozlabs.org/pipermail/linuxppc-dev/2008-December/065917.html
>>>
>>> David, if you're OK with the patches, may I ask you to sign off on
>>> the ones that touch drivers/spi so that we could pass it via Kumar's
>>> powerpc.git?
>>>
>>> The queue:
>>>
>>> [1/7] powerpc: Implement get_brgfreq() and get_baudrate() stubs
>>> [2/7] spi_mpc83xx: Fix sparse warnings
>>> [3/7] spi_mpc83xx: Rework chip selects handling
>>> [4/7] spi_mpc83xx: Add OF platform driver bindings
>>> [5/7] powerpc/fsl_soc: Isolate legacy fsl_spi support to mpc832x_rdb
>>> boards
>>> [6/7] powerpc: Add mmc-spi-slot bindings
>>> [7/7] powerpc/83xx: Add mmc-spi support via the device tree for
>>> MPC8323E-RDB
>>>
>>
>> David,
>>
>> Any status on these patches?
>
> Ping? No single comment on this patch set for ~2 months...
>
> Resending...
>
> Thanks,
David,
Anything going on here? Should we send this via some other channel?
- k
^ permalink raw reply
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