Skip to content

L
linux
Switch branch/tag
  1. 05 Feb, 2009 1 commit
    • Pavel Emelyanov's avatar
      x86: fix hpet timer reinit for x86_64 · a6a95406
      Pavel Emelyanov authored 
      There's a small problem with hpet_rtc_reinit function - it checks
for the:

	hpet_readl(HPET_COUNTER) - hpet_t1_cmp > 0

to continue increasing both the HPET_T1_CMP (register) and the
hpet_t1_cmp (variable).

But since the HPET_COUNTER is always 32-bit, if the hpet_t1_cmp
is 64-bit this condition will always be FALSE once the latter hits
the 32-bit boundary, and we can have a situation, when we don't
increase the HPET_T1_CMP register high enough.

The result - timer stops ticking, since HPET_T1_CMP becomes less,
than the COUNTER and never increased again.

The solution is (based on Linus's suggestion) to not compare 64-bits
(on 64-bit x86), but to do the comparison on 32-bit signed
integers.
Reported-by: default avatarKirill Korotaev <dev@openvz.org>
Signed-off-by: default avatarPavel Emelyanov <xemul@openvz.org>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      a6a95406
  3. 03 Feb, 2009 11 commits
  5. 02 Feb, 2009 23 commits
  7. 01 Feb, 2009 5 commits
    • Linus Torvalds's avatar
      Manually revert "mlock: downgrade mmap sem while populating mlocked regions" · 27421e21
      Linus Torvalds authored 
      This essentially reverts commit 8edb08ca.

It downgraded our mmap semaphore to a read-lock while mlocking pages, in
order to allow other threads (and external accesses like "ps" et al) to
walk the vma lists and take page faults etc.  Which is a nice idea, but
the implementation does not work.

Because we cannot upgrade the lock back to a write lock without
releasing the mmap semaphore, the code had to release the lock entirely
and then re-take it as a writelock.  However, that meant that the caller
possibly lost the vma chain that it was following, since now another
thread could come in and mmap/munmap the range.

The code tried to work around that by just looking up the vma again and
erroring out if that happened, but quite frankly, that was just a buggy
hack that doesn't actually protect against anything (the other thread
could just have replaced the vma with another one instead of totally
unmapping it).

The only way to downgrade to a read map _reliably_ is to do it at the
end, which is likely the right thing to do: do all the 'vma' operations
with the write-lock held, then downgrade to a read after completing them
all, and then do the "populate the newly mlocked regions" while holding
just the read lock.  And then just drop the read-lock and return to user
space.

The (perhaps somewhat simpler) alternative is to just make all the
callers of mlock_vma_pages_range() know that the mmap lock got dropped,
and just re-grab the mmap semaphore if it needs to mlock more than one
vma region.

So we can do this "downgrade mmap sem while populating mlocked regions"
thing right, but the way it was done here was absolutely not correct.
Thus the revert, in the expectation that we will do it all correctly
some day.

Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: stable@kernel.org
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      27421e21
    • Devin Heitmueller's avatar
      V4L/DVB (10411): s5h1409: Perform s5h1409 soft reset after tuning · 67e70baf
      Devin Heitmueller authored 
      Just like with the s5h1411, the s5h1409 needs a soft-reset in order for it
to know that the tuner has been told to change frequencies.  This change
changes the behavior from "random tuning times between 500ms to complete
tuning lock failures" to "tuning lock consistently within 700ms".

Thanks to Robert Krakora <rob.krakora@messagenetsystems.com> for doing
initial testing of the patch on the KWorld 330U.

Thanks to Andy Walls <awalls@radix.net> for doing testing of the patch on
the HVR-1600.

Thanks to Michael Krufky <mkrufky@linuxtv.org> for doing additional testing.
Signed-off-by: default avatarDevin Heitmueller <dheitmueller@linuxtv.org>
Signed-off-by: default avatarMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      67e70baf
    • Mauro Carvalho Chehab's avatar
      V4L/DVB (10403): saa7134-alsa: saa7130 doesn't support digital audio · 40c41c8c
      Mauro Carvalho Chehab authored 
      According with saa7130 public datasheet, saa7130 doesn't support
digital audio. This is also confirmed by experimental tests. So, it
doesn't make sense to let saa7134-alsa register for those chipsets.
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      40c41c8c
    • Rusty Russell's avatar
      sched_rt: don't use first_cpu on cpumask created with cpumask_and · 3d398703
      Rusty Russell authored 
      cpumask_and() only initializes nr_cpu_ids bits, so the (deprecated)
first_cpu() might find one of those uninitialized bits if nr_cpu_ids
is less than NR_CPUS (as it can be for CONFIG_CPUMASK_OFFSTACK).
Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      3d398703
    • Peter Zijlstra's avatar
      sched: fix buddie group latency · a571bbea
      Peter Zijlstra authored 
      Similar to the previous patch, by not clearing buddies we can select entities
past their run quota, which can increase latency. This means we have to clear
group buddies as well.

Do not use the group clear for pick_next_task(), otherwise that'll get O(n^2).
Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      a571bbea
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7