Skip to content

L
linux
Switch branch/tag
  1. 17 Nov, 2009 3 commits
  3. 15 Nov, 2009 13 commits
  5. 14 Nov, 2009 8 commits
  7. 13 Nov, 2009 16 commits
    • Kevin D. Kissell's avatar
      MIPS: SMTC: Fix lockup in smtc_distribute_timer · 5df9d11b
      Kevin D. Kissell authored 
      1. At the end of smtc_distribute_timer, nextstamp is valid and has already
   passed so we goto repeat.
2. Nothing updates nextstamp (only updated if the timeout is in the future
   And we just decided it is in the past)
3. At the end nextstamp still has the same value so it is still valid and
   in the past.
4. This repeats until read_c0_count has a value which causes nextstamp to
   be in the future.

Reported and initial patch and testing  by Mikael Starvik
<mikael.starvik@axis.com>.
Signed-off-by: default avatarKevin D. Kissell <kevink@paralogos.com>
Cc: Mikael Starvik <mikael.starvik@axis.com>
Cc: linux-mips@linux-mips.org
Cc: Jesper Nilsson <Jesper.Nilsson@axis.com>
Patchwork: http://patchwork.linux-mips.org/patch/621/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      5df9d11b
    • Atsushi Nemoto's avatar
      MIPS: TXx9: Update rbtx49xx_defconfig · 1b12a9c8
      Atsushi Nemoto authored 
      Enable following features:

  * MTD (RBTX4939, NAND_TXX9NDFMC)
  * HW_RANDOM (HW_RANDOM_TX4939)
  * SOUND (SND_SOC_TXX9ACLC)
  * DMADEVICE (TXX9_DMAC)
Signed-off-by: default avatarAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      1b12a9c8
    • Atsushi Nemoto's avatar
      MIPS: Make local arrays with CL_SIZE static __initdata · c4304529
      Atsushi Nemoto authored 
      Since commit 22242681 ("MIPS: Extend
COMMAND_LINE_SIZE"), CL_SIZE is 4096 and local array variables with this
size will cause an build failure with default CONFIG_FRAME_WARN settings.

Although current users of such array variables are all early bootstrap
code and not likely to cause real stack overflow (thread_info corruption),
it is preferable to  to declare these arrays static with __initdata.
Signed-off-by: default avatarAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      c4304529
    • Yoichi Yuasa's avatar
      MIPS: Add DMA declare coherent memory support · f8ac0425
      Yoichi Yuasa authored 
      The ohci-sm501 driver requires dma_declare_coherent_memory().  It is used
by the driver's local memory allocation with dma_alloc_coherent().

Tested on TANBAC TB0287(VR4131 + SM501).

[Ralf: Fixed reject in dma-default.c and removed the entire #if 0'ed block
 in dma-mapping.h instead of just the #if 0.]
Signed-off-by: default avatarYoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      f8ac0425
    • David Daney's avatar
      MIPS: Fix emulation of 64-bit FPU on FPU-less 64-bit CPUs. · da0bac33
      David Daney authored 
      Running a 64-bit kernel on a 64-bit CPU without an FPU would cause the
emulator to run in 32-bit mode.  The c0_Status.FR bit is wired to zero
on systems without an FPU, so using that bit to decide how the emulator
behaves doesn't allow for proper emulation on 64-bit FPU-less
processors.

Instead, we need to select the emulator mode based on the user-space
ABI.  Since the thread flag TIF_32BIT_REGS is used to set c0_Status.FR,
we can just use it to decide if the emulator should be in 32-bit or
64-bit mode.
Signed-off-by: default avatarDavid Daney <ddaney@caviumnetworks.com>
Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      da0bac33
    • Christian Borntraeger's avatar
      [S390] s390: fix single stepping on svc0 · bcc6525f
      Christian Borntraeger authored 
      On s390 there are two ways of specifying the system call number for
the svc instruction. The standard way is to use the immediate field
in the instruction (or to use EXecute for values unknown during
assemble time). This can encode 256 system calls.
The kernel ABI also allows to put the system call number in r1 and
then execute svc 0 to enable system call numbers > 255.

It turns out that single stepping svc 0 is broken, since the PER
program check handler uses r1. We have to use a different register.
Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      bcc6525f
    • Martin Schwidefsky's avatar
      [S390] sclp: undo quiesce handler override on resume · 8b94c1ed
      Martin Schwidefsky authored 
      In a system where the ctrl-alt-del init action initiated by signal
quiesce suspends the machine the quiesce handler override for
_machine_restart, _machine_halt and _machine_power_off needs to be
undone, otherwise the override is still present in the resumed
system. The next shutdown would then load the quiesce state psw
instead of performing the correct shutdown action.
Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      8b94c1ed
    • Martin Schwidefsky's avatar
      [S390] reset cputime accounting after IPL from NSS · b89031e0
      Martin Schwidefsky authored 
      After an IPL from NSS the uptime of the system is incorrect. The reason
is that the startup code in head.S is not executed in case of an IPL
from NSS. Due to that sched_clock_base_cc which is used to initialze
wall_to_monotonic contains the time stamp when the NSS has been created
instead of the time stamp of the system start.

Reinitialize the cputime accounting values in create_kernel_nss after
the SAVESYS CP command that created the NSS segment.
Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      b89031e0
    • Gerald Schaefer's avatar
      [S390] monreader: fix use after free bug with suspend/resume · ccaf6553
      Gerald Schaefer authored 
      The monreader device driver doesn't set dev->driver_data to NULL after
freeing the corresponding data structure. This leads to a use after
free bug in the freeze/thaw suspend/resume functions after the device
has been opened and closed once. Fix this by clearing dev->driver_data
in the close() function.
Signed-off-by: default avatarGerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      ccaf6553
    • Takashi Iwai's avatar
      Input: psmouse - remove unneeded '\n' from psmouse.proto parameter · 3d4c3aa9
      Takashi Iwai authored 
      The get parameter function should return a string without a life-feed.
Otherwise you'll see additional empty line in sysfs parameters file.
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      3d4c3aa9
    • Dmitry Torokhov's avatar
      Input: atkbd - restore LED state at reconnect · d4119bda
      Dmitry Torokhov authored 
      Even though input core tells us to restore LED state and repeat rate
at resume keyboard may be reconnected either by request from userspace
(via sysfs) or just by pulling it from the box and plugging it back in.
In these cases we still need to restore state ourselves.
Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      d4119bda
    • Dmitry Torokhov's avatar
      Input: force LED reset on resume · 3cc96351
      Dmitry Torokhov authored 
      We should be sending EV_LED event down to drivers upon resume even in cases
when in-kernel state of the LED is off since device could come up with some
leds turned on.
Reported-and-tested-by: default avatarMikko Vinni <mmvinni@yahoo.com>
Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      3cc96351
    • NeilBrown's avatar
      md/raid5: Allow dirty-degraded arrays to be assembled when only party is degraded. · c148ffdc
      NeilBrown authored 
      Normally is it not safe to allow a raid5 that is both dirty and
degraded to be assembled without explicit request from that admin, as
it can cause hidden data corruption.
This is because 'dirty' means that the parity cannot be trusted, and
'degraded' means that the parity needs to be used.

However, if the device that is missing contains only parity, then
there is no issue and assembly can continue.
This particularly applies when a RAID5 is being converted to a RAID6
and there is an unclean shutdown while the conversion is happening.

So check for whether the degraded space only contains parity, and
in that case, allow the assembly.
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      c148ffdc
    • NeilBrown's avatar
      Don't unconditionally set in_sync on newly added device in raid5_reshape · 7ef90146
      NeilBrown authored 
      When a reshape finds that it can add spare devices into the array,
those devices might already be 'in_sync' if they are beyond the old
size of the array, or they might not if they are within the array.

The first case happens when we change an N-drive RAID5 to an
N+1-drive RAID5.
The second happens when we convert an N-drive RAID5 to an
N+1-drive RAID6.

So set the flag more carefully.
Also, ->recovery_offset is only meaningful when the flag is clear,
so only set it in that case.

This change needs the preceding two to ensure that the non-in_sync
device doesn't get evicted from the array when it is stopped, in the
case where v0.90 metadata is used.
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      7ef90146
    • NeilBrown's avatar
      md: allow v0.91 metadata to record devices as being active but not in-sync. · 0261cd9f
      NeilBrown authored 
      This is a combination that didn't really make sense before.
However when a reshape is converting e.g. raid5 -> raid6, the extra
device is not fully in-sync, but is certainly active and contains
important data.
So allow that start to be meaningful and in particular get
the 'recovery_offset' value (which is needed for any non-in-sync
active device) from the reshape_position.
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      0261cd9f
    • Ryusuke Konishi's avatar
      nilfs2: fix lock order reversal in chcp operation · c1ea985c
      Ryusuke Konishi authored 
      Will fix the following lock order reversal lockdep detected:

=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.32-rc6 #7
-------------------------------------------------------
chcp/30157 is trying to acquire lock:
 (&nilfs->ns_mount_mutex){+.+.+.}, at: [<fed7cfcc>] nilfs_cpfile_change_cpmode+0x46/0x752 [nilfs2]

but task is already holding lock:
 (&nilfs->ns_segctor_sem){++++.+}, at: [<fed7ca32>] nilfs_transaction_begin+0xba/0x110 [nilfs2]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&nilfs->ns_segctor_sem){++++.+}:
       [<c105799c>] __lock_acquire+0x109c/0x139d
       [<c1057d26>] lock_acquire+0x89/0xa0
       [<c14151e2>] down_read+0x31/0x45
       [<fed6d77b>] nilfs_attach_checkpoint+0x8f/0x16b [nilfs2]
       [<fed6e393>] nilfs_get_sb+0x3e7/0x653 [nilfs2]
       [<c10c0ccb>] vfs_kern_mount+0x8b/0x124
       [<c10c0db2>] do_kern_mount+0x37/0xc3
       [<c10d7517>] do_mount+0x64d/0x69d
       [<c10d75cd>] sys_mount+0x66/0x95
       [<c1002a14>] sysenter_do_call+0x12/0x32

-> #1 (&type->s_umount_key#31/1){+.+.+.}:
       [<c105799c>] __lock_acquire+0x109c/0x139d
       [<c1057d26>] lock_acquire+0x89/0xa0
       [<c104c0f3>] down_write_nested+0x34/0x52
       [<c10c08fe>] sget+0x22e/0x389
       [<fed6e133>] nilfs_get_sb+0x187/0x653 [nilfs2]
       [<c10c0ccb>] vfs_kern_mount+0x8b/0x124
       [<c10c0db2>] do_kern_mount+0x37/0xc3
       [<c10d7517>] do_mount+0x64d/0x69d
       [<c10d75cd>] sys_mount+0x66/0x95
       [<c1002a14>] sysenter_do_call+0x12/0x32

-> #0 (&nilfs->ns_mount_mutex){+.+.+.}:
       [<c1057727>] __lock_acquire+0xe27/0x139d
       [<c1057d26>] lock_acquire+0x89/0xa0
       [<c1414d63>] mutex_lock_nested+0x41/0x23e
       [<fed7cfcc>] nilfs_cpfile_change_cpmode+0x46/0x752 [nilfs2]
       [<fed801b2>] nilfs_ioctl+0x11a/0x7da [nilfs2]
       [<c10cca12>] vfs_ioctl+0x27/0x6e
       [<c10ccf93>] do_vfs_ioctl+0x491/0x4db
       [<c10cd022>] sys_ioctl+0x45/0x5f
       [<c1002a14>] sysenter_do_call+0x12/0x32
Signed-off-by: default avatarRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      c1ea985c
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7