1. 10 6月, 2005 5 次提交
    • D
      [PATCH] remove bogus hack from radeon IRQ handler · 74e8ebc5
      Dave Airlie 提交于
      This removes a bogus hack from the radeon IRQ handler.
      There is a better fix from myself and benh in DRM CVS but I'll wait
      until 2.6.13-rc so it gets more testing.
      Signed-off-by: NDave Airlie <airlied@linux.ie>
      74e8ebc5
    • D
      [PATCH] drm add i945G pci id · e98ded32
      Dave Airlie 提交于
      Add pci identifier for i945G chipset
      Signed-off-by: NDave Airlie <airlied@linux.ie>
      e98ded32
    • B
      [PATCH] ppc32: Fix nasty sleep/wakeup problem · 0086b5ec
      Benjamin Herrenschmidt 提交于
      Despite all the care lately in making the powermac sleep/wakeup as
      robust as possible, there is still a nasty related to the use of cpufreq
      on PMU based machines.  Unfortunately, it affects paulus old powerbook
      so I have to fix it :)
      
      We didn't manage to understand what is precisely going on, it leads to
      memory corruption and might have to do with RAM not beeing properly
      refreshed when a cpufreq transition is done right before the sleep.
      
      The best workaround (and less intrusive at this point) we could come up
      with is included in this patch.  We basically do _not_ force a switch to
      high speed on suspend anymore (that is what is causing the problem) on
      those machines.  We still force a speed switch on wakeup (since we don't
      know what speed we are coming back from sleep at, and that seems to work
      fine).
      
      Since, during this short interval, the actual CPU speed might be
      incorrect, we also hack around by multiplying loops_per_jiffy by 2 (max
      speed factor on those machines) during early wakeup stage to make sure
      udelay's during that time aren't too short.
      
      For after 2.6.12, we'll change udelay implementation to use the CPU
      timebase (which is always constant) instead like we do on ppc64 and thus
      get rid of all those problems.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0086b5ec
    • M
      [PATCH] iseries_veth: Supress spurious WARN_ON() at module unload · 243cd55e
      Michael Ellerman 提交于
      My patch from a few weeks back (now in mainline), called "Cleanup skbs to
      prevent unregister_netdevice() hanging", can cause our TX timeout code to
      fire on machines with lots of VLANs (because it takes > 2 seconds between
      when we stop the queues and when we're finished stopping the connections).
      
      When that happens the TX timeout code freaks out and does a WARN_ON()
      because as far as it's concerned there shouldn't be a TX timeout happening,
      which is fair enough.
      
      I have a "proper" fix for this, which is to a) do refcounting on
      connections and b) implement a proper ack timer so we don't keep unacked
      skbs lying around for ever.  But for 2.6.12 I propose just supressing the
      WARN_ON().  Users will still see the "NETDEV WATCHDOG" warning, but that's
      not nearly as bad as a WARN_ON() which users interpret as an Oops.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      243cd55e
    • N
      [PATCH] PCI: MSI functionality broken on Serverworks GC chipset · 1e062767
      Narendra Sankar 提交于
      MSI functionality is broken on the GC_LE x86 chipset that Serverworks
      developed and that is being used in various platforms today. Broadcom is
      going to push out to the kernel MSI enabled Gigabit drivers (in the very
      near future), and we would like to make sure that MSI does not get
      enabled on any platforms using the GC_LE chipset (device id 0x17).
      Following the AMD 8131 example, I am including a patch to disable MSI
      functionality when a GCNB_LE is detected. Please let me know if there
      are any issues with this. This is a permanent fix for this chipset, as
      the hardware will not be updated.
      Signed-off-by: NNarendra Sankar <nsankar@broadcom.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1e062767
  2. 09 6月, 2005 9 次提交
  3. 08 6月, 2005 6 次提交
  4. 07 6月, 2005 5 次提交
  5. 05 6月, 2005 1 次提交
  6. 03 6月, 2005 14 次提交