18 Jan, 2012

3 commits

  • Function split up, should have no functional change.

    Provides entry point for physically hotplugged CPUs
    to initialize and activate cpuidle.

    Signed-off-by: Thomas Renninger
    CC: Deepthi Dharwar
    CC: Shaohua Li
    CC: Andrew Morton
    Signed-off-by: Len Brown

    Thomas Renninger
     
  • V2: Fix typo: pr->handle -> pr, here: acpi_processor_hotadd_init(pr)

    This is a very small part taken from patches which afaik
    are coming from Yunhong Jiang (for a Xen not a Linus repo?).

    Cleanup only: no functional change.

    Advantage (beside cleanup) is that other data of the pr (acpi_processor) struct
    in the acpi_processor_hotadd_init() is needed later, for example a newly
    introduced flag:
    pr->flags.need_hotplug_init

    Signed-off-by: Thomas Renninger
    CC: Bjorn Helgaas
    CC: Jiang, Yunhong
    Signed-off-by: Len Brown

    Thomas Renninger
     
  • Since commit 46bcfad7a819bd17ac4e831b04405152d59784ab registering
    and unregistering cpuidle is done in processor_idle.c.
    Unregistering via:
    acpi_bus_unregister_driver(&acpi_processor_driver)
    -> acpi_processor_remove()
    -> acpi_processor_power_exit()

    Remove not needed cpuidle_unregister_driver() call from
    acpi_processor_exit

    Signed-off-by: Thomas Renninger
    CC: Deepthi Dharwar
    Signed-off-by: Len Brown

    Thomas Renninger
     

17 Jan, 2012

2 commits

  • Signed-off-by: Thomas Renninger
    Signed-off-by: Len Brown

    Thomas Renninger
     
  • For UP processor, it is likely that no _MAT method or MADT table defined.
    So currently acpi_get_cpuid(...) always return -1 for UP processor.
    This is wrong. It should return valid value for CPU0.

    In the other hand, BIOS may define multiple CPU handles even for UP
    processor, for example

    Scope (_PR)
    {
    Processor (CPU0, 0x00, 0x00000410, 0x06) {}
    Processor (CPU1, 0x01, 0x00000410, 0x06) {}
    Processor (CPU2, 0x02, 0x00000410, 0x06) {}
    Processor (CPU3, 0x03, 0x00000410, 0x06) {}
    }

    We should only return valid value for CPU0's acpi handle.
    And return invalid value for others.

    http://marc.info/?t=132329819900003&r=1&w=2

    Cc: stable@vger.kernel.org
    Reported-and-tested-by: wallak@free.fr
    Signed-off-by: Lin Ming
    Signed-off-by: Len Brown

    Lin Ming
     

05 Jan, 2012

2 commits


04 Jan, 2012

6 commits

  • This reverts commit 93b2ec0128c431148b216b8f7337c1a52131ef03.

    The call to "schedule_work()" in rtc_initialize_alarm() happens too
    early, and can cause oopses at bootup

    Neil Brown explains why we do it:

    "If you set an alarm in the future, then shutdown and boot again after
    that time, then you will end up with a timer_queue node which is in
    the past.

    When this happens the queue gets stuck. That entry-in-the-past won't
    get removed until and interrupt happens and an interrupt won't happen
    because the RTC only triggers an interrupt when the alarm is "now".

    So you'll find that e.g. "hwclock" will always tell you that
    'select' timed out.

    So we force the interrupt work to happen at the start just in case."

    and has a patch that convert it to do things in-process rather than with
    the worker thread, but right now it's too late to play around with this,
    so we just revert the patch that caused problems for now.

    Reported-by: Sander Eikelenboom
    Requested-by: Konrad Rzeszutek Wilk
    Requested-by: John Stultz
    Cc: Neil Brown
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • This reverts commit c0afabd3d553c521e003779c127143ffde55a16f.

    It causes failures on Toshiba laptops - instead of disabling the alarm,
    it actually seems to enable it on the affected laptops, resulting in
    (for example) the laptop powering on automatically five minutes after
    shutdown.

    There's a patch for it that appears to work for at least some people,
    but it's too late to play around with this, so revert for now and try
    again in the next merge window.

    See for example

    http://bugs.debian.org/652869

    Reported-and-bisected-by: Andreas Friedrich (Toshiba Tecra)
    Reported-by: Antonio-M. Corbi Bellot (Toshiba Portege R500)
    Reported-by: Marco Santos (Toshiba Portege Z830)
    Reported-by: Christophe Vu-Brugier (Toshiba Portege R830)
    Cc: Jonathan Nieder
    Requested-by: John Stultz
    Cc: stable@kernel.org # for the versions that applied this
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • If 'iw connect' command is fired when driver is already busy in
    serving 'iw scan' command, ssid specific scan operation for connect
    is skipped. In this case cmd wait queue handler gets called with no
    command in queue (i.e. adapter->cmd_queued = NULL).

    This patch adds a NULL check in mwifiex_wait_queue_complete()
    routine to fix crash observed during simultaneous scan and assoc
    operations.

    Signed-off-by: Amitkumar Karwar
    Signed-off-by: Bing Zhao
    Signed-off-by: John W. Linville

    Amitkumar Karwar
     
  • This patch fixes the regression, introduced by

    commit 17030f48e31adde5b043741c91ba143f5f7db0fd
    From: Rafał Miłecki
    Date: Thu, 11 Aug 2011 17:16:27 +0200
    Subject: [PATCH] b43: support new RX header, noticed to be used in 598.314+ fw

    in PIO case.

    Signed-off-by: Guennadi Liakhovetski
    Signed-off-by: John W. Linville

    Guennadi Liakhovetski
     
  • don't do aggregation related stuff for 'AP mode client power save
    handling' if aggregation is not enabled in the driver, otherwise it
    will lead to panic because those data structures won't be never
    intialized in 'ath_tx_node_init' if aggregation is disabled

    EIP is at ath_tx_aggr_wakeup+0x37/0x80 [ath9k]
    EAX: e8c09a20 EBX: f2a304e8 ECX: 00000001 EDX: 00000000
    ESI: e8c085e0 EDI: f2a304ac EBP: f40e1ca4 ESP: f40e1c8c
    DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
    Process swapper/1 (pid: 0, ti=f40e0000 task=f408e860
    task.ti=f40dc000)
    Stack:
    0001e966 e8c09a20 00000000 f2a304ac e8c085e0 f2a304ac
    f40e1cb0 f8186741
    f8186700 f40e1d2c f922988d f2a304ac 00000202 00000001
    c0b4ba43 00000000
    0000000f e8eb75c0 e8c085e0 205b0001 34383220 f2a304ac
    f2a30000 00010020
    Call Trace:
    [] ath9k_sta_notify+0x41/0x50 [ath9k]
    [] ? ath9k_get_survey+0x110/0x110 [ath9k]
    [] ieee80211_sta_ps_deliver_wakeup+0x9d/0x350
    [mac80211]
    [] ? __module_address+0x95/0xb0
    [] ap_sta_ps_end+0x63/0xa0 [mac80211]
    [] ieee80211_rx_h_sta_process+0x156/0x2b0
    [mac80211]
    [] ieee80211_rx_handlers+0xce/0x510 [mac80211]
    [] ? trace_hardirqs_on+0xb/0x10
    [] ? skb_queue_tail+0x3e/0x50
    [] ieee80211_prepare_and_rx_handle+0x111/0x750
    [mac80211]
    [] ieee80211_rx+0x349/0xb20 [mac80211]
    [] ? ieee80211_rx+0x99/0xb20 [mac80211]
    [] ath_rx_tasklet+0x818/0x1d00 [ath9k]
    [] ? ath9k_tasklet+0x35/0x1c0 [ath9k]
    [] ? ath9k_tasklet+0x35/0x1c0 [ath9k]
    [] ath9k_tasklet+0xf3/0x1c0 [ath9k]
    [] tasklet_action+0xbe/0x180

    Cc: stable@kernel.org
    Cc: Senthil Balasubramanian
    Cc: Rajkumar Manoharan
    Reported-by: Ashwin Mendonca
    Tested-by: Ashwin Mendonca
    Signed-off-by: Mohammed Shafi Shajakhan
    Signed-off-by: John W. Linville

    Mohammed Shafi Shajakhan
     
  • If one only selects mx23-based boards, compile fails:

    drivers/net/ethernet/freescale/fec.c:410:2: error: 'FEC_HASH_TABLE_HIGH' undeclared (first use in this function)
    drivers/net/ethernet/freescale/fec.c:411:2: error: 'FEC_HASH_TABLE_LOW' undeclared (first use in this function)

    This is because fec.h uses CONFIG_SOC_IMX28 to determine the register
    layout of the core which makes sense since the MX23 does not have a fec.
    However, Kconfig uses the broader ARCH_MXS symbol and this way even
    makes the fec-driver default for MX23. Adapt Kconfig to use the more
    precise SOC_IMX28 as well.

    Signed-off-by: Wolfram Sang
    Cc: Fabio Estevam
    Cc: Uwe Kleine-König
    Cc: Shawn Guo
    Cc: David S. Miller
    Acked-by: Fabio Estevam
    Signed-off-by: David S. Miller

    Wolfram Sang
     

03 Jan, 2012

2 commits


02 Jan, 2012

1 commit


01 Jan, 2012

1 commit

  • The current gspca core code has a regression where it no longer properly
    falls back to lower alt settings when there is not enough bandwidth.

    This causes many iso based usb-1 cameras to not work when plugged into a
    usb2 hub or a sandybridge chipset motherboard!

    This patch fixes this.

    Signed-off-by: Hans de Goede
    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Linus Torvalds

    Mauro Carvalho Chehab
     

31 Dec, 2011

6 commits


30 Dec, 2011

3 commits


28 Dec, 2011

1 commit

  • Redhat Bugzilla: Bug 727875 - TCO_EN bit is disabled by TCO driver

    The previous patch breaks reset watchdog behaviour on the older hardware.
    It is therefor better to make sure that the behaviour for older hardware ( Do not turn off SMI clearing watchdog.
    turn_SMI_watchdog_clear_off=1 -> Turn off SMI clearing watchdog when iTCO_version=1
    (ICHO till ICH5 + 6300ESB only)
    turn_SMI_watchdog_clear_off=2 -> Turn off SMI clearing watchdog.

    Signed-off-by: Wim Van Sebroeck

    Wim Van Sebroeck
     

27 Dec, 2011

2 commits

  • RC6 fails again.

    > I found my system freeze mostly during starting up X and KDE. Sometimes it
    > works for some minutes, sometimes it freezes immediatly. When the freeze
    > happens, everything is dead (even the reset button does not work, I need to
    > power cycle).

    > I disabled RC6, and my system runs wonderfully.

    > The system is a Z68 Pro board with Sandybridge i5-2500K processor, 8
    > GB of RAM and UEFI firmware.

    Reported-by: Kai Krakow
    Signed-off-by: Keith Packard
    Signed-off-by: Linus Torvalds

    Keith Packard
     
  • Semaphores still cause problems on some machines:

    > From Udo Steinberg:
    >
    > With Linux-3.2-rc6 I'm frequently seeing GPU hangs when large amounts of
    > text scroll in an xterm, such as when extracting a tar archive. Such as this
    > one (note the timestamps):
    >
    > I can reproduce it fairly easily with something
    > as simple as:
    >
    > while true; do dmesg; done

    This patch turns them off on SNB while leaving them on for IVB.

    Reported-by: Udo Steinberg
    Cc: Daniel Vetter
    Cc: Eugeni Dodonov
    Signed-off-by: Keith Packard
    Signed-off-by: Linus Torvalds

    Keith Packard
     

26 Dec, 2011

3 commits

  • This patch makes use of the set_memory_x() kernel API in order
    to make necessary BIOS calls to source NMIs.

    This is needed for SLES11 SP2 and the latest upstream kernel as it appears
    the NX Execute Disable has grown in its control.

    Signed-off by: Thomas Mingarelli
    Signed-off by: Wim Van Sebroeck
    Cc: stable@kernel.org

    Mingarelli, Thomas
     
  • The AMBA ID table is marked as __initdata, yet it is referenced by the
    driver struct which is not. This causes a (somewhat unhelpful) section
    mismatch warning:

    WARNING: drivers/watchdog/sp805_wdt.o(.data+0x4c): Section mismatch in
    reference from the variable sp805_wdt_driver to the (unknown
    reference) .init.data:(unknown)

    Fix this by removing the annotation.

    Signed-off-by: Nick Bowler
    Signed-off-by: Wim Van Sebroeck

    Nick Bowler
     
  • The state holders used in the PM path of the drivers report as
    unused variables when compiling without CONFIG_PM so let's
    move them inside CONFIG_PM.

    Signed-off-by: Linus Walleij
    Signed-off-by: Wim Van Sebroeck

    Linus Walleij
     

25 Dec, 2011

1 commit


24 Dec, 2011

1 commit


23 Dec, 2011

6 commits

  • Make sure that mutex is released upon register writing failure.
    This fixes boot freezing observed on ARM based OLPC
    (http://dev.laptop.org/ticket/11357).

    Signed-off-by: Paul Fox
    Signed-off-by: Tai-hwa Liang
    Signed-off-by: Dmitry Torokhov

    Tai-hwa Liang
     
  • * 'for-linus' of git://neil.brown.name/md:
    md/bitmap: It is OK to clear bits during recovery.
    md: don't give up looking for spares on first failure-to-add
    md/raid5: ensure correct assessment of drives during degraded reshape.
    md/linear: fix hot-add of devices to linear arrays.

    Linus Torvalds
     
  • commit d0a4bb492772ce5c4bdfba3744a99ed6f6fb238f introduced a
    regression which is annoying but fairly harmless.

    When writing to an array that is undergoing recovery (a spare
    in being integrated into the array), writing to the array will
    set bits in the bitmap, but they will not be cleared when the
    write completes.

    For bits covering areas that have not been recovered yet this is not a
    problem as the recovery will clear the bits. However bits set in
    already-recovered region will stay set and never be cleared.
    This doesn't risk data integrity. The only negatives are:
    - next time there is a crash, more resyncing than necessary will
    be done.
    - the bitmap doesn't look clean, which is confusing.

    While an array is recovering we don't want to update the
    'events_cleared' setting in the bitmap but we do still want to clear
    bits that have very recently been set - providing they were written to
    the recovering device.

    So split those two needs - which previously both depended on 'success'
    and always clear the bit of the write went to all devices.

    Signed-off-by: NeilBrown

    NeilBrown
     
  • Before performing a recovery we try to remove any spares that
    might not be working, then add any that might have become relevant.

    Currently we abort on the first spare that cannot be added.
    This is a false optimisation.
    It is conceivable that - depending on rules in the personality - a
    subsequent spare might be accepted.
    Also the loop does other things like count the available spares and
    reset the 'recovery_offset' value.

    If we abort early these might not happen properly.

    So remove the early abort.

    In particular if you have an array what is undergoing recovery and
    which has extra spares, then the recovery may not restart after as
    reboot as the could of 'spares' might end up as zero.

    Reported-by: Anssi Hannula
    Signed-off-by: NeilBrown

    NeilBrown
     
  • While reshaping a degraded array (as when reshaping a RAID0 by first
    converting it to a degraded RAID4) we currently get confused about
    which devices are in_sync. In most cases we get it right, but in the
    region that is being reshaped we need to treat non-failed devices as
    in-sync when we have the data but haven't actually written it out yet.

    Reported-by: Adam Kwolek
    Signed-off-by: NeilBrown

    NeilBrown
     
  • commit d70ed2e4fafdbef0800e73942482bb075c21578b
    broke hot-add to a linear array.
    After that commit, metadata if not written to devices until they
    have been fully integrated into the array as determined by
    saved_raid_disk. That patch arranged to clear that field after
    a recovery completed.

    However for linear arrays, there is no recovery - the integration is
    instantaneous. So we need to explicitly clear the saved_raid_disk
    field.

    Signed-off-by: NeilBrown

    NeilBrown