* Re: linux-next: acpi tree build failure
From: Greg KH @ 2009-02-07 5:32 UTC (permalink / raw)
To: Len Brown; +Cc: Stephen Rothwell, linux-next, Matthew Garrett, Kay Sievers
In-Reply-To: <alpine.LFD.2.00.0902062303090.26256@localhost.localdomain>
On Fri, Feb 06, 2009 at 11:06:28PM -0500, Len Brown wrote:
>
> On Wed, 4 Feb 2009, Greg KH wrote:
>
> > On Thu, Feb 05, 2009 at 01:13:40PM +1100, Stephen Rothwell wrote:
> > > Greg, Len,
> > >
> > > On Mon, 2 Feb 2009 13:22:54 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > >
> > > > drivers/platform/x86/oqo-wmi.c: In function 'oqo_kine_init':
> > > > drivers/platform/x86/oqo-wmi.c:595: error: 'struct device' has no member named 'bus_id'
> > > >
> > > > Caused by commit 03919980ad590ad5c5c181d1bd7d58513ad170bc ("platform/x86:
> > > > Add oqo-wmi driver for model 2 OQO backlight and rfkill control")
> > > > interacting with commit c44c8304353aa6da82cbf98040c6a9c254e68e1c ("driver
> > > > core: get rid of struct device's bus_id string array") from the
> > > > driver-core tree.
> > >
> > > Still getting this (of course). Can you guys come up with a fix, please?
> >
> > Len, you have the patch from Kay, what do you want to do with it?
>
> I don't recall a patch from Kay specifically for OQO.
> OQO is sitting in my tree to get exposure while it waits for
> a few updates from Matthew.
Ah, sorry, I was confused with the other acpi bus_id patch.
> I think it can be restored with this 1 liner, which I can apply to it.
Yes, your patch looks fine.
thanks,
greg k-h
^ permalink raw reply
* linux-next: manual merge of the tip-core tree with the x86 tree
From: Stephen Rothwell @ 2009-02-09 0:24 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
Cc: linux-next, Cyrill Gorcunov, Jaswinder Singh Rajput
[-- Attachment #1: Type: text/plain, Size: 481 bytes --]
Hi all,
Today's linux-next merge of the tip-core tree got a trivial conflict in
arch/x86/include/asm/setup.h between commit
dbca1df48e89d8aa59254fdc10ef16c16e73d94e ("x86: headers cleanup -
setup.h") from the x86 tree and commit
15c554439faedfa490389b31db893dc764245e88 ("headers_check fix: x86,
setup.h") from the tip-core tree.
I fixed it up as in tip/master.
--
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 tip-core tree with Linus' tree
From: Stephen Rothwell @ 2009-02-09 0:38 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin; +Cc: linux-next, Chris Mason
[-- Attachment #1: Type: text/plain, Size: 570 bytes --]
Hi all,
Today's linux-next merge of the tip-core tree got a conflict in
fs/btrfs/locking.c between commit
b4ce94de9b4d64e8ab3cf155d13653c666e22b9b ("Btrfs: Change btree locking to
use explicit blocking points") from Linus' tree and commit
cf47b8f3d96b0b8b10b557444a28b3ca4024ff82 ("Btrfs: stop spinning on
mutex_trylock and let the adaptive code spin for us") from the tip-core
tree.
Resolved as in tip/master by taking the version from Linus' tree.
--
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: manual merge of the tip-core tree with Linus' tree
From: Chris Mason @ 2009-02-09 0:46 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next
In-Reply-To: <20090209113855.180c03cb.sfr@canb.auug.org.au>
On Mon, 2009-02-09 at 11:38 +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip-core tree got a conflict in
> fs/btrfs/locking.c between commit
> b4ce94de9b4d64e8ab3cf155d13653c666e22b9b ("Btrfs: Change btree locking to
> use explicit blocking points") from Linus' tree and commit
> cf47b8f3d96b0b8b10b557444a28b3ca4024ff82 ("Btrfs: stop spinning on
> mutex_trylock and let the adaptive code spin for us") from the tip-core
> tree.
>
> Resolved as in tip/master by taking the version from Linus' tree.
Sorry, I meant to ask Ingo to drop the patch I had sent along for the
btrfs adaptive code. Using Linus' copy was the right answer, it replaces
the patch I sent to Ingo.
-chris
^ permalink raw reply
* linux-next: manual merge of the rr tree with the x86 tree
From: Stephen Rothwell @ 2009-02-09 4:29 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-next, Ingo Molnar
Hi Rusty,
Today's linux-next merge of the rr tree got a conflict in
arch/x86/include/asm/es7000/apic.h between commit
018e047f3a98bd8d9e9d78b19bc38415f0c34dd7 ("x86, ES7000: consolidate the
APIC code") from the x86 tree and commit
2bd9413a5deca2b0b764cad0e23dfabd28cbf7fc
("cpumask:remove-address-of-CPU_MASK_ALL") from the rr tree.
The former moved all the code from that file into
arch/x86/mach-generic/es7000.c whcih was itself consolidated into
arch/x86/kernel/es7000_32.c by commit
2e096df8edefad78155bb406a5a86c182b17786e ("x86, ES7000: Consolidate
code") from the x86 tree.
So I added the following patch to the merge of the rr tree and can carry
it as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --git a/arch/x86/kernel/es7000_32.c b/arch/x86/kernel/es7000_32.c
index d6184c1..1c6cabe 100644
--- a/arch/x86/kernel/es7000_32.c
+++ b/arch/x86/kernel/es7000_32.c
@@ -471,7 +471,7 @@ static int es7000_apic_id_registered(void)
static const cpumask_t *target_cpus_cluster(void)
{
- return &CPU_MASK_ALL;
+ return cpu_all_mask;
}
static const cpumask_t *es7000_target_cpus(void)
^ permalink raw reply related
* linux-next: manual merge of the rr tree with the x86 tree
From: Stephen Rothwell @ 2009-02-09 4:29 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-next, Ingo Molnar
Hi Rusty,
Today's linux-next merge of the rr tree got a conflict in
arch/x86/include/asm/numaq/apic.h between commit
5a44632f77a9c867621f7bf80c233eac75fea672 ("x86, numaq: consolidate code")
from the x86 tree and commit 2bd9413a5deca2b0b764cad0e23dfabd28cbf7fc
("cpumask:remove-address-of-CPU_MASK_ALL") from the rr tree.
The former moved all the code from that file into
arch/x86/mach-generic/numaq.c which was further consolidated into
arch/x86/kernel/numaq_32.c by commit
61b90b7ca10cc65d8b850ab542859dc593e5a381 ("x86, NUMAQ: Consolidate code").
I applied the following patch to the merge of the rr tree and can carry it
as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --git a/arch/x86/kernel/numaq_32.c b/arch/x86/kernel/numaq_32.c
index 0cc41a1..6ed0834 100644
--- a/arch/x86/kernel/numaq_32.c
+++ b/arch/x86/kernel/numaq_32.c
@@ -363,7 +363,7 @@ numaq_store_NMI_vector(unsigned short *high, unsigned short *low)
static inline const cpumask_t *numaq_target_cpus(void)
{
- return &CPU_MASK_ALL;
+ return cpu_all_mask;
}
static inline unsigned long
^ permalink raw reply related
* Re: linux-next: manual merge of the tip-core tree with the x86 tree
From: Cyrill Gorcunov @ 2009-02-09 6:00 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next,
Jaswinder Singh Rajput
In-Reply-To: <20090209112453.7bb773f5.sfr@canb.auug.org.au>
On Mon, Feb 9, 2009 at 3:24 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the tip-core tree got a trivial conflict in
> arch/x86/include/asm/setup.h between commit
> dbca1df48e89d8aa59254fdc10ef16c16e73d94e ("x86: headers cleanup -
> setup.h") from the x86 tree and commit
> 15c554439faedfa490389b31db893dc764245e88 ("headers_check fix: x86,
> setup.h") from the tip-core tree.
>
> I fixed it up as in tip/master.
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>
Thanks Stephen.
^ permalink raw reply
* linux-next: Linus' tree build failure
From: Stephen Rothwell @ 2009-02-09 8:29 UTC (permalink / raw)
To: Chris Mason; +Cc: linux-next, LKML, Linus
[-- Attachment #1: Type: text/plain, Size: 956 bytes --]
Hi Chris,
Today's linux-next build (powerpc allyesconfig) failed like this:
fs/btrfs/locking.c: In function 'btrfs_path_lock_waiting':
fs/btrfs/locking.c:254: error: implicit declaration of function '__raw_spin_is_contended'
CONFIG_PREEMPT is not set (since CONFIG_PREEMPT_NONE takes precedence
over it) which means that CONFIG_GENERIC_LOCKBREAK is not set (since it
depends on CONFIG_PREEMPT - at least on powerpc). So spin_is_contended()
is __raw_spin_is_contended().
__raw_spin_is_contended is only defined for UP, MIPS and X86.
Commit b4ce94de9b4d64e8ab3cf155d13653c666e22b9b ("Btrfs: Change btree
locking to use explicit blocking points") from Linus' tree added the
first generic non CONFIG_PREEMPT usage via a call to spin_is_contended().
I got past this for today by building the PowerPC allyesconfig without
btrfs.
--
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: Tree for February 9
From: Stephen Rothwell @ 2009-02-09 8:39 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 8187 bytes --]
Hi all,
[I accidentally deleted the merge and quilt-import logs today :-( - I
wonder if any would have noticed :-). The merge summary still appears
below.]
Changes since 20090206:
New tree:
aoe
Undropped trees:
ide
security-testing
Dropped trees (temporarily):
quota (build problem)
audit (difficult conflicts)
Linus' tree has a build failure for (at least) powerpc allyesconfig in
btrfs.
The tip-core tree lost its conflict, but gained a conflict against each of
Linus' and the x86 trees.
The net tree lost its 2 conflicts.
The rr tree gained 2 conflicts against the x86 tree.
The kmemcheck tree lost a conflict.
The security-testing tree lost its conflict and build failure.
----------------------------------------------------------------------------
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,
ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES) and
i386, sparc and sparc64 defconfig.
Below is a summary of the state of the merge.
We are up to 133 trees (counting Linus' and 18 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 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
CONFLICT (content): Merge conflict in drivers/char/tty_audit.c
CONFLICT (content): Merge conflict in kernel/auditsc.c
Merging crypto-current/master
Merging dwmw2/master
Merging arm/devel
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging mips/mips-for-linux-next
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging pxa/for-next
CONFLICT (content): Merge conflict in arch/arm/configs/magician_defconfig
Merging s390/features
Merging sh/master
Merging sparc/master
Merging x86/auto-x86-next
Merging xtensa/master
Merging quilt/driver-core
Merging quilt/usb
Merging tip-core/auto-core-next
CONFLICT (content): Merge conflict in arch/x86/include/asm/setup.h
CONFLICT (content): Merge conflict in fs/btrfs/locking.c
Merging cpus4096/auto-cpus4096-next
Merging ftrace/auto-ftrace-next
Merging genirq/auto-genirq-next
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
Merging pci/linux-next
CONFLICT (content): Merge conflict in drivers/pci/pcie/portdrv_pci.c
Merging quilt/device-mapper
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging quota/for_next
$ git reset --hard HEAD^
Merging jfs/next
Merging kbuild/master
Merging quilt/ide
Merging libata/NEXT
Merging nfs/linux-next
Merging xfs/master
Merging infiniband/for-next
Merging acpi/test
Merging nfsd/nfsd-next
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging ocfs2/linux-next
Merging ext4/next
CONFLICT (content): Merge conflict in fs/ext4/ext4.h
Merging async_tx/next
Merging udf/for_next
Merging net/master
Merging mtd/master
Merging wireless/master
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
Merging cpufreq/next
Merging v9fs/for-next
CONFLICT (content): Merge conflict in net/9p/protocol.c
Merging quilt/rr
CONFLICT (delete/modify): arch/x86/include/asm/es7000/apic.h deleted in HEAD and modified in quilt/rr. Version quilt/rr of arch/x86/include/asm/es7000/apic.h left in tree.
CONFLICT (delete/modify): arch/x86/include/asm/numaq/apic.h deleted in HEAD and modified in quilt/rr. Version quilt/rr of arch/x86/include/asm/numaq/apic.h left in tree.
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/cpufreq/powernow-k8.c
CONFLICT (content): Merge conflict in drivers/net/virtio_net.c
$ git rm -f arch/x86/include/asm/es7000/apic.h
$ git rm -f arch/x86/include/asm/numaq/apic.h
Applying: rr: fixup for cpumask:remove-address-of-CPU_MASK_ALL
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging bkl-removal/bkl-removal
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
Merging embedded/master
Merging firmware/master
CONFLICT (content): Merge conflict in sound/isa/Kconfig
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
CONFLICT (content): Merge conflict in include/linux/slub_def.h
CONFLICT (content): Merge conflict in mm/slob.c
CONFLICT (content): Merge conflict in mm/slub.c
Merging uclinux/for-next
Merging md/for-next
Merging kmemcheck/auto-kmemcheck-next
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (content): Merge conflict in mm/Makefile
Merging generic-ipi/auto-generic-ipi-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 oprofile/auto-oprofile-next
Merging fastboot/auto-fastboot-next
Merging sparseirq/auto-sparseirq-next
CONFLICT (content): Merge conflict in kernel/irq/handle.c
Merging iommu/auto-iommu-next
CONFLICT (content): Merge conflict in arch/x86/include/asm/dma-mapping.h
Merging uwb/for-upstream
Merging watchdog/master
Merging proc/proc
CONFLICT (content): Merge conflict in security/selinux/hooks.c
Merging bdev/master
Merging dwmw2-iommu/master
CONFLICT (content): Merge conflict in drivers/pci/intel-iommu.c
CONFLICT (content): Merge conflict in include/linux/dma_remapping.h
Merging cputime/cputime
Merging osd/linux-next
Merging fatfs/master
Merging fuse/for-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging squashfs/master
Merging omap/for-next
Merging quilt/aoe
Merging kmemleak/kmemleak
CONFLICT (content): Merge conflict in include/linux/slab.h
CONFLICT (content): Merge conflict in init/main.c
CONFLICT (content): Merge conflict in lib/Kconfig.debug
CONFLICT (content): Merge conflict in mm/slab.c
CONFLICT (content): Merge conflict in mm/slob.c
CONFLICT (content): Merge conflict in mm/slub.c
Merging quilt/staging
Merging scsi-post-merge/master
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the tip-core tree with Linus' tree
From: Ingo Molnar @ 2009-02-09 8:51 UTC (permalink / raw)
To: Chris Mason; +Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin, linux-next
In-Reply-To: <1234140383.26563.0.camel@think.oraclecorp.com>
* Chris Mason <chris.mason@oracle.com> wrote:
> On Mon, 2009-02-09 at 11:38 +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the tip-core tree got a conflict in
> > fs/btrfs/locking.c between commit
> > b4ce94de9b4d64e8ab3cf155d13653c666e22b9b ("Btrfs: Change btree locking to
> > use explicit blocking points") from Linus' tree and commit
> > cf47b8f3d96b0b8b10b557444a28b3ca4024ff82 ("Btrfs: stop spinning on
> > mutex_trylock and let the adaptive code spin for us") from the tip-core
> > tree.
> >
> > Resolved as in tip/master by taking the version from Linus' tree.
>
> Sorry, I meant to ask Ingo to drop the patch I had sent along for the btrfs
> adaptive code. Using Linus' copy was the right answer, it replaces the patch I
> sent to Ingo.
It was obvious how to resolve it so i did not notify you about it. I generally ping
people when a conflict looks troublesome in some way - that's pretty rare.
Ingo
^ permalink raw reply
* X200: Suspend & resume, iwlwifi on 2.6.29-rc3-00697-gae1a25d
From: Nico Schottelius @ 2009-02-09 9:35 UTC (permalink / raw)
To: Linux Next Mailing List; +Cc: LKML, ipw3945-devel
[-- Attachment #1: Type: text/plain, Size: 1733 bytes --]
Hello!
Using latest git fetch from
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
I can suspend and resume!
(-next: does not work for a long time -- what's happening there?)
Though, the first resume takes about 30 seconds, the following ones
resume within 10 seconds.
The iwlagn / iwlwifi driver does not work anymore: ip l s wlan0 up
makes ip hang for about 10 seconds, issuing the following in dmesg:
[22640.752121] iwlagn: Could not load the INST uCode section
[22640.752132] iwlagn: Unable to set up bootstrap uCode: -110
[22645.752062] iwlagn: Could not load the INST uCode section
[22645.752072] iwlagn: Unable to set up bootstrap uCode: -110
[22650.752118] iwlagn: Could not load the INST uCode section
[22650.752128] iwlagn: Unable to set up bootstrap uCode: -110
[22660.752059] iwlagn: Could not load the INST uCode section
[22660.752069] iwlagn: Unable to set up bootstrap uCode: -110
[22660.761456] iwlagn: Unable to initialize device after 5 attempts.
[22660.761581] iwlagn 0000:03:00.0: PCI INT A disabled
I'm using latest microcode:
[10:33] ikn:~# sha1sum /lib/firmware/iwlwifi-5000-1.ucode ~nico/Desktop/iwlwifi-5000-ucode-5.4.A.11/iwlwifi-5000-1.ucode
f06ff86c8baa8616de584f8b0fff072a9aab6a44 /lib/firmware/iwlwifi-5000-1.ucode
f06ff86c8baa8616de584f8b0fff072a9aab6a44 /home/user/nico/Desktop/iwlwifi-5000-ucode-5.4.A.11/iwlwifi-5000-1.ucode
I'm wondering what's broken with iwlwifi and why the first resume takes so long.
Anyone a good idea?
Sincerly,
Nico
--
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/
PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: next-20090206: deadlock on ext4
From: Alexander Beregalov @ 2009-02-09 12:01 UTC (permalink / raw)
To: Eric Sandeen; +Cc: linux-next@vger.kernel.org, linux-ext4, LKML
In-Reply-To: <498C9876.3060208@redhat.com>
2009/2/6 Eric Sandeen <sandeen@redhat.com>:
> Alexander Beregalov wrote:
>> 2009/2/6 Eric Sandeen <sandeen@redhat.com>:
>>> Alexander Beregalov wrote:
>>>> Hi
>>>>
>>>> I run dbench on ext4 on loop device.
>>>>
>>>> EXT4-fs: barriers enabled
>>>> kjournald2 starting: pid 2420, dev loop0:8, commit interval 5 seconds
>>>> EXT4 FS on loop0, internal journal on loop0:8
>>>> EXT4-fs: delayed allocation enabled
>>>> EXT4-fs: file extents enabled
>>>> EXT4-fs: mballoc enabled
>>>> EXT4-fs: mounted filesystem loop0 with ordered data mode
>>>> JBD: barrier-based sync failed on loop0:8 - disabling barriers
>>>>
>>>> INFO: task pdflush:2339 blocked for more than 120 seconds.
>>> Looks a lot like a bug I filed:
>>>
>>> http://bugzilla.kernel.org/show_bug.cgi?id=12579
>>>
>>> but I'm having trouble reproducing it, now. I'll try dbench!
>> Yes, I can reproduce it easy with dbench.
>
> Do you only hit it on loopback? What is the filesystem hosting the loop
> file?
I have reproduced it with 2.6.29-rc4.
Loop file was on XFS.
I can not reproduce it on ext4 on raw device.
Let me know if I can do anything else to help resolving it.
^ permalink raw reply
* Re: next-20090206: kernel BUG at mm/slub.c:1132
From: Alexander Beregalov @ 2009-02-09 13:44 UTC (permalink / raw)
To: Chris Mason
Cc: linux-kernel, linux-mm, linux-btrfs, linux-next@vger.kernel.org
In-Reply-To: <1233934630.17551.1.camel@think.oraclecorp.com>
2009/2/6 Chris Mason <chris.mason@oracle.com>:
> On Fri, 2009-02-06 at 18:10 +0300, Alexander Beregalov wrote:
>> Hi
>>
>> I run dbench on btrfs, which is on file on xfs
>>
>> btrfs: disabling barriers on dev /dev/loop/0
>> ------------[ cut here ]------------
>> kernel BUG at mm/slub.c:1132!
>> invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
>> last sysfs file: /sys/kernel/uevent_seqnum
>
> Btrfs hammers on slab caches quite a lot, can you reproduce this without
> loop or without btrfs?
Hi Chris
No, I can not reproduce it without loop.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH] SGI IA64 UV: fix ia64 build error in the linux-next tree
From: Dean Nelson @ 2009-02-09 16:25 UTC (permalink / raw)
To: Tony Luck; +Cc: Ingo Molnar, Andrew Morton, linux-ia64, linux-next, LKML
Fix the ia64 build error that occurs in the linux-next tree by introducing
an ia64 version of uv.h. Additionally, clean up the usage of is_uv_system().
Signed-off-by: Dean Nelson <dcn@sgi.com>
Signed-off-by: Jack Steiner <steiner@sgi.com>
---
arch/ia64/include/asm/uv/uv.h | 13 +++++++++++++
drivers/misc/sgi-gru/gru.h | 2 --
drivers/misc/sgi-gru/grufile.c | 18 +++---------------
drivers/misc/sgi-xp/xp.h | 22 ++++++++--------------
4 files changed, 24 insertions(+), 31 deletions(-)
Index: linux/arch/ia64/include/asm/uv/uv.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux/arch/ia64/include/asm/uv/uv.h 2009-02-09 09:18:45.657924900 -0600
@@ -0,0 +1,13 @@
+#ifndef _ASM_IA64_UV_UV_H
+#define _ASM_IA64_UV_UV_H
+
+#include <asm/system.h>
+#include <asm/sn/simulator.h>
+
+static inline int is_uv_system(void)
+{
+ /* temporary support for running on hardware simulator */
+ return IS_MEDUSA() || ia64_platform_is("uv");
+}
+
+#endif /* _ASM_IA64_UV_UV_H */
Index: linux/drivers/misc/sgi-gru/gru.h
===================================================================
--- linux.orig/drivers/misc/sgi-gru/gru.h 2009-02-09 09:18:43.485658003 -0600
+++ linux/drivers/misc/sgi-gru/gru.h 2009-02-09 09:18:45.677927344 -0600
@@ -19,8 +19,6 @@
#ifndef __GRU_H__
#define __GRU_H__
-#include <asm/uv/uv.h>
-
/*
* GRU architectural definitions
*/
Index: linux/drivers/misc/sgi-gru/grufile.c
===================================================================
--- linux.orig/drivers/misc/sgi-gru/grufile.c 2009-02-09 09:18:43.485658003 -0600
+++ linux/drivers/misc/sgi-gru/grufile.c 2009-02-09 09:18:45.697930179 -0600
@@ -36,23 +36,11 @@
#include <linux/interrupt.h>
#include <linux/proc_fs.h>
#include <linux/uaccess.h>
+#include <asm/uv/uv.h>
#include "gru.h"
#include "grulib.h"
#include "grutables.h"
-#if defined CONFIG_X86_64
-#include <asm/genapic.h>
-#include <asm/irq.h>
-#define IS_UV() is_uv_system()
-#elif defined CONFIG_IA64
-#include <asm/system.h>
-#include <asm/sn/simulator.h>
-/* temp support for running on hardware simulator */
-#define IS_UV() IS_MEDUSA() || ia64_platform_is("uv")
-#else
-#define IS_UV() 0
-#endif
-
#include <asm/uv/uv_hub.h>
#include <asm/uv/uv_mmrs.h>
@@ -381,7 +369,7 @@ static int __init gru_init(void)
char id[10];
void *gru_start_vaddr;
- if (!IS_UV())
+ if (!is_uv_system())
return 0;
#if defined CONFIG_IA64
@@ -451,7 +439,7 @@ static void __exit gru_exit(void)
int order = get_order(sizeof(struct gru_state) *
GRU_CHIPLETS_PER_BLADE);
- if (!IS_UV())
+ if (!is_uv_system())
return;
for (i = 0; i < GRU_CHIPLETS_PER_BLADE; i++)
Index: linux/drivers/misc/sgi-xp/xp.h
===================================================================
--- linux.orig/drivers/misc/sgi-xp/xp.h 2009-02-09 09:18:43.489658800 -0600
+++ linux/drivers/misc/sgi-xp/xp.h 2009-02-09 09:19:18.065905314 -0600
@@ -15,21 +15,19 @@
#include <linux/mutex.h>
+#if defined CONFIG_X86_UV || defined CONFIG_IA64_SGI_UV
#include <asm/uv/uv.h>
+#define is_uv() is_uv_system()
+#endif
-#ifdef CONFIG_IA64
+#ifndef is_uv
+#define is_uv() 0
+#endif
+
+#if defined CONFIG_IA64
#include <asm/system.h>
#include <asm/sn/arch.h> /* defines is_shub1() and is_shub2() */
#define is_shub() ia64_platform_is("sn2")
-#ifdef CONFIG_IA64_SGI_UV
-#define is_uv() ia64_platform_is("uv")
-#else
-#define is_uv() 0
-#endif
-#endif
-#ifdef CONFIG_X86_64
-#include <asm/genapic.h>
-#define is_uv() is_uv_system()
#endif
#ifndef is_shub1
@@ -44,10 +42,6 @@
#define is_shub() 0
#endif
-#ifndef is_uv
-#define is_uv() 0
-#endif
-
#ifdef USE_DBUG_ON
#define DBUG_ON(condition) BUG_ON(condition)
#else
^ permalink raw reply
* [ofa-general] Re: linux-next: Tree for February 9 (infiniband)
From: Randy Dunlap @ 2009-02-09 16:53 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: general, linux-next, LKML, swise
In-Reply-To: <20090209193908.1a448944.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi all,
>
> [I accidentally deleted the merge and quilt-import logs today :-( - I
> wonder if any would have noticed :-). The merge summary still appears
> below.]
>
> Changes since 20090206:
allyesconfig build on i386 fails with:
drivers/built-in.o: In function `iwch_sgl2pbl_map':
/usr/builds/linux-next-20090209/drivers/infiniband/hw/cxgb3/iwch_qp.c:237: undefined reference to `__umoddi3'
make: *** [.tmp_vmlinux1] Error 1
or allmodconfig on i386 fails with:
ERROR: "__umoddi3" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
--
~Randy
^ permalink raw reply
* Re: linux-next: Tree for February 9 (infiniband)
From: Steve Wise @ 2009-02-09 17:00 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, linux-next, LKML, swise, general, Roland Dreier
In-Reply-To: <49905F93.300@oracle.com>
Randy Dunlap wrote:
> Stephen Rothwell wrote:
>
>> Hi all,
>>
>> [I accidentally deleted the merge and quilt-import logs today :-( - I
>> wonder if any would have noticed :-). The merge summary still appears
>> below.]
>>
>> Changes since 20090206:
>>
>
>
> allyesconfig build on i386 fails with:
>
> drivers/built-in.o: In function `iwch_sgl2pbl_map':
> /usr/builds/linux-next-20090209/drivers/infiniband/hw/cxgb3/iwch_qp.c:237: undefined reference to `__umoddi3'
> make: *** [.tmp_vmlinux1] Error 1
>
>
> or allmodconfig on i386 fails with:
>
> ERROR: "__umoddi3" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
>
>
Somehow changing offset to a u64 must have caused this. What is
__umoddi3? (it can't be good) :)
Steve
^ permalink raw reply
* [ofa-general] Re: linux-next: Tree for February 9 (infiniband)
From: Randy Dunlap @ 2009-02-09 17:01 UTC (permalink / raw)
To: Steve Wise
Cc: Randy Dunlap, Stephen Rothwell, swise, LKML, linux-next, general
In-Reply-To: <49906118.3060801@opengridcomputing.com>
Steve Wise wrote:
> Randy Dunlap wrote:
>> Stephen Rothwell wrote:
>>
>>> Hi all,
>>>
>>> [I accidentally deleted the merge and quilt-import logs today :-( - I
>>> wonder if any would have noticed :-). The merge summary still appears
>>> below.]
>>>
>>> Changes since 20090206:
>>>
>>
>>
>> allyesconfig build on i386 fails with:
>>
>> drivers/built-in.o: In function `iwch_sgl2pbl_map':
>> /usr/builds/linux-next-20090209/drivers/infiniband/hw/cxgb3/iwch_qp.c:237:
>> undefined reference to `__umoddi3'
>> make: *** [.tmp_vmlinux1] Error 1
>>
>>
>> or allmodconfig on i386 fails with:
>>
>> ERROR: "__umoddi3" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
>>
>>
>
> Somehow changing offset to a u64 must have caused this. What is
> __umoddi3? (it can't be good) :)
It's some kind of mod operation, like 64-bit % 32-bit or
64-bit % 64-bit. Should be in a fairly recent change.
--
~Randy
^ permalink raw reply
* Re: linux-next: Tree for February 9 (ide-dma)
From: Randy Dunlap @ 2009-02-09 17:15 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, linux-ide, bzolnier
In-Reply-To: <20090209193908.1a448944.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi all,
>
> [I accidentally deleted the merge and quilt-import logs today :-( - I
> wonder if any would have noticed :-). The merge summary still appears
> below.]
>
> Changes since 20090206:
>
> New tree:
> aoe
>
> Undropped trees:
> ide
When CONFIG_BLK_DEV_IDEDMA=n:
drivers/ide/ide-taskfile.c:104: error: implicit declaration of function 'ide_build_sglist'
--
~Randy
^ permalink raw reply
* Re: linux-next: Tree for February 9 (ide-dma)
From: Bartlomiej Zolnierkiewicz @ 2009-02-09 18:56 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML, linux-ide
In-Reply-To: <499064CC.1030907@oracle.com>
On Monday 09 February 2009, Randy Dunlap wrote:
> Stephen Rothwell wrote:
> > Hi all,
> >
> > [I accidentally deleted the merge and quilt-import logs today :-( - I
> > wonder if any would have noticed :-). The merge summary still appears
> > below.]
> >
> > Changes since 20090206:
> >
> > New tree:
> > aoe
> >
> > Undropped trees:
> > ide
>
>
> When CONFIG_BLK_DEV_IDEDMA=n:
>
> drivers/ide/ide-taskfile.c:104: error: implicit declaration of function 'ide_build_sglist'
Thanks. Should be fixed with new revision of the guilty patch
(fix part is in <linux/ide.h> chunk):
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] ide: call ide_build_sglist() prior to ->dma_setup (v2)
* Re-map sg table if needed in ide_build_sglist().
* Move ide_build_sglist() call from ->dma_setup to its users.
* Un-export ide_build_sglist().
v2:
* Build fix for CONFIG_BLK_DEV_IDEDMA=n (noticed by Randy Dunlap).
There should be no functional changes caused by this patch.
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/au1xxx-ide.c | 7 +------
drivers/ide/icside.c | 6 ------
drivers/ide/ide-atapi.c | 19 ++++++++++++++-----
drivers/ide/ide-dma-sff.c | 4 ----
drivers/ide/ide-dma.c | 9 ++++++---
drivers/ide/ide-taskfile.c | 1 +
drivers/ide/pmac.c | 7 +------
drivers/ide/sgiioc4.c | 10 ++--------
drivers/ide/tx4939ide.c | 4 ----
include/linux/ide.h | 2 ++
10 files changed, 27 insertions(+), 42 deletions(-)
Index: b/drivers/ide/au1xxx-ide.c
===================================================================
--- a/drivers/ide/au1xxx-ide.c
+++ b/drivers/ide/au1xxx-ide.c
@@ -211,21 +211,16 @@ static void auide_set_dma_mode(ide_drive
#ifdef CONFIG_BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA
static int auide_build_dmatable(ide_drive_t *drive)
{
- int i, iswrite, count = 0;
ide_hwif_t *hwif = drive->hwif;
struct request *rq = hwif->rq;
_auide_hwif *ahwif = &auide_hwif;
struct scatterlist *sg;
+ int i = hwif->sg_nents, iswrite, count = 0;
iswrite = (rq_data_dir(rq) == WRITE);
/* Save for interrupt context */
ahwif->drive = drive;
- hwif->sg_nents = i = ide_build_sglist(drive, rq);
-
- if (!i)
- return 0;
-
/* fill the descriptors */
sg = hwif->sg_table;
while (i && sg_dma_len(sg)) {
Index: b/drivers/ide/icside.c
===================================================================
--- a/drivers/ide/icside.c
+++ b/drivers/ide/icside.c
@@ -325,12 +325,6 @@ static int icside_dma_setup(ide_drive_t
*/
BUG_ON(dma_channel_active(ec->dma));
- hwif->sg_nents = ide_build_sglist(drive, rq);
- if (hwif->sg_nents == 0) {
- ide_map_sg(drive, rq);
- return 1;
- }
-
/*
* Ensure that we have the right interrupt routed.
*/
Index: b/drivers/ide/ide-atapi.c
===================================================================
--- a/drivers/ide/ide-atapi.c
+++ b/drivers/ide/ide-atapi.c
@@ -619,18 +619,23 @@ ide_startstop_t ide_issue_pc(ide_drive_t
struct ide_atapi_pc *pc;
ide_hwif_t *hwif = drive->hwif;
ide_expiry_t *expiry = NULL;
+ struct request *rq = hwif->rq;
unsigned int timeout;
u32 tf_flags;
u16 bcount;
if (dev_is_idecd(drive)) {
tf_flags = IDE_TFLAG_OUT_NSECT | IDE_TFLAG_OUT_LBAL;
- bcount = ide_cd_get_xferlen(hwif->rq);
+ bcount = ide_cd_get_xferlen(rq);
expiry = ide_cd_expiry;
timeout = ATAPI_WAIT_PC;
- if (drive->dma)
- drive->dma = !hwif->dma_ops->dma_setup(drive);
+ if (drive->dma) {
+ if (ide_build_sglist(drive, rq))
+ drive->dma = !hwif->dma_ops->dma_setup(drive);
+ else
+ drive->dma = 0;
+ }
} else {
pc = drive->pc;
@@ -649,8 +654,12 @@ ide_startstop_t ide_issue_pc(ide_drive_t
}
if ((pc->flags & PC_FLAG_DMA_OK) &&
- (drive->dev_flags & IDE_DFLAG_USING_DMA))
- drive->dma = !hwif->dma_ops->dma_setup(drive);
+ (drive->dev_flags & IDE_DFLAG_USING_DMA)) {
+ if (ide_build_sglist(drive, rq))
+ drive->dma = !hwif->dma_ops->dma_setup(drive);
+ else
+ drive->dma = 0;
+ }
if (!drive->dma)
pc->flags &= ~PC_FLAG_DMA_OK;
Index: b/drivers/ide/ide-dma-sff.c
===================================================================
--- a/drivers/ide/ide-dma-sff.c
+++ b/drivers/ide/ide-dma-sff.c
@@ -120,10 +120,6 @@ int ide_build_dmatable(ide_drive_t *driv
struct scatterlist *sg;
u8 is_trm290 = !!(hwif->host_flags & IDE_HFLAG_TRM290);
- hwif->sg_nents = ide_build_sglist(drive, rq);
- if (hwif->sg_nents == 0)
- return 0;
-
for_each_sg(hwif->sg_table, sg, hwif->sg_nents, i) {
u32 cur_addr, cur_len, xcount, bcount;
Index: b/drivers/ide/ide-dma.c
===================================================================
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -128,6 +128,7 @@ int ide_build_sglist(ide_drive_t *drive,
{
ide_hwif_t *hwif = drive->hwif;
struct scatterlist *sg = hwif->sg_table;
+ int i;
ide_map_sg(drive, rq);
@@ -136,10 +137,12 @@ int ide_build_sglist(ide_drive_t *drive,
else
hwif->sg_dma_direction = DMA_TO_DEVICE;
- return dma_map_sg(hwif->dev, sg, hwif->sg_nents,
- hwif->sg_dma_direction);
+ i = dma_map_sg(hwif->dev, sg, hwif->sg_nents, hwif->sg_dma_direction);
+ if (i == 0)
+ ide_map_sg(drive, rq);
+
+ return i;
}
-EXPORT_SYMBOL_GPL(ide_build_sglist);
/**
* ide_destroy_dmatable - clean up DMA mapping
Index: b/drivers/ide/ide-taskfile.c
===================================================================
--- a/drivers/ide/ide-taskfile.c
+++ b/drivers/ide/ide-taskfile.c
@@ -103,6 +103,7 @@ ide_startstop_t do_rw_taskfile (ide_driv
return ide_started;
default:
if ((drive->dev_flags & IDE_DFLAG_USING_DMA) == 0 ||
+ ide_build_sglist(drive, hwif->rq) == 0 ||
dma_ops->dma_setup(drive))
return ide_stopped;
dma_ops->dma_exec_cmd(drive, tf->command);
Index: b/drivers/ide/pmac.c
===================================================================
--- a/drivers/ide/pmac.c
+++ b/drivers/ide/pmac.c
@@ -1429,10 +1429,10 @@ pmac_ide_build_dmatable(ide_drive_t *dri
pmac_ide_hwif_t *pmif =
(pmac_ide_hwif_t *)dev_get_drvdata(hwif->gendev.parent);
struct dbdma_cmd *table;
- int i, count = 0;
volatile struct dbdma_regs __iomem *dma = pmif->dma_regs;
struct scatterlist *sg;
int wr = (rq_data_dir(rq) == WRITE);
+ int i = hwif->sg_nents, count = 0;
/* DMA table is already aligned */
table = (struct dbdma_cmd *) pmif->dma_table_cpu;
@@ -1442,11 +1442,6 @@ pmac_ide_build_dmatable(ide_drive_t *dri
while (readl(&dma->status) & RUN)
udelay(1);
- hwif->sg_nents = i = ide_build_sglist(drive, rq);
-
- if (!i)
- return 0;
-
/* Build DBDMA commands list */
sg = hwif->sg_table;
while (i && sg_dma_len(sg)) {
Index: b/drivers/ide/sgiioc4.c
===================================================================
--- a/drivers/ide/sgiioc4.c
+++ b/drivers/ide/sgiioc4.c
@@ -429,15 +429,9 @@ sgiioc4_build_dma_table(ide_drive_t * dr
{
ide_hwif_t *hwif = drive->hwif;
unsigned int *table = hwif->dmatable_cpu;
- unsigned int count = 0, i = 1;
- struct scatterlist *sg;
+ unsigned int count = 0, i = hwif->sg_nents;
+ struct scatterlist *sg = hwif->sg_table;
- hwif->sg_nents = i = ide_build_sglist(drive, rq);
-
- if (!i)
- return 0; /* sglist of length Zero */
-
- sg = hwif->sg_table;
while (i && sg_dma_len(sg)) {
dma_addr_t cur_addr;
int cur_len;
Index: b/drivers/ide/tx4939ide.c
===================================================================
--- a/drivers/ide/tx4939ide.c
+++ b/drivers/ide/tx4939ide.c
@@ -240,10 +240,6 @@ static int tx4939ide_build_dmatable(ide_
int i;
struct scatterlist *sg;
- hwif->sg_nents = ide_build_sglist(drive, rq);
- if (hwif->sg_nents == 0)
- return 0;
-
for_each_sg(hwif->sg_table, sg, hwif->sg_nents, i) {
u32 cur_addr, cur_len, bcount;
Index: b/include/linux/ide.h
===================================================================
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -1474,6 +1474,8 @@ static inline int ide_set_dma(ide_drive_
static inline void ide_check_dma_crc(ide_drive_t *drive) { ; }
static inline ide_startstop_t ide_dma_timeout_retry(ide_drive_t *drive, int error) { return ide_stopped; }
static inline void ide_release_dma_engine(ide_hwif_t *hwif) { ; }
+static inline int ide_build_sglist(ide_drive_t *drive,
+ struct request *rq) { return 0; }
#endif /* CONFIG_BLK_DEV_IDEDMA */
#ifdef CONFIG_BLK_DEV_IDEACPI
^ permalink raw reply
* [PATCH -next] alpha: fix link error re stacktrace
From: Alexey Dobriyan @ 2009-02-09 21:38 UTC (permalink / raw)
To: Stephen Rothwell, mingo; +Cc: linux-next, acme
In-Reply-To: <20090209193908.1a448944.sfr@canb.auug.org.au>
Please, fold this into 32c0bd9624115041cfec31c0436995418083090a
"blktrace: the ftrace interface needs CONFIG_TRACING"
to fix link error on alpha (which doesn't implenent stacktrace support)
--- a/block/Kconfig
+++ b/block/Kconfig
@@ -51,7 +51,7 @@ config BLK_DEV_IO_TRACE
select DEBUG_FS
select TRACEPOINTS
select TRACING
- select STACKTRACE
+ select STACKTRACE if STACKTRACE_SUPPORT
help
Say Y here if you want to be able to trace the block layer actions
on a given queue. Tracing allows you to see any traffic happening
^ permalink raw reply
* Re: linux-next: quota tree build failure
From: Jan Kara @ 2009-02-09 21:36 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next
In-Reply-To: <20090206141806.fdbd5cc3.sfr@canb.auug.org.au>
Hi Stephen,
On Fri 06-02-09 14:18:06, Stephen Rothwell wrote:
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> fs/nfsd/vfs.c: In function 'nfsd_setattr':
> fs/nfsd/vfs.c:359: error: implicit declaration of function 'DQUOT_INIT'
>
> Caused by commit 74d9386bc58d5f8b5bcee051e04e7123cd9cac88 ("quota: Remove
> uppercase aliases for quota functions"). Seems you missed at least one
> of the users.
Thanks for the pointer. Fixed.
Honza
^ permalink raw reply
* Re: linux-next: Tree for February 9 (ide-dma)
From: Randy Dunlap @ 2009-02-09 21:50 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: Stephen Rothwell, linux-next, LKML, linux-ide
In-Reply-To: <200902091956.54226.bzolnier@gmail.com>
Bartlomiej Zolnierkiewicz wrote:
> On Monday 09 February 2009, Randy Dunlap wrote:
>> Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> [I accidentally deleted the merge and quilt-import logs today :-( - I
>>> wonder if any would have noticed :-). The merge summary still appears
>>> below.]
>>>
>>> Changes since 20090206:
>>>
>>> New tree:
>>> aoe
>>>
>>> Undropped trees:
>>> ide
>>
>> When CONFIG_BLK_DEV_IDEDMA=n:
>>
>> drivers/ide/ide-taskfile.c:104: error: implicit declaration of function 'ide_build_sglist'
>
> Thanks. Should be fixed with new revision of the guilty patch
> (fix part is in <linux/ide.h> chunk):
Ack. That works. Thanks.
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] ide: call ide_build_sglist() prior to ->dma_setup (v2)
>
> * Re-map sg table if needed in ide_build_sglist().
>
> * Move ide_build_sglist() call from ->dma_setup to its users.
>
> * Un-export ide_build_sglist().
>
> v2:
> * Build fix for CONFIG_BLK_DEV_IDEDMA=n (noticed by Randy Dunlap).
>
> There should be no functional changes caused by this patch.
>
> Cc: Randy Dunlap <randy.dunlap@oracle.com>
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Index: b/include/linux/ide.h
> ===================================================================
> --- a/include/linux/ide.h
> +++ b/include/linux/ide.h
> @@ -1474,6 +1474,8 @@ static inline int ide_set_dma(ide_drive_
> static inline void ide_check_dma_crc(ide_drive_t *drive) { ; }
> static inline ide_startstop_t ide_dma_timeout_retry(ide_drive_t *drive, int error) { return ide_stopped; }
> static inline void ide_release_dma_engine(ide_hwif_t *hwif) { ; }
> +static inline int ide_build_sglist(ide_drive_t *drive,
> + struct request *rq) { return 0; }
> #endif /* CONFIG_BLK_DEV_IDEDMA */
>
> #ifdef CONFIG_BLK_DEV_IDEACPI
>
>
>
>
--
~Randy
^ permalink raw reply
* Re: [PATCH -next] alpha: fix link error re stacktrace
From: Arnaldo Carvalho de Melo @ 2009-02-09 21:55 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: Stephen Rothwell, Ingo Molnar, Frédéric Weisbecker,
Steven Rostedt, linux-next
In-Reply-To: <20090209213836.GA9492@x200.localdomain>
Em Tue, Feb 10, 2009 at 12:38:36AM +0300, Alexey Dobriyan escreveu:
> Please, fold this into 32c0bd9624115041cfec31c0436995418083090a
> "blktrace: the ftrace interface needs CONFIG_TRACING"
> to fix link error on alpha (which doesn't implenent stacktrace support)
>
> --- a/block/Kconfig
> +++ b/block/Kconfig
> @@ -51,7 +51,7 @@ config BLK_DEV_IO_TRACE
> select DEBUG_FS
> select TRACEPOINTS
> select TRACING
> - select STACKTRACE
> + select STACKTRACE if STACKTRACE_SUPPORT
> help
> Say Y here if you want to be able to trace the block layer actions
> on a given queue. Tracing allows you to see any traffic happening
Well, with 51a763dd84253bab1d0a1e68e11a7753d1b702ca this can as well be
reverted :-)
- Arnaldo
^ permalink raw reply
* Re: [PATCH -next] alpha: fix link error re stacktrace
From: Ingo Molnar @ 2009-02-09 22:39 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: Stephen Rothwell, linux-next, acme
In-Reply-To: <20090209213836.GA9492@x200.localdomain>
* Alexey Dobriyan <adobriyan@gmail.com> wrote:
> Please, fold this into 32c0bd9624115041cfec31c0436995418083090a
> "blktrace: the ftrace interface needs CONFIG_TRACING"
> to fix link error on alpha (which doesn't implenent stacktrace support)
>
> --- a/block/Kconfig
> +++ b/block/Kconfig
> @@ -51,7 +51,7 @@ config BLK_DEV_IO_TRACE
> select DEBUG_FS
> select TRACEPOINTS
> select TRACING
> - select STACKTRACE
> + select STACKTRACE if STACKTRACE_SUPPORT
> help
> Say Y here if you want to be able to trace the block layer actions
> on a given queue. Tracing allows you to see any traffic happening
This didnt apply to the latest tracing tree due to other, interacting changes - i
have applied the commit below - thanks Alexey!
Ingo
----------------->
>From 510223da040cb7a7d6f524b12eeed03b3845aea1 Mon Sep 17 00:00:00 2001
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Tue, 10 Feb 2009 00:38:36 +0300
Subject: [PATCH] alpha: fix link error re stacktrace
Fix link error on alpha (which doesn't implenent stacktrace support).
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
kernel/trace/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 3a33128..79be773 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -310,7 +310,7 @@ config BLK_DEV_IO_TRACE
select DEBUG_FS
select TRACEPOINTS
select TRACING
- select STACKTRACE
+ select STACKTRACE if STACKTRACE_SUPPORT
help
Say Y here if you want to be able to trace the block layer actions
on a given queue. Tracing allows you to see any traffic happening
^ permalink raw reply related
* linux-next: manual merge of the sound tree with the pxa tree
From: Stephen Rothwell @ 2009-02-10 3:22 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linux-next, Philipp Zabel, Eric Miao
Hi Takashi,
Today's linux-next merge of the sound tree got a conflict in
sound/soc/pxa/pxa2xx-i2s.c between commit
69e2a881351e31e936e3a75f8efff768f0edb2be ("[ARM] pxa: move DMA registers
definitions into <mach/dma.h>") from the pxa tree and commit
44dd2b9168350b82a671ce71666b99208ab2d973 ("ASoC: pxa2xx-i2s: remove I2S
pin setup") from the sound tree.
Just simple context change. I fiex it up (see below) and can carry the
fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc sound/soc/pxa/pxa2xx-i2s.c
index 223de89,83b59d7..0000000
--- a/sound/soc/pxa/pxa2xx-i2s.c
+++ b/sound/soc/pxa/pxa2xx-i2s.c
@@@ -24,8 -24,7 +24,7 @@@
#include <sound/pxa2xx-lib.h>
#include <mach/hardware.h>
-#include <mach/pxa-regs.h>
+#include <mach/dma.h>
- #include <mach/pxa2xx-gpio.h>
#include <mach/audio.h>
#include "pxa2xx-pcm.h"
^ 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