* Re: time accounting problem (powerpc only?)
From: Johannes Berg @ 2007-11-27 13:42 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev list, Linux Kernel list
In-Reply-To: <20071127050031.GC24243@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 547 bytes --]
On Tue, 2007-11-27 at 16:00 +1100, Tony Breeds wrote:
> On Mon, Nov 26, 2007 at 05:23:13PM +0100, Johannes Berg wrote:
> > Contrary to what I claimed later in the thread, my 64-bit powerpc box
> > (quad-core G5) doesn't suffer from this problem.
> >
> > Does anybody have any idea? I don't even know how to debug it further.
>
> I'll see if I can grab an appropriate machine tomorrow and have a look at
> it. I think it's just an accounting bug, which is probably my fault :)
Thanks. Let me know if you need any info.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] fsl_soc: add support for gianfar for fixed-link property
From: Joakim Tjernlund @ 2007-11-27 13:17 UTC (permalink / raw)
To: avorontsov; +Cc: netdev, linux-kernel, Jeff Garzik, linuxppc-dev
In-Reply-To: <20071127113935.GA26867@localhost.localdomain>
On Tue, 2007-11-27 at 14:39 +0300, Anton Vorontsov wrote:
> On Mon, Nov 26, 2007 at 04:04:08PM +0100, Joakim Tjernlund wrote:
> > On Mon, 2007-11-26 at 17:29 +0300, Vitaly Bordug wrote:
> > > fixed-link says: register new "Fixed/emulated PHY", i.e. PHY that
> > > not connected to the real MDIO bus.
> > >
> > > Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> > > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > >
> > > ---
> > >
> > > Documentation/powerpc/booting-without-of.txt | 3 +
> > > arch/powerpc/sysdev/fsl_soc.c | 56 ++++++++++++++++++--------
> > > 2 files changed, 42 insertions(+), 17 deletions(-)
> > >
> > >
> > > diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> > > index e9a3cb1..cf25070 100644
> > > --- a/Documentation/powerpc/booting-without-of.txt
> > > +++ b/Documentation/powerpc/booting-without-of.txt
> > > @@ -1254,6 +1254,9 @@ platforms are moved over to use the flattened-device-tree model.
> > > services interrupts for this device.
> > > - phy-handle : The phandle for the PHY connected to this ethernet
> > > controller.
> > > + - fixed-link : <a b c> where a is emulated phy id - choose any,
> > > + but unique to the all specified fixed-links, b is duplex - 0 half,
> > > + 1 full, c is link speed - d#10/d#100/d#1000.
> >
> > Good work!
> > May I suggest adding a "d" to <a b c> where d is flow control - 0 no, 1 yes
>
> Well, I see no reference of the "flow" neither in the include/linux/mii.h
> nor in the drivers/net/phy/*. :-/ Thus today there is no such register
> bit we can emulate?..
Well, as good as I can recall, flow control(pause) is something that the
PHY negotiates, just like FDX/HDX and should be dealt with in the
adjust_link callback but not many do currently.
If you seach for pause in phy_device.c you will find it.
>
> > flow control or not just popped up here today so I got a use for it.
>
> ..and I looked into few drivers (gianfar, ucc), and they seem to use
> hard-coded flow control values, thus they don't speak to the PHYs
> about that.
Yes, but they should.
>
> Can you give any reference to the driver that needs that parameter?
> Does it use PHY subsystem to obtain flow-control on/off information?
>
> Thanks,
>
^ permalink raw reply
* Re: time accounting problem (powerpc only?)
From: Johannes Berg @ 2007-11-27 13:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Linux Kernel list
In-Reply-To: <18251.59930.30260.145217@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 727 bytes --]
On Tue, 2007-11-27 at 20:57 +1100, Paul Mackerras wrote:
> Johannes Berg writes:
>
> > Contrary to what I claimed later in the thread, my 64-bit powerpc box
> > (quad-core G5) doesn't suffer from this problem.
> >
> > Does anybody have any idea? I don't even know how to debug it further.
>
> I see it on my G4 powerbook. However, a compute-bound task runs just
> as fast (i.e. completes in the same elapsed time) as on older kernels,
> so it does look like it is just an accounting problem. If the CPU was
> really spending more than half its time servicing hardware interrupts,
> the task should take more than twice as long to complete.
Exactly. So where do I look for the accounting bug?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: time accounting problem (powerpc only?)
From: Johannes Berg @ 2007-11-26 23:55 UTC (permalink / raw)
To: Linux Kernel list; +Cc: linuxppc-dev list
In-Reply-To: <1195814816.4149.94.camel@johannes.berg>
[-- Attachment #1: Type: text/plain, Size: 200 bytes --]
> On my powerbook, with NO_HZ and HIGH_RES_TIMERS, I observed recently
> that powernowd would not ever switch between CPU speeds.
Also happens without NO_HZ (with HIGH_RES_TIMERS).
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: 2.6.24-rc3: High CPU load -- hardware interrupts
From: Jörg Sommer @ 2007-11-27 11:13 UTC (permalink / raw)
To: Elimar Riesebieter; +Cc: linuxppc-dev
In-Reply-To: <20071126223831.GA11112@frodo.home.lxtec.de>
[-- Attachment #1: Type: text/plain, Size: 403 bytes --]
Hi Elimar,
Elimar Riesebieter schrieb am Mon 26. Nov, 23:38 (+0100):
> I can confirm this situation. But it seems, that no one takes care
> of it ....
Have a look at the thread “time accounting problem (powerpc only?)”
started by Johannes Berg on 23 Nov 2007.
Bye, Jörg.
--
Du kannst einem Schwein einen goldenen Ring durch die Nase ziehen,
deswegen bleibt es trozdem ein Schwein!
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] fsl_soc: add support for gianfar for fixed-link property
From: Anton Vorontsov @ 2007-11-27 11:39 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev, linux-kernel, Jeff Garzik, linuxppc-dev
In-Reply-To: <1196089448.12625.62.camel@gentoo-jocke.transmode.se>
On Mon, Nov 26, 2007 at 04:04:08PM +0100, Joakim Tjernlund wrote:
> On Mon, 2007-11-26 at 17:29 +0300, Vitaly Bordug wrote:
> > fixed-link says: register new "Fixed/emulated PHY", i.e. PHY that
> > not connected to the real MDIO bus.
> >
> > Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> >
> > ---
> >
> > Documentation/powerpc/booting-without-of.txt | 3 +
> > arch/powerpc/sysdev/fsl_soc.c | 56 ++++++++++++++++++--------
> > 2 files changed, 42 insertions(+), 17 deletions(-)
> >
> >
> > diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> > index e9a3cb1..cf25070 100644
> > --- a/Documentation/powerpc/booting-without-of.txt
> > +++ b/Documentation/powerpc/booting-without-of.txt
> > @@ -1254,6 +1254,9 @@ platforms are moved over to use the flattened-device-tree model.
> > services interrupts for this device.
> > - phy-handle : The phandle for the PHY connected to this ethernet
> > controller.
> > + - fixed-link : <a b c> where a is emulated phy id - choose any,
> > + but unique to the all specified fixed-links, b is duplex - 0 half,
> > + 1 full, c is link speed - d#10/d#100/d#1000.
>
> Good work!
> May I suggest adding a "d" to <a b c> where d is flow control - 0 no, 1 yes
Well, I see no reference of the "flow" neither in the include/linux/mii.h
nor in the drivers/net/phy/*. :-/ Thus today there is no such register
bit we can emulate?..
> flow control or not just popped up here today so I got a use for it.
..and I looked into few drivers (gianfar, ucc), and they seem to use
hard-coded flow control values, thus they don't speak to the PHYs
about that.
Can you give any reference to the driver that needs that parameter?
Does it use PHY subsystem to obtain flow-control on/off information?
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [2.6 patch] the scheduled I2C RTC driver removal
From: Jean Delvare @ 2007-11-27 10:19 UTC (permalink / raw)
To: linuxppc-dev, Kumar Gala, Paul Mackerras
Cc: Adrian Bunk, linux-kernel, rtc-linux, i2c
In-Reply-To: <20071102231243.61c39d23@hyperion.delvare>
On Fri, 2 Nov 2007 23:12:43 +0100, Jean Delvare wrote:
> Hi Adrian,
>
> On Thu, 1 Nov 2007 00:03:58 +0100, Adrian Bunk wrote:
> > This patch contains the scheduled removal of legacy I2C RTC drivers with
> > replacement drivers.
> > (...)
> > Documentation/feature-removal-schedule.txt | 7
> > arch/powerpc/platforms/83xx/mpc832x_mds.c | 24 -
> > arch/powerpc/platforms/83xx/mpc834x_mds.c | 24 -
> > arch/powerpc/platforms/83xx/mpc836x_mds.c | 24 -
> > arch/ppc/platforms/83xx/mpc834x_sys.c | 20 -
> > arch/ppc/platforms/85xx/tqm85xx.c | 21 -
> > arch/ppc/platforms/katana.c | 21 -
> > drivers/i2c/chips/Kconfig | 38 -
> > drivers/i2c/chips/Makefile | 3
> > drivers/i2c/chips/ds1337.c | 410 --------------------
> > drivers/i2c/chips/ds1374.c | 267 -------------
> > drivers/i2c/chips/m41t00.c | 413 ---------------------
> > include/linux/m41t00.h | 50 --
> > 13 files changed, 1322 deletions(-)
>
> Obviously we're not yet ready to remove the drivers, as some platforms
> still use them! The remaining platforms need to be updated to use the
> new RTC drivers first. The mapping is as follows:
>
> chip | old driver | new driver |
> -----------+------------+--------------+
> DS1337 | ds1337 | rtc-ds1307 |
> DS1339 | ds1337 | rtc-ds1307 |
> DS1374 | ds1374 | rtc-ds1374 |
> M41T00 | m41t00 | rtc-ds1307 |
> M41T81 | m41t00 | rtc-m41t80 |
> M41ST85 | m41t00 | rtc-m41t80 |
>
> So, PPC people, please update your platform code to make use of the new
> drivers now, and let me know when you're done. As soon as all platforms
> are converted, I'll apply Adrian's patch.
As of 2.6.24-rc3-git2, I see that the references to the obsolete
drivers have been removed from arch/powerpc/*. Great, I'll update
Adrian's patch. This leaves only 3 platforms under arch/ppc (83xx, 85xx
and katana) that still need updating. Kumar, Paul, what's the status?
Thanks,
--
Jean Delvare
^ permalink raw reply
* MPC5200 I2C and 2.6 kernel
From: Oliver Rutsch @ 2007-11-27 10:07 UTC (permalink / raw)
To: Linuxppc-dev
Hi,
I'm using a TQM5200S (MPC5200B CPU) module on the STK52xx starter kit.
For some reasons I have to use the 2.6 kernel (the latest 2.6.23.1 from
the DENX git archive) with ARCH=powerpc and most of my external hardware
is running fine with this.
On the starter kit there is an external I2C RTC (M41T00) and I like to
use it now. In the 2.4 kernel there were some options regarding MPC5200
I2C, but I could not find them in the 2.6 kernel.
There were options for MPCxxx I2C Algorithm or MPC5xxx TQM5200 I2C
Adapter, for example.
Regardless what I'm doing in the 2.6 kernel configuration I can't get
this RTC running (I activated RTC support and the driver for the M41T00
in the configuration).
hwclock --debug tells me:
hwclock: Open of /dev/rtc failed, errno=19: No such device.
No usable clock interface found.
So the questions is: Is the I2C support for the MPC5200 in the 2.6.23
kernel in an usable state? Or do I need some special patches from TQ for
this board to get it running?
Thanks in advance and bye,
--
Dipl. Ing. Oliver Rutsch
EMail: orutsch@sympatec.com
^ permalink raw reply
* Re: How to map addresses beyond 4GB
From: Dell Query @ 2007-11-27 9:57 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <A54CDFF0-EF7A-445B-8A1E-E211E5D267D9@embeddedalley.com>
[-- Attachment #1: Type: text/plain, Size: 354 bytes --]
Thanks
Dan Malek <dan@embeddedalley.com> wrote:
On Nov 22, 2007, at 2:42 AM, Dell Query wrote:
> May I know how to map this one?
Just call ioremap() as usual. It will understand the > 4G
physical address and return a useful virtual address
to you.
-- Dan
---------------------------------
Never miss a thing. Make Yahoo your homepage.
[-- Attachment #2: Type: text/html, Size: 610 bytes --]
^ permalink raw reply
* Re: time accounting problem (powerpc only?)
From: Paul Mackerras @ 2007-11-27 9:57 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Linux Kernel list
In-Reply-To: <1196094193.4149.287.camel@johannes.berg>
Johannes Berg writes:
> Contrary to what I claimed later in the thread, my 64-bit powerpc box
> (quad-core G5) doesn't suffer from this problem.
>
> Does anybody have any idea? I don't even know how to debug it further.
I see it on my G4 powerbook. However, a compute-bound task runs just
as fast (i.e. completes in the same elapsed time) as on older kernels,
so it does look like it is just an accounting problem. If the CPU was
really spending more than half its time servicing hardware interrupts,
the task should take more than twice as long to complete.
Paul.
^ permalink raw reply
* Re: [patch 2/9] ps3: Use symbolic names for video modes
From: Geert Uytterhoeven @ 2007-11-27 8:17 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linux/PPC Development, Linux Frame Buffer Device Development
In-Reply-To: <20071127110538.32f8dfef.sfr@canb.auug.org.au>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2562 bytes --]
On Tue, 27 Nov 2007, Stephen Rothwell wrote:
> On Mon, 26 Nov 2007 18:24:57 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > @@ -594,20 +594,21 @@ static const struct {
> > unsigned mask : 19;
> > unsigned id : 4;
> > } ps3av_preferred_modes[] = {
> > - { .mask = PS3AV_RESBIT_WUXGA << SHIFT_VESA, .id = 13 },
> > - { .mask = PS3AV_RESBIT_1920x1080P << SHIFT_60, .id = 5 },
> > - { .mask = PS3AV_RESBIT_1920x1080P << SHIFT_50, .id = 10 },
> > - { .mask = PS3AV_RESBIT_1920x1080I << SHIFT_60, .id = 4 },
> > - { .mask = PS3AV_RESBIT_1920x1080I << SHIFT_50, .id = 9 },
> > - { .mask = PS3AV_RESBIT_SXGA << SHIFT_VESA, .id = 12 },
> > - { .mask = PS3AV_RESBIT_WXGA << SHIFT_VESA, .id = 11 },
> > - { .mask = PS3AV_RESBIT_1280x720P << SHIFT_60, .id = 3 },
> > - { .mask = PS3AV_RESBIT_1280x720P << SHIFT_50, .id = 8 },
> > - { .mask = PS3AV_RESBIT_720x480P << SHIFT_60, .id = 2 },
> > - { .mask = PS3AV_RESBIT_720x576P << SHIFT_50, .id = 7 },
> > + { PS3AV_RESBIT_WUXGA << SHIFT_VESA, PS3AV_MODE_WUXGA },
> > + { PS3AV_RESBIT_1920x1080P << SHIFT_60, PS3AV_MODE_1080P60 },
> > + { PS3AV_RESBIT_1920x1080P << SHIFT_50, PS3AV_MODE_1080P50 },
> > + { PS3AV_RESBIT_1920x1080I << SHIFT_60, PS3AV_MODE_1080I60 },
> > + { PS3AV_RESBIT_1920x1080I << SHIFT_50, PS3AV_MODE_1080I50 },
> > + { PS3AV_RESBIT_SXGA << SHIFT_VESA, PS3AV_MODE_SXGA },
> > + { PS3AV_RESBIT_WXGA << SHIFT_VESA, PS3AV_MODE_WXGA },
> > + { PS3AV_RESBIT_1280x720P << SHIFT_60, PS3AV_MODE_720P60 },
> > + { PS3AV_RESBIT_1280x720P << SHIFT_50, PS3AV_MODE_720P50 },
> > + { PS3AV_RESBIT_720x480P << SHIFT_60, PS3AV_MODE_480P },
> > + { PS3AV_RESBIT_720x576P << SHIFT_50, PS3AV_MODE_576P },
>
> Why did you remove the C99 style initialisers?
Because else things no longer fit on one line.
I prefered a clean structural overview over the protection against the
(almost nonexisting) risk of initializing the wrong member.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers
From: Vitaly Bordug @ 2007-11-27 8:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <474B3D7F.8060503@freescale.com>
On Mon, 26 Nov 2007 15:41:19 -0600
Scott Wood wrote:
> Vitaly Bordug wrote:
> > perhaps I was not clear enough. That was a rough idea how to handle
> > the whole thing, not just cpm_cr_cmd. This cpm command is a corner
> > case, but there can be other actions that may confuse CPM being
> > triggered simultaneously or overlapping.
>
> What kind of actions did you have in mind? Microcode patching?
>
microcode is another case to handle gracefully. There are also
"soft" cases like cpmux mess-up, incompatible SoC devices (which we are handling by
logical exclude now but which do have natural reasons of "not leaving together" like
shared dedicated GPIO or smth else) etc.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: Booting latest linux kernel(2.6.20) on MPC8548ECDS
From: Kumar Gala @ 2007-11-27 7:40 UTC (permalink / raw)
To: rajendra prasad; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <760ff48e0711262154u39c30dbduacdf310b820a7c81@mail.gmail.com>
On Nov 26, 2007, at 11:54 PM, rajendra prasad wrote:
> Hi,
>
> I am using MPC8548ECDS board from CDS for my telecom application. I am
> able to build 2.6.10 linux kernel and boot 2.6.10 kernel on
> MPC8548ECDS board.When I take same configuration file and built
> successfully but not able to boot on MPC8548E CDS board.I am using
> u-boot-1.1.6 as boot loader.I came to know taht latest kernel is
> booted with new procedure.Pls tell me the procedure how to boot
> procedure.
Ask this question on the linuxppc-dev list. You're more likely to get
an answer.
Its unclear, but you are trying to use the latest kernel on a MPC8548E
CDS?
- k
^ permalink raw reply
* Re: 85xx software reset problems from paulus.git
From: Kumar Gala @ 2007-11-27 7:38 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <474B2A7F.5090607@anagramm.de>
>> Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or when
>> calling 'reboot' in the shell, it just hangs. Using the same dts and
>> resets in 2.6.23.1 reboots fine. I don't have a cds reference, but
>> someone who does should be able to confirm whether the issue exists
>> or
>> not by just attempting to reboot via bash.
Can someone do a git-bisect and find the patch that breaks things?
>> ACK. Exactly the same over here (mpc8540ads compatible).
> I added the global-utilities today as well, but reboot fails.
if you are on a 8540 GUTS doesn't support hreset_req (8548 or newer).
> Why is the guts stuff missing i.e. in most of the shipped
> mpc85xx*.dts? Does it depend on some hardware connections
> external to the CPU?
Only the 8548 or newer CPUs have the GUTS HRESET_REQ ability that we
use to reset. (8540, 8560, 8541, 8555 do not).
- k
^ permalink raw reply
* Re: time accounting problem (powerpc only?)
From: Tony Breeds @ 2007-11-27 5:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Linux Kernel list
In-Reply-To: <1196094193.4149.287.camel@johannes.berg>
On Mon, Nov 26, 2007 at 05:23:13PM +0100, Johannes Berg wrote:
> Contrary to what I claimed later in the thread, my 64-bit powerpc box
> (quad-core G5) doesn't suffer from this problem.
>
> Does anybody have any idea? I don't even know how to debug it further.
I'll see if I can grab an appropriate machine tomorrow and have a look at
it. I think it's just an accounting bug, which is probably my fault :)
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: The question about the high memory support on MPC8360?
From: vijay baskar @ 2007-11-27 4:27 UTC (permalink / raw)
To: Scott Wood; +Cc: 郭劲, linuxppc-embedded
In-Reply-To: <20071126165751.GA4415@loki.buserror.net>
[-- Attachment #1: Type: text/html, Size: 4592 bytes --]
^ permalink raw reply
* Re: dtc: Add valgrind support to testsuite
From: David Gibson @ 2007-11-27 4:17 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IwmA3-0002eh-OO@jdl.com>
On Mon, Nov 26, 2007 at 04:10:39PM -0600, Jon Loeliger wrote:
> So, like, the other day David Gibson mumbled:
> > This patch adds some options to the run_tests.sh script allowing it to
> > run all the testcases under valgrind to check for pointer corruption
> > bugs and memory leaks. Invoking "make checkm" will run the testsuite
> > with valgrind.
> >
> > It include a mechanism for specifying valgrind errors to be suppressed
> > on a per-testcase basis, and adds a couple of such suppression files
> > for the mangle-layout and open_pack testcases which dump for use by
> > other testcases a buffer which may contain uninitialized sections. We
> > use suppressions rather than initializing the buffer so that valgrind
> > will catch any internal access s to the uninitialized data, which
> > would be a bug.
> >
> > The patch also fixes one genuine bug caught by valgrind -
> > _packblocks() in fdt_rw.c was using memcpy() where it should have been
> > using memmove().
> >
> > At present the valgrinding won't do anything useful for testcases
> > invoked via a shell script - which includes all the dtc testcases. I
> > plan to fix that later.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> Applied.
>
> Thanks,
> jdl
>
> PS -- Clearly, I'm going to have to break down and install valgrind now. :-)
Absolutely. Actually valgrind didn't show up much interesting on
libfdt. Some preliminary investigations suggest it may find some
problems in dtc, once I get the shell scripts to pass the valgrind
option through properly.
Be aware that running the testsuite under valgrind will take a long
time. It goes from something like 1s without valgrind to 10 minutes
on one of my machines.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: dtc: Flexible tree checking infrastructure (v2)
From: David Gibson @ 2007-11-27 3:58 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IwmCq-0002g9-Nk@jdl.com>
On Mon, Nov 26, 2007 at 04:13:32PM -0600, Jon Loeliger wrote:
> So, like, the other day David Gibson mumbled:
> > dtc: Flexible tree checking infrastructure
> >
> > Here, at last, is a substantial start on revising dtc's infrastructure
> > for checking the tree; this is the rework I've been saying was
> > necessary practically since dtc was first release.
> >
> > In the new model, we have a table of "check" structures, each with a
> > name, references to checking functions, and status variables. Each
> > check can (in principle) be individually switched off or on (as either
> > a warning or error). Checks have a list of prerequisites, so if
> > checks need to rely on results from earlier checks to make sense (or
> > even to avoid crashing) they just need to list the relevant other
> > checks there.
> >
> > For now, only the "structural" checks and the fixups for phandle
> > references are converted to the new mechanism. The rather more
> > involved semantic checks (which is where this new mechanism will
> > really be useful) will have to be converted in future patches.
> >
> > At present, there's no user interface for turning on/off the checks -
> > the -f option now forces output even if "error" level checks fail.
> > Again, future patches will be needed to add the fine-grained control,
> > but that should be quite straightforward with the infrastructure
> > implemented here.
> >
> > Also adds a testcase for the handling of bad references, which catches
> > a bug encountered while developing this patch.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> While I've Applied this one, it has introduced this:
>
> CC dtc.o
> dtc.c: In function 'main':
> dtc.c:199: warning: 'structure_ok' is used uninitialized in this function
>
> Followup easy patch?
Crap. For some reason my compiler isn't giving that warning, so I
missed that little bug :(.
I'm away at the moment, I'll see what I can do.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* RE: LED heartbeat trigger - in_atomic() while allocs
From: Benedict, Michael @ 2007-11-27 1:02 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-embedded
In-Reply-To: <20071126203649.GD29155@localdomain>
Thanks, yeah I see that now. I just changed the alloc to be GPF_ATOMIC
for now, but I don't really know how this was intended to work.
-Michael=20
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+mbenedict=3Dtwacs.com@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces+mbenedict=3Dtwacs.com@ozlabs.o
rg] On Behalf Of Nathan Lynch
> Sent: Monday, November 26, 2007 2:37 PM
> To: Benedict, Michael
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: LED heartbeat trigger - in_atomic() while allocs
>=20
> Benedict, Michael wrote:
> > I was playing around with the LED heartbeat trigger and it=20
> caught the
> > BUG() code when trying to activate. Does anyone know why this call
> > stack would be in_atomic()? Or any ideas for a patch that=20
> would allow
> > the heartbeat trigger to allocate when it is not in atomic context?
> >=20
> > BUG: sleeping function called from invalid context at mm/slab.c:3024
> > in_atomic():1, irqs_disabled():0
> > Call Trace:
> > [def3dd90] [c0008e60] show_stack+0x48/0x194 (unreliable)
> > [def3ddc0] [c0014160] __might_sleep+0xd0/0xdc
> > [def3dde0] [c0063e60] kmem_cache_zalloc+0xdc/0x12c
> > [def3de00] [c01975c0] heartbeat_trig_activate+0x24/0x80
> > [def3de20] [c0196844] led_trigger_set+0x128/0x160
> > [def3de40] [c0196988] led_trigger_store+0x10c/0x1a8
> > [def3deb0] [c0162f40] class_device_attr_store+0x44/0x5c
> > [def3dec0] [c00ae614] sysfs_write_file+0x114/0x1dc
> > [def3def0] [c0068ea4] vfs_write+0x9c/0x110
> > [def3df10] [c0068ff4] sys_write+0x4c/0x90
> > [def3df40] [c000fc00] ret_from_syscall+0x0/0x38
> > --- Exception: c01 at 0xfe83818
> > LR =3D 0xfe35448
> >=20
> > Kernel 2.6.22-4, powerpc, targeting an MPC 8347.
>=20
> From a brief glance at the code, looks like led_trigger_store is
> holding a rwlock while calling led_trigger_set.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
^ permalink raw reply
* Re: [PATCH] ehea: Add kdump support
From: Michael Neuling @ 2007-11-27 0:35 UTC (permalink / raw)
To: Christoph Raisch
Cc: Jeff Garzik, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Paul Mackerras, Marcus Eder, tklein, Stefan Roscher
In-Reply-To: <OF94123F44.9DB75CE9-ONC125739F.00398E63-C125739F.003B2AFE@de.ibm.com>
In message <OF94123F44.9DB75CE9-ONC125739F.00398E63-C125739F.003B2AFE@de.ibm.com> you wrote:
> Michael Ellerman wrote on 26.11.2007 09:16:28:
> > Solutions that might be better:
> >
> > a) if there are a finite number of handles and we can predict their
> > values, just delete them all in the kdump kernel before the driver
> > loads.
>
> Guessing the values does not work, because of the handle structure
> defined by the hypervisor.
>
> > b) if there are a small & finite number of handles, save their values
> > in a device tree property and have the kdump kernel read them and
> > delete them before the driver loads.
>
> 5*16*nr_ports+1+1= >82. a ML16 has 4 adapters with up to 16 ports, so the
> number is not small anymore....
I assume this machine with a huge number of adapters has a huge amount
of memory too! :-)
> The device tree functions are currently not exported.
We can add this.
> If you crashdump to a new kernel, will it get the device tree
> representation of the crashed kernel or of the initial one of open
> firmware?
The kexec tools userspace control this. Normally it just takes the
current device tree plus some modifications (eg. initrd location
changes).
So provided the ehea driver export this info somewhere, it can be
grabbed by the kexec tools and stuffed in the device tree of the new
kernel.
That being said, the proper place to have this would be original device
tree.
>
> > c) if neither of those work, provide a minimal routine that _only_
> > deletes the handles in the crashed kernel.
>
> I would hope this has the highest chance to actually work.
> For this we would have to add a proper notifier chain.
> Do you agree?
>
> > d) <something else>
>
> Firmware change? But that's not something you will get very soon.
>
> Christoph R.
>
^ permalink raw reply
* Re: [patch 2/9] ps3: Use symbolic names for video modes
From: Stephen Rothwell @ 2007-11-27 0:05 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Linux Frame Buffer Device Development
In-Reply-To: <20071126172712.128301000@pademelon.sonytel.be>
[-- Attachment #1: Type: text/plain, Size: 1819 bytes --]
On Mon, 26 Nov 2007 18:24:57 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
>
> @@ -594,20 +594,21 @@ static const struct {
> unsigned mask : 19;
> unsigned id : 4;
> } ps3av_preferred_modes[] = {
> - { .mask = PS3AV_RESBIT_WUXGA << SHIFT_VESA, .id = 13 },
> - { .mask = PS3AV_RESBIT_1920x1080P << SHIFT_60, .id = 5 },
> - { .mask = PS3AV_RESBIT_1920x1080P << SHIFT_50, .id = 10 },
> - { .mask = PS3AV_RESBIT_1920x1080I << SHIFT_60, .id = 4 },
> - { .mask = PS3AV_RESBIT_1920x1080I << SHIFT_50, .id = 9 },
> - { .mask = PS3AV_RESBIT_SXGA << SHIFT_VESA, .id = 12 },
> - { .mask = PS3AV_RESBIT_WXGA << SHIFT_VESA, .id = 11 },
> - { .mask = PS3AV_RESBIT_1280x720P << SHIFT_60, .id = 3 },
> - { .mask = PS3AV_RESBIT_1280x720P << SHIFT_50, .id = 8 },
> - { .mask = PS3AV_RESBIT_720x480P << SHIFT_60, .id = 2 },
> - { .mask = PS3AV_RESBIT_720x576P << SHIFT_50, .id = 7 },
> + { PS3AV_RESBIT_WUXGA << SHIFT_VESA, PS3AV_MODE_WUXGA },
> + { PS3AV_RESBIT_1920x1080P << SHIFT_60, PS3AV_MODE_1080P60 },
> + { PS3AV_RESBIT_1920x1080P << SHIFT_50, PS3AV_MODE_1080P50 },
> + { PS3AV_RESBIT_1920x1080I << SHIFT_60, PS3AV_MODE_1080I60 },
> + { PS3AV_RESBIT_1920x1080I << SHIFT_50, PS3AV_MODE_1080I50 },
> + { PS3AV_RESBIT_SXGA << SHIFT_VESA, PS3AV_MODE_SXGA },
> + { PS3AV_RESBIT_WXGA << SHIFT_VESA, PS3AV_MODE_WXGA },
> + { PS3AV_RESBIT_1280x720P << SHIFT_60, PS3AV_MODE_720P60 },
> + { PS3AV_RESBIT_1280x720P << SHIFT_50, PS3AV_MODE_720P50 },
> + { PS3AV_RESBIT_720x480P << SHIFT_60, PS3AV_MODE_480P },
> + { PS3AV_RESBIT_720x576P << SHIFT_50, PS3AV_MODE_576P },
Why did you remove the C99 style initialisers?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] [PPC 44x] enable L2-cache for ALPR, Katmai, Ocotea, and Taishan
From: Benjamin Herrenschmidt @ 2007-11-26 23:41 UTC (permalink / raw)
To: Yuri Tikhonov; +Cc: linuxppc-dev, sr, dzu
In-Reply-To: <1416528026.20071107014041@emcraft.com>
BTW... Do you know why we can't just enable HW snoop ? The 440SPe
documentation seems to indicate that this is supported by the L2 cache
via snooping on the PLB.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] e1000: Fix for 32 bits platforms with 64 bits resources
From: Kok, Auke @ 2007-11-26 23:15 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, auke-jan.h.kok, netdev
In-Reply-To: <474791D3.1090607@pobox.com>
Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
>> The e1000 driver stores the content of the PCI resources into
>> unsigned long's before ioremapping. This breaks on 32 bits
>> platforms that support 64 bits MMIO resources such as ppc 44x.
>>
>> This fixes it by removing those temporary variables and passing
>> directly the result of pci_resource_start/len to ioremap.
>>
>> The side effect is that I removed the assignments to the netdev
>> fields mem_start, mem_end and base_addr, which are totally useless
>> for PCI devices.
>>
>> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> --
>>
>> drivers/net/e1000/e1000_main.c | 18 +++++-------------
>> 1 file changed, 5 insertions(+), 13 deletions(-)
>
> Looks good to me. auke?
yes, please apply.
Acked-by: Auke Kok <auke-jan.h.kok@intel.com>
Auke
^ permalink raw reply
* Re: LED heartbeat trigger - in_atomic() while allocs
From: Nathan Lynch @ 2007-11-26 20:36 UTC (permalink / raw)
To: Benedict, Michael; +Cc: linuxppc-embedded
In-Reply-To: <BAF8B1E0BB28024A90895E746A3B610D1C2DA2@twx-exch01.twacs.local>
Benedict, Michael wrote:
> I was playing around with the LED heartbeat trigger and it caught the
> BUG() code when trying to activate. Does anyone know why this call
> stack would be in_atomic()? Or any ideas for a patch that would allow
> the heartbeat trigger to allocate when it is not in atomic context?
>
> BUG: sleeping function called from invalid context at mm/slab.c:3024
> in_atomic():1, irqs_disabled():0
> Call Trace:
> [def3dd90] [c0008e60] show_stack+0x48/0x194 (unreliable)
> [def3ddc0] [c0014160] __might_sleep+0xd0/0xdc
> [def3dde0] [c0063e60] kmem_cache_zalloc+0xdc/0x12c
> [def3de00] [c01975c0] heartbeat_trig_activate+0x24/0x80
> [def3de20] [c0196844] led_trigger_set+0x128/0x160
> [def3de40] [c0196988] led_trigger_store+0x10c/0x1a8
> [def3deb0] [c0162f40] class_device_attr_store+0x44/0x5c
> [def3dec0] [c00ae614] sysfs_write_file+0x114/0x1dc
> [def3def0] [c0068ea4] vfs_write+0x9c/0x110
> [def3df10] [c0068ff4] sys_write+0x4c/0x90
> [def3df40] [c000fc00] ret_from_syscall+0x0/0x38
> --- Exception: c01 at 0xfe83818
> LR = 0xfe35448
>
> Kernel 2.6.22-4, powerpc, targeting an MPC 8347.
>From a brief glance at the code, looks like led_trigger_store is
holding a rwlock while calling led_trigger_set.
^ permalink raw reply
* Re: 2.6.24-rc3: High CPU load -- hardware interrupts
From: Elimar Riesebieter @ 2007-11-26 22:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: joerg
In-Reply-To: <slrnfk1d21.229.joerg@alea.gnuu.de>
[-- Attachment #1: Type: text/plain, Size: 184 bytes --]
Hi,
I can confirm this situation. But it seems, that no one takes care
of it ....
Elimar
--
Excellent day for drinking heavily.
Spike the office water cooler;-)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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