On Thu, Nov 20, 2008 at 03:34:16PM -0500, Steven Rostedt wrote:
> +} elsif ($arch eq "sh") {
> +$section_regex = "Disassembly of section\\s+(\\S+):";
> +$function_regex = "^([0-9a-fA-F]+)\\s+<(.*?)>:";
> +$mcount_regex = "^\\s*([0-9a-fA-F]+):.*\\smcount\$";
> +$type = ".long";
> +
>
On Fri, 2008-11-21 at 10:52 +1100, Paul Mackerras wrote:
> Joakim Tjernlund writes:
>
> > This little hack changes the kernel sys call handling in an crude
> > way and then it works. Apperently the kernel thinks is an error if the
> > syscall returns a value between -_LAST_ERRNO and -1.
>
> Try t
On Fri, Nov 21, 2008 at 10:52:14AM +1100, Paul Mackerras wrote:
> Joakim Tjernlund writes:
>
> > This little hack changes the kernel sys call handling in an crude
> > way and then it works. Apperently the kernel thinks is an error if the
> > syscall returns a value between -_LAST_ERRNO and -1.
>
Hi Grant&Wolfgang
thanks for yours posts. You are right about WR. For lite5200 only few patchs
have been used. Most of the job is for support other boards or to introduce
some patchs for its debug system.
The main HW difference between our board and lite5200 is:
console on PSC3 and
port_config
On Fri, 2008-11-21 at 09:41 +0100, Gabriel Paubert wrote:
> On Fri, Nov 21, 2008 at 10:52:14AM +1100, Paul Mackerras wrote:
> > Joakim Tjernlund writes:
> >
> > > This little hack changes the kernel sys call handling in an crude
> > > way and then it works. Apperently the kernel thinks is an error
Gabriel Paubert writes:
> On Fri, Nov 21, 2008 at 10:52:14AM +1100, Paul Mackerras wrote:
> > Joakim Tjernlund writes:
> >
> > > This little hack changes the kernel sys call handling in an crude
> > > way and then it works. Apperently the kernel thinks is an error if the
> > > syscall returns a v
On Wed, 2008-11-19 at 13:59 +0100, Ricardo wrote:
> Hello All:
>
> I am using the paulus tree popwerpc linux kernel for a ppc440 cpu
> located in a Virtex5 FPGA.
>
> While developing some drivers (a simple gpio device) I have notice
> that if I try to access an unmapped area (an address witho
On Fri, 2008-11-21 at 20:03 +1100, Paul Mackerras wrote:
> Gabriel Paubert writes:
>
> > On Fri, Nov 21, 2008 at 10:52:14AM +1100, Paul Mackerras wrote:
> > > Joakim Tjernlund writes:
> > >
> > > > This little hack changes the kernel sys call handling in an crude
> > > > way and then it works. Ap
On Fri, 2008-11-21 at 10:52 +1100, Paul Mackerras wrote:
> Joakim Tjernlund writes:
>
> > This little hack changes the kernel sys call handling in an crude
> > way and then it works. Apperently the kernel thinks is an error if the
> > syscall returns a value between -_LAST_ERRNO and -1.
>
> Try t
On Fri, Nov 21, 2008 at 08:03:06PM +1100, Paul Mackerras wrote:
> Gabriel Paubert writes:
>
> > On Fri, Nov 21, 2008 at 10:52:14AM +1100, Paul Mackerras wrote:
> > > Joakim Tjernlund writes:
> > >
> > > > This little hack changes the kernel sys call handling in an crude
> > > > way and then it wo
Joakim Tjernlund writes:
> > + force_successful_syscall_return();
> > return (long) jiffies_64_to_clock_t(get_jiffies_64());
>
> Why is 64 bits ops used here when you only use 32 bits?
If HZ is 1000, jiffies_64_to_clock_t is going to divide jiffies by 10,
so we need to start with 64 bits
On Fri, 2008-11-21 at 10:31 +0100, Joakim Tjernlund wrote:
> On Fri, 2008-11-21 at 10:52 +1100, Paul Mackerras wrote:
> > Joakim Tjernlund writes:
> >
> > > This little hack changes the kernel sys call handling in an crude
> > > way and then it works. Apperently the kernel thinks is an error if th
Gabriel Paubert writes:
> Who does this? I have spotted some errors in other places on
> my man pages too, especially in the networking area (they were
> correct once upon a time, but have not been updated).
Michael Kerrisk <[EMAIL PROTECTED]>, I believe.
Paul.
_
On Fri, 2008-11-21 at 20:51 +1100, Paul Mackerras wrote:
> Joakim Tjernlund writes:
>
> > > + force_successful_syscall_return();
> > > return (long) jiffies_64_to_clock_t(get_jiffies_64());
> >
> > Why is 64 bits ops used here when you only use 32 bits?
>
> If HZ is 1000, jiffies_64_to_clock_
On Fri, 2008-11-21 at 10:50 +0100, Gabriel Paubert wrote:
> On Fri, Nov 21, 2008 at 08:03:06PM +1100, Paul Mackerras wrote:
> > Gabriel Paubert writes:
> >
> > > On Fri, Nov 21, 2008 at 10:52:14AM +1100, Paul Mackerras wrote:
> > > > Joakim Tjernlund writes:
> > > >
> > > > > This little hack cha
On Fri, Nov 21, 2008 at 04:44:29PM +0900, Paul Mundt wrote:
> On Thu, Nov 20, 2008 at 03:34:16PM -0500, Steven Rostedt wrote:
> > +} elsif ($arch eq "sh") {
> > +$section_regex = "Disassembly of section\\s+(\\S+):";
> > +$function_regex = "^([0-9a-fA-F]+)\\s+<(.*?)>:";
> > +$mcount_rege
Hi all,
we have trouble with the eth based config pins (ETH0...ETH6) of the MPC5200B
CPU. These pins act as the interface to an external phy and also act as
configurations pins to configure the size of the flash and other things.
While the reset is active these pins should be in their high impe
On Fri, 21 Nov 2008, Russell King - ARM Linux wrote:
> On Thu, Nov 20, 2008 at 02:11:49PM -0800, Jim Radford wrote:
> > Ingo and Steven,
> >
> > Here's an updated version of the arch/arm changes for dynamic ftrace
> > based on top of your latest tip/master.
>
> Excuse me if I'm rather confused,
On Thu, Nov 20, 2008 at 02:11:49PM -0800, Jim Radford wrote:
> Ingo and Steven,
>
> Here's an updated version of the arch/arm changes for dynamic ftrace
> based on top of your latest tip/master.
Excuse me if I'm rather confused, but...
When ftrace for ARM was originally merged, neither linux-arm
Hi Stuart, Thanks for the information. gpp access was
resolved. I was successful in building the linux 2.6.11 using the
ltib and able to bring up the MPC8360 EMDS.But, I still face the problem
for linux kernel 2.6.19 and 2.6.20. When I tried using ltib in
the bringing up the board. T
Hi Nanda,
You'll need to get help from the kernel experts with this issue.
Regards, Stuart
On Fri, 2008-11-21 at 14:16 +, nanda wrote:
> Hi Stuart,
>Thanks for the information. gpp access was resolved.
>I was successful in building the linux 2.6.11 using the ltib and
> able to bri
On Friday 21 November 2008, Michael Ellerman wrote:
> By incrementing the offset we're dropping the irq. Would it be better to
> just return, and hope that the next time we come in the MSI will have
> landed in the fifo and then we can deliver it? It might be late, really
> late I guess, but that m
nanda wrote:
Hi Stuart,
Thanks for the information. gpp access was resolved.
I was successful in building the linux 2.6.11 using the ltib and able
to bring up the MPC8360 EMDS.
But, I still face the problem for linux kernel 2.6.19 and 2.6.20. When
I tried using ltib in the bringing up
On Friday 21 November 2008, Benjamin Herrenschmidt wrote:
> Oh just that for powermac for example, I know I'm resetting the thing,
> so can't rely on init values, and on some BML embedded boxes too, while
> on things like cell I don't off hand know what the right CPU number is
> to hit the right C3
On Fri, Nov 21, 2008 at 1:36 AM, <[EMAIL PROTECTED]> wrote:
> Hi Grant&Wolfgang
>
> thanks for yours posts. You are right about WR. For lite5200 only few patchs
> have been used. Most of the job is for support other boards or to introduce
> some patchs for its debug system.
>
> The main HW differe
Juergen, I haven't seen this behaviour. Have you asked you Freescale FAE?
Hey John, have you ever seen this sort of issue?
g.
On Fri, Nov 21, 2008 at 5:36 AM, Juergen Beisert <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> we have trouble with the eth based config pins (ETH0...ETH6) of the MPC5200B
>
Hi Grant,
On Freitag, 21. November 2008, Grant Likely wrote:
> Juergen, I haven't seen this behaviour. Have you asked you Freescale FAE?
Yes. But no answer yet. Thats why I ask here.
Regards,
Juergen
--
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix - Linux Solutions for
From: Michael Ellerman <[EMAIL PROTECTED]>
shca_list_lock is taken from softirq context in ehca_poll_eqs, so we need to
lock IRQ safe elsewhere.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_main.c | 17
On Nov 20, 2008, at 1:16 PM, Timur Tabi wrote:
Milton Miller wrote:
Stated differently, if your routine (1) fundamently works one
character
at a time and (2) is not interrupt driven, and (3) only supports one
channel, what avantage is there to an explicit hvc driver?
I think it's because H
On Fri, 2008-11-21 at 16:37 +0100, Joachim Fenkes wrote:
> + u64 flags;
> - spin_lock(&shca_list_lock);
> + spin_lock_irqsave(&shca_list_lock, flags);
That's wrong and I think will give a warning on all machines where
u64 != unsigned long. Might not particularly matter in this case.
Hi Scott,
On Thursday 20 November 2008, Scott Wood wrote:
> On Thu, Nov 20, 2008 at 01:32:23PM +0100, Laurent Pinchart wrote:
> > Instead of rounding the divider down, improve the baud-rate generators
> > accuracy by rounding to the nearest integer.
> >
> > Signed-off-by: Laurent Pinchart <[EMAIL
Milton Miller wrote:
> We want the last console= parameter on the command line to win. So if
> that implys the last call to add_preferred_console wins, then you have
> code overriding the command line.
Hmm, good point. However, how likely is it that we'll have more than one
console driver? A
shca_list_lock is taken from softirq context in ehca_poll_eqs, so we need to
lock IRQ safe elsewhere.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
On Friday 21 November 2008 17:02, Johannes Berg wrote:
> On Fri, 2008-11-21 at 16:37 +010
Jürgen,
Have a look at the manual chapter 4 (=Reset + Config).
SRESET (issued by gpt0 - watchdog) isn't supposed to do a full hardware
reset.
Looks like you should make use of the SRESET and trigger HRESET accordingly.
I could solve this with _not_ using the internal watchdog but an
external
Hi Andre,
On Freitag, 21. November 2008, Andre Schwarz wrote:
> Have a look at the manual chapter 4 (=Reset + Config).
> SRESET (issued by gpt0 - watchdog) isn't supposed to do a full hardware
> reset.
> Looks like you should make use of the SRESET and trigger HRESET
> accordingly.
>
> I could sol
Laurent Pinchart wrote:
On Thursday 20 November 2008, Scott Wood wrote:
This makes things worse on mpc8272ads -- the result of the division is
13.56, but I only get error-free serial output when rounding down. I
don't think the remote end has timing problems, as I don't see this with
any other
Dave,
On Friday 21 November 2008, David Brownell wrote:
> On Friday 31 October 2008, Stefan Roese wrote:
> > + dev_dbg(&spi->dev, "%s: mode %d, %u bpw, %d hz\n",
> > + __FUNCTION__, spi->mode, spi->bits_per_word,
> > + spi->max_speed_hz);
>
> Oh, and checkpatch.pl
Looks good... I'll add this for 2.6.29, since as far as I can tell this
bug has been there approximately forever already.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Nov 21, 2008, at 10:13 AM, Timur Tabi wrote:
Milton Miller wrote:
We want the last console= parameter on the command line to win. So if
that implys the last call to add_preferred_console wins, then you have
code overriding the command line.
Hmm, good point. However, how likely is it that
On Nov 20, 2008, at 6:35 PM, David Gibson wrote:
On Thu, Nov 20, 2008 at 01:07:11PM -0600, Milton Miller wrote:
David Gibson wrote at 2008-11-18 00:28:28:
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
On Thu, 20 Nov 2008 15:01:23 +0100
Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> This patch adds support for the nwp serial device which is connected to
> a DCR bus. It uses the of_serial device driver to determine necessary
> properties from the device tree. The supported device is added as serial
>
On Fri, 2008-11-21 at 15:40 +0100, Arnd Bergmann wrote:
> On Friday 21 November 2008, Benjamin Herrenschmidt wrote:
> > Oh just that for powermac for example, I know I'm resetting the thing,
> > so can't rely on init values, and on some BML embedded boxes too, while
> > on things like cell I don't
I was handed off a bug report about a blade not booting with a, um
"newer" kernel. After turning on some debugging messages, I got this
ominous message:
node 1
NODE_DATA() = c000
Which obviously comes from here:
arch/powerpc/mm/numa.c
for_each_online_node(ni
Dave Hansen wrote:
> I was handed off a bug report about a blade not booting with a, um
> "newer" kernel.
If you're unable to provide basic information such as the kernel
version then perhaps this isn't the best forum for discussing this. :)
> I'm thinking that we need to at least fix careful_a
On Fri, 2008-11-21 at 18:49 -0600, Nathan Lynch wrote:
> Dave Hansen wrote:
> > I was handed off a bug report about a blade not booting with a, um
> > "newer" kernel.
>
> If you're unable to provide basic information such as the kernel
> version then perhaps this isn't the best forum for discussin
With 2.6.28-rc5 the WARN_ON in xics_set_cpu_giq is triggering on a
JS20. I changed it to a WARN to get the actual status returned:
[boot]0020 XICS Init
set-indicator returned -22
[ cut here ]
Badness at arch/powerpc/platforms/pseries/xics.c:733
NIP: c0047454 LR: c0
On Fri, 2008-11-21 at 17:02 +0100, Johannes Berg wrote:
> On Fri, 2008-11-21 at 16:37 +0100, Joachim Fenkes wrote:
>
> > + u64 flags;
>
> > - spin_lock(&shca_list_lock);
> > + spin_lock_irqsave(&shca_list_lock, flags);
>
> That's wrong and I think will give a warning on all machines where
47 matches
Mail list logo