From: Christoph Hellwig <[EMAIL PROTECTED]>
I recently tried to work on lockdep for powerpc. I have preliminary
version of the stacktrace code, but had to give up on trace irqflags
support because I'm not that knowledgeable on lowlevel ppc details.
Maybe someone more faimilar with the code wants
This fixes the handling of the preempt count when switching
interrupt stacks so that HW interrupt properly get the softirq
mask copied over from the previous stack.
It also initializes the softirq stack preempt_count to 0 instead
of SOFTIRQ_OFFSET, like x86, as __do_softirq() does the increment,
a
The iSeries veth driver uses an on-stack struct completion that
it initializes using the COMPLETION_INITIALIZER instead of
COMPLETION_INITIALIZER_ONSTACK macro, causing problems with
lockdep.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/net/iseries_veth.c |3 ++-
1 f
Lockdep found out that we can occasionally take the device-tree
lock for reading from softirq time (from rtas_token called
by the rtas real time clock code called by the NTP code),
while we take it occasionally for writing without masking
interrupts. The combination of those two can thus deadlock.
Currently, we initialize the "current" pointer in the PACA (which
is used by the "current" macro in the kernel) before calling
setup_system(). That means that early_setup() is called with
current still "NULL" which is -not- a good idea. It happens to
work so far but breaks with lockdep when early c
This adds the low level irq tracing hooks to the powerpc architecture
needed to enable full lockdep functionality
Partly based on Johannes Berg's initial version, removing the asm
trampoline that isn't needed (thus improving perfs) and all sorts
of bits and pieces, reworking most of the assembly,
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> On Fri, 2008-04-04 at 15:42 +0900, Ishizaki Kou wrote:
> >
> > As you pointed, spider I/O functions in Cell blades need 2 step
> > indirections by our patch. Shall I make another one for Cell blades
> > whose spider I/O functions need one step in
On Wed, Apr 09, 2008 at 05:21:34PM +1000, Benjamin Herrenschmidt wrote:
> The iSeries veth driver uses an on-stack struct completion that
> it initializes using the COMPLETION_INITIALIZER instead of
> COMPLETION_INITIALIZER_ONSTACK macro, causing problems with
> lockdep.
should probably go in ASAP
On Wed, 9 Apr 2008 16:22:17 +1000
Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Josh Boyer writes:
>
> > I've not heard any objections. I'll be pushing my commit to my next
> > branch tomorrow morning.
>
> I don't have any objections. I wonder if Sam Ravnborg responded to
> Segher's patch to ext
On Wed, 09 Apr 2008 17:21:34 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
>
> The iSeries veth driver uses an on-stack struct completion that
> it initializes using the COMPLETION_INITIALIZER instead of
> COMPLETION_INITIALIZER_ONSTACK macro, causing problems with
> lockdep.
>
> Signed
The architecture allows for "Book-E" style debug interrupts to either go
to critial interrupts of their own debug interrupt level. To allow for
a dynamic kernel to support machines of either type we want to be able to
compile in the interrupt handling code for both exception levels.
Towards this
On Wednesday 09 April 2008 14:16, Pandita, Vikram wrote:
> What does QUICC stand for?
QUICC stands for QUad Integrated Communications Controller.
http://en.wikipedia.org/wiki/PowerQUICC
> Am getting confused with SmartCard UICC. Is it anyway related?
They are not related.
--
Laurent Pinchar
On Tuesday 08 April 2008 14:16, Anton Vorontsov wrote:
> On Mon, Apr 07, 2008 at 06:11:15PM +0200, Laurent Pinchart wrote:
> [...]
> > I had a first go at hacking the FHCI driver to make it run on a CPM2
> > platform. Results so far are quite good. After getting rid of qe-specific
> > APIs as expla
What does QUICC stand for?
Am getting confused with SmartCard UICC. Is it anyway related?
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Laurent
>Pinchart
>Sent: Wednesday, April 09, 2008 5:44 PM
>To: [EMAIL PROTECTED]
>Cc: linuxppc-dev@ozlabs.org; [E
Scott Wood schrieb:
On Tue, Apr 08, 2008 at 03:50:26PM +0200, Andre Schwarz wrote:
after building a debug kernel and attaching the bdi2000 it looks like
the crash occurs during "console_init()" ...
Does your device tree have a /chosen node after u-boot is done with it?
find_legacy_se
Hi All,
This patch fixes a mixup in struct fs_platform_info. The struct has a field
dpram_offset which really is no offset but an io pointer to the dpram
(casted to u32).
It also has a field mem_offset which is used as the offset from the dpram
to the fcc RAM but then in turn filled into fcc.mem (
Currently USB Host isn't functional on the MPC8315E boards, for two
reasons as described below.
MPC8315 Reference Manual says:
"The USB DR unit must have the same clock ratio as the encryption core
unit, unless one of them has its clock disabled."
The encryption core also drives I2C clock, so it
> > This version fixes the clobbering of r12 by the call to
> > trace_hardirqs_off() that was pointed out by BenH.
> >
> > Johannes, I'd appreciate your trying this version if/when
> > you get the chance.
>
> Thanks Dale, this version seems to work. I'll stress it a bit more
> later, but so far
Board specific defconfigs are useful, however with the ability to do
multi-board defconfigs they aren't needed in the top level configs directory
Move the 83xx/85xx board specific defconfigs to individual directories under
arch/powerpc/configs.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
.
On Apr 9, 2008, at 10:26 AM, Grant Likely wrote:
On Wed, Apr 9, 2008 at 9:18 AM, Kumar Gala
<[EMAIL PROTECTED]> wrote:
Board specific defconfigs are useful, however with the ability to do
multi-board defconfigs they aren't needed in the top level configs
directory
Move the 83xx/85xx board
On Wed, Apr 9, 2008 at 9:18 AM, Kumar Gala <[EMAIL PROTECTED]> wrote:
> Board specific defconfigs are useful, however with the ability to do
> multi-board defconfigs they aren't needed in the top level configs directory
>
> Move the 83xx/85xx board specific defconfigs to individual directories un
I've not heard any objections. I'll be pushing my commit to my next
branch tomorrow morning.
I don't have any objections. I wonder if Sam Ravnborg responded to
Segher's patch to extend make help?
I haven't had a reply to that yet, from anyone. IIRC Sam send a
mail some time ago saying he wo
On Wed, Apr 09, 2008 at 10:27:04AM -0500, Kumar Gala wrote:
> Scott is 8xx capable of having a generic defconfig such that we can
> build a single kernel image that will run on the various boards?
It should be.
-Scott
___
Linuxppc-dev mailing list
Lin
On Wed, Apr 09, 2008 at 03:06:10PM +0200, Sascha Hauer wrote:
> This patch fixes a mixup in struct fs_platform_info. The struct has a field
> dpram_offset which really is no offset but an io pointer to the dpram
> (casted to u32).
Right, I didn't want to touch that as the old-binding code should b
On Tue, Apr 8, 2008 at 10:51 PM, Segher Boessenkool <
[EMAIL PROTECTED]> wrote:
>
> Let's flat out refuse any patch series that uses a non-documented
> binding.
>
I would love this, it makes life easier, but let's make sure that the
documented binding is actually
fairly future proof, first, and n
On Wed, Apr 09, 2008 at 11:11:10AM -0500, Scott Wood wrote:
> On Wed, Apr 09, 2008 at 03:06:10PM +0200, Sascha Hauer wrote:
> > This patch fixes a mixup in struct fs_platform_info. The struct has a field
> > dpram_offset which really is no offset but an io pointer to the dpram
> > (casted to u32).
Olof Johansson wrote:
> These make for some really long variable names and lines. I know from
> experience, since I've picked unneccessary long driver names in the past
> myself. :)
>
> How about just naming the new variables reserve_bootvar, etc? The name
> of the struct they're in makes it obvio
Olof Johansson wrote:
>> +static inline unsigned long phyp_dump_calculate_reserve_size(void)
>> +{
>> +unsigned long tmp;
>> +
>> +if (phyp_dump_info->phyp_dump_reserve_bootvar)
>> +return phyp_dump_info->phyp_dump_reserve_bootvar;
>> +
>> +/* divide by 20 to get 5% of value
Sascha Hauer wrote:
Right, so it's probably not worth the effort. I stumbled on this while
porting my board to the new binding code. I was quite confused when
seeing this so I made this fix to understand what's going on here.
BTW have you tested the FCC driver with the new binding code?
Yes.
Hi Grant,
I have a question about your patch. It appears as if the cache setup code is in
a file that would be used only on Xilinx FPGA devices.
I understand that many people are using a bootloader that already sets up the
cache for the kernel, but I'm wondering if Xilinx boards are really a sp
Hi
I made my own backtrace function for printing
a trace from within a signal handler. Maybe it
can be useful for the kernel too? General
comments welcome.
Jocke
#include
#include
#include
#include
#define __USE_GNU
#include
/* This is the stack layout we see with every stack frame.
On Wed, Apr 09, 2008 at 12:37:51PM -0500, Manish Ahuja wrote:
> Olof Johansson wrote:
> >> +static inline unsigned long phyp_dump_calculate_reserve_size(void)
> >> +{
> >> + unsigned long tmp;
> >> +
> >> + if (phyp_dump_info->phyp_dump_reserve_bootvar)
> >> + return phyp_dump_info->phyp
[ added Akira & Kou to cc: ]
On Tuesday 08 April 2008, Sergei Shtylyov wrote:
> Hi, I just wrote:
>
> >>> This function didn't actually check if a given BAR is in I/O space
> >>> because of
> >>> using the bogus PCI_BASE_ADDRESS_IO_MASK (which equals ~3) to test
> >>> the resource
> >>> flags
On Tuesday 08 April 2008, Sergei Shtylyov wrote:
> Bartlomiej Zolnierkiewicz wrote:
>
> >>Fix kernel oops due to machine check occuring in init_chipset_siimage() on
> >>PPC
> >>44x platforms. These 32-bit CPUs have 36-bit physical address and PCI I/O
> >>and
> >>memory spaces are mapped beyond
Hmmm,
You are possibly right.
Okay I can check and fix that.
-Manish
Olof Johansson wrote:
>>> That's 512MB, isn't it?
>> My calculations in the example I gave in the last email were wrong.
>>
>> In mentally did 10% instead of 5%. But the premise is same.
>>
>> So assuming 5% of some memory is
On Wed, Apr 09, 2008 at 01:43:51PM -0500, Manish Ahuja wrote:
> Hmmm,
>
> You are possibly right.
>
> Okay I can check and fix that.
Well, fix the comments if you prefer, I just pointed out the
discreptancy.
-Olof
___
Linuxppc-dev mailing list
Linux
Andre Schwarz wrote:
-> find_legacy_serial_port()
stdout is /[EMAIL PROTECTED]/[EMAIL PROTECTED]
It looks like you have some memory corruption between here...
clocksource: timebase mult[3c1] shift[22] registered
!!
-> check_legacy_ser
Scott Wood schrieb:
Andre Schwarz wrote:
-> find_legacy_serial_port()
stdout is /[EMAIL PROTECTED]/[EMAIL PROTECTED]
It looks like you have some memory corruption between here...
clocksource: timebase mult[3c1] shift[22] registered
!!
Andre Schwarz wrote:
Scott Wood schrieb:
Andre Schwarz wrote:
-> find_legacy_serial_port()
stdout is /[EMAIL PROTECTED]/[EMAIL PROTECTED]
It looks like you have some memory corruption between here...
clocksource: timebase mult[3c1] shift[22] registered
On Wed, Apr 9, 2008 at 12:00 PM, John Bonesio <[EMAIL PROTECTED]> wrote:
> Hi Grant,
>
> I have a question about your patch. It appears as if the cache setup code is
> in a file that would be used only on Xilinx FPGA devices.
That is correct.
>
> I understand that many people are using a bootlo
+ tmp = tmp & ~0x1FFF;
Note that this only works as you expect because the constant is
signed here -- the extra zeroes do not magically make it a 64-bit
number. So it goes 32-bit 0x1fff -> 32-bit -0x2000 ->
64-bit -0x2000.
Please consider writing it with an "L" su
The PS3 gelic network driver depends on the wake-on-lan support
provided by the PS3 sys manager driver. Add that dependency
to the GELIC_NET Kconfig option.
Prevents these build errors:
ps3_gelic_net.c:1277: undefined reference to `.ps3_sys_manager_get_wol'
ps3_gelic_net.c:1337: undefined re
On Wed, 2008-04-09 at 10:36 +0200, Christoph Hellwig wrote:
> On Wed, Apr 09, 2008 at 05:21:34PM +1000, Benjamin Herrenschmidt wrote:
> > The iSeries veth driver uses an on-stack struct completion that
> > it initializes using the COMPLETION_INITIALIZER instead of
> > COMPLETION_INITIALIZER_ONSTAC
global_dbcr0 needs to be a per cpu set of save areas instead of a single
global on all processors.
Also, we switch to using DBCR0_IDM to determine if the user space app is
being debugged as its a more consistent way. In the future we should
support features like hardware breakpoint and watchpoint
Geoff Levand wrote:
The PS3 gelic network driver depends on the wake-on-lan support
provided by the PS3 sys manager driver. Add that dependency
to the GELIC_NET Kconfig option.
Prevents these build errors:
ps3_gelic_net.c:1277: undefined reference to `.ps3_sys_manager_get_wol'
ps3_gelic_ne
Hi everybody,
Previously, with the arch/ppc tree, mpc8540 boards could reboot.
Now with the arch/powerpc tree, they can not anymore.
Fix that.
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
--- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:41.0 +
Hello everybody,
Here is small patch allowing to use a m41t81 rtc chip on a FSL_SOC based
board.
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
--- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:41.0 +
+++ b/arch/powerpc/sysdev/fsl_soc.c 2008-03-26 12:08:25.0
Hi,
On Thu, Apr 10, 2008 at 12:22:52AM +0200, Philippe De Muyter wrote:
> Hello everybody,
>
> Here is small patch allowing to use a m41t81 rtc chip on a FSL_SOC based
> board.
>
> Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
>
> --- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:4
On Wed, 2008-04-09 at 17:21 +1000, Benjamin Herrenschmidt wrote:
> From: Christoph Hellwig <[EMAIL PROTECTED]>
>
> I recently tried to work on lockdep for powerpc. I have preliminary
> version of the stacktrace code, but had to give up on trace irqflags
> support because I'm not that knowledgeab
Hello everybody,
Here is small patch allowing to use a m41t81 rtc chip on a FSL_SOC based
board.
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
--
I have removed the ifdef as pointed by Olof
--- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:41.0 +
+++ b/arch/powerpc/s
On Apr 9, 2008, at 5:12 PM, Philippe De Muyter wrote:
Hi everybody,
Previously, with the arch/ppc tree, mpc8540 boards could reboot.
Now with the arch/powerpc tree, they can not anymore.
Fix that.
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
--- a/arch/powerpc
On Wed, Apr 09, 2008 at 05:51:40PM -0500, Kumar Gala wrote:
>
> On Apr 9, 2008, at 5:12 PM, Philippe De Muyter wrote:
>> Hi everybody,
>>
>> Previously, with the arch/ppc tree, mpc8540 boards could reboot.
>> Now with the arch/powerpc tree, they can not anymore.
>> Fix that.
>>
>> Si
Hi Kumar,
On Wed, 9 Apr 2008 10:18:06 -0500 (CDT) Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> Board specific defconfigs are useful, however with the ability to do
> multi-board defconfigs they aren't needed in the top level configs directory
>
> Move the 83xx/85xx board specific defconfigs to indiv
Kumar Gala writes:
> [POWERPC] bootwrapper: Allow specifying of image physical offset
>
> reworked to look at PHDR (needs linker script update patch). Still
> open question on how best to do that (objdump, readelf, C program,
> suggestions)
Just replied about that one.
> [POWERPC] Remove K
Segher Boessenkool writes:
> >>> + tmp = tmp & ~0x1FFF;
>
> Note that this only works as you expect because the constant is
> signed here -- the extra zeroes do not magically make it a 64-bit
> number. So it goes 32-bit 0x1fff -> 32-bit -0x2000 ->
> 64-bit -0x2000.
Huh?
Kumar Gala writes:
> So now we can look at the vmlinux and determine the physical offset.
> The question is how best to do that. Here are the options I see:
> * readelf, grep and parse output
> * objdump grep and parse output
> * simple C program that read's the elf and reports back
Either re
On Apr 9, 2008, at 7:31 PM, Stephen Rothwell wrote:
Hi Kumar,
On Wed, 9 Apr 2008 10:18:06 -0500 (CDT) Kumar Gala <[EMAIL PROTECTED]
> wrote:
Board specific defconfigs are useful, however with the ability to do
multi-board defconfigs they aren't needed in the top level configs
directory
M
+ tmp = tmp & ~0x1FFF;
Note that this only works as you expect because the constant is
signed here -- the extra zeroes do not magically make it a 64-bit
number. So it goes 32-bit 0x1fff -> 32-bit -0x2000 ->
64-bit -0x2000.
Huh? It's not big enough to be negative
The powerpc kernel stacks need to be naturally aligned, as they
contain the thread info at the bottom, which is obtained by
clearing the low bits of the stack pointer.
However, when using 64K pages (the stack is smaller than a page),
we use kmalloc to allocate it, which doesn't provide that guaran
Some architecture need to maintain a kmem cache for thread info
structures. (next patch adds that to powerpc to fix an alignment
problem).
There is no good arch callback to use to initialize that cache
that I can find, so this adds a new one and adds an empty macro
for when it's not implemented.
On Wed, 9 Apr 2008 22:11:38 -0500 Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> Yeah the are mpc85xx_defconfig and mpc83xx_defconfig.
So should we add mpc83xx_defconfig to the kisskb builds and remove
mpc885_ads_defconfig (we already do a mpc85xx_defconfig build)?
--
Cheers,
Stephen Rothwell
On Wed, Apr 9, 2008 at 10:24 PM, Stephen Rothwell <[EMAIL PROTECTED]> wrote:
> On Wed, 9 Apr 2008 22:11:38 -0500 Kumar Gala <[EMAIL PROTECTED]> wrote:
> >
> > Yeah the are mpc85xx_defconfig and mpc83xx_defconfig.
>
> So should we add mpc83xx_defconfig to the kisskb builds and remove
> mpc885_ad
Hi Grant,
On Tue, Apr 08, 2008 at 03:26:11PM -0600, Grant Likely wrote:
> I disagree and that is not my point.
Well, having something like a device tree that describes the hardware is
definitely a good thing, in general.
> Now, if out-of-tree ports continue to break then we've got a problem
> th
Now that we have the alpaca, the reg_save_ptr is no longer needed in the
paca. Eradicate all global uses of it and make it static in the iSeries
lpardata.c
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/paca.c | 33 +++
arch/powerpc/platfo
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/iseries/ipl_parms.h|2 --
arch/powerpc/platforms/iseries/lpardata.c | 14 +++---
arch/powerpc/platforms/iseries/naca.h |2 +-
arch/powerpc/platforms/iseries/release_data.h |2 +-
a
On Thu, 3 Apr 2008 14:08:42 -0700 (PDT) Roland McGrath <[EMAIL PROTECTED]>
wrote:
> This requires the earlier HAVE_SET_RESTORE_SIGMASK patch series.
> This does the same for powerpc that I posted the x86 change for.
>
> ---
> Replace TIF_RESTORE_SIGMASK with TLF_RESTORE_SIGMASK and define
> our
66 matches
Mail list logo
