* Re: PPC upstream kernel ignored DABR bug
From: Jan Kratochvil @ 2007-11-28 8:59 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras, Roland McGrath
In-Reply-To: <200711272335.36981.arnd@arndb.de>
On Tue, 27 Nov 2007 23:35:36 +0100, Arnd Bergmann wrote:
> On Monday 26 November 2007, Jan Kratochvil wrote:
> > Hi,
> >
> > this testcase:
> > http://people.redhat.com/jkratoch/dabr-lost.c
> >
> > reproduces a PPC DABR kernel bug. The variable `variable' should not get
> > modified as the thread modifying it should be caught by its DABR:
> >
> > $ ./dabr-lost
> > TID 30914: DABR 0x10012a77 NIP 0x80f6ebb318
> > TID 30915: DABR 0x10012a77 NIP 0x80f6ebb318
> > TID 30916: DABR 0x10012a77 NIP 0x80f6ebb318
> > TID 30914: hitting the variable
> > TID 30915: hitting the variable
> > TID 30916: hitting the variable
> > variable found = 30916, caught TID = 30914
> > TID 30916: DABR 0x10012a77
> > Variable got modified by a thread which has DABR still set!
> >
>
> This sounds like a bug recently reported by Uli Weigand. BenH
> said he'd take a look, but it probably fell under the table.
> The problem found by Uli is that on certain processors (Cell/B.E.
> in his case), the DABRX register needs to be set in order for
> the DABR to take effect.
Please be aware DABR works fine if the same code runs just 1 (always) or
2 (sometimes) threads. It starts failing with too many threads running:
$ ./dabr-lost
TID 32725: DABR 0x1001279f NIP 0xfecf41c
TID 32726: DABR 0x1001279f NIP 0xfecf41c
TID 32725: hitting the variable
variable found = -1, caught TID = 32725
TID 32726: hitting the variable
variable found = -1, caught TID = 32726
The kernel bug did not get reproduced - increase THREADS.
As I did not find any code in that kernel touching DABRX its value should not
be dependent on the number of threads running.
Regards,
Lace
^ permalink raw reply
* Re: Device tree and /proc/iomem question
From: Kumar Gala @ 2007-11-28 7:02 UTC (permalink / raw)
To: robert lazarski; +Cc: linuxppc-embedded
In-Reply-To: <f87675ee0711261026k65d2d4e3pe74697abbc39930e@mail.gmail.com>
On Nov 26, 2007, at 12:26 PM, robert lazarski wrote:
> Hi all, I'm using a recent pull of the paulus tree 2.6.24RC2 on my
> custom 85xx board. I'm trying to test my PCI1, PCI2 and PCIe . My
> device tree for PCI is:
>
> pci@8000 {
> compatible = "fsl,mpc8540-pci";
> device_type = "pci";
> interrupt-map-mask = <f800 0 0 7>;
> interrupt-map = <
>
> /* IDSEL 0x11 J17 Slot 1 */
> 8800 0 0 1 &mpic 2 1
> 8800 0 0 2 &mpic 3 1
> 8800 0 0 3 &mpic 4 1
> 8800 0 0 4 &mpic 1 1
>
> /* IDSEL 0x12 J16 Slot 2 */
>
> 9000 0 0 1 &mpic 3 1
> 9000 0 0 2 &mpic 4 1
> 9000 0 0 3 &mpic 2 1
> 9000 0 0 4 &mpic 1 1>;
>
> interrupt-parent = <&mpic>;
> interrupts = <18 2>;
> bus-range = <0 ff>;
> ranges = <02000000 0 80000000 80000000 0 20000000
> 01000000 0 00000000 e2000000 0 00100000>;
> clock-frequency = <3f940aa>;
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> reg = <8000 1000>;
> };
>
> pci@c000 {
> compatible = "fsl,mpc8540-pci";
> device_type = "pci";
> interrupt-map-mask = <f800 0 0 7>;
> interrupt-map = <
>
> /* IDSEL 0x11 J17 Slot 1 */
> 8800 0 0 1 &mpic 2 1
> 8800 0 0 2 &mpic 3 1
> 8800 0 0 3 &mpic 4 1
> 8800 0 0 4 &mpic 1 1
>
> /* IDSEL 0x12 J16 Slot 2 */
>
> 9000 0 0 1 &mpic 3 1
> 9000 0 0 2 &mpic 4 1
> 9000 0 0 3 &mpic 2 1
> 9000 0 0 4 &mpic 1 1>;
>
> interrupt-parent = <&mpic>;
> interrupts = <18 2>;
> bus-range = <0 ff>;
> ranges = <02000000 0 c0000000 c0000000 0 20000000
> 01000000 0 00000000 e2800000 0 00100000>;
> clock-frequency = <3f940aa>;
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> reg = <c000 1000>;
> };
>
> pcie@a000 {
> compatible = "fsl,mpc8548-pcie";
> device_type = "pci";
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> reg = <a000 1000>;
> bus-range = <0 ff>;
> ranges = <02000000 0 a0000000 a0000000 0 20000000
> 01000000 0 00000000 e3000000 0 00100000>;
> clock-frequency = <1fca055>;
> interrupt-parent = <&mpic>;
> interrupts = <19 2>;
> interrupt-map-mask = <f800 0 0 7>;
> interrupt-map = <
> /* IDSEL 0x0 */
> 0000 0 0 1 &mpic 0 1
> 0000 0 0 2 &mpic 1 1
> 0000 0 0 3 &mpic 2 1
> 0000 0 0 4 &mpic 3 1
> >;
> };
Take a look at the device trees in the kernel source. You'll see we
moved PCI around so its at the root level. Not sure if that's your
issue.
> I see all the above in /proc/device-tree/soc8548@e0000000 when booting
> the kernel. I double checked my memory mapping in u-boot and it
> appears to match my device tree. Yet I don't see any pci here:
>
> root:~> cat /proc/iomem
> e0004500-e0004507 : serial
> e0004600-e0004607 : serial
> e0024000-e0024fff : ethernet
> e0024520-e002453f : mdio
> e0025000-e0025fff : ethernet
> e0026000-e0026fff : ethernet
> e0027000-e0027fff : ethernet
>
> cat /proc/bus/pci/devices shows nothing though I have a card in PCI1,
> and all I see from dmesg is "PCI: Probing PCI hardware" . Any ideas?
It seems like its not even really probing or finding the buses.
Can you post what your board/platform code looks like?
- k
^ permalink raw reply
* [BUG] 2.6.24-rc3-git2 softlockup detected
From: Kamalesh Babulal @ 2007-11-28 6:29 UTC (permalink / raw)
To: LKML, linuxppc-dev, Andy Whitcroft, Balbir Singh
Hi,
Soft lockup is detected while bootup with 2.6.24-rc3-git2 on powerbox
BUG: soft lockup - CPU#1 stuck for 11s! [insmod:375]
NIP: c00000000002f02c LR: d0000000001414fc CTR: c00000000002f018
REGS: c00000077cbef0b0 TRAP: 0901 Not tainted (2.6.24-rc3-git2-autotest)
MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24022088 XER: 00000000
TASK = c00000077cbd8000[375] 'insmod' THREAD: c00000077cbec000 CPU: 1
GPR00: d0000000001414fc c00000077cbef330 c00000000052b930 d000080080002014
GPR04: d00008008000202c 0000000000000000 c00000077ca1cb00 d00000000014ce54
GPR08: c00000077ca1c63c 0000000000000000 000000000000002a c00000000002f018
GPR12: d000000000143610 c000000000473d00
NIP [c00000000002f02c] .ioread8+0x14/0x60
LR [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
Call Trace:
[c00000077cbef330] [c00000077cbef3c0] 0xc00000077cbef3c0 (unreliable)
[c00000077cbef3a0] [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
[c00000077cbef470] [d0000000001395f8] .sym2_probe+0x700/0x99c [sym53c8xx]
[c00000077cbef710] [c0000000001bc118] .pci_device_probe+0x124/0x1b0
[c00000077cbef7b0] [c000000000221138] .driver_probe_device+0x144/0x20c
[c00000077cbef850] [c000000000221450] .__driver_attach+0xcc/0x154
[c00000077cbef8e0] [c00000000021ff94] .bus_for_each_dev+0x7c/0xd4
[c00000077cbef9a0] [c000000000220e9c] .driver_attach+0x28/0x40
[c00000077cbefa20] [c0000000002204d8] .bus_add_driver+0x90/0x228
[c00000077cbefac0] [c000000000221858] .driver_register+0x94/0xb0
[c00000077cbefb40] [c0000000001bc430] .__pci_register_driver+0x6c/0xcc
[c00000077cbefbe0] [d000000000143428] .sym2_init+0x108/0x15b0 [sym53c8xx]
[c00000077cbefc80] [c00000000008ce80] .sys_init_module+0x17c4/0x1958
[c00000077cbefe30] [c00000000000872c] syscall_exit+0x0/0x40
Instruction dump:
60000000 786b0420 38210070 7d635b78 e8010010 7c0803a6 4e800020 7c0802a6
f8010010 f821ff91 7c0004ac 89230000 <0c090000> 4c00012c 79290620 2f8900ff
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)
From: Dell Query @ 2007-11-28 6:38 UTC (permalink / raw)
To: Josh Boyer, linuxppc-embedded
In-Reply-To: <20071127212548.3efd39e9@vader.jdub.homelinux.org>
[-- Attachment #1: Type: text/plain, Size: 1768 bytes --]
Oh is it 0x1C0002000?
Where can I get the document? What I have is 0xC0002000 from ep440xc_um_amcc.pdf file that I get from the accompanying PPC440EPx resource CD.
Thanks!
dell
Josh Boyer <jwboyer@gmail.com> wrote: On Tue, 27 Nov 2007 02:47:45 -0800 (PST)
Dell Query wrote:
> Hi,
>
> I am creating a simple program which will try to read the board ID of the PPC440EPx thru BCSR but when I load it, it gives me "Data Read PLB Error".
>
> I am not sure if I missed out something.
>
> I would really appreciate it if somebody could help me on this.
>
> I have posted the source code below, as well as the complete message.
>
> Many thanks!
>
> SOURCE CODE:
> ----------------------------------------------------------------------
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> MODULE_LICENSE("GPL");
>
> #define BCSR_BASE 0xC0002000
This is wrong. It's 0x1C0002000.
> #define BCSR0 0
> #define BCSR1 1
> #define BCSR2 2
>
> #define USER_LED 0x2
> #define SIZE_TO_MAP 10
>
> #define LED_ON 0
>
> uint __iomem *bcsrbase = NULL;
>
> static int __init initFunction(void) {
> uint tmp;
> printk("<1> Calling init function.\n");
> printk("<1> bcsrbase value %p...\n",bcsrbase);
> printk("<1> Remapping %x...\n",BCSR_BASE);
> /*map*/
> bcsrbase = ioremap(BCSR_BASE, SIZE_TO_MAP);
Since this seems to be arch/ppc, use ioremap64.
josh
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
---------------------------------
Never miss a thing. Make Yahoo your homepage.
[-- Attachment #2: Type: text/html, Size: 2574 bytes --]
^ permalink raw reply
* Re: [BUG] 2.6.24-rc3-git2 softlockup detected
From: Andrew Morton @ 2007-11-28 6:53 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: linux-scsi, LKML, Rafael J. Wysocki, linuxppc-dev, Andy,
Balbir Singh
In-Reply-To: <474D0AAC.5010005@linux.vnet.ibm.com>
On Wed, 28 Nov 2007 11:59:00 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Hi,
(cc linux-scsi, for sym53c8xx)
> Soft lockup is detected while bootup with 2.6.24-rc3-git2 on powerbox
I assume this is a post-2.6.23 regression?
> BUG: soft lockup - CPU#1 stuck for 11s! [insmod:375]
> NIP: c00000000002f02c LR: d0000000001414fc CTR: c00000000002f018
> REGS: c00000077cbef0b0 TRAP: 0901 Not tainted (2.6.24-rc3-git2-autotest)
> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24022088 XER: 00000000
> TASK = c00000077cbd8000[375] 'insmod' THREAD: c00000077cbec000 CPU: 1
> GPR00: d0000000001414fc c00000077cbef330 c00000000052b930 d000080080002014
> GPR04: d00008008000202c 0000000000000000 c00000077ca1cb00 d00000000014ce54
> GPR08: c00000077ca1c63c 0000000000000000 000000000000002a c00000000002f018
> GPR12: d000000000143610 c000000000473d00
> NIP [c00000000002f02c] .ioread8+0x14/0x60
> LR [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
> Call Trace:
> [c00000077cbef330] [c00000077cbef3c0] 0xc00000077cbef3c0 (unreliable)
> [c00000077cbef3a0] [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
> [c00000077cbef470] [d0000000001395f8] .sym2_probe+0x700/0x99c [sym53c8xx]
> [c00000077cbef710] [c0000000001bc118] .pci_device_probe+0x124/0x1b0
> [c00000077cbef7b0] [c000000000221138] .driver_probe_device+0x144/0x20c
> [c00000077cbef850] [c000000000221450] .__driver_attach+0xcc/0x154
> [c00000077cbef8e0] [c00000000021ff94] .bus_for_each_dev+0x7c/0xd4
> [c00000077cbef9a0] [c000000000220e9c] .driver_attach+0x28/0x40
> [c00000077cbefa20] [c0000000002204d8] .bus_add_driver+0x90/0x228
> [c00000077cbefac0] [c000000000221858] .driver_register+0x94/0xb0
> [c00000077cbefb40] [c0000000001bc430] .__pci_register_driver+0x6c/0xcc
> [c00000077cbefbe0] [d000000000143428] .sym2_init+0x108/0x15b0 [sym53c8xx]
> [c00000077cbefc80] [c00000000008ce80] .sys_init_module+0x17c4/0x1958
> [c00000077cbefe30] [c00000000000872c] syscall_exit+0x0/0x40
> Instruction dump:
> 60000000 786b0420 38210070 7d635b78 e8010010 7c0803a6 4e800020 7c0802a6
> f8010010 f821ff91 7c0004ac 89230000 <0c090000> 4c00012c 79290620 2f8900ff
I see no obvious lockup sites near the end of sym_hcb_attach(). Maybe it's
being called lots of times from a higher level.. Do the traces all look
the same?
^ permalink raw reply
* Re: [BUG] 2.6.24-rc3-git2 softlockup detected
From: Andrew Morton @ 2007-11-28 7:25 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: linux-scsi, LKML, Rafael J. Wysocki, linuxppc-dev, Andy,
Balbir Singh
In-Reply-To: <474D15FF.5080508@linux.vnet.ibm.com>
On Wed, 28 Nov 2007 12:47:19 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Andrew Morton wrote:
> > On Wed, 28 Nov 2007 11:59:00 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> >
> >> Hi,
> >
> > (cc linux-scsi, for sym53c8xx)
> >
> >> Soft lockup is detected while bootup with 2.6.24-rc3-git2 on powerbox
> >
> > I assume this is a post-2.6.23 regression?
> >
> >> BUG: soft lockup - CPU#1 stuck for 11s! [insmod:375]
> >> NIP: c00000000002f02c LR: d0000000001414fc CTR: c00000000002f018
> >> REGS: c00000077cbef0b0 TRAP: 0901 Not tainted (2.6.24-rc3-git2-autotest)
> >> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24022088 XER: 00000000
> >> TASK = c00000077cbd8000[375] 'insmod' THREAD: c00000077cbec000 CPU: 1
> >> GPR00: d0000000001414fc c00000077cbef330 c00000000052b930 d000080080002014
> >> GPR04: d00008008000202c 0000000000000000 c00000077ca1cb00 d00000000014ce54
> >> GPR08: c00000077ca1c63c 0000000000000000 000000000000002a c00000000002f018
> >> GPR12: d000000000143610 c000000000473d00
> >> NIP [c00000000002f02c] .ioread8+0x14/0x60
> >> LR [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
> >> Call Trace:
> >> [c00000077cbef330] [c00000077cbef3c0] 0xc00000077cbef3c0 (unreliable)
> >> [c00000077cbef3a0] [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
> >> [c00000077cbef470] [d0000000001395f8] .sym2_probe+0x700/0x99c [sym53c8xx]
> >> [c00000077cbef710] [c0000000001bc118] .pci_device_probe+0x124/0x1b0
> >> [c00000077cbef7b0] [c000000000221138] .driver_probe_device+0x144/0x20c
> >> [c00000077cbef850] [c000000000221450] .__driver_attach+0xcc/0x154
> >> [c00000077cbef8e0] [c00000000021ff94] .bus_for_each_dev+0x7c/0xd4
> >> [c00000077cbef9a0] [c000000000220e9c] .driver_attach+0x28/0x40
> >> [c00000077cbefa20] [c0000000002204d8] .bus_add_driver+0x90/0x228
> >> [c00000077cbefac0] [c000000000221858] .driver_register+0x94/0xb0
> >> [c00000077cbefb40] [c0000000001bc430] .__pci_register_driver+0x6c/0xcc
> >> [c00000077cbefbe0] [d000000000143428] .sym2_init+0x108/0x15b0 [sym53c8xx]
> >> [c00000077cbefc80] [c00000000008ce80] .sys_init_module+0x17c4/0x1958
> >> [c00000077cbefe30] [c00000000000872c] syscall_exit+0x0/0x40
> >> Instruction dump:
> >> 60000000 786b0420 38210070 7d635b78 e8010010 7c0803a6 4e800020 7c0802a6
> >> f8010010 f821ff91 7c0004ac 89230000 <0c090000> 4c00012c 79290620 2f8900ff
> >
> > I see no obvious lockup sites near the end of sym_hcb_attach(). Maybe it's
> > being called lots of times from a higher level.. Do the traces all look
> > the same?
>
> Hi Andrew,
>
> I see this call trace twice and both looks similar and on another reboot
> the following trace is seen twice in different cpu
>
> BUG: soft lockup detected on CPU#3!
> Call Trace:
> [C00000003FEDEDA0] [C000000000010220] .show_stack+0x68/0x1b0 (unreliable)
> [C00000003FEDEE40] [C0000000000A061C] .softlockup_tick+0xf0/0x13c
> [C00000003FEDEEF0] [C000000000072E2C] .run_local_timers+0x1c/0x30
> [C00000003FEDEF70] [C000000000022FA0] .timer_interrupt+0xa8/0x488
> [C00000003FEDF050] [C0000000000034EC] decrementer_common+0xec/0x100
> --- Exception: 901 at .ioread8+0x14/0x60
> LR = .sym_hcb_attach+0x1194/0x1384 [sym53c8xx]
> [C00000003FEDF340] [D0000000002B3BC0] 0xd0000000002b3bc0 (unreliable)
> [C00000003FEDF3B0] [D00000000029A3C0] .sym_hcb_attach+0x1194/0x1384 [sym53c8xx]
> [C00000003FEDF480] [D000000000291D30] .sym2_probe+0x75c/0x9f8 [sym53c8xx]
> [C00000003FEDF710] [C0000000001B65A4] .pci_device_probe+0x13c/0x1dc
> [C00000003FEDF7D0] [C000000000219A0C] .driver_probe_device+0xa0/0x15c
> [C00000003FEDF870] [C000000000219C64] .__driver_attach+0xb4/0x138
> [C00000003FEDF900] [C00000000021913C] .bus_for_each_dev+0x7c/0xd4
> [C00000003FEDF9C0] [C0000000002198B0] .driver_attach+0x28/0x40
> [C00000003FEDFA40] [C000000000218BA4] .bus_add_driver+0x98/0x18c
> [C00000003FEDFAE0] [C00000000021A064] .driver_register+0xa8/0xc4
> [C00000003FEDFB60] [C0000000001B68AC] .__pci_register_driver+0x5c/0xa4
> [C00000003FEDFBF0] [D00000000029C204] .sym2_init+0x104/0x1550 [sym53c8xx]
> [C00000003FEDFC90] [C00000000008D1F4] .sys_init_module+0x1764/0x1998
> [C00000003FEDFE30] [C00000000000869C] syscall_exit+0x0/0x40
>
hm, odd.
Can you look up sym_hcb_attach+0x1194/0x1384 in gdb? Something like
- Enable CONFIG_DEBUG_INFO
- gdb sym53c8xx.o
(gdb) p sym_hcb_attach
<prints 0xsomething>
(gdb) p/x 0xsomething + 0x1194
<prints 0xsomethingelse>
(gdb) l *0xsomethingelse
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: add hugepagesz boot-time parameter
From: Arnd Bergmann @ 2007-11-28 7:26 UTC (permalink / raw)
To: linuxppc-dev, kniht; +Cc: Linux Memory Management List
In-Reply-To: <474CF68E.1040709@us.ibm.com>
On Wednesday 28 November 2007, Jon Tollefson wrote:
> This patch adds the hugepagesz boot-time parameter for ppc64 that lets=20
> you pick the size for your huge pages. =A0The choices available are 64K=20
> and 16M. =A0It defaults to 16M (previously the only choice) if nothing or=
=20
> an invalid choice is specified. =A0Tested 64K huge pages with the=20
> libhugetlbfs 1.2 release with its 'make func' and 'make stress' test=20
> invocations.
How hard would it be to add the 1MB page size that some CPUs support
as well? On systems with small physical memory like the PS3, that
sounds very useful to me.
Arnd <><
^ permalink raw reply
* Re: [BUG] 2.6.24-rc3-git2 softlockup detected
From: Kamalesh Babulal @ 2007-11-28 7:17 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-scsi, LKML, Rafael J. Wysocki, linuxppc-dev, Balbir Singh
In-Reply-To: <20071127225328.9e3f3827.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Wed, 28 Nov 2007 11:59:00 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
>> Hi,
>
> (cc linux-scsi, for sym53c8xx)
>
>> Soft lockup is detected while bootup with 2.6.24-rc3-git2 on powerbox
>
> I assume this is a post-2.6.23 regression?
>
>> BUG: soft lockup - CPU#1 stuck for 11s! [insmod:375]
>> NIP: c00000000002f02c LR: d0000000001414fc CTR: c00000000002f018
>> REGS: c00000077cbef0b0 TRAP: 0901 Not tainted (2.6.24-rc3-git2-autotest)
>> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24022088 XER: 00000000
>> TASK = c00000077cbd8000[375] 'insmod' THREAD: c00000077cbec000 CPU: 1
>> GPR00: d0000000001414fc c00000077cbef330 c00000000052b930 d000080080002014
>> GPR04: d00008008000202c 0000000000000000 c00000077ca1cb00 d00000000014ce54
>> GPR08: c00000077ca1c63c 0000000000000000 000000000000002a c00000000002f018
>> GPR12: d000000000143610 c000000000473d00
>> NIP [c00000000002f02c] .ioread8+0x14/0x60
>> LR [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
>> Call Trace:
>> [c00000077cbef330] [c00000077cbef3c0] 0xc00000077cbef3c0 (unreliable)
>> [c00000077cbef3a0] [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
>> [c00000077cbef470] [d0000000001395f8] .sym2_probe+0x700/0x99c [sym53c8xx]
>> [c00000077cbef710] [c0000000001bc118] .pci_device_probe+0x124/0x1b0
>> [c00000077cbef7b0] [c000000000221138] .driver_probe_device+0x144/0x20c
>> [c00000077cbef850] [c000000000221450] .__driver_attach+0xcc/0x154
>> [c00000077cbef8e0] [c00000000021ff94] .bus_for_each_dev+0x7c/0xd4
>> [c00000077cbef9a0] [c000000000220e9c] .driver_attach+0x28/0x40
>> [c00000077cbefa20] [c0000000002204d8] .bus_add_driver+0x90/0x228
>> [c00000077cbefac0] [c000000000221858] .driver_register+0x94/0xb0
>> [c00000077cbefb40] [c0000000001bc430] .__pci_register_driver+0x6c/0xcc
>> [c00000077cbefbe0] [d000000000143428] .sym2_init+0x108/0x15b0 [sym53c8xx]
>> [c00000077cbefc80] [c00000000008ce80] .sys_init_module+0x17c4/0x1958
>> [c00000077cbefe30] [c00000000000872c] syscall_exit+0x0/0x40
>> Instruction dump:
>> 60000000 786b0420 38210070 7d635b78 e8010010 7c0803a6 4e800020 7c0802a6
>> f8010010 f821ff91 7c0004ac 89230000 <0c090000> 4c00012c 79290620 2f8900ff
>
> I see no obvious lockup sites near the end of sym_hcb_attach(). Maybe it's
> being called lots of times from a higher level.. Do the traces all look
> the same?
Hi Andrew,
I see this call trace twice and both looks similar and on another reboot
the following trace is seen twice in different cpu
BUG: soft lockup detected on CPU#3!
Call Trace:
[C00000003FEDEDA0] [C000000000010220] .show_stack+0x68/0x1b0 (unreliable)
[C00000003FEDEE40] [C0000000000A061C] .softlockup_tick+0xf0/0x13c
[C00000003FEDEEF0] [C000000000072E2C] .run_local_timers+0x1c/0x30
[C00000003FEDEF70] [C000000000022FA0] .timer_interrupt+0xa8/0x488
[C00000003FEDF050] [C0000000000034EC] decrementer_common+0xec/0x100
--- Exception: 901 at .ioread8+0x14/0x60
LR = .sym_hcb_attach+0x1194/0x1384 [sym53c8xx]
[C00000003FEDF340] [D0000000002B3BC0] 0xd0000000002b3bc0 (unreliable)
[C00000003FEDF3B0] [D00000000029A3C0] .sym_hcb_attach+0x1194/0x1384 [sym53c8xx]
[C00000003FEDF480] [D000000000291D30] .sym2_probe+0x75c/0x9f8 [sym53c8xx]
[C00000003FEDF710] [C0000000001B65A4] .pci_device_probe+0x13c/0x1dc
[C00000003FEDF7D0] [C000000000219A0C] .driver_probe_device+0xa0/0x15c
[C00000003FEDF870] [C000000000219C64] .__driver_attach+0xb4/0x138
[C00000003FEDF900] [C00000000021913C] .bus_for_each_dev+0x7c/0xd4
[C00000003FEDF9C0] [C0000000002198B0] .driver_attach+0x28/0x40
[C00000003FEDFA40] [C000000000218BA4] .bus_add_driver+0x98/0x18c
[C00000003FEDFAE0] [C00000000021A064] .driver_register+0xa8/0xc4
[C00000003FEDFB60] [C0000000001B68AC] .__pci_register_driver+0x5c/0xa4
[C00000003FEDFBF0] [D00000000029C204] .sym2_init+0x104/0x1550 [sym53c8xx]
[C00000003FEDFC90] [C00000000008D1F4] .sys_init_module+0x1764/0x1998
[C00000003FEDFE30] [C00000000000869C] syscall_exit+0x0/0x40
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* [PATCH 2/2] powerpc: make 64K huge pages more reliable
From: Jon Tollefson @ 2007-11-28 5:03 UTC (permalink / raw)
To: linuxppc-dev, Linux Memory Management List
This patch adds reliability to the 64K huge page option by making use of
the PMD for 64K huge pages when base pages are 4k. So instead of a 12
bit pte it would be 7 bit pmd and a 5 bit pte. The pgd and pud offsets
would continue as 9 bits and 7 bits respectively. This will allow the
pgtable to fit in one base page. This patch would have to be applied
after part 1.
Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com>
---
hugetlbpage.c | 53 ++++++++++++++++++++++++++++++++++++++---------------
1 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index f4632ad..c6df45b 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -30,15 +30,11 @@
#define NUM_LOW_AREAS (0x100000000UL >> SID_SHIFT)
#define NUM_HIGH_AREAS (PGTABLE_RANGE >> HTLB_AREA_SHIFT)
-#ifdef CONFIG_PPC_64K_PAGES
-#define HUGEPTE_INDEX_SIZE (PMD_SHIFT-HPAGE_SHIFT)
-#else
-#define HUGEPTE_INDEX_SIZE (PUD_SHIFT-HPAGE_SHIFT)
-#endif
-#define PTRS_PER_HUGEPTE (1 << HUGEPTE_INDEX_SIZE)
-#define HUGEPTE_TABLE_SIZE (sizeof(pte_t) << HUGEPTE_INDEX_SIZE)
+unsigned int hugepte_shift;
+#define PTRS_PER_HUGEPTE (1 << hugepte_shift)
+#define HUGEPTE_TABLE_SIZE (sizeof(pte_t) << hugepte_shift)
-#define HUGEPD_SHIFT (HPAGE_SHIFT + HUGEPTE_INDEX_SIZE)
+#define HUGEPD_SHIFT (HPAGE_SHIFT + hugepte_shift)
#define HUGEPD_SIZE (1UL << HUGEPD_SHIFT)
#define HUGEPD_MASK (~(HUGEPD_SIZE-1))
@@ -105,7 +101,14 @@ pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
if (!pmd_none(*pm))
return hugepte_offset((hugepd_t *)pm, addr);
#else
- return hugepte_offset((hugepd_t *)pu, addr);
+ if (HPAGE_SHIFT == HPAGE_SHIFT_64K) {
+ pmd_t *pm;
+ pm = pmd_offset(pu, addr);
+ if (!pmd_none(*pm))
+ return hugepte_offset((hugepd_t *)pm, addr);
+ } else {
+ return hugepte_offset((hugepd_t *)pu, addr);
+ }
#endif
}
}
@@ -133,7 +136,14 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long addr)
if (pm)
hpdp = (hugepd_t *)pm;
#else
- hpdp = (hugepd_t *)pu;
+ if (HPAGE_SHIFT == HPAGE_SHIFT_64K) {
+ pmd_t *pm;
+ pm = pmd_alloc(mm, pu, addr);
+ if (pm)
+ hpdp = (hugepd_t *)pm;
+ } else {
+ hpdp = (hugepd_t *)pu;
+ }
#endif
}
@@ -161,7 +171,6 @@ static void free_hugepte_range(struct mmu_gather *tlb, hugepd_t *hpdp)
PGF_CACHENUM_MASK));
}
-#ifdef CONFIG_PPC_64K_PAGES
static void hugetlb_free_pmd_range(struct mmu_gather *tlb, pud_t *pud,
unsigned long addr, unsigned long end,
unsigned long floor, unsigned long ceiling)
@@ -194,7 +203,6 @@ static void hugetlb_free_pmd_range(struct mmu_gather *tlb, pud_t *pud,
pud_clear(pud);
pmd_free_tlb(tlb, pmd);
}
-#endif
static void hugetlb_free_pud_range(struct mmu_gather *tlb, pgd_t *pgd,
unsigned long addr, unsigned long end,
@@ -213,9 +221,15 @@ static void hugetlb_free_pud_range(struct mmu_gather *tlb, pgd_t *pgd,
continue;
hugetlb_free_pmd_range(tlb, pud, addr, next, floor, ceiling);
#else
- if (pud_none(*pud))
- continue;
- free_hugepte_range(tlb, (hugepd_t *)pud);
+ if (HPAGE_SHIFT == HPAGE_SHIFT_64K) {
+ if (pud_none_or_clear_bad(pud))
+ continue;
+ hugetlb_free_pmd_range(tlb, pud, addr, next, floor, ceiling);
+ } else {
+ if (pud_none(*pud))
+ continue;
+ free_hugepte_range(tlb, (hugepd_t *)pud);
+ }
#endif
} while (pud++, addr = next, addr != end);
@@ -538,6 +552,15 @@ void set_huge_psize(int psize)
mmu_psize_defs[psize].shift == HPAGE_SHIFT_64K)) {
HPAGE_SHIFT = mmu_psize_defs[psize].shift;
mmu_huge_psize = psize;
+#ifdef CONFIG_PPC_64K_PAGES
+ hugepte_shift = (PMD_SHIFT-HPAGE_SHIFT);
+#else
+ if (HPAGE_SHIFT == HPAGE_SHIFT_64K)
+ hugepte_shift = (PMD_SHIFT-HPAGE_SHIFT);
+ else
+ hugepte_shift = (PUD_SHIFT-HPAGE_SHIFT);
+#endif
+
} else
HPAGE_SHIFT = 0;
}
^ permalink raw reply related
* [PATCH 1/2] powerpc: add hugepagesz boot-time parameter
From: Jon Tollefson @ 2007-11-28 5:03 UTC (permalink / raw)
To: linuxppc-dev, Linux Memory Management List
This patch adds the hugepagesz boot-time parameter for ppc64 that lets
you pick the size for your huge pages. The choices available are 64K
and 16M. It defaults to 16M (previously the only choice) if nothing or
an invalid choice is specified. Tested 64K huge pages with the
libhugetlbfs 1.2 release with its 'make func' and 'make stress' test
invocations.
This patch requires the patch posted by Mel Gorman that adds
HUGETLB_PAGE_SIZE_VARIABLE; "[PATCH] Fix boot problem with iSeries
lacking hugepage support" on 2007-11-15.
Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com>
---
Documentation/kernel-parameters.txt | 1
arch/powerpc/mm/hash_utils_64.c | 11 +--------
arch/powerpc/mm/hugetlbpage.c | 41 ++++++++++++++++++++++++++++++++++++
include/asm-powerpc/mmu-hash64.h | 1
mm/hugetlb.c | 1
5 files changed, 46 insertions(+), 9 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 33121d6..2fc1fb8 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -685,6 +685,7 @@ and is between 256 and 4096 characters. It is defined in the file
See Documentation/isdn/README.HiSax.
hugepages= [HW,X86-32,IA-64] Maximal number of HugeTLB pages.
+ hugepagesz= [HW,IA-64,PPC] The size of the HugeTLB pages.
i8042.direct [HW] Put keyboard port into non-translated mode
i8042.dumbkbd [HW] Pretend that controller can only read data from
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index f09730b..afc044c 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -368,18 +368,11 @@ static void __init htab_init_page_sizes(void)
* on what is available
*/
if (mmu_psize_defs[MMU_PAGE_16M].shift)
- mmu_huge_psize = MMU_PAGE_16M;
+ set_huge_psize(MMU_PAGE_16M);
/* With 4k/4level pagetables, we can't (for now) cope with a
* huge page size < PMD_SIZE */
else if (mmu_psize_defs[MMU_PAGE_1M].shift)
- mmu_huge_psize = MMU_PAGE_1M;
-
- /* Calculate HPAGE_SHIFT and sanity check it */
- if (mmu_psize_defs[mmu_huge_psize].shift > MIN_HUGEPTE_SHIFT &&
- mmu_psize_defs[mmu_huge_psize].shift < SID_SHIFT)
- HPAGE_SHIFT = mmu_psize_defs[mmu_huge_psize].shift;
- else
- HPAGE_SHIFT = 0; /* No huge pages dude ! */
+ set_huge_psize(MMU_PAGE_1M);
#endif /* CONFIG_HUGETLB_PAGE */
}
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 71efb38..f4632ad 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -24,6 +24,9 @@
#include <asm/cputable.h>
#include <asm/spu.h>
+#define HPAGE_SHIFT_64K 16
+#define HPAGE_SHIFT_16M 24
+
#define NUM_LOW_AREAS (0x100000000UL >> SID_SHIFT)
#define NUM_HIGH_AREAS (PGTABLE_RANGE >> HTLB_AREA_SHIFT)
@@ -526,6 +529,44 @@ repeat:
return err;
}
+void set_huge_psize(int psize)
+{
+ /* Check that it is a page size supported by the hardware and
+ * that it fits within pagetable limits. */
+ if (mmu_psize_defs[psize].shift && mmu_psize_defs[psize].shift < SID_SHIFT &&
+ (mmu_psize_defs[psize].shift > MIN_HUGEPTE_SHIFT ||
+ mmu_psize_defs[psize].shift == HPAGE_SHIFT_64K)) {
+ HPAGE_SHIFT = mmu_psize_defs[psize].shift;
+ mmu_huge_psize = psize;
+ } else
+ HPAGE_SHIFT = 0;
+}
+
+static int __init hugepage_setup_sz(char *str)
+{
+ unsigned long long size;
+
+ size = memparse(str, &str);
+
+ int shift = __ffs(size);
+ int mmu_psize = -1;
+ switch (shift) {
+ case HPAGE_SHIFT_64K:
+ mmu_psize = MMU_PAGE_64K;
+ break;
+ case HPAGE_SHIFT_16M:
+ mmu_psize = MMU_PAGE_16M;
+ break;
+ }
+ if (mmu_psize >= 0 && mmu_psize_defs[mmu_psize].shift)
+ set_huge_psize(mmu_psize);
+ else
+ printk(KERN_WARNING "Invalid huge page size specified(%i)\n", size);
+
+ return 1;
+}
+__setup("hugepagesz=", hugepage_setup_sz);
+
static void zero_ctor(struct kmem_cache *cache, void *addr)
{
memset(addr, 0, kmem_cache_size(cache));
diff --git a/include/asm-powerpc/mmu-hash64.h b/include/asm-powerpc/mmu-hash64.h
index 82328de..f35c945 100644
--- a/include/asm-powerpc/mmu-hash64.h
+++ b/include/asm-powerpc/mmu-hash64.h
@@ -277,6 +277,7 @@ extern int hash_huge_page(struct mm_struct *mm, unsigned long access,
extern int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
unsigned long pstart, unsigned long mode,
int psize, int ssize);
+extern void set_huge_psize(int psize);
extern void htab_initialize(void);
extern void htab_initialize_secondary(void);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 6121b57..055d232 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -422,6 +422,7 @@ static int __init hugetlb_init(void)
break;
}
max_huge_pages = free_huge_pages = nr_huge_pages = i;
+ printk(KERN_INFO "HugeTLB page size: %ld bytes\n", HPAGE_SIZE);
printk("Total HugeTLB memory allocated, %ld\n", free_huge_pages);
return 0;
}
^ permalink raw reply related
* Re: The question about the high memory support on MPC8360?
From: vijay baskar @ 2007-11-28 4:02 UTC (permalink / raw)
To: Scott Wood; +Cc: 郭劲, linuxppc-embedded
In-Reply-To: <474C4DA9.6000205@freescale.com>
Hi,
"The kernel also allows hardcoded mapping
of IO regions into its virtual address space through the
io_block_mapping interface."
Can u tell me how this is in current arch/powerpc. Also does it mean
that whatever be the size of the ram > 768 MB there is not going to be
much improvement in performance in kernel space irrespective of invoking
CONFIG_HIGHMEM or not?
Also do you think this low mem be enough if i have lots of kernel space
processes each invoking lots of kmallocs. Will there be bottle necks??
Also what alternative do we have if low mem of 768 MB is not enough??
Scott Wood wrote:
> vijay baskar wrote:
>
>> The kernel maps the last 1 GB of the virtual address space one to one
>> to the physical memory.
>
>
> No, it maps 768MB of RAM in this manner.
>
>> This is called the kernel space. After the one
>> to one mapping is done for the available physical memory, the
>> remaining virtual addresses are used for vmalloc and ioremap.
>
>
> And highmem mappings.
>
>> The kernel also allows hardcoded mapping
>> of IO regions into its virtual address space through the
>> io_block_mapping interface.
>
>
> Not in current arch/powerpc kernels.
>
>> Many boards use the block IO mapping to
>> map the CCSRBAR/IMMR into the kernel address space, such that the
>> physical address and the virutal address is the same. Virtual
>> addresses beyond these hardcoded mappings cannot be used by
>> vmalloc/ioremap.
>
>
> And this is why.
>
>> Now as more and more memory is added to the system the addresses
>> available for vmalloc and ioremap gets reduced, and memory allocations
>> start to fail, due to the lack of availability of virtual addresses.
>
>
> How so? The size of lowmem is constant once you reach the threshold,
> as is the size of the highmem mapping area.
>
> What *does* start to fail eventually, if you have a *lot* of highmem,
> is that you run out of lowmem for pagetables and such.
>
> -Scott
>
>
^ permalink raw reply
* of_compat_cmp on various platforms
From: Jon Smirl @ 2007-11-28 3:46 UTC (permalink / raw)
To: PowerPC dev list
Is this right or should it be the same everywhere?
asm-powerpc/prom.h:#define of_compat_cmp(s1, s2, l) strcasecmp((s1), (s2))
asm-sparc/prom.h:#define of_compat_cmp(s1, s2, l) strncmp((s1), (s2), (l))
asm-sparc64/prom.h:#define of_compat_cmp(s1, s2, l) strncmp((s1), (s2), (l))
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)
From: Josh Boyer @ 2007-11-28 3:25 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <409454.53699.qm@web45615.mail.sp1.yahoo.com>
On Tue, 27 Nov 2007 02:47:45 -0800 (PST)
Dell Query <dell.query@yahoo.com> wrote:
> Hi,
>
> I am creating a simple program which will try to read the board ID of the PPC440EPx thru BCSR but when I load it, it gives me "Data Read PLB Error".
>
> I am not sure if I missed out something.
>
> I would really appreciate it if somebody could help me on this.
>
> I have posted the source code below, as well as the complete message.
>
> Many thanks!
>
> SOURCE CODE:
> ----------------------------------------------------------------------
> #include <linux/module.h>
> #include <linux/kernel.h>
> #include <linux/ioport.h>
> #include <linux/delay.h>
> #include <linux/init.h>
> #include <linux/interrupt.h>
> #include <linux/platform_device.h>
> #include <asm/irq.h>
> #include <asm/io.h>
> #include <linux/i2c.h>
> #include <linux/i2c-id.h>
> #include <asm/ocp.h>
> #include <asm/ibm4xx.h>
>
> MODULE_LICENSE("GPL");
>
> #define BCSR_BASE 0xC0002000
This is wrong. It's 0x1C0002000.
> #define BCSR0 0
> #define BCSR1 1
> #define BCSR2 2
>
> #define USER_LED 0x2
> #define SIZE_TO_MAP 10
>
> #define LED_ON 0
>
> uint __iomem *bcsrbase = NULL;
>
> static int __init initFunction(void) {
> uint tmp;
> printk("<1> Calling init function.\n");
> printk("<1> bcsrbase value %p...\n",bcsrbase);
> printk("<1> Remapping %x...\n",BCSR_BASE);
> /*map*/
> bcsrbase = ioremap(BCSR_BASE, SIZE_TO_MAP);
Since this seems to be arch/ppc, use ioremap64.
josh
^ permalink raw reply
* Re: Xilinx devicetrees
From: John Williams @ 2007-11-28 0:52 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: Michal Simek, linuxppc-embedded
In-Reply-To: <20071128002835.068BE16A005D@mail198-sin.bigfish.com>
Stephen Neuendorffer wrote:
>>From: John Williams [mailto:jwilliams@itee.uq.edu.au]
>>MicroBlaze is a highly configurable CPU in terms of its
>>instruction set,
>>features and so on. To make use of this, it is essential that each
>>kernel image be compiled to match the CPU configuration. While a
>>generic kernel, making use of no features (MUL, DIV, Shift,
>>MSR ops etc)
>>would run on any CPU, performance would be abysmal.
>
> I think the userspace is actually much more critical than the kernel for
> most of these things (with the exception of msrset/msrclr, and the
> barrel shifter perhaps). Unfortunately, even if you implement an
> alternatives-style mechanism for the kernel, you're still hosed for
> userspace.
I haven't benchmarks each option on the kernel - you are right that
shift is a big one, but mul I think is also important, given that every
array access generates an integer multiply,
Once I a big enough system, it's just unfeasible to
> recompile everything anyway. I think this is where autoconfig starts to
> break down.
I'm not sure I agree, here, given that most people building MicroBlaze
systems are doing so with uClinux-dist (or PetaLinux), you can do a full
rebuilt, kernel libs apps, in a couple of minutes. Much shorter than
sythnesis and P&R, that's for sure (and runtime is linear in size,
unlike P&R :)
> It's not nice, I agree. I think the key principle should be that I
> should be able to get a system working as quickly as possible, and I
> might optimize things later. One thing that device trees will allow is
> for *all* the drivers to get compiled in to the kernel, and only as a
> late stage operation does a designer need to start throwing things away.
> Using traps I can easily start with a 'kitchen sink' design, and start
> discarding processor features, relying on the traps. When I get low
> enough down on the performance curve, I can uas an autoconfig-type
> mechanism to regain a little of what I lost by optimizing away the trap
> overhead.
OK, but now we have a kernel dependent on *3* files - a DTS, a
Kconfig.auto, and (indirectly) the bitstream itself.
> Personally, I think the easiest way out of all this is to just have less
> configurability. For microblaze in general, this is too much of a
> restriction, but microblaze used as a control processor running linux,
> there are probably just a few design points that really make sense
> (probably size optimized: no options except maybe msrset/msrclr, and the
> kitchen sink). If we go that far, we don't really need people to ever
> run autoconfig, or kernels, or anything. Especially considering there
> is no easy way of selecting which of the 2^N design points I want
> *anyway*. :)
My experience tells me that if the microblaze can be configured in a
particular way, *someone* will want to do it (and still boot linux on
it!) We still have people building MicroBlaze 3.00 in Spartan2E, with
EDK 6.3. And autoconfig works! Exceptions on/off, MMU on/off (runtime
configurable on that?).
Our ability to plug into the backend design database of EDK presents a
great opportunity - truly automatically configured kernels. I think we
have a responsibility to leverage that power. We are already there
with the static approach, I think we just need to make sure that
persists into the dynamic approach, and that we find a good mix of the two.
There are of course some semantic issues that the EDK cannot
automatically resolve - relative ordering and priority of multiple
peripheral instances for example.
>>One compromise approach might be to have a script in
>>arch/microblaze/scripts, called by the arch Makefile, that
>>cracks open
>>the DT at build time and extracts appropriate cpu flags.
>
> Hmm... interesting idea, although parsing the source is likely
> difficult... It's probably not worth it to go this far, I think. As
> you say, why doesn't autoconfig of today work fine for this.
Well, copying multiple configuration files into the kernel is not ideal.
Surely a little perl or python script would do the trick? DTS syntax
is pretty clean, just find the CPU node and off we go. Multiple CPU,
well... :)
>>Finally, what is the LKML position on DT files going into the kernel
>>source tree?
>
>
> Source .dts go in and get compiled to binary blobs at compile time. The
> 'big' recent controversy is whether the source->binary compiler dtc
> should be mirrored in the Linux tree or not.
OK.
Another thing I suggested to Michal recently, perhaps we need
kernel/lib/libof to store common OF / DT handling code. Much better
than duplicating it accross microblaze and PPC, and maybe other arch's
would also see the light.. That would also add a claim for the DTC to
go in scripts/
John
^ permalink raw reply
* Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
From: Stephen Rothwell @ 2007-11-28 0:41 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <20071127153908.GB14183@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 599 bytes --]
On Tue, 27 Nov 2007 18:39:08 +0300 Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> +static int __devinit pata_of_platform_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + uint32_t *prop;
Make this "const uint32_t *prop" or (more kernel like) "const u32 *prop" ...
> + prop = (uint32_t *)of_get_property(dn, "ioport-shift", NULL);
then you don't need this cast. Anytime you use a cast to get rid of
"const", is probably a mistake.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: Xilinx devicetrees
From: Stephen Neuendorffer @ 2007-11-28 0:28 UTC (permalink / raw)
To: John Williams; +Cc: Michal Simek, linuxppc-embedded
In-Reply-To: <474CAE70.3030005@itee.uq.edu.au>
=20
> -----Original Message-----
> From: John Williams [mailto:jwilliams@itee.uq.edu.au]=20
> Sent: Tuesday, November 27, 2007 3:55 PM
> To: Stephen Neuendorffer
> Cc: David H. Lynch Jr.; linuxppc-embedded; Michal Simek
> Subject: Re: Xilinx devicetrees
>=20
>=20
> MicroBlaze is a highly configurable CPU in terms of its=20
> instruction set,=20
> features and so on. To make use of this, it is essential that each=20
> kernel image be compiled to match the CPU configuration. While a=20
> generic kernel, making use of no features (MUL, DIV, Shift,=20
> MSR ops etc)=20
> would run on any CPU, performance would be abysmal.
I think the userspace is actually much more critical than the kernel for
most of these things (with the exception of msrset/msrclr, and the
barrel shifter perhaps). Unfortunately, even if you implement an
alternatives-style mechanism for the kernel, you're still hosed for
userspace. Once I a big enough system, it's just unfeasible to
recompile everything anyway. I think this is where autoconfig starts to
break down.
> In my view it's not acceptable to present these as options=20
> for the user=20
> to select at kernel config time. With N yes/no parameters, there is 1=20
> correct configuration, and 2^N-1 incorrect ones. The odds of=20
> the user=20
> falling upon a configuration that at worst fails to boot, or=20
> at best is=20
> not optimally matched to the hardware, are high.
Yes. Autoconfig does handle this in a fairly nice way.
> This same issue also applies to C libraries and apps - they must be=20
> compiled with prior knowledge of the CPU. This is why our=20
> microblaze-uclinux-gcc toolchain, with multilib'd uClibc, is=20
> almost 400meg!
>=20
> Wrapping every mul, div, shift etc in a function call is clearly not=20
> feasible. Things like the msrset/msrclr ops have a modest but=20
> measurable impact on kernel code size and performance - it's just not=20
> reasonable to add any level of indirection in there.
>=20
> I have thought about dynamic (boot-time) code re-writing as one=20
> possibility here, but it very quickly gets nasty. All of the=20
> "optimised" opcodes (MUL/DIV/Shift etc) are smaller than=20
> their emulated=20
> counterparts, so in principle we could re-write the text segment with=20
> the optimised opcode, then NOP pad, but that's still inefficient. As=20
> soon as we start talking about dynamic code relocation, re-writing=20
> relative offsets in loops, ... yuck.. We'd be putting half of mb-ld=20
> into the arch early boot code (or bootloader...)
>=20
> The opposite approach, to build with all instructions enabled and=20
> install exception handlers to deal with the fixups, is also=20
> pretty awful.
It's not nice, I agree. I think the key principle should be that I
should be able to get a system working as quickly as possible, and I
might optimize things later. One thing that device trees will allow is
for *all* the drivers to get compiled in to the kernel, and only as a
late stage operation does a designer need to start throwing things away.
Using traps I can easily start with a 'kitchen sink' design, and start
discarding processor features, relying on the traps. When I get low
enough down on the performance curve, I can uas an autoconfig-type
mechanism to regain a little of what I lost by optimizing away the trap
overhead.=20
Personally, I think the easiest way out of all this is to just have less
configurability. For microblaze in general, this is too much of a
restriction, but microblaze used as a control processor running linux,
there are probably just a few design points that really make sense
(probably size optimized: no options except maybe msrset/msrclr, and the
kitchen sink). If we go that far, we don't really need people to ever
run autoconfig, or kernels, or anything. Especially considering there
is no easy way of selecting which of the 2^N design points I want
*anyway*. :)
> I find myself asking the question - for what use cases does=20
> the current=20
> static approach used in MicroBlaze (with the PetaLinux BSP /=20
> Kconfig.auto) *not* work?
>=20
> One compromise approach might be to have a script in=20
> arch/microblaze/scripts, called by the arch Makefile, that=20
> cracks open=20
> the DT at build time and extracts appropriate cpu flags.
Hmm... interesting idea, although parsing the source is likely
difficult... It's probably not worth it to go this far, I think. As
you say, why doesn't autoconfig of today work fine for this.
> Finally, what is the LKML position on DT files going into the kernel=20
> source tree?
Source .dts go in and get compiled to binary blobs at compile time. The
'big' recent controversy is whether the source->binary compiler dtc
should be mirrored in the Linux tree or not.
Steve
^ permalink raw reply
* Re: Xilinx devicetrees
From: Grant Likely @ 2007-11-28 0:27 UTC (permalink / raw)
To: John Williams; +Cc: Stephen Neuendorffer, Michal Simek, linuxppc-embedded
In-Reply-To: <474CAE70.3030005@itee.uq.edu.au>
On 11/27/07, John Williams <jwilliams@itee.uq.edu.au> wrote:
> Hi folks,
>
> Stephen Neuendorffer wrote:
>
> > > Binding it to a kernel, is a non-starter for us.
> >
> > I agree that this is not the best way of leveraging the power of device
> > trees. The point is that by using a device tree, you haven't lost
> > anything you can do currently. In the future we might have one kernel
> > which supports all versions of all our IP, along with all flavors of
> > microblaze and powerpc... You would only ever need to recompile this
> > kernel as a final optimization, if at all.
>
> I strongly support the OF / device tree work being done, from its own
> perspective and also as a path to MicroBlaze/PPC unification, however
> there is one critical difference that I have not seen adequately
> addressed yet.
>
> MicroBlaze is a highly configurable CPU in terms of its instruction set,
> features and so on. To make use of this, it is essential that each
> kernel image be compiled to match the CPU configuration. While a
> generic kernel, making use of no features (MUL, DIV, Shift, MSR ops etc)
> would run on any CPU, performance would be abysmal.
Looks like you've found the point of diminishing returns. :-) It is
probably not appropriate to try and encode CPU configuration into the
device tree *unless* it is only used to determine whether or not the
kernel as compiled will run on that CPU; but even by then you're
already running code on the platform. :-)
>
> In my view it's not acceptable to present these as options for the user
> to select at kernel config time. With N yes/no parameters, there is 1
> correct configuration, and 2^N-1 incorrect ones. The odds of the user
> falling upon a configuration that at worst fails to boot, or at best is
> not optimally matched to the hardware, are high.
>
> This same issue also applies to C libraries and apps - they must be
> compiled with prior knowledge of the CPU. This is why our
> microblaze-uclinux-gcc toolchain, with multilib'd uClibc, is almost 400meg!
>
> Wrapping every mul, div, shift etc in a function call is clearly not
> feasible. Things like the msrset/msrclr ops have a modest but
> measurable impact on kernel code size and performance - it's just not
> reasonable to add any level of indirection in there.
>
> I have thought about dynamic (boot-time) code re-writing as one
> possibility here, but it very quickly gets nasty. All of the
> "optimised" opcodes (MUL/DIV/Shift etc) are smaller than their emulated
> counterparts, so in principle we could re-write the text segment with
> the optimised opcode, then NOP pad, but that's still inefficient. As
> soon as we start talking about dynamic code relocation, re-writing
> relative offsets in loops, ... yuck.. We'd be putting half of mb-ld
> into the arch early boot code (or bootloader...)
>
> The opposite approach, to build with all instructions enabled and
> install exception handlers to deal with the fixups, is also pretty awful.
>
> I find myself asking the question - for what use cases does the current
> static approach used in MicroBlaze (with the PetaLinux BSP /
> Kconfig.auto) *not* work?
>
> One compromise approach might be to have a script in
> arch/microblaze/scripts, called by the arch Makefile, that cracks open
> the DT at build time and extracts appropriate cpu flags.
>
> Finally, what is the LKML position on DT files going into the kernel
> source tree?
arch/powerpc is awash with .dts files in the kernel tree. It's a
practice that is encouraged for most of the embedded boards. :-)
However, for something like xilinx virtex ppc and microblaze it
probably doesn't make much sense for anything other than the Xilinx
reference design bitstreams. (at least in mainline)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] powerpc: fix os-term usage on kernel panic
From: Will Schmidt @ 2007-11-28 0:15 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071120012815.GB7969@austin.ibm.com>
(resending with the proper "from" addr this time).
I'm seeing some funky behavior on power5/power6 partitions with this
patch. A "/sbin/reboot" is now behaving much more like a
"/sbin/halt".
Anybody else seeing this, or is it time for me to call an exorcist for
my boxes?
-Will
On Mon, 2007-11-19 at 19:28 -0600, Linas Vepstas wrote:
> The rtas_os_term() routine was being called at the wrong time.
> The actual rtas call "os-term" will not ever return, and so
> calling it from the panic notifier is too early. Instead,
> call it from the machine_reset() call.
>
> The patch splits the rtas_os_term() routine into two: one
> part to capture the kernel panic message, invoked during
> the panic notifier, and another part that is invoked during
> machine_reset().
>
> Prior to this patch, the os-term call was never being made,
> because panic_timeout was always non-zero. Calling os-term
> helps keep the hypervisor happy! We have to keep the hypervisor
> happy to avoid service, dump and error reporting problems.
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
>
> ----
> One could make a strong argument to move all of this code
> from kernel/rtas.c to platforms/pseries/setup.c I did not
> do this, just so as to make the changes minimal.
>
> arch/powerpc/kernel/rtas.c | 12 ++++++------
> arch/powerpc/platforms/pseries/setup.c | 3 ++-
> include/asm-powerpc/rtas.h | 3 ++-
> 3 files changed, 10 insertions(+), 8 deletions(-)
>
> Index: linux-2.6.24-rc2-git4/arch/powerpc/kernel/rtas.c
> ===================================================================
> --- linux-2.6.24-rc2-git4.orig/arch/powerpc/kernel/rtas.c 2007-11-19 18:58:53.000000000 -0600
> +++ linux-2.6.24-rc2-git4/arch/powerpc/kernel/rtas.c 2007-11-19 19:01:10.000000000 -0600
> @@ -631,18 +631,18 @@ void rtas_halt(void)
> /* Must be in the RMO region, so we place it here */
> static char rtas_os_term_buf[2048];
>
> -void rtas_os_term(char *str)
> +void rtas_panic_msg(char *str)
> {
> - int status;
> + snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
> +}
>
> - if (panic_timeout)
> - return;
> +void rtas_os_term(void)
> +{
> + int status;
>
> if (RTAS_UNKNOWN_SERVICE == rtas_token("ibm,os-term"))
> return;
>
> - snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
> -
> do {
> status = rtas_call(rtas_token("ibm,os-term"), 1, 1, NULL,
> __pa(rtas_os_term_buf));
> Index: linux-2.6.24-rc2-git4/arch/powerpc/platforms/pseries/setup.c
> ===================================================================
> --- linux-2.6.24-rc2-git4.orig/arch/powerpc/platforms/pseries/setup.c 2007-11-19 18:58:53.000000000 -0600
> +++ linux-2.6.24-rc2-git4/arch/powerpc/platforms/pseries/setup.c 2007-11-19 19:01:10.000000000 -0600
> @@ -507,7 +507,8 @@ define_machine(pseries) {
> .restart = rtas_restart,
> .power_off = pSeries_power_off,
> .halt = rtas_halt,
> - .panic = rtas_os_term,
> + .panic = rtas_panic_msg,
> + .machine_shutdown = rtas_os_term,
> .get_boot_time = rtas_get_boot_time,
> .get_rtc_time = rtas_get_rtc_time,
> .set_rtc_time = rtas_set_rtc_time,
> Index: linux-2.6.24-rc2-git4/include/asm-powerpc/rtas.h
> ===================================================================
> --- linux-2.6.24-rc2-git4.orig/include/asm-powerpc/rtas.h 2007-11-19 18:58:53.000000000 -0600
> +++ linux-2.6.24-rc2-git4/include/asm-powerpc/rtas.h 2007-11-19 19:01:10.000000000 -0600
> @@ -164,7 +164,8 @@ extern int rtas_call(int token, int, int
> extern void rtas_restart(char *cmd);
> extern void rtas_power_off(void);
> extern void rtas_halt(void);
> -extern void rtas_os_term(char *str);
> +extern void rtas_panic_msg(char *str);
> +extern void rtas_os_term(void);
> extern int rtas_get_sensor(int sensor, int index, int *state);
> extern int rtas_get_power_level(int powerdomain, int *level);
> extern int rtas_set_power_level(int powerdomain, int level, int *setlevel);
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] [POWERPC] kernel_execve is identical in 32 and 64 bit
From: Stephen Rothwell @ 2007-11-28 0:13 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
so concolidate it into misc.S.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/misc.S | 8 ++++++++
arch/powerpc/kernel/misc_32.S | 7 -------
arch/powerpc/kernel/misc_64.S | 7 -------
3 files changed, 8 insertions(+), 14 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/kernel/misc.S b/arch/powerpc/kernel/misc.S
index 330c9dc..74ce0c7 100644
--- a/arch/powerpc/kernel/misc.S
+++ b/arch/powerpc/kernel/misc.S
@@ -14,6 +14,7 @@
* 2 of the License, or (at your option) any later version.
*/
#include <asm/ppc_asm.h>
+#include <asm/unistd.h>
.text
@@ -43,3 +44,10 @@ _GLOBAL(add_reloc_offset)
add r3,r3,r5
mtlr r0
blr
+
+_GLOBAL(kernel_execve)
+ li r0,__NR_execve
+ sc
+ bnslr
+ neg r3,r3
+ blr
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index 8b642ab..ea11378 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -793,13 +793,6 @@ _GLOBAL(kernel_thread)
addi r1,r1,16
blr
-_GLOBAL(kernel_execve)
- li r0,__NR_execve
- sc
- bnslr
- neg r3,r3
- blr
-
/*
* This routine is just here to keep GCC happy - sigh...
*/
diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index bbb3ba5..a3c491e 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -518,13 +518,6 @@ _GLOBAL(giveup_altivec)
#endif /* CONFIG_ALTIVEC */
-_GLOBAL(kernel_execve)
- li r0,__NR_execve
- sc
- bnslr
- neg r3,r3
- blr
-
/* kexec_wait(phys_cpu)
*
* wait for the flag to change, indicating this kernel is going away but
--
1.5.3.6
^ permalink raw reply related
* Re: Xilinx devicetrees
From: John Williams @ 2007-11-27 23:55 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: Michal Simek, linuxppc-embedded
In-Reply-To: <20071125181506.EE2041BA004F@mail141-cpk.bigfish.com>
Hi folks,
Stephen Neuendorffer wrote:
> > Binding it to a kernel, is a non-starter for us.
>
> I agree that this is not the best way of leveraging the power of device
> trees. The point is that by using a device tree, you haven't lost
> anything you can do currently. In the future we might have one kernel
> which supports all versions of all our IP, along with all flavors of
> microblaze and powerpc... You would only ever need to recompile this
> kernel as a final optimization, if at all.
I strongly support the OF / device tree work being done, from its own
perspective and also as a path to MicroBlaze/PPC unification, however
there is one critical difference that I have not seen adequately
addressed yet.
MicroBlaze is a highly configurable CPU in terms of its instruction set,
features and so on. To make use of this, it is essential that each
kernel image be compiled to match the CPU configuration. While a
generic kernel, making use of no features (MUL, DIV, Shift, MSR ops etc)
would run on any CPU, performance would be abysmal.
In my view it's not acceptable to present these as options for the user
to select at kernel config time. With N yes/no parameters, there is 1
correct configuration, and 2^N-1 incorrect ones. The odds of the user
falling upon a configuration that at worst fails to boot, or at best is
not optimally matched to the hardware, are high.
This same issue also applies to C libraries and apps - they must be
compiled with prior knowledge of the CPU. This is why our
microblaze-uclinux-gcc toolchain, with multilib'd uClibc, is almost 400meg!
Wrapping every mul, div, shift etc in a function call is clearly not
feasible. Things like the msrset/msrclr ops have a modest but
measurable impact on kernel code size and performance - it's just not
reasonable to add any level of indirection in there.
I have thought about dynamic (boot-time) code re-writing as one
possibility here, but it very quickly gets nasty. All of the
"optimised" opcodes (MUL/DIV/Shift etc) are smaller than their emulated
counterparts, so in principle we could re-write the text segment with
the optimised opcode, then NOP pad, but that's still inefficient. As
soon as we start talking about dynamic code relocation, re-writing
relative offsets in loops, ... yuck.. We'd be putting half of mb-ld
into the arch early boot code (or bootloader...)
The opposite approach, to build with all instructions enabled and
install exception handlers to deal with the fixups, is also pretty awful.
I find myself asking the question - for what use cases does the current
static approach used in MicroBlaze (with the PetaLinux BSP /
Kconfig.auto) *not* work?
One compromise approach might be to have a script in
arch/microblaze/scripts, called by the arch Makefile, that cracks open
the DT at build time and extracts appropriate cpu flags.
Finally, what is the LKML position on DT files going into the kernel
source tree?
Regards,
John
^ permalink raw reply
* Re: 85xx software reset problems from paulus.git
From: Dale Farnsworth @ 2007-11-27 23:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <751B3227-484E-45BE-B233-D4A8CAC2F3FD@kernel.crashing.org>
On Tue, Nov 27, 2007 at 10:26:59AM -0600, Kumar Gala wrote:
> On Nov 27, 2007, at 8:54 AM, Dale Farnsworth wrote:
> >I wrote:
> >>Kumar Gala wrote:
> >>>>>Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or
> >>>>>when
> >>>>>calling 'reboot' in the shell, it just hangs. Using the same dts
> >>>>>and
> >>>>>resets in 2.6.23.1 reboots fine. I don't have a cds reference, but
> >>>>>someone who does should be able to confirm whether the issue
> >>>>>exists
> >>>>>or
> >>>>>not by just attempting to reboot via bash.
> >>>
> >>>Can someone do a git-bisect and find the patch that breaks things?
> >>
> >>I'll see if I can reproduce it on my 8548cds. If so, I'll then git-
> >>bisect.
> >
> >I tried this with the current powerpc.git tree on my mpc8548cds, and
> >the reboot command works for me. The system rebooted just fine.
>
> I'm wondering if there is an issue rebooting if we are in an oops.
I still can't reproduce it. Current powerpc.git reboots OK after an
oops on my 8548cds. As long as I make it to "Rebooting in 180 seconds..",
it resets 3 minutes later. It may be hw-dependent as well as
sw-dependent.
-Dale
^ permalink raw reply
* Re: [PATCH] sys_indirect kernel implementation for PowerPC
From: Arnd Bergmann @ 2007-11-27 22:57 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071121144245.e8abf9e8.sfr@canb.auug.org.au>
On Wednesday 21 November 2007, Stephen Rothwell wrote:
> > +++ b/include/asm-powerpc/systbl.h
> > @@ -313,3 +313,4 @@ COMPAT_SYS_SPU(timerfd)
> > =A0SYSCALL_SPU(eventfd)
> > =A0COMPAT_SYS_SPU(sync_file_range2)
> > =A0COMPAT_SYS(fallocate)
> > +COMPAT_SYS(indirect)
>=20
> Do the SPUs want this?
Excellent question. Sorry for being late in my reply here. The calls
that are marked non-spu capable are those that are harmful when run
on the SPU, e.g. because they modify the signal mask -- the SPU cannot
receive signals itself.
sys_indirect is potentially very useful on the SPU, but we can't allow
it if it gives you access to all other syscalls. If we want to use it
on the SPU at some point, we may have to provide an alternative
implementation that walks the spu_syscall_table instead.
OTOH, if sys_indirect is mostly useful for the eventual addition of
syslets, we can leave it out, because syslets don't make sense if
you have no multithreading capability.
Arnd <><
^ permalink raw reply
* Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)
From: Dell Query @ 2007-11-27 10:47 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3859 bytes --]
Hi,
I am creating a simple program which will try to read the board ID of the PPC440EPx thru BCSR but when I load it, it gives me "Data Read PLB Error".
I am not sure if I missed out something.
I would really appreciate it if somebody could help me on this.
I have posted the source code below, as well as the complete message.
Many thanks!
SOURCE CODE:
----------------------------------------------------------------------
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/ioport.h>
#include <linux/delay.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
#include <asm/irq.h>
#include <asm/io.h>
#include <linux/i2c.h>
#include <linux/i2c-id.h>
#include <asm/ocp.h>
#include <asm/ibm4xx.h>
MODULE_LICENSE("GPL");
#define BCSR_BASE 0xC0002000
#define BCSR0 0
#define BCSR1 1
#define BCSR2 2
#define USER_LED 0x2
#define SIZE_TO_MAP 10
#define LED_ON 0
uint __iomem *bcsrbase = NULL;
static int __init initFunction(void) {
uint tmp;
printk("<1> Calling init function.\n");
printk("<1> bcsrbase value %p...\n",bcsrbase);
printk("<1> Remapping %x...\n",BCSR_BASE);
/*map*/
bcsrbase = ioremap(BCSR_BASE, SIZE_TO_MAP);
printk("<1> bcsrbase new value %p...\n",bcsrbase);
/*read value*/
/*based on PPC440EPx document, BCSR0 is BoardID*/
tmp = in_be32(bcsrbase + BCSR0 /* BCSR0 */);
printk("<1> BCSR0 %x...\n",tmp);
/*try to output something*/
//out_be32(bcsrbase , /*LED_ON*/);
return 0;
}
static void __exit cleanupFunction(void) {
printk("<1> Calling cleanup function.\n");
/*unmap*/
iounmap(bcsrbase);
}
module_init(initFunction);
module_exit(cleanupFunction);
----------------------------------------------------------------------
ERROR MESSAGE:
----------------------------------------------------------------------
/mnt/flash_fs/var/ftp # insmod bcsr.ko
Calling init function.
bcsrbase value 00000000...
Remapping c0002000...
bcsrbase new value d50fe000...
Machine check in kernel mode.
Data Read PLB Error
OPB to PLB3: BSTAT= 0x00000000
PLB3 to PLB4: BEAR=0xffffffffffff7fff BESR0=0x00000000 BESR1=0x00000000
PLB4 to PLB3: BEAR=0xfd7fffffffffffff BESR0=0x00000000 BESR1=0x00000000
PLB3 to OPB: BEAR=0xffffffff BESR0=0x00000000 BESR1=0x00000000
PLB3 arbiter: BEAR=0xbfffffef ACR=0x90000000 BESR=0x00000000
PLB4 to OPB1: BEAR=0x0000000efffbfffb BESR0=0x00000000 BESR1=0x00000000
PLB40 Arbiter: BEAR=0x00000000c0002000 ACR=0xde000000 BESR0=0x0f000000
PLB41 Arbiter: BEAR=0xfffffffffffffffa ACR=0xdf000000 BESR0=0x00000000
POB0: BEAR=0xc27e3194ffffffff BESR0=0x00000000 BESR1=0x00000000
OPB0: BEAR=0x0000000000000000 BSTAT=0x00000000
Oops: machine check, sig: 7 [#1]
NIP: D50FC07C LR: D50FC070 CTR: 00000000
REGS: c02bcf50 TRAP: 0202 Not tainted (2.6.21-rc4)
MSR: 00029000 <EE,ME> CR: 24004022 XER: 00000000
TASK = c05fe490[115] 'insmod' THREAD: cdc6c000
GPR00: D50FC070 CDC6DE80 C05FE490 00000023 0A00C100 00000001 00000000 00000031
GPR08: 00000000 D50FE000 000017E4 C0290000 04004022 1016F458 00000000 00000000
GPR16: 00000000 00000000 00000030 00000030 00000124 D51132BC 00000000 C0035E2C
GPR24: 00000022 D5108000 00000022 D50F7500 CF68A21C D50F0000 CF68A000 C0279CEC
NIP [D50FC07C] initFunction+0x7c/0x128 [bcsr]
LR [D50FC070] initFunction+0x70/0x128 [bcsr]
Call Trace:
[CDC6DE80] [D50FC070] initFunction+0x70/0x128 [bcsr] (unreliable)
[CDC6DEA0] [C003731C] sys_init_module+0xe4/0x1458
[CDC6DF40] [C0001AC4] ret_from_syscall+0x0/0x3c
Instruction dump:
60842000 38600000 48000065 7c601b78 3c60d50f 7c040378 386370e8 901d76a0
4800003d 813d76a0 7c0004ac 80890000 <0c040000> 4c00012c 3c60d50f 38637108
Bus error
----------------------------------------------------------------------
---------------------------------
Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how.
[-- Attachment #2: Type: text/html, Size: 4726 bytes --]
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Arnd Bergmann @ 2007-11-27 22:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Jan Kratochvil, Roland McGrath
In-Reply-To: <20071126220224.GA5606@host0.dyn.jankratochvil.net>
On Monday 26 November 2007, Jan Kratochvil wrote:
> Hi,
>=20
> this testcase:
> =A0=A0=A0=A0=A0=A0=A0=A0http://people.redhat.com/jkratoch/dabr-lost.c
>=20
> reproduces a PPC DABR kernel bug. =A0The variable `variable' should not g=
et
> modified as the thread modifying it should be caught by its DABR:
>=20
> $ ./dabr-lost
> TID 30914: DABR 0x10012a77 NIP 0x80f6ebb318
> TID 30915: DABR 0x10012a77 NIP 0x80f6ebb318
> TID 30916: DABR 0x10012a77 NIP 0x80f6ebb318
> TID 30914: hitting the variable
> TID 30915: hitting the variable
> TID 30916: hitting the variable
> variable found =3D 30916, caught TID =3D 30914
> TID 30916: DABR 0x10012a77
> Variable got modified by a thread which has DABR still set!
>=20
This sounds like a bug recently reported by Uli Weigand. BenH
said he'd take a look, but it probably fell under the table.
The problem found by Uli is that on certain processors (Cell/B.E.
in his case), the DABRX register needs to be set in order for
the DABR to take effect.
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/3] [libata] pata_platform: make probe and remove functions device type neutral
From: Arnd Bergmann @ 2007-11-27 22:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-ide
In-Reply-To: <20071127153900.GA14183@localhost.localdomain>
On Tuesday 27 November 2007, Anton Vorontsov wrote:
> Split pata_platform_{probe,remove} into two pieces:
> 1. pata_platform_{probe,remove} -- platform_device-dependant bits;
> 2. __ptata_platform_{probe,remove} -- device type neutral bits.
>
> This is done to not duplicate code for the OF-platform driver.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ 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