[IMSTT FBDEV] Fixed a bug that caused the hardware to lock up when scrolling.

into kozmo.(none):/usr/src/fbdev-2.5

into maxwell.earthlink.net:/usr/src/fbdev-2.5

into kozmo.(none):/usr/src/fbdev-2.5

Noted by David Mosberger:

 "If someone happens to arm a periodic timer at exactly 256 jiffies (as
  ohci happens to do on platforms with HZ=1024), then you end up getting
  an endless loop of timer activations, causing a machine hang.

  The problem is that __run_timers updates base->timer_jiffies _before_
  running the callback routines.  If a callback re-arms the timer at
  exactly 256 jiffies, add_timers() will reinsert the timer into the list
  that we're currently processing, which of course will cause the timer to
  expire immediately again, etc., etc., ad naseum... "

The answer here is to move the whole expired list to a local header and
to not look back.

- Convert nodemgr to new driver model.
- Convert to new module_param() calls.
- Merged fixes for devfs mkdir and some sleep-in-atomic fixes from
  mainline 2.5-bk
- Fix possible memory corruption on highlevel local read/write.
- Fix bitmap usage for some bitops.
- Fix bug in closing ISO stream.
- Fixes for nodemgr probing in the event of a reset storm.
- Workaround for nForce2 firewire chipset. This is preliminary.
- Conversion of SBP-2 to use new driver model in nodemgr, including
  providing a driver for firewire unit directories and registering
  proper callbacks.

into home.transmeta.com:/home/torvalds/v2.5/linux

into kroah.com:/home/greg/linux/BK/gregkh-2.5

into kroah.com:/home/greg/linux/BK/i2c-2.5

the driver should not mess with configurations here.

there's no reason this driver should mess with configurations.

Found by Rik van Riel:

 "There's a serious bug in the handling of the pointer returned
  by kmap_atomic() in nfs/dir.c.   The pointer (part of desc) is
  passed into find_dirent_name and from there into dir_decode,
  which modifies the pointer.

  That means you end up passing a wrong address to kunmap_atomic()."

into kozmo.(none):/usr/src/fbdev-2.5

into home.transmeta.com:/home/torvalds/v2.5/linux

into home.transmeta.com:/home/torvalds/v2.5/linux

into maxwell.earthlink.net:/usr/src/fbdev-2.5

into kernel.bkbits.net:/home/davem/net-2.5

into nuts.ninka.net:/home/davem/src/BK/net-2.5

into kozmo.(none):/usr/src/fbdev-2.5

into home.transmeta.com:/home/torvalds/v2.5/linux

If we build >1 DRM driver into the kernel, we get this lovely output..

[drm] Initialized tdfx 1.0.0 20010216 on minor 0
[drm] AGP 0.100 aperture @ 0xe0000000 64MB
[drm] Initialized r128 2.3.0 20021029 on minor 1
[drm] AGP 0.100 aperture @ 0xe0000000 64MB
[drm] Initialized radeon 1.8.0 20020828 on minor 2
[drm] AGP 0.100 aperture @ 0xe0000000 64MB
[drm] Initialized mga 3.1.0 20021029 on minor 3
[drm] AGP 0.100 aperture @ 0xe0000000 64MB
[drm] Initialized i810 1.2.1 20020211 on minor 4
[drm] AGP 0.100 aperture @ 0xe0000000 64MB
[drm] Initialized i830 1.3.2 20021108 on minor 5

agpgart already outputs the info about the aperture address & size
before drm initialises, so its just repetition for no purpose.

Spotted by Andi Kleen. AMD64 is the architecture, not the CPU.