* never mind .. [was Re: Hard hang in hypervisor!?
From: Linas Vepstas @ 2007-10-09 23:22 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <20071009212810.GN4350@austin.ibm.com>
On Tue, Oct 09, 2007 at 04:28:10PM -0500, Linas Vepstas wrote:
>
> Perhaps I should IRC this ...
yeah. I guess I'd forgotten how funky things can get. So never mind ...
--linas
^ permalink raw reply
* [PATCH] [PPC] Disable vDSO support for ARCH=ppc where it's not implemented.
From: Wolfgang Denk @ 2007-10-09 22:36 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Wolfgang Denk <wd@denx.de>
---
arch/powerpc/kernel/vdso.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 213fa31..2322ba5 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -766,7 +766,9 @@ static int __init vdso_init(void)
return 0;
}
+#ifdef CONFIG_PPC_MERGE
arch_initcall(vdso_init);
+#endif
int in_gate_area_no_task(unsigned long addr)
{
--
1.5.2.2
^ permalink raw reply related
* Re: Hard hang in hypervisor!?
From: Linas Vepstas @ 2007-10-09 21:28 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <20071009211819.GR29559@localdomain>
On Tue, Oct 09, 2007 at 04:18:19PM -0500, Nathan Lynch wrote:
> Linas Vepstas wrote:
> >
> > I was futzing with linux-2.6.23-rc8-mm1 in a power6 lpar when,
> > for whatever reason, a spinlock locked up. The bizarre thing
> > was that the rest of system locked up as well: an ssh terminal,
> > and also an hvc console.
> >
> > Breaking into the debugger showed 4 cpus, 1 of which was
> > deadlocked in the spinlock, and the other 3 in
> > .pseries_dedicated_idle_sleep
> >
> > This was, ahhh, unexpected. What's up with that? Can
> > anyone provide any insight?
>
> Sounds consistent with a task trying to double-acquire the lock, or an
> interrupt handler attempting to acquire a lock that the current task
> holds. Or maybe even an uninitialized spinlock. Do you know which
> lock it was?
Not sure .. trying to find out now. But why would that kill the
ssh session, and the console? Sure, so maybe one cpu is spinning,
but the other three can still take interrupts, right? The ssh session
should have been generating ethernet card interrupts, and the console
should have been generating hvc interrupts.
Err .. it was cpu 0 that was spinlocked. Are interrupts not
distributed?
Perhaps I should IRC this ...
--linas
^ permalink raw reply
* Re: Hard hang in hypervisor!?
From: Nathan Lynch @ 2007-10-09 21:18 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev
In-Reply-To: <20071009203724.GM4350@austin.ibm.com>
Linas Vepstas wrote:
>
> I was futzing with linux-2.6.23-rc8-mm1 in a power6 lpar when,
> for whatever reason, a spinlock locked up. The bizarre thing
> was that the rest of system locked up as well: an ssh terminal,
> and also an hvc console.
>
> Breaking into the debugger showed 4 cpus, 1 of which was
> deadlocked in the spinlock, and the other 3 in
> .pseries_dedicated_idle_sleep
>
> This was, ahhh, unexpected. What's up with that? Can
> anyone provide any insight?
Sounds consistent with a task trying to double-acquire the lock, or an
interrupt handler attempting to acquire a lock that the current task
holds. Or maybe even an uninitialized spinlock. Do you know which
lock it was?
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH 0/6] Patch series to add of_platform binding to xilinxfb
From: Antonino A. Daplas @ 2007-10-09 21:06 UTC (permalink / raw)
To: Grant Likely
Cc: linuxppc, akonovalov, linux-fbdev-devel, linux-kernel,
Paul Mackerras
In-Reply-To: <fa686aa40710091039hd945eb4n7dfdba3df37a08f2@mail.gmail.com>
On Tue, 2007-10-09 at 11:39 -0600, Grant Likely wrote:
> On 10/8/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > On Mon, 2007-10-08 at 22:43 -0600, Grant Likely wrote:
> > > BTW, what path do framebuffer patches take to get into Linus' tree?
> > > Does he pull your tree directly, or do they go through someone else's
> > > tree?
> >
> > They all go to -mm tree, unless it's a needed fix, then to Linus's.
> >
> > Tony
>
> Ah, okay.
>
> Since the XilinxFB is a powerpc-only device, is it okay with you if I
> get Paul Mackerras to merge them into his tree instead (that way the
> changes go in with the platform code which requires these changes)
Fine with me.
Tony
^ permalink raw reply
* Hard hang in hypervisor!?
From: Linas Vepstas @ 2007-10-09 20:37 UTC (permalink / raw)
To: linuxppc-dev
I was futzing with linux-2.6.23-rc8-mm1 in a power6 lpar when,
for whatever reason, a spinlock locked up. The bizarre thing
was that the rest of system locked up as well: an ssh terminal,
and also an hvc console.
Breaking into the debugger showed 4 cpus, 1 of which was
deadlocked in the spinlock, and the other 3 in
.pseries_dedicated_idle_sleep
This was, ahhh, unexpected. What's up with that? Can
anyone provide any insight?
I should mention:
-- prior to the complete hard lockp, I did see
BUG: soft lockup - CPU#0 stuck for 11s! [ip:4473]
go off, and I did manage to sneak in a few commands
into the console and the ssh session. Then it locked
up hard -- but still not completely -- exactly
360 seconds later, a kernel thread ran for a while,
producing some console output, even though the
keyboard and console were locked up.
--linas
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Kumar Gala @ 2007-10-09 19:50 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <470BD3F8.6000006@freescale.com>
On Oct 9, 2007, at 2:18 PM, Timur Tabi wrote:
> Kumar Gala wrote:
>
>> Ok. I guess I'm not in favor of changing the device tree to
>> address this issue. I think it would be solved if "dtc" had
>> #define support.
>
> Not really. The #defines would then need to match the enum, and
> that's dual maintenance. This method is better because you can use
> the real name of the clock source in the DTS. That keeps the DTS
> from having to know the internal representation of clock sources.
>
> (BTW, when I said "I just understand", I meant "I just don't
> understand".)
I misread the idea. I'm ok with using a string, just use a new prop
name and deprecate the old names in booting-without-of.txt
Also, I think Scott suggested this but I'd say parse the string for
"BRG" & "CLK" and the decimal number and use some enum + math rather
than a big lookup table.
- k
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Timur Tabi @ 2007-10-09 19:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <B2FD32B4-241E-4FCF-A18D-1E619034EC3A@kernel.crashing.org>
Kumar Gala wrote:
> Ok. I guess I'm not in favor of changing the device tree to address
> this issue. I think it would be solved if "dtc" had #define support.
Not really. The #defines would then need to match the enum, and that's dual
maintenance. This method is better because you can use the real name of the
clock source in the DTS. That keeps the DTS from having to know the internal
representation of clock sources.
(BTW, when I said "I just understand", I meant "I just don't understand".)
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Kumar Gala @ 2007-10-09 19:15 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <470BC5CA.1010105@freescale.com>
On Oct 9, 2007, at 1:17 PM, Timur Tabi wrote:
> Kumar Gala wrote:
>
>> But that's a function of linux' use. Remember decouple the device
>> tree from how linux does things.
>
> Ok, I just understand what your point is. I'm proposing that we
> just put the name of the clock source in the device tree, and have
> a function which converts that into an internal representation.
> The clock is called "BRG3". It's not called BRG, #3 or something
> like that. Same thing with the CLK sources.
Ok. I guess I'm not in favor of changing the device tree to address
this issue. I think it would be solved if "dtc" had #define support.
- k
^ permalink raw reply
* Re: Build failure on treeboot-walnut.cg
From: Kumar Gala @ 2007-10-09 19:14 UTC (permalink / raw)
To: Josh Boyer; +Cc: PowerPC dev list, Paul Mackerras, Timur Tabi, David Gibson
In-Reply-To: <20071009135235.1026bb23@vader.jdub.homelinux.org>
On Oct 9, 2007, at 1:52 PM, Josh Boyer wrote:
> On Tue, 09 Oct 2007 11:06:05 -0500
> Timur Tabi <timur@freescale.com> wrote:
>
>> David Gibson wrote:
>>
>>> Policy. Compiling everything means build bugs - like this one - can
>>> be found by everybody, not just those building for the specific
>>> obscure platform.
>>
>> Is this a new policy? Modules in the kernel are not built unless
>> you want
>> them. Even in arch/powerpc/platforms, only the specific platform
>> file I'm
>> targeting is built. So I don't really understand why you claim
>> it's normal
>> for platform-specific files to be built, regardless of the actual
>> platform.
>>
>> And frankly, I don't like this "policy". Build bugs for 4xx
>> should not
>> interfere in my 83xx development. I can't build any kernels now
>> because of
>> this bug!
>
> I fixed this bug. It should be in Paul's latest tree. You seem to be
> having a different issue with your binutils though.
Just to clarify this is an issue with the particular patched binutils
Timur is using.
I'll leave it to you guys to fight over if we should be building
everything or not.
- k
^ permalink raw reply
* Re: Build failure on treeboot-walnut.cg
From: Josh Boyer @ 2007-10-09 18:52 UTC (permalink / raw)
To: Timur Tabi; +Cc: Paul Mackerras, linuxppc-dev, David Gibson
In-Reply-To: <470BA6ED.3020504@freescale.com>
On Tue, 09 Oct 2007 11:06:05 -0500
Timur Tabi <timur@freescale.com> wrote:
> David Gibson wrote:
>
> > Policy. Compiling everything means build bugs - like this one - can
> > be found by everybody, not just those building for the specific
> > obscure platform.
>
> Is this a new policy? Modules in the kernel are not built unless you want
> them. Even in arch/powerpc/platforms, only the specific platform file I'm
> targeting is built. So I don't really understand why you claim it's normal
> for platform-specific files to be built, regardless of the actual platform.
>
> And frankly, I don't like this "policy". Build bugs for 4xx should not
> interfere in my 83xx development. I can't build any kernels now because of
> this bug!
I fixed this bug. It should be in Paul's latest tree. You seem to be
having a different issue with your binutils though.
josh
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Timur Tabi @ 2007-10-09 18:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <91CB543F-A0F2-42A4-AA5C-6F8FC99F9EC3@kernel.crashing.org>
Kumar Gala wrote:
> But that's a function of linux' use. Remember decouple the device tree
> from how linux does things.
Ok, I just understand what your point is. I'm proposing that we just put the
name of the clock source in the device tree, and have a function which
converts that into an internal representation. The clock is called "BRG3".
It's not called BRG, #3 or something like that. Same thing with the CLK sources.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Kumar Gala @ 2007-10-09 18:15 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <470BC484.3060702@freescale.com>
On Oct 9, 2007, at 1:12 PM, Timur Tabi wrote:
> Kumar Gala wrote:
>
>> rx-clock-type = "brg" or "clk"
>> rx-clock-id = 3
>> I don't see how this doesn't cover what you need in the device tree.
>
> That just looks more complicated than what my patch proposes. Why
> have two properties when one will suffice? I still need to have a
> look-up table that will convert "3" to QE_BRG3, since the latter is
> an enum.
But that's a function of linux' use. Remember decouple the device
tree from how linux does things.
- k
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Timur Tabi @ 2007-10-09 18:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <EF1344B5-5A53-4CC1-A51E-59EB9024B0C5@kernel.crashing.org>
Kumar Gala wrote:
> rx-clock-type = "brg" or "clk"
> rx-clock-id = 3
>
> I don't see how this doesn't cover what you need in the device tree.
That just looks more complicated than what my patch proposes. Why have two
properties when one will suffice? I still need to have a look-up table that
will convert "3" to QE_BRG3, since the latter is an enum.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Kumar Gala @ 2007-10-09 18:10 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <470BB0E6.4050801@freescale.com>
On Oct 9, 2007, at 11:48 AM, Timur Tabi wrote:
> Scott Wood wrote:
>
>> In the absence of a BRG, the driver should just not support
>> changing the baud rate -- it shouldn't fail to function.
>
> Since I don't have hardware that can test external clocks, I can't
> guarantee that any such code will work.
>
> I'm sure there are a dozen things I could do to improve the driver
> as it stands, but I need to draw the line somewhere.
I guess my point is it appears the patch is related to how we
represent the RX/TX clock information in the device tree.
I'm suggesting that we do something like:
rx-clock-type = "brg" or "clk"
rx-clock-id = 3
I don't see how this doesn't cover what you need in the device tree.
- k
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH 0/6] Patch series to add of_platform binding to xilinxfb
From: Grant Likely @ 2007-10-09 17:39 UTC (permalink / raw)
To: Antonino A. Daplas
Cc: linuxppc, akonovalov, linux-fbdev-devel, linux-kernel,
Paul Mackerras
In-Reply-To: <1191906242.6083.7.camel@daplas>
On 10/8/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> On Mon, 2007-10-08 at 22:43 -0600, Grant Likely wrote:
> > BTW, what path do framebuffer patches take to get into Linus' tree?
> > Does he pull your tree directly, or do they go through someone else's
> > tree?
>
> They all go to -mm tree, unless it's a needed fix, then to Linus's.
>
> Tony
Ah, okay.
Since the XilinxFB is a powerpc-only device, is it okay with you if I
get Paul Mackerras to merge them into his tree instead (that way the
changes go in with the platform code which requires these changes)
Paulus, is that okay by you?
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [patch v2] PS3: Add os-area database routines
From: Linas Vepstas @ 2007-10-09 17:15 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, paulus
In-Reply-To: <470AD44C.5080305@am.sony.com>
On Mon, Oct 08, 2007 at 06:07:24PM -0700, Geoff Levand wrote:
> Subject: PS3: Add os-area database routines
>
> Add support for a simple tagged database in the PS3 flash rom
> os-area. The database allows the flash rom os-area to be shared
> between a bootloader and installed operating systems. The
> application ps3-flash-util or the library libps3-utils from the
> ps3-utils package can be used for userspace database operations.
Perhaps I missed the discussion; but .. out of general curiosity,
what is the relation between this and the ppc_md.nvram_* system?
I note that pseries, powermac, chrp, celleb implement the nvram calls,
but cell and ps3 do not. So clearly, whatever this is, its not
layered on top of nvram?
FWIW, I don't quite understand the nvram system; it seems to have
partitions; one part is an "os area", and a chuck of it is set
up as a file system.
So I'm wondering -- wouldn't the DB os-area be "generically
interesting" to other ppowerpc platforms? Maybe even other arches?
And why isn't this built on top of the nvram structure? ... etc?
--linas
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Timur Tabi @ 2007-10-09 16:48 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <470BB09D.7060304@freescale.com>
Scott Wood wrote:
> In the absence of a BRG, the driver should just not support changing the
> baud rate -- it shouldn't fail to function.
Since I don't have hardware that can test external clocks, I can't guarantee
that any such code will work.
I'm sure there are a dozen things I could do to improve the driver as it
stands, but I need to draw the line somewhere.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Scott Wood @ 2007-10-09 16:48 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <470BB087.7080607@freescale.com>
Timur Tabi wrote:
> Scott Wood wrote:
>
>> Or we could just stop putting CLK information in the device tree. :-)
>
> If we had a BRG/CLK manager, we probably could do that. But we don't
> have something like that now.
I didn't say stop putting BRG information in there -- just CLKs, which
are static setup that can be done in firmware or the board file. This
works fine on CPM1/2.
-Scott
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Scott Wood @ 2007-10-09 16:47 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <470BAFA8.1060408@freescale.com>
Timur Tabi wrote:
> UART, for instance, can use a CLK signal, but I wrote the driver to only
> support BRGs because there are plenty of them and it's a lot simpler. But
> someone, for instance, could wire up his board to want to use external clocks
> for some UARTs, and so he'd need to modify the driver.
In the absence of a BRG, the driver should just not support changing the
baud rate -- it shouldn't fail to function.
-Scott
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Timur Tabi @ 2007-10-09 16:47 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <470BB055.6050602@freescale.com>
Scott Wood wrote:
> Or we could just stop putting CLK information in the device tree. :-)
If we had a BRG/CLK manager, we probably could do that. But we don't have
something like that now.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Scott Wood @ 2007-10-09 16:46 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <8D4AA8EB-812F-4E58-A13C-CE3BA72037F3@kernel.crashing.org>
Kumar Gala wrote:
> Ok, I went and looked at how rx-clock & tx-clock are spec'd in
> booting-without-of.txt
>
> Why dont we fix this so we have a property that says "BRG" or "CLK"
> and another that has ID = [1.16] for BRG and [1..24] for CLK.
Or we could keep it as it is, check the beginning of the string for
"BRG" or "CLK", and binarize the number that follows.
Or we could just stop putting CLK information in the device tree. :-)
-Scott
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Timur Tabi @ 2007-10-09 16:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <8D4AA8EB-812F-4E58-A13C-CE3BA72037F3@kernel.crashing.org>
Kumar Gala wrote:
> Ok, I went and looked at how rx-clock & tx-clock are spec'd in
> booting-without-of.txt
>
> Why dont we fix this so we have a property that says "BRG" or "CLK" and
> another that has ID = [1.16] for BRG and [1..24] for CLK.
Because sometimes you can use both BRGs and CLKs. Some operations can be done
only on one or the other, and some can be done on both. The enum itself is
fine, I think. I'd rather not split up the two, just report an error if you
specify a clock source that's not support for that particular purpose.
UART, for instance, can use a CLK signal, but I wrote the driver to only
support BRGs because there are plenty of them and it's a lot simpler. But
someone, for instance, could wire up his board to want to use external clocks
for some UARTs, and so he'd need to modify the driver.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Kumar Gala @ 2007-10-09 16:38 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <470BAAA2.30400@freescale.com>
Ok, I went and looked at how rx-clock & tx-clock are spec'd in
booting-without-of.txt
Why dont we fix this so we have a property that says "BRG" or "CLK"
and another that has ID = [1.16] for BRG and [1..24] for CLK.
- k
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Timur Tabi @ 2007-10-09 16:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <2E830F97-ADAE-43CA-9BD3-BEBFEFBE1D5C@kernel.crashing.org>
Kumar Gala wrote:
> is 19 the actual value you'd end up using from the HW? or is it related
> to some random enum value?
Random enum value. Here's the code in ucc_geth:
prop = of_get_property(np, "rx-clock", NULL);
ug_info->uf_info.rx_clock = *prop;
Here's the data type:
struct ucc_fast_info {
int ucc_num;
enum qe_clock rx_clock;
enum qe_clock tx_clock;
...
As you can see, it doesn't even validate the property.
My uart driver has this:
rx-clock-source = "BRG5";
tx-clock-source = "BRG6";
sprop = of_get_property(np, "rx-clock-source", NULL);
if (!sprop) {
printk(KERN_ERR
"ucc-uart: missing rx-clock-source in device tree\n");
kfree(qe_port);
return -ENODEV;
}
qe_port->us_info.rx_clock = of_clock_source(sprop);
if ((qe_port->us_info.rx_clock < QE_BRG1) ||
(qe_port->us_info.rx_clock > QE_BRG16)) {
printk(KERN_ERR
"ucc-uart: rx-clock-source must be a BRG for UART\n");
kfree(qe_port);
return -ENODEV;
}
I will be submitting patches to ucc_geth to fix this problem.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox