* Re: Next April 24 : BUG: lock held at task exit time!
From: Stephen Rothwell @ 2009-04-24 14:11 UTC (permalink / raw)
To: Al Viro
Cc: peterz, LKML, Oleg Nesterov, linuxppc-dev, linux-next,
Hugh Dickins, Ingo Molnar
In-Reply-To: <20090424140445.GL8633@ZenIV.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 309 bytes --]
Hi Al,
On Fri, 24 Apr 2009 15:04:45 +0100 Al Viro <viro@ZenIV.linux.org.uk> wrote:
>
> Applied, will fold on reorder (since Ingo is asking for what will amount
> to reorder anyway).
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] [MTD] ofpart: Partitions at same address cannot have the same name v3
From: Ricardo Ribalda Delgado @ 2009-04-24 14:01 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev, David.Woodhouse, ben; +Cc: Ricardo Ribalda Delgado
Sometimes, an special partition is included in the device tree including all the
partitions. Like in:
partition@ff000000 {
reg = < 0x000000 0x800000 >;
label = "Root File System";
};
partition@ff800000 {
reg = < 0x800000 0x1a0000 >;
label = "Bitstream";
};
...
full@ff000000 {
compatible = "partition";
reg = < 0x000000 0x1000000 >;
label = "Full FLASH";
};
Because two nodes of a device tree cannot have the same name, but all the
partitions must be named "partition", this special partition is invalid.
This patch makes ofpart.c accept spetial partitions compatible with
"partition" but not named partition.
These spetial partitions are very useful for flashing the full firmware
of a device from linux
---
This v3 includes feedback from Scott Wood, Peter Korsgaard & Benjamin Kril
v3: Use the compatible propierty
v2: buggy implementation, strlen-1 instead of strlen
v1: Just check the firt part of the name
drivers/mtd/ofpart.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index 3e164f0..59c1e4a 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -48,7 +48,9 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
/* check if this is a partition node */
partname = of_get_property(pp, "name", &len);
- if (strcmp(partname, "partition") != 0) {
+ if ((strcmp(partname, "partition") != 0) &&
+ (of_device_is_compatible(pp, "partition") != 1))
+ {
nr_parts--;
continue;
}
--
1.6.2.4
^ permalink raw reply related
* Re: Next April 24 : BUG: lock held at task exit time!
From: Al Viro @ 2009-04-24 14:04 UTC (permalink / raw)
To: Hugh Dickins
Cc: Stephen Rothwell, peterz, LKML, Oleg Nesterov, linuxppc-dev,
linux-next, Ingo Molnar
In-Reply-To: <Pine.LNX.4.64.0904241249180.20196@blonde.anvils>
On Fri, Apr 24, 2009 at 12:55:44PM +0100, Hugh Dickins wrote:
> Indeed, thanks for the headsup Stephen. My own config gives, not
> Sachin's message (or not still visibly on screen anyway), but an
> outright panic. Shame that leaked out into the big world, we'd
> all have preferred a quiet fixup! Here's a patch, which I'll
> also send as reply to the relevant thread.
Applied, will fold on reorder (since Ingo is asking for what will amount
to reorder anyway).
^ permalink raw reply
* Please pull 'merge' branch of the 4xx tree
From: Josh Boyer @ 2009-04-24 13:21 UTC (permalink / raw)
To: paulus, benh; +Cc: linuxppc-dev
Hi Paul,
Please pull the following two commits for 2.6.30. One is a
trivial MAINTAINERS fix, the other fixes a bug that computes
the memory size of some 4xx boards incorrectly.
The following changes since commit 6329db8bd60fbc0832f30c350b0181b8d865573e:
Bartlomiej Zolnierkiewicz (1):
powerpc: Fix modular build of ide-pmac when mediabay is built in
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git merge
Josh Boyer (1):
maintainers: Fix PowerPC 4xx git tree
Valentine Barshak (1):
powerpc/44x: Correct memory size calculation for denali-based boards
MAINTAINERS | 2 +-
arch/powerpc/boot/4xx.c | 56 ++++++++++++++++++++++++++++++++++++-----------
2 files changed, 44 insertions(+), 14 deletions(-)
josh
^ permalink raw reply
* Re: [PATCH] i2c: i2c-ibm_iic message can be confusing
From: Josh Boyer @ 2009-04-24 13:10 UTC (permalink / raw)
To: Sean MacLennan; +Cc: Jean Delvare, linuxppc-dev, ben-linux
In-Reply-To: <20090417203600.1d0c5cf0@lappy.seanm.ca>
On Fri, Apr 17, 2009 at 08:36:00PM -0400, Sean MacLennan wrote:
>Any update on the status of this patch? This patch was acked by Jean.
>
>The patchwork entry is http://patchwork.ozlabs.org/patch/21576/ and the
>original patch message is below.
Yeah, that's a bit annoying. A case of too many trees again.
Ben,
Do you want to take this through your tree or should I take it through the
powerpc tree? I'll be up-front and say silence will translate to 'powerpc tree'
josh
>
>Cheers,
> Sean
>
>On Mon, 2 Feb 2009 12:01:59 -0500
>Sean MacLennan <smaclennan@pikatech.com> wrote:
>
>> This is a trivial patch that does not need to be in 2.6.29. While
>> tracking down an EEPROM problem, I found the messages confusing... it
>> looked like the EEPROM was being started before the I2C driver!
>>
>> Here is an example:
>>
>> at24 0-0052: 512 byte 24c04 EEPROM (writable)
>> ibm-iic ef600700.i2c: using standard (100 kHz) mode
>> ad7414 0-004a: chip found
>>
>> It looks like the at24 starts first, then the i2c driver, then the
>> ad7414. By moving the message to after the of scan, we always get the
>> driver, then the devices.
>>
>> Cheers,
>> Sean
>>
>> Print the i2c driver message before scanning for devices so that the
>> logs show the driver, then the devices. Currently you can get
>> device(s), driver, device(s).
>>
>> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
>> ---
>> diff --git a/drivers/i2c/busses/i2c-ibm_iic.c
>> b/drivers/i2c/busses/i2c-ibm_iic.c index 88f0db7..7fc0729 100644
>> --- a/drivers/i2c/busses/i2c-ibm_iic.c
>> +++ b/drivers/i2c/busses/i2c-ibm_iic.c
>> @@ -756,12 +756,12 @@ static int __devinit iic_probe(struct of_device
>> *ofdev, goto error_cleanup;
>> }
>>
>> - /* Now register all the child nodes */
>> - of_register_i2c_devices(adap, np);
>> -
>> dev_info(&ofdev->dev, "using %s mode\n",
>> dev->fast_mode ? "fast (400 kHz)" : "standard (100
>> kHz)");
>> + /* Now register all the child nodes */
>> + of_register_i2c_devices(adap, np);
>> +
>> return 0;
>>
>> error_cleanup:
>>
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Next April 24 : BUG: lock held at task exit time!
From: Hugh Dickins @ 2009-04-24 11:55 UTC (permalink / raw)
To: Stephen Rothwell
Cc: peterz, LKML, Oleg Nesterov, linuxppc-dev, linux-next, Al Viro,
Ingo Molnar
In-Reply-To: <20090424175509.561c96ad.sfr@canb.auug.org.au>
On Fri, 24 Apr 2009, Stephen Rothwell wrote:
> On Fri, 24 Apr 2009 12:25:41 +0530 Sachin Sant <sachinp@in.ibm.com> wrote:
> >
> > While booting today's next tree on a powerpc box [ power 6 blade]
> > observed the following :
> >
> > khelper used greatest stack depth: 10176 bytes left
> >
> > =====================================
> > [ BUG: lock held at task exit time! ]
> > -------------------------------------
> > khelper/21 is exiting with locks still held!
> > 2 locks held by khelper/21:
> > #0: (rcu_read_lock){.+.+.+}, at: [<c0000000001382fc>]
> > .check_unsafe_exec+0x44/0x148
> > #1: (rcu_read_lock){.+.+.+}, at: [<c000000000138368>]
> > .check_unsafe_exec+0xb0/0x148
> >
> > stack backtrace:
> > Call Trace:
> > [c000000044483cf0] [c000000000011a54] .show_stack+0x6c/0x16c (unreliable)
> > [c000000044483da0] [c00000000009ae14] .debug_check_no_locks_held+0x98/0xb4
> > [c000000044483e20] [c000000000073b1c] .do_exit+0x758/0x7b0
> > [c000000044483f00] [c0000000000853d8] .____call_usermodehelper+0x170/0x174
> > [c000000044483f90] [c00000000002bd8c] .kernel_thread+0x54/0x70
> > net_namespace: 2000 bytes
> >
> > Complete dmesg attached. Let me know if you need any other info. I will
> > try yesterday's next
> > tree to check if this problem can be recreated.
>
> Almost certainly commit 874a9e18f25c86dbc199ad32ddd9ca44d25290e8
> ("check_unsafe_exec: s/lock_task_sighand/rcu_read_lock/") which has a
> typo (two locks instead of lock/unlock) as pointed out by Hugh Dickins
> (<Pine.LNX.4.64.0904240526080.15735@blonde.anvils> on LKML).
Indeed, thanks for the headsup Stephen. My own config gives, not
Sachin's message (or not still visibly on screen anyway), but an
outright panic. Shame that leaked out into the big world, we'd
all have preferred a quiet fixup! Here's a patch, which I'll
also send as reply to the relevant thread.
[PATCH] check_unsafe_exec: rcu_read_unlock
Fix typo in previous commit: second rcu_read_lock should be rcu_read_unlock.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
---
fs/exec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 2.6.30-rc3-next-20090424/fs/exec.c 2009-04-24 12:23:43.000000000 +0100
+++ linux/fs/exec.c 2009-04-24 12:26:10.000000000 +0100
@@ -1043,7 +1043,7 @@ int check_unsafe_exec(struct linux_binpr
if (t->fs == p->fs)
n_fs++;
}
- rcu_read_lock();
+ rcu_read_unlock();
if (p->fs->users > n_fs) {
bprm->unsafe |= LSM_UNSAFE_SHARE;
^ permalink raw reply
* Re: [PATCH] [V5] Xilinx : Framebuffer Driver: Add PLB support and cleanup DCR
From: Arnd Bergmann @ 2009-04-24 11:01 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-fbdev-devel, adaplas, Suneel, akonovalov, John Linn
In-Reply-To: <20090417205119.3D35660055@mail16-sin.bigfish.com>
[-- Attachment #1: Type: text/plain, Size: 851 bytes --]
On Friday 17 April 2009, John Linn wrote:
> Added support for the new xps tft controller. The new core
> has PLB interface support in addition to existing DCR interface.
>
> Removed platform device support as both MicroBlaze and PowerPC
> use device tree.
I just said in another email thread that we would need a CONFIG_DCR
option that DCR using drivers should depend on, if it ever happened
outside of powerpc.
Well, apparently this happened earlier than I expected.
Converting the driver to use the generic DCR interface
makes it possible to use in any system that provides this
interface, including those that use a hard CPU core with xilinx_fb
on an FPGA, so it makes sense to just change the dependency
in Kconfig and provide CONFIG_DCR in microblaze (unconditionally)
as well as in powerpc instead of the existing CONFIG_PPC_DCR.
Arnd <><
[-- Attachment #2: Type: text/html, Size: 4265 bytes --]
^ permalink raw reply
* Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze
From: Arnd Bergmann @ 2009-04-24 10:49 UTC (permalink / raw)
To: linuxppc-dev
Cc: Stephen Neuendorffer, linux-kernel, microblaze-uclinux, John Linn,
John Williams
In-Reply-To: <1d3f23370904201924n4ab592cdq49a4a4c8ec78d1df@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 814 bytes --]
On Tuesday 21 April 2009, John Williams wrote:
> Some (most?) of the Xilinx drivers currently have this construct:
>
> #ifdef CONFIG_OF
>
> // probe using OF
>
> #else
If there are multiple ways of detecting the device, then
the driver should be compilable on any system that allows
either one.
At the very least, it should be restricted to CONFIG_HAS_IOMEM,
which is probably required for any of these, but not provided
on stuff like UML or s390.
Drivers that use of_* functions unconditionally need to
depend on CONFIG_OF.
Also, some of the xilinx drivers apparantly use DCR, which in turn is
only defined when you have CONFIG_PPC_DCR, and these
have so far only been used on powerpc. If other architectures
start using DCR (I hope that never happens), we will need a
global CONFIG_DCR option.
Arnd <><
[-- Attachment #2: Type: text/html, Size: 5105 bytes --]
^ permalink raw reply
* [BUG] 2.6.30-rc3: BUG triggered on some hugepage usages
From: Mel Gorman @ 2009-04-24 9:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, Linux Kernel Mailing List
In-Reply-To: <alpine.LFD.2.00.0904212014170.3101@localhost.localdomain>
On Tue, Apr 21, 2009 at 08:27:57PM -0700, Linus Torvalds wrote:
> Another week, another -rc.
>
I'm seeing some tests with sysbench+postgres+large pages fail on ppc64
although a very clear pattern is not forming as to what exactly is
causing it. However, the libhugetlbfs regression tests (make && make
func) are triggering the following oops when calling mlock() and so are
likely related.
------------[ cut here ]------------
kernel BUG at arch/powerpc/mm/pgtable.c:243!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=128 NUMA pSeries
Modules linked in: dm_snapshot dm_mirror dm_region_hash dm_log qla2xxx
loop nfnetlink iptable_filter iptable_nat nf_nat ip_tables
nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT
xt_tcpudp xt_limit ipt_LOG xt_pkttype x_tables
NIP: c00000000002becc LR: c00000000002c02c CTR: 0000000000000000
REGS: c0000000ea92b4c0 TRAP: 0700 Not tainted (2.6.30-rc3-autokern1)
MSR: 8000000000029032 <EE,ME,CE,IR,DR> CR: 28000484 XER: 20000020
TASK = c00000000395b660[7611] 'mlock' THREAD: c0000000ea928000 CPU: 3
GPR00: 0000000000000001 c0000000ea92b740 c0000000008ea170 c0000000ec7d4980
GPR04: 000000003f000000 c0000001e2278cf8 0000001900000393 0000000000000001
GPR08: f000000002bc0000 0000000000000000 0000000000000113 c0000001e2278c81
GPR12: 0000000044000482 c00000000093b880 0000000028004422 0000000000000000
GPR16: c0000000ea92bbf0 c0000000009f06f0 0000001900000113 c0000000ec7d4980
GPR20: 0000000000000000 f000000002bc0000 000000003f000000 c0000001e2278cf8
GPR24: c0000000eaa90bb0 0000000000000000 c0000000eaa90bb0 c0000000ea928000
GPR28: f000000002bc0000 0000001900000393 0000000000000001 c0000001e2278cf8
NIP [c00000000002becc] .assert_pte_locked+0x54/0x8c
LR [c00000000002c02c] .ptep_set_access_flags+0x50/0x8c
Call Trace:
[c0000000ea92b740] [c0000000eaa90bb0] 0xc0000000eaa90bb0 (unreliable)
[c0000000ea92b7d0] [c0000000000ed1b0] .hugetlb_cow+0xd4/0x654
[c0000000ea92b900] [c0000000000edbf0] .hugetlb_fault+0x4c0/0x708
[c0000000ea92b9f0] [c0000000000ee890] .follow_hugetlb_page+0x174/0x364
[c0000000ea92bae0] [c0000000000d8d30] .__get_user_pages+0x288/0x4c0
[c0000000ea92bbb0] [c0000000000da10c] .make_pages_present+0xa0/0xe0
[c0000000ea92bc40] [c0000000000db758] .mlock_fixup+0x90/0x228
[c0000000ea92bd00] [c0000000000dbb38] .do_mlock+0xc4/0x128
[c0000000ea92bda0] [c0000000000dbccc] .SyS_mlock+0xb0/0xec
[c0000000ea92be30] [c00000000000852c] syscall_exit+0x0/0x40
Instruction dump:
0b000000 78892662 79291f24 7d69582a 7d600074 7800d182 0b000000 78895e62
79291f24 7d29582a 7d200074 7800d182 <0b000000> 3c004000 3960ffff
780007c6
---[ end trace 36a7faa04fa9452b ]---
This corresponds to
#ifdef CONFIG_DEBUG_VM
void assert_pte_locked(struct mm_struct *mm, unsigned long addr)
{
pgd_t *pgd;
pud_t *pud;
pmd_t *pmd;
if (mm == &init_mm)
return;
pgd = mm->pgd + pgd_index(addr);
BUG_ON(pgd_none(*pgd));
pud = pud_offset(pgd, addr);
BUG_ON(pud_none(*pud));
pmd = pmd_offset(pud, addr);
BUG_ON(!pmd_present(*pmd)); <----- THIS LINE
BUG_ON(!spin_is_locked(pte_lockptr(mm, pmd)));
}
#endif /* CONFIG_DEBUG_VM */
This area was last changed by commit 8d30c14cab30d405a05f2aaceda1e9ad57800f36
in the 2.6.30-rc1 timeframe. I think there was another hugepage-related
problem with this patch but I can't remember what it was. Full dmesg is
==== dmesg ====
Using pSeries machine description
Page orders: linear mapping = 24, virtual = 12, io = 12, vmemmap = 24
Found initrd at 0xc000000003300000:0xc000000004b67000
console [udbg0] enabled
Partition configured for 8 cpus.
CPU maps initialized for 2 threads per core
(thread shift is 1)
Starting Linux PPC64 #1 SMP Fri Apr 24 09:08:10 UTC 2009
-----------------------------------------------------
ppc64_pft_size = 0x1b
physicalMemorySize = 0x1e8000000
htab_hash_mask = 0xfffff
-----------------------------------------------------
Initializing cgroup subsys cpuset
Linux version 2.6.30-rc3-autokern1 (root@elm3a121) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Apr 24 09:08:10 UTC 2009
[boot]0012 Setup Arch
Node 0 Memory: 0x0-0xee000000
Node 1 Memory: 0xee000000-0x1e8000000
PCI host bridge /pci@800000020000001 ranges:
IO 0x000003fe00100000..0x000003fe001fffff -> 0x0000000000000000
MEM 0x0000040080000000..0x00000400bfffffff -> 0x00000000c0000000
PCI host bridge /pci@800000020000002 ranges:
IO 0x000003fe00600000..0x000003fe006fffff -> 0x0000000000000000
MEM 0x0000040100000000..0x000004017fffffff -> 0x0000000080000000
PCI host bridge /pci@800000020000003 ranges:
IO 0x000003fe00300000..0x000003fe003fffff -> 0x0000000000000000
MEM 0x00000400c0000000..0x00000400ffffffff -> 0x00000000c0000000
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 7168 bytes
Using dedicated idle loop
Zone PFN ranges:
DMA 0x00000000 -> 0x001e8000
Normal 0x001e8000 -> 0x001e8000
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0x00000000 -> 0x000ee000
1: 0x000ee000 -> 0x001e8000
On node 0 totalpages: 974848
DMA zone: 13328 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 961520 pages, LIFO batch:31
On node 1 totalpages: 1024000
DMA zone: 14000 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 1010000 pages, LIFO batch:31
[boot]0015 Setup Done
Built 2 zonelists in Node order, mobility grouping on. Total pages: 1971520
Policy zone: DMA
Kernel command line: loglevel=8 autobench_args: root=/dev/sda3 ABAT:1240564260 loglevel=8
NR_IRQS:512
[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 = 238.060000 MHz
time_init: processor frequency = 1904.480000 MHz
clocksource: timebase mult[10cd6fc] shift[22] registered
clockevent: decrementer mult[3cf1] shift[16] cpu[0]
Console: colour dummy device 80x25
console handover: boot [udbg0] -> real [hvc0]
freeing bootmem node 0
freeing bootmem node 1
Memory: 7834904k/7995392k available (7808k kernel code, 160488k reserved, 1312k data, 1010k bss, 324k init)
SLUB: Genslabs=14, HWalign=128, Order=0-3, MinObjects=0, CPUs=8, Nodes=16
Calibrating delay loop... 475.13 BogoMIPS (lpj=950272)
Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
Mount-cache hash table entries: 256
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
irq: irq 2 on host null mapped to virtual irq 16
clockevent: decrementer mult[3cf1] shift[16] cpu[1]
Processor 1 found.
clockevent: decrementer mult[3cf1] shift[16] cpu[2]
Processor 2 found.
clockevent: decrementer mult[3cf1] shift[16] cpu[3]
Processor 3 found.
clockevent: decrementer mult[3cf1] shift[16] cpu[4]
Processor 4 found.
clockevent: decrementer mult[3cf1] shift[16] cpu[5]
Processor 5 found.
clockevent: decrementer mult[3cf1] shift[16] cpu[6]
Processor 6 found.
clockevent: decrementer mult[3cf1] shift[16] cpu[7]
Processor 7 found.
Brought up 8 CPUs
Node 0 CPUs: 0-3
Node 1 CPUs: 4-7
CPU0 attaching sched-domain:
domain 0: span 0-1 level SIBLING
groups: 0 1
domain 1: span 0-3 level CPU
groups: 0-1 2-3
domain 2: span 0-7 level NODE
groups: 0-3 (__cpu_power = 2048) 4-7 (__cpu_power = 2048)
CPU1 attaching sched-domain:
domain 0: span 0-1 level SIBLING
groups: 1 0
domain 1: span 0-3 level CPU
groups: 0-1 2-3
domain 2: span 0-7 level NODE
groups: 0-3 (__cpu_power = 2048) 4-7 (__cpu_power = 2048)
CPU2 attaching sched-domain:
domain 0: span 2-3 level SIBLING
groups: 2 3
domain 1: span 0-3 level CPU
groups: 2-3 0-1
domain 2: span 0-7 level NODE
groups: 0-3 (__cpu_power = 2048) 4-7 (__cpu_power = 2048)
CPU3 attaching sched-domain:
domain 0: span 2-3 level SIBLING
groups: 3 2
domain 1: span 0-3 level CPU
groups: 2-3 0-1
domain 2: span 0-7 level NODE
groups: 0-3 (__cpu_power = 2048) 4-7 (__cpu_power = 2048)
CPU4 attaching sched-domain:
domain 0: span 4-5 level SIBLING
groups: 4 5
domain 1: span 4-7 level CPU
groups: 4-5 6-7
domain 2: span 0-7 level NODE
groups: 4-7 (__cpu_power = 2048) 0-3 (__cpu_power = 2048)
CPU5 attaching sched-domain:
domain 0: span 4-5 level SIBLING
groups: 5 4
domain 1: span 4-7 level CPU
groups: 4-5 6-7
domain 2: span 0-7 level NODE
groups: 4-7 (__cpu_power = 2048) 0-3 (__cpu_power = 2048)
CPU6 attaching sched-domain:
domain 0: span 6-7 level SIBLING
groups: 6 7
domain 1: span 4-7 level CPU
groups: 6-7 4-5
domain 2: span 0-7 level NODE
groups: 4-7 (__cpu_power = 2048) 0-3 (__cpu_power = 2048)
CPU7 attaching sched-domain:
domain 0: span 6-7 level SIBLING
groups: 7 6
domain 1: span 4-7 level CPU
groups: 6-7 4-5
domain 2: span 0-7 level NODE
groups: 4-7 (__cpu_power = 2048) 0-3 (__cpu_power = 2048)
net_namespace: 1352 bytes
NET: Registered protocol family 16
IBM eBus Device Driver
PCI: Probing PCI hardware
IOMMU table initialized, virtual merging enabled
irq: irq 83 on host null mapped to virtual irq 83
pci 0000:c8:01.0: supports D1 D2
pci 0000:c8:01.0: PME# supported from D0 D1 D2 D3hot
pci 0000:c8:01.0: PME# disabled
pci 0000:c8:01.1: supports D1 D2
pci 0000:c8:01.1: PME# supported from D0 D1 D2 D3hot
pci 0000:c8:01.1: PME# disabled
pci 0000:c8:01.2: supports D1 D2
pci 0000:c8:01.2: PME# supported from D0 D1 D2 D3hot
pci 0000:c8:01.2: PME# disabled
irq: irq 85 on host null mapped to virtual irq 85
pci 0000:d0:01.0: PME# supported from D0 D3hot D3cold
pci 0000:d0:01.0: PME# disabled
pci 0000:d0:01.1: PME# supported from D0 D3hot D3cold
pci 0000:d0:01.1: PME# disabled
irq: irq 87 on host null mapped to virtual irq 87
irq: irq 88 on host null mapped to virtual irq 88
pci 0001:c8:01.0: supports D1 D2
pci 0001:c8:01.0: PME# supported from D0 D1 D2 D3hot
pci 0001:c8:01.0: PME# disabled
irq: irq 165 on host null mapped to virtual irq 165
irq: irq 167 on host null mapped to virtual irq 167
irq: irq 117 on host null mapped to virtual irq 117
pci 0002:d0:01.0: supports D1
irq: irq 119 on host null mapped to virtual irq 119
irq: irq 115 on host null mapped to virtual irq 115
PCI: Probing PCI hardware done
bio: create slab <bio-0> at 0
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 1
Switched to high resolution mode on CPU 2
Switched to high resolution mode on CPU 3
Switched to high resolution mode on CPU 4
Switched to high resolution mode on CPU 5
Switched to high resolution mode on CPU 6
Switched to high resolution mode on CPU 7
IP route cache hash table entries: 262144 (order: 9, 2097152 bytes)
TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 524288 bind 65536)
TCP reno registered
NET: Registered protocol family 1
checking if image is initramfs...
rootfs image is not initramfs (junk in compressed archive); looks like an initrd
Freeing initrd memory: 24988k freed
irq: irq 655360 on host null mapped to virtual irq 17
irq: irq 589825 on host null mapped to virtual irq 18
RTAS daemon started
audit: initializing netlink socket (disabled)
type=2000 audit(1240564423.424:1): initialized
HugeTLB registered 16 MB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
msgmni has been set to 15351
alg: No test for stdrng (krng)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
matroxfb: Matrox G450 detected
PInS data found at offset 31168
PInS memtype = 5
matroxfb: 640x480x8bpp (virtual: 640x26214)
matroxfb: framebuffer at 0x40170000000, mapped to 0xd000080080080000, size 33554432
Console: switching to colour frame buffer device 80x30
fb0: MATROX frame buffer device
matroxfb_crtc2: secondary head of fb0 was registered as fb1
vio_register_driver: driver hvc_console registering
HVSI: registered 0 devices
Generic RTC Driver v1.07
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
brd: module loaded
Uniform Multi-Platform E-IDE driver
ide-gd driver 1.18
ide-cd driver 5.00
ipr: IBM Power RAID SCSI Device Driver version: 2.4.2 (January 21, 2009)
ipr 0000:c0:01.0: enabling device (0140 -> 0142)
ipr 0000:c0:01.0: Found IOA with IRQ: 83
ipr 0000:c0:01.0: Initializing IOA.
ipr 0000:c0:01.0: Starting IOA initialization sequence.
ipr 0000:c0:01.0: Adapter firmware version: 020A004E
ipr 0000:c0:01.0: IOA initialized.
scsi0 : IBM 570B Storage Adapter
scsi 0:0:15:0: Enclosure IBM VSBPD3E U4SCSI 4812 PQ: 0 ANSI: 2
scsi: unknown device type 31
scsi 0:255:255:255: No Device IBM 570B001 0150 PQ: 0 ANSI: 0
ipr 0002:c8:01.0: Found IOA with IRQ: 117
ipr 0002:c8:01.0: Starting IOA initialization sequence.
ipr 0002:c8:01.0: Adapter firmware version: 020A004E
ipr 0002:c8:01.0: IOA initialized.
scsi1 : IBM 570B Storage Adapter
scsi 1:0:4:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
scsi 1:0:5:0: Direct-Access IBM ST373453LC C51A PQ: 0 ANSI: 3
scsi 1:0:15:0: Enclosure IBM VSBPD3E U4SCSI 4812 PQ: 0 ANSI: 2
scsi: unknown device type 31
scsi 1:255:255:255: No Device IBM 570B001 0150 PQ: 0 ANSI: 0
vio_register_driver: driver ibmvscsi registering
st: Version 20081215, fixed bufsize 32768, s/g segs 256
Driver 'st' needs updating - please use bus_type methods
Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
scsi 0:0:15:0: Attached scsi generic sg0 type 13
scsi 0:255:255:255: Attached scsi generic sg1 type 31
sd 1:0:4:0: Attached scsi generic sg2 type 0
sd 1:0:5:0: Attached scsi generic sg3 type 0
scsi 1:0:15:0: Attached scsi generic sg4 type 13
scsi 1:255:255:255: Attached scsi generic sg5 type 31
Intel(R) PRO/1000 Network Driver - version 7.3.21-k3-NAPI
Copyright (c) 1999-2006 Intel Corporation.
e1000 0000:d0:01.0: enabling device (0140 -> 0143)
sd 1:0:4:0: [sda] 286748000 512-byte hardware sectors: (146 GB/136 GiB)
sd 1:0:5:0: [sdb] 143374000 512-byte hardware sectors: (73.4 GB/68.3 GiB)
sd 1:0:5:0: [sdb] Write Protect is off
sd 1:0:5:0: [sdb] Mode Sense: cb 00 10 08
sd 1:0:5:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA
sdb: sdb1 sdb2 sdb3
sd 1:0:5:0: [sdb] Attached SCSI disk
sd 1:0:4:0: [sda] Write Protect is off
sd 1:0:4:0: [sda] Mode Sense: d3 00 10 08
sd 1:0:4:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
e1000: 0000:d0:01.0: e1000_probe: (PCI-X:133MHz:64-bit) 00:09:6b:dd:0d:9c
sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000 0000:d0:01.1: enabling device (0140 -> 0143)
sd 1:0:4:0: [sda] Attached SCSI disk
e1000: 0000:d0:01.1: e1000_probe: (PCI-X:133MHz:64-bit) 00:09:6b:dd:0d:9d
e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
pcnet32.c:v1.35 21.Apr.2008 tsbogend@alpha.franken.de
e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
drivers/net/ibmveth.c: ibmveth: IBM i/pSeries Virtual Ethernet Driver 1.03
vio_register_driver: driver ibmveth registering
console [netcon0] enabled
netconsole: network logging started
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci_hcd 0000:c8:01.2: enabling device (0140 -> 0142)
ehci_hcd 0000:c8:01.2: EHCI Host Controller
ehci_hcd 0000:c8:01.2: new USB bus registered, assigned bus number 1
ehci_hcd 0000:c8:01.2: Enabling legacy PCI PM
ehci_hcd 0000:c8:01.2: irq 85, io mem 0x400a0002000
ehci_hcd 0000:c8:01.2: USB 2.0 started, EHCI 1.00
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 5 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd 0000:c8:01.0: OHCI Host Controller
ohci_hcd 0000:c8:01.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:c8:01.0: irq 85, io mem 0x400a0001000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
ohci_hcd 0000:c8:01.1: OHCI Host Controller
ohci_hcd 0000:c8:01.1: new USB bus registered, assigned bus number 3
ohci_hcd 0000:c8:01.1: irq 85, io mem 0x400a0000000
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com
oprofile: using ppc64/power5 performance monitoring.
IPv4 over IPv4 tunneling driver
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
registered taskstats version 1
md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: Scanned 0 and added 0 devices.
md: autorun ...
md: ... autorun DONE.
RAMDISK: cramfs filesystem found at block 0
RAMDISK: Loading 24988KiB [1 disk] into ram disk... done.
VFS: Mounted root (cramfs filesystem) readonly on device 1:0.
Freeing unused kernel memory: 324k freed
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
nf_conntrack.acct=1 kernel paramater, acct=1 nf_conntrack module option or
sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
loop: module loaded
QLogic Fibre Channel HBA Driver: 8.03.01-k1
qla2xxx 0001:d0:01.0: enabling device (0140 -> 0143)
qla2xxx 0001:d0:01.0: Found an ISP2300, irq 167, iobase 0xd00008008001a000
qla2xxx 0001:d0:01.0: Configuring PCI space...
qla2xxx 0001:d0:01.0: Configure NVRAM parameters...
qla2xxx 0001:d0:01.0: Verifying loaded RISC code...
qla2xxx 0001:d0:01.0: firmware: requesting ql2300_fw.bin
qla2xxx 0001:d0:01.0: Firmware image unavailable.
qla2xxx 0001:d0:01.0: Firmware images can be retrieved from: ftp://ftp.qlogic.com/outgoing/linux/firmware/.
qla2xxx 0001:d0:01.0: Failed to initialize adapter
qla2xxx 0002:c0:01.0: enabling device (0140 -> 0143)
qla2xxx 0002:c0:01.0: Found an ISP2300, irq 115, iobase 0xd00008008001e000
qla2xxx 0002:c0:01.0: Configuring PCI space...
qla2xxx 0002:c0:01.0: Configure NVRAM parameters...
qla2xxx 0002:c0:01.0: Verifying loaded RISC code...
qla2xxx 0002:c0:01.0: firmware: requesting ql2300_fw.bin
qla2xxx 0002:c0:01.0: Firmware image unavailable.
qla2xxx 0002:c0:01.0: Firmware images can be retrieved from: ftp://ftp.qlogic.com/outgoing/linux/firmware/.
qla2xxx 0002:c0:01.0: Failed to initialize adapter
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with writeback data mode.
EXT3 FS on sda3, internal journal
e1000: lan0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
------------[ cut here ]------------
kernel BUG at arch/powerpc/mm/pgtable.c:243!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=128 NUMA pSeries
Modules linked in: dm_snapshot dm_mirror dm_region_hash dm_log qla2xxx loop nfnetlink iptable_filter iptable_nat nf_nat ip_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp xt_limit ipt_LOG xt_pkttype x_tables
NIP: c00000000002becc LR: c00000000002c02c CTR: 0000000000000000
REGS: c0000000ea92b4c0 TRAP: 0700 Not tainted (2.6.30-rc3-autokern1)
MSR: 8000000000029032 <EE,ME,CE,IR,DR> CR: 28000484 XER: 20000020
TASK = c00000000395b660[7611] 'mlock' THREAD: c0000000ea928000 CPU: 3
GPR00: 0000000000000001 c0000000ea92b740 c0000000008ea170 c0000000ec7d4980
GPR04: 000000003f000000 c0000001e2278cf8 0000001900000393 0000000000000001
GPR08: f000000002bc0000 0000000000000000 0000000000000113 c0000001e2278c81
GPR12: 0000000044000482 c00000000093b880 0000000028004422 0000000000000000
GPR16: c0000000ea92bbf0 c0000000009f06f0 0000001900000113 c0000000ec7d4980
GPR20: 0000000000000000 f000000002bc0000 000000003f000000 c0000001e2278cf8
GPR24: c0000000eaa90bb0 0000000000000000 c0000000eaa90bb0 c0000000ea928000
GPR28: f000000002bc0000 0000001900000393 0000000000000001 c0000001e2278cf8
NIP [c00000000002becc] .assert_pte_locked+0x54/0x8c
LR [c00000000002c02c] .ptep_set_access_flags+0x50/0x8c
Call Trace:
[c0000000ea92b740] [c0000000eaa90bb0] 0xc0000000eaa90bb0 (unreliable)
[c0000000ea92b7d0] [c0000000000ed1b0] .hugetlb_cow+0xd4/0x654
[c0000000ea92b900] [c0000000000edbf0] .hugetlb_fault+0x4c0/0x708
[c0000000ea92b9f0] [c0000000000ee890] .follow_hugetlb_page+0x174/0x364
[c0000000ea92bae0] [c0000000000d8d30] .__get_user_pages+0x288/0x4c0
[c0000000ea92bbb0] [c0000000000da10c] .make_pages_present+0xa0/0xe0
[c0000000ea92bc40] [c0000000000db758] .mlock_fixup+0x90/0x228
[c0000000ea92bd00] [c0000000000dbb38] .do_mlock+0xc4/0x128
[c0000000ea92bda0] [c0000000000dbccc] .SyS_mlock+0xb0/0xec
[c0000000ea92be30] [c00000000000852c] syscall_exit+0x0/0x40
Instruction dump:
0b000000 78892662 79291f24 7d69582a 7d600074 7800d182 0b000000 78895e62
79291f24 7d29582a 7d200074 7800d182 <0b000000> 3c004000 3960ffff 780007c6
---[ end trace 36a7faa04fa9452b ]---
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: Next April 24 : BUG: lock held at task exit time!
From: Stephen Rothwell @ 2009-04-24 7:55 UTC (permalink / raw)
To: Sachin Sant
Cc: peterz, LKML, Oleg Nesterov, linuxppc-dev, linux-next, Al Viro,
Hugh Dickins, Ingo Molnar
In-Reply-To: <49F1626D.6080102@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]
Hi Sachin,
On Fri, 24 Apr 2009 12:25:41 +0530 Sachin Sant <sachinp@in.ibm.com> wrote:
>
> While booting today's next tree on a powerpc box [ power 6 blade]
> observed the following :
>
> khelper used greatest stack depth: 10176 bytes left
>
> =====================================
> [ BUG: lock held at task exit time! ]
> -------------------------------------
> khelper/21 is exiting with locks still held!
> 2 locks held by khelper/21:
> #0: (rcu_read_lock){.+.+.+}, at: [<c0000000001382fc>]
> .check_unsafe_exec+0x44/0x148
> #1: (rcu_read_lock){.+.+.+}, at: [<c000000000138368>]
> .check_unsafe_exec+0xb0/0x148
>
> stack backtrace:
> Call Trace:
> [c000000044483cf0] [c000000000011a54] .show_stack+0x6c/0x16c (unreliable)
> [c000000044483da0] [c00000000009ae14] .debug_check_no_locks_held+0x98/0xb4
> [c000000044483e20] [c000000000073b1c] .do_exit+0x758/0x7b0
> [c000000044483f00] [c0000000000853d8] .____call_usermodehelper+0x170/0x174
> [c000000044483f90] [c00000000002bd8c] .kernel_thread+0x54/0x70
> net_namespace: 2000 bytes
>
> Complete dmesg attached. Let me know if you need any other info. I will
> try yesterday's next
> tree to check if this problem can be recreated.
Almost certainly commit 874a9e18f25c86dbc199ad32ddd9ca44d25290e8
("check_unsafe_exec: s/lock_task_sighand/rcu_read_lock/") which has a
typo (two locks instead of lock/unlock) as pointed out by Hugh Dickins
(<Pine.LNX.4.64.0904240526080.15735@blonde.anvils> on LKML).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Regarding the linkstation defconfig
From: Rogério Brito @ 2009-04-24 6:58 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, linux-mtd, linux-kernel
Hi, Guennadi, Kumar & Co.
Guennadi, since you seem to be the one responsible for the
linkstation/kurobox in the kernel, I would like to ask you a few things
that I couldn't quite understand. Please, forgive my ignorance here
while I ask you some things:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
01. why is anticipatory the default scheduler for linkstations when CFQ
is the default scheduler for the rest of the kernel?
02. since kuroboxes/linkstations are meant to store files, is there any
reason why they don't have support for large blk devs enabled by
default?
03. why is CONFIG_MIGRATION enabled in such low memory devices?
04. why is CONFIG_BLK_DEV_RAM enabled by default?
05. why is SCSI_LOWLEVEL enabled, if no device under that tree is used?
06. idem for CONFIG_NETDEV_10000.
07. idem for CONFIG_WIRELESS.
08. idem for CONFIG_HWMON.
09. idem for CONFIG_CRYPTO_HW.
10. any reason why CONFIG_VIDEO_OUTPUT_CONTROL is configured as a
module?
11. any reason why CIFS is not configured with extended attributes,
while both ext3 and nfs are?
12. wouldn't it be a good thing to enable CONFIG_PRINTK_TIME?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Perhaps similar remarks would apply to the other device that you
maintain? I forgot its name.
Again, please, forgive my ignorance here regarding the questions above.
I'm really looking for some clarification and to get things in shape
both on my systems and in the default kernel configuration, in general.
Thank you very much for your contributions, Rogério Brito.
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
^ permalink raw reply
* Next April 24 : BUG: lock held at task exit time!
From: Sachin Sant @ 2009-04-24 6:55 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: peterz, linuxppc-dev, linux-next, Ingo Molnar, LKML
In-Reply-To: <20090424150456.ff35e4ea.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]
While booting today's next tree on a powerpc box [ power 6 blade]
observed the following :
khelper used greatest stack depth: 10176 bytes left
=====================================
[ BUG: lock held at task exit time! ]
-------------------------------------
khelper/21 is exiting with locks still held!
2 locks held by khelper/21:
#0: (rcu_read_lock){.+.+.+}, at: [<c0000000001382fc>]
.check_unsafe_exec+0x44/0x148
#1: (rcu_read_lock){.+.+.+}, at: [<c000000000138368>]
.check_unsafe_exec+0xb0/0x148
stack backtrace:
Call Trace:
[c000000044483cf0] [c000000000011a54] .show_stack+0x6c/0x16c (unreliable)
[c000000044483da0] [c00000000009ae14] .debug_check_no_locks_held+0x98/0xb4
[c000000044483e20] [c000000000073b1c] .do_exit+0x758/0x7b0
[c000000044483f00] [c0000000000853d8] .____call_usermodehelper+0x170/0x174
[c000000044483f90] [c00000000002bd8c] .kernel_thread+0x54/0x70
net_namespace: 2000 bytes
Complete dmesg attached. Let me know if you need any other info. I will
try yesterday's next
tree to check if this problem can be recreated.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
[-- Attachment #2: dmesg_next0424 --]
[-- Type: text/plain, Size: 12730 bytes --]
Using pSeries machine description
Page orders: linear mapping = 16, virtual = 16, io = 12, vmemmap = 24
Using 1TB segments
Found initrd at 0xc000000003600000:0xc000000003bebc74
console [udbg0] enabled
Partition configured for 8 cpus.
CPU maps initialized for 2 threads per core
(thread shift is 1)
Starting Linux PPC64 #2 SMP Fri Apr 24 11:30:39 IST 2009
-----------------------------------------------------
ppc64_pft_size = 0x19
physicalMemorySize = 0x80000000
htab_hash_mask = 0x3ffff
-----------------------------------------------------
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.30-rc3-next-20090424 (root@mjs22lp5) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #2 SMP Fri Apr 24 11:30:39 IST 2009
[boot]0012 Setup Arch
Node 0 Memory: 0x8000000-0x46000000
Node 1 Memory: 0x0-0x8000000 0x46000000-0x80000000
EEH: No capable adapters found
PPC64 nvram contains 15360 bytes
Using shared processor idle loop
Zone PFN ranges:
DMA 0x00000000 -> 0x00008000
Normal 0x00008000 -> 0x00008000
Movable zone start PFN for each node
early_node_map[3] active PFN ranges
1: 0x00000000 -> 0x00000800
0: 0x00000800 -> 0x00004600
1: 0x00004600 -> 0x00008000
On node 0 totalpages: 15872
DMA zone: 22 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 15850 pages, LIFO batch:1
On node 1 totalpages: 16896
DMA zone: 44 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 16852 pages, LIFO batch:1
[boot]0015 Setup Done
Built 2 zonelists in Node order, mobility grouping on. Total pages: 32702
Policy zone: DMA
Kernel command line: root=/dev/sda3 sysrq=1
Experimental hierarchical RCU implementation.
RCU-based detection of stalled CPUs is enabled.
Experimental hierarchical RCU init done.
NR_IRQS:512
[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 = 512.000000 MHz
time_init: processor frequency = 4005.000000 MHz
clocksource: timebase mult[7d0000] shift[22] registered
clockevent: decrementer mult[8312] 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: 4607 kB
per task-struct memory footprint: 1920 bytes
allocated 1310720 bytes of page_cgroup
please try cgroup_disable=memory option if you don't want
freeing bootmem node 0
freeing bootmem node 1
Memory: 2035200k/2097152k available (8448k kernel code, 67136k reserved, 1216k data, 8988k bss, 448k init)
ODEBUG: 0 of 0 active objects replaced
ODEBUG: selftest passed
Calibrating delay loop... 1021.95 BogoMIPS (lpj=510976)
Security Framework initialized
SELinux: Initializing.
SELinux: Starting in permissive mode
Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes)
Mount-cache hash table entries: 4096
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
irq: irq 2 on host null mapped to virtual irq 16
Testing tracer nop: PASSED
clockevent: decrementer mult[8312] shift[16] cpu[1]
Processor 1 found.
clockevent: decrementer mult[8312] shift[16] cpu[2]
Processor 2 found.
clockevent: decrementer mult[8312] shift[16] cpu[3]
Processor 3 found.
Brought up 4 CPUs
Node 0 CPUs: 0-3
Node 1 CPUs:
CPU0 attaching sched-domain:
domain 0: span 0-1 level SIBLING
groups: 0 1
domain 1: span 0-3 level CPU
groups: 0-1 2-3
domain 2: span 0-3 level NODE
groups: 0-3 (__cpu_power = 2048)
CPU1 attaching sched-domain:
domain 0: span 0-1 level SIBLING
groups: 1 0
domain 1: span 0-3 level CPU
groups: 0-1 2-3
domain 2: span 0-3 level NODE
groups: 0-3 (__cpu_power = 2048)
CPU2 attaching sched-domain:
domain 0: span 2-3 level SIBLING
groups: 2 3
domain 1: span 0-3 level CPU
groups: 2-3 0-1
domain 2: span 0-3 level NODE
groups: 0-3 (__cpu_power = 2048)
CPU3 attaching sched-domain:
domain 0: span 2-3 level SIBLING
groups: 3 2
domain 1: span 0-3 level CPU
groups: 2-3 0-1
domain 2: span 0-3 level NODE
groups: 0-3 (__cpu_power = 2048)
khelper used greatest stack depth: 10176 bytes left
=====================================
[ BUG: lock held at task exit time! ]
-------------------------------------
khelper/21 is exiting with locks still held!
2 locks held by khelper/21:
#0: (rcu_read_lock){.+.+.+}, at: [<c0000000001382fc>] .check_unsafe_exec+0x44/0x148
#1: (rcu_read_lock){.+.+.+}, at: [<c000000000138368>] .check_unsafe_exec+0xb0/0x148
stack backtrace:
Call Trace:
[c000000044483cf0] [c000000000011a54] .show_stack+0x6c/0x16c (unreliable)
[c000000044483da0] [c00000000009ae14] .debug_check_no_locks_held+0x98/0xb4
[c000000044483e20] [c000000000073b1c] .do_exit+0x758/0x7b0
[c000000044483f00] [c0000000000853d8] .____call_usermodehelper+0x170/0x174
[c000000044483f90] [c00000000002bd8c] .kernel_thread+0x54/0x70
net_namespace: 2000 bytes
NET: Registered protocol family 16
IBM eBus Device Driver
PCI: Probing PCI hardware
PCI: Probing PCI hardware done
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NetLabel: Initializing
NetLabel: domain hash size = 128
NetLabel: protocols = UNLABELED CIPSOv4
NetLabel: unlabeled traffic allowed by default
Failed to register trace events module notifier
NET: Registered protocol family 2
IP route cache hash table entries: 16384 (order: 1, 131072 bytes)
TCP established hash table entries: 65536 (order: 4, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 5, 3670016 bytes)
TCP: Hash tables configured (established 65536 bind 65536)
TCP reno registered
NET: Registered protocol family 1
checking if image is initramfs...
rootfs image is initramfs; unpacking...
Freeing initrd memory: 6063k freed
irq: irq 655360 on host null mapped to virtual irq 17
irq: irq 655362 on host null mapped to virtual irq 18
IOMMU table initialized, virtual merging enabled
irq: irq 655364 on host null mapped to virtual irq 19
irq: irq 655365 on host null mapped to virtual irq 20
irq: irq 589825 on host null mapped to virtual irq 21
RTAS daemon started
audit: initializing netlink socket (disabled)
type=2000 audit(1240553894.305:1): initialized
Kprobe smoke test started
Kprobe smoke test passed successfully
HugeTLB registered 16 MB page size, pre-allocated 0 pages
HugeTLB registered 16 GB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 8192 (order 0, 65536 bytes)
Btrfs loaded
msgmni has been set to 3984
SELinux: Registering netfilter hooks
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
vio_register_driver: driver hvc_console registering
HVSI: registered 0 devices
Linux agpgart interface v0.103
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
brd: module loaded
Uniform Multi-Platform E-IDE driver
ide-gd driver 1.18
vio_register_driver: driver ibmvscsi registering
ibmvscsi 30000002: SRP_VERSION: 16.a
scsi0 : IBM POWER Virtual SCSI Adapter 1.5.8
ibmvscsi 30000002: partner initialization complete
ibmvscsi 30000002: sent SRP login
ibmvscsi 30000002: SRP_LOGIN succeeded
ibmvscsi 30000002: host srp version: 16.a, host partition 06-1C12A (1), OS 3, max io 262144
scsi 0:0:1:0: Direct-Access AIX VDASD 0001 PQ: 0 ANSI: 3
scsi 0:0:2:0: CD-ROM AIX VOPTA PQ: 0 ANSI: 4
ibmvfc: IBM Virtual Fibre Channel Driver version: 1.0.5 (March 19, 2009)
vio_register_driver: driver ibmvfc registering
st: Version 20081215, fixed bufsize 32768, s/g segs 256
Driver 'st' needs updating - please use bus_type methods
osst :I: Tape driver with OnStream support version 0.99.4
osst :I: $Id: osst.c,v 1.73 2005/01/01 21:13:34 wriede Exp $
Driver 'osst' needs updating - please use bus_type methods
Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.20
sd 0:0:1:0: [sda] 33554432 512-byte hardware sectors: (17.1 GB/16.0 GiB)
sd 0:0:1:0: [sda] Write Protect is off
sd 0:0:1:0: [sda] Mode Sense: 17 00 00 08
sd 0:0:1:0: [sda] Cache data unavailable
sd 0:0:1:0: [sda] Assuming drive cache: write through
sr 0:0:2:0: Attached scsi CD-ROM sr0
sd 0:0:1:0: [sda] Cache data unavailable
sd 0:0:1:0: [sda] Assuming drive cache: write through
sda:<5>sd 0:0:1:0: Attached scsi generic sg0 type 0
sr 0:0:2:0: Attached scsi generic sg1 type 5
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
uhci_hcd: USB Universal Host Controller Interface driver
mice: PS/2 mouse device common for all mice
sda1 sda2 sda3 sda4 <<6>usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
TCP bic registered
Initializing XFRM netlink socket
NET: Registered protocol family 17
registered taskstats version 1
Running tests on trace events:
Testing event kfree_skb: sda5 sda6 >
sd 0:0:1:0: [sda] Attached SCSI disk
OK
Testing event kmem_cache_free: OK
Testing event kfree: OK
Testing event kmem_cache_alloc_node: OK
Testing event kmalloc_node: OK
Testing event kmem_cache_alloc: OK
Testing event kmalloc: OK
Testing event irq_handler_exit: OK
Testing event softirq_exit: OK
Testing event softirq_entry: OK
Testing event irq_handler_entry: OK
Testing event lock_release: OK
Testing event lock_acquire: OK
Testing event sched_signal_send: OK
Testing event sched_process_fork: OK
Testing event sched_process_wait: OK
Testing event sched_process_exit: OK
Testing event sched_process_free: OK
Testing event sched_migrate_task: OK
Testing event sched_switch: OK
Testing event sched_wakeup_new: OK
Testing event sched_wakeup: OK
Testing event sched_wait_task: OK
Testing event sched_kthread_stop_ret: OK
Testing event sched_kthread_stop: OK
Running tests on trace event systems:
Testing event system skb: OK
Testing event system kmem: OK
Testing event system irq: OK
Testing event system lockdep: OK
Testing event system sched: OK
Running tests on all trace events:
Testing all events: OK
Freeing unused kernel memory: 448k freed
SysRq : Changing Loglevel
Loglevel set to 1
udevd version 128 started
scsi_id used greatest stack depth: 9104 bytes left
vol_id used greatest stack depth: 8432 bytes left
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda3, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
stty used greatest stack depth: 8096 bytes left
mount used greatest stack depth: 7504 bytes left
udevd version 128 started
drivers/net/ibmveth.c: ibmveth: IBM i/pSeries Virtual Ethernet Driver 1.03
vio_register_driver: driver ibmveth registering
IBM eHEA ethernet device driver (Release EHEA_0100)
irq: irq 590080 on host null mapped to virtual irq 256
ehea: eth2: Jumbo frames are enabled
ehea: eth2 -> logical port id #9
ehea: eth3: Jumbo frames are enabled
ehea: eth3 -> logical port id #10
modprobe used greatest stack depth: 7200 bytes left
Adding 2096320k swap on /dev/sda5. Priority:-1 extents:1 across:2096320k
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com
loop: module loaded
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda2, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
kjournald starting. Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on sda6, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
mv used greatest stack depth: 7008 bytes left
ehea: eth2: Physical port up
irq: irq 775 on host null mapped to virtual irq 263
ehea: External switch port is backup port
irq: irq 776 on host null mapped to virtual irq 264
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
modprobe used greatest stack depth: 6752 bytes left
eth2: no IPv6 routers present
less used greatest stack depth: 6336 bytes left
^ permalink raw reply
* General SPI question
From: Arnav Das @ 2009-04-24 6:28 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, Stefan Roese, spi-devel-general
[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]
Hi,
Thanks a lot and sorry for the mistakes. I have gone through the trm of the
adc as well as the omap driver. my question is that i want to interact the
adc to the board. now should i directly use the omap driver or should i mak
one of my own. if i make one of my own then i would like to know how would
the spi registers be changed by driver. should it include the omap2 driver
or is the fuctionality provided directly when i include spi.h.
another doubt: when and why is the spidev.c/h used?
i am deeply grateful towards you for helping me out
thanks
Arnav
On Fri, Apr 24, 2009 at 11:50 AM, David Brownell <david-b@pacbell.net>wrote:
> On Thursday 23 April 2009, Arnav Das wrote:
> > i am a newbie
>
> Lesson #1: make sure your Subject: lines match the message
> topic (I did a partial repair) and don't post to the wrong
> list (e.g. PPC lists for OMAP questions).
>
>
> > and am doing a project on beagle board(running
> > omap3530). i am interfacing an adc(ads7886) to the beagleboard via
> > spi. need to know how the spi works
>
> Read the ads7886 data sheet, in this case. It uses
> a subset of SPI ... no input commands, just a 12-bit
> sample returned each time chipselect pulses.
>
>
> > and how a module can access the
> > spi registers of the omap. if someones already made an adc driver can
> > they mail me?
>
> Use drivers/spi/omap2_mcspi.c on OMAP3 boards, at
> least to start with. If you want streaming conversions
> you may want to use different modes than are currently
> supported by that driver.
>
> - Dave
>
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 1983 bytes --]
^ permalink raw reply
* [PATCH 2/2] powerpc: Add 2.06 tlbie mnemonics
From: Michael Neuling @ 2009-04-24 6:24 UTC (permalink / raw)
To: Michael Neuling, Paul Mackerras, Benjamin Herrenschmidt
Cc: linuxppc-dev, Milton Miller
In-Reply-To: <1240554271.668632.486641775152.qpush@pale>
From: Milton Miller <miltonm@bga.com>
This adds the PowerPC 2.06 tlbie mnemonics and keeps backwards
compatibilty for CPUs before 2.06.
Only useful for bare metal systems.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
As they say, better out than in....
---
arch/powerpc/include/asm/cputable.h | 3 ++-
arch/powerpc/mm/hash_native_64.c | 13 +++++++++++--
2 files changed, 13 insertions(+), 3 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/include/asm/cputable.h
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/include/asm/cputable.h
+++ linux-2.6-ozlabs/arch/powerpc/include/asm/cputable.h
@@ -195,6 +195,7 @@ extern const char *powerpc_base_platform
#define CPU_FTR_SAO LONG_ASM_CONST(0x0020000000000000)
#define CPU_FTR_CP_USE_DCBTZ LONG_ASM_CONST(0x0040000000000000)
#define CPU_FTR_UNALIGNED_LD_STD LONG_ASM_CONST(0x0080000000000000)
+#define CPU_FTR_TLBIE_206 LONG_ASM_CONST(0x0100000000000000)
#ifndef __ASSEMBLY__
@@ -409,7 +410,7 @@ extern const char *powerpc_base_platform
CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
- CPU_FTR_DSCR | CPU_FTR_SAO)
+ CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_TLBIE_206)
#define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
Index: linux-2.6-ozlabs/arch/powerpc/mm/hash_native_64.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/hash_native_64.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/hash_native_64.c
@@ -38,6 +38,9 @@
static DEFINE_SPINLOCK(native_tlbie_lock);
+#define TLBIE(lp,a) \
+ stringify_in_c(.long 0x7c000264 | ((a) << 11) | ((lp) << 21))
+
static inline void __tlbie(unsigned long va, int psize, int ssize)
{
unsigned int penc;
@@ -49,14 +52,19 @@ static inline void __tlbie(unsigned long
case MMU_PAGE_4K:
va &= ~0xffful;
va |= ssize << 8;
- asm volatile("tlbie %0,0" : : "r" (va) : "memory");
+ asm volatile(ASM_FTR_IFCLR("tlbie %0,0", TLBIE(%1,%0), %2)
+ : : "r" (va), "r"(0), "i" (CPU_FTR_TLBIE_206)
+ : "memory");
break;
default:
penc = mmu_psize_defs[psize].penc;
va &= ~((1ul << mmu_psize_defs[psize].shift) - 1);
va |= penc << 12;
va |= ssize << 8;
- asm volatile("tlbie %0,1" : : "r" (va) : "memory");
+ va |= 1; /* L */
+ asm volatile(ASM_FTR_IFCLR("tlbie %0,1", TLBIE(%1,%0), %2)
+ : : "r" (va), "r"(0), "i" (CPU_FTR_TLBIE_206)
+ : "memory");
break;
}
}
@@ -80,6 +88,7 @@ static inline void __tlbiel(unsigned lon
va &= ~((1ul << mmu_psize_defs[psize].shift) - 1);
va |= penc << 12;
va |= ssize << 8;
+ va |= 1; /* L */
asm volatile(".long 0x7c000224 | (%0 << 11) | (1 << 21)"
: : "r"(va) : "memory");
break;
^ permalink raw reply
* [PATCH 0/2] powerpc: tlbie implementation PowerPC 2.06
From: Michael Neuling @ 2009-04-24 6:24 UTC (permalink / raw)
To: Michael Neuling, Paul Mackerras, Benjamin Herrenschmidt
Cc: linuxppc-dev, Milton Miller
These patches implement the new PowerPC 2.06 tlbie mnemonics
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
It's friday afternoon & I'm drinking beer, so odds are that these
patches are complete crap.
^ permalink raw reply
* [PATCH 1/2] powerpc: Enable CPU feature sections for inline asm
From: Michael Neuling @ 2009-04-24 6:24 UTC (permalink / raw)
To: Michael Neuling, Paul Mackerras, Benjamin Herrenschmidt
Cc: linuxppc-dev, Milton Miller
In-Reply-To: <1240554271.668632.486641775152.qpush@pale>
From: Milton Miller <miltonm@bga.com>
powerpc: Enable CPU feature sections for inline asm
This adds the ability to do CPU feature sections for inline asm.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/include/asm/feature-fixups.h | 25 ++++++++++++++++++++-----
1 file changed, 20 insertions(+), 5 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/include/asm/feature-fixups.h
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/include/asm/feature-fixups.h
+++ linux-2.6-ozlabs/arch/powerpc/include/asm/feature-fixups.h
@@ -8,8 +8,6 @@
* 2 of the License, or (at your option) any later version.
*/
-#ifdef __ASSEMBLY__
-
/*
* Feature section common macros
*
@@ -23,10 +21,12 @@
/* 64 bits kernel, 32 bits code (ie. vdso32) */
#define FTR_ENTRY_LONG .llong
#define FTR_ENTRY_OFFSET .long 0xffffffff; .long
+#elif defined(CONFIG_PPC64)
+#define FTR_ENTRY_LONG .llong
+#define FTR_ENTRY_OFFSET .llong
#else
-/* 64 bit kernel 64 bit code, or 32 bit kernel 32 bit code */
-#define FTR_ENTRY_LONG PPC_LONG
-#define FTR_ENTRY_OFFSET PPC_LONG
+#define FTR_ENTRY_LONG .long
+#define FTR_ENTRY_OFFSET .long
#endif
#define START_FTR_SECTION(label) label##1:
@@ -141,6 +141,21 @@ label##5: \
#define ALT_FW_FTR_SECTION_END_IFCLR(msk) \
ALT_FW_FTR_SECTION_END_NESTED_IFCLR(msk, 97)
+#ifndef __ASSEMBLY__
+
+#define ASM_FTR_IF_X(string, estring, msk, val) \
+ stringify_in_c(BEGIN_FTR_SECTION) \
+ string "; " \
+ stringify_in_c(FTR_SECTION_ELSE) \
+ estring "; " \
+ stringify_in_c(ALT_FTR_SECTION_END((msk), (val)))
+
+#define ASM_FTR_IFSET(string, estring, msk) \
+ ASM_FTR_IF_X(string, estring, (msk), (msk))
+
+#define ASM_FTR_IFCLR(string, estring, msk) \
+ ASM_FTR_IF_X(string, estring, (msk), 0)
+
#endif /* __ASSEMBLY__ */
/* LWSYNC feature sections */
^ permalink raw reply
* Re: general SPI question (WAS: [PATCH v6] spi: Add PPC4xx SPI driver)
From: David Brownell @ 2009-04-24 6:20 UTC (permalink / raw)
To: Arnav Das; +Cc: linuxppc-dev, Stefan Roese, spi-devel-general
In-Reply-To: <8ee9e87c0904232032sc7ef5e7ibf058618fca8c1a0@mail.gmail.com>
On Thursday 23 April 2009, Arnav Das wrote:
> i am a newbie
Lesson #1: make sure your Subject: lines match the message
topic (I did a partial repair) and don't post to the wrong
list (e.g. PPC lists for OMAP questions).
> and am doing a project on beagle board(running
> omap3530). i am interfacing an adc(ads7886) to the beagleboard via
> spi. need to know how the spi works
Read the ads7886 data sheet, in this case. It uses
a subset of SPI ... no input commands, just a 12-bit
sample returned each time chipselect pulses.
> and how a module can access the
> spi registers of the omap. if someones already made an adc driver can
> they mail me?
Use drivers/spi/omap2_mcspi.c on OMAP3 boards, at
least to start with. If you want streaming conversions
you may want to use different modes than are currently
supported by that driver.
- Dave
^ permalink raw reply
* Re: MPC8349E's DMA controller like ISA controller but with more feature?
From: lhthanh @ 2009-04-24 6:12 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <49F08FBC.9010903@freescale.com>
Thank Scott and Timur!
> Scott Wood wrote:
>
>> Timur Tabi (CCed) has written an audio
>> driver that does something very similar; he could probably tell you more
>> about how to do that (this is why such discussions should be kept on the
>> mailing list rather than taken to private e-mail).
>>
>
> The code in drivers/dma cannot be used to send a buffer of data to a
> single I/O port. That code is just an elaborate version of memcpy that
> uses the DMA engine to copy data in the background.
>
>
Thanks for your explaination! So if I want to transfer a buffer of data
from a single I/O port, will not DMA framework
also be able ? Have I to write aother driver?
> If you want to transfer a buffer to a single I/O port, you will need to
> write your own DMA driver, similar to what I've done in
> sound/soc/fsl/fsl_dma.c. This is not trivial. You will need to
> understand the DMA hardware programming model to determine whether you
> can use direct mode or if you need to create link descriptors.
>
>
Actually, I don't want write all because there are serveral DMA code at
hand. I only want to use a framework instead of re-writing.
And I afraid that I can not write code which assure sharing DMA channels.
Regards!
^ permalink raw reply
* Re: Fedora on the ibm power 275
From: Tony Breeds @ 2009-04-24 5:05 UTC (permalink / raw)
To: Freeman Wiser; +Cc: linuxppc-dev
In-Reply-To: <20090424000453.C92837BD5A@ws5-10.us4.outblaze.com>
On Fri, Apr 24, 2009 at 01:04:53AM +0100, Freeman Wiser wrote:
> Hey I saw that Jim installed Fedora on the 275, can you tell me how? I just
> bought one of the 275s and am not really ibm savvy, and was going to sell it
> when I came across Jim's post here:
>
> http://lists.infradead.org/pipermail/fedora-ppc/2008-November/001114.html
Hmm didn't know that list existed.
Basially grabbibng the DVD or boot.iso for Fedora-10 should "just work".
having said that I haven't tried it.
Yours Tony
^ permalink raw reply
* Re: [PATCH] PowerPC 44x: ibm4xx_denali_fixup_memsize fix
From: Stefan Roese @ 2009-04-24 4:23 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090423205506.GA2962@ru.mvista.com>
On Thursday 23 April 2009, Valentine Barshak wrote:
> Some U-Boot versions incorrectly set the number of chipselects to two
> for Sequoia/Rainier boards while they only have one chipselect hardwired.
> This patch adds a workaround for this, hardcoding the number of chipselects
> to one for sequioa/rainer board models and reading the actual value from
> the memory controller register DDR0_10 otherwise.
> It also fixes another error in the way ibm4xx_denali_fixup_memsize
> calculates memory size. When testing the DDR_REDUC bit, the polarity is
> backwards. A "1" implies 32-bit wide memory while a "0" implies 64-bit
> wide memory.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> Signed-off-by: Steven A. Falco <sfalco@harris.com>
Acked-by: Stefan Roese <sr@denx.de>
Thanks.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 1/6] powerpc: Move #ifdef'ed body of do_IRQ() into a separate function
From: Michael Ellerman @ 2009-04-24 3:39 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20090423164917.GA20190@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 358 bytes --]
On Thu, 2009-04-23 at 11:49 -0500, Scott Wood wrote:
> On Thu, Apr 23, 2009 at 11:31:37AM +1000, Michael Ellerman wrote:
> > + handler = desc->handler;
>
> Should be desc->handle_irq. It's fixed in a later patch, but this breaks
> bisect.
Ah crud, thanks for spotting it. That's an artifact of me reordering the
patches. Will resend.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [spi-devel-general] [PATCH v6] spi: Add PPC4xx SPI driver
From: Arnav Das @ 2009-04-24 3:32 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, Stefan Roese, spi-devel-general
In-Reply-To: <200904221300.39747.david-b@pacbell.net>
Hi
i am a newbie and am doing a project on beagle board(running
omap3530). i am interfacing an adc(ads7886) to the beagleboard via
spi. need to know how the spi works and how a module can access the
spi registers of the omap. if someones already made an adc driver can
they mail me?
thanks
arnav
On 4/23/09, David Brownell <david-b@pacbell.net> wrote:
> On Thursday 08 January 2009, Stefan Roese wrote:
>> This adds a SPI driver for the SPI controller found in the IBM/AMCC
>> 4xx PowerPC's.
>
>
>> +/*
>> + * The PPC4xx SPI controller has no FIFO so each sent/received byte will
>> + * generate an interrupt to the CPU. This can cause high CPU utilization.
>> + * This driver allows platforms to reduce the interrupt load on the CPU
>> + * during SPI transfers by setting max_speed_hz via the device tree.
>
> Note that an alternate strategy is to use polling instead of IRQs,
> at least when the data rate is high enough that the IRQ processing
> is also slowing down the data transfers.
>
>
>> +/* bits in mode register - bit 0 ist MSb */
>> +/* data latched on leading edge of clock, else trailing edge */
>> +#define SPI_PPC4XX_MODE_SCP (0x80 >> 3)
>
> Or in short, SCP == CPHA.
>
>> +/* port enabled */
>> +#define SPI_PPC4XX_MODE_SPE (0x80 >> 4)
>> +/* MSB first, else LSB first */
>> +#define SPI_PPC4XX_MODE_RD (0x80 >> 5)
>> +/* clock invert - idle clock = 1, active clock = 0; else reversed */
>> +#define SPI_PPC4XX_MODE_CI (0x80 >> 6)
>
> Or in short, CI == CPOL.
>
>> +/* loopback enable */
>> +#define SPI_PPC4XX_MODE_IL (0x80 >> 7)
>> +/* bits in control register */
>> +/* starts a transfer when set */
>> +#define SPI_PPC4XX_CR_STR (0x80 >> 7)
>> +/* bits in status register */
>> +/* port is busy with a transfer */
>> +#define SPI_PPC4XX_SR_BSY (0x80 >> 6)
>> +/* RxD ready */
>> +#define SPI_PPC4XX_SR_RBR (0x80 >> 7)
>> +
>> +/* the spi->mode bits understood by this driver: */
>> +#define MODEBITS (SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | SPI_LSB_FIRST)
>> +
>> +/* clock settings (SCP and CI) for various SPI modes */
>> +#define SPI_CLK_MODE0 SPI_PPC4XX_MODE_SCP
>> +#define SPI_CLK_MODE1 0
>> +#define SPI_CLK_MODE2 SPI_PPC4XX_MODE_CI
>> +#define SPI_CLK_MODE3 (SPI_PPC4XX_MODE_SCP | SPI_PPC4XX_MODE_CI)
>
> Color me puzzled then. Either the definitions of MODE0 and MODE1
> are swapped here ... or the comments above are wrong, and SCP should
> describe "falling" vs "rising" instead of "leading" vs "trailing".
>
>
>> +static int spi_ppc4xx_setupxfer(struct spi_device *spi, struct
>> spi_transfer *t)
>> +{
>> + struct ppc4xx_spi *hw = spi_master_get_devdata(spi->master);
>> + struct spi_ppc4xx_cs *cs = spi->controller_state;
>> + int scr;
>> + u8 cdm = 0;
>> + u32 speed;
>> + u8 bits_per_word;
>> +
>> + bits_per_word = (t) ? t->bits_per_word : spi->bits_per_word;
>> + speed = (t) ? t->speed_hz : spi->max_speed_hz;
>> +
>> + ...
>> +
>> + if (!speed || (speed > spi->max_speed_hz)) {
>
> This is wrong. Typical case is that t->speed_hz is zero,
> meaning "use spi->max_speed_hz" ... you treat that as an error.
>
>> + dev_err(&spi->dev, "invalid speed_hz (%d)\n", speed);
>> + return -EINVAL;
>> + }
>> +
>> + ...
>> +}
>> +
>> +static int spi_ppc4xx_setup(struct spi_device *spi)
>> +{
>> + int ret;
>> + struct spi_ppc4xx_cs *cs = spi->controller_state;
>> + int init = 0;
>
> This "init" thing is still wrong.
>
> Consider: board gets set up with one device. Later,
> *WHILE BUSY TRANSFERRING DATA TO/FROM THAT DEVICE*
> some other device gets instantiated. Then ...
>
>
>> + if (cs == NULL) {
>> + cs = kzalloc(sizeof *cs, GFP_KERNEL);
>> + if (!cs)
>> + return -ENOMEM;
>> + spi->controller_state = cs;
>> +
>> + /*
>> + * First time called, so let's init the SPI controller
>> + * at the end of this function
>> + */
>> + init = 1;
>
> "init" becomes true here, although the controller has
> already been initialized. If it needs to be set up,
> do it in probe() before registering the spi_master.
>
>
>> + }
>> +
>> + ...
>> +
>> + /*
>> + * New configuration (mode, speed etc) will be written to the
>> + * controller in spi_ppc4xx_setupxfer(). Only call
>> + * spi_ppc4xx_setupxfer() directly upon first initialization.
>> + */
>> + if (init) {
>> + ret = spi_ppc4xx_setupxfer(spi, NULL);
>
> ... so blam, you clobber the settings currently being used for
> the active transfer. So this would be a bug.
>
> If not ... this driver deserves a comment on exactly how
> unusual this driver is. Specifically, that all spi_device
> children must be set up *in advance* so that standard calls
> like spi_new_device() don't work with it; and why.
>
> I don't think I see anything in this driver which would
> prevent that from working, though. Sure you've got to
> have a list of chipselect GPIOs in advance, but that's
> distinct from being unable to use spi_new_device().
>
>
>> + ...
>> +}
>> +
>> +static void spi_ppc4xx_chipsel(struct spi_device *spi, int value)
>> +{
>> + struct ppc4xx_spi *hw = spi_master_get_devdata(spi->master);
>> + unsigned int cspol = spi->mode & SPI_CS_HIGH ? 1 : 0;
>> + unsigned int cs = spi->chip_select;
>> +
>> + if (!hw->num_gpios)
>> + return;
>
> Hmm, num_gpios ... can never be zero, right? You always
> set it up so that of_gpio_count() GPIOs can all be used
> as chipselects. Looks like this check is not needed.
>
>> +
>> + if (cs >= hw->num_gpios)
>> + return;
>
> I guess I don't see why you have num_gpio instead of just
> using the chipselect count, either. (Assuming that the
> of_gpio_count routine isn't counting *all* gpios, instead
> of just ones allocated to this controller, which would be
> a different issue.)
>
>
>> +
>> + if (value != BITBANG_CS_INACTIVE && value != BITBANG_CS_ACTIVE)
>> + return;
>
> Strange, what other values could be passed??
>
>
>> +
>> + if (value == BITBANG_CS_INACTIVE)
>> + cspol = !cspol;
>> +
>> + gpio_set_value(hw->gpios[cs], cspol);
>> +}
>> +
>> +static irqreturn_t spi_ppc4xx_int(int irq, void *dev_id)
>> +{
>> + struct ppc4xx_spi *hw;
>> + u8 status;
>> + u8 data;
>> + unsigned int count;
>> +
>> + hw = (struct ppc4xx_spi *)dev_id;
>> +
>> + status = in_8(&hw->regs->sr);
>> + if (!status)
>> + return IRQ_NONE;
>> +
>> + /* should never happen but check anyway */
>> + if (status & SPI_PPC4XX_SR_BSY) {
>
> Maybe "if (unlikely(...)) {" then.
>
>
>> + u8 lstatus;
>> + int cnt = 0;
>> +
>> + dev_dbg(hw->dev, "got interrupt but spi still busy?\n");
>
> But ... *does* this ever happen? If not, I'd strike this
> code. And if it does, I'd add a comment explaining what's
> known about this hardware bug. Without this, the IRQ handler
> would look pretty tight.
>
>> + do {
>> + ndelay(10);
>> + lstatus = in_8(&hw->regs->sr);
>> + } while (++cnt < 100 && lstatus & SPI_PPC4XX_SR_BSY);
>> +
>> + if (cnt >= 100) {
>> + dev_err(hw->dev, "busywait: too many loops!\n");
>> + complete(&hw->done);
>> + return IRQ_HANDLED;
>> + } else {
>> + /* status is always 1 (RBR) here */
>> + status = in_8(&hw->regs->sr);
>> + dev_dbg(hw->dev, "loops %d status %x\n", cnt, status);
>> + }
>> + }
>> +
>> + count = hw->count;
>> + hw->count++;
>> +
>> + if (status & SPI_PPC4XX_SR_RBR) {
>> + /* Data Ready */
>
> Most SPI hardware I've seen has at most a weak distinction
> between "tx done" and "rx done" IRQs ... there's little
> point to separate IRQs, since shifting out the last TX bit
> is what shifts in the last RX bit.
>
> Unless this is unusual hardware you can probably just assume
> that there's RX data, and only read it if hw->rx is non-null.
> Or, if this is *not* set, report the odd behavior...
>
>
>> + data = in_8(&hw->regs->rxd);
>> + if (hw->rx)
>> + hw->rx[count] = data;
>> + }
>> +
>> + count++;
>> +
>> + if (count < hw->len) {
>> + data = hw->tx ? hw->tx[count] : 0;
>> + out_8(&hw->regs->txd, data);
>> + out_8(&hw->regs->cr, SPI_PPC4XX_CR_STR);
>> + } else {
>> + complete(&hw->done);
>> + }
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> + ...
>> +
>
>> +static int __init spi_ppc4xx_of_probe(struct of_device *op,
>> + const struct of_device_id *match)
>> +{
>> + struct ppc4xx_spi *hw;
>> + struct spi_master *master;
>> + struct spi_bitbang *bbp;
>> + struct resource resource;
>> + struct device_node *np = op->node;
>> + struct device *dev = &op->dev;
>> + struct device_node *opbnp;
>> + int ret;
>> + const unsigned int *clk;
>> +
>> + master = spi_alloc_master(dev, sizeof *hw);
>> + if (master == NULL)
>> + return -ENOMEM;
>> + dev_set_drvdata(dev, master);
>> + hw = spi_master_get_devdata(master);
>> + memset(hw, 0, sizeof(struct ppc4xx_spi));
>
> That memset is not required, it comes to you pre-zeroed.
>
>> +
>> + hw->master = spi_master_get(master);
>> + hw->dev = dev;
>> +
>> + init_completion(&hw->done);
>> +
>> + hw->num_gpios = of_gpio_count(np);
>
> Worth a comment what's going on there. I'm assuming this
> of_gpio_count() thing returns a count of GPIOs somehow
> associated with this specific device tree node, rather than
> say all GPIOs known to the device tree...
>
>> + if (hw->num_gpios) {
>> + int i;
>> +
>> + hw->gpios = kzalloc(sizeof(int) * hw->num_gpios,
>> + GFP_KERNEL);
>> + if (!hw->gpios) {
>> + ret = -ENOMEM;
>> + goto free_master;
>> + }
>> +
>> + for (i = 0; i < hw->num_gpios; i++) {
>> + int gpio = of_get_gpio(np, i);
>> + if (gpio < 0) {
>> + dev_err(dev, "Invalid gpio spec %d\n", i);
>> + ret = gpio;
>> + goto free_gpios;
>> + }
>> +
>> + ret = gpio_request(gpio, np->name);
>> + if (ret < 0) {
>> + dev_err(dev, "gpio %d already in use\n", i);
>> + ret = gpio;
>> + goto free_gpios;
>> + }
>> +
>> + gpio_direction_output(gpio, 0);
>> + hw->gpios[i] = gpio;
>> + }
>> + }
>
> Else ... error, if there are no chipselects?
>
> I've got a patch pending to add a "no chipselect" spi->mode flag.
> If you expect to support that, please let me know.
>
>
>> +
>> + /* Setup the state for the bitbang driver */
>> + bbp = &hw->bitbang;
>> + bbp->master = hw->master;
>> + bbp->setup_transfer = spi_ppc4xx_setupxfer;
>> + bbp->chipselect = spi_ppc4xx_chipsel;
>> + bbp->txrx_bufs = spi_ppc4xx_txrx;
>> + bbp->use_dma = 0;
>> + bbp->master->setup = spi_ppc4xx_setup;
>> + bbp->master->cleanup = spi_ppc4xx_cleanup;
>> + /* only one SPI controller */
>> + bbp->master->bus_num = 0;
>
> Bad assumption. There could be GPIO-based adapters,
> of course. And aren't these the cores which can be
> found on higher end Xilinx FPGAs? And, accordingly,
> integrated with any number of additional controllers?
>
> If so, the restriction is just that this controller
> be bus #0. If not ... the Kconfig should say more
> about *which* PPC4xx chips have this controller.
> (I suspect it's the latter.)
>
>
>> + if (bbp->master->num_chipselect == 0) {
>
> You didn't set it, so of course it's still zeroed.
>
>
>> + /* this many pins in al GPIO controllers */
>> + bbp->master->num_chipselect = hw->num_gpios;
>
> So num_chipselect is alays num_gpios, and there's no point
> to having num_gpios since you could always use num_chipselect.
>
>
>> + }
>> +
>> + ...
>> +}
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> spi-devel-general mailing list
> spi-devel-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/spi-devel-general
>
^ permalink raw reply
* Enable Serial Management Controller (SMC) in MPC8265
From: Andres F Marquez @ 2009-04-23 23:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nirmala Kakkuppi, Haysam Rachid
Hello,
I am working with a MPC8265 processor for which I am compiling a
Kernel using LTIB. I just came to a point in my project in which I need
an additional serial port to interface my CPU with a FPGA. Since my
UTOPIA interface is using several serial ports -pins, the only option
that I find available is to use a Serial Management Controller (SMC)
port (SMC1 or SMC2).
I enabled SCC1 (for the console) and SMC2 through the Kernel
(2.6.25) configuration tool using LTIB. I am able to run my system and
execute minicom to try to configure the needed serial port. I have not
been able to find the tty port that refers to either one of the two SMC
ports. I have tried all the tty's that I get when I do ls /dev/tty* but
none of them seem to work. Below, I provide the list of tty's that I am
getting. ttyCPM0 is being used for the console. ttyCPM1 is the only one
that I am allowed to configure through minicom (for the rest it says
device not found). But even after configuring ttyCPM1 I don't see
anything through the serial lines.
-sh-2.05b# ls /dev/tty*
Using fallback suid method
/dev/tty /dev/tty7 /dev/ttyP1 /dev/ttyPSC5 /dev/ttyp3
/dev/tty0 /dev/ttyAM0 /dev/ttyP2 /dev/ttyS0 /dev/ttyp4
/dev/tty1 /dev/ttyAM1 /dev/ttyP3 /dev/ttyS1 /dev/ttyp5
/dev/tty2 /dev/ttyAM2 /dev/ttyPSC0 /dev/ttyS2 /dev/ttyp6
/dev/tty3 /dev/ttyAM3 /dev/ttyPSC1 /dev/ttyS3 /dev/ttyp7
/dev/tty4 /dev/ttyCPM0 /dev/ttyPSC2 /dev/ttyp0 /dev/ttyp8
/dev/tty5 /dev/ttyCPM1 /dev/ttyPSC3 /dev/ttyp1 /dev/ttyp9
/dev/tty6 /dev/ttyP0 /dev/ttyPSC4 /dev/ttyp2
-sh-2.05b#
I am not sure how to know which one of them belongs to the SMC serial
controllers.
After doing some research online, I added an entry in my
mpc8272ads.dts file for the smc serial controller. Below, I provide the
entries for the serial ports (one SCC1 and one SMC2):
serial@11a00 {
device_type = "serial";
compatible = "fsl,mpc8280-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a00 20 8000 100>;
interrupts = <28 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <2>;
fsl,cpm-command = <00800000>;
};
serial@11a92 {
device_type = "serial";
compatible = "fsl,mpc8280-smc-uart",
"fsl,cpm2-smc-uart";
reg = <11a92 20 88fc 2>;
interrupts = <5 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <2>;
fsl,cpm-command = <21200000>;
};
I am kind of confused about what I could be missing in order to use
the SMC. I don't even need it to be UART. I just need a serial interface
for a FPGA which I am programming. One thing in which I was successful
was in configuring in uboot the console to run in the SMC2 port -instead
of the default which is SCC1 (I was able to boot uboot and the kernel
through the SMC2 serial port -using NFS). However, I need in my system
both enable (SCC1 and SMC2). I have not been able to do that. I am not
sure if it is possible or not. I have made a lot of changes in the .dts
file but have not been successful. For some reason in uboot, it seems
like the configurations for SCC1 and SMC2 are exclusive. They depend on
where the console is configured (SCC1 or SMC2). Either one can be
configured, but not both at the same time (at least based on uboot
configuration definitions. They are within if's and elif's...). As I
said before, both of them are able to run the console.
Thank you in advance for any help.
Bye.
ANDRES
^ permalink raw reply
* Fedora on the ibm power 275
From: Freeman Wiser @ 2009-04-24 0:04 UTC (permalink / raw)
To: linuxppc-dev
Hey I saw that Jim installed Fedora on the 275, can you tell me how? I jus=
t bought one of the 275s and am not really ibm savvy, and was going to sell=
it when I came across Jim's post here:
http://lists.infradead.org/pipermail/fedora-ppc/2008-November/001114.html
Geoff Levand recommended posting here.
Regards Freeman
--=20
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com
Powered by Outblaze
^ permalink raw reply
* Re: PCI changes 2.6.26 => 2.6.28
From: Gary Thomas @ 2009-04-23 22:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <97DF2A19-563D-404A-AD3D-039D5989E489@kernel.crashing.org>
Kumar Gala wrote:
>
> On Apr 23, 2009, at 9:24 AM, Gary Thomas wrote:
>
>> I have found the culprit - in arch/powerpc/kernel/pci_32.c
>>
>> static void
>> fixup_hide_host_resource_fsl(struct pci_dev *dev)
>> {
>> int i, class = dev->class >> 8;
>>
>> #if 0
>> if ((class == PCI_CLASS_PROCESSOR_POWERPC ||
>> class == PCI_CLASS_BRIDGE_OTHER) &&
>> #else
>> if ((class == PCI_CLASS_PROCESSOR_POWERPC) &&
>> #endif
>> (dev->hdr_type == PCI_HEADER_TYPE_NORMAL) &&
>> (dev->bus->parent == NULL)) {
>> for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
>> dev->resource[i].start = 0;
>> dev->resource[i].end = 0;
>> dev->resource[i].flags = 0;
>> }
>> }
>> }
>> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MOTOROLA, PCI_ANY_ID,
>> fixup_hide_host_resource_fsl);
>> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID,
>> fixup_hide_host_resource_fsl);
>>
>> This function is now (the #if 0 case is in 2.6.28) tossing out
>> the memory resources used by the PCI bridge itself. This makes
>> everything fall over, at least on my 834x platform.
>>
>> This change was applied 2008-10-08, but it seems incorrect on the 834x.
>
> Its not. The PCI subsystem shouldn't be allocating or seeing the PHBs
> resources.
>
>>> Are you using u-boot to boot? If so is the board port public?
>>
>> My systems use RedBoot (I'm the original author of RedBoot, so one would
>> expect that). At this moment, the code isn't public, sorry.
>
> Ok. Not sure if RedBoot has a simple memory dump command, but if you
> can dump the IMMR registers for PCI (0x8400 - IOS and 0x8500 - PCI1).
> (I'm assuming PCI1 is the one you are using). From IOS I wanted the
I don't think any of this matters. It turns out that even
the 2.6.26 kernel fails on an identical board with a newer
revision of the 8347 chip. I'm sure that the problem is
that the Coral-P fails when mapped to 0 (PCI relative).
I couldn't find another reliable way to get the Coral-P assigned
an address other than 0, so I'm happy accepting the work around
of allowing the kernel to map those windows, even if it's not
necessary.
For completeness, here are the values you asked for:
pcilawbar0 : 0xc0000000 -1073741824
pcilawar : 0x8000001b -2147483621
pcilawbar1 : 0xb8000000 -1207959552
pcilawar1 : 0x80000013 -2147483629
8347>md 0xff008400
ff008400 : 00000000 00000000 000c0000 00000000 ................
ff008410 : 800f0000 00000000 00000000 00000000 ................
ff008420 : 000b8000 00000000 c00fff00 00000000 ................
ff008430 : 00000000 00000000 00000000 00000000 ................
ff008440 : 00000000 00000000 00000000 00000000 ................
ff008450 : 00000000 00000000 00000000 00000000 ................
ff008460 : 00000000 00000000 00000000 00000000 ................
ff008470 : 00000000 00000000 00000000 00000000 ................
ff008480 : 00000000 00000000 00000000 00000000 ................
ff008490 : 00000000 00000000 00000000 00000000 ................
ff0084a0 : 00000000 00000000 00000000 00000000 ................
ff0084b0 : 00000000 00000000 00000000 00000000 ................
ff0084c0 : 00000000 00000000 00000000 00000000 ................
ff0084d0 : 00000000 00000000 00000000 00000000 ................
ff0084e0 : 00000000 00000000 00000000 00000000 ................
ff0084f0 : 00000001 00010006 00000000 00000000 ................
8347>md 0xff008500
ff008500 : 00000000 00000000 00000000 00000000 ................
ff008510 : 00000000 00000000 00000000 00000000 ................
ff008520 : 00000001 00000000 00000001 00000000 ................
ff008530 : 00000000 00000000 00000000 00000000 ................
ff008540 : 00000000 00000000 00000000 00000000 ................
ff008550 : 00000000 00000000 00000000 00000000 ................
ff008560 : a005501a 00000000 00000000 00000000 ..P.............
ff008570 : 00000000 00000000 00000000 00000000 ................
ff008580 : 00000000 00000000 00000000 00000000 ................
ff008590 : 00000000 00000000 00000000 00000000 ................
ff0085a0 : 00000000 00000000 00000000 00000000 ................
ff0085b0 : 00000000 00000000 00000000 00000000 ................
ff0085c0 : 00000000 00000000 00000000 00000000 ................
ff0085d0 : 00000000 00000000 00000000 00000000 ................
ff0085e0 : 00000000 00000000 00000000 00000000 ................
ff0085f0 : 00000000 00000000 00000000 00000000 ................
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ 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