Skip to content

L
linux
Switch branch/tag
  1. 14 May, 2009 3 commits
    • Alan Jenkins's avatar
      eeepc-laptop: Work around rfkill firmware bug · 978605c4
      Alan Jenkins authored 
      1) Buggy firmware can change the RFKILL state by itself. This is easily
   detected.  The RFKILL API states that in such cases, we should call
   rfkill_force_state() to notify the core.

   I have reported the bug to Asus. I believe this is the right thing
   to do for robustness, even if this particular firmware bug is fixed.

2) The same bug causes the wireless toggle key to be reported as 0x11
   instead of 0x10.  0x11 is otherwise unused, so it should be safe to
   add this as a new keycode.

The bug is triggered by removing the laptop battery while hibernated.

On resume, the wireless toggle key causes the firmware to toggle the
wireless state itself.  (Also, the key is reported as 0x11 when the
current wireless state is OFF).

This is very poor behaviour because the OS can't predict whether the
firmware is controlling the RFKILL state.

Without this workaround, the bug means users have to press the wireless
toggle key twice to enable, due to the OS/firmware conflict.  (Assuming
rfkill-input or equivalent is being used).  The workaround avoids this.

I believe that acpid scripts which toggle the value of the sysfs state file
when the toggle key is pressed will be rendered ineffective by the bug,
regardless of this workaround.  If they simply toggle the state, when the
firmware has already toggled it, then you will never see a state change.

Tested on "EEEPC 4G" only.
Signed-off-by: default avatarAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: default avatarCorentin Chary <corentincj@iksaif.net>
Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      978605c4
    • Darren Salt's avatar
      eeepc-laptop: report brightness control events via the input layer · 64b86b65
      Darren Salt authored 
      This maps the brightness control events to one of two keys, either
KEY_BRIGHTNESSDOWN or KEY_BRIGHTNESSUP, as needed.

Some mapping has to be done due to the fact that the BIOS reports them as
<base value> + <current brightness index>; the selection is done according to
the sign of the change in brightness (if this is 0, no keypress is reported).

(Ref. http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-April/002001.html)
Signed-off-by: default avatarDarren Salt <linux@youmustbejoking.demon.co.uk>
Signed-off-by: default avatarCorentin Chary <corentincj@iksaif.net>
Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      64b86b65
    • Alan Jenkins's avatar
      eeepc-laptop: fix wlan rfkill state change during init · fbc97e4c
      Alan Jenkins authored 
      When an rfkill device is registered, the rfkill core will change its
state to the system default. So we need to prepare for state changes
*before* we register it. That means installing the eeepc-specific ACPI
callback which handles the hotplug of the wireless network adaptor.

This problem doesn't occur during normal operation.  You have to

1) Boot with wireless enabled. eeepc-laptop should load automatically.
2) modprobe -r eeepc-laptop
3) modprobe eeepc-laptop

On boot, the default rfkill state will be set to enabled.
With the current core code, step 2) will disable the wireless.
Therefore in step 3), the wireless will change state during registration,
from disabled to enabled.  But without this fix, the PCI device for the
wireless adaptor will not appear.
Signed-off-by: default avatarAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: default avatarMatthew Garrett <mjg@redhat.com>
Signed-off-by: default avatarCorentin Chary <corentincj@iksaif.net>
Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      fbc97e4c
  3. 09 May, 2009 2 commits
  5. 08 May, 2009 14 commits
  7. 07 May, 2009 13 commits
    • David Howells's avatar
      NOMMU: Don't check vm_region::vm_start is page aligned in add_nommu_region() · 8c9ed899
      David Howells authored 
      Don't check vm_region::vm_start is page aligned in add_nommu_region() because
the region may reflect some non-page-aligned mapped file, such as could be
obtained from RomFS XIP.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
Acked-by: default avatarGreg Ungerer <gerg@uclinux.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8c9ed899
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://neil.brown.name/md · ee7fee0b
      Linus Torvalds authored 
      * 'for-linus' of git://neil.brown.name/md:
  md: remove rd%d links immediately after stopping an array.
  md: remove ability to explicit set an inactive array to 'clean'.
  md: constify VFTs
  md: tidy up status_resync to handle large arrays.
  md: fix some (more) errors with bitmaps on devices larger than 2TB.
  md/raid10: don't clear bitmap during recovery if array will still be degraded.
  md: fix loading of out-of-date bitmap.
      ee7fee0b
    • Linus Torvalds's avatar
      random: make get_random_int() more random · 8a0a9bd4
      Linus Torvalds authored 
      It's a really simple patch that basically just open-codes the current
"secure_ip_id()" call, but when open-coding it we now use a _static_
hashing area, so that it gets updated every time.

And to make sure somebody can't just start from the same original seed of
all-zeroes, and then do the "half_md4_transform()" over and over until
they get the same sequence as the kernel has, each iteration also mixes in
the same old "current->pid + jiffies" we used - so we should now have a
regular strong pseudo-number generator, but we also have one that doesn't
have a single seed.

Note: the "pid + jiffies" is just meant to be a tiny tiny bit of noise. It
has no real meaning. It could be anything. I just picked the previous
seed, it's just that now we keep the state in between calls and that will
feed into the next result, and that should make all the difference.

I made that hash be a per-cpu data just to avoid cache-line ping-pong:
having multiple CPU's write to the same data would be fine for randomness,
and add yet another layer of chaos to it, but since get_random_int() is
supposed to be a fast interface I did it that way instead. I considered
using "__raw_get_cpu_var()" to avoid any preemption overhead while still
getting the hash be _mostly_ ping-pong free, but in the end good taste won
out.
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8a0a9bd4
    • Linus Torvalds's avatar
      Merge master.kernel.org:/home/rmk/linux-2.6-arm · 2c66fa7e
      Linus Torvalds authored 
      * master.kernel.org:/home/rmk/linux-2.6-arm:
  [ARM] 5507/1: support R_ARM_MOVW_ABS_NC and MOVT_ABS relocation types
  [ARM] 5506/1: davinci: DMA_32BIT_MASK --> DMA_BIT_MASK(32)
  i.MX31: Disable CPU_32v6K in mx3_defconfig.
  mx3fb: Fix compilation with CONFIG_PM
  mx27ads: move PBC mapping out of vmalloc space
  MXC: remove BUG_ON in interrupt handler
  mx31: remove mx31moboard_defconfig
  ARM: ARCH_MXC should select HAVE_CLK
  mxc : BUG in imx_dma_request
  mxc : Clean up properly when imx_dma_free() used without imx_dma_disable()
  [ARM] mv78xx0: update defconfig
  [ARM] orion5x: update defconfig
  [ARM] Kirkwood: update defconfig
  [ARM] Kconfig typo fix:  "PXA930" -> "CPU_PXA930".
  [ARM] S3C2412: Add missing cache flush in suspend code
  [ARM] S3C: Add UDIVSLOT support for newer UARTS
  [ARM] S3C64XX: Add S3C64XX_PA_IIS{0,1} to <mach/map.h>
      2c66fa7e
    • Paul Gortmaker's avatar
      [ARM] 5507/1: support R_ARM_MOVW_ABS_NC and MOVT_ABS relocation types · ae51e609
      Paul Gortmaker authored 
      From: Bruce Ashfield <bruce.ashfield@windriver.com>

To fully support the armv7-a instruction set/optimizations, support
for the R_ARM_MOVW_ABS_NC and R_ARM_MOVT_ABS relocation types is
required.

The MOVW and MOVT are both load-immediate instructions, MOVW loads 16
bits into the bottom half of a register, and MOVT loads 16 bits into the
top half of a register.

The relocation information for these instructions has a full 32 bit
value, plus an addend which is stored in the 16 immediate bits in the
instruction itself.  The immediate bits in the instruction are not
contiguous (the register # splits it into a 4 bit and 12 bit value),
so the addend has to be extracted accordingly and added to the value.
The value is then split and put into the instruction; a MOVW uses the
bottom 16 bits of the value, and a MOVT uses the top 16 bits.
Signed-off-by: default avatarDavid Borman <david.borman@windriver.com>
Signed-off-by: default avatarBruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      ae51e609
    • Kevin Hilman's avatar
      [ARM] 5506/1: davinci: DMA_32BIT_MASK --> DMA_BIT_MASK(32) · a029b706
      Kevin Hilman authored 
      As per commit 284901a9, use
DMA_BIT_MASK(n)
Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      a029b706
    • NeilBrown's avatar
      md: remove rd%d links immediately after stopping an array. · c4647292
      NeilBrown authored 
      md maintains link in sys/mdXX/md/ to identify which device has
which role in the array. e.g.
   rd2 -> dev-sda

indicates that the device with role '2' in the array is sda.

These links are only present when the array is active.  They are
created immediately after ->run is called, and so should be removed
immediately after ->stop is called.
However they are currently removed a little bit later, and it is
possible for ->run to be called again, thus adding these links, before
they are removed.

So move the removal earlier so they are consistently only present when
the array is active.
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      c4647292
    • NeilBrown's avatar
      md: remove ability to explicit set an inactive array to 'clean'. · 5bf29597
      NeilBrown authored 
      Being able to write 'clean' to an 'array_state' of an inactive array
to activate it in 'clean' mode is both unnecessary and inconvenient.

It is unnecessary because the same can be achieved by writing
'active'.  This activates and array, but it still remains 'clean'
until the first write.

It is inconvenient because writing 'clean' is more often used to
cause an 'active' array to revert to 'clean' mode (thus blocking
any writes until a 'write-pending' is promoted to 'active').

Allowing 'clean' to both activate an array and mark an active array as
clean can lead to races:  One program writes 'clean' to mark the
active array as clean at the same time as another program writes
'inactive' to deactivate (stop) and active array.  Depending on which
writes first, the array could be deactivated and immediately
reactivated which isn't what was desired.

So just disable the use of 'clean' to activate an array.

This avoids a race that can be triggered with mdadm-3.0 and external
metadata, so it suitable for -stable.
Reported-by: default avatarRafal Marszewski <rafal.marszewski@intel.com>
Acked-by: default avatarDan Williams <dan.j.williams@intel.com>
Cc: <stable@kernel.org>
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      5bf29597
    • Jan Engelhardt's avatar
      md: constify VFTs · 110518bc
      Jan Engelhardt authored 
      Signed-off-by: default avatarJan Engelhardt <jengelh@medozas.de>
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      110518bc
    • NeilBrown's avatar
      md: tidy up status_resync to handle large arrays. · dd71cf6b
      NeilBrown authored 
      Two problems in status_resync.
1/ It still used Kilobytes as the basic block unit, while most code
   now uses sectors uniformly.
2/ It doesn't allow for the possibility that max_sectors exceeds
   the range of "unsigned long".

So
 - change "max_blocks" to "max_sectors", and store sector numbers
   in there and in 'resync'
 - Make 'rt' a 'sector_t' so it can temporarily hold the number of
   remaining sectors.
 - use sector_div rather than normal division.
 - change the magic '100' used to preserve precision to '32'.
   + making it a power of 2 makes division easier
   + it doesn't need to be as large as it was chosen when we averaged
     speed over the entire run.  Now we average speed over the last 30
     seconds or so.
Reported-by: default avatar"Mario 'BitKoenig' Holbe" <Mario.Holbe@TU-Ilmenau.DE>
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      dd71cf6b
    • NeilBrown's avatar
      md: fix some (more) errors with bitmaps on devices larger than 2TB. · db305e50
      NeilBrown authored 
      If a write intent bitmap covers more than 2TB, we sometimes work with
values beyond 32bit, so these need to be sector_t.  This patches
add the required casts to some unsigned longs that are being shifted
up.

This will affect any raid10 larger than 2TB, or any raid1/4/5/6 with
member devices that are larger than 2TB.
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
Reported-by: default avatar"Mario 'BitKoenig' Holbe" <Mario.Holbe@TU-Ilmenau.DE>
Cc: stable@kernel.org
      db305e50
    • NeilBrown's avatar
      md/raid10: don't clear bitmap during recovery if array will still be degraded. · 18055569
      NeilBrown authored 
      If we have a raid10 with multiple missing devices, and we recover just
one of these to a spare, then we risk (depending on the bitmap and
array chunk size) clearing bits of the bitmap for which recovery isn't
complete (because a device is still missing).

This can lead to a subsequent "re-add" being recovered without
any IO happening, which would result in loss of data.

This patch takes the safe approach of not clearing bitmap bits
if the array will still be degraded.

This patch is suitable for all active -stable kernels.

Cc: stable@kernel.org
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      18055569
    • NeilBrown's avatar
      md: fix loading of out-of-date bitmap. · b74fd282
      NeilBrown authored 
      When md is loading a bitmap which it knows is out of date, it fills
each page with 1s and writes it back out again.  However the
write_page call makes used of bitmap->file_pages and
bitmap->last_page_size which haven't been set correctly yet.  So this
can sometimes fail.

Move the setting of file_pages and last_page_size to before the call
to write_page.

This bug can cause the assembly on an array to fail, thus making the
data inaccessible.  Hence I think it is a suitable candidate for
-stable.

Cc: stable@kernel.org
Reported-by: default avatarVojtech Pavlik <vojtech@suse.cz>
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      b74fd282
  9. 06 May, 2009 8 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7