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 wa
> > 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 NOT
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
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 pr
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
> > loade
On Mon, 17 Nov 2008, Paul Mackerras wrote:
> Steven Rostedt writes:
>
> > When idle is called, interrupts are disabled, but the idle function
> > will still wake up on an interrupt. The problem is that the interrupt
> > disabled latency tracer will take this call to idle as a latency.
> >
> > T
On Mon, 17 Nov 2008, Paul Mackerras wrote:
> Steven Rostedt writes:
>
> > +static int test_24bit_addr(unsigned long ip, unsigned long addr)
> > +{
> > + unsigned long diff;
> > +
> > + /* can we get to addr from ip in 24 bits? */
> > + diff = ip > addr ? ip - addr : addr - ip;
> > +
> > +
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
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, and
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 10064
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 enet1 (UCC3/eth1), and
ethernet1 should be enet0 (UCC2/eth0), to be cons
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 jum
Impact: fix to module check in making nops in dynamic ftrace for PPC
Paul Mackerras pointed out that the mod test in ftrace_make_nop looks
wrong. It is, but it did not trigger because the logic to ftrace just
happens to miss the bad case.
When ftrace first changes all the calls to mcount into nop
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 ft
Impact: fix positive failure of branch link on PPC
Paul Mackerras pointed out that the test to verify that the modify
code is a banch link is incorrect. It was testing the wrong bits.
This patch corrects the test.
Reported-by: Paul Mackerras <[EMAIL PROTECTED]>
Signed-off-by: Steven Rostedt <[EMA
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 simple udbg primitives. This is kind
> of a hack - since ud
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 Ha
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
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
> There's one place in flattree.c where we currently ignore the return
> value from fwrite(). On some gcc/glibc versions, where fwrite() is
> declared with attribute warn_unused_result, this causes a warning.
>
> This patch fixes the warning, by checking the fwrite() result.
>
> Signed-off-by: D
> 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,
jd
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 caus
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_
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 b
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 fl
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 /debug/t
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, 17 Nov 2008 15:34:13 -0500 (EST)
Steven Rostedt <[EMAIL PROTECTED]> 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 s
On Mon, 17 Nov 2008, Steven Rostedt wrote:
>
> Here's my stack after boot up with CONFIG_IRQSTACKS set. Seems that
> softirqs still use the same stack as the process.
Yes.
> This is still 12K. Kind of big even for a 16K stack.
And while that 1kB+ stack slot for block_read_full_page still sta
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 thread I also said:
"If we have 64kB pages, such architectures will have to have a bi
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 st
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
>
>
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
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 chan
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]>
---
arch/power
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 deepes
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-b
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
+++ everything/arch/pow
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
> 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 pag
> I'd have thought so, but I'm sure we're about to hear how important an
> optimisation the smaller stacks are ;)
Not sure, I tend to agree that it would make sense to bump our stack to
64K on 64K pages, it's not like we are saving anything and we are
probably adding overhead in alloc/dealloc. I'
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 / 5
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
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 ve
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
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 sta
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 yo
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
> byte
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?
2
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)
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 ter
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
> > hardwa
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 fr
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. Th
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 an
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:
>
> [EM
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 dr
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,
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) 197
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 sh
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() effectivel
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 dr
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 nonexisten
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 s
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
Linuxppc-dev@ozlab
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.
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 do
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
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
82 matches
Mail list logo
