1. 21 6月, 2008 7 次提交
  2. 19 6月, 2008 33 次提交
    • J
      x86, geode: add a VSA2 ID for General Software · ffe6e1da
      Jordan Crouse 提交于
      General Software writes their own VSA2 module for their version
      of the Geode BIOS, which returns a different ID then the standard
      VSA2.  This was causing the framebuffer driver to break for most
      GSW boards.
      Signed-off-by: NJordan Crouse <jordan.crouse@amd.com>
      Cc: tglx@linutronix.de
      Cc: linux-geode@lists.infradead.org
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ffe6e1da
    • B
      sched, delay accounting: fix incorrect delay time when constantly waiting on runqueue · d4abc238
      Bharath Ravi 提交于
      This patch corrects the incorrect value of per process run-queue wait
      time reported by delay statistics. The anomaly was due to the following
      reason. When a process leaves the CPU and immediately starts waiting for
      CPU on the runqueue (which means it remains in the TASK_RUNNABLE state),
      the time of re-entry into the run-queue is never recorded. Due to this,
      the waiting time on the runqueue from this point of re-entry upto the
      next time it hits the CPU is not accounted for. This is solved by
      recording the time of re-entry of a process leaving the CPU in the
      sched_info_depart() function IF the process will go back to waiting on
      the run-queue. This IF condition is verified by checking whether the
      process is still in the TASK_RUNNABLE state.
      
      The patch was tested on 2.6.26-rc6 using two simple CPU hog programs.
      The values noted prior to the fix did not account for the time spent on
      the runqueue waiting. After the fix, the correct values were reported
      back to user space.
      Signed-off-by: NBharath Ravi <bharathravi1@gmail.com>
      Signed-off-by: NMadhava K R  <madhavakr@gmail.com>
      Cc: dhaval@linux.vnet.ibm.com
      Cc: vatsa@in.ibm.com
      Cc: balbir@in.ibm.com
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d4abc238
    • S
      Blackfin Serial Driver: Use timer to poll CTS PIN instead of workqueue. · f30ac0ce
      Sonic Zhang 提交于
      This allows other threads to run when the serial driver polls the CTS
      PIN in a loop.
      Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
      Signed-off-by: NBryan Wu <cooloney@kernel.org>
      f30ac0ce
    • S
      ec64b6c8
    • B
      x86: use BOOTMEM_EXCLUSIVE on 32-bit · d3942cff
      Bernhard Walle 提交于
      This patch uses the BOOTMEM_EXCLUSIVE for crashkernel reservation also for
      i386 and prints a error message on failure.
      
      The patch is still for 2.6.26 since it is only bug fixing. The unification
      of reserve_crashkernel() between i386 and x86_64 should be done for 2.6.27.
      Signed-off-by: NBernhard Walle <bwalle@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: <stable@kernel.org>
      d3942cff
    • M
      x86, 32-bit: fix boot failure on TSC-less processors · df17b1d9
      Mikael Pettersson 提交于
      Booting 2.6.26-rc6 on my 486 DX/4 fails with a "BUG: Int 6"
      (invalid opcode) and a kernel halt immediately after the
      kernel has been uncompressed. The BUG shows EIP pointing
      to an rdtsc instruction in native_read_tsc(), invoked from
      native_sched_clock().
      
      (This error occurs so early that not even the serial console
      can capture it.)
      
      A bisection showed that this bug first occurs in 2.6.26-rc3-git7,
      via commit 9ccc906c:
      
      >x86: distangle user disabled TSC from unstable
      >
      >tsc_enabled is set to 0 from the command line switch "notsc" and from
      >the mark_tsc_unstable code. Seperate those functionalities and replace
      >tsc_enable with tsc_disable. This makes also the native_sched_clock()
      >decision when to use TSC understandable.
      >
      >Preparatory patch to solve the sched_clock() issue on 32 bit.
      >
      >Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
      
      The core reason for this bug is that native_sched_clock() gets
      called before tsc_init().
      
      Before the commit above, tsc_32.c used a "tsc_enabled" variable
      which defaulted to 0 == disabled, and which only got enabled late
      in tsc_init(). Thus early calls to native_sched_clock() would skip
      the TSC and use jiffies instead.
      
      After the commit above, tsc_32.c uses a "tsc_disabled" variable
      which defaults to 0, meaning that the TSC is Ok to use. Early calls
      to native_sched_clock() now erroneously try to use the TSC on
      !cpu_has_tsc processors, leading to invalid opcode exceptions.
      
      My proposed fix is to initialise tsc_disabled to a "soft disabled"
      state distinct from the hard disabled state set up by the "notsc"
      kernel option. This fixes the native_sched_clock() problem. It also
      allows tsc_init() to be simplified: instead of setting tsc_disabled = 1
      on every error return, we just set tsc_disabled = 0 once when all
      checks have succeeded.
      
      I've verified that this lets my 486 boot again. I've also verified
      that a Core2 machine still uses the TSC as clocksource after the patch.
      Signed-off-by: NMikael Pettersson <mikpe@it.uu.se>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      df17b1d9
    • S
      x86: fix NULL pointer deref in __switch_to · 75118a82
      Suresh Siddha 提交于
      Patrick McHardy reported a crash:
      
      > > I get this oops once a day, its apparently triggered by something
      > > run by cron, but the process is a different one each time.
      > >
      > > Kernel is -git from yesterday shortly before the -rc6 release
      > > (last commit is the usb-2.6 merge, the x86 patches are missing),
      > > .config is attached.
      > >
      > > I'll retry with current -git, but the patches that have gone in
      > > since I last updated don't look related.
      > >
      > > [62060.043009] BUG: unable to handle kernel NULL pointer dereference at
      > > 000001ff
      > > [62060.043009] IP: [<c0102a9b>] __switch_to+0x2f/0x118
      > > [62060.043009] *pde = 00000000
      > > [62060.043009] Oops: 0002 [#1] PREEMPT
      
      Vegard Nossum analyzed it:
      
      > This decodes to
      >
      >    0:   0f ae 00                fxsave (%eax)
      >
      > so it's related to the floating-point context. This is the exact
      > location of the crash:
      >
      > $ addr2line -e arch/x86/kernel/process_32.o -i ab0
      > include/asm/i387.h:232
      > include/asm/i387.h:262
      > arch/x86/kernel/process_32.c:595
      >
      > ...so it looks like prev_task->thread.xstate->fxsave has become NULL.
      > Or maybe it never had any other value.
      
      Somehow (as described below) TS_USEDFPU is set but the fpu is not
      allocated or freed.
      
      Another possible FPU pre-emption issue with the sleazy FPU optimization
      which was benign before but not so anymore, with the dynamic FPU allocation
      patch.
      
      New task is getting exec'd and it is prempted at the below point.
      
      flush_thread() {
      	...
      	/*
      	* Forget coprocessor state..
      	*/
      	clear_fpu(tsk);
      		<----- Preemption point
      	clear_used_math();
      	...
      }
      
      Now when it context switches in again, as the used_math() is still set
      and fpu_counter can be > 5, we will do a math_state_restore() which sets
      the task's TS_USEDFPU. After it continues from the above preemption point
      it does clear_used_math() and much later free_thread_xstate().
      
      Now, at the next context switch, it is quite possible that xstate is
      null, used_math() is not set and TS_USEDFPU is still set. This will
      trigger unlazy_fpu() causing kernel oops.
      
      Fix this  by clearing tsk's fpu_counter before clearing task's fpu.
      Reported-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      75118a82
    • J
      x86: set PAE PHYSICAL_MASK_SHIFT to 44 bits. · ad524d46
      Jeremy Fitzhardinge 提交于
      When a 64-bit x86 processor runs in 32-bit PAE mode, a pte can
      potentially have the same number of physical address bits as the
      64-bit host ("Enhanced Legacy PAE Paging").  This means, in theory,
      we could have up to 52 bits of physical address in a pte.
      
      The 32-bit kernel uses a 32-bit unsigned long to represent a pfn.
      This means that it can only represent physical addresses up to 32+12=44
      bits wide.  Rather than widening pfns everywhere, just set 2^44 as the
      Linux x86_32-PAE architectural limit for physical address size.
      
      This is a bugfix for two cases:
      1. running a 32-bit PAE kernel on a machine with
        more than 64GB RAM.
      2. running a 32-bit PAE Xen guest on a host machine with
        more than 64GB RAM
      
      In both cases, a pte could need to have more than 36 bits of physical,
      and masking it to 36-bits will cause fairly severe havoc.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Jan Beulich <jbeulich@novell.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ad524d46
    • J
      softlockup: fix NMI hangs due to lock race - 2.6.26-rc regression · 9c106c11
      Jason Wessel 提交于
      The touch_nmi_watchdog() routine on x86 ultimately calls
      touch_softlockup_watchdog().  The problem is that to touch the
      softlockup watchdog, the cpu_clock code has to be called which could
      involve multiple cpu locks and can lead to a hard hang if one of the
      locks is held by a processor that is not going to return anytime soon
      (such as could be the case with kgdb or perhaps even with some other
      kind of exception).
      
      This patch causes the public version of the
      touch_softlockup_watchdog() to defer the cpu clock access to a later
      point.
      
      The test case for this problem is to use the following kernel config
      options:
      
      CONFIG_KGDB_TESTS=y
      CONFIG_KGDB_TESTS_ON_BOOT=y
      CONFIG_KGDB_TESTS_BOOT_STRING="V1F100I100000"
      
      It should be noted that kgdb test suite and these options were not
      available until 2.6.26-rc2, so it was necessary to patch the kgdb
      test suite during the bisection.
      
      I would consider this patch a regression fix because the problem first
      appeared in commit 27ec4407 when some
      logic was added to try to periodically sync the clocks.  It was
      possible to work around this particular problem by simply not
      performing the sync anytime the system was in a critical context.
      This was ok until commit 3e51f33f,
      which added config option CONFIG_HAVE_UNSTABLE_SCHED_CLOCK and some
      multi-cpu locks to sync the clocks.  It became clear that accessing
      this code from an nmi was the source of the lockups.  Avoiding the
      access to the low level clock code from an code inside the NMI
      processing also fixed the problem with the 27ec44... commit.
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9c106c11
    • S
      rcupreempt: remove export of rcu_batches_completed_bh · afd38009
      Steven Rostedt 提交于
      In rcupreempt, rcu_batches_completed_bh is defined as a static inline in
      the header file. This does not need to be exported, and not only that,
      this breaks my PPC build.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: paulus@samba.org
      Cc: linuxppc-dev@ozlabs.org
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      afd38009
    • L
      cpuset: limit the input of cpuset.sched_relax_domain_level · 30e0e178
      Li Zefan 提交于
      We allow the inputs to be [-1 ... SD_LV_MAX), and return -EINVAL
      for inputs outside this range.
      Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
      Acked-by: NPaul Menage <menage@google.com>
      Acked-by: NPaul Jackson <pj@sgi.com>
      Acked-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      30e0e178
    • I
      Merge branch 'linus' into sched/urgent · d819c49d
      Ingo Molnar 提交于
      d819c49d
    • M
      sched: CPU hotplug events must not destroy scheduler domains created by the cpusets · f18f982a
      Max Krasnyansky 提交于
      First issue is not related to the cpusets. We're simply leaking doms_cur.
      It's allocated in arch_init_sched_domains() which is called for every
      hotplug event. So we just keep reallocation doms_cur without freeing it.
      I introduced free_sched_domains() function that cleans things up.
      
      Second issue is that sched domains created by the cpusets are
      completely destroyed by the CPU hotplug events. For all CPU hotplug
      events scheduler attaches all CPUs to the NULL domain and then puts
      them all into the single domain thereby destroying domains created
      by the cpusets (partition_sched_domains).
      The solution is simple, when cpusets are enabled scheduler should not
      create default domain and instead let cpusets do that. Which is
      exactly what the patch does.
      Signed-off-by: NMax Krasnyansky <maxk@qualcomm.com>
      Cc: pj@sgi.com
      Cc: menage@google.com
      Cc: rostedt@goodmis.org
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      f18f982a
    • P
      sched: rt-group: fix RR buglet · 15a8641e
      Peter Zijlstra 提交于
      In tick_task_rt() we first call update_curr_rt() which can dequeue a runqueue
      due to it running out of runtime, and then we try to requeue it, of it also
      having exhausted its RR quota. Obviously requeueing something that is no longer
      on the runqueue will not have the expected result.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Tested-by: NDaniel K. <dk@uw.no>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      15a8641e
    • P
      sched: rt-group: heirarchy aware throttle · ad2a3f13
      Peter Zijlstra 提交于
      The bandwidth throttle code dequeues a group when it runs out of quota, and
      re-queues it once the period rolls over and the quota gets refreshed.
      
      Sadly it failed to take the hierarchy into consideration. Share more of the
      enqueue/dequeue code with regular task opterations.
      
      Also, some operations like sched_setscheduler() can dequeue/enqueue tasks that
      are in throttled runqueues, we should not inadvertly re-enqueue empty runqueues
      so check for that.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Tested-by: NDaniel K. <dk@uw.no>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ad2a3f13
    • P
      sched: rt-group: fix hierarchy · 7ea56616
      Peter Zijlstra 提交于
      Don't re-set the entity's runqueue to the wrong rq after we've set it
      to the right one.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Tested-by: NDaniel K. <dk@uw.no>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7ea56616
    • D
      sched: NULL pointer dereference while setting sched_rt_period_us · 49307fd6
      Dario Faggioli 提交于
      When CONFIG_RT_GROUP_SCHED and CONFIG_CGROUP_SCHED are enabled, with:
      
       echo 10000 > /proc/sys/kernel/sched_rt_period_us
      
      We get this:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000008c
       [  947.682233] IP: [<c0216b72>] __rt_schedulable+0x12/0x160
       [  947.683123] *pde = 00000000=20
       [  947.683782] Oops: 0000 [#1]
       [  947.684307] Modules linked in:
       [  947.684308]
       [  947.684308] Pid: 2359, comm: bash Not tainted (2.6.26-rc6 #8)
       [  947.684308] EIP: 0060:[<c0216b72>] EFLAGS: 00000246 CPU: 0
       [  947.684308] EIP is at __rt_schedulable+0x12/0x160
       [  947.684308] EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000001
       [  947.684308] ESI: c0521db4 EDI: 00000001 EBP: c6cc9f00 ESP: c6cc9ed0
       [  947.684308]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
       [  947.684308] Process bash (pid: 2359, tiÆcc8000 taskÇa54f00=20 task.tiÆcc8000)
       [  947.684308] Stack: c0222790 00000000 080f8c08 c0521db4 c6cc9f00 00000001 00000000 00000000
       [  947.684308]        c6cc9f9c 00000000 c0521db4 00000001 c6cc9f28 c0216d40 00000000 00000000
       [  947.684308]        c6cc9f9c 000f4240 000e7ef0 ffffffff c0521db4 c79dfb60 c6cc9f58 c02af2cc
       [  947.684308] Call Trace:
       [  947.684308]  [<c0222790>] ? do_proc_dointvec_conv+0x0/0x50
       [  947.684308]  [<c0216d40>] ? sched_rt_handler+0x80/0x110
       [  947.684308]  [<c02af2cc>] ? proc_sys_call_handler+0x9c/0xb0
       [  947.684308]  [<c02af2fa>] ? proc_sys_write+0x1a/0x20
       [  947.684308]  [<c0273c36>] ? vfs_write+0x96/0x160
       [  947.684308]  [<c02af2e0>] ? proc_sys_write+0x0/0x20
       [  947.684308]  [<c027423d>] ? sys_write+0x3d/0x70
       [  947.684308]  [<c0202ef5>] ? sysenter_past_esp+0x6a/0x91
       [  947.684308]  =======================
       [  947.684308] Code: 24 04 e8 62 b1 0e 00 89 c7 89 f8 8b 5d f4 8b 75
       f8 8b 7d fc 89 ec 5d c3 90 55 89 e5 57 56 53 83 ec 24 89 45 ec 89 55 e4
       89 4d e8 <8b> b8 8c 00 00 00 85 ff 0f 84 c9 00 00 00 8b 57 24 39 55 e8
       8b
       [  947.684308] EIP: [<c0216b72>] __rt_schedulable+0x12/0x160 SS:ESP  0068:c6cc9ed0
      
      We think the following patch solves the issue.
      Signed-off-by: NDario Faggioli <raistlin@linux.it>
      Signed-off-by: NMichael Trimarchi <trimarchimichael@yahoo.it>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      49307fd6
    • D
      agp: brown paper bag patch - put back two lines that got lost · 9bedbcb2
      Dave Airlie 提交于
      Commit 62c96b9d ("agp/intel: cleanup
      some serious whitespace badness") didn't just fix whitespace.  It also
      lost two lines.
      
      Noticed by Linus. No more whitespace diffs for me.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9bedbcb2
    • L
      Merge branch 'agp-patches' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/agp-2.6 · 3506ba7b
      Linus Torvalds 提交于
      * 'agp-patches' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/agp-2.6:
        agp/intel: cleanup some serious whitespace badness
        [AGP] intel_agp: Add support for Intel 4 series chipsets
        [AGP] intel_agp: extra stolen mem size available for IGD_GM chipset
        agp: more boolean conversions.
        drivers/char/agp - use bool
        agp: two-stage page destruction issue
        agp/via: fixup pci ids
      3506ba7b
    • D
      agp/intel: cleanup some serious whitespace badness · 62c96b9d
      Dave Airlie 提交于
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      62c96b9d
    • Z
      25ce77ab
    • Z
      [AGP] intel_agp: extra stolen mem size available for IGD_GM chipset · 598d1448
      Zhenyu Wang 提交于
      This adds missing stolen memory size detect for IGD_GM, be sure to
      detect right size as current X intel driver (2.3.2) which has already
      worked out.
      Signed-off-by: NZhenyu Wang <zhenyu.z.wang@intel.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      598d1448
    • T
      ahci: sis can't do PMP · 9a3b103c
      Tejun Heo 提交于
      From: Piter PUNK <piterpunk@slackware.com>
      
      SiS AHCIs say they can do PMP but can't and fail detection if SRST w/
      pmp==15 is used.  Turn off PMP support.
      
      tj: added patch description, adapted patch to #upstream-fixes and
          renamed board_ahci_sis to board_ahci_nopmp.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      9a3b103c
    • D
      agp: more boolean conversions. · 9516b030
      Dave Airlie 提交于
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      9516b030
    • T
      ata_piix: add TECRA M4 to broken suspend list · 040dee53
      Tejun Heo 提交于
      TOSHIBA also used "TECRA M4" in additon to "Tecra M4", add it.
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      040dee53
    • B
      LIBATA: Add HAVE_PATA_PLATFORM to select PATA_PLATFORM driver · cc18e0fe
      Ben Dooks 提交于
      Add HAVE_PATA_PLATFORM to select the pata platform driver
      to ensure that we do not end up with a long 'depends on' list
      when other users of this driver turn up.
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      cc18e0fe
    • M
      sata_mv: warn on PIO with multiple DRQs · c6112bd8
      Mark Lord 提交于
      Chip errata sometimes prevents reliable use of PIO commands which involve
      more than a single DRQ (data request).  In normal operation, libata should
      not generate such PIO commands (uses DMA instead), but they could be sent
      in via SG_IO from userspace.
      
      A full workaround might be to break up such commands into sequences
      of single DRQ ones, but that's just way too complex for something
      that doesn't normally happen in real life.
      
      So, allow the attempt (it often works, despite the errata),
      but log the event for reference when somebody screams.
      Signed-off-by: NMark Lord <mlord@pobox.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      c6112bd8
    • M
      sata_mv: enable async_notify for 60x1 Rev.C0 and higher · 3bd0a70e
      Mark Lord 提交于
      The early chipsets cannot safely handle Async Notification (AN),
      but 6041/6081 chip revision "C0" (and newer) can handle it.
      
      So allow AN for "C0" and higher.
      
      This enables use of hotplug on PMP ports for the 6041/6081 PCI Rev.9 chips.
      Signed-off-by: NMark Lord <mlord@pobox.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      3bd0a70e
    • T
      libata: don't check whether to use DMA or not for no data commands · 5895ef9a
      Tejun Heo 提交于
      There's no reason to check whether to use DMA or not for no data
      commands.  Don't do it.  While at it, make local variable using_pio in
      atapi_xlat() set iff ATAPI_PROT_PIO is going to be used and rename
      ata_check_atapi_dma() to atapi_check_dma() for consistency.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      5895ef9a
    • T
      ahci: jmb361 has only one port · d799e083
      Tejun Heo 提交于
      JMB361 has only one port but reports it has two causing longish probe
      failure on the second one.  Quirk it.
      
      Reported by Gajo Petrovic in bz 10911.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Gajo Petrovic <gajo01@gmail.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      d799e083
    • J
      drivers/char/agp - use bool · c7258012
      Joe Perches 提交于
      Use boolean in AGP instead of having own TRUE/FALSE
      
      --
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      c7258012
    • J
      agp: two-stage page destruction issue · da503fa6
      Jan Beulich 提交于
      besides it apparently being useful only in 2.6.24 (the changes in 2.6.25
      really mean that it could be converted back to a single-stage mechanism),
      I'm seeing an issue in Xen Dom0 kernels, which is caused by the calling
      of gart_to_virt() in the second stage invocations of the destroy function.
      I think that besides this being a real issue with Xen (where
      unmap_page_from_agp() is not just a page table attribute change), this
      also is invalid from a theoretical perspective: One should not assume that
      gart_to_virt() is still valid after unmapping a page. So minimally (keeping
      the 2-stage mechanism) a patch like the one below would be needed.
      
      Jan
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      da503fa6
    • G
      agp/via: fixup pci ids · dcd981a7
      Greg KH 提交于
      add a new PCI ID and remove an old dodgy one, include the explaination
      in the commented code so nobody readds later.
      
      (davej also sent the pci id addition).
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      dcd981a7