summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2013-11-20Btrfs: remove dead codes from ctree.hWang Shilong
These two functions are only stated but undefined. Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com> Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
2013-11-20Btrfs: don't wait for ordered data outside desired rangeFilipe David Borba Manana
In btrfs_wait_ordered_range(), if we found an extent to the left of the start of our desired wait range and the last byte of that extent is 1 less than the desired range's start, we would would wait for the IO completion of that extent unnecessarily. Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com> Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
2013-11-20Btrfs: fix lockdep error in async commitLiu Bo
Lockdep complains about btrfs's async commit: [ 2372.462171] [ BUG: bad unlock balance detected! ] [ 2372.462191] 3.12.0+ #32 Tainted: G W [ 2372.462209] ------------------------------------- [ 2372.462228] ceph-osd/14048 is trying to release lock (sb_internal) at: [ 2372.462275] [<ffffffffa022cb10>] btrfs_commit_transaction_async+0x1b0/0x2a0 [btrfs] [ 2372.462305] but there are no more locks to release! [ 2372.462324] [ 2372.462324] other info that might help us debug this: [ 2372.462349] no locks held by ceph-osd/14048. [ 2372.462367] [ 2372.462367] stack backtrace: [ 2372.462386] CPU: 2 PID: 14048 Comm: ceph-osd Tainted: G W 3.12.0+ #32 [ 2372.462414] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080015 11/09/2011 [ 2372.462455] ffffffffa022cb10 ffff88007490fd28 ffffffff816f094a ffff8800378aa320 [ 2372.462491] ffff88007490fd50 ffffffff810adf4c ffff8800378aa320 ffff88009af97650 [ 2372.462526] ffffffffa022cb10 ffff88007490fd88 ffffffff810b01ee ffff8800898c0000 [ 2372.462562] Call Trace: [ 2372.462584] [<ffffffffa022cb10>] ? btrfs_commit_transaction_async+0x1b0/0x2a0 [btrfs] [ 2372.462619] [<ffffffff816f094a>] dump_stack+0x45/0x56 [ 2372.462642] [<ffffffff810adf4c>] print_unlock_imbalance_bug+0xec/0x100 [ 2372.462677] [<ffffffffa022cb10>] ? btrfs_commit_transaction_async+0x1b0/0x2a0 [btrfs] [ 2372.462710] [<ffffffff810b01ee>] lock_release+0x18e/0x210 [ 2372.462742] [<ffffffffa022cb36>] btrfs_commit_transaction_async+0x1d6/0x2a0 [btrfs] [ 2372.462783] [<ffffffffa025a7ce>] btrfs_ioctl_start_sync+0x3e/0xc0 [btrfs] [ 2372.462822] [<ffffffffa025f1d3>] btrfs_ioctl+0x4c3/0x1f70 [btrfs] [ 2372.462849] [<ffffffff812c0321>] ? avc_has_perm+0x121/0x1b0 [ 2372.462873] [<ffffffff812c0224>] ? avc_has_perm+0x24/0x1b0 [ 2372.462897] [<ffffffff8107ecc8>] ? sched_clock_cpu+0xa8/0x100 [ 2372.462922] [<ffffffff8117b145>] do_vfs_ioctl+0x2e5/0x4e0 [ 2372.462946] [<ffffffff812c19e6>] ? file_has_perm+0x86/0xa0 [ 2372.462969] [<ffffffff8117b3c1>] SyS_ioctl+0x81/0xa0 [ 2372.462991] [<ffffffff817045a4>] tracesys+0xdd/0xe2 ==================================================== It's because that we don't do the right thing when checking if it's ok to tell lockdep that we're trying to release the rwsem. If the trans handle's type is TRANS_ATTACH, we won't acquire the freeze rwsem, but as TRANS_ATTACH fits the check (trans < TRANS_JOIN_NOLOCK), we'll release the freeze rwsem, which makes lockdep complains a lot. Reported-by: Ma Jianpeng <majianpeng@gmail.com> Signed-off-by: Liu Bo <bo.li.liu@oracle.com> Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
2013-11-20Btrfs: avoid heavy operations in btrfs_commit_superLiu Bo
The 'git blame' history shows that, the old transaction commit code has to do twice to ensure roots are updated and we have to flush metadata and super block manually, however, right now all of these can be handled well inside the transaction commit code without extra efforts. And the error handling part remains same with the current code, -- 'return to caller once we get error'. This saves us a transaction commit and a flush of super block, which are both heavy operations according to ftrace output analysis. Signed-off-by: Liu Bo <bo.li.liu@oracle.com> Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
2013-11-20Btrfs: fix __btrfs_start_workers retvalIlya Dryomov
__btrfs_start_workers returns 0 in case it raced with btrfs_stop_workers and lost the race. This is wrong because worker in this case is not allowed to start and is in fact destroyed. Return -EINVAL instead. Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
2013-11-20Btrfs: disable online raid-repair on ro mountsIlya Dryomov
This disables the "if needed, write the good copy back before the read is completed" part of the read sequence for read-only mounts. Cc: Jan Schmidt <list.btrfs@jan-o-sch.net> Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
2013-11-20Btrfs: do not inc uncorrectable_errors counter on ro scrubsIlya Dryomov
Currently if we discover an error when scrubbing in ro mode we a) blindly increment the uncorrectable_errors counter, and b) spam the dmesg with the 'unable to fixup (regular) error at ...' message, even though a) we haven't tried to determine if the error is correctable or not, and b) we haven't tried to fixup anything. Fix this. Cc: Stefan Behrens <sbehrens@giantdisaster.de> Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
2013-11-20Btrfs: only drop modified extents if we logged the whole inodeJosef Bacik
If we fsync, seek and write, rename and then fsync again we will lose the modified hole extent because the rename will drop all of the modified extents since we didn't do the fast search. We need to only drop the modified extents if we didn't do the fast search and we were logging the entire inode as we don't need them anymore, otherwise this is being premature. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
2013-11-20Btrfs: make sure to copy everything if we renameJosef Bacik
If we rename a file that is already in the log and we fsync again we will lose the new name. This is because we just log the inode update and not the new ref. To fix this we just need to check if we are logging the new name of the inode and copy all the metadata instead of just updating the inode itself. With this patch my testcase now passes. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
2013-11-20Btrfs: don't BUG_ON() if we get an error walking backrefsJosef Bacik
We can just return false for this so we stop doing the snapshot aware defrag stuff. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
2013-11-20x86, wmi fix modalias_show return valuesPrarit Bhargava
I just fixed this same bug in arch/powerpc/kernel/vio.c and took a quick look for other similar errors in the kernel. modalias_show() should return an empty string on error, not errno. Signed-off-by: Prarit Bhargava <prarit@redhat.com> Cc: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20ipc: Added support for IPC interrupt modeKuppuswamy Sathyanarayanan
This patch adds support for ipc command interrupt mode. Also added platform data option to select 'irq_mode' irq_mode = 1: configure the driver to receive IOC interrupt for each successful ipc_command. irq_mode = 0: makes driver use polling method to track the command completion status. Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: David Cohen <david.a.cohen@linux.intel.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20ipc: Handle error conditions in ipc commandKuppuswamy Sathyanarayanan
Handle error conditions in intel_scu_ipc_command() and pwr_reg_rdwr(). Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: David Cohen <david.a.cohen@linux.intel.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20ipc: Enabled ipc support for additional intel platformsKuppuswamy Sathyanarayanan
Enabled ipc support for penwell, clovertrail & tangier platforms. Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Cc: David Cohen <david.a.cohen@linux.intel.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20ipc: Added platform data structureKuppuswamy Sathyanarayanan
Since the same ipc driver can be used by many platforms, using macros for defining ipc_base and i2c_base addresses is not a scalable approach. So added a platform data structure to pass this information. Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Acked-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk> Cc: David Cohen <david.a.cohen@linux.intel.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20thinkpad_acpi: Fix build error when CONFIG_SND_MAX_CARDS > 32Takashi Iwai
SNDRV_CARDS can be specified via Kconfig since 3.11 kernel, so this can be over 32bit integer range, which leads to a build error. Cc: <stable@vger.kernel.org> [v3.11+] Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20platform: add chrome platform directoryOlof Johansson
It makes sense to split out the Chromebook/Chromebox hardware platform drivers to a separate subdirectory, since some of it will be shared between ARM and x86. This moves over the existing chromeos_laptop driver without making any other changes, and adds appropriate Kconfig entries for the new directory. It also adds a MAINTAINERS entry for the new subdir. Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20hp-wmi: detect "2009 BIOS or later" flag by WMI 0x0d for wireless cmdAlex Hung
Some HP BIOS has dummy WMI 0x05 cmd and it causes wireless set cmd to fail. This patch fixes the problem by detecting "2009 BIOS or later" flag which determines whether WMI 0x1b is supported and is used to replace WMI 0x05. Signed-off-by: Alex Hung <alex.hung@canonical.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20dell-wmi: Add KEY_MICMUTE to bios_to_linux_keycodeAlex Hung
Signed-off-by: Alex Hung <alex.hung@canonical.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20platform:x86: Remove OOM message after input_allocate_deviceJoe Perches
Emitting an OOM message isn't necessary after input_allocate_device as there's a generic OOM and a dump_stack already done. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20sony-laptop: fixe typos in sony_laptop_input_keycode_mapStephen Gildea
Signed-off-by: Stephen Gildea <stepheng+linux@gildea.com> Signed-off-by: Mattia Dongili <malattia@linux.it> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20sony-laptop: warn on multiple KBD backlight handlesMattia Dongili
Some BIOS versions/Vaio models apparently ship with two nearly identical functions to handle backlight related controls. The only difference seems to be: If (LEqual (BUF1, 0x40)) { Store (0x40, P80H) Store (BUF2, Local0) - And (Local0, One, Local0) + And (Local0, 0x03, Local0) Store (Local0, ^^H_EC.KLPC) } Avoid erroring out on initialization and messing things up on cleanup for now since we never call into these methods with anything different than 1 or 0. This issue was found on a Sony VPCSE1V9E/BIOS R2087H4. Cc: Marco Krüger <krgsch@gmail.com> Signed-off-by: Mattia Dongili <malattia@linux.it> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20dell-laptop: Only enable rfkill functionality on laptops with a hw killswitchHans de Goede
All my testing has been on laptops with a hw killswitch, so to be on the safe side disable rfkill functionality on models without a hw killswitch for now. Once we gather some feedback on laptops without a hw killswitch this decision maybe reconsidered. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20dell-laptop: Add a force_rfkill module parameterHans de Goede
Setting force_rfkill will cause the dell-laptop rfkill code to skip its whitelist checks, this will allow individual users to override the whitelist, as well as to gather info from users to improve the checks. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20dell-laptop: Wait less long before updating rfkill after an rfkill keypressHans de Goede
Some time is needed for the BIOS to do its work, but 250ms should be plenty. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20dell-laptop: Do not skip setting blocked bit rfkill_set while hw-blockedHans de Goede
Instead when hw-blocked always write 1 to the blocked bit for the radio in question. This is necessary to properly set all the blocked bits for hw-switch controlled radios to 1 after power-on and resume. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20dell-laptop: Sync current block state to BIOS on hw switch changeHans de Goede
This is necessary for 3 reasons: 1) To apply sw_state changes made while hw-blocked 2) To set all the blocked bits for hw-switch controlled radios to 1 when the switch gets changed to off, this is necessary on some models to actually turn the radio status LEDs off. 3) On some models non hw-switch controlled radios will have their block bit cleared (potentially undoing a soft-block) on hw-switch toggle, this restores the sw-block in this case. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20dell-laptop: Allow changing the sw_state while the radio is blocked by hwHans de Goede
This makes dell-laptop's rfkill code consistent with other drivers which allow sw_state changes while hw blocked. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20dell-laptop: Don't read-back sw_state on machines with a hardware switchHans de Goede
On machines with a hardware switch, the blocking settings can not be changed through a Fn + wireless-key combo, so there is no reason to read back the blocking state from the BIOS. Reading back is not only not necessary it is actually harmful, since on some machines the blocking state will be cleared to all 0 after a wireless switch toggle, even for radios not controlled by the hw-switch (yeah firmware bugs). This causes "magic" changes to the sw_state. This is inconsistent with other rfkill drivers which preserve the sw_state over a hw kill on / off. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20dell-laptop: Don't set sw_state from the query callbackHans de Goede
The query callback should only update the hw_state, see the comment in net/rfkill/core.c in rfkill_set_block, which is its only caller. rfkill_set_block will modify the sw_state directly after calling query so calling set_sw_state is an expensive NOP. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20dell-laptop: Only get status from BIOS once when updatingHans de Goede
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20dell-laptop: If there is no hwswitch, then clear all hw-controlled bitsHans de Goede
To ensure we don't enter any hw-switch related code paths on machines without a hw-switch. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20dell-laptop: Only enable rfkill on LatitudesHans de Goede
The rfkill functionality was removed from the dell-laptop driver because it was causing problems on various non Latitude models, and the blacklist kept growing and growing. In the thread discussing this Dell mentioned that they only QA the rfkill acpi interface on Latitudes and indeed there have been no blacklist entries for Latitudes. Note that the blacklist contained no Vostros either, and most Vostros have a hardware switch too, so we could consider supporting Vostros with a hardware switch too. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-20Revert "dell-laptop: Remove rfkill code"Hans de Goede
Without rfkill functionality in dell-laptop I have the following problems: -If the hardware radio switch is set to disable the radio, then userspace will still think it can use wireless and bluetooth. -The wwan / 3g modem cannot be soft blocked without the dell-laptop rfkill functionality I know the rfkill functionality was removed from the dell-laptop driver because it caused more problems then it fixed, and the blacklist for it was growing out of control. But in the thread discussing this Dell mentioned that they only QA the rfkill acpi interface on Latitudes and indeed there have been no blacklist entries for Latitudes. Therefor I would like to bring the rfkill functionality back only for Latitudes. This patch is a straight-forward revert. The next patch in this set will drop the blacklist and replace it with a Latitude check. This reverts commit a6c2390cd6d2083d27a2359658e08f2d3df375ac. Conflicts: drivers/platform/x86/dell-laptop.c Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-11-21powerpc/signals: Mark VSX not saved with small contextsMichael Neuling
The VSX MSR bit in the user context indicates if the context contains VSX state. Currently we set this when the process has touched VSX at any stage. Unfortunately, if the user has not provided enough space to save the VSX state, we can't save it but we currently still set the MSR VSX bit. This patch changes this to clear the MSR VSX bit when the user doesn't provide enough space. This indicates that there is no valid VSX state in the user context. This is needed to support get/set/make/swapcontext for applications that use VSX but only provide a small context. For example, getcontext in glibc provides a smaller context since the VSX registers don't need to be saved over the glibc function call. But since the program calling getcontext may have used VSX, the kernel currently says the VSX state is valid when it's not. If the returned context is then used in setcontext (ie. a small context without VSX but with MSR VSX set), the kernel will refuse the context. This situation has been reported by the glibc community. Based on patch from Carlos O'Donell. Tested-by: Haren Myneni <haren@linux.vnet.ibm.com> Signed-off-by: Michael Neuling <mikey@neuling.org> Cc: stable@vger.kernel.org Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc/pseries: Fix SMP=n build of rng.cMichael Ellerman
In commit a489043 "Implement arch_get_random_long() based on H_RANDOM" I broke the SMP=n build. We were getting plpar_wrappers.h via spinlock.h which breaks when SMP=n. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc: Make cpu_to_chip_id() available when SMP=nMichael Ellerman
Up until now we have only used cpu_to_chip_id() in the topology code, which is only used on SMP builds. However my recent commit a4da0d5 "Implement arch_get_random_long/int() for powernv" added a usage when SMP=n, breaking the build. Move cpu_to_chip_id() into prom.c so it is available for SMP=n builds. We would move the extern to prom.h, but that breaks the include in topology.h. Instead we leave it in smp.h, but move it out of the CONFIG_SMP #ifdef. We also need to include asm/smp.h in rng.c, because the linux version skips asm/smp.h on UP. What a mess. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc/vio: Fix a dma_mask issue of vioLi Zhong
I encountered following issue: [ 0.283035] ibmvscsi 30000015: couldn't initialize event pool [ 5.688822] ibmvscsi: probe of 30000015 failed with error -1 which prevents the storage from being recognized, and the machine from booting. After some digging, it seems that it is caused by commit 4886c399da as dma_mask pointer in viodev->dev is not set, so in dma_set_mask_and_coherent(), dma_set_coherent_mask() is not called because dma_set_mask(), which is dma_set_mask_pSeriesLP() returned EIO. While before the commit, dma_set_coherent_mask() is always called. I tried to replace dma_set_mask_and_coherent() with dma_coerce_mask_and_coherent(), and the machine could boot again. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc: booke: Fix build failuresAneesh Kumar K.V
arch/powerpc/platforms/wsp/wsp.c: In function ‘wsp_probe_devices’: arch/powerpc/platforms/wsp/wsp.c:76:3: error: implicit declaration of function ‘of_address_to_resource’ [-Werror=implicit-function-declaration] Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc: ppc64 address space capped at 32TB, mmap randomisation disabledAnton Blanchard
Commit fba2369e6ceb (mm: use vm_unmapped_area() on powerpc architecture) has a bug in slice_scan_available() where we compare an unsigned long (high_slices) against a shifted int. As a result, comparisons against the top 32 bits of high_slices (representing the top 32TB) always returns 0 and the top of our mmap region is clamped at 32TB This also breaks mmap randomisation since the randomised address is always up near the top of the address space and it gets clamped down to 32TB. Cc: stable@vger.kernel.org # v3.10+ Signed-off-by: Anton Blanchard <anton@samba.org> Acked-by: Michel Lespinasse <walken@google.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc: Only print PACATMSCRATCH in oops when TM is activeAnton Blanchard
If TM is not active there is no need to print PACATMSCRATCH so we can save ourselves a line. Signed-off-by: Anton Blanchard <anton@samba.org> Acked-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc/pseries: Duplicate dtl entries sometimes sent to userspaceAnton Blanchard
When reading from the dispatch trace log (dtl) userspace interface, I sometimes see duplicate entries. One example: # hexdump -C dtl.out 00000000 07 04 00 0c 00 00 48 44 00 00 00 00 00 00 00 00 00000010 00 0c a0 b4 16 83 6d 68 00 00 00 00 00 00 00 00 00000020 00 00 00 00 10 00 13 50 80 00 00 00 00 00 d0 32 00000030 07 04 00 0c 00 00 48 44 00 00 00 00 00 00 00 00 00000040 00 0c a0 b4 16 83 6d 68 00 00 00 00 00 00 00 00 00000050 00 00 00 00 10 00 13 50 80 00 00 00 00 00 d0 32 The problem is in scan_dispatch_log() where we call dtl_consumer() but bail out before incrementing the index. To fix this I moved dtl_consumer() after the timebase comparison. Signed-off-by: Anton Blanchard <anton@samba.org> Cc: stable@vger.kernel.org Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc: Remove a few lines of oops outputAnton Blanchard
We waste quite a few lines in our oops output: ... MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 28044024 XER: 00000000 SOFTE: 0 CFAR: 0000000000009088 DAR: 000000000000001c, DSISR: 40000000 GPR00: c0000000000c74f0 c00000037cc1b010 c000000000d2bb30 0000000000000000 ... We can do a better job here and remove 3 lines: MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 28044024 XER: 00000000 CFAR: 0000000000009088 DAR: 0000000000000010, DSISR: 40000000 SOFTE: 1 GPR00: c0000000000e3d10 c00000037cc2fda0 c000000000d2c3a8 0000000000000001 Also move PACATMSCRATCH up, it doesn't really belong in the stack trace section. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc: Print DAR and DSISR on machine check oopsesAnton Blanchard
Machine check exceptions set DAR and DSISR, so print them in our oops output. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc: Fix __get_user_pages_fast() irq handlingHeiko Carstens
__get_user_pages_fast() may be called with interrupts disabled (see e.g. get_futex_key() in kernel/futex.c) and therefore should use local_irq_save() and local_irq_restore() instead of local_irq_disable()/enable(). Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> CC: <stable@vger.kernel.org> [v3.12] Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc/eeh: More accurate logGavin Shan
This clarifies in the log whether the error is a global PHB error or an individual PE being frozen. Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc/eeh: Enable PCI_COMMAND_MASTER for PCI bridgesGavin Shan
On PHB3, we will fail to fetch IODA tables without PCI_COMMAND_MASTER on PCI bridges. According to one experiment I had, the MSIx interrupts didn't raise from the adapter without the bit applied to all upstream PCI bridges including root port of the adapter. The patch forces to have that bit enabled accordingly. Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> CC: <stable@vger.kernel.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-20Merge branch 'next' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc Pull powerpc LE updates from Ben Herrenschmidt: "With my previous pull request I mentioned some remaining Little Endian patches, notably support for our new ABI, which I was sitting on making sure it was all finalized. The toolchain folks confirmed it now, the new ABI is stable and merged with gcc, so we are all good. Oh and we actually missed the actual Kconfig switch for LE so here it is, along with a couple more bug fixes. I have more fixes but not related to LE so I'll send them as a separate pull request tomorrow, let's get this one out of the way. Note that this supports running user space binaries using the new ABI, but the kernel itself still needs to be built with the old one. We'll bring fixes for that after -rc1. Here's Anton log that goes with this series: This patch series adds support for the new ABI, LPAR support for H_SET_MODE and finally adds a kconfig option and defconfig. ABIv2 support was recently committed to binutils and gcc, and should be merged into glibc soon. There are a number of very nice improvements including the removal of function descriptors. Rusty's kernel patches allow binaries of either ABI to work, easing the transition" * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: powerpc: Wrong DWARF CFI in the kernel vdso for little-endian / ELFv2 powerpc: Add pseries_le_defconfig powerpc: Add CONFIG_CPU_LITTLE_ENDIAN kernel config option. powerpc: Don't use ELFv2 ABI to build the kernel powerpc: ELF2 binaries signal handling powerpc: ELF2 binaries launched directly. powerpc: Set eflags correctly for ELF ABIv2 core dumps. powerpc: Add TIF_ELF2ABI flag. pseries: Add H_SET_MODE to change exception endianness powerpc/pseries: Fix endian issues in pseries EEH code
2013-11-20ARM: 7894/1: kconfig: select GENERIC_CLOCKEVENTS if HAVE_ARM_ARCH_TIMERWill Deacon
The ARM architected timer driver doesn't compile without GENERIC_CLOCKEVENTS selected, so ensure that we select it when building for a platform that has the timer. Without this patch, mach-virt fails to build without something like mach-vexpress also selected. Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-11-20ARM: 7893/1: bitops: only emit .arch_extension mp if CONFIG_SMPWill Deacon
Uwe reported a build failure when targetting a NOMMU platform with my recent prefetch changes: arch/arm/lib/changebit.S: Assembler messages: arch/arm/lib/changebit.S:15: Error: architectural extension `mp' is not allowed for the current base architecture This is due to use of the .arch_extension mp directive immediately prior to an ALT_SMP(...) instruction. Whilst the ALT_SMP macro will expand to nothing if !CONFIG_SMP, gas will still choke on the directive. This patch fixes the issue by only emitting the sequence (including the directive) if CONFIG_SMP=y. Tested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
generated by cgit (git 2.34.1) at 2025-07-15 23:30:50 +0000