[PATCH] powerpc: minimizing the configuration of linkstation_defconfig
This patch addresses the following issues: 01. makes CFQ the default scheduler, to be in line with the rest of the kernel. 02. since linkstations are meant to store files, enable large blk devices. 03. disable CONFIG_MIGRATION in in such low memory devices. 04. disable CONFIG_BLK_DEV_RAM. 05. disable CONFIG_SCSI_LOWLEVEL, as no device under that tree is used. 06. idem for CONFIG_NETDEV_1. 07. idem for CONFIG_WIRELESS. 08. idem for CONFIG_HWMON. 09. idem for CONFIG_CRYPTO_HW. 10. disable CONFIG_VIDEO_OUTPUT_CONTROL. 11. keep consistency and disable extended attributes in CIFS, ext3, and NFS. 12. enable CONFIG_PRINTK_TIME. Signed-off-by: Rogério Brito --- Dear Kumar, please, apply this one. I have another patch regarding one regression regarding MTD & PHYSMAP_COMPAT that I plan to send on top of this one. Thanks. --- a/arch/powerpc/configs/linkstation_defconfig2009-04-22 21:43:45.0 -0300 +++ b/arch/powerpc/configs/linkstation_defconfig2009-04-24 18:07:12.0 -0300 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.29-rc6 -# Fri Mar 6 00:07:38 2009 +# Linux kernel version: 2.6.30-rc3 +# Fri Apr 24 18:07:12 2009 # # CONFIG_PPC64 is not set @@ -14,6 +14,7 @@ CONFIG_6xx=y # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set +CONFIG_PPC_BOOK3S=y CONFIG_PPC_FPU=y # CONFIG_ALTIVEC is not set CONFIG_PPC_STD_MMU=y @@ -54,6 +55,7 @@ CONFIG_GENERIC_BUG=y CONFIG_DEFAULT_UIMAGE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set +CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # @@ -68,6 +70,7 @@ CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y +CONFIG_POSIX_MQUEUE_SYSCTL=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set @@ -100,21 +103,24 @@ CONFIG_NAMESPACES=y # CONFIG_NET_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" +CONFIG_RD_GZIP=y +CONFIG_RD_BZIP2=y +CONFIG_RD_LZMA=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y +CONFIG_ANON_INODES=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set +# CONFIG_STRIP_ASM_SYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y -# CONFIG_COMPAT_BRK is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y -CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y @@ -124,10 +130,12 @@ CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y +# CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set +# CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y @@ -135,6 +143,7 @@ CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y +# CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y @@ -146,8 +155,7 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_BLOCK=y -# CONFIG_LBD is not set -# CONFIG_BLK_DEV_IO_TRACE is not set +CONFIG_LBD=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set @@ -158,18 +166,16 @@ CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y -CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set -# CONFIG_DEFAULT_CFQ is not set +CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set -CONFIG_DEFAULT_IOSCHED="anticipatory" +CONFIG_DEFAULT_IOSCHED="cfq" # CONFIG_FREEZER is not set # # Platform support # -CONFIG_PPC_MULTIPLATFORM=y -CONFIG_CLASSIC32=y # CONFIG_PPC_CHRP is not set # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set @@ -191,6 +197,8 @@ CONFIG_LINKSTATION=y CONFIG_MPC10X_BRIDGE=y CONFIG_MPC10X_OPENPIC=y # CONFIG_MPC10X_STORE_GATHERING is not set +# CONFIG_AMIGAONE is not set +CONFIG_PPC_OF_BOOT_TRAMPOLINE=y # CONFIG_IPIC is not set CONFIG_MPIC=y # CONFIG_MPIC_WEIRD is not set @@ -244,15 +252,18 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 -CONFIG_MIGRATION=y +# CONFIG_MIGRATION is not set # CONFIG_PHYS_ADDR_T_64BIT is not set CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_UNEVICTABLE_LRU=y +CONFIG_HAVE_MLOCK=y +CONFIG_HAVE_MLOCKED_PAGE_BIT=y CONFIG_PPC_4K_PAGES=y # CONFIG_PPC_16K_PAGES is not set # CONFIG_PPC_64K_PAGES is not set +# CONFIG_PPC_256K_PAGES is not set CONFIG_FORCE_MAX_ZONEORDER=11 CONFIG_PROC_DEVICETREE=y # CONFIG_CMDLINE_BOOL is not set @@ -277,6 +288,7 @@ CONFIG_ARCH_SUPPORTS_MSI=y # CONFIG_PCI_LEGACY is not set # CONFIG_PCI_DEBUG is not set # CONFIG_PCI_STUB
Re: Regarding the linkstation defconfig
Dear Guennadi, and Kumar.
On Apr 24 2009, Guennadi Liakhovetski wrote:
> On Fri, 24 Apr 2009, Rogério Brito wrote:
> > Guennadi, since you seem to be the one responsible for the
> > linkstation/kurobox in the kernel,
>
> That's not howI interpret my role in linkstation development /
> support.
Sorry. I thought that you were. I have, nonetheless, interest in helping
and understanding more about the platform.
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > 01. why is anticipatory the default scheduler for linkstations when CFQ
> > is the default scheduler for the rest of the kernel?
(...)
> > 12. wouldn't it be a good thing to enable CONFIG_PRINTK_TIME?
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> As I already replied to you earlier, I am not particularly interested in
> fine-tuning and optimisation of defconfigs. IMHO *_defconfigs are only
> examples of board configuration, that are known to build and work. The
> rest is up to the user / packager.
IMVHO, defconfigs should be examples of board configuration, known to
build and work (like you said) *and* be, in a way, exemplary to the
user/packager.
> > Again, please, forgive my ignorance here regarding the questions above.
> > I'm really looking for some clarification and to get things in shape
> > both on my systems and in the default kernel configuration, in general.
>
> Feel free to submit patches with reasoning to the powerpc ML and
> respective maintainer as per MAINTAINERS file.
I'm doing that as a reply to this message.
Thanks for your guiding, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Regarding the linkstation defconfig
On Fri, 24 Apr 2009, Rogério Brito wrote: > Hi, Guennadi, Kumar & Co. > > Guennadi, since you seem to be the one responsible for the > linkstation/kurobox in the kernel, That's not howI interpret my role in linkstation development / support. > I would like to ask you a few things > that I couldn't quite understand. Please, forgive my ignorance here > while I ask you some things: > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > 01. why is anticipatory the default scheduler for linkstations when CFQ > is the default scheduler for the rest of the kernel? > > 02. since kuroboxes/linkstations are meant to store files, is there any > reason why they don't have support for large blk devs enabled by > default? > > 03. why is CONFIG_MIGRATION enabled in such low memory devices? > > 04. why is CONFIG_BLK_DEV_RAM enabled by default? > > 05. why is SCSI_LOWLEVEL enabled, if no device under that tree is used? > > 06. idem for CONFIG_NETDEV_1. > > 07. idem for CONFIG_WIRELESS. > > 08. idem for CONFIG_HWMON. > > 09. idem for CONFIG_CRYPTO_HW. > > 10. any reason why CONFIG_VIDEO_OUTPUT_CONTROL is configured as a > module? > > 11. any reason why CIFS is not configured with extended attributes, > while both ext3 and nfs are? > > 12. wouldn't it be a good thing to enable CONFIG_PRINTK_TIME? > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - As I already replied to you earlier, I am not particularly interested in fine-tuning and optimisation of defconfigs. IMHO *_defconfigs are only examples of board configuration, that are known to build and work. The rest is up to the user / packager. > Perhaps similar remarks would apply to the other device that you > maintain? I forgot its name. > > Again, please, forgive my ignorance here regarding the questions above. > I'm really looking for some clarification and to get things in shape > both on my systems and in the default kernel configuration, in general. Feel free to submit patches with reasoning to the powerpc ML and respective maintainer as per MAINTAINERS file. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] fsldma: use PCI Read Multiple command
By default, the Freescale 83xx DMA controller uses the PCI Read Line command when reading data over the PCI bus. Setting the controller to use the PCI Read Multiple command instead allows the controller to read much larger bursts of data, which provides a drastic speed increase. The slowdown due to using PCI Read Line was only observed when a PCI-to-PCI bridge was between the devices trying to communicate. A simple test driver showed an increase from 4MB/sec to 116MB/sec when performing DMA over the PCI bus. Using DMA to transfer between blocks of local SDRAM showed no change in performance with this patch. The dmatest driver was also used to verify the correctness of the transfers, and showed no errors. Signed-off-by: Ira W. Snyder --- drivers/dma/fsldma.c |5 +++-- drivers/dma/fsldma.h |1 + 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index da8a8ed..638d00e 100644 --- a/drivers/dma/fsldma.c +++ b/drivers/dma/fsldma.c @@ -49,9 +49,10 @@ static void dma_init(struct fsl_dma_chan *fsl_chan) case FSL_DMA_IP_83XX: /* Set the channel to below modes: * EOTIE - End-of-transfer interrupt enable +* PRC_RM - PCI read multiple */ - DMA_OUT(fsl_chan, &fsl_chan->reg_base->mr, FSL_DMA_MR_EOTIE, - 32); + DMA_OUT(fsl_chan, &fsl_chan->reg_base->mr, FSL_DMA_MR_EOTIE + | FSL_DMA_MR_PRC_RM, 32); break; } diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h index 4f21a51..dc7f268 100644 --- a/drivers/dma/fsldma.h +++ b/drivers/dma/fsldma.h @@ -38,6 +38,7 @@ /* Special MR definition for MPC8349 */ #define FSL_DMA_MR_EOTIE 0x0080 +#define FSL_DMA_MR_PRC_RM 0x0800 #define FSL_DMA_SR_CH 0x0020 #define FSL_DMA_SR_PE 0x0010 -- 1.5.4.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: help with inline assembly code?
Scott Wood wrote: Chris Friesen wrote: Scott Wood wrote: Is the compiler assigning r0 to addr? That will be treated as a literal zero instead. Try changing "r" (addr) to "b" (addr), or use stwx. Bingo! Is there a constraint to tell the compiler to not use r0 for addr? Yes, "b". Doh. Sorry, apparently I can't read today. Both of those fixes seem to work. Much appreciated. Chris ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: help with inline assembly code?
Chris Friesen wrote: Scott Wood wrote: Is the compiler assigning r0 to addr? That will be treated as a literal zero instead. Try changing "r" (addr) to "b" (addr), or use stwx. Bingo! Is there a constraint to tell the compiler to not use r0 for addr? Yes, "b". -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: help with inline assembly code?
Scott Wood wrote:
Chris Friesen wrote:
I've got a function that is used to overwrite opcodes in order to create
self-modifying code. It worked just fine with previous compilers, but
with gcc 4.3 it seems like it sometimes (but not always) causes problems
when inlined. If I force it to never be inlined, it works fine.
First, here's the code:
void alter_opcode(unsigned long *addr, unsigned long opcode)
{
asm volatile(
"stw%1,0(%0)\n\t"
"dcbf 0,%0\n\t"
"sync\n\t"
"icbi 0,%0,\n\t"
"isync\n\t"
:: "r" (addr), "r" (opcode): "memory");
}
The symptom of the problem is a segfault on the "stw" instruction. I've
verified that the address it's trying to write to is the expected
address,
Verified by looking at the address in "addr", or by looking at the
reported faulting address?
Verified by running it in userspace under gdb, then looking at the
registers listed in the disassembly and comparing it to the process maps.
and that the opcode being written is the expected opcode.
I assume I've mixed up the registers or constraints or
something...anyone want to take a crack at it?
Is the compiler assigning r0 to addr? That will be treated as a literal
zero instead. Try changing "r" (addr) to "b" (addr), or use stwx.
Bingo! Is there a constraint to tell the compiler to not use r0 for addr?
Chris
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: help with inline assembly code?
Chris Friesen wrote:
I've got a function that is used to overwrite opcodes in order to create
self-modifying code. It worked just fine with previous compilers, but
with gcc 4.3 it seems like it sometimes (but not always) causes problems
when inlined. If I force it to never be inlined, it works fine.
First, here's the code:
void alter_opcode(unsigned long *addr, unsigned long opcode)
{
asm volatile(
"stw%1,0(%0)\n\t"
"dcbf 0,%0\n\t"
"sync\n\t"
"icbi 0,%0,\n\t"
"isync\n\t"
:: "r" (addr), "r" (opcode): "memory");
}
The symptom of the problem is a segfault on the "stw" instruction. I've
verified that the address it's trying to write to is the expected
address,
Verified by looking at the address in "addr", or by looking at the
reported faulting address?
and that the opcode being written is the expected opcode.
I assume I've mixed up the registers or constraints or
something...anyone want to take a crack at it?
Is the compiler assigning r0 to addr? That will be treated as a literal
zero instead. Try changing "r" (addr) to "b" (addr), or use stwx.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
help with inline assembly code?
Hi,
I've got a function that is used to overwrite opcodes in order to create
self-modifying code. It worked just fine with previous compilers, but
with gcc 4.3 it seems like it sometimes (but not always) causes problems
when inlined. If I force it to never be inlined, it works fine.
First, here's the code:
void alter_opcode(unsigned long *addr, unsigned long opcode)
{
asm volatile(
"stw%1,0(%0) \n\t"
"dcbf 0,%0 \n\t"
"sync \n\t"
"icbi 0,%0, \n\t"
"isync \n\t"
:: "r" (addr), "r" (opcode): "memory");
}
The symptom of the problem is a segfault on the "stw" instruction. I've
verified that the address it's trying to write to is the expected
address, and that the opcode being written is the expected opcode.
I assume I've mixed up the registers or constraints or
something...anyone want to take a crack at it?
Chris
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Enable Serial Management Controller (SMC) in MPC8265
On Thu, Apr 23, 2009 at 07:50:25PM -0400, Andres F Marquez wrote:
> I am working with a MPC8265 processor for which I am compiling a
> Kernel using LTIB.
Please contact Freescale support for issues with BSPs. Around here
you'll be told to upgrade to the latest upstream kernel. :-)
> I enabled SCC1 (for the console) and SMC2 through the Kernel
> (2.6.25) configuration tool using LTIB. I am able to run my system and
> execute minicom to try to configure the needed serial port. I have not
> been able to find the tty port that refers to either one of the two SMC
> ports.
All CPM serial ports (whether SCC or SMC) will be /dev/ttyCPMn.
> I have tried all the tty's that I get when I do ls /dev/tty* but
> none of them seem to work. Below, I provide the list of tty's that I am
> getting. ttyCPM0 is being used for the console. ttyCPM1 is the only one
> that I am allowed to configure through minicom (for the rest it says
> device not found).
Not allowed? Don't you have root access to your board?
> After doing some research online, I added an entry in my
> mpc8272ads.dts file for the smc serial controller. Below, I provide the
> entries for the serial ports (one SCC1 and one SMC2):
>
> ser...@11a00 {
> device_type = "serial";
> compatible = "fsl,mpc8280-scc-uart",
> "fsl,cpm2-scc-uart";
> reg = <11a00 20 8000 100>;
> interrupts = <28 8>;
> interrupt-parent = <&PIC>;
> fsl,cpm-brg = <2>;
> fsl,cpm-command = <0080>;
> };
>
> ser...@11a92 {
> device_type = "serial";
> compatible = "fsl,mpc8280-smc-uart",
> "fsl,cpm2-smc-uart";
> reg = <11a92 20 88fc 2>;
> interrupts = <5 8>;
> interrupt-parent = <&PIC>;
> fsl,cpm-brg = <2>;
> fsl,cpm-command = <2120>;
> };
Do you really have both ports on the same BRG?
Change 11a92 to 11a90 -- it's the address of the register block, not the
first register within the block.
You should also change 8280 to 8265, though nothing currently cares.
Finally, I think 2.6.25 is too old to support automatic allocation of SMC
parameter RAM. Unless they've backported something in the BSP, you'll
have to manually allocate some space, remove that chunk from the muram
node, program SMC2_BASE yourself, and put the address of the actual
parameter RAM in the device tree. Or, upgrade to the latest upstream
kernel, or complain to Freescale sales and/or support that the BSP kernel
is too old for your desired use.
> For some reason in uboot, it seems like the configurations for SCC1 and
> SMC2 are exclusive. They depend on where the console is configured
> (SCC1 or SMC2). Either one can be configured, but not both at the same
> time (at least based on uboot configuration definitions. They are
> within if's and elif's...). As I said before, both of them are able to
> run the console.
I don't see any obvious pin conflict between SCC1 and SMC2. It's
probably just a u-boot limitation -- but make sure that the pins get set
up for SMC2 even if u-boot doesn't use it.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.30-rc3: BUG triggered on some hugepage usages
On Fri, 2009-04-24 at 10:51 +0100, Mel Gorman wrote:
> On Tue, Apr 21, 2009 at 08:27:57PM -0700, Linus Torvalds wrote:
> > Another week, another -rc.
> >
>
> I'm seeing some tests with sysbench+postgres+large pages fail on ppc64
> although a very clear pattern is not forming as to what exactly is
> causing it. However, the libhugetlbfs regression tests (make && make
> func) are triggering the following oops when calling mlock() and so are
> likely related.
>
> [ cut here ]
> kernel BUG at arch/powerpc/mm/pgtable.c:243!
> Oops: Exception in kernel mode, sig: 5 [#1]
> SMP NR_CPUS=128 NUMA pSeries
> Modules linked in: dm_snapshot dm_mirror dm_region_hash dm_log qla2xxx
> loop nfnetlink iptable_filter iptable_nat nf_nat ip_tables
> nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT
> xt_tcpudp xt_limit ipt_LOG xt_pkttype x_tables
> NIP: c002becc LR: c002c02c CTR:
> REGS: c000ea92b4c0 TRAP: 0700 Not tainted (2.6.30-rc3-autokern1)
> MSR: 80029032 CR: 28000484 XER: 2020
> TASK = c395b660[7611] 'mlock' THREAD: c000ea928000 CPU: 3
> GPR00: 0001 c000ea92b740 c08ea170 c000ec7d4980
> GPR04: 3f00 c001e2278cf8 00190393 0001
> GPR08: f2bc 0113 c001e2278c81
> GPR12: 44000482 c093b880 28004422
> GPR16: c000ea92bbf0 c09f06f0 00190113 c000ec7d4980
> GPR20: f2bc 3f00 c001e2278cf8
> GPR24: c000eaa90bb0 c000eaa90bb0 c000ea928000
> GPR28: f2bc 00190393 0001 c001e2278cf8
> NIP [c002becc] .assert_pte_locked+0x54/0x8c
> LR [c002c02c] .ptep_set_access_flags+0x50/0x8c
> Call Trace:
> [c000ea92b740] [c000eaa90bb0] 0xc000eaa90bb0 (unreliable)
> [c000ea92b7d0] [c00ed1b0] .hugetlb_cow+0xd4/0x654
> [c000ea92b900] [c00edbf0] .hugetlb_fault+0x4c0/0x708
> [c000ea92b9f0] [c00ee890] .follow_hugetlb_page+0x174/0x364
> [c000ea92bae0] [c00d8d30] .__get_user_pages+0x288/0x4c0
> [c000ea92bbb0] [c00da10c] .make_pages_present+0xa0/0xe0
> [c000ea92bc40] [c00db758] .mlock_fixup+0x90/0x228
> [c000ea92bd00] [c00dbb38] .do_mlock+0xc4/0x128
> [c000ea92bda0] [c00dbccc] .SyS_mlock+0xb0/0xec
> [c000ea92be30] [c000852c] syscall_exit+0x0/0x40
> Instruction dump:
> 0b00 78892662 79291f24 7d69582a 7d600074 7800d182 0b00 78895e62
> 79291f24 7d29582a 7d200074 7800d182 <0b00> 3c004000 3960
> 780007c6
> ---[ end trace 36a7faa04fa9452b ]---
>
> This corresponds to
>
> #ifdef CONFIG_DEBUG_VM
> void assert_pte_locked(struct mm_struct *mm, unsigned long addr)
> {
> pgd_t *pgd;
> pud_t *pud;
> pmd_t *pmd;
>
> if (mm == &init_mm)
> return;
> pgd = mm->pgd + pgd_index(addr);
> BUG_ON(pgd_none(*pgd));
> pud = pud_offset(pgd, addr);
> BUG_ON(pud_none(*pud));
> pmd = pmd_offset(pud, addr);
> BUG_ON(!pmd_present(*pmd)); <- THIS LINE
> BUG_ON(!spin_is_locked(pte_lockptr(mm, pmd)));
> }
> #endif /* CONFIG_DEBUG_VM */
>
> This area was last changed by commit 8d30c14cab30d405a05f2aaceda1e9ad57800f36
> in the 2.6.30-rc1 timeframe. I think there was another hugepage-related
> problem with this patch but I can't remember what it was.
It broke modules, but I don't remember anything hugepage related.
So the code changed from:
-#define ptep_set_access_flags(__vma, __address, __ptep, __entry, __dirty) \
-({\
- int __changed = !pte_same(*(__ptep), __entry); \
- if (__changed) { \
- __ptep_set_access_flags(__ptep, __entry, __dirty); \
- flush_tlb_page_nohash(__vma, __address); \
- } \
- __changed; \
-})
to:
+int ptep_set_access_flags(struct vm_area_struct *vma, unsigned long address,
+ pte_t *ptep, pte_t entry, int dirty)
+{
+ int changed;
+ if (!dirty && pte_need_exec_flush(entry, 0))
+ entry = do_dcache_icache_coherency(entry);
+ changed = !pte_same(*(ptep), entry);
+ if (changed) {
+ assert_pte_locked(vma->vm_mm, address);
+ __ptep_set_access_flags(ptep, entry);
+ flush_tlb_page_nohash(vma, address);
+ }
+ return changed;
+}
So the call to assert_pte_locked() is new. And it's never going to work
for huge pages, the page table structure is different right? Notic
where to simplify code using is_power_of_2() function
just an observation that you can aesthetically simplify some ppc
code using the boolean is_power_of_2() routine from
include/linux/log2.h if you were so inclined:
arch/powerpc/sysdev/ppc4xx_pci.c:171: if ((size & (size - 1)) != 0 ||
arch/powerpc/mm/ppc_mmu_32.c:216: if (n_hpteg & (n_hpteg - 1)) {
arch/powerpc/boot/cuboot-pq2.c:176: if (mem->size[1] & (mem->size[1] - 1))
arch/powerpc/boot/cuboot-pq2.c:178: if (io->size[1] & (io->size[1] - 1))
arch/powerpc/lib/rheap.c:258: if ((alignment & (alignment - 1)) != 0)
arch/powerpc/lib/rheap.c:307: if ((alignment & (alignment - 1)) != 0)
arch/powerpc/lib/rheap.c:450: if (size <= 0 || (alignment & (alignment - 1))
!= 0)
rday
--
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Linked In: http://www.linkedin.com/in/rpjday
Twitter: http://twitter.com/rpjday
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8349E's DMA controller like ISA controller but with more feature?
lhthanh wrote: > Thanks for your explaination! So if I want to transfer a buffer of data > from a single I/O port, will not DMA framework > also be able ? No. > Have I to write aother driver? Yes. > Actually, I don't want write all because there are serveral DMA code at > hand. I only want to use a framework instead of re-writing. There is no framework for what you want to do. There is only one other driver that does what you want (sound/soc/fsl/fsl_dma.c), and that is a complicated driver that does many things besides transferring data to an I/O port. > And I afraid that I can not write code which assure sharing DMA channels. Look at arch/powerpc/boot/dts/mpc8610_hpcd.dts. The DMA channels that are needed by the 8610 audio driver have a different 'compatible' property. This is how you prevent the generic DMA driver from using a channel that you want. I'm afraid that you're going to have to study the DMA programming model, and my device driver, and write a brand new driver from scratch. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: removing get_immrbase()??
> > We've run into plenty of situations where customers will update the > > kernel, but insist that U-Boot and the device tree remain unchanged. > > when? I'm not aware of any significant # of cases that > customer is willing to update kernel & not dts. Usually if > they are willing to update kernel they tend to be willing to > update everything. I recently fried a U-Boot flash on a machine at home when upgrading and the machine sits there and is dead of course. Luckily that machine doesn't have to be up 24x7, so I can wait until I have time to fix the situation ... and I can either pull the socketed flash or hook up a JTAG debugger. But Freescale or other eval(!) boards or isolated Power Architecture based home use machines like my fried one should not be a reference for this kind of discussion. I see a very common scenario with Telecom/Networking customers. They have a boot flash with firmware and basic startup/BIST SW which they do not really ever want to touch at all even if they should after it shipped. If a remote upgrade on just a few out of installed systems fails, they can send technicians to Mars to pull the board(s), and service guarantees, and profit, are out the window then. That makes U-Boot and/or subsequent ultra-low-level startup/BIST SW from the same boot source *very* firm. If a device-tree is served from there for whichever reason, then you have a *very* firm device-tree, too. Then these customers either have a second flash with a filesystem or more volatile images in the sense that they see that other flash as upgradable (if they have to), or a physical link to some remote fs that serves them the kernel and application load. They still do not like upgrades too much as any upgrade can have service impact. But they do them when necessary because they know they have a way to revert to previous or fixed releases remotely as they can always depend on the original boot loader to be there. It would not be smart to prohibit any change ever, but we also shouldn't cause device-tree changes a lot just because we felt like it today. Both seems a bit extreme. There must be some middle ground, err'ing towards the conservative side. A change affecting "lower" levels than the kernel should be very well thought through, and if it is necessary, we should strive to keep compatibility to a level that makes sense and possibly eases a transition over some time. If a few clearly marked code lines (with a possibly marked planned max lifetime) ease compatibility and transition, they should be considered. Hope this helps Heinz ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Next April 24 : BUG: lock held at task exit time!
Hi Al, On Fri, 24 Apr 2009 15:04:45 +0100 Al Viro wrote: > > Applied, will fold on reorder (since Ingo is asking for what will amount > to reorder anyway). Thanks. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpUACwsb23z8.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [MTD] ofpart: Partitions at same address cannot have the same name v3
Sometimes, an special partition is included in the device tree including all the
partitions. Like in:
partit...@ff00 {
reg = < 0x00 0x80 >;
label = "Root File System";
};
partit...@ff80 {
reg = < 0x80 0x1a >;
label = "Bitstream";
};
...
f...@ff00 {
compatible = "partition";
reg = < 0x00 0x100 >;
label = "Full FLASH";
};
Because two nodes of a device tree cannot have the same name, but all the
partitions must be named "partition", this special partition is invalid.
This patch makes ofpart.c accept spetial partitions compatible with
"partition" but not named partition.
These spetial partitions are very useful for flashing the full firmware
of a device from linux
---
This v3 includes feedback from Scott Wood, Peter Korsgaard & Benjamin Kril
v3: Use the compatible propierty
v2: buggy implementation, strlen-1 instead of strlen
v1: Just check the firt part of the name
drivers/mtd/ofpart.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index 3e164f0..59c1e4a 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -48,7 +48,9 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
/* check if this is a partition node */
partname = of_get_property(pp, "name", &len);
- if (strcmp(partname, "partition") != 0) {
+ if ((strcmp(partname, "partition") != 0) &&
+ (of_device_is_compatible(pp, "partition") != 1))
+ {
nr_parts--;
continue;
}
--
1.6.2.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Next April 24 : BUG: lock held at task exit time!
On Fri, Apr 24, 2009 at 12:55:44PM +0100, Hugh Dickins wrote: > Indeed, thanks for the headsup Stephen. My own config gives, not > Sachin's message (or not still visibly on screen anyway), but an > outright panic. Shame that leaked out into the big world, we'd > all have preferred a quiet fixup! Here's a patch, which I'll > also send as reply to the relevant thread. Applied, will fold on reorder (since Ingo is asking for what will amount to reorder anyway). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull 'merge' branch of the 4xx tree
Hi Paul, Please pull the following two commits for 2.6.30. One is a trivial MAINTAINERS fix, the other fixes a bug that computes the memory size of some 4xx boards incorrectly. The following changes since commit 6329db8bd60fbc0832f30c350b0181b8d865573e: Bartlomiej Zolnierkiewicz (1): powerpc: Fix modular build of ide-pmac when mediabay is built in are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git merge Josh Boyer (1): maintainers: Fix PowerPC 4xx git tree Valentine Barshak (1): powerpc/44x: Correct memory size calculation for denali-based boards MAINTAINERS |2 +- arch/powerpc/boot/4xx.c | 56 --- 2 files changed, 44 insertions(+), 14 deletions(-) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c: i2c-ibm_iic message can be confusing
On Fri, Apr 17, 2009 at 08:36:00PM -0400, Sean MacLennan wrote: >Any update on the status of this patch? This patch was acked by Jean. > >The patchwork entry is http://patchwork.ozlabs.org/patch/21576/ and the >original patch message is below. Yeah, that's a bit annoying. A case of too many trees again. Ben, Do you want to take this through your tree or should I take it through the powerpc tree? I'll be up-front and say silence will translate to 'powerpc tree' josh > >Cheers, > Sean > >On Mon, 2 Feb 2009 12:01:59 -0500 >Sean MacLennan wrote: > >> This is a trivial patch that does not need to be in 2.6.29. While >> tracking down an EEPROM problem, I found the messages confusing... it >> looked like the EEPROM was being started before the I2C driver! >> >> Here is an example: >> >> at24 0-0052: 512 byte 24c04 EEPROM (writable) >> ibm-iic ef600700.i2c: using standard (100 kHz) mode >> ad7414 0-004a: chip found >> >> It looks like the at24 starts first, then the i2c driver, then the >> ad7414. By moving the message to after the of scan, we always get the >> driver, then the devices. >> >> Cheers, >>Sean >> >> Print the i2c driver message before scanning for devices so that the >> logs show the driver, then the devices. Currently you can get >> device(s), driver, device(s). >> >> Signed-off-by: Sean MacLennan >> --- >> diff --git a/drivers/i2c/busses/i2c-ibm_iic.c >> b/drivers/i2c/busses/i2c-ibm_iic.c index 88f0db7..7fc0729 100644 >> --- a/drivers/i2c/busses/i2c-ibm_iic.c >> +++ b/drivers/i2c/busses/i2c-ibm_iic.c >> @@ -756,12 +756,12 @@ static int __devinit iic_probe(struct of_device >> *ofdev, goto error_cleanup; >> } >> >> -/* Now register all the child nodes */ >> -of_register_i2c_devices(adap, np); >> - >> dev_info(&ofdev->dev, "using %s mode\n", >> dev->fast_mode ? "fast (400 kHz)" : "standard (100 >> kHz)"); >> +/* Now register all the child nodes */ >> +of_register_i2c_devices(adap, np); >> + >> return 0; >> >> error_cleanup: >> >___ >Linuxppc-dev mailing list >Linuxppc-dev@ozlabs.org >https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Next April 24 : BUG: lock held at task exit time!
On Fri, 24 Apr 2009, Stephen Rothwell wrote:
> On Fri, 24 Apr 2009 12:25:41 +0530 Sachin Sant wrote:
> >
> > While booting today's next tree on a powerpc box [ power 6 blade]
> > observed the following :
> >
> > khelper used greatest stack depth: 10176 bytes left
> >
> > =
> > [ BUG: lock held at task exit time! ]
> > -
> > khelper/21 is exiting with locks still held!
> > 2 locks held by khelper/21:
> > #0: (rcu_read_lock){.+.+.+}, at: []
> > .check_unsafe_exec+0x44/0x148
> > #1: (rcu_read_lock){.+.+.+}, at: []
> > .check_unsafe_exec+0xb0/0x148
> >
> > stack backtrace:
> > Call Trace:
> > [c00044483cf0] [c0011a54] .show_stack+0x6c/0x16c (unreliable)
> > [c00044483da0] [c009ae14] .debug_check_no_locks_held+0x98/0xb4
> > [c00044483e20] [c0073b1c] .do_exit+0x758/0x7b0
> > [c00044483f00] [c00853d8] .call_usermodehelper+0x170/0x174
> > [c00044483f90] [c002bd8c] .kernel_thread+0x54/0x70
> > net_namespace: 2000 bytes
> >
> > Complete dmesg attached. Let me know if you need any other info. I will
> > try yesterday's next
> > tree to check if this problem can be recreated.
>
> Almost certainly commit 874a9e18f25c86dbc199ad32ddd9ca44d25290e8
> ("check_unsafe_exec: s/lock_task_sighand/rcu_read_lock/") which has a
> typo (two locks instead of lock/unlock) as pointed out by Hugh Dickins
> ( on LKML).
Indeed, thanks for the headsup Stephen. My own config gives, not
Sachin's message (or not still visibly on screen anyway), but an
outright panic. Shame that leaked out into the big world, we'd
all have preferred a quiet fixup! Here's a patch, which I'll
also send as reply to the relevant thread.
[PATCH] check_unsafe_exec: rcu_read_unlock
Fix typo in previous commit: second rcu_read_lock should be rcu_read_unlock.
Signed-off-by: Hugh Dickins
---
fs/exec.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 2.6.30-rc3-next-20090424/fs/exec.c 2009-04-24 12:23:43.0 +0100
+++ linux/fs/exec.c 2009-04-24 12:26:10.0 +0100
@@ -1043,7 +1043,7 @@ int check_unsafe_exec(struct linux_binpr
if (t->fs == p->fs)
n_fs++;
}
- rcu_read_lock();
+ rcu_read_unlock();
if (p->fs->users > n_fs) {
bprm->unsafe |= LSM_UNSAFE_SHARE;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [V5] Xilinx : Framebuffer Driver: Add PLB support and cleanup DCR
On Friday 17 April 2009, John Linn wrote: > Added support for the new xps tft controller. The new core > has PLB interface support in addition to existing DCR interface. > > Removed platform device support as both MicroBlaze and PowerPC > use device tree. I just said in another email thread that we would need a CONFIG_DCR option that DCR using drivers should depend on, if it ever happened outside of powerpc. Well, apparently this happened earlier than I expected. Converting the driver to use the generic DCR interface makes it possible to use in any system that provides this interface, including those that use a hard CPU core with xilinx_fb on an FPGA, so it makes sense to just change the dependency in Kconfig and provide CONFIG_DCR in microblaze (unconditionally) as well as in powerpc instead of the existing CONFIG_PPC_DCR. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze
On Tuesday 21 April 2009, John Williams wrote: > Some (most?) of the Xilinx drivers currently have this construct: > > #ifdef CONFIG_OF > > // probe using OF > > #else If there are multiple ways of detecting the device, then the driver should be compilable on any system that allows either one. At the very least, it should be restricted to CONFIG_HAS_IOMEM, which is probably required for any of these, but not provided on stuff like UML or s390. Drivers that use of_* functions unconditionally need to depend on CONFIG_OF. Also, some of the xilinx drivers apparantly use DCR, which in turn is only defined when you have CONFIG_PPC_DCR, and these have so far only been used on powerpc. If other architectures start using DCR (I hope that never happens), we will need a global CONFIG_DCR option. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[BUG] 2.6.30-rc3: BUG triggered on some hugepage usages
On Tue, Apr 21, 2009 at 08:27:57PM -0700, Linus Torvalds wrote:
> Another week, another -rc.
>
I'm seeing some tests with sysbench+postgres+large pages fail on ppc64
although a very clear pattern is not forming as to what exactly is
causing it. However, the libhugetlbfs regression tests (make && make
func) are triggering the following oops when calling mlock() and so are
likely related.
[ cut here ]
kernel BUG at arch/powerpc/mm/pgtable.c:243!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=128 NUMA pSeries
Modules linked in: dm_snapshot dm_mirror dm_region_hash dm_log qla2xxx
loop nfnetlink iptable_filter iptable_nat nf_nat ip_tables
nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT
xt_tcpudp xt_limit ipt_LOG xt_pkttype x_tables
NIP: c002becc LR: c002c02c CTR:
REGS: c000ea92b4c0 TRAP: 0700 Not tainted (2.6.30-rc3-autokern1)
MSR: 80029032 CR: 28000484 XER: 2020
TASK = c395b660[7611] 'mlock' THREAD: c000ea928000 CPU: 3
GPR00: 0001 c000ea92b740 c08ea170 c000ec7d4980
GPR04: 3f00 c001e2278cf8 00190393 0001
GPR08: f2bc 0113 c001e2278c81
GPR12: 44000482 c093b880 28004422
GPR16: c000ea92bbf0 c09f06f0 00190113 c000ec7d4980
GPR20: f2bc 3f00 c001e2278cf8
GPR24: c000eaa90bb0 c000eaa90bb0 c000ea928000
GPR28: f2bc 00190393 0001 c001e2278cf8
NIP [c002becc] .assert_pte_locked+0x54/0x8c
LR [c002c02c] .ptep_set_access_flags+0x50/0x8c
Call Trace:
[c000ea92b740] [c000eaa90bb0] 0xc000eaa90bb0 (unreliable)
[c000ea92b7d0] [c00ed1b0] .hugetlb_cow+0xd4/0x654
[c000ea92b900] [c00edbf0] .hugetlb_fault+0x4c0/0x708
[c000ea92b9f0] [c00ee890] .follow_hugetlb_page+0x174/0x364
[c000ea92bae0] [c00d8d30] .__get_user_pages+0x288/0x4c0
[c000ea92bbb0] [c00da10c] .make_pages_present+0xa0/0xe0
[c000ea92bc40] [c00db758] .mlock_fixup+0x90/0x228
[c000ea92bd00] [c00dbb38] .do_mlock+0xc4/0x128
[c000ea92bda0] [c00dbccc] .SyS_mlock+0xb0/0xec
[c000ea92be30] [c000852c] syscall_exit+0x0/0x40
Instruction dump:
0b00 78892662 79291f24 7d69582a 7d600074 7800d182 0b00 78895e62
79291f24 7d29582a 7d200074 7800d182 <0b00> 3c004000 3960
780007c6
---[ end trace 36a7faa04fa9452b ]---
This corresponds to
#ifdef CONFIG_DEBUG_VM
void assert_pte_locked(struct mm_struct *mm, unsigned long addr)
{
pgd_t *pgd;
pud_t *pud;
pmd_t *pmd;
if (mm == &init_mm)
return;
pgd = mm->pgd + pgd_index(addr);
BUG_ON(pgd_none(*pgd));
pud = pud_offset(pgd, addr);
BUG_ON(pud_none(*pud));
pmd = pmd_offset(pud, addr);
BUG_ON(!pmd_present(*pmd)); <- THIS LINE
BUG_ON(!spin_is_locked(pte_lockptr(mm, pmd)));
}
#endif /* CONFIG_DEBUG_VM */
This area was last changed by commit 8d30c14cab30d405a05f2aaceda1e9ad57800f36
in the 2.6.30-rc1 timeframe. I think there was another hugepage-related
problem with this patch but I can't remember what it was. Full dmesg is
dmesg
Using pSeries machine description
Page orders: linear mapping = 24, virtual = 12, io = 12, vmemmap = 24
Found initrd at 0xc330:0xc4b67000
console [udbg0] enabled
Partition configured for 8 cpus.
CPU maps initialized for 2 threads per core
(thread shift is 1)
Starting Linux PPC64 #1 SMP Fri Apr 24 09:08:10 UTC 2009
-
ppc64_pft_size= 0x1b
physicalMemorySize= 0x1e800
htab_hash_mask= 0xf
-
Initializing cgroup subsys cpuset
Linux version 2.6.30-rc3-autokern1 (r...@elm3a121) (gcc version 4.1.2 20061115
(prerelease) (Debian 4.1.1-21)) #1 SMP Fri Apr 24 09:08:10 UTC 2009
[boot]0012 Setup Arch
Node 0 Memory: 0x0-0xee00
Node 1 Memory: 0xee00-0x1e800
PCI host bridge /p...@8002001 ranges:
IO 0x03fe0010..0x03fe001f -> 0x
MEM 0x04008000..0x0400bfff -> 0xc000
PCI host bridge /p...@8002002 ranges:
IO 0x03fe0060..0x03fe006f -> 0x
MEM 0x0401..0x04017fff -> 0x8000
PCI host bridge /p...@8002003 ranges:
IO 0x03fe0030..0x03fe003f -> 0x
MEM 0x0400c000..0x0400 -> 0xc000
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 7168 bytes
Using dedicated idle loop
Zone PFN ranges:
DMA 0x -> 0x001e8000
Normal 0x001e8000 -> 0x001e8000
M
Re: Next April 24 : BUG: lock held at task exit time!
Hi Sachin,
On Fri, 24 Apr 2009 12:25:41 +0530 Sachin Sant wrote:
>
> While booting today's next tree on a powerpc box [ power 6 blade]
> observed the following :
>
> khelper used greatest stack depth: 10176 bytes left
>
> =
> [ BUG: lock held at task exit time! ]
> -
> khelper/21 is exiting with locks still held!
> 2 locks held by khelper/21:
> #0: (rcu_read_lock){.+.+.+}, at: []
> .check_unsafe_exec+0x44/0x148
> #1: (rcu_read_lock){.+.+.+}, at: []
> .check_unsafe_exec+0xb0/0x148
>
> stack backtrace:
> Call Trace:
> [c00044483cf0] [c0011a54] .show_stack+0x6c/0x16c (unreliable)
> [c00044483da0] [c009ae14] .debug_check_no_locks_held+0x98/0xb4
> [c00044483e20] [c0073b1c] .do_exit+0x758/0x7b0
> [c00044483f00] [c00853d8] .call_usermodehelper+0x170/0x174
> [c00044483f90] [c002bd8c] .kernel_thread+0x54/0x70
> net_namespace: 2000 bytes
>
> Complete dmesg attached. Let me know if you need any other info. I will
> try yesterday's next
> tree to check if this problem can be recreated.
Almost certainly commit 874a9e18f25c86dbc199ad32ddd9ca44d25290e8
("check_unsafe_exec: s/lock_task_sighand/rcu_read_lock/") which has a
typo (two locks instead of lock/unlock) as pointed out by Hugh Dickins
( on LKML).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
pgp3bAUz1wXp2.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
General SPI question
Hi, Thanks a lot and sorry for the mistakes. I have gone through the trm of the adc as well as the omap driver. my question is that i want to interact the adc to the board. now should i directly use the omap driver or should i mak one of my own. if i make one of my own then i would like to know how would the spi registers be changed by driver. should it include the omap2 driver or is the fuctionality provided directly when i include spi.h. another doubt: when and why is the spidev.c/h used? i am deeply grateful towards you for helping me out thanks Arnav On Fri, Apr 24, 2009 at 11:50 AM, David Brownell wrote: > On Thursday 23 April 2009, Arnav Das wrote: > > i am a newbie > > Lesson #1: make sure your Subject: lines match the message > topic (I did a partial repair) and don't post to the wrong > list (e.g. PPC lists for OMAP questions). > > > > and am doing a project on beagle board(running > > omap3530). i am interfacing an adc(ads7886) to the beagleboard via > > spi. need to know how the spi works > > Read the ads7886 data sheet, in this case. It uses > a subset of SPI ... no input commands, just a 12-bit > sample returned each time chipselect pulses. > > > > and how a module can access the > > spi registers of the omap. if someones already made an adc driver can > > they mail me? > > Use drivers/spi/omap2_mcspi.c on OMAP3 boards, at > least to start with. If you want streaming conversions > you may want to use different modes than are currently > supported by that driver. > > - Dave > > > > > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Regarding the linkstation defconfig
Hi, Guennadi, Kumar & Co.
Guennadi, since you seem to be the one responsible for the
linkstation/kurobox in the kernel, I would like to ask you a few things
that I couldn't quite understand. Please, forgive my ignorance here
while I ask you some things:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
01. why is anticipatory the default scheduler for linkstations when CFQ
is the default scheduler for the rest of the kernel?
02. since kuroboxes/linkstations are meant to store files, is there any
reason why they don't have support for large blk devs enabled by
default?
03. why is CONFIG_MIGRATION enabled in such low memory devices?
04. why is CONFIG_BLK_DEV_RAM enabled by default?
05. why is SCSI_LOWLEVEL enabled, if no device under that tree is used?
06. idem for CONFIG_NETDEV_1.
07. idem for CONFIG_WIRELESS.
08. idem for CONFIG_HWMON.
09. idem for CONFIG_CRYPTO_HW.
10. any reason why CONFIG_VIDEO_OUTPUT_CONTROL is configured as a
module?
11. any reason why CIFS is not configured with extended attributes,
while both ext3 and nfs are?
12. wouldn't it be a good thing to enable CONFIG_PRINTK_TIME?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Perhaps similar remarks would apply to the other device that you
maintain? I forgot its name.
Again, please, forgive my ignorance here regarding the questions above.
I'm really looking for some clarification and to get things in shape
both on my systems and in the default kernel configuration, in general.
Thank you very much for your contributions, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
