linux-next: Tree for April 10

linux-next: Tree for April 10

[Stephen Rothwell]

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

Hi all,

[I have been asked to provide a summary of changes before the biolerplate
so here goes (please tell me if this is what you want or not).  I am not
going to try to describe the changes in the individual trees, just the
interactions between them.]

Changes since next-20080410:

I no longer revert "x86: phase out forced inlining".
There is a new conflict in arch/s390/lib/uaccess_pt.c between the s390 and
	kvm trees.
There is a new trivial white space conflict in arch/ia64/kernel/mca.c.
I no longer need to revert "wusb: add the wireless usb stack to Linux".

Today's Next/Trees file is lying: the x86-latest and sched-latest trees
did not merge/build correctly so have not been included.

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

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

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64.

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

We are up to 55 trees, more are welcome (even if they are currently
empty).  Thanks to those who have contributed, and to those who haven't,
please do.

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

Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ and the guys at http://test.kernel.org/.

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

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

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

[BUG] linux-next: Tree for April 10 - kernel panic while loading ata driver on powermac

[Kamalesh Babulal]

Hi Stephen,

The next-20080410 kernel panics while bootup over the PowerMac G5 box, while
loading the ATA driver.

[    3.704000] Faulting instruction address: 0xc0000000000222a8
[    3.704000] Oops: Kernel access of bad area, sig: 11 [#1]
[    3.704000] SMP NR_CPUS=32 NUMA PowerMac
[    3.704000] Modules linked in:
[    3.704000] NIP: c0000000000222a8 LR: c00000000021cd10 CTR: 0000000000000100
[    3.704000] REGS: c0000002760db070 TRAP: 0300   Not tainted  (2.6.25-rc8-next-20080410-autokern1)
[    3.704000] MSR: 9000000000009032 <EE,ME,IR,DR>  CR: 44000042  XER: 20000000
[    3.704000] DAR: a0001000822fa000, DSISR: 0000000040000000
[    3.704000] TASK = c0000002760d7100[1] 'swapper' THREAD: c0000002760d8000 CPU: 0
[    3.704000] GPR00: 0000000000000100 c0000002760db2f0 c000000000498310 a0001000822fa000 
[    3.704000] GPR04: c000000274806a00 0000000000000100 0000000000000201 c00000000000fed4 
[    3.704000] GPR08: c0000002760daf20 c0000000003ee0d8 c0000000004f1428 0000000000000000 
[    3.704000] GPR12: 0000000000000000 c0000000003fa700 0000000000000000 0000000000000000 
[    3.704000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 
[    3.704000] GPR20: 0000000000000001 0000000000000027 0000000000000027 0000000000000000 
[    3.704000] GPR24: c0000000004f1400 0000000000000000 0000000000000201 c0000000004f1490 
[    3.704000] GPR28: a0001000822fa000 0000000000000200 c00000000044cf50 c000000274806a00 
[    3.704000] NIP [c0000000000222a8] ._insw_ns+0x10/0x30
[    3.704000] LR [c00000000021cd10] .ata_input_data+0x1f4/0x264
[    3.704000] Call Trace:
[    3.704000] [c0000002760db2f0] [c0000002760d7100] 0xc0000002760d7100 (unreliable)
[    3.704000] [c0000002760db3b0] [c00000000021fc34] .try_to_identify+0x298/0x690
[    3.704000] [c0000002760db470] [c000000000220168] .do_probe+0x13c/0x2f0
[    3.704000] [c0000002760db510] [c00000000022059c] .ide_probe_port+0x280/0x670
[    3.704000] [c0000002760db5e0] [c000000000220d84] .ide_device_add_all+0x2f8/0x670
[    3.704000] [c0000002760db690] [c000000000221160] .ide_device_add+0x64/0x74
[    3.704000] [c0000002760db720] [c0000000002f7e14] 0xc0000000002f7e14
[    3.704000] [c0000002760db810] [c0000000002f8028] 0xc0000000002f8028
[    3.704000] [c0000002760db930] [c00000000019241c] .pci_device_probe+0x10c/0x184
[    3.704000] [c0000002760db9e0] [c0000000002068ac] .driver_probe_device+0x120/0x1e4
[    3.704000] [c0000002760dba70] [c0000000002069d0] .__driver_attach+0x60/0xa4
[    3.704000] [c0000002760dbb00] [c0000000002050e8] .bus_for_each_dev+0x7c/0xcc
[    3.704000] [c0000002760dbbb0] [c000000000206388] .driver_attach+0x28/0x40
[    3.704000] [c0000002760dbc30] [c000000000206154] .bus_add_driver+0xd4/0x274
[    3.704000] [c0000002760dbcd0] [c000000000206f04] .driver_register+0x90/0x14c
[    3.704000] [c0000002760dbd70] [c000000000191c80] .__pci_register_driver+0x68/0xc8
[    3.704000] [c0000002760dbe10] [c0000000003ccfb8] .pmac_ide_probe+0x48/0x94
[    3.704000] [c0000002760dbea0] [c0000000003a3bf4] .kernel_init+0x1e4/0x3a4
[    3.704000] [c0000002760dbf90] [c000000000022648] .kernel_thread+0x4c/0x68
[    3.704000] Instruction dump:
[    3.704000] 88030000 7c0006ac 98040000 38840001 4200fff0 0c000000 4c00012c 4e800020 
[    3.704000] 7ca02b79 7c0903a6 4c810020 7c0004ac <a0030000> 7c0006ac b0040000 38840002 
[    3.704000] ---[ end trace 0c3e1cc71183fc17 ]---
[    3.704000] Kernel panic - not syncing: Attempted to kill init!
[    3.704000] Call Trace:
[    3.704000] [c0000002760dac20] [c000000000010474] .show_stack+0x74/0x1ac (unreliable)
[    3.704000] [c0000002760dacd0] [c000000000051d38] .panic+0x80/0x194
[    3.704000] [c0000002760dae20] [c000000000056e60] .do_exit+0x98/0x74c
[    3.704000] [c0000002760daee0] [c000000000020680] .die+0x1c8/0x1cc
[    3.704000] [c0000002760daf80] [c000000000027a50] .bad_page_fault+0xb8/0xd4
[    3.704000] [c0000002760db000] [c000000000004f98] handle_page_fault+0x3c/0x5c
[    3.704000] --- Exception: 300 at ._insw_ns+0x10/0x30
[    3.704000]     LR = .ata_input_data+0x1f4/0x264
[    3.704000] [c0000002760db2f0] [c0000002760d7100] 0xc0000002760d7100 (unreliable)
[    3.704000] [c0000002760db3b0] [c00000000021fc34] .try_to_identify+0x298/0x690
[    3.704000] [c0000002760db470] [c000000000220168] .do_probe+0x13c/0x2f0
[    3.704000] [c0000002760db510] [c00000000022059c] .ide_probe_port+0x280/0x670
[    3.704000] [c0000002760db5e0] [c000000000220d84] .ide_device_add_all+0x2f8/0x670
[    3.704000] [c0000002760db690] [c000000000221160] .ide_device_add+0x64/0x74
[    3.704000] [c0000002760db720] [c0000000002f7e14] 0xc0000000002f7e14
[    3.704000] [c0000002760db810] [c0000000002f8028] 0xc0000000002f8028
[    3.704000] [c0000002760db930] [c00000000019241c] .pci_device_probe+0x10c/0x184
[    3.704000] [c0000002760db9e0] [c0000000002068ac] .driver_probe_device+0x120/0x1e4
[    3.704000] [c0000002760dba70] [c0000000002069d0] .__driver_attach+0x60/0xa4
[    3.704000] [c0000002760dbb00] [c0000000002050e8] .bus_for_each_dev+0x7c/0xcc
[    3.704000] [c0000002760dbbb0] [c000000000206388] .driver_attach+0x28/0x40
[    3.704000] [c0000002760dbc30] [c000000000206154] .bus_add_driver+0xd4/0x274
[    3.704000] [c0000002760dbcd0] [c000000000206f04] .driver_register+0x90/0x14c
[    3.704000] [c0000002760dbd70] [c000000000191c80] .__pci_register_driver+0x68/0xc8
[    3.704000] [c0000002760dbe10] [c0000000003ccfb8] .pmac_ide_probe+0x48/0x94
[    3.704000] [c0000002760dbea0] [c0000000003a3bf4] .kernel_init+0x1e4/0x3a4
[    3.704000] [c0000002760dbf90] [c000000000022648] .kernel_thread+0x4c/0x68


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

Re: [BUG] linux-next: Tree for April 10 - kernel panic while loading ata driver on powermac

[Jeff Garzik]

Kamalesh Babulal wrote:
> Hi Stephen,
> 
> The next-20080410 kernel panics while bootup over the PowerMac G5 box, while
> loading the ATA driver.

IDE driver, you mean.


> [    3.704000] NIP [c0000000000222a8] ._insw_ns+0x10/0x30
> [    3.704000] LR [c00000000021cd10] .ata_input_data+0x1f4/0x264
> [    3.704000] Call Trace:

> [    3.704000] [c0000002760db3b0] [c00000000021fc34] .try_to_identify+0x298/0x690
> [    3.704000] [c0000002760db470] [c000000000220168] .do_probe+0x13c/0x2f0
> [    3.704000] [c0000002760db510] [c00000000022059c] .ide_probe_port+0x280/0x670
> [    3.704000] [c0000002760db5e0] [c000000000220d84] .ide_device_add_all+0x2f8/0x670
> [    3.704000] [c0000002760db690] [c000000000221160] .ide_device_add+0x64/0x74

> [    3.704000] [c0000002760db930] [c00000000019241c] .pci_device_probe+0x10c/0x184
> [    3.704000] [c0000002760db9e0] [c0000000002068ac] .driver_probe_device+0x120/0x1e4
> [    3.704000] [c0000002760dba70] [c0000000002069d0] .__driver_attach+0x60/0xa4
> [    3.704000] [c0000002760dbb00] [c0000000002050e8] .bus_for_each_dev+0x7c/0xcc
> [    3.704000] [c0000002760dbbb0] [c000000000206388] .driver_attach+0x28/0x40
> [    3.704000] [c0000002760dbc30] [c000000000206154] .bus_add_driver+0xd4/0x274
> [    3.704000] [c0000002760dbcd0] [c000000000206f04] .driver_register+0x90/0x14c
> [    3.704000] [c0000002760dbd70] [c000000000191c80] .__pci_register_driver+0x68/0xc8
> [    3.704000] [c0000002760dbe10] [c0000000003ccfb8] .pmac_ide_probe+0x48/0x94

Regards,

	Jeff

Re: [BUG] linux-next: Tree for April 10 - kernel panic while loading ata driver on powermac

[Kamalesh Babulal]

Jeff Garzik wrote:
> Kamalesh Babulal wrote:
>> Hi Stephen,
>>
>> The next-20080410 kernel panics while bootup over the PowerMac G5 box, while
>> loading the ATA driver.
> 
> IDE driver, you mean.
> 
> 
>> [    3.704000] NIP [c0000000000222a8] ._insw_ns+0x10/0x30
>> [    3.704000] LR [c00000000021cd10] .ata_input_data+0x1f4/0x264
>> [    3.704000] Call Trace:
> 
>> [    3.704000] [c0000002760db3b0] [c00000000021fc34] .try_to_identify+0x298/0x690
>> [    3.704000] [c0000002760db470] [c000000000220168] .do_probe+0x13c/0x2f0
>> [    3.704000] [c0000002760db510] [c00000000022059c] .ide_probe_port+0x280/0x670
>> [    3.704000] [c0000002760db5e0] [c000000000220d84] .ide_device_add_all+0x2f8/0x670
>> [    3.704000] [c0000002760db690] [c000000000221160] .ide_device_add+0x64/0x74
> 
>> [    3.704000] [c0000002760db930] [c00000000019241c] .pci_device_probe+0x10c/0x184
>> [    3.704000] [c0000002760db9e0] [c0000000002068ac] .driver_probe_device+0x120/0x1e4
>> [    3.704000] [c0000002760dba70] [c0000000002069d0] .__driver_attach+0x60/0xa4
>> [    3.704000] [c0000002760dbb00] [c0000000002050e8] .bus_for_each_dev+0x7c/0xcc
>> [    3.704000] [c0000002760dbbb0] [c000000000206388] .driver_attach+0x28/0x40
>> [    3.704000] [c0000002760dbc30] [c000000000206154] .bus_add_driver+0xd4/0x274
>> [    3.704000] [c0000002760dbcd0] [c000000000206f04] .driver_register+0x90/0x14c
>> [    3.704000] [c0000002760dbd70] [c000000000191c80] .__pci_register_driver+0x68/0xc8
>> [    3.704000] [c0000002760dbe10] [c0000000003ccfb8] .pmac_ide_probe+0x48/0x94
> 
> Regards,
> 
> 	Jeff
Hi Jeff,

Looking at the boot log before the kernel oops, I suspected it to be the ide driver causing
the kernel oops, I am trying reproduce the crash with debug info compiled into the kernel.

[    2.236136] Uniform Multi-Platform E-IDE driver
[    2.248211] ide-pmac 0001:03:0d.0: enabling device (0014 -> 0016)
[    3.284006] ide0: Found Apple K2 ATA-6 controller, bus ID 3, irq 39
[    3.700012] Unable to handle kernel paging request for data at address 0xa0001000822fa000
[    3.704000] Faulting instruction address: 0xc0000000000222a8
[    3.704000] Oops: Kernel access of bad area, sig: 11 [#1]
[    3.704000] SMP NR_CPUS=32 NUMA PowerMac
-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

Re: [BUG] linux-next: Tree for April 10 - kernel panic while loading ata driver on powermac

[Alan Cox]

On Thu, 10 Apr 2008 06:45:28 -0400
Jeff Garzik <jeff@garzik.org> wrote:

> Kamalesh Babulal wrote:
> > Hi Stephen,
> > 
> > The next-20080410 kernel panics while bootup over the PowerMac G5 box, while
> > loading the ATA driver.
> 
> IDE driver, you mean.

Jeff - we may in the kernel world use IDE v ATA to distinguish between
the two drivers but both are still ATA drives and I don't think its too
fair to respond this way, especially to someone who has gone to the
trouble of capturing a very good trace.

Alan

Re: [BUG] linux-next: Tree for April 10 - kernel panic while loading ata driver on powermac

[Bartlomiej Zolnierkiewicz]

Hi,

On Thu, Apr 10, 2008 at 12:24 PM, Kamalesh Babulal
<kamalesh@linux.vnet.ibm.com> wrote:
> Hi Stephen,
>
>  The next-20080410 kernel panics while bootup over the PowerMac G5 box, while
>  loading the ATA driver.
>
>  [    3.704000] Faulting instruction address: 0xc0000000000222a8
>  [    3.704000] Oops: Kernel access of bad area, sig: 11 [#1]
>  [    3.704000] SMP NR_CPUS=32 NUMA PowerMac
>  [    3.704000] Modules linked in:
>  [    3.704000] NIP: c0000000000222a8 LR: c00000000021cd10 CTR: 0000000000000100
>  [    3.704000] REGS: c0000002760db070 TRAP: 0300   Not tainted  (2.6.25-rc8-next-20080410-autokern1)
>  [    3.704000] MSR: 9000000000009032 <EE,ME,IR,DR>  CR: 44000042  XER: 20000000
>  [    3.704000] DAR: a0001000822fa000, DSISR: 0000000040000000
>  [    3.704000] TASK = c0000002760d7100[1] 'swapper' THREAD: c0000002760d8000 CPU: 0
>  [    3.704000] GPR00: 0000000000000100 c0000002760db2f0 c000000000498310 a0001000822fa000
>  [    3.704000] GPR04: c000000274806a00 0000000000000100 0000000000000201 c00000000000fed4
>  [    3.704000] GPR08: c0000002760daf20 c0000000003ee0d8 c0000000004f1428 0000000000000000
>  [    3.704000] GPR12: 0000000000000000 c0000000003fa700 0000000000000000 0000000000000000
>  [    3.704000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>  [    3.704000] GPR20: 0000000000000001 0000000000000027 0000000000000027 0000000000000000
>  [    3.704000] GPR24: c0000000004f1400 0000000000000000 0000000000000201 c0000000004f1490
>  [    3.704000] GPR28: a0001000822fa000 0000000000000200 c00000000044cf50 c000000274806a00
>  [    3.704000] NIP [c0000000000222a8] ._insw_ns+0x10/0x30
>  [    3.704000] LR [c00000000021cd10] .ata_input_data+0x1f4/0x264

Could you please add printk() for 'hwif->host_flags', 'mmio' and 'io_32bit'
to ide-iops.c::ata_input_data() so we know more on what is going on?

Thanks,
Bart

Re: [BUG] linux-next: Tree for April 10 - kernel panic while loading ata driver on powermac

[Jeff Garzik]

Alan Cox wrote:
> On Thu, 10 Apr 2008 06:45:28 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
> 
>> Kamalesh Babulal wrote:
>>> Hi Stephen,
>>>
>>> The next-20080410 kernel panics while bootup over the PowerMac G5 box, while
>>> loading the ATA driver.
>> IDE driver, you mean.
> 
> Jeff - we may in the kernel world use IDE v ATA to distinguish between
> the two drivers but both are still ATA drives and I don't think its too
> fair to respond this way, especially to someone who has gone to the
> trouble of capturing a very good trace.

Sure.  The main goal was to copy Bart and linux-ide.  That was just an 
aside.

	Jeff

Re: [BUG] linux-next: Tree for April 10 - kernel panic while loading ata driver on powermac

[Bartlomiej Zolnierkiewicz]

On Thursday 10 April 2008, Bartlomiej Zolnierkiewicz wrote:
> Hi,
> 
> On Thu, Apr 10, 2008 at 12:24 PM, Kamalesh Babulal
> <kamalesh@linux.vnet.ibm.com> wrote:
> > Hi Stephen,
> >
> >  The next-20080410 kernel panics while bootup over the PowerMac G5 box, while
> >  loading the ATA driver.
> >
> >  [    3.704000] Faulting instruction address: 0xc0000000000222a8
> >  [    3.704000] Oops: Kernel access of bad area, sig: 11 [#1]
> >  [    3.704000] SMP NR_CPUS=32 NUMA PowerMac
> >  [    3.704000] Modules linked in:
> >  [    3.704000] NIP: c0000000000222a8 LR: c00000000021cd10 CTR: 0000000000000100
> >  [    3.704000] REGS: c0000002760db070 TRAP: 0300   Not tainted  (2.6.25-rc8-next-20080410-autokern1)
> >  [    3.704000] MSR: 9000000000009032 <EE,ME,IR,DR>  CR: 44000042  XER: 20000000
> >  [    3.704000] DAR: a0001000822fa000, DSISR: 0000000040000000
> >  [    3.704000] TASK = c0000002760d7100[1] 'swapper' THREAD: c0000002760d8000 CPU: 0
> >  [    3.704000] GPR00: 0000000000000100 c0000002760db2f0 c000000000498310 a0001000822fa000
> >  [    3.704000] GPR04: c000000274806a00 0000000000000100 0000000000000201 c00000000000fed4
> >  [    3.704000] GPR08: c0000002760daf20 c0000000003ee0d8 c0000000004f1428 0000000000000000
> >  [    3.704000] GPR12: 0000000000000000 c0000000003fa700 0000000000000000 0000000000000000
> >  [    3.704000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> >  [    3.704000] GPR20: 0000000000000001 0000000000000027 0000000000000027 0000000000000000
> >  [    3.704000] GPR24: c0000000004f1400 0000000000000000 0000000000000201 c0000000004f1490
> >  [    3.704000] GPR28: a0001000822fa000 0000000000000200 c00000000044cf50 c000000274806a00
> >  [    3.704000] NIP [c0000000000222a8] ._insw_ns+0x10/0x30
> >  [    3.704000] LR [c00000000021cd10] .ata_input_data+0x1f4/0x264
> 
> Could you please add printk() for 'hwif->host_flags', 'mmio' and 'io_32bit'
> to ide-iops.c::ata_input_data() so we know more on what is going on?

No longer needed - please test the hot-fix below instead:

---
thanks to Andrew for noticing me about the gcc warning

 drivers/ide/ppc/pmac.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ide/ppc/pmac.c
===================================================================
--- a/drivers/ide/ppc/pmac.c
+++ b/drivers/ide/ppc/pmac.c
@@ -941,7 +941,7 @@ static const struct ide_port_info pmac_p
 	.port_ops		= &pmac_ide_port_ops,
 	.host_flags		= IDE_HFLAG_SET_PIO_MODE_KEEP_DMA |
 				  IDE_HFLAG_POST_SET_MODE |
-				  IDE_HFLAG_UNMASK_IRQS,
+				  IDE_HFLAG_UNMASK_IRQS |
 				  IDE_HFLAG_MMIO,
 	.pio_mask		= ATA_PIO4,
 	.mwdma_mask		= ATA_MWDMA2,

Re: linux-next: Tree for April 10

[Greg KH]

On Thu, Apr 10, 2008 at 06:14:04PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> [I have been asked to provide a summary of changes before the biolerplate
> so here goes (please tell me if this is what you want or not).  I am not
> going to try to describe the changes in the individual trees, just the
> interactions between them.]
> 
> Changes since next-20080410:
> 
> I no longer revert "x86: phase out forced inlining".
> There is a new conflict in arch/s390/lib/uaccess_pt.c between the s390 and
> 	kvm trees.
> There is a new trivial white space conflict in arch/ia64/kernel/mca.c.
> I no longer need to revert "wusb: add the wireless usb stack to Linux".

Very nice, thanks for the summary, I appreciate it.

greg k-h

[BUG] linux-next: April 10 - kernel oops at kmem_cache_alloc () regression from April 9 kernel

[Kamalesh Babulal]

Hi Stephen,

When booting the x86_64 boxes with the next-20080409 and 20080410 kernels
the kernel bug is hit. The same bug was reported for the April 9  kernel
at http://lkml.org/lkml/2008/4/10/63 (this kernel was compiled with 
CONFIG_CC_STACKPROTECTOR is not set)


BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
IP: [<ffffffff802869b1>] kmem_cache_alloc+0x41/0x130
PGD 32dc2e067 PUD 32dd6a067 PMD 0 
Oops: 0000 [1] SMP 
last sysfs file: /sys/kernel/uevent_seqnum
CPU 0 
Modules linked in: sg
Pid: 1, comm: init Not tainted 2.6.25-rc8-next-20080410-autotest #1
RIP: 0010:[<ffffffff802869b1>]  [<ffffffff802869b1>] kmem_cache_alloc+0x41/0x130
RSP: 0000:ffff810bfe4abef8  EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff81090e4aa050 RCX: 0000000000405017
RDX: 00007ffffb4c05b8 RSI: 00000000000000d0 RDI: 0000000000000000
RBP: 0000000000000292 R08: 0000000000586f00 R09: 0000000000586f20
R10: 0000000000586f08 R11: 0000000000000246 R12: 00000000000000d0
R13: 0000000000000000 R14: 0000000000405150 R15: 0000000000000000
FS:  000000000058b850(0063) GS:ffffffff8067f000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 000000090d0e6000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process init (pid: 1, threadinfo ffff810bfe4aa000, task ffff81090e4aa050)
Stack:  0000000000000000 ffff81090e4aa050 ffff81090e4aa050 0000000000000001
 0000000000405110 ffffffff80212f96 0000000000000292 ffff81090e4aa050
 00007ffffb4c05a8 ffffffff8020cb79 0000000000000000 ffffffff804da339
Call Trace:
 [<ffffffff80212f96>] init_fpu+0x96/0xf0
 [<ffffffff8020cb79>] math_state_restore+0x19/0x60
 [<ffffffff804da339>] error_exit+0x0/0x51


Code: 48 89 6c 24 10 49 89 fd 9c 5d fa 65 48 8b 04 25 00 00 00 00 f7 40 14 00 00 00 12 0f 85 b6 00 00 00 65 8b 04 25 24 00 00 00 89 c0 <49> 8b 54 c5 00 8b 02 85 c0 0f 84 cb 00 00 00 8b 02 c7 42 0c 01 
RIP  [<ffffffff802869b1>] kmem_cache_alloc+0x41/0x130
 RSP <ffff810bfe4abef8>
CR2: 0000000000000000
---[ end trace d1dc597e06b986c0 ]---
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: init Tainted: G      D  2.6.25-rc8-next-20080410-autotest #1

Call Trace:
 [<ffffffff80232016>] panic+0x86/0x170
 [<ffffffff802332ce>] printk+0x4e/0x60
 [<ffffffff802332ce>] printk+0x4e/0x60
 [<ffffffff80234f30>] do_exit+0x770/0x780
 [<ffffffff8020c737>] oops_end+0x87/0x90
 [<ffffffff8021ef55>] do_page_fault+0x405/0x890
 [<ffffffff804da339>] error_exit+0x0/0x51
 [<ffffffff802869b1>] kmem_cache_alloc+0x41/0x130
 [<ffffffff80212f96>] init_fpu+0x96/0xf0
 [<ffffffff8020cb79>] math_state_restore+0x19/0x60
 [<ffffffff804da339>] error_exit+0x0/0x51
-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

Re: [BUG] linux-next: Tree for April 10 - kernel panic while loading ata driver on powermac

[Kamalesh Babulal]

Bartlomiej Zolnierkiewicz wrote:
> On Thursday 10 April 2008, Bartlomiej Zolnierkiewicz wrote:
>> Hi,
>>
>> On Thu, Apr 10, 2008 at 12:24 PM, Kamalesh Babulal
>> <kamalesh@linux.vnet.ibm.com> wrote:
>>> Hi Stephen,
>>>
>>>  The next-20080410 kernel panics while bootup over the PowerMac G5 box, while
>>>  loading the ATA driver.
>>>
>>>  [    3.704000] Faulting instruction address: 0xc0000000000222a8
>>>  [    3.704000] Oops: Kernel access of bad area, sig: 11 [#1]
>>>  [    3.704000] SMP NR_CPUS=32 NUMA PowerMac
>>>  [    3.704000] Modules linked in:
>>>  [    3.704000] NIP: c0000000000222a8 LR: c00000000021cd10 CTR: 0000000000000100
>>>  [    3.704000] REGS: c0000002760db070 TRAP: 0300   Not tainted  (2.6.25-rc8-next-20080410-autokern1)
>>>  [    3.704000] MSR: 9000000000009032 <EE,ME,IR,DR>  CR: 44000042  XER: 20000000
>>>  [    3.704000] DAR: a0001000822fa000, DSISR: 0000000040000000
>>>  [    3.704000] TASK = c0000002760d7100[1] 'swapper' THREAD: c0000002760d8000 CPU: 0
>>>  [    3.704000] GPR00: 0000000000000100 c0000002760db2f0 c000000000498310 a0001000822fa000
>>>  [    3.704000] GPR04: c000000274806a00 0000000000000100 0000000000000201 c00000000000fed4
>>>  [    3.704000] GPR08: c0000002760daf20 c0000000003ee0d8 c0000000004f1428 0000000000000000
>>>  [    3.704000] GPR12: 0000000000000000 c0000000003fa700 0000000000000000 0000000000000000
>>>  [    3.704000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>>  [    3.704000] GPR20: 0000000000000001 0000000000000027 0000000000000027 0000000000000000
>>>  [    3.704000] GPR24: c0000000004f1400 0000000000000000 0000000000000201 c0000000004f1490
>>>  [    3.704000] GPR28: a0001000822fa000 0000000000000200 c00000000044cf50 c000000274806a00
>>>  [    3.704000] NIP [c0000000000222a8] ._insw_ns+0x10/0x30
>>>  [    3.704000] LR [c00000000021cd10] .ata_input_data+0x1f4/0x264
>> Could you please add printk() for 'hwif->host_flags', 'mmio' and 'io_32bit'
>> to ide-iops.c::ata_input_data() so we know more on what is going on?
> 
> No longer needed - please test the hot-fix below instead:
> 
> ---
> thanks to Andrew for noticing me about the gcc warning
> 
>  drivers/ide/ppc/pmac.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: b/drivers/ide/ppc/pmac.c
> ===================================================================
> --- a/drivers/ide/ppc/pmac.c
> +++ b/drivers/ide/ppc/pmac.c
> @@ -941,7 +941,7 @@ static const struct ide_port_info pmac_p
>  	.port_ops		= &pmac_ide_port_ops,
>  	.host_flags		= IDE_HFLAG_SET_PIO_MODE_KEEP_DMA |
>  				  IDE_HFLAG_POST_SET_MODE |
> -				  IDE_HFLAG_UNMASK_IRQS,
> +				  IDE_HFLAG_UNMASK_IRQS |
>  				  IDE_HFLAG_MMIO,
>  	.pio_mask		= ATA_PIO4,
>  	.mwdma_mask		= ATA_MWDMA2,
> 
> --
Thanks, the kernel panic is solved after applying the patch.

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

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

Re: [BUG] linux-next: Tree for April 10 - kernel panic while loading ata driver on powermac

[Bartlomiej Zolnierkiewicz]

On Thursday 10 April 2008, Kamalesh Babulal wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 10 April 2008, Bartlomiej Zolnierkiewicz wrote:
> >> Hi,
> >>
> >> On Thu, Apr 10, 2008 at 12:24 PM, Kamalesh Babulal
> >> <kamalesh@linux.vnet.ibm.com> wrote:
> >>> Hi Stephen,
> >>>
> >>>  The next-20080410 kernel panics while bootup over the PowerMac G5 box, while
> >>>  loading the ATA driver.
> >>>
> >>>  [    3.704000] Faulting instruction address: 0xc0000000000222a8
> >>>  [    3.704000] Oops: Kernel access of bad area, sig: 11 [#1]
> >>>  [    3.704000] SMP NR_CPUS=32 NUMA PowerMac
> >>>  [    3.704000] Modules linked in:
> >>>  [    3.704000] NIP: c0000000000222a8 LR: c00000000021cd10 CTR: 0000000000000100
> >>>  [    3.704000] REGS: c0000002760db070 TRAP: 0300   Not tainted  (2.6.25-rc8-next-20080410-autokern1)
> >>>  [    3.704000] MSR: 9000000000009032 <EE,ME,IR,DR>  CR: 44000042  XER: 20000000
> >>>  [    3.704000] DAR: a0001000822fa000, DSISR: 0000000040000000
> >>>  [    3.704000] TASK = c0000002760d7100[1] 'swapper' THREAD: c0000002760d8000 CPU: 0
> >>>  [    3.704000] GPR00: 0000000000000100 c0000002760db2f0 c000000000498310 a0001000822fa000
> >>>  [    3.704000] GPR04: c000000274806a00 0000000000000100 0000000000000201 c00000000000fed4
> >>>  [    3.704000] GPR08: c0000002760daf20 c0000000003ee0d8 c0000000004f1428 0000000000000000
> >>>  [    3.704000] GPR12: 0000000000000000 c0000000003fa700 0000000000000000 0000000000000000
> >>>  [    3.704000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> >>>  [    3.704000] GPR20: 0000000000000001 0000000000000027 0000000000000027 0000000000000000
> >>>  [    3.704000] GPR24: c0000000004f1400 0000000000000000 0000000000000201 c0000000004f1490
> >>>  [    3.704000] GPR28: a0001000822fa000 0000000000000200 c00000000044cf50 c000000274806a00
> >>>  [    3.704000] NIP [c0000000000222a8] ._insw_ns+0x10/0x30
> >>>  [    3.704000] LR [c00000000021cd10] .ata_input_data+0x1f4/0x264
> >> Could you please add printk() for 'hwif->host_flags', 'mmio' and 'io_32bit'
> >> to ide-iops.c::ata_input_data() so we know more on what is going on?
> > 
> > No longer needed - please test the hot-fix below instead:
> > 
> > ---
> > thanks to Andrew for noticing me about the gcc warning
> > 
> >  drivers/ide/ppc/pmac.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > Index: b/drivers/ide/ppc/pmac.c
> > ===================================================================
> > --- a/drivers/ide/ppc/pmac.c
> > +++ b/drivers/ide/ppc/pmac.c
> > @@ -941,7 +941,7 @@ static const struct ide_port_info pmac_p
> >  	.port_ops		= &pmac_ide_port_ops,
> >  	.host_flags		= IDE_HFLAG_SET_PIO_MODE_KEEP_DMA |
> >  				  IDE_HFLAG_POST_SET_MODE |
> > -				  IDE_HFLAG_UNMASK_IRQS,
> > +				  IDE_HFLAG_UNMASK_IRQS |
> >  				  IDE_HFLAG_MMIO,
> >  	.pio_mask		= ATA_PIO4,
> >  	.mwdma_mask		= ATA_MWDMA2,
> > 
> > --
> Thanks, the kernel panic is solved after applying the patch.
> 
> Tested-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>

Thanks.

I integrated the fix with the guilty patch and pushed it to IDE tree
(Andrew, you may drop the revert-patch now).

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] ide: add IDE_HFLAG_MMIO host flag (take 2)

* Add IDE_HFLAG_MMIO host flag and set it for hosts which use
  default_hwif_mmiops().

v2:
* Fix kernel panic in pmac host driver (',' should be '|').

  Thanks to Kamalesh for reporting it + testing the fix
  and to Andrew for hinting me about the source of the issue.

Cc: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ide/arm/icside.c          |    2 +-
 drivers/ide/arm/palm_bk3710.c     |    1 +
 drivers/ide/arm/rapide.c          |    1 +
 drivers/ide/legacy/ide_platform.c |    4 +++-
 drivers/ide/mips/swarm.c          |    1 +
 drivers/ide/pci/sgiioc4.c         |    1 +
 drivers/ide/pci/siimage.c         |    1 +
 drivers/ide/ppc/pmac.c            |    1 +
 include/linux/ide.h               |    2 ++
 9 files changed, 12 insertions(+), 2 deletions(-)

Index: b/drivers/ide/arm/icside.c
===================================================================
--- a/drivers/ide/arm/icside.c
+++ b/drivers/ide/arm/icside.c
@@ -481,7 +481,7 @@ static const struct ide_port_info icside
 	.init_dma		= icside_dma_off_init,
 	.port_ops		= &icside_v6_no_dma_port_ops,
 	.dma_ops		= &icside_v6_dma_ops,
-	.host_flags		= IDE_HFLAG_SERIALIZE,
+	.host_flags		= IDE_HFLAG_SERIALIZE | IDE_HFLAG_MMIO,
 	.mwdma_mask		= ATA_MWDMA2,
 	.swdma_mask		= ATA_SWDMA2,
 };
Index: b/drivers/ide/arm/palm_bk3710.c
===================================================================
--- a/drivers/ide/arm/palm_bk3710.c
+++ b/drivers/ide/arm/palm_bk3710.c
@@ -342,6 +342,7 @@ static const struct ide_port_ops palm_bk
 static const struct ide_port_info __devinitdata palm_bk3710_port_info = {
 	.init_dma		= palm_bk3710_init_dma,
 	.port_ops		= &palm_bk3710_ports_ops,
+	.host_flags		= IDE_HFLAG_MMIO,
 	.pio_mask		= ATA_PIO4,
 	.udma_mask		= ATA_UDMA4,	/* (input clk 99MHz) */
 	.mwdma_mask		= ATA_MWDMA2,
Index: b/drivers/ide/arm/rapide.c
===================================================================
--- a/drivers/ide/arm/rapide.c
+++ b/drivers/ide/arm/rapide.c
@@ -53,6 +53,7 @@ rapide_probe(struct expansion_card *ec, 
 
 		ide_init_port_hw(hwif, &hw);
 
+		hwif->host_flags = IDE_HFLAG_MMIO;
 		default_hwif_mmiops(hwif);
 
 		idx[0] = hwif->index;
Index: b/drivers/ide/legacy/ide_platform.c
===================================================================
--- a/drivers/ide/legacy/ide_platform.c
+++ b/drivers/ide/legacy/ide_platform.c
@@ -101,8 +101,10 @@ static int __devinit plat_ide_probe(stru
 
 	ide_init_port_hw(hwif, &hw);
 
-	if (mmio)
+	if (mmio) {
+		hwif->host_flags = IDE_HFLAG_MMIO;
 		default_hwif_mmiops(hwif);
+	}
 
 	idx[0] = hwif->index;
 
Index: b/drivers/ide/mips/swarm.c
===================================================================
--- a/drivers/ide/mips/swarm.c
+++ b/drivers/ide/mips/swarm.c
@@ -109,6 +109,7 @@ static int __devinit swarm_ide_probe(str
 	base = ioremap(offset, size);
 
 	/* Setup MMIO ops.  */
+	hwif->host_flags = IDE_HFLAG_MMIO;
 	default_hwif_mmiops(hwif);
 
 	hwif->chipset = ide_generic;
Index: b/drivers/ide/pci/sgiioc4.c
===================================================================
--- a/drivers/ide/pci/sgiioc4.c
+++ b/drivers/ide/pci/sgiioc4.c
@@ -573,6 +573,7 @@ static const struct ide_port_info sgiioc
 	.init_dma		= ide_dma_sgiioc4,
 	.port_ops		= &sgiioc4_port_ops,
 	.dma_ops		= &sgiioc4_dma_ops,
+	.host_flags		= IDE_HFLAG_MMIO,
 	.mwdma_mask		= ATA_MWDMA2_ONLY,
 };
 
Index: b/drivers/ide/pci/siimage.c
===================================================================
--- a/drivers/ide/pci/siimage.c
+++ b/drivers/ide/pci/siimage.c
@@ -630,6 +630,7 @@ static void __devinit init_mmio_iops_sii
 	 *	Fill in the basic HWIF bits
 	 */
 
+	hwif->host_flags |= IDE_HFLAG_MMIO;
 	default_hwif_mmiops(hwif);
 	hwif->hwif_data			= addr;
 
Index: b/drivers/ide/ppc/pmac.c
===================================================================
--- a/drivers/ide/ppc/pmac.c
+++ b/drivers/ide/ppc/pmac.c
@@ -941,6 +941,7 @@ static const struct ide_port_info pmac_p
 	.port_ops		= &pmac_ide_port_ops,
 	.host_flags		= IDE_HFLAG_SET_PIO_MODE_KEEP_DMA |
 				  IDE_HFLAG_POST_SET_MODE |
+				  IDE_HFLAG_MMIO |
 				  IDE_HFLAG_UNMASK_IRQS,
 	.pio_mask		= ATA_PIO4,
 	.mwdma_mask		= ATA_MWDMA2,
Index: b/include/linux/ide.h
===================================================================
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -1056,6 +1056,8 @@ enum {
 	IDE_HFLAG_NO_DMA		= (1 << 14),
 	/* check if host is PCI IDE device before allowing DMA */
 	IDE_HFLAG_NO_AUTODMA		= (1 << 15),
+	/* host uses MMIO */
+	IDE_HFLAG_MMIO			= (1 << 16),
 	/* host is CS5510/CS5520 */
 	IDE_HFLAG_CS5520		= IDE_HFLAG_VDMA,
 	/* no LBA48 */

Re: linux-next: Tree for April 10: generic pci_enable_resources() strikes again

[Mariusz Kozlowski]

Hello Stephen,

	The commit b818da52 makes my sparc64 box simply unable to boot.
You should probably take a look at other arches as well. The story is here:

http://lkml.org/lkml/2008/3/28/465
http://lkml.org/lkml/2008/4/1/248

	Mariusz

Re: linux-next: Tree for April 10 (ftrace)

[Randy Dunlap]

On Thu, 10 Apr 2008 18:14:04 +1000 Stephen Rothwell wrote:

> Hi all,
> 
> [I have been asked to provide a summary of changes before the biolerplate
> so here goes (please tell me if this is what you want or not).  I am not
> going to try to describe the changes in the individual trees, just the
> interactions between them.]
> 
> Changes since next-20080410:
> 
> I no longer revert "x86: phase out forced inlining".
> There is a new conflict in arch/s390/lib/uaccess_pt.c between the s390 and
> 	kvm trees.
> There is a new trivial white space conflict in arch/ia64/kernel/mca.c.
> I no longer need to revert "wusb: add the wireless usb stack to Linux".
> 
> Today's Next/Trees file is lying: the x86-latest and sched-latest trees
> did not merge/build correctly so have not been included.
> 
> ----------------------------------------------------------------------------
> 
> 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/).

trace selftest build fails when CONFIG_RT_MUTEXES=n:

next-20080410/kernel/trace/trace_selftest.c:413: error: implicit declaration of function 'rt_mutex_setprio'
make[3]: *** [kernel/trace/trace.o] Error 1

Possible fixes:

kernel/trace/Kconfig: SCHED_TRACER can depend on RT_MUTEXES
or there can be a stub for rt_mutex_setprio() when RT_MUTEXES=n

And kernel/trace/trace_selftest.c still needs #include <sched.h> added to it.

---
~Randy

Re: linux-next: Tree for April 10 (arch/x86)

[Randy Dunlap]

Has the printk format warning in arch/x86/mm/ioremap.c already been fixed
somewhere else (and not in linux-next merges)?

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

Fix printk formats in x86/mm/ioremap.c:

next-20080410/arch/x86/mm/ioremap.c:137: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'resource_size_t'
next-20080410/arch/x86/mm/ioremap.c:188: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'resource_size_t'
next-20080410/arch/x86/mm/ioremap.c:188: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'long unsigned int'

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
 arch/x86/mm/ioremap.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- next-20080410.orig/arch/x86/mm/ioremap.c
+++ next-20080410/arch/x86/mm/ioremap.c
@@ -134,7 +134,7 @@ static void __iomem *__ioremap(resource_
 
 	if (!phys_addr_valid(phys_addr)) {
 		printk(KERN_WARNING "ioremap: invalid physical address %llx\n",
-		       phys_addr);
+		       (unsigned long long)phys_addr);
 		WARN_ON_ONCE(1);
 		return NULL;
 	}
@@ -187,7 +187,8 @@ static void __iomem *__ioremap(resource_
 		     new_prot_val == _PAGE_CACHE_WB)) {
 			pr_debug(
 		"ioremap error for 0x%llx-0x%llx, requested 0x%lx, got 0x%lx\n",
-				phys_addr, phys_addr + size,
+				(unsigned long long)phys_addr,
+				(unsigned long long)(phys_addr + size),
 				prot_val, new_prot_val);
 			free_memtype(phys_addr, phys_addr + size);
 			return NULL;

Re: linux-next: Tree for April 10 (arch/x86)

[Ingo Molnar]

* Randy Dunlap <randy.dunlap@oracle.com> wrote:

> Fix printk formats in x86/mm/ioremap.c:
> 
> next-20080410/arch/x86/mm/ioremap.c:137: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'resource_size_t'
> next-20080410/arch/x86/mm/ioremap.c:188: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'resource_size_t'
> next-20080410/arch/x86/mm/ioremap.c:188: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'long unsigned int'

thanks, applied.

>  	if (!phys_addr_valid(phys_addr)) {
>  		printk(KERN_WARNING "ioremap: invalid physical address %llx\n",
> -		       phys_addr);
> +		       (unsigned long long)phys_addr);

is there really no way to solve this more cleanly than a forced cast? It 
is a totally uninteresting warning that we pass in a narrower type to 
printk(). It cannot ever cause any bugs or problems. Why does gcc warn 
about it?

	Ingo

Re: linux-next: Tree for April 10 (arch/x86)

[Randy Dunlap]

On Fri, 11 Apr 2008 09:46:31 +0200 Ingo Molnar wrote:

> 
> * Randy Dunlap <randy.dunlap@oracle.com> wrote:
> 
> > Fix printk formats in x86/mm/ioremap.c:
> > 
> > next-20080410/arch/x86/mm/ioremap.c:137: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'resource_size_t'
> > next-20080410/arch/x86/mm/ioremap.c:188: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'resource_size_t'
> > next-20080410/arch/x86/mm/ioremap.c:188: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'long unsigned int'
> 
> thanks, applied.
> 
> >  	if (!phys_addr_valid(phys_addr)) {
> >  		printk(KERN_WARNING "ioremap: invalid physical address %llx\n",
> > -		       phys_addr);
> > +		       (unsigned long long)phys_addr);
> 
> is there really no way to solve this more cleanly than a forced cast?

I haven't seen any other decent solutions.  This is what we do
all over the kernel.

> It
> is a totally uninteresting warning that we pass in a narrower type to 
> printk(). It cannot ever cause any bugs or problems. Why does gcc warn 
> about it?

No idea about that part.

---
~Randy

Re: linux-next: Tree for April 10 (arch/x86)

[Al Viro]

On Fri, Apr 11, 2008 at 08:19:01AM -0700, Randy Dunlap wrote:

> > It
> > is a totally uninteresting warning that we pass in a narrower type to 
> > printk(). It cannot ever cause any bugs or problems. Why does gcc warn 
> > about it?
> 
> No idea about that part.

Er...  That's kinda obvious - vararg function getting the wrong-sized
argument is *NOT* a harmless situation.  And yes, it's certainly a bug -
gcc manages to recover by using the knowledge of printf() formats (i.e.
it guesses that we want a long long and does conversion), but try to
do
	char *s = "%llx %c";
	printf(s, 1, '.');
and watch the show...

Re: [BUG] linux-next: April 10 - kernel oops at kmem_cache_alloc () regression from April 9 kernel

[Suresh Siddha]

On Thu, Apr 10, 2008 at 11:37:33PM +0530, Kamalesh Babulal wrote:
> Hi Stephen,
> 
> When booting the x86_64 boxes with the next-20080409 and 20080410 kernels
> the kernel bug is hit. The same bug was reported for the April 9  kernel
> at http://lkml.org/lkml/2008/4/10/63 (this kernel was compiled with 
> CONFIG_CC_STACKPROTECTOR is not set)
> 
> 
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> IP: [<ffffffff802869b1>] kmem_cache_alloc+0x41/0x130
> PGD 32dc2e067 PUD 32dd6a067 PMD 0 
> Oops: 0000 [1] SMP 
> last sysfs file: /sys/kernel/uevent_seqnum
> CPU 0 
> Modules linked in: sg
> Pid: 1, comm: init Not tainted 2.6.25-rc8-next-20080410-autotest #1
> RIP: 0010:[<ffffffff802869b1>]  [<ffffffff802869b1>] kmem_cache_alloc+0x41/0x130
> RSP: 0000:ffff810bfe4abef8  EFLAGS: 00010046
> RAX: 0000000000000000 RBX: ffff81090e4aa050 RCX: 0000000000405017
> RDX: 00007ffffb4c05b8 RSI: 00000000000000d0 RDI: 0000000000000000
> RBP: 0000000000000292 R08: 0000000000586f00 R09: 0000000000586f20
> R10: 0000000000586f08 R11: 0000000000000246 R12: 00000000000000d0
> R13: 0000000000000000 R14: 0000000000405150 R15: 0000000000000000
> FS:  000000000058b850(0063) GS:ffffffff8067f000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 000000090d0e6000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process init (pid: 1, threadinfo ffff810bfe4aa000, task ffff81090e4aa050)
> Stack:  0000000000000000 ffff81090e4aa050 ffff81090e4aa050 0000000000000001
>  0000000000405110 ffffffff80212f96 0000000000000292 ffff81090e4aa050
>  00007ffffb4c05a8 ffffffff8020cb79 0000000000000000 ffffffff804da339
> Call Trace:
>  [<ffffffff80212f96>] init_fpu+0x96/0xf0
>  [<ffffffff8020cb79>] math_state_restore+0x19/0x60
>  [<ffffffff804da339>] error_exit+0x0/0x51

I noticed in another thread, that you are using gcc 4.1.1. I think
both 4.1.0 and 4.1.1 has some issues with weak symbols. Can you please
try gcc 4.1.2 and see if that fixes your issue.

When I go back to 4.1.0, I am bitten by smilar oops. But not with 4.1.2.

thanks,
suresh

Re: linux-next: Tree for April 10: generic pci_enable_resources() strikes again

[Stephen Rothwell]

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

Hi Greg,

On Thu, 10 Apr 2008 21:34:00 +0200 Mariusz Kozlowski <m.kozlowski@tuxland.pl> wrote:
>
> 	The commit b818da52 makes my sparc64 box simply unable to boot.
> You should probably take a look at other arches as well. The story is here:
> 
> http://lkml.org/lkml/2008/3/28/465
> http://lkml.org/lkml/2008/4/1/248

This patch has remained unchanged since first imported into linux-next in
March 6.

So, the question is: What are the consequences of reverting it?  I am not
in a position to judge, but if it causes boxes to simply not boot, then
it would be a major regression in 2.6.26 and simply cannot be included
there.

I will revert it at the end of today's tree and hope that there is some
resolution before the merge window opens.

Of course, there is still the question of the other architectures ...

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

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

Re: linux-next: Tree for April 10: generic pci_enable_resources() strikes again

[Greg KH]

On Mon, Apr 14, 2008 at 11:48:23AM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> On Thu, 10 Apr 2008 21:34:00 +0200 Mariusz Kozlowski <m.kozlowski@tuxland.pl> wrote:
> >
> > 	The commit b818da52 makes my sparc64 box simply unable to boot.
> > You should probably take a look at other arches as well. The story is here:
> > 
> > http://lkml.org/lkml/2008/3/28/465
> > http://lkml.org/lkml/2008/4/1/248
> 
> This patch has remained unchanged since first imported into linux-next in
> March 6.
> 
> So, the question is: What are the consequences of reverting it?  I am not
> in a position to judge, but if it causes boxes to simply not boot, then
> it would be a major regression in 2.6.26 and simply cannot be included
> there.
> 
> I will revert it at the end of today's tree and hope that there is some
> resolution before the merge window opens.
> 
> Of course, there is still the question of the other architectures ...

Yes, I haven't caught up with my emails, but yes, this will not go
upstream for those arches that have had problems with it (like sparc64).
I'll fix my tree up first thing Monday morning for this issue.

Sorry for taking so long with it, been stuck doing other things...

thanks,

greg k-h

Re: linux-next: Tree for April 10: generic pci_enable_resources() strikes again

[Stephen Rothwell]

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

Hi Greg,

On Sun, 13 Apr 2008 21:28:47 -0700 Greg KH <greg@kroah.com> wrote:
>
> Yes, I haven't caught up with my emails, but yes, this will not go
> upstream for those arches that have had problems with it (like sparc64).
> I'll fix my tree up first thing Monday morning for this issue.

Thanks.  I will look for it tomorrow.

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

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

Re: linux-next: Tree for April 10 (arch/x86)

[Ingo Molnar]

* Al Viro <viro@ZenIV.linux.org.uk> wrote:

> On Fri, Apr 11, 2008 at 08:19:01AM -0700, Randy Dunlap wrote:
> 
> > > It
> > > is a totally uninteresting warning that we pass in a narrower type to 
> > > printk(). It cannot ever cause any bugs or problems. Why does gcc warn 
> > > about it?
> > 
> > No idea about that part.
> 
> Er...  That's kinda obvious - vararg function getting the wrong-sized
> argument is *NOT* a harmless situation.  And yes, it's certainly a bug -
> gcc manages to recover by using the knowledge of printf() formats (i.e.
> it guesses that we want a long long and does conversion), but try to
> do
> 	char *s = "%llx %c";
> 	printf(s, 1, '.');
> and watch the show...

well, gcc does not "recover", we _gave_ it the format string as a 
constant, and do so in 99.9% of the cases. It is a totally 
well-specified thing.

so yes, this warning is bogus.

You are right that passing in a non-constant string to printf is 
inherently dangerous though, and i'd suggest we warn about _that_ very 
prominently.

but the constant noise from gcc about printf formats, where the 
conversion is very clear and could be done implicitly, only hinders us 
and only teaches people to _ignore_ gcc warnings - which is actually 
very dangerous.

the only warning from gcc in this area should be where the format 
results in information _loss_ (i.e. the format has a narrower type than 
we pass into it) - there a warning is very much needed - and the 
programmer should then fix the bug or add a cast.

	Ingo

Re: linux-next: Tree for April 10 (arch/x86)

[Al Viro]

On Mon, Apr 14, 2008 at 10:12:20AM +0200, Ingo Molnar wrote:

> well, gcc does not "recover", we _gave_ it the format string as a 
> constant, and do so in 99.9% of the cases. It is a totally 
> well-specified thing.

It is an undefined behaviour according to any variant of C standard.
Sorry, printf() is not magic and it does _not_ have special calling
conventions.

> but the constant noise from gcc about printf formats, where the 
> conversion is very clear and could be done implicitly, only hinders us 
> and only teaches people to _ignore_ gcc warnings - which is actually 
> very dangerous.
> 
> the only warning from gcc in this area should be where the format 
> results in information _loss_ (i.e. the format has a narrower type than 
> we pass into it) - there a warning is very much needed - and the 
> programmer should then fix the bug or add a cast.

No, sorry.  That kind of mismatch is simply not a valid C.  Plain as that,
read the standard and you'll see.

Fundamentally, printf() is a function like any other vararg one.  So
explicitly typed arguments *are* the right thing to do.

What is not right is the lack of ability to define new conversions.  If
we could do that, we would kill the absolute majority of casts - and
remain within normal C limits...

Re: linux-next: Tree for April 10 (arch/x86)

[Ingo Molnar]

* Al Viro <viro@ZenIV.linux.org.uk> wrote:

> On Mon, Apr 14, 2008 at 10:12:20AM +0200, Ingo Molnar wrote:
> 
> > well, gcc does not "recover", we _gave_ it the format string as a 
> > constant, and do so in 99.9% of the cases. It is a totally 
> > well-specified thing.
> 
> It is an undefined behaviour according to any variant of C standard. 
> Sorry, printf() is not magic and it does _not_ have special calling 
> conventions.

... but reality called in and gcc added printf format checks as a gcc 
extension and even modifies the code to make it safe when the user gets 
it "wrong".

why? Because vararg is a dangerous concept as specified and strong but 
meaningful type checking should be enforced across such places. And our 
goal is to build better software and avoid bugs that can be avoided, not 
to follow standards where they are _stupid_.

> What is not right is the lack of ability to define new conversions.  
> If we could do that, we would kill the absolute majority of casts - 
> and remain within normal C limits...

sure. I dont actually care that much how it's solved - via extending the 
concept of varargs or via working it around where it hurts most. What 
matters is that the current situation is suboptimal. The present 
"solution" uglifies the code and more ugly code is always more 
dangerous.

But it's even worse: bogus warnings also reduce the psychological 
threshold to adding stupid casts - if you have to add casts in a printk 
that looks senseless then why not circumvent _other_ warnings that look 
senseless?

Excessive false positives are actively harmful to software quality 
because they teach people to ignore warnings.

	Ingo

Re: linux-next: Tree for April 10 (arch/x86)

[Jakub Jelinek]

On Fri, Apr 11, 2008 at 08:19:01AM -0700, Randy Dunlap wrote:
> On Fri, 11 Apr 2008 09:46:31 +0200 Ingo Molnar wrote:
> 
> > 
> > * Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > 
> > > Fix printk formats in x86/mm/ioremap.c:
> > > 
> > > next-20080410/arch/x86/mm/ioremap.c:137: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'resource_size_t'
> > > next-20080410/arch/x86/mm/ioremap.c:188: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'resource_size_t'
> > > next-20080410/arch/x86/mm/ioremap.c:188: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'long unsigned int'
> > 
> > thanks, applied.
> > 
> > >  	if (!phys_addr_valid(phys_addr)) {
> > >  		printk(KERN_WARNING "ioremap: invalid physical address %llx\n",
> > > -		       phys_addr);
> > > +		       (unsigned long long)phys_addr);
> > 
> > is there really no way to solve this more cleanly than a forced cast?
> 
> I haven't seen any other decent solutions.  This is what we do
> all over the kernel.

You can define macros and use them in the format string.
In this case
		printk(KERN_WARNING "ioremap: invalid physical address %" PRIRESOURCESZ "\n",
		       phys_addr);
(see the PRI* macros in
http://www.opengroup.org/onlinepubs/009695399/basedefs/inttypes.h.html
and e.g. glibc inttypes.h to see how it is defined).  Other alternative is
custom format length modifiers, but unfortunately there is no easy way ATM
to teach GCC about them.

	Jakub

Re: linux-next: Tree for April 10 (arch/x86)

[Jakub Jelinek]

On Mon, Apr 14, 2008 at 10:34:40AM +0200, Ingo Molnar wrote:
> ... but reality called in and gcc added printf format checks as a gcc 
> extension and even modifies the code to make it safe when the user gets 
> it "wrong".

GCC format string checking is only about warnings, GCC never modifies
the arguments passed to make them match the format string conversions.

	Jakub

Re: linux-next: Tree for April 10 (arch/x86)

[Al Viro]

On Mon, Apr 14, 2008 at 04:43:20AM -0400, Jakub Jelinek wrote:
> On Mon, Apr 14, 2008 at 10:34:40AM +0200, Ingo Molnar wrote:
> > ... but reality called in and gcc added printf format checks as a gcc 
> > extension and even modifies the code to make it safe when the user gets 
> > it "wrong".
> 
> GCC format string checking is only about warnings, GCC never modifies
> the arguments passed to make them match the format string conversions.

Actually, how hard would it be to allow new modifiers recognized by
format string checking?  Hell, even being able to teach it that (in this
family of functions) "%<d>u" should expect dma_addr_t, "%016<64>x" -
u64, etc. would solve all the problems.  Ideally we'd need something
for things like IPv4 address (__be32 expected), IPv6 address (taking
__be32 *), etc.

No magic, usual calling conventions - it'd still remain a valid C.
We can do that in sparse and just tell gcc to STFU about these warnings,
of course, but that's kind of things that is probably wanted by userland
projects as well...

BTW, ISTR FreeBSD folks carrying gcc patches in their tree for something
with similar purpose - project-specific format modifiers/specifiers.
No idea how hard it would be to generalize, though - never looked at
those in details...

Re: linux-next: Tree for April 10 (arch/x86)

[David Miller]

From: Al Viro <viro@ZenIV.linux.org.uk>
Date: Mon, 14 Apr 2008 10:30:38 +0100

> BTW, ISTR FreeBSD folks carrying gcc patches in their tree for something
> with similar purpose - project-specific format modifiers/specifiers.
> No idea how hard it would be to generalize, though - never looked at
> those in details...

You might be thinking of:

	http://www.stack.nl/~marcolz/FreeBSD/gcc-printf.patch

Re: [BUG] linux-next: April 10 - kernel oops at kmem_cache_alloc () regression from April 9 kernel

[Kamalesh Babulal]

Suresh Siddha wrote:
> On Thu, Apr 10, 2008 at 11:37:33PM +0530, Kamalesh Babulal wrote:
>> Hi Stephen,
>>
>> When booting the x86_64 boxes with the next-20080409 and 20080410 kernels
>> the kernel bug is hit. The same bug was reported for the April 9  kernel
>> at http://lkml.org/lkml/2008/4/10/63 (this kernel was compiled with 
>> CONFIG_CC_STACKPROTECTOR is not set)
>>
>>
>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
>> IP: [<ffffffff802869b1>] kmem_cache_alloc+0x41/0x130
>> PGD 32dc2e067 PUD 32dd6a067 PMD 0 
>> Oops: 0000 [1] SMP 
>> last sysfs file: /sys/kernel/uevent_seqnum
>> CPU 0 
>> Modules linked in: sg
>> Pid: 1, comm: init Not tainted 2.6.25-rc8-next-20080410-autotest #1
>> RIP: 0010:[<ffffffff802869b1>]  [<ffffffff802869b1>] kmem_cache_alloc+0x41/0x130
>> RSP: 0000:ffff810bfe4abef8  EFLAGS: 00010046
>> RAX: 0000000000000000 RBX: ffff81090e4aa050 RCX: 0000000000405017
>> RDX: 00007ffffb4c05b8 RSI: 00000000000000d0 RDI: 0000000000000000
>> RBP: 0000000000000292 R08: 0000000000586f00 R09: 0000000000586f20
>> R10: 0000000000586f08 R11: 0000000000000246 R12: 00000000000000d0
>> R13: 0000000000000000 R14: 0000000000405150 R15: 0000000000000000
>> FS:  000000000058b850(0063) GS:ffffffff8067f000(0000) knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> CR2: 0000000000000000 CR3: 000000090d0e6000 CR4: 00000000000006e0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> Process init (pid: 1, threadinfo ffff810bfe4aa000, task ffff81090e4aa050)
>> Stack:  0000000000000000 ffff81090e4aa050 ffff81090e4aa050 0000000000000001
>>  0000000000405110 ffffffff80212f96 0000000000000292 ffff81090e4aa050
>>  00007ffffb4c05a8 ffffffff8020cb79 0000000000000000 ffffffff804da339
>> Call Trace:
>>  [<ffffffff80212f96>] init_fpu+0x96/0xf0
>>  [<ffffffff8020cb79>] math_state_restore+0x19/0x60
>>  [<ffffffff804da339>] error_exit+0x0/0x51
> 
> I noticed in another thread, that you are using gcc 4.1.1. I think
> both 4.1.0 and 4.1.1 has some issues with weak symbols. Can you please
> try gcc 4.1.2 and see if that fixes your issue.
> 
> When I go back to 4.1.0, I am bitten by smilar oops. But not with 4.1.2.
> 
> thanks,
> suresh
Hi,

When I tried reproducing the problem on another machine with gcc 4.1.2, the goes into a loop with 
the following call trace. Will try and reproduce on the same machine, which was causing the panic.

[    0.000000] Initializing cgroup subsys cpuset

[    0.000000] Linux version 2.6.25-rc8-next-20080411-autokern1 (root@elm3b63.beaverton.ibm.com) (gcc version 4.1.2 20071124 (Red Hat 4.1.2-41)) #1 SMP PREEMPT Mon Apr 14 08:31:54 EDT 2008
.
.
.
<snip>
.
.
[    3.059347] request_module: runaway loop modprobe binfmt-464c
[    3.065238] request_module: runaway loop modprobe binfmt-464c
[    3.071106] request_module: runaway loop modprobe binfmt-464c
[    3.077242] request_module: runaway loop modprobe binfmt-464c
[    3.085556] request_module: runaway loop modprobe binfmt-464c
[    3.169430] khelper used greatest stack depth: 2884 bytes left
[    3.224149] khelper used greatest stack depth: 2864 bytes left
[    3.358136] khelper used greatest stack depth: 2844 bytes left
[    3.384146] khelper used greatest stack depth: 2780 bytes left
[    3.692012] khelper used greatest stack depth: 2744 bytes left
[    4.470665] khelper used greatest stack depth: 2716 bytes left
[    4.714540] khelper used greatest stack depth: 2700 bytes left
[    5.632645] khelper used greatest stack depth: 2616 bytes left
[   37.306789] khelper used greatest stack depth: 2596 bytes left
[  279.173966] INFO: task swapper:1 blocked for more than 240 seconds.
[  279.180375] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  279.188421] swapper       D 00000001  2376     1      0
[  279.196385]        f7844cc0 00000046 f7844c78 00000001 c06ed24c f7880000 f7846000 f7846190 
[  279.205829]        c4ab1700 00000007 00000000 fffeddc1 c0511054 373dd61a 000000ab ffffffff 
[  279.215036]        ffffffff ffffffff ffffffff 00000000 00000000 00000000 7fffffff 7fffffff 
[  279.224236] Call Trace:
[  279.227087]  [<c03c2c36>] schedule_timeout+0x16/0x8b
[  279.233650]  [<c023f674>] trace_hardirqs_on+0xb/0xd
[  279.240270]  [<c023f648>] trace_hardirqs_on_caller+0xe1/0x102
[  279.246470]  [<c023f674>] trace_hardirqs_on+0xb/0xd
[  279.254471]  [<c03c2423>] wait_for_common+0xda/0x139
[  279.259650]  [<c021ba97>] default_wake_function+0x0/0xd
[  279.266715]  [<c03c2504>] wait_for_completion+0x12/0x14
[  279.273332]  [<c0230e90>] call_usermodehelper_exec+0x7f/0xbf
[  279.279212]  [<c023119e>] request_module+0xce/0xe0
[  279.285587]  [<c023da76>] put_lock_stats+0xd/0x21
[  279.292211]  [<c023dada>] lock_release_holdtime+0x50/0x56
[  279.298064]  [<c028250f>] search_binary_handler+0x189/0x1c2
[  279.306064]  [<c02a5388>] load_script+0x0/0x188
[  279.311048]  [<c02a54fd>] load_script+0x175/0x188
[  279.315960]  [<c0208268>] __cycles_2_ns+0x14/0x35
[  279.322499]  [<c023da76>] put_lock_stats+0xd/0x21
[  279.329116]  [<c023dada>] lock_release_holdtime+0x50/0x56
[  279.334967]  [<c02823fc>] search_binary_handler+0x76/0x1c2
[  279.342968]  [<c0282404>] search_binary_handler+0x7e/0x1c2
[  279.348668]  [<c02a5388>] load_script+0x0/0x188
[  279.355034]  [<c02835ff>] do_execve+0x125/0x17b
[  279.359763]  [<c020273b>] sys_execve+0x29/0x4d
[  279.366382]  [<c0203c36>] syscall_call+0x7/0xb
[  279.371027]  [<c028007b>] set_anon_super+0x2d/0xa0
[  279.376268]  [<c0206b83>] kernel_execve+0x17/0x1c
[  279.382811]  [<c0201147>] run_init_process+0x17/0x19
[  279.389438]  [<c02011a8>] init_post+0x5f/0xc3
[  279.394243]  [<c0203c8e>] restore_nocheck_notrace+0x0/0xe
[  279.401485]  [<c0204833>] kernel_thread_helper+0x7/0x10
[  279.408103]  =======================



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

Re: linux-next: Tree for April 10 (arch/x86)

[Randy Dunlap]

On Mon, 14 Apr 2008 04:40:49 -0400 Jakub Jelinek wrote:

> On Fri, Apr 11, 2008 at 08:19:01AM -0700, Randy Dunlap wrote:
> > On Fri, 11 Apr 2008 09:46:31 +0200 Ingo Molnar wrote:
> > 
> > > 
> > > * Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > > 
> > > > Fix printk formats in x86/mm/ioremap.c:
> > > > 
> > > > next-20080410/arch/x86/mm/ioremap.c:137: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'resource_size_t'
> > > > next-20080410/arch/x86/mm/ioremap.c:188: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'resource_size_t'
> > > > next-20080410/arch/x86/mm/ioremap.c:188: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'long unsigned int'
> > > 
> > > thanks, applied.
> > > 
> > > >  	if (!phys_addr_valid(phys_addr)) {
> > > >  		printk(KERN_WARNING "ioremap: invalid physical address %llx\n",
> > > > -		       phys_addr);
> > > > +		       (unsigned long long)phys_addr);
> > > 
> > > is there really no way to solve this more cleanly than a forced cast?
> > 
> > I haven't seen any other decent solutions.  This is what we do
> > all over the kernel.
> 
> You can define macros and use them in the format string.
> In this case
> 		printk(KERN_WARNING "ioremap: invalid physical address %" PRIRESOURCESZ "\n",
> 		       phys_addr);
> (see the PRI* macros in
> http://www.opengroup.org/onlinepubs/009695399/basedefs/inttypes.h.html
> and e.g. glibc inttypes.h to see how it is defined).  Other alternative is
> custom format length modifiers, but unfortunately there is no easy way ATM
> to teach GCC about them.

Hi,
I tried this.

In this particular case, phys_addr is a type(def) of resource_size_t,
so we still get gcc warnings:

next-20080410/arch/x86/mm/ioremap.c: In function '__ioremap':
next-20080410/arch/x86/mm/ioremap.c:137: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'resource_size_t'
next-20080410/arch/x86/mm/ioremap.c:188: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'resource_size_t'

so we still need to cast phys_addr either to (unsigned long) or
(unsigned long long).  Rigth?  or am I missing something?  if so, what?

Thanks,
---
~Randy