linux-next: Tree for April 9

linux-next: Tree for April 9

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 5126 bytes --]

Hi all,

I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(tar balls at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/).

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.

There were a few merge conflicts (fairly trivial) and couple of build
failures (notified).  There is a know build failure with powerpc
allyesconfig.  Below is a summary of the state of the merge.

We are up to 55 trees, 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/ and the guys at http://test.kernel.org/.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

Merging origin/master
Merging x86-fixes/for-linus
Merging sched-fixes/for-linus
Merging powerpc-merge/merge
Merging scsi-rc-fixes/master
Merging quilt/driver-core
Merging quilt/pci
Merging quilt/usb
Merging x86/for-akpm
Created commit 11876f8: Revert "x86: phase out forced inlining"
Merging sched/for-akpm
Merging quilt/device-mapper
Merging hid/mm
Merging quilt/i2c
Merging quilt/kernel-doc
Merging avr32/avr32-arch
Merging v4l-dvb/stable
Merging s390/features
Merging sh/master
Merging jfs/next
Merging kbuild/master
Merging quilt/ide
CONFLICT (content): Merge conflict in Documentation/ide/ide.txt
CONFLICT (content): Merge conflict in Documentation/kernel-parameters.txt
CONFLICT (content): Merge conflict in drivers/ide/ide.c
CONFLICT (content): Merge conflict in include/asm-x86/ide.h
CONFLICT (content): Merge conflict in include/linux/Kbuild
Merging libata/NEXT
Applying libata-fix-1.patch
Merging nfs/linux-next
Merging xfs/master
Merging infiniband/for-next
CONFLICT (content): Merge conflict in drivers/infiniband/hw/amso1100/c2_provider.c
CONFLICT (content): Merge conflict in drivers/infiniband/hw/cxgb3/iwch_provider.c
CONFLICT (content): Merge conflict in drivers/infiniband/hw/nes/nes_verbs.c
Applying infiniband-fix-2
Merging acpi/test
CONFLICT (content): Merge conflict in arch/x86/kernel/setup_64.c
CONFLICT (delete/modify): arch/x86/kernel/smpboot_64.c deleted in HEAD and modified in acpi/test. Version acpi/test of arch/x86/kernel/smpboot_64.c left in tree.
CONFLICT (delete/modify): include/asm-x86/smp_64.h deleted in HEAD and modified in acpi/test. Version acpi/test of include/asm-x86/smp_64.h left in tree.
$ git rm arch/x86/kernel/smpboot_64.c include/asm-x86/smp_64.h
Applying acpi-fix-1.patch
Applying acpi-fix-2.patch
Merging blackfin/for-linus
Merging nfsd/nfsd-next
Merging ieee1394/for-next
CONFLICT (content): Merge conflict in lib/Kconfig.debug
Merging hwmon/testing
Merging ubi/master
Merging kvm/master
CONFLICT (add/add): Merge conflict in include/asm-s390/sysinfo.h
CONFLICT (content): Merge conflict in include/asm-x86/kvm_host.h
Merging dlm/next
Merging scsi/master
Merging ia64/test
CONFLICT (content): Merge conflict in arch/ia64/mm/tlb.c
Merging tests/master
CONFLICT (content): Merge conflict in lib/Kconfig.debug
Merging ocfs2/linux-next
Merging selinux/for-akpm
Merging quilt/m68k
Merging powerpc/powerpc-next
Merging hrt/mm
Merging lblnet/master
Merging ext4/next
CONFLICT (content): Merge conflict in fs/jbd2/journal.c
CONFLICT (content): Merge conflict in fs/jbd2/revoke.c
Merging 4xx/next
Merging async_tx/next
Merging udf/for_next
Merging security-testing/next
Merging net/master
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
CONFLICT (content): Merge conflict in MAINTAINERS
Merging galak/powerpc-next
Merging mtd/master
Merging wireless/master
Merging crypto/master
Merging vfs/vfs-2.6.25
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_ioctl.c
CONFLICT (content): Merge conflict in fs/xfs/xfs_ialloc.c
CONFLICT (content): Merge conflict in fs/xfs/xfs_sb.h
Merging semaphore/semaphore
CONFLICT (delete/modify): include/asm-x86/semaphore_32.h deleted in semaphore/semaphore and modified in HEAD. Version HEAD of include/asm-x86/semaphore_32.h left in tree.
CONFLICT (delete/modify): include/asm-x86/semaphore_64.h deleted in semaphore/semaphore and modified in HEAD. Version HEAD of include/asm-x86/semaphore_64.h left in tree.
$ git rm include/asm-x86/semaphore_32.h include/asm-x86/semaphore_64.h
Merging quilt/ldp
Created commit 1d2b198: Revert "wusb: add the wireless usb stack to Linux"
Applying parport_pc: wrap PNP probe code in #ifdef CONFIG_PNP
Applying nsc-ircc: wrap PNP probe code in #ifdef CONFIG_PNP
Applying smsc-ircc2: wrap PNP probe code in #ifdef CONFIG_PNP

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: linux-next: Tree for April 9

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]

Hi Jacek,

On Wed, 9 Apr 2008 13:00:37 +0200 "Jacek Luczak" <difrost.kernel@gmail.com> wrote:
>
> this tree fails to compile on my box with message:
>   CC      init/version.o
> arch/x86/kernel/traps_32.c: In function 'do_general_protection':
> arch/x86/kernel/traps_32.c:647: error: 'VM_MASK' undeclared (first use in
> this function)
> arch/x86/kernel/traps_32.c:647: error: (Each undeclared identifier is
> reported only once
> arch/x86/kernel/traps_32.c:647: error: for each function it appears in.)
> arch/x86/kernel/traps_32.c: In function 'do_debug':
> arch/x86/kernel/traps_32.c:926: error: 'VM_MASK' undeclared (first use in
> this function)
> arch/x86/kernel/traps_32.c: In function 'do_simd_coprocessor_error':
> arch/x86/kernel/traps_32.c:1098: error: 'VM_MASK' undeclared (first use in
> this function)
> 
> GCC version:
> $ gcc -v
> Reading specs from /usr/lib/gcc/i686-slackware-linux/4.2.2/specs
> Target: i686-slackware-linux
> Configured with: ../gcc-4.2.2/configure --prefix=/usr --enable-shared
> --enable-threads=posix --enable-__cxa_atexit --disable-checking
> --with-gnu-ld --enable-languages=c,c++ --enable-clocale=gnu --verbose
> --disable-multilib --with-tune=prescott --disable-libstdcxx-pch
> --disable-bootstrap --target=i686-slackware-linux
> --host=i686-slackware-linux
> Thread model: posix
> gcc version 4.2.2

Thanks for the report, can you please send us your .config, please?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: linux-next: Tree for April 9

[Jacek Luczak]

Stephen Rothwell pisze:
> Hi Jacek,
> 
> On Wed, 9 Apr 2008 21:09:36 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Thanks for the report, can you please send us your .config, please?
> 
> Don't worry about it, I found the problem.
> 
> It seems that commit 883a9fc4e5d9b0701f15d4e5a23608f942104721 ("x86:
> cleanup - rename VM_MASK to X86_VM_MASK") from the x86 tree seems to have
> missed some places.
> 

Yep, I did the same. You can find patch, which renames changes VM_MASK 
to X86_VM_MASK across all files in arch/x86/kernel, here: 
http://pin.if.uz.zgora.pl/~difrost/linux-next/09042008/

-Jacek

Re: linux-next: Tree for April 9

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

Hi Jacek,

On Wed, 9 Apr 2008 21:09:36 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Thanks for the report, can you please send us your .config, please?

Don't worry about it, I found the problem.

It seems that commit 883a9fc4e5d9b0701f15d4e5a23608f942104721 ("x86:
cleanup - rename VM_MASK to X86_VM_MASK") from the x86 tree seems to have
missed some places.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: linux-next: Tree for April 9

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Jacek,
> 
> On Wed, 9 Apr 2008 21:09:36 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Thanks for the report, can you please send us your .config, please?
> 
> Don't worry about it, I found the problem.
> 
> It seems that commit 883a9fc4e5d9b0701f15d4e5a23608f942104721 ("x86: 
> cleanup - rename VM_MASK to X86_VM_MASK") from the x86 tree seems to 
> have missed some places.

i think what happened is that some changes came in from other trees that 
reintroduced the old symbols?

if that's the case i'll add back the old symbol names to make the 
transition and integration easier.

	Ingo

Re: linux-next: Tree for April 9

[Ingo Molnar]

* Jacek Luczak <difrost.kernel@gmail.com> wrote:

>> Don't worry about it, I found the problem.
>>
>> It seems that commit 883a9fc4e5d9b0701f15d4e5a23608f942104721 ("x86: 
>> cleanup - rename VM_MASK to X86_VM_MASK") from the x86 tree seems to 
>> have missed some places.
>
> Yep, I did the same. You can find patch, which renames changes VM_MASK 
> to X86_VM_MASK across all files in arch/x86/kernel, here: 
> http://pin.if.uz.zgora.pl/~difrost/linux-next/09042008/

ah, that again comes from x86/for-akpm missing a patch that comes later 
in x86/latest. I'll resort it.

	Ingo

Re: linux-next: Tree for April 9

[Jacek Luczak]

Ingo Molnar pisze:
> * Jacek Luczak <difrost.kernel@gmail.com> wrote:
> 
>>> Don't worry about it, I found the problem.
>>>
>>> It seems that commit 883a9fc4e5d9b0701f15d4e5a23608f942104721 ("x86: 
>>> cleanup - rename VM_MASK to X86_VM_MASK") from the x86 tree seems to 
>>> have missed some places.
>> Yep, I did the same. You can find patch, which renames changes VM_MASK 
>> to X86_VM_MASK across all files in arch/x86/kernel, here: 
>> http://pin.if.uz.zgora.pl/~difrost/linux-next/09042008/
> 
> ah, that again comes from x86/for-akpm missing a patch that comes later 
> in x86/latest. I'll resort it.

X86_VM_MASK was already changed in one place in kernel/traps_32.c:
  arch/x86/kernel/traps_32.c:502:    if (regs->flags & X86_VM_MASK) {
and in mm/fault.c:
  if (regs->flags & (X86_EFLAGS_IF | X86_VM_MASK))

-Jacek

Re: linux-next: Tree for April 9

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> > Yep, I did the same. You can find patch, which renames changes 
> > VM_MASK to X86_VM_MASK across all files in arch/x86/kernel, here: 
> > http://pin.if.uz.zgora.pl/~difrost/linux-next/09042008/
> 
> ah, that again comes from x86/for-akpm missing a patch that comes 
> later in x86/latest. I'll resort it.

done, i've pushed out that reordering into x86.git.

	Ingo

Re: linux-next: Tree for April 9

[Cyrill Gorcunov]

[Ingo Molnar - Wed, Apr 09, 2008 at 01:31:09PM +0200]
| 
| * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
| 
| > Hi Jacek,
| > 
| > On Wed, 9 Apr 2008 21:09:36 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
| > >
| > > Thanks for the report, can you please send us your .config, please?
| > 
| > Don't worry about it, I found the problem.
| > 
| > It seems that commit 883a9fc4e5d9b0701f15d4e5a23608f942104721 ("x86: 
| > cleanup - rename VM_MASK to X86_VM_MASK") from the x86 tree seems to 
| > have missed some places.
| 
| i think what happened is that some changes came in from other trees that 
| reintroduced the old symbols?

actually, that is the only explanation I could find. The last time I sent
you patches to fixup *all* VM_MASK (wich were grep'ed on *latest branch over
*all* sources inside x86). So this all were settled down by a few of my
patches and /for shame on me/ yours fixups. So these fixups were missed
on merging.

| 
| if that's the case i'll add back the old symbol names to make the 
| transition and integration easier.
| 
| 	Ingo
| 
		- Cyrill -

Re: linux-next: Tree for April 9

[Ingo Molnar]

* Cyrill Gorcunov <gorcunov@gmail.com> wrote:

> | > It seems that commit 883a9fc4e5d9b0701f15d4e5a23608f942104721 
> | > ("x86: cleanup - rename VM_MASK to X86_VM_MASK") from the x86 tree 
> | > seems to have missed some places.
> | 
> | i think what happened is that some changes came in from other trees 
> | that reintroduced the old symbols?
> 
> actually, that is the only explanation I could find. The last time I 
> sent you patches to fixup *all* VM_MASK (wich were grep'ed on *latest 
> branch over *all* sources inside x86). So this all were settled down 
> by a few of my patches and /for shame on me/ yours fixups. So these 
> fixups were missed on merging.

no, the problem turned out to be that i kept those fixes too spread out, 
and part of them went into the x86/for-akpm portion of the tree, part of 
it went into x86/testing. Since all x86 developers work against 
x86/testing this was never a problem - only now did it become one when i 
shuffled patches and branch boundaries around. Such problems will go 
away once linux-next starts using x86/testing as well. In any case i 
moved your fixes together and fixed up the patch ordering as well.

	Ingo

Re: linux-next: Tree for April 9

[Cyrill Gorcunov]

[Ingo Molnar - Wed, Apr 09, 2008 at 05:03:33PM +0200]
| 
| * Cyrill Gorcunov <gorcunov@gmail.com> wrote:
| 
| > | > It seems that commit 883a9fc4e5d9b0701f15d4e5a23608f942104721 
| > | > ("x86: cleanup - rename VM_MASK to X86_VM_MASK") from the x86 tree 
| > | > seems to have missed some places.
| > | 
| > | i think what happened is that some changes came in from other trees 
| > | that reintroduced the old symbols?
| > 
| > actually, that is the only explanation I could find. The last time I 
| > sent you patches to fixup *all* VM_MASK (wich were grep'ed on *latest 
| > branch over *all* sources inside x86). So this all were settled down 
| > by a few of my patches and /for shame on me/ yours fixups. So these 
| > fixups were missed on merging.
| 
| no, the problem turned out to be that i kept those fixes too spread out, 
| and part of them went into the x86/for-akpm portion of the tree, part of 
| it went into x86/testing. Since all x86 developers work against 
| x86/testing this was never a problem - only now did it become one when i 
| shuffled patches and branch boundaries around. Such problems will go 
| away once linux-next starts using x86/testing as well. In any case i 
| moved your fixes together and fixed up the patch ordering as well.
| 
| 	Ingo
| 

ok, i see, thanks

		- Cyrill -

Re: linux-next: Tree for April 9

[Stefan Richter]

Stephen Rothwell wrote:
> There were a few merge conflicts (fairly trivial) and couple of build
> failures (notified).  There is a know build failure with powerpc
> allyesconfig.  Below is a summary of the state of the merge.
...
> Merging ieee1394/for-next
> CONFLICT (content): Merge conflict in lib/Kconfig.debug

Would it be safe for me (and preferred by you) to merge sched/for-akpm
into ieee1394/for-next to resolve this conflict until next mainline merge?
-- 
Stefan Richter
-=====-==--- -=-- -=--=
http://arcgraph.de/sr/

Re: linux-next: Tree for April 9

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

Hi Stefan,

On Wed, 09 Apr 2008 18:55:42 +0200 Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
>
> Stephen Rothwell wrote:
> > There were a few merge conflicts (fairly trivial) and couple of build
> > failures (notified).  There is a know build failure with powerpc
> > allyesconfig.  Below is a summary of the state of the merge.
> ...
> > Merging ieee1394/for-next
> > CONFLICT (content): Merge conflict in lib/Kconfig.debug
> 
> Would it be safe for me (and preferred by you) to merge sched/for-akpm
> into ieee1394/for-next to resolve this conflict until next mainline merge?

Actually, no, as sched/for-akpm gets rebased sometimes.  I only have to
fix these trivial conflicts once as "git rerere" remembers the fix for me
and they are so trivial that Linus will probably fix them the same way
when he finally merges your tree.  Also, there is the possibility that he
will merge your tree before sched/for-akpm ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: linux-next: Tree for April 9

[Ingo Molnar]

* Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:

> Stephen Rothwell wrote:
> > There were a few merge conflicts (fairly trivial) and couple of build
> > failures (notified).  There is a know build failure with powerpc
> > allyesconfig.  Below is a summary of the state of the merge.
> ...
> > Merging ieee1394/for-next
> > CONFLICT (content): Merge conflict in lib/Kconfig.debug
> 
> Would it be safe for me (and preferred by you) to merge sched/for-akpm 
> into ieee1394/for-next to resolve this conflict until next mainline 
> merge?

what type of conflict do you have there? If it's a new entry then you 
might be able to fix it by moving the new entry elsewhere in the file. 
Or if i introduced a new entry close to an existing entry you modify 
then i could move my new entry elsewhere.

	Ingo

Re: linux-next: Tree for April 9

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

On Thu, 10 Apr 2008 08:52:27 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> what type of conflict do you have there? If it's a new entry then you 
> might be able to fix it by moving the new entry elsewhere in the file. 
> Or if i introduced a new entry close to an existing entry you modify 
> then i could move my new entry elsewhere.

Commit 523a65f1a7a339e528ca6d6d808516fe195fde03 ("firewire: fw-ohci: add
option for remote debugging") in the ieee1394 tree adds a new entry just
where the sched tree adds

source kernel/trace/Kconfig

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

debug Kconfig option (was Re: linux-next: Tree for April 9)

[Stefan Richter]

On 10 Apr, Stephen Rothwell wrote:
> On Thu, 10 Apr 2008 08:52:27 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>>
>> what type of conflict do you have there? If it's a new entry then you 
>> might be able to fix it by moving the new entry elsewhere in the file. 
>> Or if i introduced a new entry close to an existing entry you modify 
>> then i could move my new entry elsewhere.
> 
> Commit 523a65f1a7a339e528ca6d6d808516fe195fde03 ("firewire: fw-ohci: add
> option for remote debugging") in the ieee1394 tree adds a new entry just
> where the sched tree adds
> 
> source kernel/trace/Kconfig
> 

I grab this opportunity to ask the list:  Would you prefer the remote
debugging option in the kernel hacking menu (as in the commit), or
rather in the respective driver submenu?

For reference:

Date: Thu, 28 Feb 2008 20:54:43 +0100 (CET)
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
Subject: firewire: fw-ohci: add option for remote debugging

This way firewire-ohci can be used for remote debugging like ohci1394.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
 Documentation/debugging-via-ohci1394.txt |   13 ++++++++-----
 drivers/firewire/fw-ohci.c               |    9 +++++++++
 lib/Kconfig.debug                        |   10 ++++++++++
 3 files changed, 27 insertions(+), 5 deletions(-)

Index: linux/Documentation/debugging-via-ohci1394.txt
===================================================================
--- linux.orig/Documentation/debugging-via-ohci1394.txt
+++ linux/Documentation/debugging-via-ohci1394.txt
@@ -41,11 +41,14 @@ to a working state and enables physical 
 This can be turned off by ohci1394's module parameter phys_dma=0.
 
 The alternative firewire-ohci driver in drivers/firewire uses filtered physical
-DMA, hence is not yet suitable for remote debugging.
-
-Because ohci1394 depends on the PCI enumeration to be completed, an
-initialization routine which runs pretty early (long before console_init()
-which makes the printk buffer appear on the console can be called) was written.
+DMA by default, which is more secure but not suitable for remote debugging.
+Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA to get unfiltered
+physical DMA.
+
+Because ohci1394 and firewire-ohci depend on the PCI enumeration to be
+completed, an initialization routine which runs pretty early has been
+implemented for x86.  This routine runs long before console_init() can be
+called, i.e. before the printk buffer appears on the console.
 
 To activate it, enable CONFIG_PROVIDE_OHCI1394_DMA_INIT (Kernel hacking menu:
 Provide code for enabling DMA over FireWire early on boot) and pass the
Index: linux/drivers/firewire/fw-ohci.c
===================================================================
--- linux.orig/drivers/firewire/fw-ohci.c
+++ linux/drivers/firewire/fw-ohci.c
@@ -1097,6 +1097,11 @@ static void bus_reset_tasklet(unsigned l
 		reg_write(ohci, OHCI1394_ConfigROMhdr, ohci->next_header);
 	}
 
+#ifdef CONFIG_FIREWIRE_OHCI_REMOTE_DMA
+	reg_write(ohci, OHCI1394_PhyReqFilterHiSet, ~0);
+	reg_write(ohci, OHCI1394_PhyReqFilterLoSet, ~0);
+#endif
+
 	spin_unlock_irqrestore(&ohci->lock, flags);
 
 	if (free_rom)
@@ -1435,6 +1440,9 @@ static int ohci_cancel_packet(struct fw_
 static int
 ohci_enable_phys_dma(struct fw_card *card, int node_id, int generation)
 {
+#ifdef CONFIG_FIREWIRE_OHCI_REMOTE_DMA
+	return 0;
+#else
 	struct fw_ohci *ohci = fw_ohci(card);
 	unsigned long flags;
 	int n, retval = 0;
@@ -1466,6 +1474,7 @@ ohci_enable_phys_dma(struct fw_card *car
  out:
 	spin_unlock_irqrestore(&ohci->lock, flags);
 	return retval;
+#endif /* CONFIG_FIREWIRE_OHCI_REMOTE_DMA */
 }
 
 static u64
Index: linux/lib/Kconfig.debug
===================================================================
--- linux.orig/lib/Kconfig.debug
+++ linux/lib/Kconfig.debug
@@ -592,6 +592,16 @@ config LATENCYTOP
 	  Enable this option if you want to use the LatencyTOP tool
 	  to find out which userspace is blocking on what kernel operations.
 
+config FIREWIRE_OHCI_REMOTE_DMA
+	bool "Remote debugging via firewire-ohci"
+	depends on FIREWIRE_OHCI
+	help
+	  This option lets you use the FireWire bus for remote debugging.
+	  It enables unfiltered remote DMA in the firewire-ohci driver.
+	  See Documentation/debugging-via-ohci1394.txt for more information.
+
+	  If unsure, say N.
+
 config PROVIDE_OHCI1394_DMA_INIT
 	bool "Provide code for enabling DMA over FireWire early on boot"
 	depends on PCI && X86

-- 
Stefan Richter
-=====-==--- -=-- -=-=-
http://arcgraph.de/sr/

[BUG] linux-next: Tree for April 9 warning on CC_STACKPROTECTOR, followed by kernel panic

[Kamalesh Babulal]

Hi Stephen,

The next-20080409 kernel warns while booting up on a x86_64 machine.
When compiled the kernel with CONFIG_CC_STACKPROTECTOR=y, the warning
is followed by the kernel panic.

Testing -fstack-protector-all feature
No -fstack-protector-stack-frame!
-fstack-protector-all test failed
------------[ cut here ]------------
WARNING: at kernel/panic.c:365 __stack_chk_test+0x4b/0x50()
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.25-rc8-next-20080409-autotest #1

Call Trace:
 [<ffffffff80231f5e>] warn_on_slowpath+0x51/0x63
 [<ffffffff80232d93>] printk+0x4e/0x56
 [<ffffffff80382fcd>] extract_entropy+0x47/0x90
 [<ffffffff80230000>] dup_mm+0xca/0x3fd
 [<ffffffff80231eba>] __stack_chk_test_func+0x21/0x32
 [<ffffffff80231fbb>] __stack_chk_test+0x4b/0x50
 [<ffffffff808ba8f1>] kernel_init+0x189/0x2f9
 [<ffffffff804ee221>] _spin_unlock_irq+0x9/0xc
 [<ffffffff8020cb88>] child_rip+0xa/0x12
 [<ffffffff808ba768>] kernel_init+0x0/0x2f9
 [<ffffffff8020cb7e>] child_rip+0x0/0x12

---[ end trace d88d2f3a71e3b32c ]---
Freeing unused kernel memory: 368k freed
Write protecting the kernel read-only data: 4188k
BUG: unable to handle kernel NULL pointer dereference at 00000000000002e8
IP: [<ffffffff80286c11>] kmem_cache_alloc+0x19/0x6b
PGD 3e925067 PUD 3e924067 PMD 0 
Oops: 0000 [1] SMP 
last sysfs file: 
CPU 0 
Modules linked in:
Pid: 1, comm: init Not tainted 2.6.25-rc8-next-20080409-autotest #1
RIP: 0010:[<ffffffff80286c11>]  [<ffffffff80286c11>] kmem_cache_alloc+0x19/0x6b
RSP: 0000:ffff81003f9c9f08  EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff80211f7e
RDX: 00007fff1f89e710 RSI: 00000000000000d0 RDI: 0000000000000000
RBP: 00007fff1f89e6f8 R08: 000000000065e300 R09: 000000000065e2e8
R10: 000000000066d800 R11: 0000000000000203 R12: 00000000000000d0
R13: 000000000047c290 R14: 000000000047c250 R15: 0000000000000000
FS:  000000000066d870(0063) GS:ffffffff8067a000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000000002e8 CR3: 000000003e921000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process init (pid: 1, threadinfo ffff81003f9c8000, task ffff81003f9c6000)
Stack:  ffff81003f9c6000 00007fff1f89e6f8 0000000000000002 ffffffff80211f7e
 ffff81003e920060 ffffffff8033419c ffff81003f9c6000 ffffffff8020d96a
 0000000000000000 ffffffff804ee379 0000000000000000 000000000047c250
Call Trace:
 [<ffffffff80211f7e>] ? init_fpu+0x88/0xc9
 [<ffffffff8033419c>] ? __up_read+0x13/0x8a
 [<ffffffff8020d96a>] ? math_state_restore+0x19/0x5a
 [<ffffffff804ee379>] ? error_exit+0x0/0x51


Code: 4b 18 31 c0 48 89 f7 fc f3 aa 5b 5d 41 5c 48 89 f0 c3 41 54 41 89 f4 55 53 48 8b 4c 24 18 9c 5b fa 65 8b 04 25 24 00 00 00 48 98 <48> 8b ac c7 e8 02 00 00 48 8b 55 00 48 85 d2 75 10 83 ca ff 49 
RIP  [<ffffffff80286c11>] kmem_cache_alloc+0x19/0x6b
 RSP <ffff81003f9c9f08>
CR2: 00000000000002e8
---[ end trace d88d2f3a71e3b32c ]---
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: init Tainted: G      D  2.6.25-rc8-next-20080409-autotest #1

Call Trace:
 [<ffffffff8023225d>] panic+0x86/0x144
 [<ffffffff80251911>] kallsyms_lookup+0x49/0x80
 [<ffffffff80286c11>] kmem_cache_alloc+0x19/0x6b
 [<ffffffff80232d93>] printk+0x4e/0x56
 [<ffffffff80232d93>] printk+0x4e/0x56
 [<ffffffff802351c9>] do_exit+0x71/0x682
 [<ffffffff804ee731>] oops_begin+0x0/0x8c
 [<ffffffff804f058d>] do_page_fault+0x738/0x7f3
 [<ffffffff804ee379>] error_exit+0x0/0x51
 [<ffffffff80211f7e>] init_fpu+0x88/0xc9
 [<ffffffff80286c11>] kmem_cache_alloc+0x19/0x6b
 [<ffffffff80211f7e>] init_fpu+0x88/0xc9
 [<ffffffff8033419c>] __up_read+0x13/0x8a
 [<ffffffff8020d96a>] math_state_restore+0x19/0x5a
 [<ffffffff804ee379>] error_exit+0x0/0x51

-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

Re: linux-next: Tree for April 9

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> On Thu, 10 Apr 2008 08:52:27 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> >
> > what type of conflict do you have there? If it's a new entry then 
> > you might be able to fix it by moving the new entry elsewhere in the 
> > file. Or if i introduced a new entry close to an existing entry you 
> > modify then i could move my new entry elsewhere.
> 
> Commit 523a65f1a7a339e528ca6d6d808516fe195fde03 ("firewire: fw-ohci: 
> add option for remote debugging") in the ieee1394 tree adds a new 
> entry just where the sched tree adds
> 
> source kernel/trace/Kconfig

hm, i think in this specific case the new firewire entry should be added 
after the PROVIDE_OHCI1394_DMA_INIT section. (that's how we extend 
groups of Kconfig entries anyway) The new trace entries in the scheduler 
tree follow that pattern and add the new kernel/trace/Kconfig at the 
right place. So if the firewire entry is added that way this conflict 
could be avoided.

	Ingo

Re: debug Kconfig option (was Re: linux-next: Tree for April 9)

[Ingo Molnar]

* Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:

> > Commit 523a65f1a7a339e528ca6d6d808516fe195fde03 ("firewire: fw-ohci: 
> > add option for remote debugging") in the ieee1394 tree adds a new 
> > entry just where the sched tree adds
> > 
> > source kernel/trace/Kconfig
> 
> I grab this opportunity to ask the list: Would you prefer the remote 
> debugging option in the kernel hacking menu (as in the commit), or 
> rather in the respective driver submenu?

it's great stuff! I very much think it's fine in lib/Kconfig.debug - we 
need prominence of debugging options. (they are used way too 
infrequently)

My only suggestion would be to move the new entry below the existing 
firewire entry (PROVIDE_OHCI1394_DMA_INIT) there - which also happens to 
avoid this particular merge conflict.

	Ingo

Re: [BUG] linux-next: Tree for April 9 warning on CC_STACKPROTECTOR, followed by kernel panic

[Jacek Luczak]

Kamalesh Babulal pisze:
> Hi Stephen,
> 
> The next-20080409 kernel warns while booting up on a x86_64 machine.
> When compiled the kernel with CONFIG_CC_STACKPROTECTOR=y, the warning
> is followed by the kernel panic.
> 
> Testing -fstack-protector-all feature
> No -fstack-protector-stack-frame!
> -fstack-protector-all test failed
> ------------[ cut here ]------------
> WARNING: at kernel/panic.c:365 __stack_chk_test+0x4b/0x50()
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 2.6.25-rc8-next-20080409-autotest #1
> 
> Call Trace:
>  [<ffffffff80231f5e>] warn_on_slowpath+0x51/0x63
>  [<ffffffff80232d93>] printk+0x4e/0x56
>  [<ffffffff80382fcd>] extract_entropy+0x47/0x90
>  [<ffffffff80230000>] dup_mm+0xca/0x3fd
>  [<ffffffff80231eba>] __stack_chk_test_func+0x21/0x32
>  [<ffffffff80231fbb>] __stack_chk_test+0x4b/0x50
>  [<ffffffff808ba8f1>] kernel_init+0x189/0x2f9
>  [<ffffffff804ee221>] _spin_unlock_irq+0x9/0xc
>  [<ffffffff8020cb88>] child_rip+0xa/0x12
>  [<ffffffff808ba768>] kernel_init+0x0/0x2f9
>  [<ffffffff8020cb7e>] child_rip+0x0/0x12
> 
> ---[ end trace d88d2f3a71e3b32c ]---

Hi,

what version of GCC are you using?

-Jacek

Re: [BUG] linux-next: Tree for April 9 warning on CC_STACKPROTECTOR, followed by kernel panic

[Kamalesh Babulal]

Jacek Luczak wrote:
> Kamalesh Babulal pisze:
>> Hi Stephen,
>>
>> The next-20080409 kernel warns while booting up on a x86_64 machine.
>> When compiled the kernel with CONFIG_CC_STACKPROTECTOR=y, the warning
>> is followed by the kernel panic.
>>
>> Testing -fstack-protector-all feature
>> No -fstack-protector-stack-frame!
>> -fstack-protector-all test failed
>> ------------[ cut here ]------------
>> WARNING: at kernel/panic.c:365 __stack_chk_test+0x4b/0x50()
>> Modules linked in:
>> Pid: 1, comm: swapper Not tainted 2.6.25-rc8-next-20080409-autotest #1
>>
>> Call Trace:
>>  [<ffffffff80231f5e>] warn_on_slowpath+0x51/0x63
>>  [<ffffffff80232d93>] printk+0x4e/0x56
>>  [<ffffffff80382fcd>] extract_entropy+0x47/0x90
>>  [<ffffffff80230000>] dup_mm+0xca/0x3fd
>>  [<ffffffff80231eba>] __stack_chk_test_func+0x21/0x32
>>  [<ffffffff80231fbb>] __stack_chk_test+0x4b/0x50
>>  [<ffffffff808ba8f1>] kernel_init+0x189/0x2f9
>>  [<ffffffff804ee221>] _spin_unlock_irq+0x9/0xc
>>  [<ffffffff8020cb88>] child_rip+0xa/0x12
>>  [<ffffffff808ba768>] kernel_init+0x0/0x2f9
>>  [<ffffffff8020cb7e>] child_rip+0x0/0x12
>>
>> ---[ end trace d88d2f3a71e3b32c ]---
> 
> Hi,
> 
> what version of GCC are you using?
> 
> -Jacek
Hi Jacek,

I use the gcc version (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)

-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

Re: [BUG] linux-next: Tree for April 9 warning on CC_STACKPROTECTOR, followed by kernel panic

[Jacek Luczak]

Kamalesh Babulal pisze:
> Jacek Luczak wrote:
>> Kamalesh Babulal pisze:
>>> Hi Stephen,
>>>
>>> The next-20080409 kernel warns while booting up on a x86_64 machine.
>>> When compiled the kernel with CONFIG_CC_STACKPROTECTOR=y, the warning
>>> is followed by the kernel panic.
>>>
>>> Testing -fstack-protector-all feature
>>> No -fstack-protector-stack-frame!
>>> -fstack-protector-all test failed
>>> ------------[ cut here ]------------
>>> WARNING: at kernel/panic.c:365 __stack_chk_test+0x4b/0x50()
>>> Modules linked in:
>>> Pid: 1, comm: swapper Not tainted 2.6.25-rc8-next-20080409-autotest #1
>>>
>>> Call Trace:
>>>  [<ffffffff80231f5e>] warn_on_slowpath+0x51/0x63
>>>  [<ffffffff80232d93>] printk+0x4e/0x56
>>>  [<ffffffff80382fcd>] extract_entropy+0x47/0x90
>>>  [<ffffffff80230000>] dup_mm+0xca/0x3fd
>>>  [<ffffffff80231eba>] __stack_chk_test_func+0x21/0x32
>>>  [<ffffffff80231fbb>] __stack_chk_test+0x4b/0x50
>>>  [<ffffffff808ba8f1>] kernel_init+0x189/0x2f9
>>>  [<ffffffff804ee221>] _spin_unlock_irq+0x9/0xc
>>>  [<ffffffff8020cb88>] child_rip+0xa/0x12
>>>  [<ffffffff808ba768>] kernel_init+0x0/0x2f9
>>>  [<ffffffff8020cb7e>] child_rip+0x0/0x12
>>>
>>> ---[ end trace d88d2f3a71e3b32c ]---
>> Hi,
>>
>> what version of GCC are you using?
>>
>> -Jacek
> Hi Jacek,
> 
> I use the gcc version (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)

IMO it's GCC problem (I've seen a lot of problems with stack-protector and GCC 4.1 branch). Can you make some tests with 
4.2 branch?

-Jacek
-Jacek

Re: [BUG] linux-next: Tree for April 9 warning on CC_STACKPROTECTOR, followed by kernel panic

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4376 bytes --]

CC to Ingo ...

On Thu, 10 Apr 2008 15:09:17 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
> Hi Stephen,
> 
> The next-20080409 kernel warns while booting up on a x86_64 machine.
> When compiled the kernel with CONFIG_CC_STACKPROTECTOR=y, the warning
> is followed by the kernel panic.
> 
> Testing -fstack-protector-all feature
> No -fstack-protector-stack-frame!
> -fstack-protector-all test failed
> ------------[ cut here ]------------
> WARNING: at kernel/panic.c:365 __stack_chk_test+0x4b/0x50()
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 2.6.25-rc8-next-20080409-autotest #1
> 
> Call Trace:
>  [<ffffffff80231f5e>] warn_on_slowpath+0x51/0x63
>  [<ffffffff80232d93>] printk+0x4e/0x56
>  [<ffffffff80382fcd>] extract_entropy+0x47/0x90
>  [<ffffffff80230000>] dup_mm+0xca/0x3fd
>  [<ffffffff80231eba>] __stack_chk_test_func+0x21/0x32
>  [<ffffffff80231fbb>] __stack_chk_test+0x4b/0x50
>  [<ffffffff808ba8f1>] kernel_init+0x189/0x2f9
>  [<ffffffff804ee221>] _spin_unlock_irq+0x9/0xc
>  [<ffffffff8020cb88>] child_rip+0xa/0x12
>  [<ffffffff808ba768>] kernel_init+0x0/0x2f9
>  [<ffffffff8020cb7e>] child_rip+0x0/0x12
> 
> ---[ end trace d88d2f3a71e3b32c ]---
> Freeing unused kernel memory: 368k freed
> Write protecting the kernel read-only data: 4188k
> BUG: unable to handle kernel NULL pointer dereference at 00000000000002e8
> IP: [<ffffffff80286c11>] kmem_cache_alloc+0x19/0x6b
> PGD 3e925067 PUD 3e924067 PMD 0 
> Oops: 0000 [1] SMP 
> last sysfs file: 
> CPU 0 
> Modules linked in:
> Pid: 1, comm: init Not tainted 2.6.25-rc8-next-20080409-autotest #1
> RIP: 0010:[<ffffffff80286c11>]  [<ffffffff80286c11>] kmem_cache_alloc+0x19/0x6b
> RSP: 0000:ffff81003f9c9f08  EFLAGS: 00010046
> RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff80211f7e
> RDX: 00007fff1f89e710 RSI: 00000000000000d0 RDI: 0000000000000000
> RBP: 00007fff1f89e6f8 R08: 000000000065e300 R09: 000000000065e2e8
> R10: 000000000066d800 R11: 0000000000000203 R12: 00000000000000d0
> R13: 000000000047c290 R14: 000000000047c250 R15: 0000000000000000
> FS:  000000000066d870(0063) GS:ffffffff8067a000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00000000000002e8 CR3: 000000003e921000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process init (pid: 1, threadinfo ffff81003f9c8000, task ffff81003f9c6000)
> Stack:  ffff81003f9c6000 00007fff1f89e6f8 0000000000000002 ffffffff80211f7e
>  ffff81003e920060 ffffffff8033419c ffff81003f9c6000 ffffffff8020d96a
>  0000000000000000 ffffffff804ee379 0000000000000000 000000000047c250
> Call Trace:
>  [<ffffffff80211f7e>] ? init_fpu+0x88/0xc9
>  [<ffffffff8033419c>] ? __up_read+0x13/0x8a
>  [<ffffffff8020d96a>] ? math_state_restore+0x19/0x5a
>  [<ffffffff804ee379>] ? error_exit+0x0/0x51
> 
> 
> Code: 4b 18 31 c0 48 89 f7 fc f3 aa 5b 5d 41 5c 48 89 f0 c3 41 54 41 89 f4 55 53 48 8b 4c 24 18 9c 5b fa 65 8b 04 25 24 00 00 00 48 98 <48> 8b ac c7 e8 02 00 00 48 8b 55 00 48 85 d2 75 10 83 ca ff 49 
> RIP  [<ffffffff80286c11>] kmem_cache_alloc+0x19/0x6b
>  RSP <ffff81003f9c9f08>
> CR2: 00000000000002e8
> ---[ end trace d88d2f3a71e3b32c ]---
> Kernel panic - not syncing: Attempted to kill init!
> Pid: 1, comm: init Tainted: G      D  2.6.25-rc8-next-20080409-autotest #1
> 
> Call Trace:
>  [<ffffffff8023225d>] panic+0x86/0x144
>  [<ffffffff80251911>] kallsyms_lookup+0x49/0x80
>  [<ffffffff80286c11>] kmem_cache_alloc+0x19/0x6b
>  [<ffffffff80232d93>] printk+0x4e/0x56
>  [<ffffffff80232d93>] printk+0x4e/0x56
>  [<ffffffff802351c9>] do_exit+0x71/0x682
>  [<ffffffff804ee731>] oops_begin+0x0/0x8c
>  [<ffffffff804f058d>] do_page_fault+0x738/0x7f3
>  [<ffffffff804ee379>] error_exit+0x0/0x51
>  [<ffffffff80211f7e>] init_fpu+0x88/0xc9
>  [<ffffffff80286c11>] kmem_cache_alloc+0x19/0x6b
>  [<ffffffff80211f7e>] init_fpu+0x88/0xc9
>  [<ffffffff8033419c>] __up_read+0x13/0x8a
>  [<ffffffff8020d96a>] math_state_restore+0x19/0x5a
>  [<ffffffff804ee379>] error_exit+0x0/0x51
> 
> -- 
> Thanks & Regards,
> Kamalesh Babulal,
> Linux Technology Center,
> IBM, ISTL.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: debug Kconfig option (was Re: linux-next: Tree for April 9)

[Randy Dunlap]

On Thu, 10 Apr 2008 09:52:25 +0200 (CEST) Stefan Richter wrote:

> On 10 Apr, Stephen Rothwell wrote:
> > On Thu, 10 Apr 2008 08:52:27 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> >>
> >> what type of conflict do you have there? If it's a new entry then you 
> >> might be able to fix it by moving the new entry elsewhere in the file. 
> >> Or if i introduced a new entry close to an existing entry you modify 
> >> then i could move my new entry elsewhere.
> > 
> > Commit 523a65f1a7a339e528ca6d6d808516fe195fde03 ("firewire: fw-ohci: add
> > option for remote debugging") in the ieee1394 tree adds a new entry just
> > where the sched tree adds
> > 
> > source kernel/trace/Kconfig
> > 
> 
> I grab this opportunity to ask the list:  Would you prefer the remote
> debugging option in the kernel hacking menu (as in the commit), or
> rather in the respective driver submenu?

I like it in the kernel hacking menu.

> For reference:
> 
> Date: Thu, 28 Feb 2008 20:54:43 +0100 (CET)
> From: Stefan Richter <stefanr@s5r6.in-berlin.de>
> Subject: firewire: fw-ohci: add option for remote debugging
> 
> This way firewire-ohci can be used for remote debugging like ohci1394.
> 
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
> ---
>  Documentation/debugging-via-ohci1394.txt |   13 ++++++++-----
>  drivers/firewire/fw-ohci.c               |    9 +++++++++
>  lib/Kconfig.debug                        |   10 ++++++++++
>  3 files changed, 27 insertions(+), 5 deletions(-)
> 
> Index: linux/Documentation/debugging-via-ohci1394.txt
> ===================================================================
> --- linux.orig/Documentation/debugging-via-ohci1394.txt
> +++ linux/Documentation/debugging-via-ohci1394.txt
> @@ -41,11 +41,14 @@ to a working state and enables physical 
>  This can be turned off by ohci1394's module parameter phys_dma=0.
>  
>  The alternative firewire-ohci driver in drivers/firewire uses filtered physical
> -DMA, hence is not yet suitable for remote debugging.
> -
> -Because ohci1394 depends on the PCI enumeration to be completed, an
> -initialization routine which runs pretty early (long before console_init()
> -which makes the printk buffer appear on the console can be called) was written.
> +DMA by default, which is more secure but not suitable for remote debugging.
> +Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA to get unfiltered
> +physical DMA.
> +
> +Because ohci1394 and firewire-ohci depend on the PCI enumeration to be
> +completed, an initialization routine which runs pretty early has been
> +implemented for x86.  This routine runs long before console_init() can be
> +called, i.e. before the printk buffer appears on the console.
>  
>  To activate it, enable CONFIG_PROVIDE_OHCI1394_DMA_INIT (Kernel hacking menu:
>  Provide code for enabling DMA over FireWire early on boot) and pass the
> Index: linux/drivers/firewire/fw-ohci.c
> ===================================================================
> --- linux.orig/drivers/firewire/fw-ohci.c
> +++ linux/drivers/firewire/fw-ohci.c
> @@ -1097,6 +1097,11 @@ static void bus_reset_tasklet(unsigned l
>  		reg_write(ohci, OHCI1394_ConfigROMhdr, ohci->next_header);
>  	}
>  
> +#ifdef CONFIG_FIREWIRE_OHCI_REMOTE_DMA
> +	reg_write(ohci, OHCI1394_PhyReqFilterHiSet, ~0);
> +	reg_write(ohci, OHCI1394_PhyReqFilterLoSet, ~0);
> +#endif
> +
>  	spin_unlock_irqrestore(&ohci->lock, flags);
>  
>  	if (free_rom)
> @@ -1435,6 +1440,9 @@ static int ohci_cancel_packet(struct fw_
>  static int
>  ohci_enable_phys_dma(struct fw_card *card, int node_id, int generation)
>  {
> +#ifdef CONFIG_FIREWIRE_OHCI_REMOTE_DMA
> +	return 0;
> +#else
>  	struct fw_ohci *ohci = fw_ohci(card);
>  	unsigned long flags;
>  	int n, retval = 0;
> @@ -1466,6 +1474,7 @@ ohci_enable_phys_dma(struct fw_card *car
>   out:
>  	spin_unlock_irqrestore(&ohci->lock, flags);
>  	return retval;
> +#endif /* CONFIG_FIREWIRE_OHCI_REMOTE_DMA */
>  }
>  
>  static u64
> Index: linux/lib/Kconfig.debug
> ===================================================================
> --- linux.orig/lib/Kconfig.debug
> +++ linux/lib/Kconfig.debug
> @@ -592,6 +592,16 @@ config LATENCYTOP
>  	  Enable this option if you want to use the LatencyTOP tool
>  	  to find out which userspace is blocking on what kernel operations.
>  
> +config FIREWIRE_OHCI_REMOTE_DMA
> +	bool "Remote debugging via firewire-ohci"
> +	depends on FIREWIRE_OHCI
> +	help
> +	  This option lets you use the FireWire bus for remote debugging.
> +	  It enables unfiltered remote DMA in the firewire-ohci driver.
> +	  See Documentation/debugging-via-ohci1394.txt for more information.
> +
> +	  If unsure, say N.
> +
>  config PROVIDE_OHCI1394_DMA_INIT
>  	bool "Provide code for enabling DMA over FireWire early on boot"
>  	depends on PCI && X86
> 
> -- 

---
~Randy

Re: linux-next: Tree for April 9

[Stefan Richter]

Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
>> On Thu, 10 Apr 2008 08:52:27 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>> >
>> > what type of conflict do you have there? If it's a new entry then 
>> > you might be able to fix it by moving the new entry elsewhere in the 
>> > file. Or if i introduced a new entry close to an existing entry you 
>> > modify then i could move my new entry elsewhere.
>> 
>> Commit 523a65f1a7a339e528ca6d6d808516fe195fde03 ("firewire: fw-ohci: 
>> add option for remote debugging") in the ieee1394 tree adds a new 
>> entry just where the sched tree adds
>> 
>> source kernel/trace/Kconfig
> 
> hm, i think in this specific case the new firewire entry should be added 
> after the PROVIDE_OHCI1394_DMA_INIT section. (that's how we extend 
> groups of Kconfig entries anyway) The new trace entries in the scheduler 
> tree follow that pattern and add the new kernel/trace/Kconfig at the 
> right place. So if the firewire entry is added that way this conflict 
> could be avoided.

Indeed, this order of the two options looks more logical now that you
say it.  Update patch will appear on LKML in a minute.

Stephen will still have a conflict in lib/Kconfig.debug when merging the
tests tree, but this happens regardless what we two do because tests is
based on 2.6.25-rc1, and mainline Kconfig.debug has changes post -rc1.
-- 
Stefan Richter
-=====-==--- -=-- -=-=-
http://arcgraph.de/sr/

[PATCH linux1394-2.6.git] firewire: fw-ohci: add option for remote debugging - amendment

[Stefan Richter]

Some afterthoughts:

  - Tell where the Kconfig prompt is in debugging-via-ohci1394.txt.

  - Open the physical DMA filter in the top half of the IRQ handler
    and flush the necessary MMIO writes.  This is to open the filter
    as soon as possible after bus reset.

  - Move the Kconfig prompt below the existing early debugging option.
    Seems more logical after all, because that one is for early use
    and this one for subsequent use.

  - Reword the existing early debugging option to state what it is for
    rather than how it works internally.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---

This could be merged into patch "firewire: fw-ohci: add option for
remote debugging" before it is submitted to mainline.

 Documentation/debugging-via-ohci1394.txt |    9 +++++----
 drivers/firewire/fw-ohci.c               |   13 +++++++------
 lib/Kconfig.debug                        |   23 ++++++++++++-----------
 3 files changed, 24 insertions(+), 21 deletions(-)

Index: linux/Documentation/debugging-via-ohci1394.txt
===================================================================
--- linux.orig/Documentation/debugging-via-ohci1394.txt
+++ linux/Documentation/debugging-via-ohci1394.txt
@@ -42,8 +42,9 @@ This can be turned off by ohci1394's mod
 
 The alternative firewire-ohci driver in drivers/firewire uses filtered physical
 DMA by default, which is more secure but not suitable for remote debugging.
-Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA to get unfiltered
-physical DMA.
+Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA (Kernel hacking menu:
+Remote debugging over FireWire with firewire-ohci) to get unfiltered physical
+DMA.
 
 Because ohci1394 and firewire-ohci depend on the PCI enumeration to be
 completed, an initialization routine which runs pretty early has been
@@ -51,8 +52,8 @@ implemented for x86.  This routine runs 
 called, i.e. before the printk buffer appears on the console.
 
 To activate it, enable CONFIG_PROVIDE_OHCI1394_DMA_INIT (Kernel hacking menu:
-Provide code for enabling DMA over FireWire early on boot) and pass the
-parameter "ohci1394_dma=early" to the recompiled kernel on boot.
+Remote debugging over FireWire early on boot) and pass the parameter
+"ohci1394_dma=early" to the recompiled kernel on boot.
 
 Tools
 -----
Index: linux/drivers/firewire/fw-ohci.c
===================================================================
--- linux.orig/drivers/firewire/fw-ohci.c
+++ linux/drivers/firewire/fw-ohci.c
@@ -1309,11 +1309,6 @@ static void bus_reset_tasklet(unsigned l
 		reg_write(ohci, OHCI1394_ConfigROMhdr, ohci->next_header);
 	}
 
-#ifdef CONFIG_FIREWIRE_OHCI_REMOTE_DMA
-	reg_write(ohci, OHCI1394_PhyReqFilterHiSet, ~0);
-	reg_write(ohci, OHCI1394_PhyReqFilterLoSet, ~0);
-#endif
-
 	spin_unlock_irqrestore(&ohci->lock, flags);
 
 	if (free_rom)
@@ -1341,8 +1336,14 @@ static irqreturn_t irq_handler(int irq, 
 	reg_write(ohci, OHCI1394_IntEventClear, event & ~OHCI1394_busReset);
 	log_irqs(event);
 
-	if (event & OHCI1394_selfIDComplete)
+	if (event & OHCI1394_selfIDComplete) {
+#ifdef CONFIG_FIREWIRE_OHCI_REMOTE_DMA
+		reg_write(ohci, OHCI1394_PhyReqFilterHiSet, ~0);
+		reg_write(ohci, OHCI1394_PhyReqFilterLoSet, ~0);
+		flush_writes(ohci);
+#endif
 		tasklet_schedule(&ohci->bus_reset_tasklet);
+	}
 
 	if (event & OHCI1394_RQPkt)
 		tasklet_schedule(&ohci->ar_request_ctx.tasklet);
Index: linux/lib/Kconfig.debug
===================================================================
--- linux.orig/lib/Kconfig.debug
+++ linux/lib/Kconfig.debug
@@ -592,18 +592,8 @@ config LATENCYTOP
 	  Enable this option if you want to use the LatencyTOP tool
 	  to find out which userspace is blocking on what kernel operations.
 
-config FIREWIRE_OHCI_REMOTE_DMA
-	bool "Remote debugging via firewire-ohci"
-	depends on FIREWIRE_OHCI
-	help
-	  This option lets you use the FireWire bus for remote debugging.
-	  It enables unfiltered remote DMA in the firewire-ohci driver.
-	  See Documentation/debugging-via-ohci1394.txt for more information.
-
-	  If unsure, say N.
-
 config PROVIDE_OHCI1394_DMA_INIT
-	bool "Provide code for enabling DMA over FireWire early on boot"
+	bool "Remote debugging over FireWire early on boot"
 	depends on PCI && X86
 	help
 	  If you want to debug problems which hang or crash the kernel early
@@ -631,4 +621,15 @@ config PROVIDE_OHCI1394_DMA_INIT
 
 	  See Documentation/debugging-via-ohci1394.txt for more information.
 
+config FIREWIRE_OHCI_REMOTE_DMA
+	bool "Remote debugging over FireWire with firewire-ohci"
+	depends on FIREWIRE_OHCI
+	help
+	  This option lets you use the FireWire bus for remote debugging
+	  with help of the firewire-ohci driver. It enables unfiltered
+	  remote DMA in firewire-ohci.
+	  See Documentation/debugging-via-ohci1394.txt for more information.
+
+	  If unsure, say N.
+
 source "samples/Kconfig"

-- 
Stefan Richter
-=====-==--- -=-- -=-=-
http://arcgraph.de/sr/

Re: [PATCH linux1394-2.6.git] firewire: fw-ohci: add option for remote debugging - amendment

[Stefan Richter]

I wrote:
>   - Open the physical DMA filter in the top half of the IRQ handler
>     and flush the necessary MMIO writes.  This is to open the filter
>     as soon as possible after bus reset.
...
> --- linux.orig/drivers/firewire/fw-ohci.c
> +++ linux/drivers/firewire/fw-ohci.c
> @@ -1309,11 +1309,6 @@ static void bus_reset_tasklet(unsigned l
>  		reg_write(ohci, OHCI1394_ConfigROMhdr, ohci->next_header);
>  	}
>  
> -#ifdef CONFIG_FIREWIRE_OHCI_REMOTE_DMA
> -	reg_write(ohci, OHCI1394_PhyReqFilterHiSet, ~0);
> -	reg_write(ohci, OHCI1394_PhyReqFilterLoSet, ~0);
> -#endif
> -
>  	spin_unlock_irqrestore(&ohci->lock, flags);
>  
>  	if (free_rom)
> @@ -1341,8 +1336,14 @@ static irqreturn_t irq_handler(int irq, 
>  	reg_write(ohci, OHCI1394_IntEventClear, event & ~OHCI1394_busReset);
>  	log_irqs(event);
>  
> -	if (event & OHCI1394_selfIDComplete)
> +	if (event & OHCI1394_selfIDComplete) {
> +#ifdef CONFIG_FIREWIRE_OHCI_REMOTE_DMA
> +		reg_write(ohci, OHCI1394_PhyReqFilterHiSet, ~0);
> +		reg_write(ohci, OHCI1394_PhyReqFilterLoSet, ~0);
> +		flush_writes(ohci);
> +#endif
>  		tasklet_schedule(&ohci->bus_reset_tasklet);
> +	}
>  

I retract this part of the patch.  Writes to PhyReqFilter have no effect 
as long as intEvent.busReset isn't cleared.  This happens in the bottom 
half of the bus reset handler (bus_reset_tasklet).

The rest of the patch stays valid.
-- 
Stefan Richter
-=====-==--- -=-- -=-==
http://arcgraph.de/sr/

Re: [BUG] linux-next: Tree for April 9 warning on CC_STACKPROTECTOR, followed by kernel panic

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> CC to Ingo ...

i've reverted the guilty patch and will push out a new x86.git soon.

	Ingo