Manish Ahuja writes:
> Check to see if there actually is data from a previously
> crashed kernel waiting. If so, Allow user-sapce tools to
> grab the data (by reading /proc/kcore). When user-space
> finishes dumping a section, it must release that memory
> by writing to sysfs. For example,
>
>
Manish Ahuja writes:
> +#define NUM_DUMP_SECTIONS 3
> +#define DUMP_HEADER_VERSION 0x1
> +#define DUMP_REQUEST_FLAG 0x1
> +#define DUMP_SOURCE_CPU 0x0001
> +#define DUMP_SOURCE_HPTE 0x0002
> +#define DUMP_SOURCE_RMO 0x0011
I think it would be clearer if you use a tab to line up the values,
like
Manish Ahuja writes:
> +#else /* CONFIG_PHYP_DUMP */
> +int early_init_dt_scan_phyp_dump(unsigned long node,
> + const char *uname, int depth, void *data) { return 0; }
This shouldn't be in the header file. Either put it in prom.c (and
make it return 1 so the of_scan_flat_dt call doe
Manish Ahuja writes:
> -static void
> -release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
> +static
> +void release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
This change looks rather pointless. If you have to change it, I'd
prefer:
static void release_memo
Manish Ahuja writes:
> +config PHYP_DUMP
> + bool "Hypervisor-assisted dump (EXPERIMENTAL)"
> + depends on PPC_PSERIES && EXPERIMENTAL
> + default y
I think this should default to n for now (i.e. leave out the default
line entirely). We can make it default to y later.
Paul.
Nothing appears to use BOOT_LOAD so remove it as a configurable option.
---
in my powerpc-next branch.
- k
arch/powerpc/Kconfig | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e4e13e0..803415e 100644
---
On Mar 10, 2008, at 7:37 PM, David Gibson wrote:
On Fri, Mar 07, 2008 at 10:55:51AM -0600, Kumar Gala wrote:
Normally we assume kernel images will be loaded at offset 0. However
there are situations, like when the kernel itself is running at a
non-zero
physical address, that we don't want t
On Tue, Mar 11, 2008 at 01:43:49AM +0100, Arnd Bergmann wrote:
> On Tuesday 11 March 2008, David Gibson wrote:
> > On Fri, Mar 07, 2008 at 04:39:30AM +0100, Segher Boessenkool wrote:
> > > > This isn't a problem with this device tree, but it's probably time we
> > > > started establishing some conv
On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote:
> [EMAIL PROTECTED] wrote:
> > Hi everybody,
> >
> > as part of a ARCH=ppc to ARCH=powerpc migration process, I'm
> > looking for an
> > OpenFirmware compatible way to handle a RAM-based MTD device.
> >
> > On the platform_device bas
On Thu, 2008-02-28 at 18:24 -0600, Manish Ahuja wrote:
> Initial patch for reserving memory in early boot, and freeing it later.
> If the previous boot had ended with a crash, the reserved memory would contain
> a copy of the crashed kernel data.
>
> Signed-off-by: Manish Ahuja <[EMAIL PROTECTED]>
On Tuesday 11 March 2008, David Gibson wrote:
> On Fri, Mar 07, 2008 at 04:39:30AM +0100, Segher Boessenkool wrote:
> > > This isn't a problem with this device tree, but it's probably time we
> > > started establishing some conventional generic names for nand flash
> > > and board-control devices.
On Fri, Mar 07, 2008 at 10:55:51AM -0600, Kumar Gala wrote:
> Normally we assume kernel images will be loaded at offset 0. However
> there are situations, like when the kernel itself is running at a non-zero
> physical address, that we don't want to load it at 0.
>
> Allow the wrapper to take an o
On Sun, Mar 09, 2008 at 11:31:09PM +0100, Philippe De Muyter wrote:
> Hi Ben,
>
> I now have a working linux on my mpc8540 based board, with support for
> the compactflash disk and the i2c rtc.
>
> The network tough, does not work yet. altough the the integrated ethernet
> controller (FEC) seems
On Fri, Mar 07, 2008 at 04:39:30AM +0100, Segher Boessenkool wrote:
> > This isn't a problem with this device tree, but it's probably time we
> > started establishing some conventional generic names for nand flash
> > and board-control devices.
> >
> > So, to start the ball rolling, I've seen sever
This patch adds a dts-format.txt in the Documentation directory, with
an introduction to the dtc source format. Note that this
documentation is also going into the upcoming ePAPR specification.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
---
Documentation/dts-format.txt | 110 +
Segher Boessenkool wrote:
>> It includes suggested changes by Segher Boessenkool and I think this
>> version was tested by Darrick J. Wong
>
>> -u8 reg;
>> +u8 reg, temp;
>> struct i2c_client *client = to_i2c_client(dev);
>> struct adt7473_data *data = i2c_get_clientdata(client);
On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
already did this. Uli Weigand found this back in November. I submitted
a patch for this which went into 2.6.25-rc4.
Can you please try again with rc4 ?
This is not the problem. This came up before and everyone seems have
forgot
It includes suggested changes by Segher Boessenkool and I think this
version was tested by Darrick J. Wong
- u8 reg;
+ u8 reg, temp;
struct i2c_client *client = to_i2c_client(dev);
struct adt7473_data *data = i2c_get_clientdata(client);
- int temp = simple_strt
Andrew, I think you may want this patch instead of the other
adt746x-logical-bitwise-confusion-in-set_max_duty_at_crit.patch
It includes suggested changes by Segher Boessenkool and I think this
version was tested by Darrick J. Wong
---
logical-bitwise & confusion
Signed-off-by: Roel Kluin <[EMAIL
The G5 that I have says:
cpu : PPC970FX, altivec supported
revision: 3.0 (pvr 003c 0300)
and it does indeed reproduce this bug.
It also strange for it to be the DABRX issue given the failure mode.
That is, it works sometimes but unreliably (as if the context s
On Mon, Mar 10, 2008 at 04:36:37PM -0300, Luis Machado wrote:
> On Mon, 2008-03-10 at 12:19 -0700, Roland McGrath wrote:
> > > On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
> > > already did this. Uli Weigand found this back in November. I submitted
> > > a patch for this whic
On Mon, 2008-03-10 at 12:19 -0700, Roland McGrath wrote:
> > On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
> > already did this. Uli Weigand found this back in November. I submitted
> > a patch for this which went into 2.6.25-rc4.
> > Can you please try again with rc4 ?
>
> T
> On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
> already did this. Uli Weigand found this back in November. I submitted
> a patch for this which went into 2.6.25-rc4.
> Can you please try again with rc4 ?
This is not the problem. This came up before and everyone seems have
On Mon, Mar 10, 2008 at 10:59:43AM +0100, Roel Kluin wrote:
> > The & 0xff here is bogus anyway; temp is only ever used as an u8,
> > so just declare it as that, or do proper overflow/underflow checking
> > on it. The patch will need testing on hardware too, since it changes
> > behaviour (it sho
Please pull from 'for-2.6.25' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.25
to receive the following updates:
arch/powerpc/boot/dts/mpc8377_mds.dts | 70 ++
arch/powerpc/boot/dts/mpc8378_mds.dts | 70 ++
arch/powerpc/boot/dts/
[EMAIL PROTECTED] wrote:
> Hi everybody,
>
> as part of a ARCH=ppc to ARCH=powerpc migration process, I'm
> looking for an
> OpenFirmware compatible way to handle a RAM-based MTD device.
>
> On the platform_device based ppc architecture, the
> drivers/mtd/maps/plat-ram.c
> driver handled "mtd-ram
Timur Tabi <[EMAIL PROTECTED]> writes:
> I'm confused about something in usercopy_64.c:
>
> unsigned long copy_from_user(void *to, const void __user *from, unsigned long
> n)
> {
> if (likely(access_ok(VERIFY_READ, from, n)))
> n = __copy_from_user(to, from, n);
> else
>
On Mon, Mar 10, 2008 at 11:38:49AM -0500, Timur Tabi wrote:
> I'm confused about something in usercopy_64.c:
>
> unsigned long copy_from_user(void *to, const void __user *from, unsigned long
> n)
> {
> if (likely(access_ok(VERIFY_READ, from, n)))
> n = __copy_from_user(to, fro
I'm confused about something in usercopy_64.c:
unsigned long copy_from_user(void *to, const void __user *from, unsigned long n)
{
if (likely(access_ok(VERIFY_READ, from, n)))
n = __copy_from_user(to, from, n);
else
memset(to, 0, n);
return n;
> On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
> already did this. Uli Weigand found this back in November. I submitted
> a patch for this which went into 2.6.25-rc4.
> Can you please try again with rc4 ?
I will try it and will post the results back.
Thanks Jens.
Regards,
Hi everybody,
as part of a ARCH=ppc to ARCH=powerpc migration process, I'm looking for an
OpenFirmware compatible way to handle a RAM-based MTD device.
On the platform_device based ppc architecture, the drivers/mtd/maps/plat-ram.c
driver handled "mtd-ram" platform devices. There is no such driv
The patch updates the booting-without-of.txt-file.
There is a description for the case
if mdio data and clock pins are on different processor ports.
It extends the "[PATCH v3] using mii-bitbang on different processor ports".
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
Signed-off-by: Scott
On Mar 7, 2008, at 5:59 PM, Andy Fleming wrote:
Not all e300 cores support the performance monitors, and the ones
that don't will be confused by the mf/mtpmr instructions. This
allows the support to be optional, so the 8349 can turn it off
while the 8379 can turn it on. Sadly, those aren't co
On Feb 2, 2008, at 1:47 AM, Yuri Tikhonov wrote:
Hello,
Here is the patch which makes Linux-2.6 swap routines operate
correctly on
the ppc-8xx-based machines.
Signed-off-by: Yuri Tikhonov <[EMAIL PROTECTED]>
applied.
- k
___
Linuxppc-dev mai
On Monday 10 March 2008, Luis Machado wrote:
> > Yes, I know. I tried it on the PS3 first and couldn't reproduce
> > the bug he saw on the blade.
>
> Arnd,
>
> Do we have any news on this topic?
>
> I've seen this happening quite often within GDB when using hardware
> watchpoints on a shared va
Am Montag, den 10.03.2008, 12:05 +0100 schrieb Laurent Pinchart:
> Your documentation patch states that
>
> "The first reg resource is the I/O port register block on which MDIO
> resides. The second reg resource is the I/O port register block on
> which MDC resides. If there is only one reg res
Hi John,
On Thu, 24 Jan 2008, Jon Loeliger wrote:
> You may find it using git here:
>
> git://www.jdl.com/software/dtc
>
> A tarball snap-shot is also available here:
>
> http://www.jdl.com/software/dtc-1.1.0.tgz
>
> Please let me know if there are problems with it!
It looks l
On Friday 07 March 2008 17:21, Scott Wood wrote:
> On Fri, Mar 07, 2008 at 03:20:55PM +0100, Laurent Pinchart wrote:
> > The CPM dual port ram was defined in the device tree as follows (copied
> > from the MPC8272ADS board device tree).
> >
> > [EMAIL PROTECTED] {
> > #addre
On Monday 10 March 2008 08:50, Sergej Stepanov wrote:
> > Acked-by: Scott Wood <[EMAIL PROTECTED]>, if I haven't already.
> >
> > -Scott
>
> I thought, you did it.
> Thank you.
Your documentation patch states that
"The first reg resource is the I/O port register block on which MDIO
resides. The
Segher Boessenkool wrote:
>> diff --git a/drivers/hwmon/adt7473.c b/drivers/hwmon/adt7473.c
>> index 9587869..8ea7da2 100644
>> --- a/drivers/hwmon/adt7473.c
>> +++ b/drivers/hwmon/adt7473.c
>> @@ -570,7 +570,7 @@ static ssize_t set_max_duty_at_crit(struct device
>> *dev,
>> struct i2c_client
diff --git a/drivers/hwmon/adt7473.c b/drivers/hwmon/adt7473.c
index 9587869..8ea7da2 100644
--- a/drivers/hwmon/adt7473.c
+++ b/drivers/hwmon/adt7473.c
@@ -570,7 +570,7 @@ static ssize_t set_max_duty_at_crit(struct device
*dev,
struct i2c_client *client = to_i2c_client(dev);
str
Benjamin Herrenschmidt wrote:
> On Mon, 2008-03-10 at 08:46 +0100, Colin Leroy wrote:
>> On Mon, 10 Mar 2008 01:04:33 +0100, Roel Kluin wrote:
>>
>>> logical-bitwise & confusion
>> Looks good to me, but I'm not really maintaining that anymore :-)
>> I'm not sure who does, Cc:ing Benjamin as he'll p
> Acked-by: Scott Wood <[EMAIL PROTECTED]>, if I haven't already.
>
> -Scott
I thought, you did it.
Thank you.
--
Dipl.-Ing. Sergej Stepanov
Software-Entwicklung
IDS GmbH
E-PA (Entwicklung - Prozess Automatisierung)
Nobelstr. 18,
D-76275 Ettlingen
T. (0) 72 43/2 18-615
F. (0) 72 43/2 18-
43 matches
Mail list logo
