* Re: Next June 29: Boot failure with SLQB on s390
From: Nick Piggin @ 2009-06-29 10:39 UTC (permalink / raw)
To: Heiko Carstens
Cc: Sachin Sant, Pekka Enberg, Stephen Rothwell, linux-next,
linux-s390
In-Reply-To: <20090629103123.GC9321@osiris.boeblingen.de.ibm.com>
On Mon, Jun 29, 2009 at 12:31:23PM +0200, Heiko Carstens wrote:
> On Mon, Jun 29, 2009 at 03:14:40PM +0530, Sachin Sant wrote:
> > I still have problems booting next with SLQB on a s390 box.
> >
> > Write protected kernel read-only data: 0x12000 - 0x446fff
> > Experimental hierarchical RCU implementation.
> > Experimental hierarchical RCU init done.
> > console ÝttyS0¨ enabled
> > Unable to handle kernel pointer dereference at virtual kernel address (null)
This could I suppose be due to failed allocation where the caller
isn't expecting failure (or using SLAB_PANIC).
Did you manage to test with the prink debugging patch for SLQB that
I sent for the power6 boot failure? I don't think I saw a reply from
you but maybe I missed it?
Thanks,
Nick
^ permalink raw reply
* Re: Next June 29: Boot failure with SLQB on s390
From: Heiko Carstens @ 2009-06-29 10:31 UTC (permalink / raw)
To: Sachin Sant, Nick Piggin
Cc: Pekka Enberg, Stephen Rothwell, linux-next, linux-s390
In-Reply-To: <4A488D08.30307@in.ibm.com>
On Mon, Jun 29, 2009 at 03:14:40PM +0530, Sachin Sant wrote:
> I still have problems booting next with SLQB on a s390 box.
>
> Write protected kernel read-only data: 0x12000 - 0x446fff
> Experimental hierarchical RCU implementation.
> Experimental hierarchical RCU init done.
> console ÝttyS0¨ enabled
> Unable to handle kernel pointer dereference at virtual kernel address (null)
> Oops: 0004 #1¨ SMP
> Modules linked in:
> CPU: 0 Not tainted 2.6.31-rc1-autotest-next-20090629 #1
> Process swapper (pid: 0, task: 0000000000447700, ksp: 0000000000498000)
> Krnl PSW : 0700200180000000 00000000002be00c (init_section_page_cgroup+0x8c/0x10
> c)
> R:0 T:1 IO:1 EX:1 Key:0 M:0 W:0 P:0 AS:0 CC:2 PM:0 EA:3
> Krnl GPRS: 0000000000000000 0000000000000028 0000000000000010 0000000000000010
> 000003e040000000 0000000000010000 0000000000498a28 0000000000000000
> 00000000004cc000 00000000004bb408 00000000004cc010 0000000080808000
> 0000000000280000 00000000002d1cf0 00000000004aa69e 0000000000497ed0
> Krnl Code: 00000000002be000: a7c90000 lghi %r12,0
> 00000000002be004: a7f40031 brc 15,2be066
> 00000000002be008: 41102018 la %r1,24(%r2)
> >00000000002be00c: e34020100024 stg %r4,16(%r2)
> 00000000002be012: a7a90000 lghi %r10,0
> 00000000002be01c: e3a020000024 stg %r10,0(%r2)
> 00000000002be022: a74b0038 aghi %r4,56
> Call Trace:
> (<00000000004b0bbe>¨ console_init+0x36/0x50)
> <000000000049897a>¨ start_kernel+0x312/0x3c0
> <0000000000012020>¨ _ehead+0x20/0x80
> Last Breaking-Event-Address:
> <00000000002be07c>¨ init_section_page_cgroup+0xfc/0x10c
>
> --- end trace 31fd0ba7d8756001 ¨---
> Kernel panic - not syncing: Attempted to kill the idle task!
> CPU: 0 Tainted: G D 2.6.31-rc1-autotest-next-20090629 #1
> Process swapper (pid: 0, task: 0000000000447700, ksp: 0000000000498000)
> 0000000000000005 0000000000497b20 0000000000000002 0000000000000000
> 0000000000497bc0 0000000000497b38 0000000000497b38 0000000000049fc2
> 00000000002c7cf0 0000000000000000 0000000000000000 000000000000000b
> 0000000000000008 0000000000000000 0000000000497b20 0000000000497b98
> 00000000002c7c78 00000000000163aa 0000000000497b20 0000000000497b70
> Call Trace:
> (<000000000001630c>¨ show_trace+0xdc/0xec)
> <0000000000048eb0>¨ panic+0x84/0x1c0
> <000000000004ce70>¨ do_exit+0x74/0x6f0
> <0000000000016862>¨ die+0x152/0x154
> <000000000001298c>¨ do_no_context+0xa0/0xac
> <00000000000131aa>¨ do_protection_exception+0x252/0x260
> <0000000000025f7c>¨ sysc_return+0x0/0x8
> <00000000002be00c>¨ init_section_page_cgroup+0x8c/0x10c
> (<00000000004b0bbe>¨ console_init+0x36/0x50)
> <000000000049897a>¨ start_kernel+0x312/0x3c0
> <0000000000012020>¨ _ehead+0x20/0x80
> 01: HCPGIR450W CP entered; disabled wait PSW 00020001 80000000 00000000 00020E3E
>
> With SLUB machine boots fine. Should i be testing this(SLQB/s390)
> combination ?
No, just stay with SLUB/SLAB for the time being.
Maybe the backtrace looks familiar to Nick?
^ permalink raw reply
* Next June 29: Boot failure with SLQB on s390
From: Sachin Sant @ 2009-06-29 9:44 UTC (permalink / raw)
To: Pekka Enberg; +Cc: Stephen Rothwell, linux-next, linux-s390
In-Reply-To: <20090629164851.57263dbc.sfr@canb.auug.org.au>
I still have problems booting next with SLQB on a s390 box.
Write protected kernel read-only data: 0x12000 - 0x446fff
Experimental hierarchical RCU implementation.
Experimental hierarchical RCU init done.
console ÝttyS0¨ enabled
Unable to handle kernel pointer dereference at virtual kernel address (null)
Oops: 0004 #1¨ SMP
Modules linked in:
CPU: 0 Not tainted 2.6.31-rc1-autotest-next-20090629 #1
Process swapper (pid: 0, task: 0000000000447700, ksp: 0000000000498000)
Krnl PSW : 0700200180000000 00000000002be00c (init_section_page_cgroup+0x8c/0x10
c)
R:0 T:1 IO:1 EX:1 Key:0 M:0 W:0 P:0 AS:0 CC:2 PM:0 EA:3
Krnl GPRS: 0000000000000000 0000000000000028 0000000000000010 0000000000000010
000003e040000000 0000000000010000 0000000000498a28 0000000000000000
00000000004cc000 00000000004bb408 00000000004cc010 0000000080808000
0000000000280000 00000000002d1cf0 00000000004aa69e 0000000000497ed0
Krnl Code: 00000000002be000: a7c90000 lghi %r12,0
00000000002be004: a7f40031 brc 15,2be066
00000000002be008: 41102018 la %r1,24(%r2)
>00000000002be00c: e34020100024 stg %r4,16(%r2)
00000000002be012: a7a90000 lghi %r10,0
00000000002be01c: e3a020000024 stg %r10,0(%r2)
00000000002be022: a74b0038 aghi %r4,56
Call Trace:
(<00000000004b0bbe>¨ console_init+0x36/0x50)
<000000000049897a>¨ start_kernel+0x312/0x3c0
<0000000000012020>¨ _ehead+0x20/0x80
Last Breaking-Event-Address:
<00000000002be07c>¨ init_section_page_cgroup+0xfc/0x10c
--- end trace 31fd0ba7d8756001 ¨---
Kernel panic - not syncing: Attempted to kill the idle task!
CPU: 0 Tainted: G D 2.6.31-rc1-autotest-next-20090629 #1
Process swapper (pid: 0, task: 0000000000447700, ksp: 0000000000498000)
0000000000000005 0000000000497b20 0000000000000002 0000000000000000
0000000000497bc0 0000000000497b38 0000000000497b38 0000000000049fc2
00000000002c7cf0 0000000000000000 0000000000000000 000000000000000b
0000000000000008 0000000000000000 0000000000497b20 0000000000497b98
00000000002c7c78 00000000000163aa 0000000000497b20 0000000000497b70
Call Trace:
(<000000000001630c>¨ show_trace+0xdc/0xec)
<0000000000048eb0>¨ panic+0x84/0x1c0
<000000000004ce70>¨ do_exit+0x74/0x6f0
<0000000000016862>¨ die+0x152/0x154
<000000000001298c>¨ do_no_context+0xa0/0xac
<00000000000131aa>¨ do_protection_exception+0x252/0x260
<0000000000025f7c>¨ sysc_return+0x0/0x8
<00000000002be00c>¨ init_section_page_cgroup+0x8c/0x10c
(<00000000004b0bbe>¨ console_init+0x36/0x50)
<000000000049897a>¨ start_kernel+0x312/0x3c0
<0000000000012020>¨ _ehead+0x20/0x80
01: HCPGIR450W CP entered; disabled wait PSW 00020001 80000000 00000000 00020E3E
With SLUB machine boots fine. Should i be testing this(SLQB/s390)
combination ?
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: linux-next: Tree for June 19
From: Stephen Rothwell @ 2009-06-29 7:30 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Len Brown, linux-next, LKML, sfi-devel, x86
In-Reply-To: <20090629071451.GA20225@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 302 bytes --]
Hi Ingo,
On Mon, 29 Jun 2009 09:14:51 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
>
> Yep, feel free, the SFI bits looked good in principle.
OK, thanks, I will add the tree tomorrow.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for June 19
From: Ingo Molnar @ 2009-06-29 7:14 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Len Brown, linux-next, LKML, sfi-devel, x86
In-Reply-To: <20090622015427.c749a0d9.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > Basically, this should be just what you would send to Linus
> > > (or ask him to fetch). It is allowed to be rebased if you
> > > deem it necessary.
> >
> > The patches are tested on the pre-release platform that makes
> > use of them. There have been several internal reviews and
> > re-writes, but since we just got permission to release the
> > patches last week, they've not been publically vetted yet.
> >
> > The content is quite close to what I plan to propose for
> > upstream, but the format is not. I'll be re-factoring the
> > series into "clean history" and senting them to LKML on Sunday
> > night.
> >
> > I don't expect much comment on the generic part, but will want
> > x86 maintainers to buy into the parts that touch their
> > architecture.
>
> OK, then I think I need to hear from the x86 maintainers, at
> least, before we include this.
Yep, feel free, the SFI bits looked good in principle.
Ingo
^ permalink raw reply
* linux-next: Tree for June 29
From: Stephen Rothwell @ 2009-06-29 6:48 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 6805 bytes --]
Hi all,
Changes since 20090626:
New tree: percpu
My fixes tree contains this commit:
fbdev: work around old compiler bug
This tree fails to build for powerpc allyesconfig.
The hid tree lost its build failure.
The rr tree gained a conflict against Linus' tree.
The block tree lost its build failure.
The percpu tree gained a conflict against Linus' tree.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES) and i386, sparc and sparc64 defconfig.
These builds also have CONFIG_ENABLE_WARN_DEPRECATED,
CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
We are up to 131 trees (counting Linus' and 19 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging dwmw2/master
Merging arm/devel
Merging davinci/for-next
Merging pxa/for-next
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
CONFLICT (add/add): Merge conflict in arch/mips/cavium-octeon/executive/cvmx-helper-errata.c
CONFLICT (content): Merge conflict in arch/mips/mm/tlbex.c
CONFLICT (content): Merge conflict in arch/mips/sibyte/swarm/setup.c
CONFLICT (content): Merge conflict in drivers/char/hw_random/Kconfig
CONFLICT (content): Merge conflict in drivers/char/hw_random/Makefile
CONFLICT (add/add): Merge conflict in drivers/dma/txx9dmac.c
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging xtensa/master
Merging cifs/master
Merging configfs/linux-next
CONFLICT (content): Merge conflict in fs/configfs/dir.c
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging jfs/next
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging squashfs/master
Merging v9fs/for-next
CONFLICT (content): Merge conflict in net/9p/protocol.c
Merging ubifs/linux-next
Merging xfs/master
Merging reiserfs-bkl/reiserfs/kill-bkl-rc6
CONFLICT (content): Merge conflict in fs/reiserfs/super.c
Merging vfs/for-next
Merging pci/linux-next
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging quota/for_next
Merging kbuild/master
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
CONFLICT (content): Merge conflict in arch/x86/kvm/x86.c
CONFLICT (content): Merge conflict in virt/kvm/kvm_main.c
Merging dlm/next
Merging scsi/master
Merging async_tx/next
Merging udf/for_next
Merging net/master
Merging wireless/master
Merging mtd/master
Merging crypto/master
Merging sound/for-next
Merging cpufreq/next
Merging quilt/rr
CONFLICT (content): Merge conflict in arch/powerpc/platforms/powermac/setup.c
CONFLICT (content): Merge conflict in kernel/cpu.c
Applying: rr/pmac: fix for cpumask accessor changes
Applying: UML: Fix some apparent bitrot in mmu_context.h
Merging mmc/next
Merging input/next
Merging bkl-removal/bkl-removal
Merging lsm/for-next
Merging block/for-next
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging quilt/ttydev
Merging agp/agp-next
Merging uwb/for-upstream
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging omap/for-next
Merging quilt/aoe
Merging suspend/linux-next
Merging bluetooth/master
Merging edac-amd/for-next
Merging fsnotify/for-next
Merging irda/for-next
Merging hwlat/for-linus
Merging tip/auto-latest
CONFLICT (content): Merge conflict in arch/x86/include/asm/termios.h
Merging percpu/for-next
CONFLICT (content): Merge conflict in arch/mn10300/kernel/vmlinux.lds.S
Merging asm-generic/next
Merging quilt/driver-core
Merging quilt/usb
Merging quilt/staging
Merging scsi-post-merge/master
Applying: kvm/powerpc: fix build error
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: manual merge of the percpu tree with Linus' tree
From: Stephen Rothwell @ 2009-06-29 5:33 UTC (permalink / raw)
To: Tejun Heo, Rusty Russell, Christoph Lameter, Ingo Molnar
Cc: linux-next, linux-kernel, David Howells
Hi all,
Today's linux-next merge of the percpu tree got a conflict in
arch/mn10300/kernel/vmlinux.lds.S between commit
2e8b5a09ebf1f98f02c1988a48415e89d4c25168 ("MN10300: Fix the vmlinux
ldscript") from Linus' tree and commit
405d967dc70002991f8fc35c20e0d3cbc7614f63 ("linker script: throw
away .discard section") from the percpu tree.
Just context changes. I fixed it up (see below) and can carry the fix
for a while.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/mn10300/kernel/vmlinux.lds.S
index c96ba3d,5d9f2f9..0000000
--- a/arch/mn10300/kernel/vmlinux.lds.S
+++ b/arch/mn10300/kernel/vmlinux.lds.S
@@@ -117,7 -145,8 +117,8 @@@ SECTION
/* Sections to be discarded */
/DISCARD/ : {
- *(.exitcall.exit)
+ EXIT_CALL
+ *(.discard)
}
STABS_DEBUG
^ permalink raw reply
* Re: linux-next: Tree for June 19
From: Stephen Rothwell @ 2009-06-29 5:25 UTC (permalink / raw)
To: x86; +Cc: Len Brown, linux-next, LKML, sfi-devel
In-Reply-To: <20090622015427.c749a0d9.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 313 bytes --]
Hi All,
On Mon, 22 Jun 2009 01:54:27 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> OK, then I think I need to hear from the x86 maintainers, at least,
> before we include this.
Ping?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: manual merge of the rr tree with Linus' tree
From: Stephen Rothwell @ 2009-06-29 3:43 UTC (permalink / raw)
To: Rusty Russell
Cc: linux-next, linux-kernel, Benjamin Herrenschmidt, Mike Travis
Hi Rusty,
Today's linux-next merge of the rr tree got a conflict in
arch/powerpc/platforms/powermac/setup.c between commit
7ccbe504b5ee766d33211a507189a06f3079b29b ("powerpc/pmac: Fix issues with
PowerMac "PowerSurge" SMP") from Linus' tree and commit
67e33aa4710019a5ee52979f7a9c6458729ab2ab
("cpumask:use-cpumap-accessors-powerpc") from the rr tree.
The code modified by the latter was moved to
arch/powerpc/platforms/powermac/smp.c by the former, so I applied the
latter change to this other file (see below).
There is another use of cpu_set in this file as well (which I did not
change).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/platforms/powermac/smp.c b/arch/powerpc/platforms/powermac/smp.c
index 6d4da7b..da12c48 100644
--- a/arch/powerpc/platforms/powermac/smp.c
+++ b/arch/powerpc/platforms/powermac/smp.c
@@ -952,7 +952,7 @@ void __init pmac_setup_smp(void)
int cpu;
for (cpu = 1; cpu < 4 && cpu < NR_CPUS; ++cpu)
- cpu_set(cpu, cpu_possible_map);
+ set_cpu_possible(cpu, true);
smp_ops = &psurge_smp_ops;
}
#endif /* CONFIG_PPC32 */
^ permalink raw reply related
* Your new time spending with your wife.
From: Gertrude Hendrix @ 2009-06-28 22:43 UTC (permalink / raw)
To: linux-next
Show your true power http://wwjhn.hebcyxehta.net/
^ permalink raw reply
* Re: [PATCH linux-next] kvm/powerpc: fix kvm build tree failure
From: Avi Kivity @ 2009-06-28 7:40 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Christian Bornträger
In-Reply-To: <20090626152347.f87cfa4f.sfr@canb.auug.org.au>
On 06/26/2009 08:23 AM, Stephen Rothwell wrote:
> Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
>
> In file included from include/trace/events/kvm.h:57,
> from arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:63:
> include/trace/define_trace.h:53:43: error: trace/events/TRACE_SYSTEM.h: No such file or directory
>
> Caused by commit faa113b7c65c44ed94ac06f6bae2259290040856 ("KVM:
> Protect irq tracing with KVM_HAVE_IOAPIC and KVM_HAVE_PIT").
>
>
Applied, thanks.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: linux-next: hid tree build failure
From: Stephen Rothwell @ 2009-06-26 17:28 UTC (permalink / raw)
To: Jiri Kosina; +Cc: linux-next, linux-kernel
In-Reply-To: <alpine.LNX.2.00.0906261052350.18021@wotan.suse.de>
[-- Attachment #1: Type: text/plain, Size: 273 bytes --]
Hi Jiri,
On Fri, 26 Jun 2009 10:53:24 +0200 (CEST) Jiri Kosina <jkosina@suse.cz> wrote:
>
> should be now fixed in the branch you pull into -next.
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for June 26 (cyclades)
From: Stephen Rothwell @ 2009-06-26 17:25 UTC (permalink / raw)
To: Alan Cox; +Cc: Randy Dunlap, linux-next, LKML
In-Reply-To: <20090626174414.12ce9291@lxorguk.ukuu.org.uk>
[-- Attachment #1: Type: text/plain, Size: 527 bytes --]
On Fri, 26 Jun 2009 17:44:14 +0100 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> On Fri, 26 Jun 2009 09:04:29 -0700
> Randy Dunlap <randy.dunlap@oracle.com> wrote:
>
> > Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Changes since 20090625:
> >
> >
> > drivers/char/cyclades.c:3332: error: assignment of read-only location
>
> Fixed
I should read all my mail before responding :-)
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for June 26 (cyclades)
From: Stephen Rothwell @ 2009-06-26 17:24 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-next, LKML, Randy Dunlap, Jiri Slaby
In-Reply-To: <4A44F18D.2000608@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 412 bytes --]
On Fri, 26 Jun 2009 09:04:29 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
>
> drivers/char/cyclades.c:3332: error: assignment of read-only location
>
> (it's const)
Caused by commit 93d671fe9bcceb522c922223f836f9c54873b866
("tty-cyclades-cleanup") from the ttydev tree.
Adding cc's.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Merge request for the Thumb-2 branch
From: Catalin Marinas @ 2009-06-26 16:59 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Russell King - ARM Linux
Hi Stephen,
Could you please merge the thumb-2 branch into linux-next:
git://linux-arm.org/linux-2.6.git thumb-2
It adds support for compiling the ARM kernel to the Thumb-2 instruction
set (16 or 32 bit opcodes) and it makes sense to check it doesn't break
other things before the next merging window (it's a bit more intrusive
but limited to arch/arm/* files).
The commits in this branch are:
Catalin Marinas (11):
Thumb-2: Add some .align statements to the .S files
Thumb-2: Add macros for the unified assembler syntax
Thumb-2: Implementation of the unified start-up and exceptions code
Thumb-2: Implement the unified arch/arm/mm support
Thumb-2: Implement the unified arch/arm/lib functions
Thumb-2: Implement the unified VFP support
Thumb-2: Implement the unified boot code
Thumb-2: Add support for loadable modules
Thumb-2: Pass a Thumb-2 address to the secondary CPUs to jump to
Thumb-2: Make the uImage entry an odd number
Thumb-2: Add Thumb-2 support to the build files
Thanks.
--
Catalin
^ permalink raw reply
* Re: linux-next: Tree for June 26 (cyclades)
From: Alan Cox @ 2009-06-26 16:44 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML
In-Reply-To: <4A44F18D.2000608@oracle.com>
On Fri, 26 Jun 2009 09:04:29 -0700
Randy Dunlap <randy.dunlap@oracle.com> wrote:
> Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20090625:
>
>
> drivers/char/cyclades.c:3332: error: assignment of read-only location
Fixed
^ permalink raw reply
* Re: linux-next: Tree for June 26 (cyclades)
From: Randy Dunlap @ 2009-06-26 16:04 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML
In-Reply-To: <20090626154605.ac73b738.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20090625:
drivers/char/cyclades.c:3332: error: assignment of read-only location
(it's const)
--
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/
^ permalink raw reply
* [PATCH] Remove 'SBC8240 Wind River' Device Driver Code
From: Subrata Modak @ 2009-06-26 14:25 UTC (permalink / raw)
To: Scott Wood, David Woodhouse
Cc: linux-kernel, Alexander Beregalov, linux-next, Jim Cromie,
Stephen Rothwell, Linuxppc-dev, carolyn.j.smith, Sachin P Sant,
Subrata Modak, Balbir Singh, Adrian Bunk
Hi David/Scott,
Today's next tree(20090626) produced the following build error:
CC [M] drivers/mtd/maps/sbc8240.o
drivers/mtd/maps/sbc8240.c:31:1: warning: "DEBUG" redefined
In file included from drivers/mtd/maps/sbc8240.c:23:
include/linux/mtd/mtd.h:333:1: warning: this is the location of the previous definition
drivers/mtd/maps/sbc8240.c: In function 'init_sbc8240_mtd':
drivers/mtd/maps/sbc8240.c:172: warning: passing argument 1 of 'simple_map_init' from incompatible pointer type
drivers/mtd/maps/sbc8240.c:177: error: 'struct mtd_info' has no member named 'module'
make[3]: *** [drivers/mtd/maps/sbc8240.o] Error 1
make[2]: *** [drivers/mtd/maps] Error 2
make[1]: *** [drivers/mtd] Error 2
make: *** [drivers] Error 2
I remember reporting this log back in April, when you suggested in removing it:
http://lkml.org/lkml/2009/4/21/476,
>On Tue, 2009-04-21 at 15:00 -0500, Scott Wood wrote:
>Subrata Modak wrote:
> > This is a very old one. Doesn´t seem to go away. Reported this earlier
> > on 14th April:
> > http://lkml.org/lkml/2009/4/14/483,
> >
> > CC [M] drivers/mtd/maps/sbc8240.o
> > drivers/mtd/maps/sbc8240.c:31:1: warning: "DEBUG" redefined
> > In file included from drivers/mtd/maps/sbc8240.c:23:
> > include/linux/mtd/mtd.h:339:1: warning: this is the location of the
> > previous definition
> > drivers/mtd/maps/sbc8240.c: In function ‘init_sbc8240_mtd’:
> > drivers/mtd/maps/sbc8240.c:172: error: ‘sbc8240_mtd’ undeclared (first
> > use in this function)
> > drivers/mtd/maps/sbc8240.c:172: error: (Each undeclared identifier is
> > reported only once
> > drivers/mtd/maps/sbc8240.c:172: error: for each function it appears in.)
> > drivers/mtd/maps/sbc8240.c: In function ‘cleanup_sbc8240_mtd’:
> > drivers/mtd/maps/sbc8240.c:233: error: ‘sbc8240_mtd’ undeclared (first
> > use in this function)
>
> This looks like an arch/ppc orphan. It's not enabled by any defconfig,
> and it doesn't look like it does anything that physmap_of can't do.
>
> I'd just remove it.
>
> -Scott
I tried to gather some more info about this driver from the link
mentioned in Kconfig:
http://www.windriver.com/products/sbc8240/,
without much success.
If there are no issues, can you please apply this patch to remove it ?
To: David Woodhouse <dwmw2@infradead.org>,
To: Scott Wood <scottwood@freescale.com>,
Cc: Jim Cromie <jim.cromie@gmail.com>,
Cc: carolyn.j.smith@exgate.tek.com,
Cc: Adrian Bunk <bunk@kernel.org>,
Cc: Sachin P Sant <sachinp@linux.vnet.ibm.com>,
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>,
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
Cc: Linuxppc-dev <Linuxppc-dev@ozlabs.org>,
Cc: linux-next <linux-next@vger.kernel.org>,
Cc: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: Subrata Modak <subrata@linux.vnet.ibm.com>
Tested-on-PPC64-by: Subrata Modak <subrata@linux.vnet.ibm.com>
---
diff -uprN a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
--- a/drivers/mtd/maps/Kconfig 2009-06-26 07:36:23.000000000 -0500
+++ b/drivers/mtd/maps/Kconfig 2009-06-26 07:39:34.000000000 -0500
@@ -284,13 +284,6 @@ config MTD_L440GX
BE VERY CAREFUL.
-config MTD_SBC8240
- tristate "Flash device on SBC8240"
- depends on MTD_JEDECPROBE && 8260
- help
- Flash access on the SBC8240 board from Wind River. See
- <http://www.windriver.com/products/sbc8240/>
-
config MTD_TQM8XXL
tristate "CFI Flash device mapped on TQM8XXL"
depends on MTD_CFI && TQM8xxL
diff -uprN a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
--- a/drivers/mtd/maps/Makefile 2009-06-26 07:36:23.000000000 -0500
+++ b/drivers/mtd/maps/Makefile 2009-06-26 07:40:03.000000000 -0500
@@ -50,7 +50,6 @@ obj-$(CONFIG_MTD_UCLINUX) += uclinux.o
obj-$(CONFIG_MTD_NETtel) += nettel.o
obj-$(CONFIG_MTD_SCB2_FLASH) += scb2_flash.o
obj-$(CONFIG_MTD_H720X) += h720x-flash.o
-obj-$(CONFIG_MTD_SBC8240) += sbc8240.o
obj-$(CONFIG_MTD_IXP4XX) += ixp4xx.o
obj-$(CONFIG_MTD_IXP2000) += ixp2000.o
obj-$(CONFIG_MTD_WRSBC8260) += wr_sbc82xx_flash.o
diff -uprN a/drivers/mtd/maps/sbc8240.c b/drivers/mtd/maps/sbc8240.c
--- a/drivers/mtd/maps/sbc8240.c 2009-06-26 07:36:23.000000000 -0500
+++ b/drivers/mtd/maps/sbc8240.c 1969-12-31 18:00:00.000000000 -0600
@@ -1,250 +0,0 @@
-/*
- * Handle mapping of the flash memory access routines on the SBC8240 board.
- *
- * Carolyn Smith, Tektronix, Inc.
- *
- * This code is GPLed
- */
-
-/*
- * The SBC8240 has 2 flash banks.
- * Bank 0 is a 512 KiB AMD AM29F040B; 8 x 64 KiB sectors.
- * It contains the U-Boot code (7 sectors) and the environment (1 sector).
- * Bank 1 is 4 x 1 MiB AMD AM29LV800BT; 15 x 64 KiB sectors, 1 x 32 KiB sector,
- * 2 x 8 KiB sectors, 1 x 16 KiB sectors.
- * Both parts are JEDEC compatible.
- */
-
-#include <linux/module.h>
-#include <linux/types.h>
-#include <linux/kernel.h>
-#include <asm/io.h>
-
-#include <linux/mtd/mtd.h>
-#include <linux/mtd/map.h>
-#include <linux/mtd/cfi.h>
-
-#ifdef CONFIG_MTD_PARTITIONS
-#include <linux/mtd/partitions.h>
-#endif
-
-#define DEBUG
-
-#ifdef DEBUG
-# define debugk(fmt,args...) printk(fmt ,##args)
-#else
-# define debugk(fmt,args...)
-#endif
-
-
-#define WINDOW_ADDR0 0xFFF00000 /* 512 KiB */
-#define WINDOW_SIZE0 0x00080000
-#define BUSWIDTH0 1
-
-#define WINDOW_ADDR1 0xFF000000 /* 4 MiB */
-#define WINDOW_SIZE1 0x00400000
-#define BUSWIDTH1 8
-
-#define MSG_PREFIX "sbc8240:" /* prefix for our printk()'s */
-#define MTDID "sbc8240-%d" /* for mtdparts= partitioning */
-
-
-static struct map_info sbc8240_map[2] = {
- {
- .name = "sbc8240 Flash Bank #0",
- .size = WINDOW_SIZE0,
- .bankwidth = BUSWIDTH0,
- },
- {
- .name = "sbc8240 Flash Bank #1",
- .size = WINDOW_SIZE1,
- .bankwidth = BUSWIDTH1,
- }
-};
-
-#define NUM_FLASH_BANKS ARRAY_SIZE(sbc8240_map)
-
-/*
- * The following defines the partition layout of SBC8240 boards.
- *
- * See include/linux/mtd/partitions.h for definition of the
- * mtd_partition structure.
- *
- * The *_max_flash_size is the maximum possible mapped flash size
- * which is not necessarily the actual flash size. It must correspond
- * to the value specified in the mapping definition defined by the
- * "struct map_desc *_io_desc" for the corresponding machine.
- */
-
-#ifdef CONFIG_MTD_PARTITIONS
-
-static struct mtd_partition sbc8240_uboot_partitions [] = {
- /* Bank 0 */
- {
- .name = "U-boot", /* U-Boot Firmware */
- .offset = 0,
- .size = 0x00070000, /* 7 x 64 KiB sectors */
- .mask_flags = MTD_WRITEABLE, /* force read-only */
- },
- {
- .name = "environment", /* U-Boot environment */
- .offset = 0x00070000,
- .size = 0x00010000, /* 1 x 64 KiB sector */
- },
-};
-
-static struct mtd_partition sbc8240_fs_partitions [] = {
- {
- .name = "jffs", /* JFFS filesystem */
- .offset = 0,
- .size = 0x003C0000, /* 4 * 15 * 64KiB */
- },
- {
- .name = "tmp32",
- .offset = 0x003C0000,
- .size = 0x00020000, /* 4 * 32KiB */
- },
- {
- .name = "tmp8a",
- .offset = 0x003E0000,
- .size = 0x00008000, /* 4 * 8KiB */
- },
- {
- .name = "tmp8b",
- .offset = 0x003E8000,
- .size = 0x00008000, /* 4 * 8KiB */
- },
- {
- .name = "tmp16",
- .offset = 0x003F0000,
- .size = 0x00010000, /* 4 * 16KiB */
- }
-};
-
-/* trivial struct to describe partition information */
-struct mtd_part_def
-{
- int nums;
- unsigned char *type;
- struct mtd_partition* mtd_part;
-};
-
-static struct mtd_info *sbc8240_mtd[NUM_FLASH_BANKS];
-static struct mtd_part_def sbc8240_part_banks[NUM_FLASH_BANKS];
-
-
-#endif /* CONFIG_MTD_PARTITIONS */
-
-
-static int __init init_sbc8240_mtd (void)
-{
- static struct _cjs {
- u_long addr;
- u_long size;
- } pt[NUM_FLASH_BANKS] = {
- {
- .addr = WINDOW_ADDR0,
- .size = WINDOW_SIZE0
- },
- {
- .addr = WINDOW_ADDR1,
- .size = WINDOW_SIZE1
- },
- };
-
- int devicesfound = 0;
- int i,j;
-
- for (i = 0; i < NUM_FLASH_BANKS; i++) {
- printk (KERN_NOTICE MSG_PREFIX
- "Probing 0x%08lx at 0x%08lx\n", pt[i].size, pt[i].addr);
-
- sbc8240_map[i].map_priv_1 =
- (unsigned long) ioremap (pt[i].addr, pt[i].size);
- if (!sbc8240_map[i].map_priv_1) {
- printk (MSG_PREFIX "failed to ioremap\n");
- for (j = 0; j < i; j++) {
- iounmap((void *) sbc8240_map[j].map_priv_1);
- sbc8240_map[j].map_priv_1 = 0;
- }
- return -EIO;
- }
- simple_map_init(&sbc8240_mtd[i]);
-
- sbc8240_mtd[i] = do_map_probe("jedec_probe", &sbc8240_map[i]);
-
- if (sbc8240_mtd[i]) {
- sbc8240_mtd[i]->module = THIS_MODULE;
- devicesfound++;
- } else {
- if (sbc8240_map[i].map_priv_1) {
- iounmap((void *) sbc8240_map[i].map_priv_1);
- sbc8240_map[i].map_priv_1 = 0;
- }
- }
- }
-
- if (!devicesfound) {
- printk(KERN_NOTICE MSG_PREFIX
- "No suppported flash chips found!\n");
- return -ENXIO;
- }
-
-#ifdef CONFIG_MTD_PARTITIONS
- sbc8240_part_banks[0].mtd_part = sbc8240_uboot_partitions;
- sbc8240_part_banks[0].type = "static image";
- sbc8240_part_banks[0].nums = ARRAY_SIZE(sbc8240_uboot_partitions);
- sbc8240_part_banks[1].mtd_part = sbc8240_fs_partitions;
- sbc8240_part_banks[1].type = "static file system";
- sbc8240_part_banks[1].nums = ARRAY_SIZE(sbc8240_fs_partitions);
-
- for (i = 0; i < NUM_FLASH_BANKS; i++) {
-
- if (!sbc8240_mtd[i]) continue;
- if (sbc8240_part_banks[i].nums == 0) {
- printk (KERN_NOTICE MSG_PREFIX
- "No partition info available, registering whole device\n");
- add_mtd_device(sbc8240_mtd[i]);
- } else {
- printk (KERN_NOTICE MSG_PREFIX
- "Using %s partition definition\n", sbc8240_part_banks[i].mtd_part->name);
- add_mtd_partitions (sbc8240_mtd[i],
- sbc8240_part_banks[i].mtd_part,
- sbc8240_part_banks[i].nums);
- }
- }
-#else
- printk(KERN_NOTICE MSG_PREFIX
- "Registering %d flash banks at once\n", devicesfound);
-
- for (i = 0; i < devicesfound; i++) {
- add_mtd_device(sbc8240_mtd[i]);
- }
-#endif /* CONFIG_MTD_PARTITIONS */
-
- return devicesfound == 0 ? -ENXIO : 0;
-}
-
-static void __exit cleanup_sbc8240_mtd (void)
-{
- int i;
-
- for (i = 0; i < NUM_FLASH_BANKS; i++) {
- if (sbc8240_mtd[i]) {
- del_mtd_device (sbc8240_mtd[i]);
- map_destroy (sbc8240_mtd[i]);
- }
- if (sbc8240_map[i].map_priv_1) {
- iounmap ((void *) sbc8240_map[i].map_priv_1);
- sbc8240_map[i].map_priv_1 = 0;
- }
- }
-}
-
-module_init (init_sbc8240_mtd);
-module_exit (cleanup_sbc8240_mtd);
-
-MODULE_LICENSE ("GPL");
-MODULE_AUTHOR ("Carolyn Smith <carolyn.smith@tektronix.com>");
-MODULE_DESCRIPTION ("MTD map driver for SBC8240 boards");
-
---
Regards--
Subrata
^ permalink raw reply
* Re: linux-next: block tree build failure
From: Jens Axboe @ 2009-06-26 9:00 UTC (permalink / raw)
To: Neil Brown; +Cc: Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <19012.24947.650584.93908@notabene.brown>
On Fri, Jun 26 2009, Neil Brown wrote:
> On Friday June 26, jens.axboe@oracle.com wrote:
> > On Fri, Jun 26 2009, NeilBrown wrote:
> > > On Fri, June 26, 2009 12:53 pm, Stephen Rothwell wrote:
> > > > Hi Jens,
> > > >
> > > > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > > >
> > > > block/blk-core.c: In function '__make_request':
> > > > block/blk-core.c:1179: error: expected ';' before 'return'
> > > >
> > > > Caused by commit 6cf2a6c8d01514e86a8d38e4eeed402378b635dc ("Restore
> > > > barrier support for md and probably other virtual devices") which I have
> > > > reverted for today.
> > >
> > > Arg, that's my fault - sorry.
> > >
> > > + bio_endio(bio, -EOPNOTSUPP)
> > > + return 0;
> > >
> > > should of course be
> > >
> > > + bio_endio(bio, -EOPNOTSUPP);
> > > + return 0;
> >
> > I was certain I ran it through a compile cycle, sorry about that
> > Stephen. And Neil sending uncompiled patches, very uncool. Did you even
> > test it? I've pulled it for now.
>
> I tested this time.
> Without the patch a 'mount -o journal=1 /dev/md0 /mnt'
> followed by writing to /mnt/something produces
>
> Jun 26 15:34:18 dell kernel: JBD: barrier-based sync failed on md0 - disabling barriers
>
> in the kernel logs.
> With the patch, it doesn't.
>
> Comment updated slightly too.
Applied this one. But please in the future do let me know if you haven't
tested or even compiled a patch. When I get an official looking patch
like the previous one, I'll usually apply it directly. Breaking the
build is baaaad.
--
Jens Axboe
^ permalink raw reply
* Re: linux-next: hid tree build failure
From: Jiri Kosina @ 2009-06-26 8:53 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel
In-Reply-To: <20090626153100.de647d08.sfr@canb.auug.org.au>
On Fri, 26 Jun 2009, Stephen Rothwell wrote:
> Today's linux-next build (sparc32 defconfig) failed like this:
>
> drivers/hid/hid-core.c:862:34: error: macro "hid_dump_input" passed 3 arguments, but takes just 2
> drivers/hid/hid-core.c: In function 'hid_process_event':
> drivers/hid/hid-core.c:862: error: 'hid_dump_input' undeclared (first use in this function)
> drivers/hid/hid-core.c:862: error: (Each undeclared identifier is reported only once
> drivers/hid/hid-core.c:862: error: for each function it appears in.)
> drivers/hid/hid-core.c:984:68: error: macro "hid_dump_input" passed 3 arguments, but takes just 2
> drivers/hid/hid-core.c: In function 'hid_set_field':
> drivers/hid/hid-core.c:984: error: 'hid_dump_input' undeclared (first use in this function)
> drivers/hid/hid-core.c: In function 'hid_input_report':
> drivers/hid/hid-core.c:1090: error: 'HID_DEBUG_BUFSIZE' undeclared (first use in this function)
>
> Caused by commit cd667ce24796700e1a0e6e7528efc61c96ff832e ("HID: use
> debugfs for events/reports dumping") which modified the prototype for
> hid_dump_input, but not the !CONFIG_DEBUG_FS version. It also added
> HID_DEBUG_BUFSIZE when CONFIG_DEBUG_FS, but used it otherwise.
>
> I have reverted that commit for today (along with commit
> a635f9dd83f3382577f4544a96df12356e951a40 ("HID: use debugfs for report
> dumping descriptor") which doesn't build without the other one).
Hi Stephen,
should be now fixed in the branch you pull into -next.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: linux-next: block tree build failure
From: Neil Brown @ 2009-06-26 5:49 UTC (permalink / raw)
To: Jens Axboe; +Cc: Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <20090626043937.GJ31415@kernel.dk>
On Friday June 26, jens.axboe@oracle.com wrote:
> On Fri, Jun 26 2009, NeilBrown wrote:
> > On Fri, June 26, 2009 12:53 pm, Stephen Rothwell wrote:
> > > Hi Jens,
> > >
> > > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > >
> > > block/blk-core.c: In function '__make_request':
> > > block/blk-core.c:1179: error: expected ';' before 'return'
> > >
> > > Caused by commit 6cf2a6c8d01514e86a8d38e4eeed402378b635dc ("Restore
> > > barrier support for md and probably other virtual devices") which I have
> > > reverted for today.
> >
> > Arg, that's my fault - sorry.
> >
> > + bio_endio(bio, -EOPNOTSUPP)
> > + return 0;
> >
> > should of course be
> >
> > + bio_endio(bio, -EOPNOTSUPP);
> > + return 0;
>
> I was certain I ran it through a compile cycle, sorry about that
> Stephen. And Neil sending uncompiled patches, very uncool. Did you even
> test it? I've pulled it for now.
I tested this time.
Without the patch a 'mount -o journal=1 /dev/md0 /mnt'
followed by writing to /mnt/something produces
Jun 26 15:34:18 dell kernel: JBD: barrier-based sync failed on md0 - disabling barriers
in the kernel logs.
With the patch, it doesn't.
Comment updated slightly too.
NeilBrown
Author: NeilBrown <neilb@suse.de>
Date: Fri Jun 26 15:41:35 2009 +1000
Restore barrier support for md and probably other virtual devices.
The next_ordered flag is only meaningful for devices that use __make_request.
So move the test against next_ordered out of generic code and in to
__make_request
Since this test was added, barriers have not worked on md or any
devices that don't use __make_request and so don't bother to set
next_ordered. (dm explicitly sets something other than
QUEUE_ORDERED_NONE since
commit 99360b4c18f7675b50d283301d46d755affe75fd
but notes in the comments that it is otherwise meaningless).
Cc: Ken Milmore <ken.milmore@googlemail.com>
Cc: stable@kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
diff --git a/block/blk-core.c b/block/blk-core.c
index b06cf5c..2283116 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1172,6 +1172,11 @@ static int __make_request(struct request_queue *q, struct bio *bio)
const int unplug = bio_unplug(bio);
int rw_flags;
+ if (bio_barrier(bio) && bio_has_data(bio) &&
+ (q->next_ordered == QUEUE_ORDERED_NONE)) {
+ bio_endio(bio, -EOPNOTSUPP);
+ return 0;
+ }
/*
* low level driver can indicate that it wants pages above a
* certain limit bounced to low memory (ie for highmem, or even
@@ -1472,11 +1477,6 @@ static inline void __generic_make_request(struct bio *bio)
err = -EOPNOTSUPP;
goto end_io;
}
- if (bio_barrier(bio) && bio_has_data(bio) &&
- (q->next_ordered == QUEUE_ORDERED_NONE)) {
- err = -EOPNOTSUPP;
- goto end_io;
- }
ret = q->make_request_fn(q, bio);
} while (ret);
^ permalink raw reply related
* linux-next: Tree for June 26
From: Stephen Rothwell @ 2009-06-26 5:46 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 6923 bytes --]
Hi all,
Changes since 20090625:
My fixes tree contains these two commits:
fbdev: work around old compiler bug
This tree fails to build for powerpc allyesconfig.
Linus' tree lost its build failure.
The block tree lost its complex conflict against Linus' tree but gained a
build failure for which I reverted a commit.
The rr tree has a build failure (for UML) for which I applied a patch.
The tip tree gained a conflict against the ttydev tree.
The kvm tree gained a build failure for which I applied a patch.
The hid tree gained a build failure for which I reverted 2 commits.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES) and i386, sparc and sparc64 defconfig.
These builds also have CONFIG_ENABLE_WARN_DEPRECATED,
CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
We are up to 130 trees (counting Linus' and 19 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging dwmw2/master
Merging arm/devel
Merging davinci/for-next
Merging pxa/for-next
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
CONFLICT (add/add): Merge conflict in arch/mips/cavium-octeon/executive/cvmx-helper-errata.c
CONFLICT (content): Merge conflict in arch/mips/mm/tlbex.c
CONFLICT (content): Merge conflict in arch/mips/sibyte/swarm/setup.c
CONFLICT (content): Merge conflict in drivers/char/hw_random/Kconfig
CONFLICT (content): Merge conflict in drivers/char/hw_random/Makefile
CONFLICT (add/add): Merge conflict in drivers/dma/txx9dmac.c
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging xtensa/master
Merging cifs/master
Merging configfs/linux-next
CONFLICT (content): Merge conflict in fs/configfs/dir.c
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging jfs/next
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging squashfs/master
Merging v9fs/for-next
CONFLICT (content): Merge conflict in net/9p/protocol.c
Merging ubifs/linux-next
Merging xfs/master
Merging reiserfs-bkl/reiserfs/kill-bkl-rc6
CONFLICT (content): Merge conflict in fs/reiserfs/super.c
Merging vfs/for-next
Merging pci/linux-next
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging quota/for_next
Merging kbuild/master
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging async_tx/next
Merging udf/for_next
Merging net/master
Merging wireless/master
Merging mtd/master
Merging crypto/master
Merging sound/for-next
Merging cpufreq/next
Merging quilt/rr
CONFLICT (content): Merge conflict in kernel/cpu.c
Applying: UML: Fix some apparent bitrot in mmu_context.h
Merging mmc/next
Merging input/next
Merging bkl-removal/bkl-removal
Merging lsm/for-next
Merging block/for-next
[master fdbcf39] Revert "Restore barrier support for md and probably other virtual devices."
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging quilt/ttydev
Merging agp/agp-next
Merging uwb/for-upstream
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging omap/for-next
Merging quilt/aoe
Merging suspend/linux-next
Merging bluetooth/master
Merging edac-amd/for-next
Merging fsnotify/for-next
Merging irda/for-next
Merging hwlat/for-linus
Merging tip/auto-latest
CONFLICT (content): Merge conflict in arch/x86/include/asm/termios.h
Merging asm-generic/next
Merging quilt/driver-core
Merging quilt/usb
Merging quilt/staging
Merging scsi-post-merge/master
Applying: kvm/powerpc: fix build error
[master 8957949] Revert "HID: use debugfs for events/reports dumping"
[master 275f907] Revert "HID: use debugfs for report dumping descriptor"
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: hid tree build failure
From: Stephen Rothwell @ 2009-06-26 5:31 UTC (permalink / raw)
To: Jiri Kosina; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]
Hi Jiri,
Today's linux-next build (sparc32 defconfig) failed like this:
drivers/hid/hid-core.c:862:34: error: macro "hid_dump_input" passed 3 arguments, but takes just 2
drivers/hid/hid-core.c: In function 'hid_process_event':
drivers/hid/hid-core.c:862: error: 'hid_dump_input' undeclared (first use in this function)
drivers/hid/hid-core.c:862: error: (Each undeclared identifier is reported only once
drivers/hid/hid-core.c:862: error: for each function it appears in.)
drivers/hid/hid-core.c:984:68: error: macro "hid_dump_input" passed 3 arguments, but takes just 2
drivers/hid/hid-core.c: In function 'hid_set_field':
drivers/hid/hid-core.c:984: error: 'hid_dump_input' undeclared (first use in this function)
drivers/hid/hid-core.c: In function 'hid_input_report':
drivers/hid/hid-core.c:1090: error: 'HID_DEBUG_BUFSIZE' undeclared (first use in this function)
Caused by commit cd667ce24796700e1a0e6e7528efc61c96ff832e ("HID: use
debugfs for events/reports dumping") which modified the prototype for
hid_dump_input, but not the !CONFIG_DEBUG_FS version. It also added
HID_DEBUG_BUFSIZE when CONFIG_DEBUG_FS, but used it otherwise.
I have reverted that commit for today (along with commit
a635f9dd83f3382577f4544a96df12356e951a40 ("HID: use debugfs for report
dumping descriptor") which doesn't build without the other one).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH linux-next] kvm/powerpc: fix kvm build tree failure
From: Stephen Rothwell @ 2009-06-26 5:23 UTC (permalink / raw)
To: Avi Kivity; +Cc: linux-next, linux-kernel, "Christian Bornträger"
Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
In file included from include/trace/events/kvm.h:57,
from arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:63:
include/trace/define_trace.h:53:43: error: trace/events/TRACE_SYSTEM.h: No such file or directory
Caused by commit faa113b7c65c44ed94ac06f6bae2259290040856 ("KVM:
Protect irq tracing with KVM_HAVE_IOAPIC and KVM_HAVE_PIT").
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/trace/events/kvm.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/trace/events/kvm.h b/include/trace/events/kvm.h
index dff68b3..5e69489 100644
--- a/include/trace/events/kvm.h
+++ b/include/trace/events/kvm.h
@@ -3,11 +3,11 @@
#include <linux/tracepoint.h>
-#if defined(__KVM_HAVE_IOAPIC) && defined(__KVM_HAVE_PIT)
#undef TRACE_SYSTEM
#define TRACE_SYSTEM kvm
#define TRACE_INCLUDE_FILE kvm
+#if defined(__KVM_HAVE_IOAPIC) && defined(__KVM_HAVE_PIT)
TRACE_EVENT(kvm_set_irq,
TP_PROTO(unsigned int gsi),
TP_ARGS(gsi),
--
1.6.3.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: linux-next: block tree build failure
From: Jens Axboe @ 2009-06-26 4:39 UTC (permalink / raw)
To: NeilBrown; +Cc: Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <f236aae1aa8ea7c4f3700dbca2f3ae14.squirrel@neil.brown.name>
On Fri, Jun 26 2009, NeilBrown wrote:
> On Fri, June 26, 2009 12:53 pm, Stephen Rothwell wrote:
> > Hi Jens,
> >
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> >
> > block/blk-core.c: In function '__make_request':
> > block/blk-core.c:1179: error: expected ';' before 'return'
> >
> > Caused by commit 6cf2a6c8d01514e86a8d38e4eeed402378b635dc ("Restore
> > barrier support for md and probably other virtual devices") which I have
> > reverted for today.
>
> Arg, that's my fault - sorry.
>
> + bio_endio(bio, -EOPNOTSUPP)
> + return 0;
>
> should of course be
>
> + bio_endio(bio, -EOPNOTSUPP);
> + return 0;
I was certain I ran it through a compile cycle, sorry about that
Stephen. And Neil sending uncompiled patches, very uncool. Did you even
test it? I've pulled it for now.
--
Jens Axboe
^ 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