linux-next: Tree for September 4

linux-next: Tree for September 4

[Stephen Rothwell]

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

Hi all,

Changes since next-20080903:

I have reverted the ttydev tree for today at Andrew's request since it is
causing him a problem.

The dwmw2 tree needed a commit reverted to fix the build.

The sparc tree gained a trivial conflict against Linus' tree.

The block tree lost 2 conflicts and a build fix patch.

I have also applied the following patches for known problems:

	ftrace: protect the definition of ftrace_release
	revert BUILD_BUG_ON change
	Revert "debug: add notifier chain debugging"
	debug: add notifier chain debugging (different version)
	sparc: qlogicpti fallout from sbus removal
	powerpc: make sure all kernel test is before _etext

----------------------------------------------------------------------------

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, it is also built with powerpc allnoconfig,
44x_defconfig and allyesconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

We are up to 113 trees (counting Linus' and 14 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 powerpc-merge/merge
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sparc-current/master
Merging sound-current/for-linus
Merging arm-current/master
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-2.6.26
Merging dwmw2/master
Created commit 636b031: Revert "Blacklist DMAR on Intel G31/G33 chipsets"
Merging arm/devel
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging quilt/m68k
Merging m68knommu/for-next
Merging mips/mips-for-linux-next
Merging parisc/master
Merging powerpc/powerpc-next
Merging 4xx/next
Merging galak/powerpc-next
Merging s390/features
Merging sh/master
Merging sparc/master
CONFLICT (content): Merge conflict in arch/sparc/kernel/of_device.c
Merging x86/auto-x86-next
CONFLICT (content): Merge conflict in include/asm-x86/cpufeature.h
CONFLICT (content): Merge conflict in include/asm-x86/statfs.h
Merging xtensa/master
Merging quilt/driver-core
Merging quilt/usb
Merging tip-core/auto-core-next
Merging cpus4096/auto-cpus4096-next
Merging ftrace/auto-ftrace-next
CONFLICT (content): Merge conflict in kernel/module.c
Applying ftrace: remove warning of old objcopy and local functions
Merging genirq/auto-genirq-next
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
Merging stackprotector/auto-stackprotector-next
CONFLICT (content): Merge conflict in include/asm-x86/pda.h
CONFLICT (content): Merge conflict in kernel/fork.c
Merging timers/auto-timers-next
Merging pci/linux-next
Merging quilt/device-mapper
Merging hid/mm
CONFLICT (content): Merge conflict in drivers/hid/usbhid/hid-core.c
Applying HID: fix for warn() removal
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/stable
CONFLICT (content): Merge conflict in drivers/media/radio/dsbr100.c
CONFLICT (content): Merge conflict in drivers/media/video/zr364xx.c
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
CONFLICT (content): Merge conflict in drivers/misc/acer-wmi.c
Merging nfsd/nfsd-next
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
CONFLICT (content): Merge conflict in include/asm-x86/kvm.h
Merging dlm/next
Merging scsi/master
Merging tests/master
CONFLICT (content): Merge conflict in lib/Kconfig.debug
Merging ocfs2/linux-next
Merging ext4/next
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
Merging quilt/rr
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Applying rr: build fix for remove CONFIG_KMOD from net
Merging semaphore/semaphore
Merging semaphore-removal/semaphore-removal
Merging bkl-removal/bkl-removal
Merging trivial/next
CONFLICT (content): Merge conflict in Documentation/edac.txt
CONFLICT (content): Merge conflict in include/linux/securebits.h
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
CONFLICT (content): Merge conflict in drivers/ide/ide-disk.c
CONFLICT (content): Merge conflict in drivers/md/dm-mpath.c
CONFLICT (content): Merge conflict in lib/Kconfig.debug
Merging embedded/master
Merging firmware/master
CONFLICT (content): Merge conflict in drivers/scsi/qlogicpti.c
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging kmemcheck/auto-kmemcheck-next
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (content): Merge conflict in arch/x86/kernel/process_64.c
CONFLICT (content): Merge conflict in arch/x86/kernel/traps_64.c
CONFLICT (content): Merge conflict in init/main.c
CONFLICT (content): Merge conflict in mm/Makefile
CONFLICT (content): Merge conflict in mm/slab.c
CONFLICT (content): Merge conflict in mm/slub.c
Merging generic-ipi/auto-generic-ipi-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/reg-for-linus
Merging security-testing/next
Merging lblnet/master
Merging quilt/ttydev
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
CONFLICT (content): Merge conflict in drivers/char/tty_io.c
CONFLICT (content): Merge conflict in drivers/char/vt.c
CONFLICT (content): Merge conflict in drivers/usb/serial/aircable.c
CONFLICT (content): Merge conflict in drivers/usb/serial/keyspan_pda.c
CONFLICT (content): Merge conflict in drivers/usb/serial/safe_serial.c
CONFLICT (content): Merge conflict in kernel/auditsc.c
Merging agp/agp-next
Merging creds/next-creds
CONFLICT (content): Merge conflict in drivers/net/wan/sbni.c
CONFLICT (content): Merge conflict in fs/namespace.c
CONFLICT (content): Merge conflict in fs/nfsd/nfs4recover.c
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_linux.h
CONFLICT (content): Merge conflict in fs/xfs/xfs_inode.c
CONFLICT (content): Merge conflict in fs/xfs/xfs_vnodeops.c
CONFLICT (content): Merge conflict in include/linux/capability.h
CONFLICT (add/add): Merge conflict in include/linux/cred.h
CONFLICT (content): Merge conflict in include/linux/security.h
CONFLICT (content): Merge conflict in kernel/exit.c
CONFLICT (content): Merge conflict in kernel/fork.c
CONFLICT (content): Merge conflict in security/commoncap.c
CONFLICT (content): Merge conflict in security/selinux/hooks.c
CONFLICT (content): Merge conflict in security/smack/smack_lsm.c
Merging oprofile/auto-oprofile-next
CONFLICT (content): Merge conflict in arch/x86/kernel/apic_32.c
Merging fastboot/auto-fastboot-next
CONFLICT (content): Merge conflict in include/linux/init.h
Merging sparseirq/auto-sparseirq-next
CONFLICT (delete/modify): arch/x86/kernel/apic_64.c deleted in sparseirq/auto-sparseirq-next and modified in HEAD. Version HEAD of arch/x86/kernel/apic_64.c left in tree.
CONFLICT (content): Merge conflict in arch/x86/xen/spinlock.c
CONFLICT (content): Merge conflict in drivers/serial/68328serial.c
CONFLICT (content): Merge conflict in drivers/serial/8250.c
$ git rm arch/x86/kernel/apic_64.c
CONFLICT (content): Merge conflict in kernel/fork.c
mark the corrected paths with 'git add <paths>' or 'git rm <paths>' and commit the result.
Created commit 0f6dc77: Revert "Merge branch 'quilt/ttydev'"
Applying revert BUILD_BUG_ON change
Applying ftrace: protect the definition of ftrace_release
Created commit 201c2cd: Revert "debug: add notifier chain debugging"
Applying debug: add notifier chain debugging
Applying sparc: qlogicpti fallout from sbus removal
Applying powerpc: make sure all kernel test is before _etext

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

Re: linux-next: Tree for September 4

[Alan Cox]

> I have reverted the ttydev tree for today at Andrew's request since it is
> causing him a problem.

I've pushed a "mini" ttydev tree with just the fixes and earlier patches
in for the moment while I nail this one down. That way the stuff which
is independent can still be tested and get to Linus even if the big tty
rework has to be delayed.

Re: linux-next: Tree for September 4

[Stephen Rothwell]

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

Hi Alan,

On Thu, 4 Sep 2008 12:52:48 +0100 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> > I have reverted the ttydev tree for today at Andrew's request since it is
> > causing him a problem.
> 
> I've pushed a "mini" ttydev tree with just the fixes and earlier patches
> in for the moment while I nail this one down. That way the stuff which
> is independent can still be tested and get to Linus even if the big tty
> rework has to be delayed.

Thanks, I will fetch that tomorrow.  (Aren't timezones fun? :-))

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

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

Re: linux-next: Tree for September 4

[Andrew Morton]

On Thu, 4 Sep 2008 19:36:06 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git

sparc64 `make headers_check':

make[1]: *** No rule to make target `/usr/src/devel/arch/sparc/include/asm/statfs_32.h', needed by `/usr/src/devel/usr/include/asm/.install'.  Stop.

Re: linux-next: Tree for September 4

[David Woodhouse]

On Thu, 2008-09-04 at 16:53 -0700, Andrew Morton wrote:
> 
> sparc64 `make headers_check':
> 
> make[1]: *** No rule to make target
> `/usr/src/devel/arch/sparc/include/asm/statfs_32.h', needed by
> `/usr/src/devel/usr/include/asm/.install'.  Stop.

Fixed in ~dwmw2/random-2.6.git. Thanks.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: linux-next: Tree for September 4 (PATCH: SND_USB)

[Randy Dunlap]

From: Randy Dunlap <randy.dunlap@oracle.com>

CONFIG_SND_USB_US122L uses snd_hwdep_new(), so SND_HWDEP needs
to be enabled (selected).

ERROR: "snd_hwdep_new" [sound/usb/usx2y/snd-usb-us122l.ko] undefined!

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
 sound/usb/Kconfig |    1 +
 1 file changed, 1 insertion(+)

--- linux-next-20080904.orig/sound/usb/Kconfig
+++ linux-next-20080904/sound/usb/Kconfig
@@ -70,6 +70,7 @@ config SND_USB_CAIAQ_INPUT
 config SND_USB_US122L
 	tristate "Tascam US-122L USB driver"
 	depends on X86 && EXPERIMENTAL
+	select SND_HWDEP
 	select SND_RAWMIDI
 	help
 	  Say Y here to include support for Tascam US-122L USB Audio/MIDI

Re: linux-next: Tree for September 4 (PATCH: IXGBE)

[Randy Dunlap]

From: Randy Dunlap <randy.dunlap@oracle.com>

ixgbe needs to be restricted to the same build config (m/y)
as DCA since it calls the dca_*() functions.

ixgbe_main.c:(.text+0xd9c09): undefined reference to `dca3_get_tag'
ixgbe_main.c:(.text+0xd9cc9): undefined reference to `dca3_get_tag'
ixgbe_main.c:(.text+0xda5c1): undefined reference to `dca_add_requester'
ixgbe_main.c:(.text+0xda5d6): undefined reference to `dca_remove_requester'
text+0xdc162): undefined reference to `dca_add_requester'
text+0xdc1d3): undefined reference to `dca_remove_requester'
ixgbe_main.c:(.init.text+0xa74b): undefined reference to `dca_register_notify'
ixgbe_main.c:(.devinit.text+0xa4ca): undefined reference to `dca_add_requester'
ixgbe_main.c:(.exit.text+0xd21): undefined reference to `dca_unregister_notify'
ixgbe_main.c:(.devexit.text+0x72d): undefined reference to `dca_remove_requester'
make[1]: *** [.tmp_vmlinux1] Error 1

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
 drivers/net/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20080904.orig/drivers/net/Kconfig
+++ linux-next-20080904/drivers/net/Kconfig
@@ -2379,7 +2379,7 @@ config EHEA
 
 config IXGBE
 	tristate "Intel(R) 10GbE PCI Express adapters support"
-	depends on PCI && INET
+	depends on PCI && INET && DCA
 	select INET_LRO
 	---help---
 	  This driver supports Intel(R) 10GbE PCI Express family of

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: linux-next: Tree for September 4

[Andrew Morton]

On Thu, 4 Sep 2008 19:36:06 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git

The infamous Vaio hasn't finished catching up with you guys yet. 
Something in linux-next broke suspend-to-RAM.

An `echo mem > /sys/power/state' causes "Freezing of tasks failed after
20.00 seconds (1 tasks refusing to freeze):"

dmesg: http://userweb.kernel.org/~akpm/dmesg-sony-suspend.txt
config: http://userweb.kernel.org/~akpm/config-sony.txt

This only happens after the X server has been started.

Mainline is OK.

Re: linux-next: Tree for September 4 (PATCH: SND_USB)

[Takashi Iwai]

At Thu, 4 Sep 2008 20:28:13 -0700,
Randy Dunlap wrote:
> 
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> CONFIG_SND_USB_US122L uses snd_hwdep_new(), so SND_HWDEP needs
> to be enabled (selected).
> 
> ERROR: "snd_hwdep_new" [sound/usb/usx2y/snd-usb-us122l.ko] undefined!
> 
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>

Thanks, applied now.


Takashi

> ---
>  sound/usb/Kconfig |    1 +
>  1 file changed, 1 insertion(+)
> 
> --- linux-next-20080904.orig/sound/usb/Kconfig
> +++ linux-next-20080904/sound/usb/Kconfig
> @@ -70,6 +70,7 @@ config SND_USB_CAIAQ_INPUT
>  config SND_USB_US122L
>  	tristate "Tascam US-122L USB driver"
>  	depends on X86 && EXPERIMENTAL
> +	select SND_HWDEP
>  	select SND_RAWMIDI
>  	help
>  	  Say Y here to include support for Tascam US-122L USB Audio/MIDI
> 

Re: linux-next: Tree for September 4

[Rafael J. Wysocki]

On Friday, 5 of September 2008, Andrew Morton wrote:
> On Thu, 4 Sep 2008 19:36:06 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > I have created today's linux-next tree at
> > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> 
> The infamous Vaio hasn't finished catching up with you guys yet. 
> Something in linux-next broke suspend-to-RAM.
> 
> An `echo mem > /sys/power/state' causes "Freezing of tasks failed after
> 20.00 seconds (1 tasks refusing to freeze):"
> 
> dmesg: http://userweb.kernel.org/~akpm/dmesg-sony-suspend.txt
> config: http://userweb.kernel.org/~akpm/config-sony.txt
> 
> This only happens after the X server has been started.
> 
> Mainline is OK.

According to your dmesg the process that refused to freeze was

hald-addon-stor

which got stuck in ... getnstimeofday (???) (can you check what
source code corresponds to getnstimeofday+0x37/0xbc pls?):

hald-addon-st D 00000046     0  2322   2282
       f4de5b74 00000046 f4de5b54 00000046 f4de5b5c c0135f56 f6b96e44 f4deaf40 
       f4deb0bc f5580948 f4de5bb0 f4de5b6c c013336e f6aa77c8 f6aa77c8 f6aa77a0 
       f4de5bb0 f4de5b7c c0331f09 f4de5bd0 c01f4205 00000000 00000000 00000000 
Call Trace:
 [<c0135f56>] ? getnstimeofday+0x37/0xbc
 [<c013336e>] ? ktime_get_ts+0x40/0x44
 [<c0331f09>] io_schedule+0x39/0x6c
 [<c01f4205>] get_request_wait+0x80/0xcd
 [<c0130615>] ? autoremove_wake_function+0x0/0x33
 [<c01f4285>] blk_get_request+0x33/0x5f
 [<c027a2a5>] scsi_execute+0x1f/0x10a
 [<c027a40a>] scsi_execute_req+0x7a/0x97
 [<f862c0f9>] sr_test_unit_ready+0x39/0x95 [sr_mod]
 [<f862ccbf>] sr_media_change+0x3c/0x1f9 [sr_mod]
 [<c0331d2f>] ? schedule+0x438/0x451
 [<f85c1073>] media_changed+0x43/0x71 [cdrom]
 [<f85c10cd>] cdrom_media_changed+0x2c/0x32 [cdrom]
 [<f862c19e>] sr_block_media_changed+0x11/0x13 [sr_mod]
 [<c019eee0>] check_disk_change+0x1c/0x79
 [<f85c4c72>] cdrom_open+0x7ec/0x85a [cdrom]
 [<c01d8499>] ? avc_has_perm_noaudit+0x38c/0x42e
 [<c01d84c0>] ? avc_has_perm_noaudit+0x3b3/0x42e
 [<c01f62e4>] ? blk_execute_rq_nowait+0x74/0x7c
 [<c01d8129>] ? avc_has_perm_noaudit+0x1c/0x42e
 [<c01d84c0>] ? avc_has_perm_noaudit+0x3b3/0x42e
 [<c033264f>] ? mutex_unlock+0x8/0xa
 [<c013d4c5>] ? trace_hardirqs_on+0xb/0xd
 [<f862c25d>] sr_block_open+0x83/0x91 [sr_mod]
 [<c019f48a>] do_open+0xa9/0x2b5
 [<c019f94b>] blkdev_open+0x28/0x51
 [<c017df80>] __dentry_open+0x181/0x29f
 [<c017edc5>] nameidata_to_filp+0x2b/0x42
 [<c019f923>] ? blkdev_open+0x0/0x51
 [<c0189251>] do_filp_open+0x391/0x662
 [<c013d4c5>] ? trace_hardirqs_on+0xb/0xd
 [<c018ffe9>] ? alloc_fd+0xbf/0xc9
 [<c018ffe9>] ? alloc_fd+0xbf/0xc9
 [<c017f0a8>] do_sys_open+0x44/0xb9
 [<c017f15f>] sys_open+0x1e/0x26
 [<c0103925>] sysenter_do_call+0x12/0x31

RE: [E1000-devel] linux-next: Tree for September 4 (PATCH: IXGBE)

[Brandeburg, Jesse]

Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> ixgbe needs to be restricted to the same build config (m/y)
> as DCA since it calls the dca_*() functions.
> 
> ixgbe_main.c:(.text+0xd9c09): undefined reference to `dca3_get_tag'

Thanks Randy for catching that, you're correct.

Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>

Re: linux-next: Tree for September 4

[Andrew Morton]

On Fri, 5 Sep 2008 12:56:35 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Friday, 5 of September 2008, Andrew Morton wrote:
> > On Thu, 4 Sep 2008 19:36:06 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > > I have created today's linux-next tree at
> > > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> > 
> > The infamous Vaio hasn't finished catching up with you guys yet. 
> > Something in linux-next broke suspend-to-RAM.
> > 
> > An `echo mem > /sys/power/state' causes "Freezing of tasks failed after
> > 20.00 seconds (1 tasks refusing to freeze):"
> > 
> > dmesg: http://userweb.kernel.org/~akpm/dmesg-sony-suspend.txt
> > config: http://userweb.kernel.org/~akpm/config-sony.txt
> > 
> > This only happens after the X server has been started.
> > 
> > Mainline is OK.
> 
> According to your dmesg the process that refused to freeze was
> 
> hald-addon-stor
> 
> which got stuck in ... getnstimeofday (???) (can you check what
> source code corresponds to getnstimeofday+0x37/0xbc pls?):
> 
> hald-addon-st D 00000046     0  2322   2282
>        f4de5b74 00000046 f4de5b54 00000046 f4de5b5c c0135f56 f6b96e44 f4deaf40 
>        f4deb0bc f5580948 f4de5bb0 f4de5b6c c013336e f6aa77c8 f6aa77c8 f6aa77a0 
>        f4de5bb0 f4de5b7c c0331f09 f4de5bd0 c01f4205 00000000 00000000 00000000 
> Call Trace:
>  [<c0135f56>] ? getnstimeofday+0x37/0xbc
>  [<c013336e>] ? ktime_get_ts+0x40/0x44
>  [<c0331f09>] io_schedule+0x39/0x6c
>  [<c01f4205>] get_request_wait+0x80/0xcd
> ...

(gdb) x/60i getnstimeofday
0xc0135d63 <getnstimeofday>:    push   %ebp
0xc0135d64 <getnstimeofday+1>:  mov    %esp,%ebp
0xc0135d66 <getnstimeofday+3>:  push   %edi
0xc0135d67 <getnstimeofday+4>:  push   %esi
0xc0135d68 <getnstimeofday+5>:  push   %ebx
0xc0135d69 <getnstimeofday+6>:  sub    $0x8,%esp
0xc0135d6c <getnstimeofday+9>:  mov    %eax,0xffffffec(%ebp)
0xc0135d6f <getnstimeofday+12>: mov    0xc045a2c0,%eax
0xc0135d74 <getnstimeofday+17>: mov    %eax,0xfffffff0(%ebp)
0xc0135d77 <getnstimeofday+20>: test   $0x1,%al
0xc0135d79 <getnstimeofday+22>: je     0xc0135d7f <getnstimeofday+28>
0xc0135d7b <getnstimeofday+24>: pause  
0xc0135d7d <getnstimeofday+26>: jmp    0xc0135d6f <getnstimeofday+12>
0xc0135d7f <getnstimeofday+28>: mov    0xffffffec(%ebp),%ecx
0xc0135d82 <getnstimeofday+31>: mov    0xc05db920,%eax
0xc0135d87 <getnstimeofday+36>: mov    0xc05db924,%edx
0xc0135d8d <getnstimeofday+42>: mov    %eax,(%ecx)
0xc0135d8f <getnstimeofday+44>: mov    %edx,0x4(%ecx)
0xc0135d92 <getnstimeofday+47>: mov    0xc05db938,%eax
0xc0135d97 <getnstimeofday+52>: call   *0x10(%eax)
0xc0135d9a <getnstimeofday+55>: mov    0xc05db938,%esi
0xc0135da0 <getnstimeofday+61>: mov    0x1c(%esi),%ecx
0xc0135da3 <getnstimeofday+64>: sub    0x48(%esi),%eax
0xc0135da6 <getnstimeofday+67>: sbb    0x4c(%esi),%edx
0xc0135da9 <getnstimeofday+70>: and    0x14(%esi),%eax
0xc0135dac <getnstimeofday+73>: and    0x18(%esi),%edx
0xc0135daf <getnstimeofday+76>: mov    %edx,%edi
0xc0135db1 <getnstimeofday+78>: imul   %ecx,%edi
0xc0135db4 <getnstimeofday+81>: mul    %ecx
0xc0135db6 <getnstimeofday+83>: mov    0x24(%esi),%ecx
0xc0135db9 <getnstimeofday+86>: lea    (%edi,%edx,1),%edx
0xc0135dbc <getnstimeofday+89>: mov    %eax,%ebx
0xc0135dbe <getnstimeofday+91>: mov    %edx,%esi
0xc0135dc0 <getnstimeofday+93>: xor    %edi,%edi
0xc0135dc2 <getnstimeofday+95>: shrd   %cl,%edx,%ebx
0xc0135dc5 <getnstimeofday+98>: shr    %cl,%esi
0xc0135dc7 <getnstimeofday+100>:        test   $0x20,%cl
0xc0135dca <getnstimeofday+103>:        cmovne %esi,%ebx
0xc0135dcd <getnstimeofday+106>:        cmovne %edi,%esi
0xc0135dd0 <getnstimeofday+109>:        mov    %ebx,%edx

(gdb) l *0xc0135d9a
0xc0135d9a is in getnstimeofday (kernel/time/timekeeping.c:104).
99      
100                     /* read clocksource: */
101                     cycle_now = clocksource_read(clock);
102     
103                     /* calculate the delta since the last update_wall_time: */
104                     cycle_delta = (cycle_now - clock->cycle_last) & clock->mask;
105     
106                     /* convert to nanoseconds: */
107                     nsecs = cyc2ns(clock, cycle_delta);
108     

Which implies that someone mucked up xtime_lock.

But I don't think any of that is correct.  The getnstimeofday is just
stack gunk.  hald is in D state and is asleep in get_request_wait().

RE: [E1000-devel] linux-next: Tree for September 4 (PATCH: IXGBE)

[Brandeburg, Jesse]

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

Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> ixgbe needs to be restricted to the same build config (m/y)
> as DCA since it calls the dca_*() functions.
> 
> ixgbe_main.c:(.text+0xd9c09): undefined reference to `dca3_get_tag'
> ixgbe_main.c:(.text+0xd9cc9): undefined reference to `dca3_get_tag'
> ixgbe_main.c:(.text+0xda5c1): undefined reference to
> `dca_add_requester' ixgbe_main.c:(.text+0xda5d6): undefined reference
> to `dca_remove_requester' text+0xdc162): undefined reference to
> `dca_add_requester' 
> text+0xdc1d3): undefined reference to `dca_remove_requester'
> ixgbe_main.c:(.init.text+0xa74b): undefined reference to
> `dca_register_notify' ixgbe_main.c:(.devinit.text+0xa4ca): undefined
> reference to `dca_add_requester' ixgbe_main.c:(.exit.text+0xd21):
> undefined reference to `dca_unregister_notify'
> ixgbe_main.c:(.devexit.text+0x72d): undefined reference to
> `dca_remove_requester' make[1]: *** [.tmp_vmlinux1] Error 1 
> 
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
...
> +	depends on PCI && INET && DCA

Looks like you set IXGBE=y and CONFIG_DCA=m.  This depends DCA option is
not so great because if INTEL_IOATDMA is disabled (and therefore DCA is
disabled) then ixgbe won't show up as an option.

How about this instead, use a select INTEL_IOATDMA:

inline is whitespace busted, sorry. attached is the patch.


[-- Attachment #2: ixgbe_Kconfig_dca.patch --]
[-- Type: application/octet-stream, Size: 932 bytes --]

ixgbe: fix DCA dependency in Kconfig

From: Jesse Brandeburg <jesse.brandeburg@intel.com>

ixgbe can depend on dca IF it is enabled.  So if we are compiled
as IXGBE=y, and DCA is enabled, then we must force INTEL_IOATDMA
and therefore DCA to be =y also.

Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: Randy Dunlap <randy.dunlap@oracle.com>
CC: Emil Tantilov <emil.s.tantilov@intel.com>
---
 drivers/net/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 4a11296..86f53a1 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2381,6 +2381,7 @@ config IXGBE
 	tristate "Intel(R) 10GbE PCI Express adapters support"
 	depends on PCI && INET
 	select INET_LRO
+	select INTEL_IOATDMA
 	---help---
 	  This driver supports Intel(R) 10GbE PCI Express family of
 	  adapters.  For more information on how to identify your adapter, go

Re: linux-next: Tree for September 4 (PATCH: IXGBE)

[Randy Dunlap]

On Fri, 5 Sep 2008 16:47:55 -0700 Brandeburg, Jesse wrote:

> Randy Dunlap wrote:
> > From: Randy Dunlap <randy.dunlap@oracle.com>
> > 
> > ixgbe needs to be restricted to the same build config (m/y)
> > as DCA since it calls the dca_*() functions.
> > 
> > ixgbe_main.c:(.text+0xd9c09): undefined reference to `dca3_get_tag'
> > ixgbe_main.c:(.text+0xd9cc9): undefined reference to `dca3_get_tag'
> > ixgbe_main.c:(.text+0xda5c1): undefined reference to
> > `dca_add_requester' ixgbe_main.c:(.text+0xda5d6): undefined reference
> > to `dca_remove_requester' text+0xdc162): undefined reference to
> > `dca_add_requester' 
> > text+0xdc1d3): undefined reference to `dca_remove_requester'
> > ixgbe_main.c:(.init.text+0xa74b): undefined reference to
> > `dca_register_notify' ixgbe_main.c:(.devinit.text+0xa4ca): undefined
> > reference to `dca_add_requester' ixgbe_main.c:(.exit.text+0xd21):
> > undefined reference to `dca_unregister_notify'
> > ixgbe_main.c:(.devexit.text+0x72d): undefined reference to
> > `dca_remove_requester' make[1]: *** [.tmp_vmlinux1] Error 1 
> > 
> > Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> ...
> > +	depends on PCI && INET && DCA
> 
> Looks like you set IXGBE=y and CONFIG_DCA=m.  This depends DCA option is
> not so great because if INTEL_IOATDMA is disabled (and therefore DCA is
> disabled) then ixgbe won't show up as an option.
> 
> How about this instead, use a select INTEL_IOATDMA:
> 
> inline is whitespace busted, sorry. attached is the patch.

OK, that works.  Thanks.

---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: linux-next: Tree for September 4

[Rafael J. Wysocki]

On Friday, 5 of September 2008, Andrew Morton wrote:
> On Fri, 5 Sep 2008 12:56:35 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > On Friday, 5 of September 2008, Andrew Morton wrote:
> > > On Thu, 4 Sep 2008 19:36:06 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > 
> > > > I have created today's linux-next tree at
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> > > 
> > > The infamous Vaio hasn't finished catching up with you guys yet. 
> > > Something in linux-next broke suspend-to-RAM.
> > > 
> > > An `echo mem > /sys/power/state' causes "Freezing of tasks failed after
> > > 20.00 seconds (1 tasks refusing to freeze):"
> > > 
> > > dmesg: http://userweb.kernel.org/~akpm/dmesg-sony-suspend.txt
> > > config: http://userweb.kernel.org/~akpm/config-sony.txt
> > > 
> > > This only happens after the X server has been started.
> > > 
> > > Mainline is OK.
> > 
> > According to your dmesg the process that refused to freeze was
> > 
> > hald-addon-stor
> > 
> > which got stuck in ... getnstimeofday (???) (can you check what
> > source code corresponds to getnstimeofday+0x37/0xbc pls?):
> > 
> > hald-addon-st D 00000046     0  2322   2282
> >        f4de5b74 00000046 f4de5b54 00000046 f4de5b5c c0135f56 f6b96e44 f4deaf40 
> >        f4deb0bc f5580948 f4de5bb0 f4de5b6c c013336e f6aa77c8 f6aa77c8 f6aa77a0 
> >        f4de5bb0 f4de5b7c c0331f09 f4de5bd0 c01f4205 00000000 00000000 00000000 
> > Call Trace:
> >  [<c0135f56>] ? getnstimeofday+0x37/0xbc
> >  [<c013336e>] ? ktime_get_ts+0x40/0x44
> >  [<c0331f09>] io_schedule+0x39/0x6c
> >  [<c01f4205>] get_request_wait+0x80/0xcd
> > ...
> 
> (gdb) x/60i getnstimeofday
> 0xc0135d63 <getnstimeofday>:    push   %ebp
> 0xc0135d64 <getnstimeofday+1>:  mov    %esp,%ebp
> 0xc0135d66 <getnstimeofday+3>:  push   %edi
> 0xc0135d67 <getnstimeofday+4>:  push   %esi
> 0xc0135d68 <getnstimeofday+5>:  push   %ebx
> 0xc0135d69 <getnstimeofday+6>:  sub    $0x8,%esp
> 0xc0135d6c <getnstimeofday+9>:  mov    %eax,0xffffffec(%ebp)
> 0xc0135d6f <getnstimeofday+12>: mov    0xc045a2c0,%eax
> 0xc0135d74 <getnstimeofday+17>: mov    %eax,0xfffffff0(%ebp)
> 0xc0135d77 <getnstimeofday+20>: test   $0x1,%al
> 0xc0135d79 <getnstimeofday+22>: je     0xc0135d7f <getnstimeofday+28>
> 0xc0135d7b <getnstimeofday+24>: pause  
> 0xc0135d7d <getnstimeofday+26>: jmp    0xc0135d6f <getnstimeofday+12>
> 0xc0135d7f <getnstimeofday+28>: mov    0xffffffec(%ebp),%ecx
> 0xc0135d82 <getnstimeofday+31>: mov    0xc05db920,%eax
> 0xc0135d87 <getnstimeofday+36>: mov    0xc05db924,%edx
> 0xc0135d8d <getnstimeofday+42>: mov    %eax,(%ecx)
> 0xc0135d8f <getnstimeofday+44>: mov    %edx,0x4(%ecx)
> 0xc0135d92 <getnstimeofday+47>: mov    0xc05db938,%eax
> 0xc0135d97 <getnstimeofday+52>: call   *0x10(%eax)
> 0xc0135d9a <getnstimeofday+55>: mov    0xc05db938,%esi
> 0xc0135da0 <getnstimeofday+61>: mov    0x1c(%esi),%ecx
> 0xc0135da3 <getnstimeofday+64>: sub    0x48(%esi),%eax
> 0xc0135da6 <getnstimeofday+67>: sbb    0x4c(%esi),%edx
> 0xc0135da9 <getnstimeofday+70>: and    0x14(%esi),%eax
> 0xc0135dac <getnstimeofday+73>: and    0x18(%esi),%edx
> 0xc0135daf <getnstimeofday+76>: mov    %edx,%edi
> 0xc0135db1 <getnstimeofday+78>: imul   %ecx,%edi
> 0xc0135db4 <getnstimeofday+81>: mul    %ecx
> 0xc0135db6 <getnstimeofday+83>: mov    0x24(%esi),%ecx
> 0xc0135db9 <getnstimeofday+86>: lea    (%edi,%edx,1),%edx
> 0xc0135dbc <getnstimeofday+89>: mov    %eax,%ebx
> 0xc0135dbe <getnstimeofday+91>: mov    %edx,%esi
> 0xc0135dc0 <getnstimeofday+93>: xor    %edi,%edi
> 0xc0135dc2 <getnstimeofday+95>: shrd   %cl,%edx,%ebx
> 0xc0135dc5 <getnstimeofday+98>: shr    %cl,%esi
> 0xc0135dc7 <getnstimeofday+100>:        test   $0x20,%cl
> 0xc0135dca <getnstimeofday+103>:        cmovne %esi,%ebx
> 0xc0135dcd <getnstimeofday+106>:        cmovne %edi,%esi
> 0xc0135dd0 <getnstimeofday+109>:        mov    %ebx,%edx
> 
> (gdb) l *0xc0135d9a
> 0xc0135d9a is in getnstimeofday (kernel/time/timekeeping.c:104).
> 99      
> 100                     /* read clocksource: */
> 101                     cycle_now = clocksource_read(clock);
> 102     
> 103                     /* calculate the delta since the last update_wall_time: */
> 104                     cycle_delta = (cycle_now - clock->cycle_last) & clock->mask;
> 105     
> 106                     /* convert to nanoseconds: */
> 107                     nsecs = cyc2ns(clock, cycle_delta);
> 108     
> 
> Which implies that someone mucked up xtime_lock.
> 
> But I don't think any of that is correct.  The getnstimeofday is just
> stack gunk.  hald is in D state and is asleep in get_request_wait().

Right.  It looks like there was a media change in the CD drive and hald was
waiting for the device in sr_test_unit_ready() forever.  Apparently, the device
could not get ready.

It looks like a SATA/ATA (whatever the CD-ROM is attached to) issue or sr_mod
breakage.

Thanks,
Rafael

Re: linux-next: Tree for September 4

[James Bottomley]

On Sat, 2008-09-06 at 13:25 +0200, Rafael J. Wysocki wrote:
> On Friday, 5 of September 2008, Andrew Morton wrote:
> > On Fri, 5 Sep 2008 12:56:35 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > 
> > > On Friday, 5 of September 2008, Andrew Morton wrote:
> > > > On Thu, 4 Sep 2008 19:36:06 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > 
> > > > > I have created today's linux-next tree at
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> > > > 
> > > > The infamous Vaio hasn't finished catching up with you guys yet. 
> > > > Something in linux-next broke suspend-to-RAM.
> > > > 
> > > > An `echo mem > /sys/power/state' causes "Freezing of tasks failed after
> > > > 20.00 seconds (1 tasks refusing to freeze):"
> > > > 
> > > > dmesg: http://userweb.kernel.org/~akpm/dmesg-sony-suspend.txt
> > > > config: http://userweb.kernel.org/~akpm/config-sony.txt
> > > > 
> > > > This only happens after the X server has been started.
> > > > 
> > > > Mainline is OK.
> > > 
> > > According to your dmesg the process that refused to freeze was
> > > 
> > > hald-addon-stor
> > > 
> > > which got stuck in ... getnstimeofday (???) (can you check what
> > > source code corresponds to getnstimeofday+0x37/0xbc pls?):
> > > 
> > > hald-addon-st D 00000046     0  2322   2282
> > >        f4de5b74 00000046 f4de5b54 00000046 f4de5b5c c0135f56 f6b96e44 f4deaf40 
> > >        f4deb0bc f5580948 f4de5bb0 f4de5b6c c013336e f6aa77c8 f6aa77c8 f6aa77a0 
> > >        f4de5bb0 f4de5b7c c0331f09 f4de5bd0 c01f4205 00000000 00000000 00000000 
> > > Call Trace:
> > >  [<c0135f56>] ? getnstimeofday+0x37/0xbc
> > >  [<c013336e>] ? ktime_get_ts+0x40/0x44
> > >  [<c0331f09>] io_schedule+0x39/0x6c
> > >  [<c01f4205>] get_request_wait+0x80/0xcd
> > > ...
> > 
> > (gdb) x/60i getnstimeofday
> > 0xc0135d63 <getnstimeofday>:    push   %ebp
> > 0xc0135d64 <getnstimeofday+1>:  mov    %esp,%ebp
> > 0xc0135d66 <getnstimeofday+3>:  push   %edi
> > 0xc0135d67 <getnstimeofday+4>:  push   %esi
> > 0xc0135d68 <getnstimeofday+5>:  push   %ebx
> > 0xc0135d69 <getnstimeofday+6>:  sub    $0x8,%esp
> > 0xc0135d6c <getnstimeofday+9>:  mov    %eax,0xffffffec(%ebp)
> > 0xc0135d6f <getnstimeofday+12>: mov    0xc045a2c0,%eax
> > 0xc0135d74 <getnstimeofday+17>: mov    %eax,0xfffffff0(%ebp)
> > 0xc0135d77 <getnstimeofday+20>: test   $0x1,%al
> > 0xc0135d79 <getnstimeofday+22>: je     0xc0135d7f <getnstimeofday+28>
> > 0xc0135d7b <getnstimeofday+24>: pause  
> > 0xc0135d7d <getnstimeofday+26>: jmp    0xc0135d6f <getnstimeofday+12>
> > 0xc0135d7f <getnstimeofday+28>: mov    0xffffffec(%ebp),%ecx
> > 0xc0135d82 <getnstimeofday+31>: mov    0xc05db920,%eax
> > 0xc0135d87 <getnstimeofday+36>: mov    0xc05db924,%edx
> > 0xc0135d8d <getnstimeofday+42>: mov    %eax,(%ecx)
> > 0xc0135d8f <getnstimeofday+44>: mov    %edx,0x4(%ecx)
> > 0xc0135d92 <getnstimeofday+47>: mov    0xc05db938,%eax
> > 0xc0135d97 <getnstimeofday+52>: call   *0x10(%eax)
> > 0xc0135d9a <getnstimeofday+55>: mov    0xc05db938,%esi
> > 0xc0135da0 <getnstimeofday+61>: mov    0x1c(%esi),%ecx
> > 0xc0135da3 <getnstimeofday+64>: sub    0x48(%esi),%eax
> > 0xc0135da6 <getnstimeofday+67>: sbb    0x4c(%esi),%edx
> > 0xc0135da9 <getnstimeofday+70>: and    0x14(%esi),%eax
> > 0xc0135dac <getnstimeofday+73>: and    0x18(%esi),%edx
> > 0xc0135daf <getnstimeofday+76>: mov    %edx,%edi
> > 0xc0135db1 <getnstimeofday+78>: imul   %ecx,%edi
> > 0xc0135db4 <getnstimeofday+81>: mul    %ecx
> > 0xc0135db6 <getnstimeofday+83>: mov    0x24(%esi),%ecx
> > 0xc0135db9 <getnstimeofday+86>: lea    (%edi,%edx,1),%edx
> > 0xc0135dbc <getnstimeofday+89>: mov    %eax,%ebx
> > 0xc0135dbe <getnstimeofday+91>: mov    %edx,%esi
> > 0xc0135dc0 <getnstimeofday+93>: xor    %edi,%edi
> > 0xc0135dc2 <getnstimeofday+95>: shrd   %cl,%edx,%ebx
> > 0xc0135dc5 <getnstimeofday+98>: shr    %cl,%esi
> > 0xc0135dc7 <getnstimeofday+100>:        test   $0x20,%cl
> > 0xc0135dca <getnstimeofday+103>:        cmovne %esi,%ebx
> > 0xc0135dcd <getnstimeofday+106>:        cmovne %edi,%esi
> > 0xc0135dd0 <getnstimeofday+109>:        mov    %ebx,%edx
> > 
> > (gdb) l *0xc0135d9a
> > 0xc0135d9a is in getnstimeofday (kernel/time/timekeeping.c:104).
> > 99      
> > 100                     /* read clocksource: */
> > 101                     cycle_now = clocksource_read(clock);
> > 102     
> > 103                     /* calculate the delta since the last update_wall_time: */
> > 104                     cycle_delta = (cycle_now - clock->cycle_last) & clock->mask;
> > 105     
> > 106                     /* convert to nanoseconds: */
> > 107                     nsecs = cyc2ns(clock, cycle_delta);
> > 108     
> > 
> > Which implies that someone mucked up xtime_lock.
> > 
> > But I don't think any of that is correct.  The getnstimeofday is just
> > stack gunk.  hald is in D state and is asleep in get_request_wait().
> 
> Right.  It looks like there was a media change in the CD drive and hald was
> waiting for the device in sr_test_unit_ready() forever.  Apparently, the device
> could not get ready.
> 
> It looks like a SATA/ATA (whatever the CD-ROM is attached to) issue or sr_mod
> breakage.

Um, I don't see how that follows.

get_request_wait() is the first thing the block layer does to try to get
a request structure for the queue.  If it's stuck there it means that
block was out of requests and is waiting for some memory to free up.  If
we're stuck there, nothing went down to the CD.

However, being stuck here really isn't good news.  These things are
mempool backed to prevent writeout deadlock ... we shouldn't be running
out of them.  What does 

/sys/block/<dev>/queue/nr_reqeusts

and

/sys/block/<dev>/stat

say for this device?

James