* Re: Adding MTD concat support to FSL ELBC NAND driver
From: Scott Wood @ 2009-08-13 17:37 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <4A841933.8090808@embedded-sol.com>
Felix Radensky wrote:
> Currently concatenation support is implemented in physmap_of driver.
> The syntax used to define a concatenation device involves multiple
> reg tuples, as described in
> Documentation/powerpc/dts-bindings/mtd-physmap.txt. Will same syntax
> be acceptable for NAND chips ?
I'm not too fond of that -- it would require support in each controller
driver, and would preclude providing other device-specific information
in the node (e.g. what if each NAND chip has to sit under a different
parent node to describe its connection to the system?). What if a NAND
controller has multiple reg resources for each chip? It's not
memory-like the way NOR flash is.
If we're going to put it in the device tree at all (I suppose for the
same reason we put partitioning there), it should probably be some
external construct that glues together flash nodes.
-Scott
^ permalink raw reply
* [PATCH] powerpc: derive COMMAND_LINE_SIZE from asm-generic
From: Paul Gortmaker @ 2009-08-13 19:37 UTC (permalink / raw)
To: Linuxppc-dev; +Cc: arnd
The default COMMAND_LINE_SIZE in asm-generic is 512, so the
net effect of this change is nil, aside from the cleanup
factor. See also commit 2b74b8569.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/include/asm/setup.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index 817fac0..dae1934 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -1,6 +1,6 @@
#ifndef _ASM_POWERPC_SETUP_H
#define _ASM_POWERPC_SETUP_H
-#define COMMAND_LINE_SIZE 512
+#include <asm-generic/setup.h>
#endif /* _ASM_POWERPC_SETUP_H */
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] powerpc: derive COMMAND_LINE_SIZE from asm-generic
From: Arnd Bergmann @ 2009-08-13 19:48 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: Linuxppc-dev
In-Reply-To: <1250192224-22772-1-git-send-email-paul.gortmaker@windriver.com>
On Thursday 13 August 2009 19:37:04 Paul Gortmaker wrote:
> The default COMMAND_LINE_SIZE in asm-generic is 512, so the
> net effect of this change is nil, aside from the cleanup
> factor. See also commit 2b74b8569.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Just to clarify why this is good: There is a patch from Remis
to kbuild that can automatically create the trivial wrappers,
so we can remove arch/powerpc/include/asm/setup.h from the
kernel once that patch is applied.
I was also planning to submit a series to clean up more powerpc
in this way headers where applicable, see
http://git.kernel.org/?p=linux/kernel/git/arnd/asm-generic.git;a=shortlog;h=powerpc
The series needs some forward porting to 2.6.31 as well as testing.
If you or someone else wants to help with that, please go ahead!
Thanks,
Arnd <><
^ permalink raw reply
* Re: [PATCH] powerpc: derive COMMAND_LINE_SIZE from asm-generic
From: Paul Gortmaker @ 2009-08-13 20:02 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Linuxppc-dev
In-Reply-To: <200908131948.48103.arnd@arndb.de>
Arnd Bergmann wrote:
> On Thursday 13 August 2009 19:37:04 Paul Gortmaker wrote:
>> The default COMMAND_LINE_SIZE in asm-generic is 512, so the
>> net effect of this change is nil, aside from the cleanup
>> factor. See also commit 2b74b8569.
>>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> Just to clarify why this is good: There is a patch from Remis
> to kbuild that can automatically create the trivial wrappers,
> so we can remove arch/powerpc/include/asm/setup.h from the
> kernel once that patch is applied.
>
> I was also planning to submit a series to clean up more powerpc
> in this way headers where applicable, see
> http://git.kernel.org/?p=linux/kernel/git/arnd/asm-generic.git;a=shortlog;h=powerpc
I'd looked at master and next in your tree; I didn't
list all the branches and so I'd not noticed powerpc in there
as well.
>
> The series needs some forward porting to 2.6.31 as well as testing.
> If you or someone else wants to help with that, please go ahead!
I'll definitely have a look at what is in there.
Paul.
>
> Thanks,
>
> Arnd <><
^ permalink raw reply
* [PATCH] sbc8560: Fix warm reboot with board specific reset function
From: Paul Gortmaker @ 2009-08-13 23:06 UTC (permalink / raw)
To: linuxppc-dev
From: Liang Li <Liang.Li@windriver.com>
The existing fsl_rstcr_restart function fails to reset the sbc8560
board. This implements a board specific reset function that uses
the RCR(Reset Control Register) of the board's EPLD to do a reset.
Signed-off-by: Liang Li <Liang.Li@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/platforms/85xx/sbc8560.c | 39 ++++++++++++++++++++++++++++++++-
1 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/sbc8560.c b/arch/powerpc/platforms/85xx/sbc8560.c
index cc27807..86dcca2 100644
--- a/arch/powerpc/platforms/85xx/sbc8560.c
+++ b/arch/powerpc/platforms/85xx/sbc8560.c
@@ -267,6 +267,43 @@ arch_initcall(sbc8560_rtc_init);
#endif /* M48T59 */
+static __u8 __iomem *brstcr;
+
+static int __init sbc8560_bdrstcr_init(void)
+{
+ struct device_node *np;
+ struct resource res;
+
+ np = of_find_compatible_node(NULL, NULL, "wrs,sbc8560-brstcr");
+ if (np == NULL) {
+ printk(KERN_WARNING "sbc8560: No board specific RSTCR in DTB.\n");
+ return -ENODEV;
+ }
+
+ of_address_to_resource(np, 0, &res);
+
+ printk(KERN_INFO "sbc8560: Found BRSTCR at i/o 0x%x\n", res.start);
+
+ brstcr = ioremap(res.start, res.end - res.start);
+ if(!brstcr)
+ printk(KERN_WARNING "sbc8560: ioremap of brstcr failed.\n");
+
+ of_node_put(np);
+
+ return 0;
+}
+
+arch_initcall(sbc8560_bdrstcr_init);
+
+void sbc8560_rstcr_restart(char * cmd)
+{
+ local_irq_disable();
+ if(brstcr)
+ out_8(brstcr,in_8(brstcr) & 0x7f);
+
+ while(1);
+}
+
define_machine(sbc8560) {
.name = "SBC8560",
.probe = sbc8560_probe,
@@ -274,7 +311,7 @@ define_machine(sbc8560) {
.init_IRQ = sbc8560_pic_init,
.show_cpuinfo = sbc8560_show_cpuinfo,
.get_irq = mpic_get_irq,
- .restart = fsl_rstcr_restart,
+ .restart = sbc8560_rstcr_restart,
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
};
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] sbc8560: Fix warm reboot with board specific reset function
From: Kumar Gala @ 2009-08-14 4:38 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <1250204775-5001-1-git-send-email-paul.gortmaker@windriver.com>
On Aug 13, 2009, at 6:06 PM, Paul Gortmaker wrote:
> From: Liang Li <Liang.Li@windriver.com>
>
> The existing fsl_rstcr_restart function fails to reset the sbc8560
> board. This implements a board specific reset function that uses
> the RCR(Reset Control Register) of the board's EPLD to do a reset.
>
> Signed-off-by: Liang Li <Liang.Li@windriver.com>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
> arch/powerpc/platforms/85xx/sbc8560.c | 39 ++++++++++++++++++++++++
> ++++++++-
> 1 files changed, 38 insertions(+), 1 deletions(-)
The reason it didn't was that feature doesnt exist on the mpc8560 :)
- k
^ permalink raw reply
* Re: [PATCH] sbc8560: Fix warm reboot with board specific reset function
From: Kumar Gala @ 2009-08-14 4:39 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <1250204775-5001-1-git-send-email-paul.gortmaker@windriver.com>
On Aug 13, 2009, at 6:06 PM, Paul Gortmaker wrote:
> From: Liang Li <Liang.Li@windriver.com>
>
> The existing fsl_rstcr_restart function fails to reset the sbc8560
> board. This implements a board specific reset function that uses
> the RCR(Reset Control Register) of the board's EPLD to do a reset.
>
> Signed-off-by: Liang Li <Liang.Li@windriver.com>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
> arch/powerpc/platforms/85xx/sbc8560.c | 39 ++++++++++++++++++++++++
> ++++++++-
> 1 files changed, 38 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/85xx/sbc8560.c b/arch/powerpc/
> platforms/85xx/sbc8560.c
> index cc27807..86dcca2 100644
> --- a/arch/powerpc/platforms/85xx/sbc8560.c
> +++ b/arch/powerpc/platforms/85xx/sbc8560.c
> @@ -267,6 +267,43 @@ arch_initcall(sbc8560_rtc_init);
>
> #endif /* M48T59 */
>
> +static __u8 __iomem *brstcr;
> +
> +static int __init sbc8560_bdrstcr_init(void)
> +{
> + struct device_node *np;
> + struct resource res;
> +
> + np = of_find_compatible_node(NULL, NULL, "wrs,sbc8560-brstcr");
> + if (np == NULL) {
> + printk(KERN_WARNING "sbc8560: No board specific RSTCR in DTB.\n");
> + return -ENODEV;
> + }
> +
> + of_address_to_resource(np, 0, &res);
> +
> + printk(KERN_INFO "sbc8560: Found BRSTCR at i/o 0x%x\n", res.start);
> +
> + brstcr = ioremap(res.start, res.end - res.start);
> + if(!brstcr)
> + printk(KERN_WARNING "sbc8560: ioremap of brstcr failed.\n");
> +
> + of_node_put(np);
> +
> + return 0;
> +}
> +
> +arch_initcall(sbc8560_bdrstcr_init);
> +
> +void sbc8560_rstcr_restart(char * cmd)
> +{
> + local_irq_disable();
> + if(brstcr)
> + out_8(brstcr,in_8(brstcr) & 0x7f);
how about using clrbits8()
> +
> + while(1);
> +}
> +
> define_machine(sbc8560) {
> .name = "SBC8560",
> .probe = sbc8560_probe,
> @@ -274,7 +311,7 @@ define_machine(sbc8560) {
> .init_IRQ = sbc8560_pic_init,
> .show_cpuinfo = sbc8560_show_cpuinfo,
> .get_irq = mpic_get_irq,
> - .restart = fsl_rstcr_restart,
> + .restart = sbc8560_rstcr_restart,
> .calibrate_decr = generic_calibrate_decr,
> .progress = udbg_progress,
> };
> --
> 1.6.3.3
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: PowerPC kernel linux-2.6.29.6 PANIC's at include/linux/cred.h for ipsec enabled kernel
From: srikanth krishnakar @ 2009-08-14 5:08 UTC (permalink / raw)
To: Linuxppc-dev
In-Reply-To: <6213bc560908102335n2b6a2bc1icb2acafe7f4117@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5141 bytes --]
Hi all,
Target : PowerPC440
Kernel : Linux-2.6.29.6
The issue still remains in kernel linux-2.6.29.6 enabling following options
in kernel, the kernel panics and won't boot anymore
The following kernel options enabled :
# Networking support
CONFIG_NET=y
CONFIG_INET=y
CONFIG_NET_KEY=y
CONFIG_XFRM_USER=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_TUNNEL=y
# IPV6
CONFIG_IPV6=y
CONFIG_IPV6_TUNNEL=y
CONFIG_INET6_AH=y
CONFIG_INET6_ESP=y
CONFIG_INET6_IPCOMP=y
CONFIG_INET6_TUNNEL=y
# Cryptographic API
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_DEFLATE=y
and while bootup I am seeing the panic/crash message as :
Looking up port of RPC 100005/1 on 10.50.21.151
VFS: Mounted root (nfs filesystem) on device 0:13.
Freeing unused kernel memory: 184k init
INIT: version 2.86 booting
Starting udevudevd version 124 started
Remounting root file system...
------------[ cut here ]------------
kernel BUG at include/linux/cred.h:206!
Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT LTT NESTING LEVEL : 0
Xilinx PPC440
Modules linked in:
NIP: c00a8414 LR: c0067804 CTR: c00a83ec
REGS: ce977da0 TRAP: 0700 Not tainted (2.6.29.6-ipsec)
MSR: 00029000 <EE,ME,CE> CR: 24028448 XER: 00000005
TASK = cf9a9430[472] 'mount.sh' THREAD: ce976000
GPR00: ffffffff ce977e50 cf9a9430 cf9e00c0 cf3c7ee0 fffeb038 00000003 c04f2224
GPR08: 000000bf 00000001 cf8070e0 c05255e8 44022444 100db7bc 4802e5a4 bf9f09c8
GPR16: c0456670 00000000 c0511188 c05111a8 c0525624 00000001 c0522ca0 ce976034
GPR24: c0511328 ce976034 ce976000 c05255e8 00000003 cf3c7160 c00a83ec cf99aaa0
NIP [c00a8414] file_free_rcu+0x28/0x6c
LR [c0067804] __rcu_process_callbacks+0x1e4/0x400
Call Trace:
[ce977e50] [c00a8444] file_free_rcu+0x58/0x6c (unreliable)
[ce977e60] [c0067804] __rcu_process_callbacks+0x1e4/0x400
[ce977e90] [c0067a4c] rcu_process_callbacks+0x2c/0x4c
[ce977eb0] [c0038cb0] __do_softirq+0xfc/0x1e0
[ce977f00] [c0004124] do_softirq+0x5c/0x60
[ce977f10] [c0038b18] irq_exit+0x98/0xc4
[ce977f20] [c000b2b4] timer_interrupt+0x104/0x1cc
[ce977f40] [c000e7d8] ret_from_except+0x0/0x18
Instruction dump:
4832cfa9 4bffffd8 9421fff0 7c0802a6 93e1000c 7c7f1b78 90010014 8063003c
81230000 3809ffff 7d290378 55290ffe <0f090000> 7c001828 3000ffff 7c00192d
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 180 seconds..
Any suggestions or the filed bug report anywhere ??
-Srikant
On Tue, Aug 11, 2009 at 12:05 PM, srikanth krishnakar <skrishnakar@gmail.com
> wrote:
> Hi All,
>
> Target : PowerPC (ppc440)
>
> While testing kernel linux-2.6.29.6 with IPSEC enabled I observed frequent
> panic messages as shown below while bootup:
>
> VFS: Mounted root (nfs filesystem) on device 0:13.
>
> Freeing unused kernel memory: 184k init
> INIT: version 2.86 booting
> Starting udevudevd version 124 started
>
> Remounting root file system...
> logger: mount: mount point /proc/bus/usb does not exist
> FAT: invalid media value (0x01)
>
> VFS: Can't find a valid FAT filesystem on dev xsa.
> ------------[ cut here ]------------
> kernel BUG at include/linux/cred.h:206!
> Oops: Exception in kernel mode, sig: 5 [#1]
> PREEMPT LTT NESTING LEVEL : 0
>
> Xilinx Virtex440
> Modules linked in: nls_iso8859_1
> NIP: c0031800 LR: c0031864 CTR: c0033e2c
> REGS: c0515d00 TRAP: 0700 Not tainted (2.6.29.6.xilinx-ml507.0908071454-ipsec)
> MSR: 00029000 <EE,ME,CE> CR: 24028028 XER: 00000005
>
> TASK = c04e74c0[0] 'swapper' THREAD: c0514000
> GPR00: ffffffff c0515db0 c04e74c0 cf9e0120 c00539b4 00000002 ffffffff c04f2224
> GPR08: 000002fd 00000001 000002fc c05255e8 44022024 ffffd6c4 dce9ee1f bfefe53f
>
> GPR16: c0456690 00000000 c0511188 c05111a8 c0525624 00000001 c0522ca0 c0514034
> GPR24: c0511328 c0514034 c0514000 c05255e8 0000000a cf3e7920 ce89e050 ce89e050
> NIP [c0031800] __put_task_struct+0x8c/0xf4
> LR [c0031864] __put_task_struct+0xf0/0xf4
>
> Call Trace:
> [c0515db0] [c0031864] __put_task_struct+0xf0/0xf4 (unreliable)
> [c0515dc0] [c0033ecc] delayed_put_task_struct+0xa0/0xbc
> [c0515de0] [c0067804] __rcu_process_callbacks+0x1e4/0x400
> [c0515e10] [c0067a4c] rcu_process_callbacks+0x2c/0x4c
>
> [c0515e30] [c0038cb0] __do_softirq+0xfc/0x1e0
> [c0515e80] [c0004124] do_softirq+0x5c/0x60
> [c0515e90] [c0038b18] irq_exit+0x98/0xc4
> [c0515ea0] [c000b2b4] timer_interrupt+0x104/0x1cc
> [c0515ec0] [c000e7d8] ret_from_except+0x0/0x18
>
> [c0515f80] [c0007294] cpu_idle+0x58/0xf4
> [c0515fa0] [c03db4dc] __got2_end+0x80/0x94
> [c0515fc0] [c04b6734] start_kernel+0x25c/0x2b0
> [c0515ff0] [c0000218] skpinv+0x1a8/0x1e4
> Instruction dump:
> 0f090000 7c001828 3000ffff 7c00192d 40a2fff4 2f800000 419e0078 807f01a4
>
> 81230000 3809ffff 7d290378 55290ffe <0f090000> 7c001828 3000ffff 7c00192d
> Kernel panic - not syncing: Fatal exception in interrupt
> Rebooting in 180 seconds..
>
>
> Attachment: kernel config
>
> your early comments are appreciated !
>
>
>
> Regards
> Srikanth Krishnakar
> **********************
>
--
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
[-- Attachment #2: Type: text/html, Size: 5905 bytes --]
^ permalink raw reply
* Re: [PATCH] Add kmemleak annotations to lmb.c
From: Benjamin Herrenschmidt @ 2009-08-14 7:56 UTC (permalink / raw)
To: Catalin Marinas; +Cc: linuxppc-dev, David S. Miller
In-Reply-To: <1250178041.14019.34.camel@pc1117.cambridge.arm.com>
On Thu, 2009-08-13 at 16:40 +0100, Catalin Marinas wrote:
> On Thu, 2009-08-13 at 13:01 +1000, Michael Ellerman wrote:
> > We don't actually want kmemleak to track the lmb allocations, so we
> > pass min_count as 0. However telling kmemleak about lmb allocations
> > allows it to scan that memory for pointers to other memory that is
> > tracked by kmemleak, ie. slab allocations etc.
>
> Looks alright to me (though I haven't tested it). You can add a
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Actually, Milton pointed to me that we may not want to allow all
LMB chunks to be scanned by kmemleaks, things like the DART hole
that's taken out of the linear mapping for example may need to
be avoided, though I'm not sure what would be the right way to
do it.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] Add kmemleak annotations to lmb.c
From: Catalin Marinas @ 2009-08-14 8:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, David S. Miller
In-Reply-To: <1250236600.24143.34.camel@pasglop>
On Fri, 2009-08-14 at 17:56 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-08-13 at 16:40 +0100, Catalin Marinas wrote:
> > On Thu, 2009-08-13 at 13:01 +1000, Michael Ellerman wrote:
> > > We don't actually want kmemleak to track the lmb allocations, so we
> > > pass min_count as 0. However telling kmemleak about lmb allocations
> > > allows it to scan that memory for pointers to other memory that is
> > > tracked by kmemleak, ie. slab allocations etc.
> >
> > Looks alright to me (though I haven't tested it). You can add a
> > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
>
> Actually, Milton pointed to me that we may not want to allow all
> LMB chunks to be scanned by kmemleaks, things like the DART hole
> that's taken out of the linear mapping for example may need to
> be avoided, though I'm not sure what would be the right way to
> do it.
I suspect there are more blocks to be scanned than those that shouldn't,
so maybe ignore the latter explicitly using kmemleak_ignore(). This was
raised recently on x86_64 as well which has a memory hole for some
aperture - http://lkml.org/lkml/2009/8/13/237.
--
Catalin
^ permalink raw reply
* RE: ARM clock API to PowerPC
From: Benjamin Herrenschmidt @ 2009-08-14 9:29 UTC (permalink / raw)
To: Li Yang-R58472
Cc: devicetree-discuss, John Jacques, linuxppc-dev list, Torez Smith,
Russell King
In-Reply-To: <3A45394FD742FA419B760BB8D398F9ED59DE33@zch01exm26.fsl.freescale.net>
On Thu, 2009-08-13 at 16:59 +0800, Li Yang-R58472 wrote:
> >Now, I know there is at least one person on earth
> >contemplating sharing some drivers between PPC and ARM. I
> >won't tell much more at this stage, but it makes sense in the
> >grand scheme of things to see SoC vendors put similar IO cores
> >into either PPC or ARM and providing that clock API is a good
> >way to also allow these drivers to work since the drivers in
> >questions make use of it.
>
> Freescale USB UDC driver is another example that shared between PowerPC
> and ARM(i.mx). Currently, the imx part of the driver uses clk API, but
> PowerPC part uses static initialization. It will be better if we can
> unify the clk setting part of the driver.
I had a look at it looks like it uses the API in a way that would fit
nicely with my plans, ie, it should be possible to use the same driver
on both archs pretty much without changes provided the ppc platform
provides a clock source driver and hooks it up to the device-tree.
I'll work on some proof-of-concept implementation of the core bits
early next week.
Cheers,
Ben.
^ permalink raw reply
* [SATA] Does SATA work with kernel > v2.6.25.7?
From: Olivier Croset @ 2009-08-14 10:49 UTC (permalink / raw)
To: linuxppc-dev
Hello everybody,
I'm working on a custom board with a Freescale 8347 CPU and a Silicon Image
SIL3512 SATA controller, which is on the PCI bus.
SATA is working with 2.6.22 but no more with 2.6.30.4. I tried different
parameters in the kernel configuration with no success. I got the following
output when Linux boots:
<snip>
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:0:0: [sda] 160086528 512-byte hardware sectors: (81.9 GB/76.3 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
sda:<6>ata2: SATA link down (SStatus 0 SControl 310)
IP-Config: Complete:
device=eth1, addr=192.0.0.238, mask=255.255.255.0, gw=192.0.0.128,
host=xcom9347, domain=, nis-domain=(none),
bootserver=192.0.0.64, rootserver=192.0.0.64, rootpath=
PHY: mdio@e0024520:09 - Link is Up - 100/Half
ata1: lost interrupt (Status 0x50)
sd 0:0:0:0: [sda] Unhandled error code
sd 0:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x06
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
ata1: lost interrupt (Status 0x50)
sd 0:0:0:0: [sda] Unhandled error code
sd 0:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x06
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
unable to read partition table
sd 0:0:0:0: [sda] Attached SCSI disk
<snip>
Then, I can see /dev/sda but not /dev/sda1 (the partition actually exists).
I can get hard drive informations with hdparm -i and -I.
While browsing the web, I found the following message with the same kind of
errors:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-03/msg08159.html
It is said that "the sata is only supported up to 2.6.25.7". Is it true for
all PowerPCs or only for 460EX CPU?
If SATA should work with 2.6.30.4, may I ask you to take a look to my config
file? (http://pastebin.com/f16067607)
Thanks,
Olivier
^ permalink raw reply
* RE: ARM clock API to PowerPC
From: Guennadi Liakhovetski @ 2009-08-14 11:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: devicetree-discuss, John Jacques, linuxppc-dev list, Torez Smith,
Russell King
In-Reply-To: <1250242149.24143.36.camel@pasglop>
On Fri, 14 Aug 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-08-13 at 16:59 +0800, Li Yang-R58472 wrote:
> > >Now, I know there is at least one person on earth
> > >contemplating sharing some drivers between PPC and ARM. I
> > >won't tell much more at this stage, but it makes sense in the
> > >grand scheme of things to see SoC vendors put similar IO cores
> > >into either PPC or ARM and providing that clock API is a good
> > >way to also allow these drivers to work since the drivers in
> > >questions make use of it.
> >
> > Freescale USB UDC driver is another example that shared between PowerPC
> > and ARM(i.mx). Currently, the imx part of the driver uses clk API, but
> > PowerPC part uses static initialization. It will be better if we can
> > unify the clk setting part of the driver.
>
> I had a look at it looks like it uses the API in a way that would fit
> nicely with my plans, ie, it should be possible to use the same driver
> on both archs pretty much without changes provided the ppc platform
> provides a clock source driver and hooks it up to the device-tree.
>
> I'll work on some proof-of-concept implementation of the core bits
> early next week.
You might have a look at these threads:
http://marc.info/?t=124876760500001&r=1&w=2
http://marc.info/?t=124782904600005&r=2&w=2
but since they are quite long, in short, in them a patch has been
discussed, that allowed to re-use an MMC driver, used on some MFDs, on
SuperH SoCs. The patch was taking the "easy route" of adding the
possibility to use the clock API to the tmio_mmc.c driver, while leaving
it to use static clock configurations with MFD drivers. This approach has
been rejected and initially it has been suggested to implement a
platform-independent clock API like what had been proposed by clocklib,
but since the future of clocklib is unclear, it has then been decided to
remove the clock (and power) management from the driver proper and move
them to some callbacks. I.e., there would be more users interested in a
unified clock API, including other platforms and platform-independent
drivers like MFD. Currently the reason, why MFD drivers cannot implement
their own clock devices is that the "struct clk" differs between
platforms.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
From: Pavel Machek @ 2009-08-14 11:30 UTC (permalink / raw)
To: Dipankar Sarma
Cc: Brown, Len, Darrick J. Wong, Peter Zijlstra, Gautham R Shenoy,
linux-kernel@vger.kernel.org, Rafael J. Wysocki,
Pallipadi, Venkatesh, Li, Shaohua, Ingo Molnar,
linuxppc-dev@lists.ozlabs.org, Len Brown
In-Reply-To: <20090813045931.GB14649@in.ibm.com>
> > > 2. A low-power state where the guest indicates it doesn't need the
> > > CPU (and can be put in low power state) but doesn't want to give up
> > > its allocated cpu share. IOW, no visible configuration changes.
> > >
> > > So, in any case we would probably want more than one states.
> >
> > How are #1 and #2 different when the hypervisor
> > gets control in all idle states? I assert that
> > they are the same, and thus 1 state will suffice.
>
> It depends on the hypervisor implementation. On pseries (powerpc)
> hypervisor, for example, they are different. By offlining a vcpu
> (and in turn shutting a cpu), you will actually create a configuration
> change in the VM that is visible to other systems management tools
> which may not be what the system administrator wanted. Ideally,
> we would like to distinguish between these two states.
>
> Hope that suffices as an example.
So... you have something like "physically pulling out hotplug cpu" on
powerpc.
But maybe it is useful to take already offline cpus (from linux side),
and make that visible to hypervisor, too.
So maybe something like "echo 1 > /sys/devices/system/cpu/cpu1/unplug"
would be more useful for hypervisor case?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [SATA] Does SATA work with kernel > v2.6.25.7?
From: Wolfgang Denk @ 2009-08-14 11:33 UTC (permalink / raw)
To: Olivier Croset; +Cc: linuxppc-dev
In-Reply-To: <AA253FF7C15741BCAE4B5D4B4FFF16B6@Labo5>
Dear "Olivier Croset",
In message <AA253FF7C15741BCAE4B5D4B4FFF16B6@Labo5> you wrote:
>
> While browsing the web, I found the following message with the same kind of
> errors:
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-03/msg08159.html
>
> It is said that "the sata is only supported up to 2.6.25.7". Is it true for
> all PowerPCs or only for 460EX CPU?
This messages is explicitly about (and only about) the AMCC 460EX
Canyonlands board and the Synopsys DesignWare Cores (DWC) SATA driver
used on this processor.
This has nothing to do with your poblems with a SIL controller.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
When all is said and done, more is said than done.
^ permalink raw reply
* RE: ARM clock API to PowerPC
From: Benjamin Herrenschmidt @ 2009-08-14 12:07 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: devicetree-discuss, John Jacques, linuxppc-dev list, Torez Smith,
Russell King
In-Reply-To: <Pine.LNX.4.64.0908141255230.5980@axis700.grange>
On Fri, 2009-08-14 at 13:29 +0200, Guennadi Liakhovetski wrote:
> but since they are quite long, in short, in them a patch has been
> discussed, that allowed to re-use an MMC driver, used on some MFDs, on
> SuperH SoCs. The patch was taking the "easy route" of adding the
> possibility to use the clock API to the tmio_mmc.c driver, while leaving
> it to use static clock configurations with MFD drivers. This approach has
> been rejected and initially it has been suggested to implement a
> platform-independent clock API like what had been proposed by clocklib,
> but since the future of clocklib is unclear, it has then been decided to
> remove the clock (and power) management from the driver proper and move
> them to some callbacks. I.e., there would be more users interested in a
> unified clock API, including other platforms and platform-independent
> drivers like MFD. Currently the reason, why MFD drivers cannot implement
> their own clock devices is that the "struct clk" differs between
> platforms.
But there is no reason for it to differ !
My idea is that struct clock would contain function pointers for the
enable/disable/get_rate/ etc... methods
Thus it's up to clk_get() to provide an object with the right pointers.
Now, on ARM, it's currently done in such a way that it's mostly up to
the platform (though that's less true with clkdev).
But with the help of the device-tree, it becomes trivial to have
somebody register clock providers (ie, objects that can product struct
clk *) and bind them to driver.
I think struct clk is the way to go. The problem is to sort out the
binding between the clock provider and the driver. The DT is an easy and
nice way to do it for archs that have it. But there are other ways.
Cheers,
Ben.
^ permalink raw reply
* Configure CPM2 PORTC pin (PC9) for external interrupt?
From: Baojun Wang @ 2009-08-14 14:27 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 922 bytes --]
hi, list:
I need to configure CPM2 PORTC pin (PC9) for external interrupt, when I
read the MPC8555ERM.pdf and cpm2-pic.c, I find that PC9 interrupt number is
56, and I request the IRQ in this way:
hw_irq = 56;
virq = irq_create_mapping(cpm2_host, hw_irq);
reqeust_irq(virq, ...);
I can request the irq successfully, but the interrupt is never generated
(ISR is not called) to the PC9 pins, even though the hardware said an
interrupt was raised. (the hardware have a register with a special bit)
Should I configure the cpm2 io port first to allow PORTC interrupt? I have
read the cpm2 io port documentation, and I initialize the PC9 as:
PPARC[pc9_bit] = 0; /* for general purpose IO, not dedicated */
PSORC[pc9_bit] = 0; /* no special option */
PDIRC[pc9_bit] = 0; /* for both input/output */
Am I missing some thing? Any suggestion will be greatly appreciated.
Best Regards,
- Wang
[-- Attachment #2: Type: text/html, Size: 995 bytes --]
^ permalink raw reply
* [PATCH v2] sbc8560: Fix warm reboot with board specific reset function
From: Paul Gortmaker @ 2009-08-14 14:36 UTC (permalink / raw)
To: Linuxppc-dev
In-Reply-To: <1456507C-E9F9-436B-9901-6F127A5FDD1F@kernel.crashing.org>
From: Liang Li <Liang.Li@windriver.com>
The existing fsl_rstcr_restart function is not applicable to the
mpc8560. The Global Utilities Block on this earlier CPU doesn't have
the control/reset register at 0xe00b0. This implements a board
specific reset function that uses the RCR(Reset Control Register) of
the sbc8560's EPLD to do a reset.
Signed-off-by: Liang Li <Liang.Li@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
v2: update comment, change outb(x, inb(x)&0x7f) --> clrbits(x,0x80)
arch/powerpc/platforms/85xx/sbc8560.c | 39 ++++++++++++++++++++++++++++++++-
1 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/sbc8560.c b/arch/powerpc/platforms/85xx/sbc8560.c
index cc27807..a5ad1c7 100644
--- a/arch/powerpc/platforms/85xx/sbc8560.c
+++ b/arch/powerpc/platforms/85xx/sbc8560.c
@@ -267,6 +267,43 @@ arch_initcall(sbc8560_rtc_init);
#endif /* M48T59 */
+static __u8 __iomem *brstcr;
+
+static int __init sbc8560_bdrstcr_init(void)
+{
+ struct device_node *np;
+ struct resource res;
+
+ np = of_find_compatible_node(NULL, NULL, "wrs,sbc8560-brstcr");
+ if (np == NULL) {
+ printk(KERN_WARNING "sbc8560: No board specific RSTCR in DTB.\n");
+ return -ENODEV;
+ }
+
+ of_address_to_resource(np, 0, &res);
+
+ printk(KERN_INFO "sbc8560: Found BRSTCR at i/o 0x%x\n", res.start);
+
+ brstcr = ioremap(res.start, res.end - res.start);
+ if(!brstcr)
+ printk(KERN_WARNING "sbc8560: ioremap of brstcr failed.\n");
+
+ of_node_put(np);
+
+ return 0;
+}
+
+arch_initcall(sbc8560_bdrstcr_init);
+
+void sbc8560_rstcr_restart(char * cmd)
+{
+ local_irq_disable();
+ if(brstcr)
+ clrbits8(brstcr, 0x80);
+
+ while(1);
+}
+
define_machine(sbc8560) {
.name = "SBC8560",
.probe = sbc8560_probe,
@@ -274,7 +311,7 @@ define_machine(sbc8560) {
.init_IRQ = sbc8560_pic_init,
.show_cpuinfo = sbc8560_show_cpuinfo,
.get_irq = mpic_get_irq,
- .restart = fsl_rstcr_restart,
+ .restart = sbc8560_rstcr_restart,
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
};
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] sbc8560: Fix warm reboot with board specific reset function
From: Paul Gortmaker @ 2009-08-14 14:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <B86B0653-311C-49EA-B27F-F5AB98D49401@kernel.crashing.org>
Kumar Gala wrote:
>
> On Aug 13, 2009, at 6:06 PM, Paul Gortmaker wrote:
>
>> From: Liang Li <Liang.Li@windriver.com>
>>
>> The existing fsl_rstcr_restart function fails to reset the sbc8560
>> board. This implements a board specific reset function that uses
>> the RCR(Reset Control Register) of the board's EPLD to do a reset.
>>
>> Signed-off-by: Liang Li <Liang.Li@windriver.com>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>> ---
>> arch/powerpc/platforms/85xx/sbc8560.c | 39
>> ++++++++++++++++++++++++++++++++-
>> 1 files changed, 38 insertions(+), 1 deletions(-)
>
> The reason it didn't was that feature doesnt exist on the mpc8560 :)
I could see how that might have an impact on the
functionality.... :-)
So, what should the guts block of the 8560 dts look
like? It currently has the standard:
------------
global-utilities@e0000 {
compatible = "fsl,mpc8560-guts";
reg = <0xe0000 0x1000>;
fsl,has-rstcr;
};
------------
MPC8560 has a guts block, but saying "has-rstcr", as
you've pointed out, is a bit of a lie. If we remove that
tag, then we'll trip the:
printk(KERN_INFO "rstcr compatible register does not exist!\n");
which isn't the end of the world, but at the moment it
reads more like an error message, vs. an informative one.
Paul.
>
> - k
^ permalink raw reply
* Re: [PATCH] sbc8560: Fix warm reboot with board specific reset function
From: Kumar Gala @ 2009-08-14 14:53 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <4A857814.5080209@windriver.com>
On Aug 14, 2009, at 9:43 AM, Paul Gortmaker wrote:
> Kumar Gala wrote:
>> On Aug 13, 2009, at 6:06 PM, Paul Gortmaker wrote:
>>> From: Liang Li <Liang.Li@windriver.com>
>>>
>>> The existing fsl_rstcr_restart function fails to reset the sbc8560
>>> board. This implements a board specific reset function that uses
>>> the RCR(Reset Control Register) of the board's EPLD to do a reset.
>>>
>>> Signed-off-by: Liang Li <Liang.Li@windriver.com>
>>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>>> ---
>>> arch/powerpc/platforms/85xx/sbc8560.c | 39 ++++++++++++++++++++++
>>> ++++++++++-
>>> 1 files changed, 38 insertions(+), 1 deletions(-)
>> The reason it didn't was that feature doesnt exist on the mpc8560 :)
>
> I could see how that might have an impact on the
> functionality.... :-)
>
> So, what should the guts block of the 8560 dts look
> like? It currently has the standard:
>
> ------------
> global-utilities@e0000 {
> compatible = "fsl,mpc8560-guts";
> reg = <0xe0000 0x1000>;
> fsl,has-rstcr;
> };
> ------------
>
> MPC8560 has a guts block, but saying "has-rstcr", as
> you've pointed out, is a bit of a lie. If we remove that
> tag, then we'll trip the:
>
> printk(KERN_INFO "rstcr compatible register does not exist!\n");
>
> which isn't the end of the world, but at the moment it
> reads more like an error message, vs. an informative one.
we should probably remove 'fsl,has-rstcr' from the .dts since that's
just wrong. I've got no issue w/either removing the warning or
changing its wording.
- k
^ permalink raw reply
* [PATCH 1/2] powerpc: issue fsl_soc reboot warning only when applicable
From: Paul Gortmaker @ 2009-08-14 16:13 UTC (permalink / raw)
To: Linuxppc-dev
Some CPU, like the MPC8560 don't have a RSTCR in the Global
Utilities Block. These boards will implement their own reboot
call, and not use this code, so we should only warn about the
absence of the GUTS RSTCR when the default reboot code is used.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/sysdev/fsl_soc.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 95dbc64..adca4af 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -37,6 +37,7 @@
#include <asm/irq.h>
#include <asm/time.h>
#include <asm/prom.h>
+#include <asm/machdep.h>
#include <sysdev/fsl_soc.h>
#include <mm/mmu_decl.h>
#include <asm/cpm2.h>
@@ -383,8 +384,9 @@ static int __init setup_rstcr(void)
if (!rstcr)
printk (KERN_EMERG "Error: reset control register "
"not mapped!\n");
- } else
- printk (KERN_INFO "rstcr compatible register does not exist!\n");
+ } else if (ppc_md.restart == fsl_rstcr_restart)
+ printk(KERN_ERR "No RSTCR register, warm reboot won't work\n");
+
if (np)
of_node_put(np);
return 0;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/2] sbc8560: remove "has-rstcr" from global utilities block
From: Paul Gortmaker @ 2009-08-14 16:13 UTC (permalink / raw)
To: Linuxppc-dev
In-Reply-To: <2d219a4998d568c5925727ce61ca440dfb25f5e7.1250266325.git.paul.gortmaker@windriver.com>
The earlier mpc8560 CPUs don't have the RSTCR at 0xe00b0
in the GUTS. The generic reboot code uses this tag to
determine if it should be using the RSTCR for reboot, so
remove it from the board definition.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/boot/dts/sbc8560.dts | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/sbc8560.dts b/arch/powerpc/boot/dts/sbc8560.dts
index 239d57a..9e13ed8 100644
--- a/arch/powerpc/boot/dts/sbc8560.dts
+++ b/arch/powerpc/boot/dts/sbc8560.dts
@@ -303,7 +303,6 @@
global-utilities@e0000 {
compatible = "fsl,mpc8560-guts";
reg = <0xe0000 0x1000>;
- fsl,has-rstcr;
};
};
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 1/3] Support for PCI Express reset type
From: Jesse Barnes @ 2009-08-14 16:54 UTC (permalink / raw)
To: Mike Mason
Cc: linuxppc-dev, Paul Mackerras, Richard Lary, linux-pci,
linasvepstas
In-Reply-To: <4A721FB1.4040903@us.ibm.com>
On Thu, 30 Jul 2009 15:33:21 -0700
Mike Mason <mmlnx@us.ibm.com> wrote:
> This is the first of three patches that implement a bit field that
> PCI Express device drivers can use to indicate they need a
> fundamental reset during error recovery.
>
> By default, the EEH framework on powerpc does what's known as a "hot
> reset" during recovery of a PCI Express device. We've found a case
> where the device needs a "fundamental reset" to recover properly.
> The current PCI error recovery and EEH frameworks do not support this
> distinction.
>
> The attached patch (courtesy of Richard Lary) adds a bit field to
> pci_dev that indicates whether the device requires a fundamental
> reset during recovery.
>
> These patches supersede the previously submitted patch that
> implemented a fundamental reset bit field.
>
> Please review and let me know of any concerns.
>
> Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
> Signed-off-by: Richard Lary <rlary@us.ibm.com>
Ok, applied this series to my linux-next branch, it looks pretty
reasonable to me.
For future patches, please cc me, and include the subsystem in the
subject, along with a specific description of the patch, e.g. "PCI: add
PCIe fundamental reset interface", "PCI: document PCIe fundamental
reset", or for arch specific patches, "PCI/powerpc: implement support
for PCIe fundamental reset".
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* [PATCH] powerpc: Fix __tlb_remove_tlb_entry for PPC_STD_MMU_32
From: Becky Bruce @ 2009-08-14 19:47 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Ben's recent patches are missing the CONFIG_ prefix to
PPC_STD_MMU_32, which results in not properly flushing hash
entries. On 8641, this showed up as a platform that would boot,
but deny logins.
Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
---
arch/powerpc/include/asm/tlb.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/tlb.h b/arch/powerpc/include/asm/tlb.h
index 5db9910..e2b428b 100644
--- a/arch/powerpc/include/asm/tlb.h
+++ b/arch/powerpc/include/asm/tlb.h
@@ -39,7 +39,7 @@ extern void flush_hash_entry(struct mm_struct *mm, pte_t *ptep,
static inline void __tlb_remove_tlb_entry(struct mmu_gather *tlb, pte_t *ptep,
unsigned long address)
{
-#ifdef PPC_STD_MMU_32
+#ifdef CONFIG_PPC_STD_MMU_32
if (pte_val(*ptep) & _PAGE_HASHPTE)
flush_hash_entry(tlb->mm, ptep, address);
#endif
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH] Add kmemleak annotations to lmb.c
From: David Miller @ 2009-08-14 19:49 UTC (permalink / raw)
To: benh; +Cc: catalin.marinas, linuxppc-dev
In-Reply-To: <1250236600.24143.34.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 14 Aug 2009 17:56:40 +1000
> On Thu, 2009-08-13 at 16:40 +0100, Catalin Marinas wrote:
>> On Thu, 2009-08-13 at 13:01 +1000, Michael Ellerman wrote:
>> > We don't actually want kmemleak to track the lmb allocations, so we
>> > pass min_count as 0. However telling kmemleak about lmb allocations
>> > allows it to scan that memory for pointers to other memory that is
>> > tracked by kmemleak, ie. slab allocations etc.
>>
>> Looks alright to me (though I haven't tested it). You can add a
>> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
>
> Actually, Milton pointed to me that we may not want to allow all
> LMB chunks to be scanned by kmemleaks, things like the DART hole
> that's taken out of the linear mapping for example may need to
> be avoided, though I'm not sure what would be the right way to
> do it.
I think that annotating LMB for kmemleak may be more problems
that it's worth.
I can't think of any specific problems like the DART thing on
sparc64, but I'm sure that as soon as someone starts trying
to test this they'll run into one thing or another :-)
^ 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