Benjamin Herrenschmidt wrote:
On Thu, 2008-11-13 at 14:29 -0800, Kevin Diggs wrote:
Benjamin Herrenschmidt wrote:
On Thu, 2008-11-13 at 03:38 -0800, Kevin Diggs wrote:
12,206 PowerMac Zilog interrupts
Interrupt load is higher without the DMA support.
Is it possible that this hardware
Well, the main thing is that when using DMA, it doesn't need to wait for
the kernel to come fetch the bytes, and thus the only latency that
matters if the DMA list is appropriately provisioned is the bus latency,
which is much less likely to be an issue even with a small buffer.
...
Benjamin Herrenschmidt wrote:
That's definitely strange. I would expect the kernel to be able to get
interrupts fast enough to service a 1200 bauds serial port. Maybe
there's something else wrong, or an other driver causing undue interrupt
latencies
As far as I can see the system is
On Nov 15, 2008, at 12:10 PM, Steven Rostedt wrote:
Kumar Gala wrote:
For some unknown reason at Steven Rostedt added in disabling of the
SPE
instruction generation for e500 based PPC cores in commit
6ec562328fda585be2d7f472cfac99d3b44d362a.
The unknown reason was that my PPC64 failed to
Here my rewritten patch for rs485 support for kernel 2.6.24.7
Read/write direction ot differential bus transceiver will be changed by /RTS
with output port register 0p0 and 0p1;
To switch uart to rs485 mode, a 1 has to be written to
/sys/dev/f.soc5200/f0002x000.serial/uartmode.
*void
On Mon, 17 Nov 2008, Paul Mackerras wrote:
Steven Rostedt writes:
The following patches are for my work on porting the new dynamic ftrace
framework to PowerPC. The issue I had with both PPC64 and PPC32 is
that the calls to mcount are 24 bit jumps. Since the modules are
loaded in
On Mon, 17 Nov 2008, Paul Mackerras wrote:
Steven Rostedt writes:
Impact: use cleaner probe_kernel API over assembly
Using probe_kernel_read/write interface is a much cleaner approach
than the current assembly version.
Possibly naive question: how is it possible for the accesses
On Mon, 17 Nov 2008, Paul Mackerras wrote:
Steven Rostedt writes:
+ if (!rec-arch.mod) {
+ if (!mod) {
+ printk(KERN_ERR No module loaded addr=%lx\n,
+ addr);
+ return -EFAULT;
+ }
+
The MSI capture logic for the axon bridge can sometimes
lose interrupts in case of high DMA and interrupt load,
when it signals an MSI interrupt to the MPIC interrupt
controller while we are already handling another MSI.
Each MSI vector gets written into a FIFO buffer in main
memory using DMA,
On Mon, 17 Nov 2008, Paul Mackerras wrote:
Steven Rostedt writes:
+ if (!rec-arch.mod) {
+ if (!mod) {
+ printk(KERN_ERR No module loaded addr=%lx\n,
+ addr);
+ return -EFAULT;
+ }
+
Signed-off-by: Paulius Zaleckas [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index 0ab0230..8670acc 100644
Impact: fix of test if an address is 26 bits away or not
Paul Mackerras pointed out that the test of the 24bit offset jump was
incorrect. For one thing, it is a 26 bit distance since we multiply
by 4 to account for the alignment. Another is that it may produce an
incorrect result on a negative
Impact: code clean up between PPC 32 and 64 bit platforms
The modification of code for dynamic ftrace between 32 bit and 64 bit PPC
platforms is a bit different. But there is also several things that are
similar. This patch consolidates some of the code between the two
algorithms so that fixes to
This series of patches addresses the problems with PPC dynamic ftrace
updates that Paul Mackerras pointed out.
The following patches are in:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
branch: tip/ppc
Steven Rostedt (4):
ftrace,ppc: consolidate dyn
forward to a better place...
On Sunday 16 November 2008 23:44:50 Fabiano Manoel de Andrade wrote:
Hi I've compiled the latest version of linux kernel (2.6.27.6) in my
PS3 running debian and get a warning message listed here
Setting the system clock.
Cannot access the
On Mon, 17 Nov 2008, Steven Rostedt wrote:
On Mon, 17 Nov 2008, Paul Mackerras wrote:
I've tested the following patches on both PPC64 and PPC32. I will
admit that the PPC64 does not seem that stable, but neither does the
code when all this is not enabled ;-) I'll debug it more to
On Thu, Oct 23, 2008 at 9:54 PM, David Gibson
[EMAIL PROTECTED] wrote:
This can be used to quickly implement a userspace usable console while
you're working on a proper driver for whatever console I/O device the
hardware has. Or, it can be used to avoid writing a full blown
tty/console
The convert-dtsv0 lexer doesn't use lex's input() macro/function.
This can result in defined but not used warnings. This patch uses
flex's noinput option to prevent this warning (as we already do for
dtc-lexer.l).
Signed-off-by: David Gibson [EMAIL PROTECTED]
Applied.
Thanks,
jdl
On Mon, 2008-11-17 at 02:21 -0800, Kevin Diggs wrote:
Benjamin Herrenschmidt wrote:
That's definitely strange. I would expect the kernel to be able to get
interrupts fast enough to service a 1200 bauds serial port. Maybe
there's something else wrong, or an other driver causing undue
On Thu, Oct 23, 2008 at 9:54 PM, David Gibson
[EMAIL PROTECTED] wrote:
One other thing ...
--- working-2.6.orig/drivers/char/Makefile 2008-10-22 15:50:59.0
+1100
+++ working-2.6/drivers/char/Makefile 2008-10-24 14:22:59.0 +1100
@@ -50,6 +50,7 @@ obj-$(CONFIG_HVC_BEAT)
We need to swap these out once we start using swiotlb, so add
them to dma_ops. When these are called, if the dma_op pointer
for the specific function is NULL, we just do nothing - most
of the 64-bit platforms don't actually need to do anything with
the sync so we don't require a sync function to
I've been hitting stack overflows on a PPC64 box, so I ran the ftrace
stack_tracer and part of the problem with that box is that it can nest
interrupts too deep. But what also worries me is that there's some heavy
hitters of stacks in generic code. Namely the fs directory has some.
Here's the
Kumar Gala wrote:
For some unknown reason at Steven Rostedt added in disabling of the SPE
instruction generation for e500 based PPC cores in commit
6ec562328fda585be2d7f472cfac99d3b44d362a.
We are removing it because:
1. It generates e500 kernels that don't work
2. its not the correct set of
On Mon, 17 Nov 2008, Steven Rostedt wrote:
Note, I was using a default config that had CONFIG_IRQSTACKS off and
CONFIG_PPC_64K_PAGES on.
Here's my stack after boot up with CONFIG_IRQSTACKS set. Seems that
softirqs still use the same stack as the process.
[EMAIL PROTECTED] ~ cat
On Mon, 17 Nov 2008, Steven Rostedt wrote:
45) 49921280 .block_read_full_page+0x23c/0x430
46) 37121280 .do_mpage_readpage+0x43c/0x740
Ouch.
Notice at line 45 and 46 the stack usage of block_read_full_page and
do_mpage_readpage. They each use 1280 bytes of stack!
On Mon, Nov 17, 2008 at 11:18 PM, Linus Torvalds
[EMAIL PROTECTED] wrote:
I do wonder just _what_ it is that causes the stack frames to be so
horrid. For example, you have
18) 8896 160 .kmem_cache_alloc+0xfc/0x140
and I'm looking at my x86-64 compile, and it has a stack
On Mon, 17 Nov 2008 13:23:23 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Mon, 17 Nov 2008, Andrew Morton wrote:
Far be it from me to apportion blame, but THIS IS ALL LINUS'S FAULT! :)
I fixed this six years ago. See http://lkml.org/lkml/2002/6/17/68
Btw, in that
On Mon, 17 Nov 2008, Andrew Morton wrote:
Yup. That being said, the younger me did assert that this is a neater
implementation anyway. If we can implement those loops without
needing those on-stack temporary arrays then things probably are better
overall.
Sure, if it actually ends up
It's over a dozen lines of output and doesn't appear to provide any useful
information. Even after looking at the code, I'm in the dark about what
score 299, offset 250 means.
Signed-off-by: Trent Piepho [EMAIL PROTECTED]
---
arch/powerpc/kernel/smp-tbsync.c | 12
1 files
On Nov 17, 2008, at 3:58 PM, Trent Piepho wrote:
It's over a dozen lines of output and doesn't appear to provide any
useful
information. Even after looking at the code, I'm in the dark about
what
score 299, offset 250 means.
Signed-off-by: Trent Piepho [EMAIL PROTECTED]
---
Steven Rostedt writes:
Here's my stack after boot up with CONFIG_IRQSTACKS set. Seems that
softirqs still use the same stack as the process.
They shouldn't. I don't see do_softirq in the trace, though. Which
functions did you think would be run in a softirq? It looks to me
like the deepest
On Mon, 17 Nov 2008, Kumar Gala wrote:
On Nov 17, 2008, at 3:58 PM, Trent Piepho wrote:
It's over a dozen lines of output and doesn't appear to provide any useful
information. Even after looking at the code, I'm in the dark about what
score 299, offset 250 means.
Signed-off-by: Trent
Linus Torvalds writes:
The ppc people run databases, and they don't care about sane people
And HPC apps, and all sorts of other things...
telling them the big pages suck. It's made worse by the fact that they
also have horribly bad TLB fills on their broken CPU's, and years and
Taking
On Fri, 2008-10-24 at 16:09 -0700, Trent Piepho wrote:
Let GPIO LEDs get their initial value from whatever the current state of
the GPIO line is. On some systems the LEDs are put into some state by the
firmware or hardware before Linux boots, and it is desired to have them
keep this state
These are inlines provided by the pci-dma-compat API.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
---
arch/powerpc/kernel/ppc_ksyms.c |2 --
1 file changed, 2 deletions(-)
--- everything.orig/arch/powerpc/kernel/ppc_ksyms.c 2008-11-17
23:58:35.0 +0100
+++
On Mon, 2008-11-17 at 15:34 -0500, Steven Rostedt wrote:
Note, I was using a default config that had CONFIG_IRQSTACKS off and
CONFIG_PPC_64K_PAGES on.
For one, we definitely need to turn IRQSTACKS on by default ... In fact,
I'm pondering just removing the option.
Cheers,
Ben.
On Mon, 2008-11-17 at 15:59 -0500, Steven Rostedt wrote:
On Mon, 17 Nov 2008, Steven Rostedt wrote:
Note, I was using a default config that had CONFIG_IRQSTACKS off and
CONFIG_PPC_64K_PAGES on.
Here's my stack after boot up with CONFIG_IRQSTACKS set. Seems that
softirqs still use the
Well, it's not unacceptable on good CPU's with 4kB blocks (just an 8-entry
array), but as you say:
On PPC64 I'm told that the page size is 64K, which makes the above equal
to: 64K / 512 = 128 multiply that by 8 byte words, we have 1024 bytes.
Yeah. Not good. I think 64kB pages are
On Tue, 18 Nov 2008 10:13:16 +1100
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
Well, it's not unacceptable on good CPU's with 4kB blocks (just an 8-entry
array), but as you say:
On PPC64 I'm told that the page size is 64K, which makes the above equal
to: 64K / 512 = 128
On Mon, 2008-11-17 at 14:22 -0800, Trent Piepho wrote:
On Mon, 17 Nov 2008, Kumar Gala wrote:
On Nov 17, 2008, at 3:58 PM, Trent Piepho wrote:
It's over a dozen lines of output and doesn't appear to provide any useful
information. Even after looking at the code, I'm in the dark about
On Tue, 18 Nov 2008, Benjamin Herrenschmidt wrote:
Guess who is pushing for larger page sizes nowadays ? Embedded
people :-) In fact, we have patches submited on the list to offer the
option for ... 256K pages on some 44x embedded CPUs :-)
It makes some sort of sense I suppose on very
On Tue, 18 Nov 2008, Paul Mackerras wrote:
Steven Rostedt writes:
Here's my stack after boot up with CONFIG_IRQSTACKS set. Seems that
softirqs still use the same stack as the process.
They shouldn't. I don't see do_softirq in the trace, though. Which
functions did you think would
On Mon, 2008-11-17 at 15:34 -0500, Steven Rostedt wrote:
I've been hitting stack overflows on a PPC64 box, so I ran the ftrace
stack_tracer and part of the problem with that box is that it can nest
interrupts too deep. But what also worries me is that there's some heavy
hitters of stacks
Linus Torvalds writes:
It's made worse by the fact that they
also have horribly bad TLB fills on their broken CPU's, and years and
years of telling people that the MMU on ppc's are sh*t has only been
reacted to with talk to the hand, we know better.
Who are you talking about
On Mon, 17 Nov 2008, Linus Torvalds wrote:
I do wonder just _what_ it is that causes the stack frames to be so
horrid. For example, you have
18) 8896 160 .kmem_cache_alloc+0xfc/0x140
and I'm looking at my x86-64 compile, and it has a stack frame of just 8
bytes (!)
I'm adding udbg support to my console driver, and I've noticed that
there is not much consistency on how the various platforms implement
udbg support. So I have a few questions:
1. What is the point of implementing udbg_getc? What does the console
do with any characters it receives this early?
On Mon, Nov 17, 2008 at 11:28:52AM -0500, Michael Barkowski wrote:
David Gibson wrote:
On Fri, Nov 14, 2008 at 10:16:19AM -0500, Michael Barkowski wrote:
David Gibson wrote:
On Thu, Nov 13, 2008 at 10:18:28AM -0500, Michael Barkowski wrote:
ethernet0 (called FSL UEC0 in U-Boot) should be
On Mon, Nov 17, 2008 at 01:41:24PM -0600, Timur Tabi wrote:
On Thu, Oct 23, 2008 at 9:54 PM, David Gibson
[EMAIL PROTECTED] wrote:
This patch adds a new backend for the hvc console based on the
low-level udbg callbacks. This effectively implements a working
runtime console in terms of the
On Mon, Nov 17, 2008 at 02:04:38PM -0600, Timur Tabi wrote:
On Thu, Oct 23, 2008 at 9:54 PM, David Gibson
[EMAIL PROTECTED] wrote:
This can be used to quickly implement a userspace usable console while
you're working on a proper driver for whatever console I/O device the
hardware has.
Steve,
On Mon, 17 Nov 2008, Linus Torvalds wrote:
I do wonder just _what_ it is that causes the stack frames to be so
horrid. For example, you have
18) 8896 160 .kmem_cache_alloc+0xfc/0x140
and I'm looking at my x86-64 compile, and it has a stack frame of just 8
Impact: fix PPC64 race condition
Milton Miller pointed out a nasty race with the current code of PPC64
dynamic ftrace. PPC64 keeps a table of content reference in the register
r2. If this gets corrupted, the kernel can crash. The calls to mcount are
replaced with nops. This is not the problem.
The following patch is in:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
branch: tip/ppc
Steven Rostedt (1):
ftrace,ppc64: do not use nops for modules
arch/powerpc/kernel/ftrace.c | 44 +++--
1 files changed,
On Tue, 18 Nov 2008, Paul Mackerras wrote:
64 bytes, still much lower than the 160 of PPC64.
The ppc64 ABI has a minimum stack frame of 112 bytes, due to having an
area for called functions to store their parameters (64 bytes) plus 6
slots for saving stuff and for the compiler and
On Thursday 13 November 2008, Anton Vorontsov wrote:
Gadgets disable endpoints in their disconnect callbacks, so
we must call disconnect before unbinding. This also fixes
muram memory leak, since we free muram in the qe_ep_disable().
But mainly the patch fixes following badness:
[EMAIL
On Thursday 13 November 2008, Anton Vorontsov wrote:
Gadgets disable endpoints in their disconnect callbacks, so
we must call disconnect before unbinding.
The patch fixes following badness:
[EMAIL PROTECTED]:~# insmod fsl_usb2_udc.ko
Freescale High-Speed USB SOC Device Controller driver
On Tuesday 11 November 2008, Anton Vorontsov wrote:
Freescale QE UDC controllers can't report the port change states,
so the only way to handle disconnects is to process bus reset
interrupts. The bus reset can take some time, that is, few irqs.
Gadgets may print the disconnection events, and
On Mon, 17 Nov 2008, Steven Rostedt wrote:
And here's my i386 max stack:
[EMAIL PROTECTED] ~]# cat /debug/tracing/stack_trace
Depth Size Location(47 entries)
-
0) 2216 240 blk_recount_segments+0x39/0x51
1) 1976
On Tue, 18 Nov 2008, Paul Mackerras wrote:
Also, you didn't respond to my comments about the purely software
benefits of a larger page size.
I realize that there are benefits. It's just that the downsides tend to
swamp the upsides.
The fact is, Intel (and to a lesser degree, AMD) has
On Tuesday 11 November 2008, Anton Vorontsov wrote:
Before freeing an endpoint's muram memory, we should stop all activity
of the endpoint, otherwise the QE UDC controller might do nasty things
with the muram memory that isn't belong to that endpoint anymore.
The qe_ep_reset() effectively
On Tuesday 11 November 2008, Anton Vorontsov wrote:
While disabling an endpoint the driver nuking any pending requests,
thus completing them with -ESHUTDOWN status. But the driver doesn't
clear the tx_req, which means that a next TX request (after
ep_enable), might get stalled, since the
On Tuesday 11 November 2008, Anton Vorontsov wrote:
In case of probing errors the driver kfrees the udc_controller, but it
doesn't set the pointer to NULL.
When usb_gadget_register_driver is called, it checks for udc_controller
!= NULL, the check passes and the driver accesses nonexistent
On Tuesday 11 November 2008, Anton Vorontsov wrote:
- spin_lock_irqsave(udc-lock, flags);
+ if (lock)
+ spin_lock_irqsave(lock, flags);
Ugly ugly ugly. Conditional locking is error prone ... don't.
Couldn't you just have the usb_ep_queue() method wrap lock calls
On Mon, 17 Nov 2008, Steven Rostedt wrote:
On Mon, 17 Nov 2008, Steven Rostedt wrote:
Note, I was using a default config that had CONFIG_IRQSTACKS off and
CONFIG_PPC_64K_PAGES on.
Here's my stack after boot up with CONFIG_IRQSTACKS set. Seems that
softirqs still use the same stack
Steven Rostedt writes:
By-the-way, my box has been running stable ever since I switched to
CONFIG_IRQSTACKS.
Great. We probably should remove the config option and just always
use irq stacks.
Paul.
___
Linuxppc-dev mailing list
On Mon, Nov 17, 2008 at 6:40 PM, David Gibson
[EMAIL PROTECTED] wrote:
Because the udbg console works for kernel messages, but doesn't
support a full tty interface, so you can't run userspace with only a
udbg console.
I still don't understand the point of your driver. You're just
routing
On Mon, Nov 17, 2008 at 10:42:46PM -0600, Timur Tabi wrote:
On Mon, Nov 17, 2008 at 6:40 PM, David Gibson
[EMAIL PROTECTED] wrote:
Because the udbg console works for kernel messages, but doesn't
support a full tty interface, so you can't run userspace with only a
udbg console.
I still
On Mon, 2008-11-17 at 18:56 -0600, Timur Tabi wrote:
I'm adding udbg support to my console driver, and I've noticed that
there is not much consistency on how the various platforms implement
udbg support. So I have a few questions:
1. What is the point of implementing udbg_getc? What does
From: Paul Mackerras [EMAIL PROTECTED]
Date: Tue, 18 Nov 2008 13:36:16 +1100
Steven Rostedt writes:
By-the-way, my box has been running stable ever since I switched to
CONFIG_IRQSTACKS.
Great. We probably should remove the config option and just always
use irq stacks.
That's what I
On Tue, 2008-11-18 at 16:37 +1100, Benjamin Herrenschmidt wrote:
On Mon, 2008-11-17 at 18:56 -0600, Timur Tabi wrote:
I'm adding udbg support to my console driver, and I've noticed that
there is not much consistency on how the various platforms implement
udbg support. So I have a few
It makes some sort of sense I suppose on very static embedded workloads
with no swap nor demand paging.
It makes perfect sense for anything that doesn't use any MMU.
To a certain extent. There's two different aspects to having an MMU and
in embedded space it's useful to have one and not
70 matches
Mail list logo
