linux-next: Tree for June 26

linux-next: Tree for June 26

[Stephen Rothwell]

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

Hi all,

Changes since next-20080625:

The tip-core tree lost its three conflicts against Linus' tree.

The pci tree gained two conflicts against the x86 tree.

The v4l-dvb tree had the second revert undone.  We will see if this is
right.

The net tree gained a conflict against the wireless-current tree.

The vfs tree lost its conflict against the sched tree.

The arm tree lost its conflict against Linus' tree.

The rr tree gained a patch for a build problem instead the revert.

The firmware tree lost a conflict against the usb tree.

I have also applied the following patches for know problems:
	fujitsu-laptop: depends on INPUT
	iwlwifi: fix build for CONFIG_INPUT=n
	module: fix NULL pointer dereference in find_symbol()

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

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 95 trees (counting Linus' and 13 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 quilt/driver-core
Merging quilt/usb
Merging tip-core/auto-core-next
Merging cpus4096/auto-cpus4096-next
Merging ftrace/auto-ftrace-next
Merging genirq/auto-genirq-next
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
CONFLICT (content): Merge conflict in kernel/Makefile
CONFLICT (content): Merge conflict in kernel/sched_rt.c
Applying sched: fix rculist split fallout
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
Merging x86/auto-x86-next
CONFLICT (content): Merge conflict in arch/x86/kernel/entry_32.S
CONFLICT (content): Merge conflict in arch/x86/kernel/process_32.c
CONFLICT (content): Merge conflict in arch/x86/kernel/process_64.c
Applying acpi-acpi_numa_init-build-fix
Applying ia64, acpi: fix Altix boot breakage in ACPI
Applying acpi: fix boot breakage on Altix
Merging pci/linux-next
CONFLICT (content): Merge conflict in arch/x86/kernel/setup_64.c
CONFLICT (content): Merge conflict in arch/x86/pci/irq.c
CONFLICT (content): Merge conflict in arch/x86/pci/pci.h
CONFLICT (content): Merge conflict in include/linux/device.h
Merging quilt/device-mapper
Merging hid/mm
Merging quilt/i2c
CONFLICT (content): Merge conflict in drivers/i2c/i2c-core.c
Merging quilt/kernel-doc
Merging avr32/avr32-arch
Merging v4l-dvb/stable
Applying v4l-dvb: class_for_each_device API change fallout
Created commit 31abc35: Revert "V4L/DVB (8049): budget-ci: Add support for Technotrend budget C-1501 dvb-c card"
Merging s390/features
CONFLICT (content): Merge conflict in drivers/s390/block/dasd.c
CONFLICT (content): Merge conflict in drivers/s390/block/dasd_eckd.c
CONFLICT (content): Merge conflict in drivers/s390/block/dasd_fba.c
CONFLICT (content): Merge conflict in drivers/s390/char/tape_core.c
CONFLICT (content): Merge conflict in drivers/s390/cio/device_fsm.c
CONFLICT (content): Merge conflict in drivers/s390/cio/qdio.c
CONFLICT (content): Merge conflict in drivers/s390/net/claw.c
CONFLICT (content): Merge conflict in drivers/s390/net/ctcm_main.c
CONFLICT (content): Merge conflict in drivers/s390/net/lcs.c
Merging sh/master
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 arch/x86/kernel/process.c
CONFLICT (content): Merge conflict in arch/x86/kernel/srat_32.c
CONFLICT (content): Merge conflict in drivers/acpi/processor_throttling.c
CONFLICT (content): Merge conflict in drivers/acpi/sleep/main.c
Merging blackfin/for-linus
Merging nfsd/nfsd-next
CONFLICT (content): Merge conflict in net/sunrpc/auth_gss/auth_gss.c
CONFLICT (content): Merge conflict in net/sunrpc/svc.c
Merging ieee1394/for-next
Merging hwmon/testing
Merging ubi/master
Merging kvm/master
Merging dlm/next
Merging scsi/master
Applying scsi: fix fallout from the class_find_device API change
Applying scsi: fix fallout from KOBJ_NAME_LEN removal
Merging ia64/test
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 lblnet/master
Merging ext4/next
Merging 4xx/next
Merging async_tx/next
Merging udf/for_next
Merging security-testing/next
Merging net/master
CONFLICT (content): Merge conflict in Documentation/powerpc/booting-without-of.txt
CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl4965-base.c
Applying wireless: fix fallout from device_create removal
Merging sparc/master
CONFLICT (content): Merge conflict in include/asm-m68k/sbus.h
Merging galak/powerpc-next
CONFLICT (content): Merge conflict in Documentation/powerpc/booting-without-of.txt
Merging mtd/master
Merging wireless/master
Merging crypto/master
Merging vfs/vfs-2.6.25
Merging sound/master
Merging arm/devel
CONFLICT (content): Merge conflict in arch/arm/mach-at91/board-yl-9200.c
Merging cpufreq/next
CONFLICT (content): Merge conflict in drivers/cpufreq/cpufreq.c
Merging v9fs/for-next
Merging quilt/rr
CONFLICT (content): Merge conflict in drivers/char/hvc_console.h
CONFLICT (content): Merge conflict in kernel/stop_machine.c
Applying rr fix patch 1
Applying virtio: virtio console can be a module
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging semaphore/semaphore
Merging semaphore-removal/semaphore-removal
CONFLICT (content): Merge conflict in drivers/net/ps3_gelic_wireless.c
CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_attr.c
CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_def.h
CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_mbx.c
CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_mid.c
CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_os.c
Merging bkl-removal/bkl-removal
Merging trivial/next
Merging ubifs/for_andrew
Merging lsm/for-next
Merging block/for-next
CONFLICT (content): Merge conflict in arch/powerpc/Kconfig
CONFLICT (content): Merge conflict in arch/x86/kernel/apic_32.c
CONFLICT (delete/modify): arch/x86/kernel/i8259_64.c deleted in HEAD and modified in block/for-next. Version block/for-next of arch/x86/kernel/i8259_64.c left in tree.
CONFLICT (content): Merge conflict in arch/x86/xen/smp.c
CONFLICT (delete/modify): include/asm-x86/hw_irq_32.h deleted in HEAD and modified in block/for-next. Version block/for-next of include/asm-x86/hw_irq_32.h left in tree.
CONFLICT (delete/modify): include/asm-x86/hw_irq_64.h deleted in HEAD and modified in block/for-next. Version block/for-next of include/asm-x86/hw_irq_64.h left in tree.
CONFLICT (delete/modify): include/asm-x86/mach-default/irq_vectors.h deleted in HEAD and modified in block/for-next. Version block/for-next of include/asm-x86/mach-default/irq_vectors.h left in tree.
CONFLICT (delete/modify): include/asm-x86/mach-voyager/irq_vectors.h deleted in HEAD and modified in block/for-next. Version block/for-next of include/asm-x86/mach-voyager/irq_vectors.h left in tree.
CONFLICT (content): Merge conflict in kernel/Makefile
Applying block: fix up rculist split fallout
Merging embedded/master
Merging firmware/master
CONFLICT (content): Merge conflict in drivers/char/ip2/ip2main.c
CONFLICT (content): Merge conflict in drivers/net/Kconfig
CONFLICT (content): Merge conflict in drivers/usb/misc/isight_firmware.c
CONFLICT (delete/modify): drivers/usb/serial/ti_fw_3410.h deleted in firmware/master and modified in HEAD. Version HEAD of drivers/usb/serial/ti_fw_3410.h left in tree.
CONFLICT (delete/modify): drivers/usb/serial/ti_fw_5052.h deleted in firmware/master and modified in HEAD. Version HEAD of drivers/usb/serial/ti_fw_5052.h left in tree.
CONFLICT (content): Merge conflict in drivers/usb/serial/ti_usb_3410_5052.c
CONFLICT (content): Merge conflict in sound/pci/Kconfig
CONFLICT (content): Merge conflict in sound/pci/maestro3.c
CONFLICT (content): Merge conflict in sound/pci/ymfpci/ymfpci_main.c
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
CONFLICT (content): Merge conflict in drivers/video/backlight/Kconfig
CONFLICT (content): Merge conflict in drivers/video/backlight/Makefile
Merging kgdb/kgdb-next
Merging slab/for-next
Merging m68knommu/for-next
Merging uclinux/for-next
Applying fujitsu-laptop: depends on INPUT
Applying iwlwifi: fix build for CONFIG_INPUT=n
Applying module: fix NULL pointer dereference in find_symbol()

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

Re: linux-next: Tree for June 26

[Rafael J. Wysocki]

On Thursday, 26 of June 2008, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since next-20080625:
> 
> The tip-core tree lost its three conflicts against Linus' tree.
> 
> The pci tree gained two conflicts against the x86 tree.
> 
> The v4l-dvb tree had the second revert undone.  We will see if this is
> right.
> 
> The net tree gained a conflict against the wireless-current tree.
> 
> The vfs tree lost its conflict against the sched tree.
> 
> The arm tree lost its conflict against Linus' tree.
> 
> The rr tree gained a patch for a build problem instead the revert.
> 
> The firmware tree lost a conflict against the usb tree.

commit 423c982fffb1cd95c8cdd654ce5ab59351ba41f5
Author: Jaswinder Singh <jaswinder-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Date:   Wed Jun 18 19:58:33 2008 +0530

    firmware: convert tg3 driver to request_firmware()

breaks my nx6325.

Apparently, with this patch applied the tg3 has a NULL pointer dereference
somewhere, but I can only see the first line of the oops, afterwards the box
hangs solid.

Please drop it if possible.

Also, arch/x86/kernel/io_apic_64.c seems wrong at the moment, as it checks
for conditions that are never satisfied etc.

Thanks,
Rafael

Re: linux-next: Tree for June 26

[David Woodhouse]

On Fri, 2008-06-27 at 01:38 +0200, Rafael J. Wysocki wrote:
> Apparently, with this patch applied the tg3 has a NULL pointer
> dereference somewhere, but I can only see the first line of the oops,
> afterwards the box hangs solid.
> 
> Please drop it if possible.

I'll take a careful look over it for problems, and will drop it for now
if I can't find the cause. I did post it for review, but just got
mostly-unrelated noise rather than anyone looking at the code changes.

-- 
dwmw2

Re: linux-next: Tree for June 26

[David Woodhouse]

On Fri, 2008-06-27 at 01:38 +0200, Rafael J. Wysocki wrote:
> commit 423c982fffb1cd95c8cdd654ce5ab59351ba41f5
> Author: Jaswinder Singh <jaswinder@infradead.org>
> Date:   Wed Jun 18 19:58:33 2008 +0530
> 
>     firmware: convert tg3 driver to request_firmware()
> 
> breaks my nx6325.
> 
> Apparently, with this patch applied the tg3 has a NULL pointer dereference
> somewhere, but I can only see the first line of the oops, afterwards the box
> hangs solid.

That's a 5705, isn't it? So using the 'tso5' firmware?

Is that firmware available (did you either build it into your kernel, or
run 'make INSTALL_FW_PATH=/lib/firmware firmware_install')? 

Not that it matters; I suspect the driver isn't trying to load it at
all. Can you test this patch, please?

(There are more cleanups I want to do to the error paths here, but those
should be harmless and irrelevant: http://david.woodhou.se/tg3.patch )

diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index a70147d..bad784b 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -12234,11 +12234,6 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
 
 	if (tp->tg3_flags2 & TG3_FLG2_HW_TSO) {
 		tp->tg3_flags2 |= TG3_FLG2_TSO_CAPABLE;
-
-		if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705)
-			fw_name = "tigon/tg3_tso5.bin";
-		else
-			fw_name = "tigon/tg3_tso.bin";
 	}
 	else if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 ||
 	    GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701 ||
@@ -12248,6 +12243,13 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
 		tp->tg3_flags2 &= ~TG3_FLG2_TSO_CAPABLE;
 	} else {
 		tp->tg3_flags2 |= TG3_FLG2_TSO_CAPABLE | TG3_FLG2_TSO_BUG;
+		printk("this code path would have forgotten to load the firmware\n");
+	}
+	if (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE) {
+		if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705)
+			fw_name = "tigon/tg3_tso5.bin";
+		else
+			fw_name = "tigon/tg3_tso.bin";
 	}
 
 	if (fw_name) {


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



---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: linux-next: Tree for June 26

[Kamalesh Babulal]

David Woodhouse wrote:
> On Fri, 2008-06-27 at 01:38 +0200, Rafael J. Wysocki wrote:
>> commit 423c982fffb1cd95c8cdd654ce5ab59351ba41f5
>> Author: Jaswinder Singh <jaswinder@infradead.org>
>> Date:   Wed Jun 18 19:58:33 2008 +0530
>>
>>     firmware: convert tg3 driver to request_firmware()
>>
>> breaks my nx6325.
>>
>> Apparently, with this patch applied the tg3 has a NULL pointer dereference
>> somewhere, but I can only see the first line of the oops, afterwards the box
>> hangs solid.
> 
> That's a 5705, isn't it? So using the 'tso5' firmware?
> 
> Is that firmware available (did you either build it into your kernel, or
> run 'make INSTALL_FW_PATH=/lib/firmware firmware_install')? 
> 
> Not that it matters; I suspect the driver isn't trying to load it at
> all. Can you test this patch, please?
> 
> (There are more cleanups I want to do to the error paths here, but those
> should be harmless and irrelevant: http://david.woodhou.se/tg3.patch )
> 
> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> index a70147d..bad784b 100644
> --- a/drivers/net/tg3.c
> +++ b/drivers/net/tg3.c
> @@ -12234,11 +12234,6 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
> 
>  	if (tp->tg3_flags2 & TG3_FLG2_HW_TSO) {
>  		tp->tg3_flags2 |= TG3_FLG2_TSO_CAPABLE;
> -
> -		if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705)
> -			fw_name = "tigon/tg3_tso5.bin";
> -		else
> -			fw_name = "tigon/tg3_tso.bin";
>  	}
>  	else if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 ||
>  	    GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701 ||
> @@ -12248,6 +12243,13 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
>  		tp->tg3_flags2 &= ~TG3_FLG2_TSO_CAPABLE;
>  	} else {
>  		tp->tg3_flags2 |= TG3_FLG2_TSO_CAPABLE | TG3_FLG2_TSO_BUG;
> +		printk("this code path would have forgotten to load the firmware\n");
> +	}
> +	if (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE) {
> +		if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705)
> +			fw_name = "tigon/tg3_tso5.bin";
> +		else
> +			fw_name = "tigon/tg3_tso.bin";
>  	}
> 
>  	if (fw_name) {
> 
Hi David,

Thanks, the patch fixes the kernel panic on x86_64 boxes. (the panic message
is listed below)

Tested-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>

BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: [<ffffffff803be1e8>] tg3_reset_hw+0xf48/0x154b
PGD add0067 PUD ad1a067 PMD 0 
Oops: 0000 [1] SMP 
last sysfs file: /sys/class/net/eth1/address
CPU 2 
Modules linked in: battery ac lp parport_pc parport nvram amd_rng rng_core i2c_amd756 i2c_core pcspkr button
Pid: 1919, comm: ip Not tainted 2.6.26-rc8-next-20080627-autotest #1
RIP: 0010:[<ffffffff803be1e8>]  [<ffffffff803be1e8>] tg3_reset_hw+0xf48/0x154b
RSP: 0018:ffff81000ad21d38  EFLAGS: 00010246
RAX: 000000000040a026 RBX: 000000000001f800 RCX: 0000000000000000
RDX: 0000000000000006 RSI: 0000000000005400 RDI: ffff81003d4e8740
RBP: ffff81003d4e8740 R08: 0000000000000002 R09: 0000000000000008
R10: 0000000000000009 R11: ffffffff804773d9 R12: 0000000001000008
R13: 00000000000003fe R14: ffff81003d4e8748 R15: 0000000000000000
FS:  00007f600a2586f0(0000) GS:ffff81003f99e800(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000008 CR3: 000000000c0c6000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process ip (pid: 1919, threadinfo ffff81000ad20000, task ffff81003d519db0)
Stack:  ffff81003d4e8740 0000000000000074 0000000000000028 ffff000880340430
 ffff81003d4e8740 ffff81003d4e8800 ffff81003d4e8740 0000000000001002
 0000000000000000 ffff81003d4e8748 ffff81003d4e8000 ffffffff803c2a7a
Call Trace:
 [<ffffffff803c2a7a>] tg3_open+0x29a/0x5e8
 [<ffffffff80317af4>] selinux_capable+0x87/0x90
 [<ffffffff80486e13>] dev_open+0x6b/0x9e
 [<ffffffff80484fd8>] dev_change_flags+0xa6/0x15d
 [<ffffffff804c42ed>] devinet_ioctl+0x243/0x59e
 [<ffffffff80278baf>] handle_mm_fault+0x32b/0x6a5
 [<ffffffff80479488>] sock_ioctl+0x1d4/0x1f8
 [<ffffffff8029eb09>] vfs_ioctl+0x21/0x6b
 [<ffffffff8029edaf>] do_vfs_ioctl+0x25c/0x275
 [<ffffffff8029ee19>] sys_ioctl+0x51/0x70
 [<ffffffff8020bcfb>] system_call_after_swapgs+0x7b/0x80


Code: ef e8 63 a0 ff ff 8b 85 88 07 00 00 a8 20 0f 84 06 01 00 00 a9 00 00 01 08 0f 85 fb 00 00 00 48 8b 8d 48 0b 00 00 be 00 54 00 00 <48> 8b 51 08 8b 42 04 48 83 c2 0c 0f c8 89 04 24 8b 01 b9 00 40 
RIP  [<ffffffff803be1e8>] tg3_reset_hw+0xf48/0x154b
 RSP <ffff81000ad21d38>
CR2: 0000000000000008
---[ end trace beeca7990caa7b8a ]---
Kernel panic - not syncing: Aiee, killing interrupt handler!
Pid: 1919, comm: ip Tainted: G      D   2.6.26-rc8-next-20080627-autotest #1

Call Trace:
 [<ffffffff802336e3>] panic+0x86/0x144
 [<ffffffff802530a9>] kallsyms_lookup+0x49/0x80
 [<ffffffff803be1e8>] tg3_reset_hw+0xf48/0x154b
 [<ffffffff80234256>] printk+0x4e/0x56
 [<ffffffff80234256>] printk+0x4e/0x56
 [<ffffffff802367d6>] do_exit+0x71/0x67c
 [<ffffffff804fdbe1>] oops_begin+0x0/0x8c
 [<ffffffff804ffafb>] do_page_fault+0x77b/0x834
 [<ffffffff804fd829>] error_exit+0x0/0x51
 [<ffffffff804773d9>] pci_conf1_write+0x0/0xdb
 [<ffffffff803be1e8>] tg3_reset_hw+0xf48/0x154b
 [<ffffffff803be0b3>] tg3_reset_hw+0xe13/0x154b
 [<ffffffff803c2a7a>] tg3_open+0x29a/0x5e8
 [<ffffffff80317af4>] selinux_capable+0x87/0x90
 [<ffffffff80486e13>] dev_open+0x6b/0x9e
 [<ffffffff80484fd8>] dev_change_flags+0xa6/0x15d
 [<ffffffff804c42ed>] devinet_ioctl+0x243/0x59e
 [<ffffffff80278baf>] handle_mm_fault+0x32b/0x6a5
 [<ffffffff80479488>] sock_ioctl+0x1d4/0x1f8
 [<ffffffff8029eb09>] vfs_ioctl+0x21/0x6b
 [<ffffffff8029edaf>] do_vfs_ioctl+0x25c/0x275
 [<ffffffff8029ee19>] sys_ioctl+0x51/0x70
 [<ffffffff8020bcfb>] system_call_after_swapgs+0x7b/0x80



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

Re: linux-next: Tree for June 26

[David Woodhouse]

On Fri, 2008-06-27 at 18:12 +0530, Kamalesh Babulal wrote:
> Thanks, the patch fixes the kernel panic on x86_64 boxes.

Thanks. I'll update my git tree and it should appear in tomorrow's
linux-next.

-- 
dwmw2

Re: linux-next: Tree for June 26

[Rafael J. Wysocki]

On Friday, 27 of June 2008, David Woodhouse wrote:
> On Fri, 2008-06-27 at 01:38 +0200, Rafael J. Wysocki wrote:
> > commit 423c982fffb1cd95c8cdd654ce5ab59351ba41f5
> > Author: Jaswinder Singh <jaswinder-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> > Date:   Wed Jun 18 19:58:33 2008 +0530
> > 
> >     firmware: convert tg3 driver to request_firmware()
> > 
> > breaks my nx6325.
> > 
> > Apparently, with this patch applied the tg3 has a NULL pointer dereference
> > somewhere, but I can only see the first line of the oops, afterwards the box
> > hangs solid.
> 
> That's a 5705, isn't it? So using the 'tso5' firmware?
> 
> Is that firmware available (did you either build it into your kernel, or
> run 'make INSTALL_FW_PATH=/lib/firmware firmware_install')? 

I built it into the kernel.

> Not that it matters; I suspect the driver isn't trying to load it at
> all. Can you test this patch, please?

Unfortunately, it doesn't help.  The driver either oopses or just doesn't work
(I don't know what exactly causes it to oops, although that only happens during
boot).

However, Ingo wrote that

" the firmware image, if i compare the before and after tg3FwText 
hex dump is blatantly different. Is this some different format, or did 
the "convert to request_firmware()" commit also embed an undocumented 
version jump in the binary blob that is loaded to your card? "

May this be the source of the problem?

Rafael

Re: linux-next: Tree for June 26

[Jaswinder Singh]

Hello Rafael,

I am really sorry for inconvenience.

I do not have this hardware around me to test this patch.
I really need your help to figure out where is problem.

On Sat, 2008-06-28 at 01:04 +0200, Rafael J. Wysocki wrote:
> On Friday, 27 of June 2008, David Woodhouse wrote:
> > On Fri, 2008-06-27 at 01:38 +0200, Rafael J. Wysocki wrote:
> > > commit 423c982fffb1cd95c8cdd654ce5ab59351ba41f5
> > > Author: Jaswinder Singh <jaswinder@infradead.org>
> > > Date:   Wed Jun 18 19:58:33 2008 +0530
> > > 
> > >     firmware: convert tg3 driver to request_firmware()
> > > 
> > > breaks my nx6325.
> > > 
> > > Apparently, with this patch applied the tg3 has a NULL pointer dereference
> > > somewhere, but I can only see the first line of the oops, afterwards the box
> > > hangs solid.
> > 
> > That's a 5705, isn't it? So using the 'tso5' firmware?
> > 

Here is updated patch :-

http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=aa8b184d8eb4f1d7b5e37d5ad449fb7c02ad79c2

Original tg3 driver have 3 firmwares :-
1. static const u32 tg3FwText[(TG3_FW_TEXT_LEN / sizeof(u32)) + 1]
2. static const u32 tg3TsoFwText[(TG3_TSO_FW_TEXT_LEN / 4) + 1]
3. static const u32 tg3Tso5FwText[(TG3_TSO5_FW_TEXT_LEN / 4) + 1]

your hardware needs which of the above firmware.

> Unfortunately, it doesn't help.  The driver either oopses or just doesn't work
> (I don't know what exactly causes it to oops, although that only happens during
> boot).
> 

Please give us more info about oops.

You always get oops or sometimes.

If you want I can put some debugging message.

> However, Ingo wrote that
> 
> " the firmware image, if i compare the before and after tg3FwText 
> hex dump is blatantly different. Is this some different format, or did 
> the "convert to request_firmware()" commit also embed an undocumented 
> version jump in the binary blob that is loaded to your card? "
> 
> May this be the source of the problem?
> 

No, firmware is same.

Our Firmware blob looks like this...
	u8 firmware_major
	u8 firmware_minor
	u8 firmware_fix
	u8 pad
	__be32 start_address
	__be32 length (total, including BSS sections to be zeroed)
	data... (in __be32 words, which is native for the firmware)

rest of data is same and you can see it manually.

I am surprise why Ingo is using hex dump and he finds different data.

And I did not received any feedback from Ingo yet.

Thank you,

Jaswinder Singh.

Re: linux-next: Tree for June 26

[David Woodhouse]

On Sat, 2008-06-28 at 15:24 +0530, Jaswinder Singh wrote:
> Here is updated patch :-
> 
> http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=aa8b184d8eb4f1d7b5e37d5ad449fb7c02ad79c2

You can ignore that; it's just the same as today's linux-next (which in
turn is just the same as yesterday's + the patch which fixes the problem
for Kamalesh but not for you + the other minor error path cleanup.

Please could you try the other debugging patch I just sent, on top of
today's linux-next? It should confirm that you're using the 'Tso5'
firmware, as I told Jaswinder yesterday, and give us a little more clue
as to what's going on.

This is your machine, right? ...

http://www.ussg.iu.edu/hypermail/linux/kernel/0709.3/1619.html

tg3.c:v3.81 (September 5, 2007)
ACPI: PCI Interrupt 0000:02:01.0[A] -> GSI 23 (level, low) -> IRQ 23
eth1: Tigon3 [partno(BCM95788A50) rev 3003 PHY(5705)] (PCI:33MHz:32-bit) 10/100/1000Base-T Ethernet 00:17:08:2e:2e:f3
eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[0] TSOcap[1]
eth1: dma_rwctrl[763f0000] dma_mask[32-bit]

 tp->pci_chip_rev_id is 0x3003, which is ASIC_REV_5705.

-- 
dwmw2

Re: linux-next: Tree for June 26

[Rafael J. Wysocki]

On Saturday, 28 of June 2008, David Woodhouse wrote:
> On Sat, 2008-06-28 at 15:24 +0530, Jaswinder Singh wrote:
> > Here is updated patch :-
> > 
> > http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=aa8b184d8eb4f1d7b5e37d5ad449fb7c02ad79c2
> 
> You can ignore that; it's just the same as today's linux-next (which in
> turn is just the same as yesterday's + the patch which fixes the problem
> for Kamalesh but not for you + the other minor error path cleanup.
> 
> Please could you try the other debugging patch I just sent, on top of
> today's linux-next? It should confirm that you're using the 'Tso5'
> firmware, as I told Jaswinder yesterday, and give us a little more clue
> as to what's going on.

I tested with the debug patch on top of
http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=aa8b184d8eb4f1d7b5e37d5ad449fb7c02ad79c2

dmesg output is at: http://www.sisk.pl/kernel/debug/20080627/dmesg-1.log
the .config is at: http://www.sisk.pl/kernel/debug/20080627/config-1

and it looks like the card just can't load the firmware.

> This is your machine, right? ...
> 
> http://www.ussg.iu.edu/hypermail/linux/kernel/0709.3/1619.html

Yes, this is the one.

Thanks,
Rafael

Re: linux-next: Tree for June 26

[David Woodhouse]

On Sun, 2008-06-29 at 02:15 +0200, Rafael J. Wysocki wrote:
> On Saturday, 28 of June 2008, David Woodhouse wrote:
> > On Sat, 2008-06-28 at 15:24 +0530, Jaswinder Singh wrote:
> > > Here is updated patch :-
> > > 
> > > http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=aa8b184d8eb4f1d7b5e37d5ad449fb7c02ad79c2
> > 
> > You can ignore that; it's just the same as today's linux-next (which in
> > turn is just the same as yesterday's + the patch which fixes the problem
> > for Kamalesh but not for you + the other minor error path cleanup.
> > 
> > Please could you try the other debugging patch I just sent, on top of
> > today's linux-next? It should confirm that you're using the 'Tso5'
> > firmware, as I told Jaswinder yesterday, and give us a little more clue
> > as to what's going on.
> 
> I tested with the debug patch on top of
> http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=aa8b184d8eb4f1d7b5e37d5ad449fb7c02ad79c2
> 
> dmesg output is at: http://www.sisk.pl/kernel/debug/20080627/dmesg-1.log
> the .config is at: http://www.sisk.pl/kernel/debug/20080627/config-1
> 
> and it looks like the card just can't load the firmware.

Ah, you have it configured as a module, not built-in. You need to run
'make INSTALL_FW_PATH=/lib/firmware firmware_install'

-- 
dwmw2

Re: linux-next: Tree for June 26

[Rafael J. Wysocki]

On Sunday, 29 of June 2008, David Woodhouse wrote:
> On Sun, 2008-06-29 at 02:15 +0200, Rafael J. Wysocki wrote:
> > On Saturday, 28 of June 2008, David Woodhouse wrote:
> > > On Sat, 2008-06-28 at 15:24 +0530, Jaswinder Singh wrote:
> > > > Here is updated patch :-
> > > > 
> > > > http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=aa8b184d8eb4f1d7b5e37d5ad449fb7c02ad79c2
> > > 
> > > You can ignore that; it's just the same as today's linux-next (which in
> > > turn is just the same as yesterday's + the patch which fixes the problem
> > > for Kamalesh but not for you + the other minor error path cleanup.
> > > 
> > > Please could you try the other debugging patch I just sent, on top of
> > > today's linux-next? It should confirm that you're using the 'Tso5'
> > > firmware, as I told Jaswinder yesterday, and give us a little more clue
> > > as to what's going on.
> > 
> > I tested with the debug patch on top of
> > http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=aa8b184d8eb4f1d7b5e37d5ad449fb7c02ad79c2
> > 
> > dmesg output is at: http://www.sisk.pl/kernel/debug/20080627/dmesg-1.log
> > the .config is at: http://www.sisk.pl/kernel/debug/20080627/config-1
> > 
> > and it looks like the card just can't load the firmware.
> 
> Ah, you have it configured as a module, not built-in. You need to run
> 'make INSTALL_FW_PATH=/lib/firmware firmware_install'

# make INSTALL_FW_PATH=/lib/firmware firmware_install
make -C /home/rafael/src/linux-next O=/home/rafael/src/build/next/albercik/. firmware_install
make[3]: *** No rule to make target `firmware/acenic/tg1.bin', needed by `/lib/firmware/acenic/tg1.bin'.  Stop.
make[2]: *** [firmware_install] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2

Re: linux-next: Tree for June 26

[David Woodhouse]

On Sun, 2008-06-29 at 13:36 +0200, Rafael J. Wysocki wrote:
> # make INSTALL_FW_PATH=/lib/firmware firmware_install
> make -C /home/rafael/src/linux-next
> O=/home/rafael/src/build/next/albercik/. firmware_install
> make[3]: *** No rule to make target `firmware/acenic/tg1.bin', needed
> by `/lib/firmware/acenic/tg1.bin'.  Stop.
> make[2]: *** [firmware_install] Error 2
> make[1]: *** [sub-make] Error 2
> make: *** [all] Error 2

Ah, sorry -- I haven't been testing firmware_install with O= builds very
often, and I seem to have broken it. This should fix it:

--- a/firmware/Makefile
+++ b/firmware/Makefile
@@ -69,7 +69,7 @@ fw-shipped-y :=
 endif
 
 firmware-y    := $(fw-external-y) $(fw-shipped-y)
-firmware-dirs := $(sort $(patsubst %,$(objtree)/$(obj)/%/,$(dir $(firmware-y))))
+firmware-dirs := $(sort $(patsubst %,$(objtree)/$(obj)/%/,$(dir $(firmware-y) $(fw-shipped-))))
 
 quiet_cmd_mkdir = MKDIR   $(patsubst $(objtree)/%,%,$@)
       cmd_mkdir = mkdir -p $@


-- 
dwmw2

Re: linux-next: Tree for June 26

[Ingo Molnar]

* Jaswinder Singh <jaswinder@infradead.org> wrote:

> No, firmware is same.
> 
> Our Firmware blob looks like this...
> 	u8 firmware_major
> 	u8 firmware_minor
> 	u8 firmware_fix
> 	u8 pad
> 	__be32 start_address
> 	__be32 length (total, including BSS sections to be zeroed)
> 	data... (in __be32 words, which is native for the firmware)
> 
> rest of data is same and you can see it manually.
> 
> I am surprise why Ingo is using hex dump and he finds different data.
> 
> And I did not received any feedback from Ingo yet.

sorry - it was just a drive-by comment i made to Rafael while i reacted 
to the x86 portion of his mail - i dont have this tg3 problem myself so 
there's nothing i could report or test. I only looked at the patch that 
was identified and the tg3FwText[] array appeared to be different - but 
as you explain it above, that is OK and the firmware image is the same.

	Ingo

Re: linux-next: Tree for June 26

[David Woodhouse]

On Sat, 2008-06-28 at 01:04 +0200, Rafael J. Wysocki wrote:
> Unfortunately, it doesn't help.  The driver either oopses or just doesn't work
> (I don't know what exactly causes it to oops, although that only happens during
> boot).

Hm, do you get any more useful output with this...?

diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 8c0631b..3bcf128 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -5670,6 +5670,11 @@ static int tg3_load_firmware_cpu(struct tg3 *tp, u32 cpu_base, u32 cpu_scratch_b
 	int err, lock_err, i;
 	void (*write_op)(struct tg3 *, u32, u32);
 
+	printk("%s, base %x scratch %x,%x info %x,%x,%p[%x,%x...]\n",
+	       __func__, cpu_base, cpu_scratch_base, cpu_scratch_size,
+	       info->fw_base, info->fw_len, info->fw_data, info->fw_data[0],
+	       info->fw_data[1]);
+
 	if (cpu_base == TX_CPU_BASE &&
 	    (tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) {
 		printk(KERN_ERR PFX "tg3_load_firmware_cpu: Trying to load "
@@ -5697,12 +5702,18 @@ static int tg3_load_firmware_cpu(struct tg3 *tp, u32 cpu_base, u32 cpu_scratch_b
 		write_op(tp, cpu_scratch_base + i, 0);
 	tw32(cpu_base + CPU_STATE, 0xffffffff);
 	tw32(cpu_base + CPU_MODE, tr32(cpu_base+CPU_MODE)|CPU_MODE_HALT);
-	for (i = 0; i < (info->fw_len / sizeof(u32)); i++)
+	for (i = 0; i < (info->fw_len / sizeof(u32)); i++) {
+		if ((i < 5) || i > ((info->fw_len / 4) - 5))
+			printk("Write word at %x: %x\n", 
+			       cpu_scratch_base +
+			       (info->fw_base & 0xffff) +
+			       (i * sizeof(u32)),
+			       be32_to_cpu(info->fw_data[i]));
 		write_op(tp, (cpu_scratch_base +
 			      (info->fw_base & 0xffff) +
 			      (i * sizeof(u32))),
 			      be32_to_cpu(info->fw_data[i]));
-
+	}
 	err = 0;
 
 out:
@@ -5716,6 +5727,8 @@ static int tg3_load_5701_a0_firmware_fix(struct tg3 *tp)
 	const __be32 *fw_data;
 	int err, i;
 
+	printk("%s, fw %p\n", __func__, tp->fw);
+
 	fw_data = (void *)tp->fw->data;
 
 	/* Firmware blob starts with version numbers, followed by
@@ -5778,6 +5791,8 @@ static int tg3_load_tso_firmware(struct tg3 *tp)
 	if (tp->tg3_flags2 & TG3_FLG2_HW_TSO)
 		return 0;
 
+	printk("%s, fw %p\n", __func__, tp->fw);
+
 	fw_data = (void *)tp->fw->data;
 
 	/* Firmware blob starts with version numbers, followed by
@@ -12253,6 +12268,7 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
 	if (fw_name) {
 		const __be32 *fw_data;
 
+		printk("tg3 request firmware %s\n", fw_name);
 		err = request_firmware(&tp->fw, fw_name, &tp->pdev->dev);
 		if (err) {
 			printk(KERN_ERR "tg3: Failed to load firmware \"%s\"\n",
@@ -12273,7 +12289,9 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
 			err = -EINVAL;
 			goto err_out_fw;
 		}
-	}
+		printk("tg3 loaded fw %s, len %x\n", fw_name, tp->fw_len);
+	} else
+		printk("tg3 no firmware\n");
 
 	/* TSO is on by default on chips that support hardware TSO.
 	 * Firmware TSO on older chips gives lower performance, so it

> However, Ingo wrote that
> 
> " the firmware image, if i compare the before and after tg3FwText 
> hex dump is blatantly different. Is this some different format, or did 
> the "convert to request_firmware()" commit also embed an undocumented 
> version jump in the binary blob that is loaded to your card? "

Where did Ingo write that? Google doesn't show any instance of those
words other than your own quote, and I'm fairly sure he didn't Cc me
when he said it.

The firmware images are a straight binary dump of what was in the driver
in hex form, stored big-endian, and with a header at the beginning thus:
{
  unsigned char major, minor, fix, pad;
  __be32 load_address;
  __be32 length; // including BSS to be zeroed
  __be32 data[];
}

The TEXT/RODATA/DATA regions were all fairly much contiguous anyway, so
they just appear one after the other in the data[] blob. Let's run 'make
firmware_install' and look at usr/lib/firmware/tigon/tg3.bin... (with
'od -A x -t x4' on a big-endian box):

	000000 00000000 08000000 00000a80 00000000
	000010 10000003 00000000 0000000d 0000000d
	000020 3c1d0800 37bd3ffc 03a0f021 3c100800
	   ... text ...
	0009b0 00851024 1443ffe8 00851824 27bd0008
	0009c0 03e00008 00000000 00000000 35373031
	0009d0 726c7341 00000000 00000000 53774576
	   ... data ...
	000a10 6c457272 00000000 00000000 4d61696e
	000a20 43707542 00000000 00000000 00000000
	000a30 00000000 00000000 00000000 00000000
	*
	000a60 00000000 00000000 00000000

That does look like Tg3FwText[] starts at 0xC after the header (with
0x0, 0x10000003, 0x0, 0xd, 0xd, 0x3c1d0800...) as it should. It ends
with 0x00851824, 0x27bd0008, 0x03e00008, 0x0, 0x0 as it should, at
offset 0x9cc in the file (there's a superfluous 0 on the end of each
word array in the driver). Then you see tg3FwRodata[] starting
0x35373031, 0x726c7341, 0x0, 0x0, 0x53774576..., and tg3FwData[] is all
zeroes at the end.

I don't think you're using that firmware though; I think you're using
tg3_tso5.bin? That one looks fine to me too -- Tg3Tso5Fw[] starts with
0x0c004003, 0x0, 0x10f04, 0x0, 0x10000003 at offset 0xC in the file, as
it should, and ends at 0xe9C with 0x03e00008, 0xac4b001c, 0x0, 0x0. Then
the 0x50 bytes of Tg3Tso5FwRodata[] appear from 0xe9c-0xeec as they
should. And then there's a gap between the end of the rodata, and
Tg3TsoData[] at 0xf0c.

	000000 01020000 00010000 00000fd8 0c004003
	000010 00000000 00010f04 00000000 10000003
	   ... text ...
	000e80 ac460010 ac470014 ac4a0018 03e00008
	000e90 ac4b001c 00000000 00000000 4d61696e
	000ea0 43707542 00000000 4d61696e 43707541
	   ... rodata ...
	000ee0 6c457272 00000000 00000000 00000000
	000ef0 00000000 00000000 00000000 00000000
	000f00 00000000 00000000 00000000 00000000
	000f10 73746b6f 66666c64 5f76312e 322e3000
	000f20 00000000 00000000 00000000

I went over the binary files quite carefully, have just done so again,
and I don't see a problem with them. If Ingo sees one, then he's
cleverer than me. But quite naughty for not Ccing me when he pointed it
out.

-- 
dwmw2

linux-next: Tree for June 26

[Stephen Rothwell]

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

Hi all,

Changes since 20090625:

My fixes tree contains these two commits:

	fbdev: work around old compiler bug

This tree fails to build for powerpc allyesconfig.

Linus' tree lost its build failure.

The block tree lost its complex conflict against Linus' tree but gained a
build failure for which I reverted a commit.

The rr tree has a build failure (for UML) for which I applied a patch.

The tip tree gained a conflict against the ttydev tree.

The kvm tree gained a build failure for which I applied a patch.

The hid tree gained a build failure for which I reverted 2 commits.

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

I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES) and i386, sparc and sparc64 defconfig.
These builds also have CONFIG_ENABLE_WARN_DEPRECATED,
CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 130 trees (counting Linus' and 19 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

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

$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging dwmw2/master
Merging arm/devel
Merging davinci/for-next
Merging pxa/for-next
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
CONFLICT (add/add): Merge conflict in arch/mips/cavium-octeon/executive/cvmx-helper-errata.c
CONFLICT (content): Merge conflict in arch/mips/mm/tlbex.c
CONFLICT (content): Merge conflict in arch/mips/sibyte/swarm/setup.c
CONFLICT (content): Merge conflict in drivers/char/hw_random/Kconfig
CONFLICT (content): Merge conflict in drivers/char/hw_random/Makefile
CONFLICT (add/add): Merge conflict in drivers/dma/txx9dmac.c
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging xtensa/master
Merging cifs/master
Merging configfs/linux-next
CONFLICT (content): Merge conflict in fs/configfs/dir.c
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging jfs/next
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging squashfs/master
Merging v9fs/for-next
CONFLICT (content): Merge conflict in net/9p/protocol.c
Merging ubifs/linux-next
Merging xfs/master
Merging reiserfs-bkl/reiserfs/kill-bkl-rc6
CONFLICT (content): Merge conflict in fs/reiserfs/super.c
Merging vfs/for-next
Merging pci/linux-next
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging quota/for_next
Merging kbuild/master
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging async_tx/next
Merging udf/for_next
Merging net/master
Merging wireless/master
Merging mtd/master
Merging crypto/master
Merging sound/for-next
Merging cpufreq/next
Merging quilt/rr
CONFLICT (content): Merge conflict in kernel/cpu.c
Applying: UML: Fix some apparent bitrot in mmu_context.h
Merging mmc/next
Merging input/next
Merging bkl-removal/bkl-removal
Merging lsm/for-next
Merging block/for-next
[master fdbcf39] Revert "Restore barrier support for md and probably other virtual devices."
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging quilt/ttydev
Merging agp/agp-next
Merging uwb/for-upstream
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging omap/for-next
Merging quilt/aoe
Merging suspend/linux-next
Merging bluetooth/master
Merging edac-amd/for-next
Merging fsnotify/for-next
Merging irda/for-next
Merging hwlat/for-linus
Merging tip/auto-latest
CONFLICT (content): Merge conflict in arch/x86/include/asm/termios.h
Merging asm-generic/next
Merging quilt/driver-core
Merging quilt/usb
Merging quilt/staging
Merging scsi-post-merge/master
Applying: kvm/powerpc: fix build error
[master 8957949] Revert "HID: use debugfs for events/reports dumping"
[master 275f907] Revert "HID: use debugfs for report dumping descriptor"

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