RE: help with MPC8272ADS board
I've upgraded to the latest kernel (2.6.29), and after updating the configuration the cuImage did boot. What's the difference between the address for the early debug console for cuImage and uImage + blob? -Original Message- From: Scott Wood [mailto:scottw...@freescale.com] Sent: Monday, May 04, 2009 7:31 PM To: Landau, Bracha Cc: linuxppc-dev@ozlabs.org Subject: Re: help with MPC8272ADS board On Sun, May 03, 2009 at 10:16:29AM +0300, Landau, Bracha wrote: I'm trying to get the MPC8272ADS evaluation board up and running with the latest versions of u-boot and Denx linux (2.6.24). 2.6.24 is nowhere near the latest version of Linux. If you specifically want to use a Denx kernel, you're better off at e...@denx.de -- though I'd be surprised if that's the latest they offer, either. I use the device tree file (mpc8272ads.dts) provided. Based on another post, I updated the MPC8260ADS.h file, changing OF_CPU from c...@0mailto:c...@0 to PowerPC,8...@0, because I was getting an error. I'd rather change the device tree, instead. I tried booting both using a cuImage (cuImage.mpc8272ads) and a uImage with a device tree blob. Neither boot was successful, with no helpful information printed to the serial port. Is there any change that has to be made in order to get the board to boot? Upgrade to the latest kernel, and if it still doesn't work try enabling the early debug console (note that the default address is currently for cuImage). -Scott This e-mail is confidential, the property of NDS Ltd and intended for the addressee only. Any dissemination, copying or distribution of this message or any attachments by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please immediately notify the postmas...@nds.com and destroy the original message. Messages sent to and from NDS may be monitored. NDS cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of NDS. To protect the environment please do not print this e-mail unless necessary. NDS Limited Registered Office: One London Road, Staines,Middlesex TW18 4EX, United Kingdom. A company registered in England and Wales Registered no. 3080780 VAT no. GB 603 8808 40-00 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Need a patch tested on a windtunnel powermac
On Mon, 4 May 2009 23:02:16 +0200, Giuliano Pochini wrote: On Thu, 30 Apr 2009 09:30:59 +1000 Paul Mackerras pau...@samba.org wrote: Does anyone here still have a windtunnel powermac (PowerMac3,6) machine running Linux? We need someone to test Jean Delvare's patch to the therm_windtunnel driver. The patch is at: http://patchwork.ozlabs.org/patch/26095/ I don't have a windtunnel machine myself - I have a PowerMac3,5 but not a PowerMac3,6. I have a dual-G4 MDD (/proc/cpuinfo says PowerMac3,6). On: Linux Jay 2.6.30-rc4 #1 SMP Sun May 3 16:20:08 CEST 2009 ppc 7455, altivec supported PowerMac3,6 GNU/Linux plus the patch above seems working fine as usual: temperature reports are written in the logs and fan speed changes correctly. therm_windtunnel is not compiled as module. I tested it for a few hours only. Thanks for the report, Giuliano! I've added the information to the wiki. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER
Yeah, I agree. This needs a better description. I only know what's going on because I was there for the start of the discussion. But just to be sure, this is what I think is happening. When we add -pg to gcc, it automatically causes frame pointers to be used. Nope, it does no such thing. But with PPC, it always has frame pointers and there's no problem. Well, what do you call a frame pointer? In the general meaning of some register that points to the incoming function arguments and the function local variables, PowerPC can _usually_ use GPR1, the stack pointer (and indeed it is called stack frame pointer in the ABI). In the more narrow meaning of what GCC calls the frame pointer, the thing that -fomit-frame-pointer optimises away -- on PowerPC (and many other targets), -fomit-frame-pointer is the *default* when optimisation is enabled! There is a GCC bug here though: it won't allow both -pg and -fomit-frame-pointer be set at the command line at the same time, even on targets where that is not problematic. But with Linux, when you add CONFIG_FRAME_POINTER, it automatically adds: -fno-omit-frame-pointer. Thus the config will add -fomit-frame-pointer when CONFIG_FRAME_POINTER is not set, or it will add -fno-omit-frame-pointer when it is set. The problem with PPC is that -fno-omit-frame-pointer is buggy and causes gcc to produce bad code. It's a deeper problem that is only _exposed_ by -fno-o-f-p (and can be hidden by -mno-sched-epilog in the one spot where it hit us). Perhaps a better name would be: HAVE_FRAME_POINTER_AS_DEFAULT NO_NO_OMIT_FRAME_POINTER ? Or better, just never use -fno-o-f-p, I don't see why you would ever need it. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2.6.30-rc5] ehea: fix invalid pointer access
Hannes Hering hannes.her...@linux.vnet.ibm.com wrote:
pref = skb_array[x];
- prefetchw(pref);
- prefetchw(pref + EHEA_CACHE_LINE);
+ if (pref) {
+ prefetchw(pref);
+ prefetchw(pref + EHEA_CACHE_LINE);
Ummm... Is prefetch() or prefetchw() faulting?
David
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MSR_SPE - being turned off...
On May 4, 2009, at 5:25 PM, Morrison, Tom wrote: I have both a MPC8548 SBC and MPC8572 system that are running different flavors of the same Linux – 2.6.23. I explicitly am turning it on very early on. Later, I have an application that is compiled with SPE instructions (e.g.: evstdd) , and there is where the problems happen. If I explicitly make sure there are NO SPE instructions in the application, nothing bad happens! I am polling the MSR – and it seems the SPE is turned OFF? What have I done wrong and/or has there been fixes in later kernels that I should be aware of that might help this issue? Can you explain what you mean by explicitly am turning it on very early on. I can't think of anything that has changed w/regards to SPE handling. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2.6.30-rc5] ehea: fix invalid pointer access
On Tuesday 05 May 2009 11:11:27 David Howells wrote:
Hannes Hering hannes.her...@linux.vnet.ibm.com wrote:
pref = skb_array[x];
- prefetchw(pref);
- prefetchw(pref + EHEA_CACHE_LINE);
+ if (pref) {
+ prefetchw(pref);
+ prefetchw(pref + EHEA_CACHE_LINE);
Ummm... Is prefetch() or prefetchw() faulting?
David
Hi David,
this is an ehea driver problem, which is occuring when the receive queue runs
empty. The faulting code is more specifically the following line:
pref = (skb_array[x]-data);
Here the access to the struct element data would cause an exception.We could
have made the if block a little smaller.
Regards
Hannes
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/9] powerpc/pci: clean up direct access to sysdata
On Apr 30, 2009, at 9:50 AM, Michael Ellerman wrote: On Thu, 2009-04-30 at 09:18 -0500, Kumar Gala wrote: On Apr 30, 2009, at 8:49 AM, Michael Ellerman wrote: On Thu, 2009-04-30 at 08:09 -0500, Kumar Gala wrote: We shouldn't be accessing sysdata directly. In the future we might have sysdata be a device_node on ppc32 to match ppc64. Direct access would make that a bit difficult. If someone can look at the iseries code I would appreciate that: arch/powerpc/platforms/iseries/pci.c: iomm_table[current_iomm_table_entry] = dev-sysdata; arch/powerpc/platforms/iseries/pci.c: iseries_ds_addr(dev-sysdata) | (bar_num 24); arch/powerpc/platforms/iseries/pci.c: pdev-sysdata = node; It looks like it's basically doing the same logic as pci_device_to_OF_node(), and fetch_dev_dn(), but there's probably some reason why it's not using those. Given how much new iseries hardware there is, I think we'd probably rather leave the code as is. It's a device node anyway, so it doesn't block your plans RE ppc32. cheers I was already thinking along those lines, but figured I see if anyone is really maintaining iseries code :) Not that much, it would be sfr if anyone, but I think he's a bit busy :) cheers I was thinking about this a bit more and would like to clean up iseries as well. Either iseries is maintained by someone or its not. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: KGDBOC testing on linux-2.6.30-rc4
Hi all,
Target : PowerPC, Virtex-440 Generic
Serial port : Xilinx 16550 Uart ( depends on OF_PLATFORM)
Further investigation of KGDBOC on PowerPC shows that kgdboc hangs at :
In file : arch/powerpc/include/asm/kgdb.h
*static inline void* arch_kgdb_breakpoint(*void*)
{
*asm*(*.long 0x7d821008*); /* *twge r2, r2 **/ *
KGDBOC Hangs here* * ---*
-
Debug Log:
r...@10.1.2.55:~# echo g
/proc/sysrq-trigger
SysRq :
GDB
1sysrq_handle_gdb
Entering KGDB
1-1---kgdb_breakpoint
1-2---kgdb_breakpoint
1-3---kgdb_breakpoint
1-1---arch_kgdb_breakpoint
-
Any comments or suggestions
-Srikanth
--
On Mon, May 4, 2009 at 8:12 PM, Bruce Ashfield bruce.ashfi...@gmail.comwrote:
On Mon, May 4, 2009 at 9:13 AM, srikanth krishnakar
skrishna...@gmail.com wrote:
Hi all,
I need help in kgdboc testing on PowerPC target.
Have you tried contacting the maintainer ? (I noticed that Jason
wasn't cc'd), just in case it isn't simply a use case problem and
might be related to KGDB internals.
KGDB
P: Jason Wessel
M: jason.wes...@windriver.com
I've tested KGDBOC up to the 2.6.29 kernel and it worked fine
on a series of 85xx boards. I haven't had a chance on 2.6.30-rcX
yet, so something may have changed.
Linux Kernel: 2.6.30-rc4
KGDB method : KGDBOC
Arch: PowerPC
Note: Attached is the kernel config used.
Has anyone tested KGDBOC for Serial 8250, and the serial port has
dependency
on OF_PLATFORM driver ?
Here are the kernel config options:
Device Drivers ---
Character devices ---
Serial drivers ---
* 8250/16550 and
compatible serial support
[*] Console on
8250/16550 and compatible serial port
(4) Number of
8250/16550 serial ports to register at runtime
[ ] Extended
8250/16550
serial driver options
*** Non-8250 serial
port support ***
* Xilinx uartlite
serial port support
[*] Support for
console on Xilinx uartlite serial port
Digi
International
NEO PCI Support
* Serial port on
Open
Firmware platform bus
NWP serial port
driver
Kernel hacking ---
-*- Magic SysRq key
[*] Kernel debugging
[*] KGDB: kernel debugging with remote gdb
---
--- KGDB: kernel debugging with remote
gdb
* KGDB: use kgdb over the serial console
--
In the process :
On the target side :
...
Serial: 8250/16550 driver, 4 ports, IRQ
sharing
disabled
83e0.serial: ttyS0 at MMIO 0x83e01003
(irq
= 16) is a
16550A
console [ttyS0]
enabled
kgdb: Registered I/O driver kgdboc.
.
r...@10.161.2.35:~# echo g
/proc/sysrq-trigger
SysRq : GDB
Entering KGDB
On host side :
[r...@srikant linux-2.6]#
powerpc-linux-gnu-gdb
vmlinux-puru
GNU gdb G++ 4.3-150) 6.8.50.20081022-cvs
Copyright (C) 2008 Free Software Foundation,
Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change
and
redistribute it.
There is NO WARRANTY, to the extent permitted
by
law. Type show copying
and show warranty for details.
This GDB was configured as
--host=i686-pc-linux-gnu --target=powerpc-linux-gnu.
For bug reporting instructions, please see:
(gdb) set remotebaud 9600
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
Ignoring packet error, continuing...
warning: unrecognized item timeout in
qSupported
[PATCH] powerpc/pci: clean up direct access to sysdata by iseries platform
We shouldn't directly access sysdata to get the device node. We should
be calling pci_device_to_OF_node().
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/platforms/iseries/pci.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/iseries/pci.c
b/arch/powerpc/platforms/iseries/pci.c
index 02a634f..18343c3 100644
--- a/arch/powerpc/platforms/iseries/pci.c
+++ b/arch/powerpc/platforms/iseries/pci.c
@@ -318,6 +318,7 @@ static void __init iomm_table_allocate_entry(struct pci_dev
*dev, int bar_num)
{
struct resource *bar_res = dev-resource[bar_num];
long bar_size = pci_resource_len(dev, bar_num);
+ struct device_node *dn = pci_device_to_OF_node(dev);
/*
* No space to allocate, quick exit, skip Allocation.
@@ -335,9 +336,9 @@ static void __init iomm_table_allocate_entry(struct pci_dev
*dev, int bar_num)
* Allocate the number of table entries needed for BAR.
*/
while (bar_size 0 ) {
- iomm_table[current_iomm_table_entry] = dev-sysdata;
+ iomm_table[current_iomm_table_entry] = dn;
ds_addr_table[current_iomm_table_entry] =
- iseries_ds_addr(dev-sysdata) | (bar_num 24);
+ iseries_ds_addr(dn) | (bar_num 24);
bar_size -= IOMM_TABLE_ENTRY_SIZE;
++current_iomm_table_entry;
}
@@ -410,7 +411,7 @@ void __init iSeries_pcibios_fixup_resources(struct pci_dev
*pdev)
struct device_node *node;
int i;
- node = find_device_node(bus, pdev-devfn);
+ node = pci_device_to_OF_node(pdev);
pr_debug(PCI: iSeries %s, pdev %p, node %p\n,
pci_name(pdev), pdev, node);
if (!node) {
@@ -441,7 +442,6 @@ void __init iSeries_pcibios_fixup_resources(struct pci_dev
*pdev)
}
}
- pdev-sysdata = node;
allocate_device_bars(pdev);
iseries_device_information(pdev, bus, *sub_bus);
iommu_devnode_init_iSeries(pdev, node);
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/pci: cleanup some minor cruft
* Removed building setup-irq on ppc32, we don't use it anymore
* Remove duplicate prototype for setup_grackle() code that needs it
gets it from asm/grackle.h
* Removed gratuitous pci_io_size type differences between ppc32/ppc64
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/include/asm/pci-bridge.h |6 --
arch/powerpc/kernel/pci_32.c |8
drivers/pci/Makefile |1 -
3 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/include/asm/pci-bridge.h
b/arch/powerpc/include/asm/pci-bridge.h
index 90fcfc4..586138e 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -86,17 +86,12 @@ struct pci_controller {
void *io_base_alloc;
#endif
resource_size_t io_base_phys;
-#ifndef CONFIG_PPC64
resource_size_t pci_io_size;
-#endif
/* Some machines (PReP) have a non 1:1 mapping of
* the PCI memory space in the CPU bus space
*/
resource_size_t pci_mem_offset;
-#ifdef CONFIG_PPC64
- unsigned long pci_io_size;
-#endif
/* Some machines have a special region to forward the ISA
* memory cycles such as VGA memory regions. Left to 0
@@ -185,7 +180,6 @@ extern int early_find_capability(struct pci_controller
*hose, int bus,
extern void setup_indirect_pci(struct pci_controller* hose,
resource_size_t cfg_addr,
resource_size_t cfg_data, u32 flags);
-extern void setup_grackle(struct pci_controller *hose);
#else /* CONFIG_PPC64 */
/*
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index d473634..529e677 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -447,14 +447,6 @@ static int __init pcibios_init(void)
subsys_initcall(pcibios_init);
-/* the next one is stolen from the alpha port... */
-void __init
-pcibios_update_irq(struct pci_dev *dev, int irq)
-{
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq);
- /* XXX FIXME - update OF device tree node interrupt property */
-}
-
static struct pci_controller*
pci_bus_to_hose(int bus)
{
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index ba6af16..b77ae67 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -39,7 +39,6 @@ obj-$(CONFIG_ALPHA) += setup-bus.o setup-irq.o
obj-$(CONFIG_ARM) += setup-bus.o setup-irq.o
obj-$(CONFIG_PARISC) += setup-bus.o
obj-$(CONFIG_SUPERH) += setup-bus.o setup-irq.o
-obj-$(CONFIG_PPC32) += setup-irq.o
obj-$(CONFIG_PPC) += setup-bus.o
obj-$(CONFIG_MIPS) += setup-bus.o setup-irq.o
obj-$(CONFIG_X86_VISWS) += setup-irq.o
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/pci: Remove redundant pcnet32 fixup
The pcnet32 driver has had in its device id table for some time a match
against the broken vendor ID. No need to fake out the vendor ID
with an explicit fixup.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/kernel/pci_32.c | 11 ---
arch/powerpc/kernel/pci_64.c | 10 --
2 files changed, 0 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 529e677..3ae1c66 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -33,7 +33,6 @@ int pcibios_assign_bus_offset = 1;
void pcibios_make_OF_bus_map(void);
-static void fixup_broken_pcnet32(struct pci_dev* dev);
static void fixup_cpc710_pci64(struct pci_dev* dev);
#ifdef CONFIG_PPC_OF
static u8* pci_to_OF_bus_map;
@@ -72,16 +71,6 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MOTOROLA, PCI_ANY_ID,
fixup_hide_host_res
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID,
fixup_hide_host_resource_fsl);
static void
-fixup_broken_pcnet32(struct pci_dev* dev)
-{
- if ((dev-class8 == PCI_CLASS_NETWORK_ETHERNET)) {
- dev-vendor = PCI_VENDOR_ID_AMD;
- pci_write_config_word(dev, PCI_VENDOR_ID, PCI_VENDOR_ID_AMD);
- }
-}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TRIDENT,PCI_ANY_ID,
fixup_broken_pcnet32);
-
-static void
fixup_cpc710_pci64(struct pci_dev* dev)
{
/* Hide the PCI64 BARs from the kernel as their content doesn't
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index be574fc..fb9a0f8 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -43,16 +43,6 @@ unsigned long pci_probe_only = 1;
unsigned long pci_io_base = ISA_IO_BASE;
EXPORT_SYMBOL(pci_io_base);
-static void fixup_broken_pcnet32(struct pci_dev* dev)
-{
- if ((dev-class8 == PCI_CLASS_NETWORK_ETHERNET)) {
- dev-vendor = PCI_VENDOR_ID_AMD;
- pci_write_config_word(dev, PCI_VENDOR_ID, PCI_VENDOR_ID_AMD);
- }
-}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TRIDENT, PCI_ANY_ID,
fixup_broken_pcnet32);
-
-
static u32 get_int_prop(struct device_node *np, const char *name, u32 def)
{
const u32 *prop;
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'pci' branch into 'test'
Ben, Here are various pci related changes for 2.6.31 that can look at going into your test tree to see if they break anyone. It would be nice if this could get some testing on pseries by one of you guys as I have no access to such HW. - k Please pull from 'pci' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git pci to receive the following updates: arch/powerpc/include/asm/pci-bridge.h |7 -- arch/powerpc/kernel/pci_32.c | 19 arch/powerpc/kernel/pci_64.c | 10 arch/powerpc/kernel/pci_dn.c | 28 - arch/powerpc/kernel/rtas_pci.c | 10 +--- arch/powerpc/platforms/52xx/efika.c|4 +-- arch/powerpc/platforms/52xx/mpc52xx_pci.c |4 +-- arch/powerpc/platforms/cell/celleb_pci.c | 10 +--- arch/powerpc/platforms/cell/celleb_scc_epci.c | 13 +-- arch/powerpc/platforms/cell/celleb_scc_pciex.c | 12 +- arch/powerpc/platforms/chrp/pci.c |8 +++ arch/powerpc/platforms/iseries/pci.c |8 +++ arch/powerpc/platforms/powermac/setup.c|2 - arch/powerpc/platforms/pseries/setup.c | 25 ++ arch/powerpc/sysdev/fsl_pci.c |6 ++--- arch/powerpc/sysdev/indirect_pci.c |4 +-- arch/powerpc/sysdev/ppc4xx_pci.c |4 +-- arch/powerpc/sysdev/tsi108_pci.c |4 +-- drivers/pci/Makefile |1 19 files changed, 57 insertions(+), 122 deletions(-) Kumar Gala (13): powerpc/pci: clean up direct access to sysdata by indirect ops powerpc/pci: clean up direct access to sysdata by FSL platforms powerpc/pci: clean up direct access to sysdata by 52xx platforms powerpc/pci: clean up direct access to sysdata by 4xx platforms powerpc/pci: clean up direct access to sysdata by CHRP platforms powerpc/pci: clean up direct access to sysdata on tsi108 platforms powerpc/pci: clean up direct access to sysdata by powermac platforms powerpc/pci: clean up direct access to sysdata by RTAS powerpc/pci: clean up direct access to sysdata by celleb platforms powerpc/pci: clean up direct access to sysdata by iseries platform powerpc/pci: Move pseries code into pseries platform specific area powerpc/pci: cleanup some minor cruft powerpc/pci: Remove redundant pcnet32 fixup ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: MSR_SPE - being turned off...
Hi Kumar/Michael... Sorry, I really didn't explain myself very well... The Problem (answer to Michael): We started using a new compiler that upon -O2 optimization - added heavy SPE related instructions into our applications (where the older compiler might not use as many). Once this was done, we started experiencing problems with data being 'shifted' and/or corrupted throughout the applications which didn't immediately cause problems, but either scribbled on someone else's memory and/or bad results... We knew where one of the offending scribbles started (by the shifting by 1 byte of a structure) and found by comparing binaries with 'older' compiler vs. this one that the only major difference was the 'density' of the SPE instructions... As to your question, Kumar: === Naively, I explicitly enabled the SPE in a BSP 'early_init' program (as well as enabling Machine Checks) - which is what I meant by Enabling SPE... Michael explained that it is 'normal' if we asynchronously polled the MSR (in an application and/or in the kernel) that it might be disabled at the moment, but that you do a 'lazy switch' that enables it...and gets turned on when an SPE exception comes in... ...ok...I can live with that... ---where I was really going- This is where I was trying to go. A developer at our company (who no longer works for us) - did some research/development on the SPE functionality, in the hopes that we could create an optimized library. The results were successful, but because of some of the restrictions (including 8 byte alignment for some instructions) - we decided not to incorporate this library into our application(s) But, this developer in his results, indicated that he believed our kernels were NOT properly saving/restoring the upper 32bits of the GPR (which can/will be used in the SPE instructions)... Thus, if the upper 32bits were not saved (and restored when the application got the SPE to operate on)...then, he thought there would be problems. He unfortunately, was unable to finish his work and fix these 'bugs' before he left our company... Again, I am only going on his results, and not my own investigations (I am not sure where to start to find this problem to begin with)... So, I was REALLY asking - has anybody else run into this type of problem, and/or the Linux community has recognized this problem and has fixed this? -- I hope I am a little clearer in the history / and outline of the problem I am trying to solve this time? Thanks in advance! Tom Morrison -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Tuesday, May 05, 2009 7:08 AM To: Morrison, Tom Cc: linuxppc-dev@ozlabs.org Subject: Re: MSR_SPE - being turned off... On May 4, 2009, at 5:25 PM, Morrison, Tom wrote: I have both a MPC8548 SBC and MPC8572 system that are running different flavors of the same Linux - 2.6.23. I explicitly am turning it on very early on. Later, I have an application that is compiled with SPE instructions (e.g.: evstdd) , and there is where the problems happen. If I explicitly make sure there are NO SPE instructions in the application, nothing bad happens! I am polling the MSR - and it seems the SPE is turned OFF? What have I done wrong and/or has there been fixes in later kernels that I should be aware of that might help this issue? Can you explain what you mean by explicitly am turning it on very early on. I can't think of anything that has changed w/regards to SPE handling. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Kgdb-bugreport] KGDBOC testing on linux-2.6.30-rc4
On Tue, May 5, 2009 at 5:28 PM, Jason Wessel jason.wes...@windriver.comwrote:
srikanth krishnakar wrote:
Hi all,
Target : PowerPC, Virtex-440 Generic
Serial port : Xilinx 16550 Uart ( depends on OF_PLATFORM)
Further investigation of KGDBOC on PowerPC shows that kgdboc hangs at :
In file : arch/powerpc/include/asm/kgdb.h
*static inline void* arch_kgdb_breakpoint(*void*)
{
*asm*(*.long 0x7d821008*); /* *twge r2, r2 **/ *
KGDBOC Hangs here* * ---*
-
Debug Log:
r...@10.1.2.55:~# echo g
/proc/sysrq-trigger
SysRq :
GDB
1sysrq_handle_gdb
Entering KGDB
1-1---kgdb_breakpoint
1-2---kgdb_breakpoint
1-3---kgdb_breakpoint
1-1---arch_kgdb_breakpoint
-
Any comments or suggestions
I had used the 2.6.30-rc3 kernel with the PowerPC 604 system I have and
it was working fine, but the 4xx archs are a bit different.
What happens next after you execute the inline assembly is that an
exception occurs, and that is the point that the kgdb entry will
actually execute. IE:
arch/powerpc/kernel/traps.c
program_check_exception()
From there kgdb should be entered and the I/O driver gets activated.
You could put another printk in kgdb_handle_exception() in kernel/kgdb.c
to make sure it actually gets there.
Generally when the system hangs hard on an initial entry to kgdb it
means there is a problem with the I/O polling driver or there is
something else eating the kgdb exception and the kgdb exception handler
was never fired in the first place.
Jason.
Hi Jason,
Re attempted with inserting a printk in kernel/kgdb.c
kgdb_handle_exception() function but seems the kgdb exception has never
occurred !!
--
Debug Log:
r...@10.1.2.55:~# echo g /proc/sysrq-trigger
SysRq : GDB
1sysrq_handle_gdb
Entering KGDB
1-1---kgdb_breakpoint
1-2---kgdb_breakpoint
1-3---kgdb_breakpoint
1-1---arch_kgdb_breakpoint
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
Ignoring packet error, continuing...
warning: unrecognized item timeout in qSupported response
Ignoring packet error, continuing...
Ignoring packet error, continuing...
---
Inserted printk's in kernel kgdb.c :
int
kgdb_handle_exception(int evector, int signo, int ecode, struct pt_regs
*regs)
{
printk(1%s\n,__FUNCTION__);
if (kgdb_reenter_check(ks)) {
-
*Does the PowerPC uses PowerPC64 hooks ??*
as seen below from arch/powerpc/kernel/kgdb.c
/* KGDB functions to use existing PowerPC64 hooks. */
static int kgdb_debugger(struct pt_regs *regs)
{
printk(1%s\n,__FUNCTION__);
return *kgdb_handle_exception*(0, computeSignal(TRAP(regs)), 0,
regs);
---
Thanks For your co-operation, patience and help.
Regards
Srikanth
**
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER
On Tue, 2009-05-05 at 09:56 +0200, Segher Boessenkool wrote: Yeah, I agree. This needs a better description. I only know what's going on because I was there for the start of the discussion. But just to be sure, this is what I think is happening. When we add -pg to gcc, it automatically causes frame pointers to be used. Nope, it does no such thing. Well, mcount is expected to be able to get to not just who called mcount, but also the parent of that function. The way mcount is implemented does not let you do that. If mcount was the first thing to be called in a function, then it would have been perfect. We could get to the caller, its parent, and even the parameters. But unfortunately, mcount is called after the stack is set up. Thus, without frame pointers (the way to find a previous frame) there's no way (on some archs) to find the parent. Nor can we figure out the parameters, which really sucks. But with PPC, it always has frame pointers and there's no problem. Well, what do you call a frame pointer? In the general meaning of some register that points to the incoming function arguments and the function local variables, PowerPC can _usually_ use GPR1, the stack pointer (and indeed it is called stack frame pointer in the ABI). In the more narrow meaning of what GCC calls the frame pointer, the thing that -fomit-frame-pointer optimises away -- on PowerPC (and many other targets), -fomit-frame-pointer is the *default* when optimisation is enabled! There is a GCC bug here though: it won't allow both -pg and -fomit-frame-pointer be set at the command line at the same time, even on targets where that is not problematic. But with Linux, when you add CONFIG_FRAME_POINTER, it automatically adds: -fno-omit-frame-pointer. Thus the config will add -fomit-frame-pointer when CONFIG_FRAME_POINTER is not set, or it will add -fno-omit-frame-pointer when it is set. The problem with PPC is that -fno-omit-frame-pointer is buggy and causes gcc to produce bad code. It's a deeper problem that is only _exposed_ by -fno-o-f-p (and can be hidden by -mno-sched-epilog in the one spot where it hit us). Perhaps a better name would be: HAVE_FRAME_POINTER_AS_DEFAULT NO_NO_OMIT_FRAME_POINTER ? Or better, just never use -fno-o-f-p, I don't see why you would ever need it. Because on x86_64 it gives better back traces. x86_64 has no way to get to the previous frames without it. There's code to use other debug metadata to get back tracing, but for uses of things like the stack tracer, we need to be able to use the actual stack frames. As you said above, -fomit-frame-pointer is default when we optimize, and that is how the kernel is built. If we optimize on x86_64 and do not use -fno-omit-frame-pointer, the stack tracer is useless. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2.6.30-rc5] ehea: fix invalid pointer access
On Tuesday 05 May 2009 14:19:54 David Howells wrote:
In that case, you might want to move the prefetchw() calls in the following:
pref = skb_array[x];
- prefetchw(pref);
- prefetchw(pref + EHEA_CACHE_LINE);
+ if (pref) {
+ prefetchw(pref);
+ prefetchw(pref + EHEA_CACHE_LINE);
to before the if-statement. That way the CPU can be attempting the prefetch
whilst it's chewing over the test and branch. prefetching shouldn't fault on
a bad address.
David
Hi David,
you are right so far, but actually the prefetch calls on POWER also contain
an if statement to check if the address is valid (i. e. non-zero). We never
have the case that the pref != NULL and pref-data == NULL. And the situation
of pref==NULL is very rare. This means there is no benefit moving our if
statement down from performance perspective if we assume that our if does not
take longer then the if in the prefetch command. We can add an
if(likely(pref) if you like. In fact doing the if statement as we do it now
we actually save the prefetch if statements in case we hit the situation of
pref==NULL.
Regards
Hannes
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER
When we add -pg to gcc, it automatically causes frame pointers to be used. Nope, it does no such thing. Well, mcount is expected to be able to get to not just who called mcount, but also the parent of that function. The way mcount is implemented does not let you do that. If mcount was the first thing to be called in a function, then it would have been perfect. We could get to the caller, its parent, and even the parameters. But unfortunately, mcount is called after the stack is set up. Thus, without frame pointers (the way to find a previous frame) there's no way (on some archs) to find the parent. Nor can we figure out the parameters, which really sucks. Yes, and this is (supposedly) why GCC does not like seeing -pg and -fomit-frame-pointer at the same time -- because that cannot work *on some architectures*. These are the same architectures that do not enable -fomit-frame-pointer automatically at -O. NO_NO_OMIT_FRAME_POINTER ? Or better, just never use -fno-o-f-p, I don't see why you would ever need it. Because on x86_64 it gives better back traces. x86_64 has no way to get to the previous frames without it. There's code to use other debug metadata to get back tracing, but for uses of things like the stack tracer, we need to be able to use the actual stack frames. As you said above, -fomit-frame-pointer is default when we optimize, and that is how the kernel is built. If we optimize on x86_64 and do not use -fno-omit-frame-pointer, the stack tracer is useless. No. -fomit-frame-pointer is only the default when optimising on archs/ABIs where it doesn't hinder debugging and -pg and all that goodness; specifically, you do not get it by default on x86, not at any optimisation level. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[Patch] powerpc/cell: make ptcal more reliable (V2)
===
This is for QS21. The following patch allocates pages only from
the specified node, moves the ptcal area into the middle of the
allocated page to avoid potential prefetch problems and prints
the address of the ptcal area to facilitate diagnostics.
Signed-off-by: Gerhard Stenzel gerhard.sten...@de.ibm.com
Index: linux-2.6/arch/powerpc/platforms/cell/ras.c
===
--- linux-2.6.orig/arch/powerpc/platforms/cell/ras.c
+++ linux-2.6/arch/powerpc/platforms/cell/ras.c
@@ -122,12 +122,23 @@ static int __init cbe_ptcal_enable_on_no
area-nid = nid;
area-order = order;
- area-pages = alloc_pages_node(area-nid, GFP_KERNEL, area-order);
+ area-pages = alloc_pages_node(area-nid, GFP_KERNEL | GFP_THISNODE,
+ area-order);
- if (!area-pages)
+ if (!area-pages) {
+ printk(KERN_WARNING %s: no page on node %d\n,
+ __func__, area-nid);
goto out_free_area;
+ }
- addr = __pa(page_address(area-pages));
+ /*
+* We move the ptcal area to the middle of the allocated
+* page, in order to avoid prefetches in memcpy and similar
+* functions stepping on it.
+*/
+ addr = __pa(page_address(area-pages)) + (PAGE_SIZE 1);
+ printk(KERN_DEBUG %s: enabling PTCAL on node %d address=0x%016lx\n,
+ __func__, area-nid, addr);
ret = -EIO;
if (rtas_call(ptcal_start_tok, 3, 1, NULL, area-nid,
===
Best regards,
Gerhard Stenzel, Linux on Cell Development, LTC
-
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschaeftsfuehrung: Erich Baier
Sitz der Gesellschaft: Boeblingen | Registergericht: Amtsgericht Stuttgart, HRB
243294
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
modprobe problem
Hello, I have a Kernel 2.6.24 running on a custom board based on mpc8313erdb. My filesystem is composed by a read-only squashfs and a read-write jffs2 filesystems. A unionfs is used to unificate the filesystems. Like you know, when a file on my read-only squasfs is modified such file is copied to read-write jffs2 partition by unionfs. So, when you try to read such file again, the modified copy on jffs2 will be used. The kernel modules (.ko) are on squashfs and I am using modprobe to load the kernel modules. THE PROBLEM is when I try load a module using modprobe, this module is copied from squashfs to jffs2 filesystem. But, my intention is not modify the module, just load it. I am supposing that is a problem because the modules are using duplicated space in flash and I don't want to store the modules in jffs2 because the compression is lower. Does someone know why this happend? Thanks, Moratelli ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC8247 booting error
On Mon, May 04, 2009 at 10:23:50PM -0700, Sauce.Cheng wrote: i want to mapping FIFO memory to bank 3 by configure br3 and or3 the boot info as following. in my code, i have mapped FIFO to 0xD000, then i red the value from this address. the prompts as following there is some wrong with BRx and ORx set? or something others? You need to pass your physical address (0xd000) to ioremap() to obtain a virtual address that you can dereference. scheduling while atomic: swapper/0x0002/0 Call trace: [c015fe20] [c0003fe0] [c01a09b4] [c0194614] [35fc] You've got another problem here that you'll want to look into. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fix wrong register read address and add interrupt acknowledge.
The receive interrupt routine checks the wrong register if the receive fifo is empty. Further an explicit interrupt acknowledge write is introduced. In some circumstances another interrupt was issued. Signed-off-by: Benjamin Krill b...@codiert.org --- drivers/serial/nwpserial.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/serial/nwpserial.c b/drivers/serial/nwpserial.c index 32f3eaf..9e150b1 100644 --- a/drivers/serial/nwpserial.c +++ b/drivers/serial/nwpserial.c @@ -145,11 +145,13 @@ static irqreturn_t nwpserial_interrupt(int irq, void *dev_id) ch = dcr_read(up-dcr_host, UART_RX); if (up-port.ignore_status_mask != NWPSERIAL_STATUS_RXVALID) tty_insert_flip_char(tty, ch, TTY_NORMAL); - } while (dcr_read(up-dcr_host, UART_RX) UART_LSR_DR); + } while (dcr_read(up-dcr_host, UART_LSR) UART_LSR_DR); tty_flip_buffer_push(tty); ret = IRQ_HANDLED; + /* clear interrupt */ + dcr_write(up-dcr_host, UART_IIR, 1); out: spin_unlock(up-port.lock); return ret; -- 1.5.4.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix wrong register read address and add interrupt acknowledge.
On Tue, May 5, 2009 at 2:11 PM, Benjamin Krill b...@codiert.org wrote: The receive interrupt routine checks the wrong register if the receive fifo is empty. Further an explicit interrupt acknowledge write is introduced. In some circumstances another interrupt was issued. The one-line summary of your patch is too vague. It should mention the name of the driver somehow. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Setting Kernel Allocated Memory Uncached on the PPC460
On Mon, May 4, 2009 at 1:55 PM, Judd Gilbert ju...@tanisys.com wrote: I have a driver which maps some kernel allocated memory to user space which works, and now I am trying to set that memory non-cacheable, on a power PC using the Denx ELDK (linux-2.6.24) on a PPC460ex. Because of the way the kernel maps main memory, you cannot do this. It is a violation of the PowerPC architecture to map a particular memory address as both cached and uncached (using different TLB entries) at the same time. When the kernel boots, it uses large mappings to map all of memory as cached. There is no mechanism to punch holes in these mappings. Therefore, if the memory is already mapped cached by the kernel, you cannot remap it as uncached. The only way around this is to use high memory, which is not mapped by the kernel normally. You can bring in a high memory page and map it uncached. However, I don't think there is a way for you to manually specify certain memory to be high. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MSR_SPE - being turned off...
On May 5, 2009, at 7:56 AM, Morrison, Tom wrote: Hi Kumar/Michael... Sorry, I really didn't explain myself very well... The Problem (answer to Michael): We started using a new compiler that upon -O2 optimization - added heavy SPE related instructions into our applications (where the older compiler might not use as many). Once this was done, we started experiencing problems with data being 'shifted' and/or corrupted throughout the applications which didn't immediately cause problems, but either scribbled on someone else's memory and/or bad results... We knew where one of the offending scribbles started (by the shifting by 1 byte of a structure) and found by comparing binaries with 'older' compiler vs. this one that the only major difference was the 'density' of the SPE instructions... As to your question, Kumar: === Naively, I explicitly enabled the SPE in a BSP 'early_init' program (as well as enabling Machine Checks) - which is what I meant by Enabling SPE... Are you setting MSR_SPE in your own board code? If so stop doing so. There isn't any need or reason to be doing that. MSR_SPE will get set when an application starts using SPE code and the kernel will manage it properly. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v7] introduce macro spin_event_timeout()
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns the result of the condition when the loop
was terminated.
This primary purpose of this macro is to poll on a hardware register until a
status bit changes. The timeout ensures that the loop still terminates if the
bit doesn't change as expected. This macro makes it easier for driver
developers to perform this kind of operation properly.
Signed-off-by: Timur Tabi ti...@freescale.com
---
v7: add if-statement to use cpu_relax() if the delay is 0. gcc will optimize
out the if-statement if 'delay' is a constant.
I'm making this a PowerPC-specific patch because I want to use
tb_ticks_per_usec, which does not exist on all other platforms. I don't want
to use jiffies because jiffies works only when interrupts are enabled, and
the resolution may not be fine enough.
arch/powerpc/include/asm/delay.h | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/delay.h b/arch/powerpc/include/asm/delay.h
index f9200a6..2bde26f 100644
--- a/arch/powerpc/include/asm/delay.h
+++ b/arch/powerpc/include/asm/delay.h
@@ -2,6 +2,8 @@
#define _ASM_POWERPC_DELAY_H
#ifdef __KERNEL__
+#include asm/time.h
+
/*
* Copyright 1996, Paul Mackerras.
*
@@ -30,5 +32,35 @@ extern void udelay(unsigned long usecs);
#define mdelay(n) udelay((n) * 1000)
#endif
+/**
+ * spin_event_timeout - spin until a condition gets true or a timeout elapses
+ * @condition: a C expression to evalate
+ * @timeout: timeout, in microseconds
+ * @delay: the number of microseconds to delay between eache evaluation of
+ * @condition
+ * @rc: the last value of the condition
+ *
+ * The process spins until the condition evaluates to true (non-zero) or the
+ * timeout elapses. Upon exit, @rc contains the value of the condition. This
+ * allows you to test the condition without incurring any side effects.
+ *
+ * This primary purpose of this macro is to poll on a hardware register
+ * until a status bit changes. The timeout ensures that the loop still
+ * terminates even if the bit never changes. The delay is for devices that
+ * need a delay in between successive reads.
+ *
+ * gcc will optimize out the if-statement if @delay is a constant.
+ */
+#define spin_event_timeout(condition, timeout, delay, rc) \
+{ \
+ unsigned long __loops = tb_ticks_per_usec * timeout;\
+ unsigned long __start = get_tbl(); \
+ while (!(rc = (condition)) (tb_ticks_since(__start) = __loops)) \
+ if (delay) \
+ udelay(delay); \
+ else\
+ cpu_relax();\
+}
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_DELAY_H */
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Setting Kernel Allocated Memory Uncached on the PPC460
On Tue, May 05, 2009 at 04:16:45PM -0500, Timur Tabi wrote: On Mon, May 4, 2009 at 1:55 PM, Judd Gilbert ju...@tanisys.com wrote: I have a driver which maps some kernel allocated memory to user space which works, and now I am trying to set that memory non-cacheable, on a power PC using the Denx ELDK (linux-2.6.24) on a PPC460ex. Because of the way the kernel maps main memory, you cannot do this. It is a violation of the PowerPC architecture to map a particular memory address as both cached and uncached (using different TLB entries) at the same time. When the kernel boots, it uses large mappings to map all of memory as cached. There is no mechanism to punch holes in these mappings. Therefore, if the memory is already mapped cached by the kernel, you cannot remap it as uncached. The only way around this is to use high memory, which is not mapped by the kernel normally. You can bring in a high memory page and map it uncached. However, I don't think there is a way for you to manually specify certain memory to be high. That isn't entirely true. You can always limit the memory mapped via the kernel with mem= (or via a memreserve), and then have a driver ioremap the now unused memory. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix wrong register read address and add interrupt acknowledge.
On Tue, May 05, 2009 at 02:24:04PM -0500, Timur Tabi wrote: On Tue, May 5, 2009 at 2:11 PM, Benjamin Krill b...@codiert.org wrote: The receive interrupt routine checks the wrong register if the receive fifo is empty. Further an explicit interrupt acknowledge write is introduced. In some circumstances another interrupt was issued. The one-line summary of your patch is too vague. It should mention the name of the driver somehow. That is quite true. Although resending the patch just for that seems overkill. The maintainer can edit the summary rather easily. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER
On Tue, 2009-05-05 at 15:51 +0200, Segher Boessenkool wrote: When we add -pg to gcc, it automatically causes frame pointers to be used. Nope, it does no such thing. Well, mcount is expected to be able to get to not just who called mcount, but also the parent of that function. The way mcount is implemented does not let you do that. If mcount was the first thing to be called in a function, then it would have been perfect. We could get to the caller, its parent, and even the parameters. But unfortunately, mcount is called after the stack is set up. Thus, without frame pointers (the way to find a previous frame) there's no way (on some archs) to find the parent. Nor can we figure out the parameters, which really sucks. Yes, and this is (supposedly) why GCC does not like seeing -pg and -fomit-frame-pointer at the same time -- because that cannot work *on some architectures*. These are the same architectures that do not enable -fomit-frame-pointer automatically at -O. NO_NO_OMIT_FRAME_POINTER ? Or better, just never use -fno-o-f-p, I don't see why you would ever need it. Because on x86_64 it gives better back traces. x86_64 has no way to get to the previous frames without it. There's code to use other debug metadata to get back tracing, but for uses of things like the stack tracer, we need to be able to use the actual stack frames. As you said above, -fomit-frame-pointer is default when we optimize, and that is how the kernel is built. If we optimize on x86_64 and do not use -fno-omit-frame-pointer, the stack tracer is useless. No. -fomit-frame-pointer is only the default when optimising on archs/ABIs where it doesn't hinder debugging and -pg and all that goodness; specifically, you do not get it by default on x86, not at any optimisation level. OK, so what's the status with this patch series? I don't want to pull it in unless I have an ack from Sam, and now there's issues with having -fno-omit-frame-pointer. Should we add a patch instead that simply removes that? If we eliminate the -fno-omit-frame-pointer, would that solve the PPC problem? And would it cause any other issues with other archs? -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MSR_SPE - being turned off...
Hi Kumar/Michael... Sorry, I really didn't explain myself very well... The Problem (answer to Michael): =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D We started using a new compiler that upon -O2 optimization - added heavy SPE related instructions into our applications (where the older compiler might not use as many). Once this was done, we started=20 experiencing problems with data being 'shifted' and/or corrupted=20 throughout the applications which didn't immediately cause problems, but either scribbled on someone else's memory and/or bad results... We knew where one of the offending scribbles started (by the shifting=20 by 1 byte of a structure) and found by comparing binaries with 'older' compiler vs. this one that the only major difference was the 'density'=20 of the SPE instructions... As to your question, Kumar:=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Naively, I explicitly enabled the SPE in a BSP 'early_init' program=20 (as well as enabling Machine Checks) - which is what I meant by Enabling SPE... Yeah, you don't want to do this. It'll potentially break your application. I'm not that familiar with the CPU you are using but I'm guessing that you can't write the MSR from user space anyway. Michael explained that it is 'normal' if we asynchronously polled the MSR (in an application and/or in the kernel) that it might be disabled at the moment, but that you do a 'lazy switch' that=20 enables it...and gets turned on when an SPE exception comes in... ...ok...I can live with that... ---where I was really going- This is where I was trying to go. A developer at our company (who no longer works for us) - did some research/development on the SPE=20 functionality, in the hopes that we could create an optimized library. The results were successful, but because of some of the restrictions=20 (including 8 byte alignment for some instructions) - we decided not to incorporate this library into our application(s) But, this developer in his results, indicated that he believed our kernels were NOT properly saving/restoring the upper 32bits of the GPR (which can/will be used in the SPE instructions)... Thus, if the upper 32bits were not saved (and restored when the application got the SPE to operate on)...then, he thought there would be problems. He unfortunately, was unable to finish his work and fix these 'bugs' before he left our company... Again, I am only going on his results, and not my own investigations (I am not sure where to start to find this problem to begin with)... So, I was REALLY asking - has anybody else run into this type of problem, and/or the Linux community has recognized this problem and has fixed this? If GPRs where getting corrupted in userspace, that would be a serious bug and would be noticed by someone pretty quickly. We'd really need a test case to get anywhere with this report. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: MSR_SPE - being turned off...
The test case we found is under 'extreme' duress (intense loading on an MPC8572)...with many applications using A LOT of SPE instructions... If you look at the context switch code (in latest code entry_32.S), I believe the context switch performs a SAVE_NVGPR() - which in our interpretation (in ppc_asm.h) - only saves the lower 32 bits of the GPR (stw/lwz)... This is only a guess of where the problem lies - based upon the single SPE instruction that seemingly got misinterpreted, and shifts the data By '1 byte' (and this code gets executed successfully MANY more times at lower bandwidths - than failures seen at higher bandwidths)... I am not sure how to proceed...we know how to recreate with our application, but we would love to know how to change (safely) the pt_regs to long long for the GPRs and then safely move all 64bits of each GPR into these doubles... We could then re-test and see if this helps? Tom -Original Message- From: Michael Neuling [mailto:mi...@neuling.org] Sent: Tuesday, May 05, 2009 8:02 PM To: Morrison, Tom Cc: Kumar Gala; linuxppc-dev@ozlabs.org Subject: Re: MSR_SPE - being turned off... Hi Kumar/Michael... Sorry, I really didn't explain myself very well... The Problem (answer to Michael): =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = 3D= =3D=3D=3D=3D=3D=3D=3D We started using a new compiler that upon -O2 optimization - added heavy SPE related instructions into our applications (where the older compiler might not use as many). Once this was done, we started=20 experiencing problems with data being 'shifted' and/or corrupted=20 throughout the applications which didn't immediately cause problems, but either scribbled on someone else's memory and/or bad results... We knew where one of the offending scribbles started (by the shifting=20 by 1 byte of a structure) and found by comparing binaries with 'older' compiler vs. this one that the only major difference was the 'density'=20 of the SPE instructions... As to your question, Kumar:=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = 3D= =3D=3D Naively, I explicitly enabled the SPE in a BSP 'early_init' program=20 (as well as enabling Machine Checks) - which is what I meant by Enabling SPE... Yeah, you don't want to do this. It'll potentially break your application. I'm not that familiar with the CPU you are using but I'm guessing that you can't write the MSR from user space anyway. Michael explained that it is 'normal' if we asynchronously polled the MSR (in an application and/or in the kernel) that it might be disabled at the moment, but that you do a 'lazy switch' that=20 enables it...and gets turned on when an SPE exception comes in... ...ok...I can live with that... ---where I was really going- This is where I was trying to go. A developer at our company (who no longer works for us) - did some research/development on the SPE=20 functionality, in the hopes that we could create an optimized library. The results were successful, but because of some of the restrictions=20 (including 8 byte alignment for some instructions) - we decided not to incorporate this library into our application(s) But, this developer in his results, indicated that he believed our kernels were NOT properly saving/restoring the upper 32bits of the GPR (which can/will be used in the SPE instructions)... Thus, if the upper 32bits were not saved (and restored when the application got the SPE to operate on)...then, he thought there would be problems. He unfortunately, was unable to finish his work and fix these 'bugs' before he left our company... Again, I am only going on his results, and not my own investigations (I am not sure where to start to find this problem to begin with)... So, I was REALLY asking - has anybody else run into this type of problem, and/or the Linux community has recognized this problem and has fixed this? If GPRs where getting corrupted in userspace, that would be a serious bug and would be noticed by someone pretty quickly. We'd really need a test case to get anywhere with this report. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v7] introduce macro spin_event_timeout()
On Tue, 5 May 2009 16:53:05 -0500 Timur Tabi ti...@freescale.com wrote: The macro spin_event_timeout() takes a condition and timeout value (in microseconds) as parameters. It spins until either the condition is true or the timeout expires. It returns the result of the condition when the loop was terminated. This primary purpose of this macro is to poll on a hardware register until a status bit changes. The timeout ensures that the loop still terminates if the bit doesn't change as expected. This macro makes it easier for driver developers to perform this kind of operation properly. Signed-off-by: Timur Tabi ti...@freescale.com Nice. I could have used a routine like this in a couple of our drivers. So, for what it is worth: Acked-by: Sean MacLennan smaclen...@pikatech.com Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MSR_SPE - being turned off...
On May 5, 2009, at 7:42 PM, Morrison, Tom wrote: The test case we found is under 'extreme' duress (intense loading on an MPC8572)...with many applications using A LOT of SPE instructions... If you look at the context switch code (in latest code entry_32.S), I believe the context switch performs a SAVE_NVGPR() - which in our interpretation (in ppc_asm.h) - only saves the lower 32 bits of the GPR (stw/lwz)... This is only a guess of where the problem lies - based upon the single SPE instruction that seemingly got misinterpreted, and shifts the data By '1 byte' (and this code gets executed successfully MANY more times at lower bandwidths - than failures seen at higher bandwidths)... I am not sure how to proceed...we know how to recreate with our application, but we would love to know how to change (safely) the pt_regs to long long for the GPRs and then safely move all 64bits of each GPR into these doubles... We could then re-test and see if this helps? Tom If you use SPE in an application the full 64-bits are saved and restored it just split into two locations (one for the lower 32-bits and one for the upper 32-bits). Look at load_up_spe and giveup_spe in arch/powerpc/kernel/ head_fsl_booke.S On the 8572 are you running w/SMP? What kernel version are you using if so? Do you see the same issue on the MPC8548? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
