* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Paul Mackerras @ 2006-10-18 6:11 UTC (permalink / raw)
To: Christoph Lameter; +Cc: akpm, linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0610161630430.8341@schroedinger.engr.sgi.com>
Christoph,
I also am hitting this BUG on a POWER5 partition. The relevant boot
messages are:
Zone PFN ranges:
DMA 0 -> 524288
Normal 524288 -> 524288
early_node_map[3] active PFN ranges
1: 0 -> 32768
0: 32768 -> 278528
1: 278528 -> 524288
[boot]0015 Setup Done
Built 2 zonelists. Total pages: 513760
Kernel command line: root=/dev/sdc3
[snip]
freeing bootmem node 0
freeing bootmem node 1
Memory: 2046852k/2097152k available (5512k kernel code, 65056k reserved, 2204k data, 554k bss, 256k init)
kernel BUG in __cache_alloc_node at /home/paulus/kernel/powerpc/mm/slab.c:3177!
Since this is a virtualized system there is every possibility that the
memory we get won't be divided into nodes in the nice neat manner you
seem to be expecting. It just depends on what memory the hypervisor
has free, and on what nodes, when the partition is booted.
In other words, the assumption that node pfn ranges won't overlap is
completely untenable for us.
Linus' tree is currently broken for us. Any suggestions for how to
fix it, since I am not very familiar with the NUMA code?
Paul.
^ permalink raw reply
* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Nicolas DET @ 2006-10-18 5:51 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: akpm, linuxppc-dev, Sven Luther, tilmann
In-Reply-To: <20061017132243.GA6773@lst.de>
[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]
Christoph Hellwig wrote:
>> --- a/arch/powerpc/kernel/rtas-proc.c 2006-10-14
05:34:03.000000000 +0200
>> +++ b/arch/powerpc/kernel/rtas-proc.c 2006-10-16
10:46:16.000000000 +0200
>> @@ -253,43 +253,70 @@ static void get_location_code(struct seq
>> static void check_location_string(struct seq_file *m, char *c);
>> static void check_location(struct seq_file *m, char *c);
>>
>> +#ifdef CONFIG_PPC64
>> +#define PROCRTAS_ROOT "ppc64"
>> +#else
>> +#define PROCRTAS_ROOT "ppc"
>
> Please don't do any pathname changes. Even if ppc64 isn't correct it's
> what applications expect and what we should provide for a coherent user
> interface.
Humm, ok.
However, in this case 'ppc' (could be 32 or 64 as it is not specified)
is more generic than 'ppc64'.
> This should be the only change you need, and it should follow kernel
> coding style, aka:
>
> if (!machine_is(pseries) && !machine_is(chrp))
> return -ENODEV;
>
>> rtas_node = of_find_node_by_name(NULL, "rtas");
>> if (rtas_node == NULL)
>> return -ENODEV;
>
> And given this check I wonder why we need the platform check at all. It
> should be safe to just remove it.
>
>
Indeed, however I can only test on CHRP. I'll remove the check in the
upcomming patch.
The patch also include a small code to create the /proc/ppc/rtas entry.
Should this be done here, or somewhere in arch/powerpc/chrp/setup.c ?
I will re submit a patch as soon as I can.
[-- Attachment #2: nd.vcf --]
[-- Type: text/x-vcard, Size: 249 bytes --]
begin:vcard
fn:Nicolas DET ( bplan GmbH )
n:DET;Nicolas
org:bplan GmbH
adr:;;;;;;Germany
email;internet:nd@bplan-gmbh.de
title:Software Entwicklung
tel;work:+49 6171 9187 - 31
x-mozilla-html:FALSE
url:http://www.bplan-gmbh.de
version:2.1
end:vcard
^ permalink raw reply
* [PATCH] Move iSeries initrd logic into device tree
From: Michael Ellerman @ 2006-10-18 5:53 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Stephen Rothwell
Remove the iSeries initrd logic, instead just store the initrd location and
size in the device tree so generic code can do the rest for us.
The iSeries code had a "feature" which the generic code lacks, ie. if the
compressed initrd is bigger than the configured ram disk size, we make
the ram disk size bigger. That's bogus, as the compressed size of the initrd
tells us nothing about how big the ram disk needs to be. If the ram disk
isn't big enough you just need to make CONFIG_BLK_DEV_RAM_SIZE larger.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/iseries/dt.c | 15 +++++++++++++--
arch/powerpc/platforms/iseries/setup.c | 32 --------------------------------
2 files changed, 13 insertions(+), 34 deletions(-)
Index: to-merge/arch/powerpc/platforms/iseries/dt.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/iseries/dt.c
+++ to-merge/arch/powerpc/platforms/iseries/dt.c
@@ -41,6 +41,7 @@
#include "call_pci.h"
#include "pci.h"
#include "it_exp_vpd_panel.h"
+#include "naca.h"
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
@@ -205,13 +206,11 @@ static void __init dt_prop_u32(struct is
dt_prop(dt, name, &data, sizeof(u32));
}
-#ifdef notyet
static void __init dt_prop_u64(struct iseries_flat_dt *dt, const char *name,
u64 data)
{
dt_prop(dt, name, &data, sizeof(u64));
}
-#endif
static void __init dt_prop_u64_list(struct iseries_flat_dt *dt,
const char *name, u64 *data, int n)
@@ -306,6 +305,17 @@ static void __init dt_model(struct iseri
dt_prop_u32(dt, "ibm,partition-no", HvLpConfig_getLpIndex());
}
+static void __init dt_initrd(struct iseries_flat_dt *dt)
+{
+#ifdef CONFIG_BLK_DEV_INITRD
+ if (naca.xRamDisk) {
+ dt_prop_u64(dt, "linux,initrd-start", (u64)naca.xRamDisk);
+ dt_prop_u64(dt, "linux,initrd-end",
+ (u64)naca.xRamDisk + naca.xRamDiskSize * HW_PAGE_SIZE);
+ }
+#endif
+}
+
static void __init dt_do_vdevice(struct iseries_flat_dt *dt,
const char *name, u32 reg, int unit,
const char *type, const char *compat, int end)
@@ -641,6 +651,7 @@ void * __init build_flat_dt(unsigned lon
/* /chosen */
dt_start_node(iseries_dt, "chosen");
dt_prop_str(iseries_dt, "bootargs", cmd_line);
+ dt_initrd(iseries_dt);
dt_end_node(iseries_dt);
dt_cpus(iseries_dt);
Index: to-merge/arch/powerpc/platforms/iseries/setup.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/iseries/setup.c
+++ to-merge/arch/powerpc/platforms/iseries/setup.c
@@ -21,7 +21,6 @@
#include <linux/smp.h>
#include <linux/param.h>
#include <linux/string.h>
-#include <linux/initrd.h>
#include <linux/seq_file.h>
#include <linux/kdev_t.h>
#include <linux/major.h>
@@ -80,8 +79,6 @@ extern void iSeries_pci_final_fixup(void
static void iSeries_pci_final_fixup(void) { }
#endif
-extern int rd_size; /* Defined in drivers/block/rd.c */
-
extern unsigned long iSeries_recal_tb;
extern unsigned long iSeries_recal_titan;
@@ -295,24 +292,6 @@ static void __init iSeries_init_early(vo
{
DBG(" -> iSeries_init_early()\n");
-#if defined(CONFIG_BLK_DEV_INITRD)
- /*
- * If the init RAM disk has been configured and there is
- * a non-zero starting address for it, set it up
- */
- if (naca.xRamDisk) {
- initrd_start = (unsigned long)__va(naca.xRamDisk);
- initrd_end = initrd_start + naca.xRamDiskSize * HW_PAGE_SIZE;
- initrd_below_start_ok = 1; // ramdisk in kernel space
- ROOT_DEV = Root_RAM0;
- if (((rd_size * 1024) / HW_PAGE_SIZE) < naca.xRamDiskSize)
- rd_size = (naca.xRamDiskSize * HW_PAGE_SIZE) / 1024;
- } else
-#endif /* CONFIG_BLK_DEV_INITRD */
- {
- /* ROOT_DEV = MKDEV(VIODASD_MAJOR, 1); */
- }
-
iSeries_recal_tb = get_tb();
iSeries_recal_titan = HvCallXm_loadTod();
@@ -331,17 +310,6 @@ static void __init iSeries_init_early(vo
mf_init();
- /* If we were passed an initrd, set the ROOT_DEV properly if the values
- * look sensible. If not, clear initrd reference.
- */
-#ifdef CONFIG_BLK_DEV_INITRD
- if (initrd_start >= KERNELBASE && initrd_end >= KERNELBASE &&
- initrd_end > initrd_start)
- ROOT_DEV = Root_RAM0;
- else
- initrd_start = initrd_end = 0;
-#endif /* CONFIG_BLK_DEV_INITRD */
-
DBG(" <- iSeries_init_early()\n");
}
^ permalink raw reply
* ibmveth and LIOBN field
From: Benjamin Herrenschmidt @ 2006-10-18 5:41 UTC (permalink / raw)
To: Santiago Leon; +Cc: linuxppc-dev list, Paul Mackerras, David Gibson
Hi Santiago !
I'm a bit annoyed by a bit of code in the ibmveth driver:
It accesses the iommu table pointer, to get the index and put it into
it's own private adapter->liobn member. However, that is never used
anywhere except in ibmveth_seq_show() for the /proc stuff to display
this LIOBN value.
Is this actually useful ? I'd like to just remove that code. I'm
changing the DMA operations management globally in the powerpc
architecture and that code now needs fixups. I've done them, but it
annoys me to have this driver dive into data structures like iommu_table
that is should have no business mucking with.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] ramdisk: make powerpc allmodconfig build
From: Randy.Dunlap @ 2006-10-18 4:56 UTC (permalink / raw)
To: michael; +Cc: ppcdev, paulus
In-Reply-To: <1161141055.7906.0.camel@localhost.localdomain>
Michael Ellerman wrote:
> On Tue, 2006-10-17 at 11:04 -0700, Judith Lebzelter wrote:
>> Hi Randy,
>>
>> There is another section in that function which depends on
>> 'CONFIG_BLK_DEV_INITRD' being defined. Although it does not throw an
>> error, it does depend on some of the variables set in this section,
>> but not 'rd_size'. I think for consistancy it might be better to do
>> somthing like this(below)? Or else add the same ifdef down there...
>>
>> Judith
>>
>>
>> Index: 2/linux/arch/powerpc/platforms/iseries/setup.c
>> ===================================================================
>> --- 2.orig/linux/arch/powerpc/platforms/iseries/setup.c 2006-10-17 10:49:31.423551104 -0700
>> +++ 2/linux/arch/powerpc/platforms/iseries/setup.c 2006-10-17 10:52:22.682515784 -0700
>> @@ -305,8 +305,10 @@
>> initrd_end = initrd_start + naca.xRamDiskSize * HW_PAGE_SIZE;
>> initrd_below_start_ok = 1; // ramdisk in kernel space
>> ROOT_DEV = Root_RAM0;
>> +#if defined(CONFIG_BLK_DEV_RAM)
>> if (((rd_size * 1024) / HW_PAGE_SIZE) < naca.xRamDiskSize)
>> rd_size = (naca.xRamDiskSize * HW_PAGE_SIZE) / 1024;
>> +#endif /* CONFIG_BLK_DEV_RAM */
>> } else
>> #endif /* CONFIG_BLK_DEV_INITRD */
>> {
>
> That code is bogus, we'll remove it entirely.
Great, thanks. :)
--
~Randy
^ permalink raw reply
* Re: [PATCH 2/2] viocons: make powerpc allmodconfig build
From: Randy.Dunlap @ 2006-10-18 3:46 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppcdev, paulus
In-Reply-To: <20061018133947.20a2c84f.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> On Tue, 17 Oct 2006 18:24:31 -0700 "Randy.Dunlap" <randy.dunlap@oracle.com> wrote:
>> OK. Makes sense. Will you just build VT in that combo *series
>> config and not build VIOCONS? If so, that would still fix
>> "make allmodconfig" to build cleanly (I think).
>
> Yes, VIOCONS is now obsolete (it is replaced by HVC_ISERIES which doesn't
> clash with VT), but it is used by the distros so I don't want to remove
> it (yet).
OK, I wasn't suggesting removing it, just tweaking the dependencies etc.
Is that doable now or do we wait for the integrated I/P series configs?
--
~Randy
^ permalink raw reply
* Re: [PATCH 2/2] viocons: make powerpc allmodconfig build
From: Stephen Rothwell @ 2006-10-18 3:39 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: ppcdev, paulus
In-Reply-To: <4535824F.1020407@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 522 bytes --]
On Tue, 17 Oct 2006 18:24:31 -0700 "Randy.Dunlap" <randy.dunlap@oracle.com> wrote:
>
> OK. Makes sense. Will you just build VT in that combo *series
> config and not build VIOCONS? If so, that would still fix
> "make allmodconfig" to build cleanly (I think).
Yes, VIOCONS is now obsolete (it is replaced by HVC_ISERIES which doesn't
clash with VT), but it is used by the distros so I don't want to remove
it (yet).
--
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
* [PATCH] Powerpc: Fix the warining message from the return value of function get_property
From: Zang Roy-r61911 @ 2006-10-18 3:18 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
The following patch fixes the warning message from the return value of
function get_property().
Add const constrain for the return value of function get_property()
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
--
diff --git a/arch/powerpc/sysdev/tsi108_dev.c b/arch/powerpc/sysdev/tsi108_dev.c
index 11de090..97f37ef 100644
--- a/arch/powerpc/sysdev/tsi108_dev.c
+++ b/arch/powerpc/sysdev/tsi108_dev.c
@@ -48,7 +48,7 @@ phys_addr_t get_csrbase(void)
tsi = of_find_node_by_type(NULL, "tsi-bridge");
if (tsi) {
unsigned int size;
- void *prop = get_property(tsi, "reg", &size);
+ const void *prop = get_property(tsi, "reg", &size);
tsi108_csr_base = of_translate_address(tsi, prop);
of_node_put(tsi);
};
@@ -79,7 +79,7 @@ static int __init tsi108_eth_of_init(voi
hw_info tsi_eth_data;
unsigned int *id;
unsigned int *phy_id;
- void *mac_addr;
+ const void *mac_addr;
phandle *ph;
memset(r, 0, sizeof(r));
^ permalink raw reply related
* Re: [PATCH 1/2] ramdisk: make powerpc allmodconfig build
From: Michael Ellerman @ 2006-10-18 3:10 UTC (permalink / raw)
To: Judith Lebzelter; +Cc: Randy Dunlap, ppcdev, paulus
In-Reply-To: <20061017180447.GC822@shell0.pdx.osdl.net>
[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]
On Tue, 2006-10-17 at 11:04 -0700, Judith Lebzelter wrote:
> Hi Randy,
>
> There is another section in that function which depends on
> 'CONFIG_BLK_DEV_INITRD' being defined. Although it does not throw an
> error, it does depend on some of the variables set in this section,
> but not 'rd_size'. I think for consistancy it might be better to do
> somthing like this(below)? Or else add the same ifdef down there...
>
> Judith
>
>
> Index: 2/linux/arch/powerpc/platforms/iseries/setup.c
> ===================================================================
> --- 2.orig/linux/arch/powerpc/platforms/iseries/setup.c 2006-10-17 10:49:31.423551104 -0700
> +++ 2/linux/arch/powerpc/platforms/iseries/setup.c 2006-10-17 10:52:22.682515784 -0700
> @@ -305,8 +305,10 @@
> initrd_end = initrd_start + naca.xRamDiskSize * HW_PAGE_SIZE;
> initrd_below_start_ok = 1; // ramdisk in kernel space
> ROOT_DEV = Root_RAM0;
> +#if defined(CONFIG_BLK_DEV_RAM)
> if (((rd_size * 1024) / HW_PAGE_SIZE) < naca.xRamDiskSize)
> rd_size = (naca.xRamDiskSize * HW_PAGE_SIZE) / 1024;
> +#endif /* CONFIG_BLK_DEV_RAM */
> } else
> #endif /* CONFIG_BLK_DEV_INITRD */
> {
That code is bogus, we'll remove it entirely.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] viocons: make powerpc allmodconfig build
From: Randy.Dunlap @ 2006-10-18 1:24 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppcdev, paulus
In-Reply-To: <20061018111935.a143164c.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> On Tue, 17 Oct 2006 09:50:03 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>
>> Make allmodconfig .config build successfully by making VIOCONS
>> available only if VT=n.
>> Using PPC_ISERIES in VT prevents kconfig "recursive" warning.
>
> The problem with this is that we are moving toward being able to build a
> single kernel with PPC_PSERIES and PPC_ISERIES (and others) all defined,
> and this patch will stop Virtual terminal being built in that case.
OK. Makes sense. Will you just build VT in that combo *series
config and not build VIOCONS? If so, that would still fix
"make allmodconfig" to build cleanly (I think).
--
~Randy
^ permalink raw reply
* Re: [PATCH 2/2] viocons: make powerpc allmodconfig build
From: Stephen Rothwell @ 2006-10-18 1:19 UTC (permalink / raw)
To: Randy Dunlap; +Cc: ppcdev, paulus
In-Reply-To: <20061017095003.c447d88a.randy.dunlap@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]
On Tue, 17 Oct 2006 09:50:03 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
>
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Make allmodconfig .config build successfully by making VIOCONS
> available only if VT=n.
> Using PPC_ISERIES in VT prevents kconfig "recursive" warning.
The problem with this is that we are moving toward being able to build a
single kernel with PPC_PSERIES and PPC_ISERIES (and others) all defined,
and this patch will stop Virtual terminal being built in that case.
--
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: RFC: qe lib code location?
From: Dan Malek @ 2006-10-16 19:21 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev list, Li Yang, Kim Phillips
In-Reply-To: <F75246DE-A58C-43EA-875E-CD82A3668188@freescale.com>
On Oct 16, 2006, at 2:46 PM, Andy Fleming wrote:
> My reasoning is that, should Freescale decide to release a non-
> powerpc chip with a QUICC Engine,
Pigs will fly someday, too, but I'm not making plans for that :-)
If you are going to speculate, history shows there will more
likely be yet another version of some communication engine
before there will be a something other than a Power core
with one.
> .... Of course, all of this is pure speculation, so if
> there's a good reason *not* to put it in drivers/, we should probably
> just maintain the status quo.
I thought I provided some reasoning, but I suspect
speculation will prevail.........
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] e1000: Reset all functions after a PCI error
From: Auke Kok @ 2006-10-17 20:56 UTC (permalink / raw)
To: Jeff Garzik; +Cc: akpm, Jesse Brandeburg, linux-kernel, linuxppc-dev, linux-pci
In-Reply-To: <20061017204206.GG6537@austin.ibm.com>
Linas Vepstas wrote:
> Please apply and forward upstream.
ACK
Jeff, please apply on top of today's fixes.
Auke
> --linas
>
> During the handling of the PCI error recovery sequence,
> the current e1000 driver erroneously blocks a device reset
> for any but the first PCI function. It shouldn't -- this
> is a cut-n-paste error from a different driver (which
> tolerated only one hardware reset per hardware card).
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Cc: Auke Kok <auke-jan.h.kok@intel.com>
>
> ----
> drivers/net/e1000/e1000_main.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> Index: linux-2.6.19-rc1-git11/drivers/net/e1000/e1000_main.c
> ===================================================================
> --- linux-2.6.19-rc1-git11.orig/drivers/net/e1000/e1000_main.c 2006-10-17 15:02:25.000000000 -0500
> +++ linux-2.6.19-rc1-git11/drivers/net/e1000/e1000_main.c 2006-10-17 15:03:35.000000000 -0500
> @@ -4914,10 +4914,6 @@ static pci_ers_result_t e1000_io_slot_re
> pci_enable_wake(pdev, PCI_D3hot, 0);
> pci_enable_wake(pdev, PCI_D3cold, 0);
>
> - /* Perform card reset only on one instance of the card */
> - if (PCI_FUNC (pdev->devfn) != 0)
> - return PCI_ERS_RESULT_RECOVERED;
> -
> e1000_reset(adapter);
> E1000_WRITE_REG(&adapter->hw, WUS, ~0);
>
^ permalink raw reply
* [PATCH] e1000: Reset all functions after a PCI error
From: Linas Vepstas @ 2006-10-17 20:42 UTC (permalink / raw)
To: akpm, Jesse Brandeburg, Auke Kok; +Cc: linuxppc-dev, linux-pci, linux-kernel
Please apply and forward upstream.
--linas
During the handling of the PCI error recovery sequence,
the current e1000 driver erroneously blocks a device reset
for any but the first PCI function. It shouldn't -- this
is a cut-n-paste error from a different driver (which
tolerated only one hardware reset per hardware card).
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
Cc: Auke Kok <auke-jan.h.kok@intel.com>
----
drivers/net/e1000/e1000_main.c | 4 ----
1 file changed, 4 deletions(-)
Index: linux-2.6.19-rc1-git11/drivers/net/e1000/e1000_main.c
===================================================================
--- linux-2.6.19-rc1-git11.orig/drivers/net/e1000/e1000_main.c 2006-10-17 15:02:25.000000000 -0500
+++ linux-2.6.19-rc1-git11/drivers/net/e1000/e1000_main.c 2006-10-17 15:03:35.000000000 -0500
@@ -4914,10 +4914,6 @@ static pci_ers_result_t e1000_io_slot_re
pci_enable_wake(pdev, PCI_D3hot, 0);
pci_enable_wake(pdev, PCI_D3cold, 0);
- /* Perform card reset only on one instance of the card */
- if (PCI_FUNC (pdev->devfn) != 0)
- return PCI_ERS_RESULT_RECOVERED;
-
e1000_reset(adapter);
E1000_WRITE_REG(&adapter->hw, WUS, ~0);
^ permalink raw reply
* Re: JFFS2 on Lite5200
From: Wolfgang Denk @ 2006-10-17 20:37 UTC (permalink / raw)
To: Andrea Galbusera; +Cc: linuxppc-embedded
In-Reply-To: <1161081183.22948.58.camel@localhost.localdomain>
In message <1161081183.22948.58.camel@localhost.localdomain> you wrote:
>
> I'm currently using linux-2.6.16 from denx on a Lite5200 V2.0. I need to
> access a JFFS2 filesystem on the onboard flash ( 16MB Am29L652D ).
We do NOT support the MPC5200 in the context of this kernel tree yet.
For the MPC5200, we still recommend to use the linuxppc_2_4_devel
tree.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"The whole problem with the world is that fools and fanatics are
always so certain of themselves, but wiser people so full of doubts."
- Bertrand Russell
^ permalink raw reply
* Re: [PATCH 1/2] ramdisk: make powerpc allmodconfig build
From: Randy.Dunlap @ 2006-10-17 20:37 UTC (permalink / raw)
To: Judith Lebzelter; +Cc: ppcdev, paulus
In-Reply-To: <20061017180447.GC822@shell0.pdx.osdl.net>
Judith Lebzelter wrote:
> Hi Randy,
>
> There is another section in that function which depends on
> 'CONFIG_BLK_DEV_INITRD' being defined. Although it does not throw an
> error, it does depend on some of the variables set in this section,
> but not 'rd_size'. I think for consistancy it might be better to do
> somthing like this(below)? Or else add the same ifdef down there...
>
> Judith
Yes, I agree, this is better. Just drop my patch 1/2.
> Index: 2/linux/arch/powerpc/platforms/iseries/setup.c
> ===================================================================
> --- 2.orig/linux/arch/powerpc/platforms/iseries/setup.c 2006-10-17 10:49:31.423551104 -0700
> +++ 2/linux/arch/powerpc/platforms/iseries/setup.c 2006-10-17 10:52:22.682515784 -0700
> @@ -305,8 +305,10 @@
> initrd_end = initrd_start + naca.xRamDiskSize * HW_PAGE_SIZE;
> initrd_below_start_ok = 1; // ramdisk in kernel space
> ROOT_DEV = Root_RAM0;
> +#if defined(CONFIG_BLK_DEV_RAM)
> if (((rd_size * 1024) / HW_PAGE_SIZE) < naca.xRamDiskSize)
> rd_size = (naca.xRamDiskSize * HW_PAGE_SIZE) / 1024;
> +#endif /* CONFIG_BLK_DEV_RAM */
> } else
> #endif /* CONFIG_BLK_DEV_INITRD */
> {
>
--
~Randy
^ permalink raw reply
* Re: [PATCH 1/2] ramdisk: make powerpc allmodconfig build
From: Randy.Dunlap @ 2006-10-17 20:29 UTC (permalink / raw)
To: Judith Lebzelter; +Cc: ppcdev, paulus
In-Reply-To: <20061017180447.GC822@shell0.pdx.osdl.net>
Judith Lebzelter wrote:
> Hi Randy,
>
> There is another section in that function which depends on
> 'CONFIG_BLK_DEV_INITRD' being defined. Although it does not throw an
> error, it does depend on some of the variables set in this section,
> but not 'rd_size'. I think for consistancy it might be better to do
> somthing like this(below)? Or else add the same ifdef down there...
>
> Judith
I agree. Just this patch, not my previous patch.
> Index: 2/linux/arch/powerpc/platforms/iseries/setup.c
> ===================================================================
> --- 2.orig/linux/arch/powerpc/platforms/iseries/setup.c 2006-10-17 10:49:31.423551104 -0700
> +++ 2/linux/arch/powerpc/platforms/iseries/setup.c 2006-10-17 10:52:22.682515784 -0700
> @@ -305,8 +305,10 @@
> initrd_end = initrd_start + naca.xRamDiskSize * HW_PAGE_SIZE;
> initrd_below_start_ok = 1; // ramdisk in kernel space
> ROOT_DEV = Root_RAM0;
> +#if defined(CONFIG_BLK_DEV_RAM)
> if (((rd_size * 1024) / HW_PAGE_SIZE) < naca.xRamDiskSize)
> rd_size = (naca.xRamDiskSize * HW_PAGE_SIZE) / 1024;
> +#endif /* CONFIG_BLK_DEV_RAM */
> } else
> #endif /* CONFIG_BLK_DEV_INITRD */
> {
>
--
~Randy
^ permalink raw reply
* Re: JFFS2 on Lite5200
From: Andrey Volkov @ 2006-10-17 20:16 UTC (permalink / raw)
To: David Woodhouse; +Cc: dedekind, Andrea Galbusera, linux-mtd, linuxppc-embedded
In-Reply-To: <1161106630.23666.109.camel@hades.cambridge.redhat.com>
David Woodhouse wrote:
> On Tue, 2006-10-17 at 17:54 +0400, Andrey Volkov wrote:
>> No, MPC5200 could write any size chunks, but it must be aligned (same
>> restrictions as in SH4), and this restriction applied only to LPB, but
>> not SDRAM.
>>
>> Also, I've in view that jffs2(jffs3 ?) read/write stuff already used
>> functions which MTD drivers exported, but jffs2_scan_dirent_node and
>> friends - doesn't.
>
> There are two modes of operation for JFFS2 scan. Either it can use the
> MTD device's read() function to read from the flash into memory and scan
> from there, or -- IF the flash can be accessed as if it were normal
> memory -- it can use the point() method and skip the read() call by
> using a pointer directly into the flash.
>
> In your case, the flash cannot be accessed directly as if it were normal
> memory. So your map driver probably shouldn't be allowing point() to
> succeed.
>
> Having said that, I'm not entirely sure we have the code set up so that
> 'simple' map drivers _can_ prevent point(). We may need to fix that.
David, thanks for an explanations (Artem already pointed me to this
jffs2 behavior).
--
Regards
Andrey
^ permalink raw reply
* [PATCH 2/2] viocons: make powerpc allmodconfig build
From: Randy Dunlap @ 2006-10-17 16:50 UTC (permalink / raw)
To: ppcdev; +Cc: paulus
From: Randy Dunlap <randy.dunlap@oracle.com>
Make allmodconfig .config build successfully by making VIOCONS
available only if VT=n.
Using PPC_ISERIES in VT prevents kconfig "recursive" warning.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
arch/powerpc/platforms/iseries/Kconfig | 2 +-
drivers/char/Kconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2619-rc2-ppc.orig/drivers/char/Kconfig
+++ linux-2619-rc2-ppc/drivers/char/Kconfig
@@ -7,7 +7,7 @@ menu "Character devices"
config VT
bool "Virtual terminal" if EMBEDDED
select INPUT
- default y if !VIOCONS
+ default y if !PPC_ISERIES
---help---
If you say Y here, you will get support for terminal devices with
display and keyboard devices. These are called "virtual" because you
--- linux-2619-rc2-ppc.orig/arch/powerpc/platforms/iseries/Kconfig
+++ linux-2619-rc2-ppc/arch/powerpc/platforms/iseries/Kconfig
@@ -3,7 +3,7 @@ menu "iSeries device drivers"
depends on PPC_ISERIES
config VIOCONS
- tristate "iSeries Virtual Console Support (Obsolete)"
+ tristate "iSeries Virtual Console Support (Obsolete)" if !VT
help
This is the old virtual console driver for legacy iSeries.
You should use the iSeries Hypervisor Virtual Console
---
^ permalink raw reply
* [PATCH 1/2] ramdisk: make powerpc allmodconfig build
From: Randy Dunlap @ 2006-10-17 16:47 UTC (permalink / raw)
To: ppcdev; +Cc: paulus
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix build error for allmodconfig on powerpc:
arch/powerpc/platforms/built-in.o:(.toc+0x10b0): undefined reference to `rd_size'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
arch/powerpc/platforms/iseries/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2619-rc2-pv.orig/arch/powerpc/platforms/iseries/setup.c
+++ linux-2619-rc2-pv/arch/powerpc/platforms/iseries/setup.c
@@ -295,7 +295,7 @@ static void __init iSeries_init_early(vo
{
DBG(" -> iSeries_init_early()\n");
-#if defined(CONFIG_BLK_DEV_INITRD)
+#if defined(CONFIG_BLK_DEV_INITRD) && defined(CONFIG_BLK_DEV_RAM)
/*
* If the init RAM disk has been configured and there is
* a non-zero starting address for it, set it up
---
---
~Randy
^ permalink raw reply
* Re: [PATCH 1/2] ramdisk: make powerpc allmodconfig build
From: Judith Lebzelter @ 2006-10-17 18:04 UTC (permalink / raw)
To: Randy Dunlap; +Cc: ppcdev, paulus
In-Reply-To: <20061017094742.a61c4873.randy.dunlap@oracle.com>
Hi Randy,
There is another section in that function which depends on
'CONFIG_BLK_DEV_INITRD' being defined. Although it does not throw an
error, it does depend on some of the variables set in this section,
but not 'rd_size'. I think for consistancy it might be better to do
somthing like this(below)? Or else add the same ifdef down there...
Judith
Index: 2/linux/arch/powerpc/platforms/iseries/setup.c
===================================================================
--- 2.orig/linux/arch/powerpc/platforms/iseries/setup.c 2006-10-17 10:49:31.423551104 -0700
+++ 2/linux/arch/powerpc/platforms/iseries/setup.c 2006-10-17 10:52:22.682515784 -0700
@@ -305,8 +305,10 @@
initrd_end = initrd_start + naca.xRamDiskSize * HW_PAGE_SIZE;
initrd_below_start_ok = 1; // ramdisk in kernel space
ROOT_DEV = Root_RAM0;
+#if defined(CONFIG_BLK_DEV_RAM)
if (((rd_size * 1024) / HW_PAGE_SIZE) < naca.xRamDiskSize)
rd_size = (naca.xRamDiskSize * HW_PAGE_SIZE) / 1024;
+#endif /* CONFIG_BLK_DEV_RAM */
} else
#endif /* CONFIG_BLK_DEV_INITRD */
{
^ permalink raw reply
* How does Linux treat memory above the "mem=" mark?
From: Howard, Marc @ 2006-10-17 18:04 UTC (permalink / raw)
To: Linuxppc-embedded
Hi,
I have a PPC440GX board with 512M of memory. I use "mem=3D496M" boot
argument to keep Linux from using the uppermost 16MB of memory. That
region of memory is instead used for hardware communications.
Occasionally however the CPU will read/write this space as well.
My questions concerns TLB entries. How does Linux define this region in
the TLB? Does it define this region as non-cacheable in the TLB? If
not, what is the correct way to define an area of memory that is outside
the OS's control as non-cacheable?
Thanks,
Marc W. Howard
marc.howard@kla-tencor.com
^ permalink raw reply
* Re: JFFS2 on Lite5200
From: David Woodhouse @ 2006-10-17 17:37 UTC (permalink / raw)
To: Andrey Volkov; +Cc: dedekind, Andrea Galbusera, linux-mtd, linuxppc-embedded
In-Reply-To: <4534E078.9030301@varma-el.com>
On Tue, 2006-10-17 at 17:54 +0400, Andrey Volkov wrote:
> No, MPC5200 could write any size chunks, but it must be aligned (same
> restrictions as in SH4), and this restriction applied only to LPB, but
> not SDRAM.
>
> Also, I've in view that jffs2(jffs3 ?) read/write stuff already used
> functions which MTD drivers exported, but jffs2_scan_dirent_node and
> friends - doesn't.
There are two modes of operation for JFFS2 scan. Either it can use the
MTD device's read() function to read from the flash into memory and scan
from there, or -- IF the flash can be accessed as if it were normal
memory -- it can use the point() method and skip the read() call by
using a pointer directly into the flash.
In your case, the flash cannot be accessed directly as if it were normal
memory. So your map driver probably shouldn't be allowing point() to
succeed.
Having said that, I'm not entirely sure we have the code set up so that
'simple' map drivers _can_ prevent point(). We may need to fix that.
--
dwmw2
^ permalink raw reply
* Re: [Regression] cpu hotplug failed on kernel 2.6.19-rc2
From: Yao Fei Zhu @ 2006-10-17 16:14 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20061017161251.GB18689@localdomain>
Nathan Lynch 写道:
> Yao Fei Zhu wrote:
>
>
>>Running cpu hotplug regression tsstcase lhcs_regression on kernel
>>2.6.19-rc2/IBM System p5 will fall into xmon.
>
>
> Your subject implies this is a regression; what is the most recent
> kernel that worked?
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
2.6.18 works. Not tested on 2.6.19-rc1.
^ permalink raw reply
* Re: [Regression] cpu hotplug failed on kernel 2.6.19-rc2
From: Nathan Lynch @ 2006-10-17 16:12 UTC (permalink / raw)
To: Yao Fei Zhu; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4534D7C6.2080402@cn.ibm.com>
Yao Fei Zhu wrote:
> Running cpu hotplug regression tsstcase lhcs_regression on kernel
> 2.6.19-rc2/IBM System p5 will fall into xmon.
Your subject implies this is a regression; what is the most recent
kernel that worked?
^ 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