linux-next: Tree for April 24

linux-next: Tree for April 24

[Stephen Rothwell]

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

Hi all,

I have added a tree that contains only simple build fixes for Linus'
tree.  It currently contains:

	lib: find_next_bit.o needed by a module only, move it from lib to obj
	powerpc: fix for long standing bug noticed by gcc 4.4.0

This is just an experiment for now and I am not sure if I should push
these fixes directly to Linus ...

Changes since 20090423:

New tree:
	fixes

The acpi tree gained a build failure for which I reverted a commit.

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

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 135 trees (counting Linus' and 18 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 avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging mips/mips-for-linux-next
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging pxa/for-next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging x86/auto-x86-next
Merging xtensa/master
Merging configfs/linux-next
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 tip-core/auto-core-next
Merging cpus4096/auto-cpus4096-next
Merging tracing/auto-tracing-next
Merging genirq/auto-genirq-next
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
Merging pci/linux-next
Merging quilt/device-mapper
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/for-next
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
CONFLICT (content): Merge conflict in drivers/net/wireless/rndis_wlan.c
CONFLICT (content): Merge conflict in include/linux/mmc/sdio_ids.h
CONFLICT (content): Merge conflict in net/mac80211/pm.c
[master ad362c6] Revert "rfkill: remove user_claim stuff"
Merging mtd/master
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
Merging cpufreq/next
Merging quilt/rr
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
Merging cifs/master
Merging mmc/next
Merging input/next
Merging bkl-removal/bkl-removal
Merging lsm/for-next
Merging block/for-next
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
CONFLICT (content): Merge conflict in drivers/usb/serial/cypress_m8.c
CONFLICT (content): Merge conflict in drivers/usb/serial/option.c
CONFLICT (content): Merge conflict in drivers/usb/serial/sierra.c
CONFLICT (content): Merge conflict in drivers/usb/serial/usb-serial.c
Merging agp/agp-next
Merging generic-ipi/auto-generic-ipi-next
Merging oprofile/auto-oprofile-next
Merging fastboot/auto-fastboot-next
Merging sparseirq/auto-sparseirq-next
Merging iommu/auto-iommu-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 kmemleak/kmemleak
CONFLICT (content): Merge conflict in lib/Kconfig.debug
Merging suspend/linux-next
Merging quilt/driver-core
Merging quilt/usb
Merging quilt/staging
Merging scsi-post-merge/master
[master 15570ec] Revert "ACPI/i915: build fix"

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

Next April 24 : BUG: lock held at task exit time!

[Sachin Sant]

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

While booting today's next tree on a powerpc box [ power 6 blade]
observed the following :

khelper used greatest stack depth: 10176 bytes left

=====================================
[ BUG: lock held at task exit time! ]
-------------------------------------
khelper/21 is exiting with locks still held!
2 locks held by khelper/21:
 #0:  (rcu_read_lock){.+.+.+}, at: [<c0000000001382fc>] 
.check_unsafe_exec+0x44/0x148
 #1:  (rcu_read_lock){.+.+.+}, at: [<c000000000138368>] 
.check_unsafe_exec+0xb0/0x148

stack backtrace:
Call Trace:
[c000000044483cf0] [c000000000011a54] .show_stack+0x6c/0x16c (unreliable)
[c000000044483da0] [c00000000009ae14] .debug_check_no_locks_held+0x98/0xb4
[c000000044483e20] [c000000000073b1c] .do_exit+0x758/0x7b0
[c000000044483f00] [c0000000000853d8] .____call_usermodehelper+0x170/0x174
[c000000044483f90] [c00000000002bd8c] .kernel_thread+0x54/0x70
net_namespace: 2000 bytes

Complete dmesg attached. Let me know if you need any other info. I will 
try yesterday's next
tree to check if this problem can be recreated.

Thanks
-Sachin

-- 

---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------


[-- Attachment #2: dmesg_next0424 --]
[-- Type: text/plain, Size: 12730 bytes --]

Using pSeries machine description
Page orders: linear mapping = 16, virtual = 16, io = 12, vmemmap = 24
Using 1TB segments
Found initrd at 0xc000000003600000:0xc000000003bebc74
console [udbg0] enabled
Partition configured for 8 cpus.
CPU maps initialized for 2 threads per core
 (thread shift is 1)
Starting Linux PPC64 #2 SMP Fri Apr 24 11:30:39 IST 2009
-----------------------------------------------------
ppc64_pft_size                = 0x19
physicalMemorySize            = 0x80000000
htab_hash_mask                = 0x3ffff
-----------------------------------------------------
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.30-rc3-next-20090424 (root@mjs22lp5) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #2 SMP Fri Apr 24 11:30:39 IST 2009
[boot]0012 Setup Arch
Node 0 Memory: 0x8000000-0x46000000
Node 1 Memory: 0x0-0x8000000 0x46000000-0x80000000
EEH: No capable adapters found
PPC64 nvram contains 15360 bytes
Using shared processor idle loop
Zone PFN ranges:
  DMA      0x00000000 -> 0x00008000
  Normal   0x00008000 -> 0x00008000
Movable zone start PFN for each node
early_node_map[3] active PFN ranges
    1: 0x00000000 -> 0x00000800
    0: 0x00000800 -> 0x00004600
    1: 0x00004600 -> 0x00008000
On node 0 totalpages: 15872
  DMA zone: 22 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 15850 pages, LIFO batch:1
On node 1 totalpages: 16896
  DMA zone: 44 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 16852 pages, LIFO batch:1
[boot]0015 Setup Done
Built 2 zonelists in Node order, mobility grouping on.  Total pages: 32702
Policy zone: DMA
Kernel command line: root=/dev/sda3 sysrq=1 
Experimental hierarchical RCU implementation.
RCU-based detection of stalled CPUs is enabled.
Experimental hierarchical RCU init done.
NR_IRQS:512
[boot]0020 XICS Init
[boot]0021 XICS Done
pic: no ISA interrupt controller
PID hash table entries: 4096 (order: 12, 32768 bytes)
time_init: decrementer frequency = 512.000000 MHz
time_init: processor frequency   = 4005.000000 MHz
clocksource: timebase mult[7d0000] shift[22] registered
clockevent: decrementer mult[8312] shift[16] cpu[0]
Console: colour dummy device 80x25
console handover: boot [udbg0] -> real [hvc0]
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES:  8
... MAX_LOCK_DEPTH:          48
... MAX_LOCKDEP_KEYS:        8191
... CLASSHASH_SIZE:          4096
... MAX_LOCKDEP_ENTRIES:     8192
... MAX_LOCKDEP_CHAINS:      16384
... CHAINHASH_SIZE:          8192
 memory used by lock dependency info: 4607 kB
 per task-struct memory footprint: 1920 bytes
allocated 1310720 bytes of page_cgroup
please try cgroup_disable=memory option if you don't want
freeing bootmem node 0
freeing bootmem node 1
Memory: 2035200k/2097152k available (8448k kernel code, 67136k reserved, 1216k data, 8988k bss, 448k init)
ODEBUG: 0 of 0 active objects replaced
ODEBUG: selftest passed
Calibrating delay loop... 1021.95 BogoMIPS (lpj=510976)
Security Framework initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes)
Mount-cache hash table entries: 4096
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
irq: irq 2 on host null mapped to virtual irq 16
Testing tracer nop: PASSED
clockevent: decrementer mult[8312] shift[16] cpu[1]
Processor 1 found.
clockevent: decrementer mult[8312] shift[16] cpu[2]
Processor 2 found.
clockevent: decrementer mult[8312] shift[16] cpu[3]
Processor 3 found.
Brought up 4 CPUs
Node 0 CPUs: 0-3
Node 1 CPUs:
CPU0 attaching sched-domain:
 domain 0: span 0-1 level SIBLING
  groups: 0 1
  domain 1: span 0-3 level CPU
   groups: 0-1 2-3
   domain 2: span 0-3 level NODE
    groups: 0-3 (__cpu_power = 2048)
CPU1 attaching sched-domain:
 domain 0: span 0-1 level SIBLING
  groups: 1 0
  domain 1: span 0-3 level CPU
   groups: 0-1 2-3
   domain 2: span 0-3 level NODE
    groups: 0-3 (__cpu_power = 2048)
CPU2 attaching sched-domain:
 domain 0: span 2-3 level SIBLING
  groups: 2 3
  domain 1: span 0-3 level CPU
   groups: 2-3 0-1
   domain 2: span 0-3 level NODE
    groups: 0-3 (__cpu_power = 2048)
CPU3 attaching sched-domain:
 domain 0: span 2-3 level SIBLING
  groups: 3 2
  domain 1: span 0-3 level CPU
   groups: 2-3 0-1
   domain 2: span 0-3 level NODE
    groups: 0-3 (__cpu_power = 2048)
khelper used greatest stack depth: 10176 bytes left

=====================================
[ BUG: lock held at task exit time! ]
-------------------------------------
khelper/21 is exiting with locks still held!
2 locks held by khelper/21:
 #0:  (rcu_read_lock){.+.+.+}, at: [<c0000000001382fc>] .check_unsafe_exec+0x44/0x148
 #1:  (rcu_read_lock){.+.+.+}, at: [<c000000000138368>] .check_unsafe_exec+0xb0/0x148

stack backtrace:
Call Trace:
[c000000044483cf0] [c000000000011a54] .show_stack+0x6c/0x16c (unreliable)
[c000000044483da0] [c00000000009ae14] .debug_check_no_locks_held+0x98/0xb4
[c000000044483e20] [c000000000073b1c] .do_exit+0x758/0x7b0
[c000000044483f00] [c0000000000853d8] .____call_usermodehelper+0x170/0x174
[c000000044483f90] [c00000000002bd8c] .kernel_thread+0x54/0x70
net_namespace: 2000 bytes
NET: Registered protocol family 16
IBM eBus Device Driver
PCI: Probing PCI hardware
PCI: Probing PCI hardware done
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NetLabel: Initializing
NetLabel:  domain hash size = 128
NetLabel:  protocols = UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default
Failed to register trace events module notifier
NET: Registered protocol family 2
IP route cache hash table entries: 16384 (order: 1, 131072 bytes)
TCP established hash table entries: 65536 (order: 4, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 5, 3670016 bytes)
TCP: Hash tables configured (established 65536 bind 65536)
TCP reno registered
NET: Registered protocol family 1
checking if image is initramfs...
rootfs image is initramfs; unpacking...
Freeing initrd memory: 6063k freed
irq: irq 655360 on host null mapped to virtual irq 17
irq: irq 655362 on host null mapped to virtual irq 18
IOMMU table initialized, virtual merging enabled
irq: irq 655364 on host null mapped to virtual irq 19
irq: irq 655365 on host null mapped to virtual irq 20
irq: irq 589825 on host null mapped to virtual irq 21
RTAS daemon started
audit: initializing netlink socket (disabled)
type=2000 audit(1240553894.305:1): initialized
Kprobe smoke test started
Kprobe smoke test passed successfully
HugeTLB registered 16 MB page size, pre-allocated 0 pages
HugeTLB registered 16 GB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 8192 (order 0, 65536 bytes)
Btrfs loaded
msgmni has been set to 3984
SELinux:  Registering netfilter hooks
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
vio_register_driver: driver hvc_console registering
HVSI: registered 0 devices
Linux agpgart interface v0.103
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
brd: module loaded
Uniform Multi-Platform E-IDE driver
ide-gd driver 1.18
vio_register_driver: driver ibmvscsi registering
ibmvscsi 30000002: SRP_VERSION: 16.a
scsi0 : IBM POWER Virtual SCSI Adapter 1.5.8
ibmvscsi 30000002: partner initialization complete
ibmvscsi 30000002: sent SRP login
ibmvscsi 30000002: SRP_LOGIN succeeded
ibmvscsi 30000002: host srp version: 16.a, host partition 06-1C12A (1), OS 3, max io 262144
scsi 0:0:1:0: Direct-Access     AIX      VDASD            0001 PQ: 0 ANSI: 3
scsi 0:0:2:0: CD-ROM            AIX      VOPTA                 PQ: 0 ANSI: 4
ibmvfc: IBM Virtual Fibre Channel Driver version: 1.0.5 (March 19, 2009)
vio_register_driver: driver ibmvfc registering
st: Version 20081215, fixed bufsize 32768, s/g segs 256
Driver 'st' needs updating - please use bus_type methods
osst :I: Tape driver with OnStream support version 0.99.4
osst :I: $Id: osst.c,v 1.73 2005/01/01 21:13:34 wriede Exp $
Driver 'osst' needs updating - please use bus_type methods
Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.20
sd 0:0:1:0: [sda] 33554432 512-byte hardware sectors: (17.1 GB/16.0 GiB)
sd 0:0:1:0: [sda] Write Protect is off
sd 0:0:1:0: [sda] Mode Sense: 17 00 00 08
sd 0:0:1:0: [sda] Cache data unavailable
sd 0:0:1:0: [sda] Assuming drive cache: write through
sr 0:0:2:0: Attached scsi CD-ROM sr0
sd 0:0:1:0: [sda] Cache data unavailable
sd 0:0:1:0: [sda] Assuming drive cache: write through
 sda:<5>sd 0:0:1:0: Attached scsi generic sg0 type 0
sr 0:0:2:0: Attached scsi generic sg1 type 5
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
uhci_hcd: USB Universal Host Controller Interface driver
mice: PS/2 mouse device common for all mice
 sda1 sda2 sda3 sda4 <<6>usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
TCP bic registered
Initializing XFRM netlink socket
NET: Registered protocol family 17
registered taskstats version 1
Running tests on trace events:
Testing event kfree_skb:  sda5 sda6 >
sd 0:0:1:0: [sda] Attached SCSI disk
OK
Testing event kmem_cache_free: OK
Testing event kfree: OK
Testing event kmem_cache_alloc_node: OK
Testing event kmalloc_node: OK
Testing event kmem_cache_alloc: OK
Testing event kmalloc: OK
Testing event irq_handler_exit: OK
Testing event softirq_exit: OK
Testing event softirq_entry: OK
Testing event irq_handler_entry: OK
Testing event lock_release: OK
Testing event lock_acquire: OK
Testing event sched_signal_send: OK
Testing event sched_process_fork: OK
Testing event sched_process_wait: OK
Testing event sched_process_exit: OK
Testing event sched_process_free: OK
Testing event sched_migrate_task: OK
Testing event sched_switch: OK
Testing event sched_wakeup_new: OK
Testing event sched_wakeup: OK
Testing event sched_wait_task: OK
Testing event sched_kthread_stop_ret: OK
Testing event sched_kthread_stop: OK
Running tests on trace event systems:
Testing event system skb: OK
Testing event system kmem: OK
Testing event system irq: OK
Testing event system lockdep: OK
Testing event system sched: OK
Running tests on all trace events:
Testing all events: OK
Freeing unused kernel memory: 448k freed
SysRq : Changing Loglevel
Loglevel set to 1
udevd version 128 started
scsi_id used greatest stack depth: 9104 bytes left
vol_id used greatest stack depth: 8432 bytes left
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda3, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
stty used greatest stack depth: 8096 bytes left
mount used greatest stack depth: 7504 bytes left
udevd version 128 started
drivers/net/ibmveth.c: ibmveth: IBM i/pSeries Virtual Ethernet Driver 1.03
vio_register_driver: driver ibmveth registering
IBM eHEA ethernet device driver (Release EHEA_0100)
irq: irq 590080 on host null mapped to virtual irq 256
ehea: eth2: Jumbo frames are enabled
ehea: eth2 -> logical port id #9
ehea: eth3: Jumbo frames are enabled
ehea: eth3 -> logical port id #10
modprobe used greatest stack depth: 7200 bytes left
Adding 2096320k swap on /dev/sda5.  Priority:-1 extents:1 across:2096320k 
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com
loop: module loaded
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda2, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
kjournald starting.  Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on sda6, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
mv used greatest stack depth: 7008 bytes left
ehea: eth2: Physical port up
irq: irq 775 on host null mapped to virtual irq 263
ehea: External switch port is backup port
irq: irq 776 on host null mapped to virtual irq 264
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
modprobe used greatest stack depth: 6752 bytes left
eth2: no IPv6 routers present
less used greatest stack depth: 6336 bytes left

Next April 24: [S390] allmodconfig build failure (trace/events)

[Sachin Sant]

Today's next tree build(s390 allmodconfig) failed with

kernel/built-in.o: In function `trace_softirq_entry'
include/trace/events/irq.h:42: undefined reference to 
`__tracepoint_softirq_entry'
include/trace/events/irq.h:42: undefined reference to 
`__tracepoint_softirq_entry'
kernel/built-in.o: In function `trace_softirq_exit':
include/trace/events/irq.h:48: undefined reference to 
`__tracepoint_softirq_exit'
include/trace/events/irq.h:48: undefined reference to 
`__tracepoint_softirq_exit'

Thanks
-Sachin

-- 

---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------

Re: Next April 24: [S390] allmodconfig build failure (trace/events)

[Ingo Molnar]

* Sachin Sant <sachinp@in.ibm.com> wrote:

> Today's next tree build(s390 allmodconfig) failed with
>
> kernel/built-in.o: In function `trace_softirq_entry'
> include/trace/events/irq.h:42: undefined reference to  
> `__tracepoint_softirq_entry'
> include/trace/events/irq.h:42: undefined reference to  
> `__tracepoint_softirq_entry'
> kernel/built-in.o: In function `trace_softirq_exit':
> include/trace/events/irq.h:48: undefined reference to  
> `__tracepoint_softirq_exit'
> include/trace/events/irq.h:48: undefined reference to  
> `__tracepoint_softirq_exit'

Hm, that's weird - s390 does not build kernel/softirq.o? Hm, it does 
- softirq.o is an obj-y object.

	Ingo

Re: Next April 24 : BUG: lock held at task exit time!

[Stephen Rothwell]

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

Hi Sachin,

On Fri, 24 Apr 2009 12:25:41 +0530 Sachin Sant <sachinp@in.ibm.com> wrote:
>
> While booting today's next tree on a powerpc box [ power 6 blade]
> observed the following :
> 
> khelper used greatest stack depth: 10176 bytes left
> 
> =====================================
> [ BUG: lock held at task exit time! ]
> -------------------------------------
> khelper/21 is exiting with locks still held!
> 2 locks held by khelper/21:
>  #0:  (rcu_read_lock){.+.+.+}, at: [<c0000000001382fc>] 
> .check_unsafe_exec+0x44/0x148
>  #1:  (rcu_read_lock){.+.+.+}, at: [<c000000000138368>] 
> .check_unsafe_exec+0xb0/0x148
> 
> stack backtrace:
> Call Trace:
> [c000000044483cf0] [c000000000011a54] .show_stack+0x6c/0x16c (unreliable)
> [c000000044483da0] [c00000000009ae14] .debug_check_no_locks_held+0x98/0xb4
> [c000000044483e20] [c000000000073b1c] .do_exit+0x758/0x7b0
> [c000000044483f00] [c0000000000853d8] .____call_usermodehelper+0x170/0x174
> [c000000044483f90] [c00000000002bd8c] .kernel_thread+0x54/0x70
> net_namespace: 2000 bytes
> 
> Complete dmesg attached. Let me know if you need any other info. I will 
> try yesterday's next
> tree to check if this problem can be recreated.

Almost certainly commit 874a9e18f25c86dbc199ad32ddd9ca44d25290e8
("check_unsafe_exec: s/lock_task_sighand/rcu_read_lock/") which has a
typo (two locks instead of lock/unlock) as pointed out by Hugh Dickins
(<Pine.LNX.4.64.0904240526080.15735@blonde.anvils> on LKML).

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

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

Re: Next April 24: [S390] allmodconfig build failure (trace/events)

[Heiko Carstens]

On Fri, 24 Apr 2009 09:25:33 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Sachin Sant <sachinp@in.ibm.com> wrote:
> 
> > Today's next tree build(s390 allmodconfig) failed with
> >
> > kernel/built-in.o: In function `trace_softirq_entry'
> > include/trace/events/irq.h:42: undefined reference to  
> > `'
> > include/trace/events/irq.h:42: undefined reference to  
> > `__tracepoint_softirq_entry'
> > kernel/built-in.o: In function `trace_softirq_exit':
> > include/trace/events/irq.h:48: undefined reference to  
> > `__tracepoint_softirq_exit'
> > include/trace/events/irq.h:48: undefined reference to  
> > `__tracepoint_softirq_exit'
> 
> Hm, that's weird - s390 does not build kernel/softirq.o? Hm, it does 
> - softirq.o is an obj-y object.

s390 does build kernel/softirq.o. However it's anything but obvious to
me how the tracepoint infrastructure works. Too many #ifdefs, #define's
and #undefine's...

I would expect that struct __tracepoint_softirq_entry somehow gets
defined via one of the TRACE_FORMAT macros, no?

kernel/softirq.i has these parts wrt. __tracepoint_softirq_entry:

# 42 "include/trace/events/irq.h"
extern struct tracepoint __tracepoint_softirq_entry; static inline __attribute__((always_inline)) void trace_softirq_entry(struc
t softirq_action *h, struct softirq_action *vec) { if (__builtin_expect(!!(__tracepoint_softirq_entry.state), 0)) do { void **it
_func; do { } while (0); it_func = ({ typeof((&__tracepoint_softirq_entry)->funcs) _________p1 = (*(volatile typeof((&__tracepoi
nt_softirq_entry)->funcs) *)&((&__tracepoint_softirq_entry)->funcs)); do { } while(0); (_________p1); }); if (it_func) { do { ((
void(*)(struct softirq_action *h, struct softirq_action *vec))(*it_func))(h, vec); } while (*(++it_func)); } do { } while (0); }
 while (0); } static inline __attribute__((always_inline)) int register_trace_softirq_entry(void (*probe)(struct softirq_action 
*h, struct softirq_action *vec)) { return tracepoint_probe_register("softirq_entry", (void *)probe); } static inline __attribute
__((always_inline)) int unregister_trace_softirq_entry(void (*probe)(struct softirq_action *h, struct softirq_action *vec)) { re
turn tracepoint_probe_unregister("softirq_entry", (void *)probe); };

extern struct tracepoint __tracepoint_softirq_exit; static inline __attribute__((always_inline)) void trace_softirq_exit(struct 
softirq_action *h, struct softirq_action *vec) { if (__builtin_expect(!!(__tracepoint_softirq_exit.state), 0)) do { void **it_fu
nc; do { } while (0); it_func = ({ typeof((&__tracepoint_softirq_exit)->funcs) _________p1 = (*(volatile typeof((&__tracepoint_s
oftirq_exit)->funcs) *)&((&__tracepoint_softirq_exit)->funcs)); do { } while(0); (_________p1); }); if (it_func) { do { ((void(*
)(struct softirq_action *h, struct softirq_action *vec))(*it_func))(h, vec); } while (*(++it_func)); } do { } while (0); } while
 (0); } static inline __attribute__((always_inline)) int register_trace_softirq_exit(void (*probe)(struct softirq_action *h, str
uct softirq_action *vec)) { return tracepoint_probe_register("softirq_exit", (void *)probe); } static inline __attribute__((alwa
ys_inline)) int unregister_trace_softirq_exit(void (*probe)(struct softirq_action *h, struct softirq_action *vec)) { return trac
epoint_probe_unregister("softirq_exit", (void *)probe); };

__do_softirq looks like below. So I would expect some header file include dependency? Dunno...

 void __do_softirq(void)
{
 struct softirq_action *h;
 __u32 pending;
 int max_restart = 10;
 int cpu;

 pending = ((*((struct _lowcore *) 0)).softirq_pending);
 account_system_vtime(((struct task_struct *const)(*((struct _lowcore *) 0)).current_task));

 __local_bh_disable((unsigned long)__builtin_return_address(0));
 do { ((struct task_struct *const)(*((struct _lowcore *) 0)).current_task)->softirq_context++; } while (0);

 cpu = ((*((struct _lowcore *) 0)).cpu_nr);
restart:

 (((*((struct _lowcore *) 0)).softirq_pending) = (0));

 do { trace_hardirqs_on(); raw_local_irq_enable(); } while (0);

 h = softirq_vec;

 do {
  if (pending & 1) {
   int prev_count = (current_thread_info()->preempt_count);

   trace_softirq_entry(h, softirq_vec);
   h->action(h);
   trace_softirq_exit(h, softirq_vec);
   if (__builtin_expect(!!(prev_count != (current_thread_info()->preempt_count)), 0)) {
    printk("<3>" "huh, entered softirq %td %s %p"
           "with preempt_count %08x,"
           " exited with %08x?\n", h - softirq_vec,
           softirq_to_name[h - softirq_vec],
           h->action, prev_count, (current_thread_info()->preempt_count));
    (current_thread_info()->preempt_count) = prev_count;
   }

   rcu_bh_qsctr_inc(cpu);
  }
  h++;
  pending >>= 1;
 } while (pending);

 do { raw_local_irq_disable(); trace_hardirqs_off(); } while (0);

 pending = ((*((struct _lowcore *) 0)).softirq_pending);
 if (pending && --max_restart)
  goto restart;

 if (pending)
  wakeup_softirqd();

 do { ((struct task_struct *const)(*((struct _lowcore *) 0)).current_task)->softirq_context--; } while (0);

 account_system_vtime(((struct task_struct *const)(*((struct _lowcore *) 0)).current_task));
 _local_bh_enable();
}

Re: Next April 24 : BUG: lock held at task exit time!

[Hugh Dickins]

On Fri, 24 Apr 2009, Stephen Rothwell wrote:
> On Fri, 24 Apr 2009 12:25:41 +0530 Sachin Sant <sachinp@in.ibm.com> wrote:
> >
> > While booting today's next tree on a powerpc box [ power 6 blade]
> > observed the following :
> > 
> > khelper used greatest stack depth: 10176 bytes left
> > 
> > =====================================
> > [ BUG: lock held at task exit time! ]
> > -------------------------------------
> > khelper/21 is exiting with locks still held!
> > 2 locks held by khelper/21:
> >  #0:  (rcu_read_lock){.+.+.+}, at: [<c0000000001382fc>] 
> > .check_unsafe_exec+0x44/0x148
> >  #1:  (rcu_read_lock){.+.+.+}, at: [<c000000000138368>] 
> > .check_unsafe_exec+0xb0/0x148
> > 
> > stack backtrace:
> > Call Trace:
> > [c000000044483cf0] [c000000000011a54] .show_stack+0x6c/0x16c (unreliable)
> > [c000000044483da0] [c00000000009ae14] .debug_check_no_locks_held+0x98/0xb4
> > [c000000044483e20] [c000000000073b1c] .do_exit+0x758/0x7b0
> > [c000000044483f00] [c0000000000853d8] .____call_usermodehelper+0x170/0x174
> > [c000000044483f90] [c00000000002bd8c] .kernel_thread+0x54/0x70
> > net_namespace: 2000 bytes
> > 
> > Complete dmesg attached. Let me know if you need any other info. I will 
> > try yesterday's next
> > tree to check if this problem can be recreated.
> 
> Almost certainly commit 874a9e18f25c86dbc199ad32ddd9ca44d25290e8
> ("check_unsafe_exec: s/lock_task_sighand/rcu_read_lock/") which has a
> typo (two locks instead of lock/unlock) as pointed out by Hugh Dickins
> (<Pine.LNX.4.64.0904240526080.15735@blonde.anvils> on LKML).

Indeed, thanks for the headsup Stephen.  My own config gives, not
Sachin's message (or not still visibly on screen anyway), but an
outright panic.  Shame that leaked out into the big world, we'd
all have preferred a quiet fixup!  Here's a patch, which I'll
also send as reply to the relevant thread.

[PATCH] check_unsafe_exec: rcu_read_unlock

Fix typo in previous commit: second rcu_read_lock should be rcu_read_unlock.

Signed-off-by: Hugh Dickins <hugh@veritas.com>
---

 fs/exec.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- 2.6.30-rc3-next-20090424/fs/exec.c	2009-04-24 12:23:43.000000000 +0100
+++ linux/fs/exec.c	2009-04-24 12:26:10.000000000 +0100
@@ -1043,7 +1043,7 @@ int check_unsafe_exec(struct linux_binpr
 		if (t->fs == p->fs)
 			n_fs++;
 	}
-	rcu_read_lock();
+	rcu_read_unlock();
 
 	if (p->fs->users > n_fs) {
 		bprm->unsafe |= LSM_UNSAFE_SHARE;

Re: Next April 24 : BUG: lock held at task exit time!

[Al Viro]

On Fri, Apr 24, 2009 at 12:55:44PM +0100, Hugh Dickins wrote:

> Indeed, thanks for the headsup Stephen.  My own config gives, not
> Sachin's message (or not still visibly on screen anyway), but an
> outright panic.  Shame that leaked out into the big world, we'd
> all have preferred a quiet fixup!  Here's a patch, which I'll
> also send as reply to the relevant thread.

Applied, will fold on reorder (since Ingo is asking for what will amount
to reorder anyway).

Re: Next April 24 : BUG: lock held at task exit time!

[Stephen Rothwell]

[-- Attachment #1.1: Type: text/plain, Size: 309 bytes --]

Hi Al,

On Fri, 24 Apr 2009 15:04:45 +0100 Al Viro <viro@ZenIV.linux.org.uk> wrote:
>
> Applied, will fold on reorder (since Ingo is asking for what will amount
> to reorder anyway).

Thanks.

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

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

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: linux-next: Tree for April 24 (p54 build error)

[Randy Dunlap]

drivers/net/wireless/p54/p54.h:193: error: array type has incomplete element type

struct p54_led_dev definition is controlled by
#ifdef CONFIG_P54_LEDS (is not set)

but the struct declaration is controlled by
#ifdef CONFIG_MAC80211_LEDS (=y)


-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: Tree for April 24 (p54 build error) (and pull request: wireless-next-2.6 2009-04-24)

[Christian Lamparter]

On Friday 24 April 2009 19:56:27 Randy Dunlap wrote:
> 
> drivers/net/wireless/p54/p54.h:193: error: array type has incomplete element type
> 
> struct p54_led_dev definition is controlled by
> #ifdef CONFIG_P54_LEDS (is not set)
> 
> but the struct declaration is controlled by
> #ifdef CONFIG_MAC80211_LEDS (=y)
> 
meh, [p54: more SoftLED updates] broke it
( dce072580e095d1fb7be59a1be30dc0e8307821b )

this also affects "pull request: wireless-next-2.6 2009-04-24"

and the current wireless-testing!

however the patches on the linux-wireless are all fine?!
(see: http://osdir.com/ml/linux-wireless/2009-03/msg01240.html )

I guess there was merge conflict with [p54: more SoftLED updates] 
and [p54: replace MAC80211_LEDS with P54_LEDS in p54.h] ?

Regards,
	Chr
---
In case someone want to fix it manually... here's the undo:
---
diff --git a/drivers/net/wireless/p54/p54.h b/drivers/net/wireless/p54/p54.h
index 7fda1a9..db3df94 100644
--- a/drivers/net/wireless/p54/p54.h
+++ b/drivers/net/wireless/p54/p54.h
@@ -189,10 +189,10 @@ struct p54_common {
 	unsigned long *used_rxkeys;
 
 	/* LED management */
-#ifdef CONFIG_MAC80211_LEDS
+#ifdef CONFIG_P54_LEDS
 	struct p54_led_dev leds[4];
 	struct delayed_work led_work;
-#endif /* CONFIG_MAC80211_LEDS */
+#endif /* CONFIG_P54_LEDS */
 	u16 softled_state;		/* bit field of glowing LEDs */
 
 	/* statistics */

Re: linux-next: Tree for April 24

[Benny Halevy]

On Apr. 24, 2009, 8:04 +0300, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
> 
> I have added a tree that contains only simple build fixes for Linus'
> tree.  It currently contains:
> 
> 	lib: find_next_bit.o needed by a module only, move it from lib to obj

Thanks Stephan!
I've already sent this patch directly to Linus (and while at it,
correcting its subject)
It's committed as a5422a5111811401f7756345e4c237ff06cf6d1e
in Linus' tree.

Benny

> 	powerpc: fix for long standing bug noticed by gcc 4.4.0
> 
> This is just an experiment for now and I am not sure if I should push
> these fixes directly to Linus ...
> 
> Changes since 20090423:
> 
> New tree:
> 	fixes
> 
> The acpi tree gained a build failure for which I reverted a commit.
> 
> ----------------------------------------------------------------------------
> 
> 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 135 trees (counting Linus' and 18 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.
> 

Re: linux-next: Tree for April 24

[Stephen Rothwell]

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

Hi Benny,

On Sun, 26 Apr 2009 16:20:36 +0300 Benny Halevy <bhalevy@panasas.com> wrote:
>
> I've already sent this patch directly to Linus (and while at it,
> correcting its subject)
> It's committed as a5422a5111811401f7756345e4c237ff06cf6d1e
> in Linus' tree.

Thanks.  I have removed it from my fixes tree.

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

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

Re: Next April 24: [S390] allmodconfig build failure (trace/events)

[Sachin Sant]

Heiko Carstens wrote:
> On Fri, 24 Apr 2009 09:25:33 +0200
> Ingo Molnar <mingo@elte.hu> wrote:
>
>   
>> * Sachin Sant <sachinp@in.ibm.com> wrote:
>>
>>     
>>> Today's next tree build(s390 allmodconfig) failed with
>>>
>>> kernel/built-in.o: In function `trace_softirq_entry'
>>> include/trace/events/irq.h:42: undefined reference to  
>>> `'
>>> include/trace/events/irq.h:42: undefined reference to  
>>> `__tracepoint_softirq_entry'
>>> kernel/built-in.o: In function `trace_softirq_exit':
>>> include/trace/events/irq.h:48: undefined reference to  
>>> `__tracepoint_softirq_exit'
>>> include/trace/events/irq.h:48: undefined reference to  
>>> `__tracepoint_softirq_exit'
>>>       
>> Hm, that's weird - s390 does not build kernel/softirq.o? Hm, it does 
>> - softirq.o is an obj-y object.
>>     
>
> s390 does build kernel/softirq.o. However it's anything but obvious to
> me how the tracepoint infrastructure works. Too many #ifdefs, #define's
> and #undefine's...
>
> I would expect that struct __tracepoint_softirq_entry somehow gets
> defined via one of the TRACE_FORMAT macros, no?
Today's next tree also has this failure. Any solution for this problem ?

Thanks
-Sachin

-- 

---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------

Re: Next April 24: [S390] allmodconfig build failure (trace/events)

[Heiko Carstens]

On Wed, 29 Apr 2009 15:21:39 +0530
Sachin Sant <sachinp@in.ibm.com> wrote:
> Heiko Carstens wrote:
> > On Fri, 24 Apr 2009 09:25:33 +0200
> > Ingo Molnar <mingo@elte.hu> wrote:
> >> * Sachin Sant <sachinp@in.ibm.com> wrote:
> >>> Today's next tree build(s390 allmodconfig) failed with
> >>>
> >>> kernel/built-in.o: In function `trace_softirq_entry'
> >>> include/trace/events/irq.h:42: undefined reference to  
> >>> `'
> >>> include/trace/events/irq.h:42: undefined reference to  
> >>> `__tracepoint_softirq_entry'
> >>> kernel/built-in.o: In function `trace_softirq_exit':
> >>> include/trace/events/irq.h:48: undefined reference to  
> >>> `__tracepoint_softirq_exit'
> >>> include/trace/events/irq.h:48: undefined reference to  
> >>> `__tracepoint_softirq_exit'
> >>>       
> >> Hm, that's weird - s390 does not build kernel/softirq.o? Hm, it does 
> >> - softirq.o is an obj-y object.
> >
> > s390 does build kernel/softirq.o. However it's anything but obvious to
> > me how the tracepoint infrastructure works. Too many #ifdefs, #define's
> > and #undefine's...
> >
> > I would expect that struct __tracepoint_softirq_entry somehow gets
> > defined via one of the TRACE_FORMAT macros, no?
> Today's next tree also has this failure. Any solution for this problem ?

Ingo, could you pick up the patch below please?

Subject: [PATCH] tracing: fix compile error

From: Heiko Carstens <heiko.carstens@de.ibm.com>

"tracing: create automated trace defines" causes this compile error on s390:

kernel/built-in.o: In function `__do_softirq':
(.text+0x1c680): undefined reference to `__tracepoint_softirq_entry'

This happens because the definitions of the softirq tracepoints were moved
from kernel/softirq.c to kernel/irq/handle.c. Since s390 doesn't support
generic hardirqs handle.c doesn't get compiled and the definitions are
missing.
So move the tracepoints to softirq.c again.

Reported-by: Sachin Sant <sachinp@in.ibm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---
 kernel/irq/handle.c |    2 --
 kernel/softirq.c    |    2 ++
 2 files changed, 2 insertions(+), 2 deletions(-)

Index: linux-next/kernel/irq/handle.c
===================================================================
--- linux-next.orig/kernel/irq/handle.c
+++ linux-next/kernel/irq/handle.c
@@ -18,8 +18,6 @@
 #include <linux/rculist.h>
 #include <linux/hash.h>
 #include <linux/bootmem.h>
-
-#define CREATE_TRACE_POINTS
 #include <trace/events/irq.h>
 
 #include "internals.h"
Index: linux-next/kernel/softirq.c
===================================================================
--- linux-next.orig/kernel/softirq.c
+++ linux-next/kernel/softirq.c
@@ -24,6 +24,8 @@
 #include <linux/ftrace.h>
 #include <linux/smp.h>
 #include <linux/tick.h>
+
+#define CREATE_TRACE_POINTS
 #include <trace/events/irq.h>
 
 #include <asm/irq.h>

Re: Next April 24: [S390] allmodconfig build failure (trace/events)

[Ingo Molnar]

* Heiko Carstens <heiko.carstens@de.ibm.com> wrote:

> On Wed, 29 Apr 2009 15:21:39 +0530
> Sachin Sant <sachinp@in.ibm.com> wrote:
> > Heiko Carstens wrote:
> > > On Fri, 24 Apr 2009 09:25:33 +0200
> > > Ingo Molnar <mingo@elte.hu> wrote:
> > >> * Sachin Sant <sachinp@in.ibm.com> wrote:
> > >>> Today's next tree build(s390 allmodconfig) failed with
> > >>>
> > >>> kernel/built-in.o: In function `trace_softirq_entry'
> > >>> include/trace/events/irq.h:42: undefined reference to  
> > >>> `'
> > >>> include/trace/events/irq.h:42: undefined reference to  
> > >>> `__tracepoint_softirq_entry'
> > >>> kernel/built-in.o: In function `trace_softirq_exit':
> > >>> include/trace/events/irq.h:48: undefined reference to  
> > >>> `__tracepoint_softirq_exit'
> > >>> include/trace/events/irq.h:48: undefined reference to  
> > >>> `__tracepoint_softirq_exit'
> > >>>       
> > >> Hm, that's weird - s390 does not build kernel/softirq.o? Hm, it does 
> > >> - softirq.o is an obj-y object.
> > >
> > > s390 does build kernel/softirq.o. However it's anything but obvious to
> > > me how the tracepoint infrastructure works. Too many #ifdefs, #define's
> > > and #undefine's...
> > >
> > > I would expect that struct __tracepoint_softirq_entry somehow gets
> > > defined via one of the TRACE_FORMAT macros, no?
> > Today's next tree also has this failure. Any solution for this problem ?
> 
> Ingo, could you pick up the patch below please?

applied, thanks Heiko!

	Ingo

Re: Next April 24: [S390] allmodconfig build failure (trace/events)

[Steven Rostedt]

On Wed, 29 Apr 2009, Heiko Carstens wrote:
> 
> Subject: [PATCH] tracing: fix compile error
> 
> From: Heiko Carstens <heiko.carstens@de.ibm.com>
> 
> "tracing: create automated trace defines" causes this compile error on s390:
> 
> kernel/built-in.o: In function `__do_softirq':
> (.text+0x1c680): undefined reference to `__tracepoint_softirq_entry'
> 
> This happens because the definitions of the softirq tracepoints were moved
> from kernel/softirq.c to kernel/irq/handle.c. Since s390 doesn't support
> generic hardirqs handle.c doesn't get compiled and the definitions are
> missing.
> So move the tracepoints to softirq.c again.

Nice catch!

Acked-by: Steven Rostedt <rostedt@goodmis.org>

-- Steve

Re: linux-next: Tree for April 24 (p54 build error) (and pull request: wireless-next-2.6 2009-04-24)

[John W. Linville]

If you want patches to be noticed and applied, it would be most
helpful if you could submit them in a regular and recognizable way.

	http://linux.yyz.us/patch-format.html

John

On Fri, Apr 24, 2009 at 10:47:14PM +0200, Christian Lamparter wrote:
> On Friday 24 April 2009 19:56:27 Randy Dunlap wrote:
> > 
> > drivers/net/wireless/p54/p54.h:193: error: array type has incomplete element type
> > 
> > struct p54_led_dev definition is controlled by
> > #ifdef CONFIG_P54_LEDS (is not set)
> > 
> > but the struct declaration is controlled by
> > #ifdef CONFIG_MAC80211_LEDS (=y)
> > 
> meh, [p54: more SoftLED updates] broke it
> ( dce072580e095d1fb7be59a1be30dc0e8307821b )
> 
> this also affects "pull request: wireless-next-2.6 2009-04-24"
> 
> and the current wireless-testing!
> 
> however the patches on the linux-wireless are all fine?!
> (see: http://osdir.com/ml/linux-wireless/2009-03/msg01240.html )
> 
> I guess there was merge conflict with [p54: more SoftLED updates] 
> and [p54: replace MAC80211_LEDS with P54_LEDS in p54.h] ?
> 
> Regards,
> 	Chr
> ---
> In case someone want to fix it manually... here's the undo:
> ---
> diff --git a/drivers/net/wireless/p54/p54.h b/drivers/net/wireless/p54/p54.h
> index 7fda1a9..db3df94 100644
> --- a/drivers/net/wireless/p54/p54.h
> +++ b/drivers/net/wireless/p54/p54.h
> @@ -189,10 +189,10 @@ struct p54_common {
>  	unsigned long *used_rxkeys;
>  
>  	/* LED management */
> -#ifdef CONFIG_MAC80211_LEDS
> +#ifdef CONFIG_P54_LEDS
>  	struct p54_led_dev leds[4];
>  	struct delayed_work led_work;
> -#endif /* CONFIG_MAC80211_LEDS */
> +#endif /* CONFIG_P54_LEDS */
>  	u16 softled_state;		/* bit field of glowing LEDs */
>  
>  	/* statistics */
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
John W. Linville		Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org			might be all we have.  Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html