Skip to content

L
linux-davinci-2.6.23
An error occurred fetching the project authors.
Switch branch/tag
  1. 06 Sep, 2005 3 commits
  3. 05 Sep, 2005 5 commits
  5. 03 Sep, 2005 8 commits
  7. 02 Sep, 2005 1 commit
  9. 01 Sep, 2005 1 commit
  11. 31 Aug, 2005 2 commits
  13. 30 Aug, 2005 1 commit
  15. 29 Aug, 2005 1 commit
  17. 28 Aug, 2005 1 commit
    • Paul Mackerras's avatar
      [PATCH] Remove race between con_open and con_close · f786648b
      Paul Mackerras authored 
      [ Same race and same patch also by Steven Rostedt <rostedt@goodmis.org> ]

I have a laptop (G3 powerbook) which will pretty reliably hit a race
between con_open and con_close late in the boot process and oops in
vt_ioctl due to tty->driver_data being NULL.

What happens is this: process A opens /dev/tty6; it comes into
con_open() (drivers/char/vt.c) and assign a non-NULL value to
tty->driver_data.  Then process A closes that and concurrently process
B opens /dev/tty6.  Process A gets through con_close() and clears
tty->driver_data, since tty->count == 1.  However, before process A
can decrement tty->count, we switch to process B (e.g. at the
down(&tty_sem) call at drivers/char/tty_io.c line 1626).

So process B gets to run and comes into con_open with tty->count == 2,
as tty->count is incremented (in init_dev) before con_open is called.
Because tty->count != 1, we don't set tty->driver_data.  Then when the
process tries to do anything with that fd, it oopses.

The simple and effective fix for this is to test tty->driver_data
rather than tty->count in con_open.  The testing and setting of
tty->driver_data is serialized with respect to the clearing of
tty->driver_data in con_close by the console_sem.  We can't get a
situation where con_open sees tty->driver_data != NULL and then
con_close on a different fd clears tty->driver_data, because
tty->count is incremented before con_open is called.  Thus this patch
eliminates the race, and in fact with this patch my laptop doesn't
oops.
Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
[ Same patch
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
  in http://marc.theaimsgroup.com/?l=linux-kernel&m=112450820432121&w=2 ]
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f786648b
  19. 24 Aug, 2005 3 commits
  21. 23 Aug, 2005 1 commit
    • Dave Airlie's avatar
      drm: fix a bad VERSION check. · 7a9aff3c
      Dave Airlie authored 
      I found why my G5 was crashing when using the linux-2.6 version of the
DRM + git-drm.patch from 2.6.13-rc6-mm1, but not with the CVS DRM.
The reason was that dev->agp->cant_use_aperture wasn't getting set,
and the reason for that was that <linux/version.h> no longer gets
included and the #if LINUX_VERSION_CODE < 0x020408 in drm_agpsupport.c
was going the wrong way.  With this patch (and a few others) a 32-bit
server works correctly, as does DRI.

From: Paul Mackerras <paulus@samba.org>
Signed-off-by: default avatarDave Airlie <airlied@linux.ie>
      7a9aff3c
  23. 20 Aug, 2005 2 commits
  25. 16 Aug, 2005 2 commits
  27. 15 Aug, 2005 1 commit
  29. 13 Aug, 2005 1 commit
    • Linus Torvalds's avatar
      Fix up mmap of /dev/kmem · 4bb82551
      Linus Torvalds authored 
      This leaves the issue of whether we should deprecate the whole thing (or
if we should check the whole mmap range, for that matter) open. Just do
the minimal fix for now.
      4bb82551
  31. 09 Aug, 2005 1 commit
  33. 07 Aug, 2005 2 commits
  35. 05 Aug, 2005 4 commits
    • Marcel Selhorst's avatar
      [PATCH] tpm_infineon: Support for new TPM 1.2 and PNPACPI · f9abb020
      Marcel Selhorst authored 
      This patch includes support for the new Infineon Trusted Platform Module
SLB 9635 TT 1.2 and does further include ACPI-support for both chip
versions (SLD 9630 TT 1.1 and SLB9635 TT 1.2).  Since the ioports and
configuration registers are not correctly set on some machines, the
configuration is now done via PNPACPI, which reads out the correct values
out of the DSDT-table.  Note that you have to have CONFIG_PNP,
CONFIG_ACPI_BUS and CONFIG_PNPACPI enabled to run this driver (assuming
that mainboards including a TPM do have the need for ACPI anyway).
Signed-off-by: default avatarMarcel Selhorst <selhorst@crypto.rub.de>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f9abb020
    • Petr Vandrovec's avatar
      [PATCH] rtc: msleep() cannot be used from interrupt · 403fe5ae
      Petr Vandrovec authored 
      Since the beginning of July my Opteron box was randomly crashing and
being rebooted by hardware watchdog.  Today it finally did it in front
of me, and this patch will hopefully fix it.

The problem is that at the end of June (the 28th, to be exact: commit
47f176fd, "[PATCH] Using msleep()
instead of HZ") rtc_get_rtc_time was converted to use msleep() instead
of busy waiting.  But rtc_get_rtc_time is used by hpet_rtc_interrupt,
and scheduling is not allowed during interrupt.  So I'm reverting this
part of original change, replacing msleep() back with busy loop.

The original code was busy waiting for up to 20ms, but on my hardware in
the worst case update-in-progress bit was asserted for at most 363
passes through loop (on 2GHz dual Opteron), much less than even one
jiffie, not even talking about 20ms.  So I changed code to just wait
only as long as necessary.  Otherwise when RTC was set to generate
8192Hz timer, it stopped doing anything for 20ms (160 pulses were
skipped!) from time to time, and this is rather suboptimal as far as I
can tell.
Signed-off-by: default avatarPetr Vandrovec <vandrove@vc.cvut.cz>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      403fe5ae
    • Dave Airlie's avatar
      drm: fix warning in drm_pci.c · aa0ca6b4
      Dave Airlie authored 
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
Signed-off-by: default avatarDave Airlie <airlied@linux.ie>
      aa0ca6b4
    • Dave Airlie's avatar
      drm: remove the gamma driver · 1fad9949
      Dave Airlie authored 
      The gamma driver has been broken for quite a while, it doesn't build,
we don't have a userspace, mine is in Ireland etc...
Signed-off-by: default avatarDave Airlie <airlied@linux.ie>
      1fad9949