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/.
--=20

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 confl...
[ message continues ]

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) ...
[ message continues ]

CC to Ingo ...
On Thu, 10 Apr 2008 15:09:17 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ib=

4 55 53 48 8b 4c 24 18 9c 5b fa 65 8b 04 25 24 00 00 00 48 98 <48> 8b ac c7=
--=20

Cheers,

Stephen Rothwell                    sfr@canb.auug.org.au

http://www.canb.auug.org.au/~sfr/

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

--

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.

--

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

--

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/

--

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

--

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
--=20

Cheers,

Stephen Rothwell                    sfr@canb.auug.org.au

http://www.canb.auug.org.au/~sfr/

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

--

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/
--

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 enab...
[ message continues ]

---

~Randy

--

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

--

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_PRO...
[ message continues ]

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/

--

Hi Stefan,
On Wed, 09 Apr 2008 18:55:42 +0200 Stefan Richter <stefanr@s5r6.in-berlin.d=
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 ...
--=20

Cheers,

Stephen Rothwell                    sfr@canb.auug.org.au

http://www.canb.auug.org.au/~sfr/