Commits on Feb 4, 2013
  1. Linux 3.0.62

    gregkh committed Feb 4, 2013
  2. x86/Sandy Bridge: Sandy Bridge workaround depends on CONFIG_PCI

    commit e43b3ce upstream.
    early_pci_allowed() and read_pci_config_16() are only available if
    CONFIG_PCI is defined.
    Signed-off-by: H. Peter Anvin <>
    Cc: Jesse Barnes <>
    Signed-off-by: Abdallah Chatila <>
    H. Peter Anvin committed with gregkh Jan 14, 2013
  3. efi, x86: Pass a proper identity mapping in efi_call_phys_prelog

    commit b8f2c21 upstream.
    Update efi_call_phys_prelog to install an identity mapping of all available
    memory.  This corrects a bug on very large systems with more then 512 GB in
    which bios would not be able to access addresses above not in the mapping.
    The result is a crash that looks much like this.
    BUG: unable to handle kernel paging request at 000000effd870020
    IP: [<0000000078bce331>] 0x78bce330
    PGD 0
    Oops: 0000 [#1] SMP
    Modules linked in:
    CPU 0
    Pid: 0, comm: swapper/0 Tainted: G        W    3.8.0-rc1-next-20121224-medusa_ntz+ #2 Intel Corp. Stoutland Platform
    RIP: 0010:[<0000000078bce331>]  [<0000000078bce331>] 0x78bce330
    RSP: 0000:ffffffff81601d28  EFLAGS: 00010006
    RAX: 0000000078b80e18 RBX: 0000000000000004 RCX: 0000000000000004
    RDX: 0000000078bcf958 RSI: 0000000000002400 RDI: 8000000000000000
    RBP: 0000000078bcf760 R08: 000000effd870000 R09: 0000000000000000
    R10: 0000000000000000 R11: 00000000000000c3 R12: 0000000000000030
    R13: 000000effd870000 R14: 0000000000000000 R15: ffff88effd870000
    FS:  0000000000000000(0000) GS:ffff88effe400000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000000effd870020 CR3: 000000000160c000 CR4: 00000000000006b0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process swapper/0 (pid: 0, threadinfo ffffffff81600000, task ffffffff81614400)
     0000000078b80d18 0000000000000004 0000000078bced7b ffff880078b81fff
     0000000000000000 0000000000000082 0000000078bce3a8 0000000000002400
     0000000060000202 0000000078b80da0 0000000078bce45d ffffffff8107cb5a
    Call Trace:
     [<ffffffff8107cb5a>] ? on_each_cpu+0x77/0x83
     [<ffffffff8102f4eb>] ? change_page_attr_set_clr+0x32f/0x3ed
     [<ffffffff81035946>] ? efi_call4+0x46/0x80
     [<ffffffff816c5abb>] ? efi_enter_virtual_mode+0x1f5/0x305
     [<ffffffff816aeb24>] ? start_kernel+0x34a/0x3d2
     [<ffffffff816ae5ed>] ? repair_env_string+0x60/0x60
     [<ffffffff816ae2be>] ? x86_64_start_reservations+0xba/0xc1
     [<ffffffff816ae120>] ? early_idt_handlers+0x120/0x120
     [<ffffffff816ae419>] ? x86_64_start_kernel+0x154/0x163
    Code:  Bad RIP value.
    RIP  [<0000000078bce331>] 0x78bce330
     RSP <ffffffff81601d28>
    CR2: 000000effd870020
    ---[ end trace ead828934fef5eab ]---
    Signed-off-by: Nathan Zimmer <>
    Cc: Thomas Gleixner <>
    Cc: Ingo Molnar <>
    Cc: "H. Peter Anvin" <>
    Signed-off-by: Robin Holt <>
    Signed-off-by: Matt Fleming <>
    Signed-off-by: Greg Kroah-Hartman <>
    Nathan Zimmer committed with gregkh Jan 8, 2013
  4. x86/msr: Add capabilities check

    commit c903f04 upstream.
    At the moment the MSR driver only relies upon file system
    checks. This means that anything as root with any capability set
    can write to MSRs. Historically that wasn't very interesting but
    on modern processors the MSRs are such that writing to them
    provides several ways to execute arbitary code in kernel space.
    Sample code and documentation on doing this is circulating and
    MSR attacks are used on Windows 64bit rootkits already.
    In the Linux case you still need to be able to open the device
    file so the impact is fairly limited and reduces the security of
    some capability and security model based systems down towards
    that of a generic "root owns the box" setup.
    Therefore they should require CAP_SYS_RAWIO to prevent an
    elevation of capabilities. The impact of this is fairly minimal
    on most setups because they don't have heavy use of
    capabilities. Those using SELinux, SMACK or AppArmor rules might
    want to consider if their rulesets on the MSR driver could be
    Signed-off-by: Alan Cox <>
    Cc: Linus Torvalds <>
    Cc: Andrew Morton <>
    Cc: Peter Zijlstra <>
    Signed-off-by: Ingo Molnar <>
    Signed-off-by: Greg Kroah-Hartman <>
    Alan Cox committed with gregkh Nov 15, 2012
  5. smp: Fix SMP function call empty cpu mask race

    commit f44310b upstream.
    I get the following warning every day with v3.7, once or
    twice a day:
      [ 2235.186027] WARNING: at /mnt/sda7/kernel/linux/arch/x86/kernel/apic/ipi.c:109 default_send_IPI_mask_logical+0x2f/0xb8()
    As explained by Linus as well:
     | Once we've done the "list_add_rcu()" to add it to the
     | queue, we can have (another) IPI to the target CPU that can
     | now see it and clear the mask.
     | So by the time we get to actually send the IPI, the mask might
     | have been cleared by another IPI.
    This patch also fixes a system hang problem, if the data->cpumask
    gets cleared after passing this point:
            if (WARN_ONCE(!mask, "empty IPI mask"))
    then the problem in commit 83d349f ("x86: don't send an IPI to
    the empty set of CPU's") will happen again.
    Signed-off-by: Wang YanQing <>
    Acked-by: Linus Torvalds <>
    Acked-by: Jan Beulich <>
    Cc: Paul E. McKenney <>
    Cc: Andrew Morton <>
    [ Tidied up the changelog and the comment in the code. ]
    Signed-off-by: Ingo Molnar <>
    Signed-off-by: Greg Kroah-Hartman <>
    udknight committed with gregkh Jan 26, 2013
  6. Bluetooth: Fix incorrect strncpy() in hidp_setup_hid()

    commit 0a9ab9b upstream.
    The length parameter should be sizeof(req->name) - 1 because there is no
    guarantee that string provided by userspace will contain the trailing
    Can be easily reproduced by manually setting req->name to 128 non-zero
    bytes prior to ioctl(HIDPCONNADD) and checking the device name setup on
    input subsystem:
    $ cat /sys/devices/pnp0/00\:04/tty/ttyS0/hci0/hci0\:1/input8/name
    ("f0:af:f0:af:f0:af" is the device bluetooth address, taken from "phys"
    field in struct hid_device due to overflow.)
    Signed-off-by: Anderson Lizardo <>
    Acked-by: Marcel Holtmann <>
    Signed-off-by: Gustavo Padovan <>
    Signed-off-by: Greg Kroah-Hartman <>
    lizardo committed with gregkh Jan 6, 2013
  7. EDAC: Test correct variable in ->store function

    commit 8024c4c upstream.
    We're testing for ->show but calling ->store().
    Signed-off-by: Dan Carpenter <>
    Signed-off-by: Borislav Petkov <>
    Signed-off-by: Greg Kroah-Hartman <>
    Dan Carpenter committed with gregkh Jan 26, 2013
  8. ALSA: usb-audio: fix invalid length check for RME and other UAC 2 dev…

    commit d56268f upstream.
    Commit 23caaf1 (ALSA: usb-mixer: Add support for Audio Class v2.0)
    forgot to adjust the length check for UAC 2.0 feature unit descriptors.
    This would make the code abort on encountering a feature unit without
    per-channel controls, and thus prevented the driver to work with any
    device having such a unit, such as the RME Babyface or Fireface UCX.
    Reported-by: Florian Hanisch <>
    Tested-by: Matthew Robbetts <>
    Tested-by: Michael Beer <>
    Cc: Daniel Mack <>
    Signed-off-by: Clemens Ladisch <>
    Signed-off-by: Takashi Iwai <>
    Signed-off-by: Greg Kroah-Hartman <>
    cladisch committed with gregkh Nov 29, 2012
  9. ath9k: fix double-free bug on beacon generate failure

    commit 1adb2e2 upstream.
    When the next beacon is sent, the ath_buf from the previous run is reused.
    If getting a new beacon from mac80211 fails, bf->bf_mpdu is not reset, yet
    the skb is freed, leading to a double-free on the next beacon tx attempt,
    resulting in a system crash.
    Signed-off-by: Felix Fietkau <>
    Signed-off-by: John W. Linville <>
    Signed-off-by: Greg Kroah-Hartman <>
    Felix Fietkau committed with gregkh Jan 9, 2013
  10. ath9k_htc: Fix memory leak

    commit 0981c3b upstream.
    SKBs that are allocated in the HTC layer do not have callbacks
    registered and hence ended up not being freed, Fix this by freeing
    them properly in the TX completion routine.
    Reported-by: Larry Finger <>
    Signed-off-by: Sujith Manoharan <>
    Tested-by: Larry Finger <>
    Signed-off-by: John W. Linville <>
    Signed-off-by: Greg Kroah-Hartman <>
    Sujith Manoharan committed with gregkh Jan 9, 2013
  11. Bluetooth: Fix sending HCI commands after reset

    commit dbccd79 upstream.
    After sending reset command wait for its command complete event before
    sending next command. Some chips sends CC event for command received
    before reset if reset was send before chip replied with CC.
    This is also required by specification that host shall not send
    additional HCI commands before receiving CC for reset.
    < HCI Command: Reset (0x03|0x0003) plen 0                              [hci0] 18.404612
    > HCI Event: Command Complete (0x0e) plen 4                            [hci0] 18.405850
          Write Extended Inquiry Response (0x03|0x0052) ncmd 1
            Status: Success (0x00)
    < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0      [hci0] 18.406079
    > HCI Event: Command Complete (0x0e) plen 4                            [hci0] 18.407864
          Reset (0x03|0x0003) ncmd 1
            Status: Success (0x00)
    < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0      [hci0] 18.408062
    > HCI Event: Command Complete (0x0e) plen 12                           [hci0] 18.408835
    Signed-off-by: Szymon Janc <>
    Acked-by: Johan Hedberg <>
    Signed-off-by: Gustavo Padovan <>
    Signed-off-by: Greg Kroah-Hartman <>
    Szymon Janc committed with gregkh Dec 11, 2012
  12. ARM: DMA: Fix struct page iterator in dma_cache_maint() to work with …

    commit 1565337 upstream.
    Subhash Jadavani reported this partial backtrace:
      Now consider this call stack from MMC block driver (this is on the ARMv7
      based board):
      [<c001b50c>] (v7_dma_inv_range+0x30/0x48) from [<c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c)
      [<c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c) from [<c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c)
      [<c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c) from [<c0017ff8>] (dma_map_sg+0x3c/0x114)
    This is caused by incrementing the struct page pointer, and running off
    the end of the sparsemem page array.  Fix this by incrementing by pfn
    instead, and convert the pfn to a struct page.
    Suggested-by: James Bottomley <>
    Tested-by: Subhash Jadavani <>
    Signed-off-by: Russell King <>
    Signed-off-by: Greg Kroah-Hartman <>
    Russell King committed with gregkh Jan 19, 2013
  13. fs/cifs/cifs_dfs_ref.c: fix potential memory leakage

    commit 10b8c7d upstream.
    When it goes to error through line 144, the memory allocated to *devname is
    not freed, and the caller doesn't free it either in line 250. So we free the
    memroy of *devname in function cifs_compose_mount_options() when it goes to
    Signed-off-by: Cong Ding <>
    Reviewed-by: Jeff Layton <>
    Signed-off-by: Steve French <>
    Signed-off-by: Greg Kroah-Hartman <>
    ccding committed with gregkh Jan 23, 2013
  14. can: pch_can: fix invalid error codes

    commit ee50e13 upstream.
    Errors in CAN protocol (location) are reported in data[3] of the can
    frame instead of data[2].
    Signed-off-by: Olivier Sobrie <>
    Signed-off-by: Marc Kleine-Budde <>
    Signed-off-by: Greg Kroah-Hartman <>
    oso committed with gregkh Jan 18, 2013
  15. can: ti_hecc: fix invalid error codes

    commit 71088c4 upstream.
    Errors in CAN protocol (location) are reported in data[3] of the can
    frame instead of data[2].
    Signed-off-by: Olivier Sobrie <>
    Cc: Anant Gole <>
    Signed-off-by: Marc Kleine-Budde <>
    Signed-off-by: Greg Kroah-Hartman <>
    oso committed with gregkh Jan 18, 2013
  16. can: c_can: fix invalid error codes

    commit 6ea4588 upstream.
    Errors in CAN protocol (location) are reported in data[3] of the can
    frame instead of data[2].
    Signed-off-by: Olivier Sobrie <>
    Cc: Bhupesh Sharma <>
    Signed-off-by: Marc Kleine-Budde <>
    Signed-off-by: Greg Kroah-Hartman <>
    oso committed with gregkh Jan 18, 2013
Commits on Jan 28, 2013
  1. Linux 3.0.61

    gregkh committed Jan 28, 2013
  2. ioat: Fix DMA memory sync direction correct flag

    commit ac49898 upstream.
    ioat does DMA memory sync with DMA_TO_DEVICE direction on a buffer allocated
    for DMA_FROM_DEVICE dma, resulting in the following warning from dma debug.
    Fixed the dma_sync_single_for_device() call to use the correct direction.
    [  226.288947] WARNING: at lib/dma-debug.c:990 check_sync+0x132/0x550()
    [  226.288948] Hardware name: ProLiant DL380p Gen8
    [  226.288951] ioatdma 0000:00:04.0: DMA-API: device driver syncs DMA memory with different direction [device address=0x00000000ffff7000] [size=4096 bytes] [mapped with DMA_FROM_DEVICE] [synced with DMA_TO_DEVICE]
    [  226.288953] Modules linked in: iTCO_wdt(+) sb_edac(+) ioatdma(+) microcode serio_raw pcspkr edac_core hpwdt(+) iTCO_vendor_support hpilo(+) dca acpi_power_meter ata_generic pata_acpi sd_mod crc_t10dif ata_piix libata hpsa tg3 netxen_nic(+) sunrpc dm_mirror dm_region_hash dm_log dm_mod
    [  226.288967] Pid: 1055, comm: work_for_cpu Tainted: G        W    3.3.0-0.20.el7.x86_64 #1
    [  226.288968] Call Trace:
    [  226.288974]  [<ffffffff810644cf>] warn_slowpath_common+0x7f/0xc0
    [  226.288977]  [<ffffffff810645c6>] warn_slowpath_fmt+0x46/0x50
    [  226.288980]  [<ffffffff81345502>] check_sync+0x132/0x550
    [  226.288983]  [<ffffffff81345c9f>] debug_dma_sync_single_for_device+0x3f/0x50
    [  226.288988]  [<ffffffff81661002>] ? wait_for_common+0x72/0x180
    [  226.288995]  [<ffffffffa019590f>] ioat_xor_val_self_test+0x3e5/0x832 [ioatdma]
    [  226.288999]  [<ffffffff811a5739>] ? kfree+0x259/0x270
    [  226.289004]  [<ffffffffa0195d77>] ioat3_dma_self_test+0x1b/0x20 [ioatdma]
    [  226.289008]  [<ffffffffa01952c3>] ioat_probe+0x2f8/0x348 [ioatdma]
    [  226.289011]  [<ffffffffa0195f51>] ioat3_dma_probe+0x1d5/0x2aa [ioatdma]
    [  226.289016]  [<ffffffffa0194d12>] ioat_pci_probe+0x139/0x17c [ioatdma]
    [  226.289020]  [<ffffffff81354b8c>] local_pci_probe+0x5c/0xd0
    [  226.289023]  [<ffffffff81083e50>] ? destroy_work_on_stack+0x20/0x20
    [  226.289025]  [<ffffffff81083e68>] do_work_for_cpu+0x18/0x30
    [  226.289029]  [<ffffffff8108d997>] kthread+0xb7/0xc0
    [  226.289033]  [<ffffffff8166cef4>] kernel_thread_helper+0x4/0x10
    [  226.289036]  [<ffffffff81662d20>] ? _raw_spin_unlock_irq+0x30/0x50
    [  226.289038]  [<ffffffff81663234>] ? retint_restore_args+0x13/0x13
    [  226.289041]  [<ffffffff8108d8e0>] ? kthread_worker_fn+0x1a0/0x1a0
    [  226.289044]  [<ffffffff8166cef0>] ? gs_change+0x13/0x13
    [  226.289045] ---[ end trace e1618afc7a606089 ]---
    [  226.289047] Mapped at:
    [  226.289048]  [<ffffffff81345307>] debug_dma_map_page+0x87/0x150
    [  226.289050]  [<ffffffffa019653c>] dma_map_page.constprop.18+0x70/0xb34 [ioatdma]
    [  226.289054]  [<ffffffffa0195702>] ioat_xor_val_self_test+0x1d8/0x832 [ioatdma]
    [  226.289058]  [<ffffffffa0195d77>] ioat3_dma_self_test+0x1b/0x20 [ioatdma]
    [  226.289061]  [<ffffffffa01952c3>] ioat_probe+0x2f8/0x348 [ioatdma]
    Signed-off-by: Shuah Khan <>
    Signed-off-by: Vinod Koul <>
    Signed-off-by: Greg Kroah-Hartman <>
    Shuah Khan committed with gregkh Oct 25, 2012
  3. ACPI / cpuidle: Fix NULL pointer issues when cpuidle is disabled

    commit b88a634 upstream.
    If cpuidle is disabled, that means that:
    	per_cpu(acpi_cpuidle_device, pr->id)
    is set to NULL as the acpi_processor_power_init ends up failing at
    	 retval = cpuidle_register_driver(&acpi_idle_driver)
    (in acpi_processor_power_init) and never sets the per_cpu idle
    device.  So when acpi_processor_hotplug on CPU online notification
    tries to reference said device it crashes:
    cpu 3 spinlock event irq 62
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
    IP: [<ffffffff81381013>] acpi_processor_setup_cpuidle_cx+0x3f/0x105
    PGD a259b067 PUD ab38b067 PMD 0
    Oops: 0002 [#1] SMP
    odules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c nouveau mxm_wmi wmi radeon ttm sg sr_mod sd_mod cdrom ata_generic ata_piix libata crc32c_intel scsi_mod atl1c i915 fbcon tileblit font bitblit softcursor drm_kms_helper video xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd mperf
    CPU 1
    Pid: 3047, comm: bash Not tainted 3.8.0-rc3upstream-00250-g165c029 #1 MSI MS-7680/H61M-P23 (MS-7680)
    RIP: e030:[<ffffffff81381013>]  [<ffffffff81381013>] acpi_processor_setup_cpuidle_cx+0x3f/0x105
    RSP: e02b:ffff88001742dca8  EFLAGS: 00010202
    RAX: 0000000000010be9 RBX: ffff8800a0a61800 RCX: ffff880105380000
    RDX: 0000000000000003 RSI: 0000000000000200 RDI: ffff8800a0a61800
    RBP: ffff88001742dce8 R08: ffffffff81812360 R09: 0000000000000200
    R10: aaaaaaaaaaaaaaaa R11: 0000000000000001 R12: ffff8800a0a61800
    R13: 00000000ffffff01 R14: 0000000000000000 R15: ffffffff81a907a0
    FS:  00007fd6942f7700(0000) GS:ffff880105280000(0000) knlGS:0000000000000000
    CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000004 CR3: 00000000a6773000 CR4: 0000000000042660
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process bash (pid: 3047, threadinfo ffff88001742c000, task ffff880017944000)
     0000000000000150 ffff880100f59e00 ffff88001742dcd8 ffff8800a0a61800
     0000000000000000 00000000ffffff01 0000000000000000 ffffffff81a907a0
     ffff88001742dd18 ffffffff813815b1 ffff88001742dd08 ffffffff810ae336
    Call Trace:
     [<ffffffff813815b1>] acpi_processor_hotplug+0x7c/0x9f
     [<ffffffff810ae336>] ? schedule_delayed_work_on+0x16/0x20
     [<ffffffff8137ee8f>] acpi_cpu_soft_notify+0x90/0xca
     [<ffffffff8166023d>] notifier_call_chain+0x4d/0x70
     [<ffffffff810bc369>] __raw_notifier_call_chain+0x9/0x10
     [<ffffffff81094a4b>] __cpu_notify+0x1b/0x30
     [<ffffffff81652cf7>] _cpu_up+0x103/0x14b
     [<ffffffff81652e18>] cpu_up+0xd9/0xec
     [<ffffffff8164a254>] store_online+0x94/0xd0
     [<ffffffff814122fb>] dev_attr_store+0x1b/0x20
     [<ffffffff81216404>] sysfs_write_file+0xf4/0x170
    This patch fixes it.
    Signed-off-by: Konrad Rzeszutek Wilk <>
    Signed-off-by: Rafael J. Wysocki <>
    Signed-off-by: Greg Kroah-Hartman <>
    Konrad Rzeszutek Wilk committed with gregkh Jan 16, 2013
  4. SGI-XP: handle non-fatal traps

    commit 891348c upstream.
    We found a user code which was raising a divide-by-zero trap.  That trap
    would lead to XPC connections between system-partitions being torn down
    due to the die_chain notifier callouts it received.
    This also revealed a different issue where multiple callers into
    xpc_die_deactivate() would all attempt to do the disconnect in parallel
    which would sometimes lock up but often overwhelm the console on very
    large machines as each would print at least one line of output at the
    end of the deactivate.
    I reviewed all the users of the die_chain notifier and changed the code
    to ignore the notifier callouts for reasons which will not actually lead
    to a system to continue on to call die().
    [ fix ia64]
    Signed-off-by: Robin Holt <>
    Cc: Thomas Gleixner <>
    Cc: Ingo Molnar <>
    Cc: <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    Robin Holt committed with gregkh Dec 20, 2012
  5. x86: Use enum instead of literals for trap values [PARTIAL]

    [Based on commit c940826 upstream, only
    taking the traps.h portion.]
    The traps are referred to by their numbers and it can be difficult to
    understand them while reading the code without context. This patch adds
    enumeration of the trap numbers and replaces the numbers with the correct
    enum for x86.
    Signed-off-by: Kees Cook <>
    Signed-off-by: H. Peter Anvin <>
    Signed-off-by: Robin Holt <>
    Signed-off-by: Greg Kroah-Hartman <>
    kees committed with gregkh Jan 24, 2013
  6. ahci: Add identifiers for ASM106x devices

    commit 7b4f6ec upstream.
    They don't always appear as AHCI class devices but instead as IDE class.
    Based on an initial patch by Hiroaki Nito
    Signed-off-by: Alan Cox <>
    Signed-off-by: Jeff Garzik <>
    Signed-off-by: Abdallah Chatila <>
    Signed-off-by: Greg Kroah-Hartman <>
    Alan Cox committed with gregkh Sep 4, 2012
  7. drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled

    commit 4283908 upstream.
    Quoting from Bspec, 3D_CHICKEN1, bit 10
    This bit needs to be set always to "1", Project: DevSNB "
    Reviewed-by: Rodrigo Vivi <>
    Signed-off-by: Daniel Vetter <>
    Signed-off-by: Abdallah Chatila <>
    Signed-off-by: Greg Kroah-Hartman <>
    danvet committed with gregkh Dec 14, 2012
  8. staging: usbip: changed function return type to void

    commit ac2b41a upstream.
    The function usbip_pad_iso never returns anything but 0 (success).
    Signed-off-by: Bart Westgeest <>
    Cc: Ben Hutchings <>
    Signed-off-by: Greg Kroah-Hartman <>
    Bart Westgeest committed with gregkh Jan 23, 2012
  9. serial: 8250, increase PASS_LIMIT

    commit e7328ae upstream.
    With virtual machines like qemu, it's pretty common to see "too much
    work for irq4" messages nowadays. This happens when a bunch of output
    is printed on the emulated serial console. This is caused by too low
    PASS_LIMIT. When ISR loops more than the limit, it spits the message.
    I've been using a kernel with doubled the limit and I couldn't see no
    problems. Maybe it's time to get rid of the message now?
    Signed-off-by: Jiri Slaby <>
    Cc: Alan Cox <>
    Cc: Ram Gupta <>
    Signed-off-by: Greg Kroah-Hartman <>
    jirislaby committed with gregkh Jun 5, 2011
  10. drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists

    commit 9f9c9cb upstream.
    The right dmi version is in SMBIOS if it's zero in DMI region
    This issue was originally found from an oracle bug.
    One customer noticed system UUID doesn't match between dmidecode & uek2.
     - HP ProLiant BL460c G6 :
       # cat /sys/devices/virtual/dmi/id/product_uuid
       # dmidecode | grep -i uuid
       UUID: 00000000-0000-484C-3031-4D5030333531
    From SMBIOS 2.6 on, spec use little-endian encoding for UUID other than
    network byte order.
    So we need to get dmi version to distinguish.  If version is 0.0, the
    real version is taken from the SMBIOS version.  This is part of original
    kernel comment in code.
    [ checkpatch fixes]
    Signed-off-by: Zhenzhong Duan <>
    Cc: Feng Jin <>
    Cc: Jean Delvare <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Abdallah Chatila <>
    Signed-off-by: Greg Kroah-Hartman <>
    Zhenzhong Duan committed with gregkh Dec 20, 2012
  11. drivers/firmware/dmi_scan.c: check dmi version when get system uuid

    commit f1d8e61 upstream.
    As of version 2.6 of the SMBIOS specification, the first 3 fields of the
    UUID are supposed to be little-endian encoded.
    Also a minor fix to match variable meaning and mute
    [ tweak code comment]
    Signed-off-by: Zhenzhong Duan <>
    Cc: Feng Jin <>
    Cc: Jean Delvare <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Abdallah Chatila <>
    Signed-off-by: Greg Kroah-Hartman <>
    Zhenzhong Duan committed with gregkh Dec 20, 2012
  12. SCSI: sd: Reshuffle init_sd to avoid crash

    commit afd5e34 upstream.
    scsi_register_driver will register a prep_fn() function, which
    in turn migh need to use the sd_cdp_pool for DIF.
    Which hasn't been initialised at this point, leading to
    a crash. So reshuffle the init_sd() and exit_sd() paths
    to have the driver registered last.
    Signed-off-by: Joel D. Diaz <>
    Signed-off-by: Hannes Reinecke <>
    Signed-off-by: James Bottomley <>
    Cc: CAI Qian <>
    Signed-off-by: Greg Kroah-Hartman <>
    Joel D. Diaz committed with gregkh Oct 10, 2012
  13. USB: UHCI: fix IRQ race during initialization

    commit 0f815a0 upstream.
    This patch (as1644) fixes a race that occurs during startup in
    uhci-hcd.  If the IRQ line is shared with other devices, it's possible
    for the handler routine to be called before the data structures are
    fully initialized.
    The problem is fixed by adding a check to the IRQ handler routine.  If
    the initialization hasn't finished yet, the routine will return
    Signed-off-by: Alan Stern <>
    Reported-by: Don Zickus <>
    Tested-by: "Huang, Adrian (ISS Linux TW)" <>
    Signed-off-by: Greg Kroah-Hartman <>
    Alan Stern committed with gregkh Jan 22, 2013
  14. PCI: Allow pcie_aspm=force even when FADT indicates it is unsupported

    commit 9e16721 upstream.
    Right now using pcie_aspm=force will not enable ASPM if the FADT indicates
    ASPM is unsupported.  However, the semantics of force should probably allow
    for this, especially as they did before 3c07635 ("PCI: Rework ASPM
    disable code")
    This patch just skips the clearing of any ASPM setup that the firmware has
    carried out on this bus if pcie_aspm=force is being used.
    Signed-off-by: Colin Ian King <>
    Signed-off-by: Bjorn Helgaas <>
    Signed-off-by: Greg Kroah-Hartman <>
    ColinIanKing committed with gregkh Nov 27, 2012
  15. ftrace: Be first to run code modification on modules

    commit c1bf08a upstream.
    If some other kernel subsystem has a module notifier, and adds a kprobe
    to a ftrace mcount point (now that kprobes work on ftrace points),
    when the ftrace notifier runs it will fail and disable ftrace, as well
    as kprobes that are attached to ftrace points.
    Here's the error:
     WARNING: at kernel/trace/ftrace.c:1618 ftrace_bug+0x239/0x280()
     Hardware name: Bochs
     Modules linked in: fat(+) stap_56d28a51b3fe546293ca0700b10bcb29__8059(F) nfsv4 auth_rpcgss nfs dns_resolver fscache xt_nat iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack lockd sunrpc ppdev parport_pc parport microcode virtio_net i2c_piix4 drm_kms_helper ttm drm i2c_core [last unloaded: bid_shared]
     Pid: 8068, comm: modprobe Tainted: GF            3.7.0-0.rc8.git0.1.fc19.x86_64 #1
     Call Trace:
      [<ffffffff8105e70f>] warn_slowpath_common+0x7f/0xc0
      [<ffffffff81134106>] ? __probe_kernel_read+0x46/0x70
      [<ffffffffa0180000>] ? 0xffffffffa017ffff
      [<ffffffffa0180000>] ? 0xffffffffa017ffff
      [<ffffffff8105e76a>] warn_slowpath_null+0x1a/0x20
      [<ffffffff810fd189>] ftrace_bug+0x239/0x280
      [<ffffffff810fd626>] ftrace_process_locs+0x376/0x520
      [<ffffffff810fefb7>] ftrace_module_notify+0x47/0x50
      [<ffffffff8163912d>] notifier_call_chain+0x4d/0x70
      [<ffffffff810882f8>] __blocking_notifier_call_chain+0x58/0x80
      [<ffffffff81088336>] blocking_notifier_call_chain+0x16/0x20
      [<ffffffff810c2a23>] sys_init_module+0x73/0x220
      [<ffffffff8163d719>] system_call_fastpath+0x16/0x1b
     ---[ end trace 9ef46351e53bbf80 ]---
     ftrace failed to modify [<ffffffffa0180000>] init_once+0x0/0x20 [fat]
      actual: cc:bb:d2:4b:e1
    A kprobe was added to the init_once() function in the fat module on load.
    But this happened before ftrace could have touched the code. As ftrace
    didn't run yet, the kprobe system had no idea it was a ftrace point and
    simply added a breakpoint to the code (0xcc in the cc:bb:d2:4b:e1).
    Then when ftrace went to modify the location from a call to mcount/fentry
    into a nop, it didn't see a call op, but instead it saw the breakpoint op
    and not knowing what to do with it, ftrace shut itself down.
    The solution is to simply give the ftrace module notifier the max priority.
    This should have been done regardless, as the core code ftrace modification
    also happens very early on in boot up. This makes the module modification
    closer to core modification.
    Acked-by: Masami Hiramatsu <>
    Reported-by: Frank Ch. Eigler <>
    Signed-off-by: Steven Rostedt <>
    Steven Rostedt committed with gregkh Dec 14, 2012
  16. drm/i915: Invalidate the relocation presumed_offsets along the slow path

    commit 262b6d3 upstream.
    In the slow path, we are forced to copy the relocations prior to
    acquiring the struct mutex in order to handle pagefaults. We forgo
    copying the new offsets back into the relocation entries in order to
    prevent a recursive locking bug should we trigger a pagefault whilst
    holding the mutex for the reservations of the execbuffer. Therefore, we
    need to reset the presumed_offsets just in case the objects are rebound
    back into their old locations after relocating for this exexbuffer - if
    that were to happen we would assume the relocations were valid and leave
    the actual pointers to the kernels dangling, instant hang.
    Fixes regression from commit bcf50e2
    Author: Chris Wilson <>
    Date:   Sun Nov 21 22:07:12 2010 +0000
        drm/i915: Handle pagefaults in execbuffer user relocations
    Signed-off-by: Chris Wilson <>
    Cc: Daniel Vetter <>
    Signed-off-by: Daniel Vetter <>
    ickle committed with gregkh Jan 15, 2013
Commits on Jan 21, 2013
  1. Linux 3.0.60

    gregkh committed Jan 21, 2013
  2. staging: vt6656: Fix inconsistent structure packing

    commit 1ee4c55 upstream.
    vt6656 has several headers that use the #pragma pack(1) directive to
    enable structure packing, but never disable it.  The layout of
    structures defined in other headers can then depend on which order the
    various headers are included in, breaking the One Definition Rule.
    In practice this resulted in crashes on x86_64 until the order of header
    inclusion was changed for some files in commit 11d404c ('staging:
    vt6656: fix headers and add cfg80211.').  But we need a proper fix that
    won't be affected by future changes to the order of inclusion.
    This removes the #pragma pack(1) directives and adds __packed to the
    structure definitions for which packing appears to have been intended.
    Reported-and-tested-by: Malcolm Priestley <>
    Signed-off-by: Ben Hutchings <>
    Signed-off-by: Greg Kroah-Hartman <>
    bwhacks committed with gregkh Jan 14, 2013
  3. serial:ifx6x60:Delete SPI timer when shut down port

    commit 014b9b4 upstream.
    When shut down SPI port, it's possible that MRDY has been asserted and a SPI
    timer was activated waiting for SRDY assert, in the case, it needs to delete
    this timer.
    Signed-off-by: Chen Jun <>
    Signed-off-by: channing <>
    Signed-off-by: Greg Kroah-Hartman <>
    ChaoBi committed with gregkh Dec 12, 2012