1. 01 Oct, 2002 9 commits
    • Christoph Hellwig's avatar
      [PATCH] no more flush_workqueue in xfs · 05684a49
      Christoph Hellwig authored
      I see you just applied my patch to make destroy_workqueue do the
      flush.  Fix up XFS for it.
      05684a49
    • Christoph Hellwig's avatar
      [PATCH] workqueue flush on destroy · 5d8f0a43
      Christoph Hellwig authored
      5d8f0a43
    • Christoph Hellwig's avatar
      [PATCH] XFS updates for workqueues · fec6fe9c
      Christoph Hellwig authored
      fec6fe9c
    • Linus Torvalds's avatar
      Merge penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/workqueue · a57e7142
      Linus Torvalds authored
      into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux
      a57e7142
    • Christoph Hellwig's avatar
    • Christoph Hellwig's avatar
      XFS: temporarily switch to schedule_task for I/O completion · d8bfe051
      Christoph Hellwig authored
      This is a huge performance drop for SMP, but at least XFS is working
      again.  Expect a better solution soon.
      d8bfe051
    • Ingo Molnar's avatar
      [PATCH] Workqueue Abstraction · 6ed12ff8
      Ingo Molnar authored
      This is the next iteration of the workqueue abstraction.
      
      The framework includes:
      
       - per-CPU queueing support.
      
      on SMP there is a per-CPU worker thread (bound to its CPU) and per-CPU
      work queues - this feature is completely transparent to workqueue-users.
      keventd automatically uses this feature. XFS can now update to work-queues
      and have the same per-CPU performance as it had with its per-CPU worker
      threads.
      
       - delayed work submission
      
      there's a new queue_delayed_work(wq, work, delay) function and a new
      schedule_delayed_work(work, delay) function. The later one is used to
      correctly fix former tq_timer users. I've reverted those changes in 2.5.40
      that changed tq_timer uses to schedule_work() - eg. in the case of
      random.c or the tty flip queue it was definitely the wrong thing to do.
      
      delayed work means a timer embedded in struct work_struct.  I considered
      using split struct work_struct and delayed_work_struct types, but lots
      of code actively uses task-queues in both delayed and non-delayed mode,
      so i went for the more generic approach that allows both methods of work
      submission.  Delayed timers do not cause any other overhead in the
      normal submission path otherwise.
      
       - multithreaded run_workqueue() implementation
      
      the run_workqueue() function can now be called from multiple contexts, and
      a worker thread will only use up a single entryy - this property is used
      by the flushing code, and can potentially be used in the future to extend
      the number of per-CPU worker threads.
      
       - more reliable flushing
      
      there's now a 'pending work' counter, which is used to accurately detect
      when the last work-function has finished execution. It's also used to
      correctly flush against timed requests. I'm not convinced whether the old
      keventd implementation got this detail right.
      
       - i switched the arguments of the queueing function(s) per Jeff's
         suggestion, it's more straightforward this way.
      
      
      Driver fixes:
      
      i have converted almost every affected driver to the new framework. This
      cleaned up tons of code. I also fixed a number of drivers that were still
      using BHs (these drivers did not compile in 2.5.40).
      
      while this means lots of changes, it might ease the QA decision whether to
      put this patch into 2.5.
      
      The pach converts roughly 80% of all tqueue-using code to workqueues - and
      all the places that are not converted to workqueues yet are places that do
      not compile in vanilla 2.5.40 anyway, due to unrelated changes. I've
      converted a fair number of drivers that do not compile in 2.5.40, and i
      think i've managed to convert every driver that compiles under 2.5.40.
      6ed12ff8
    • Paul Mackerras's avatar
      [PATCH] pcmcia resource allocation fix · 45ecad2e
      Paul Mackerras authored
      The patch below is a forward-port from 2.4 of a fix that went in to
      the 2.4.x PCMCIA code some time back.  It makes sure that that we
      request I/O and memory regions from the correct resource (the parent
      of the PCMCIA bridge chip, for PCMCIA bridges connected to a PCI bus)
      rather than always requesting them from the top-level ioport_resource
      or iomem_resource.
      45ecad2e
    • Hugh Dickins's avatar
      [PATCH] Oracle startup split_vma fix · d036a4e7
      Hugh Dickins authored
      Alessandro Suardi and Zlatko Calusic independently reported that
      Oracle cannot start on recent 2.5: excellent research by Zlatko
      quickly pointed to vm_pgoff buglet in the new split_vma.
      d036a4e7
  2. 30 Sep, 2002 13 commits
    • Linus Torvalds's avatar
      Linux v2.5.40 · 7570df54
      Linus Torvalds authored
      7570df54
    • Linus Torvalds's avatar
      Merge http://linux-scsi.bkbits.net/scsi-for-linus-2.5 · 2b9fa51a
      Linus Torvalds authored
      into home.transmeta.com:/home/torvalds/v2.5/linux
      2b9fa51a
    • James Bottomley's avatar
      Merge mulgrave.(none):/home/jejb/BK/linux-2.5 · fd0a1c61
      James Bottomley authored
      into mulgrave.(none):/home/jejb/BK/scsi-for-linus-2.5
      fd0a1c61
    • Mike Anderson's avatar
      Error handler general clean up · 9b46c836
      Mike Anderson authored
      9b46c836
    • Rolf Fokkens's avatar
      [PATCH] sg.c and USER_HZ, kernel 2.5.37 · 8885e375
      Rolf Fokkens authored
      Hi!
      
      Since the introduction of USER_HZ the SG_[GS]ET_TIMEOUT ioctls may have
      a serious BUG as userspace uses a different HZ from the HZ in kernelspace.
      
      In x86 HZ=1000 and USER_HZ=100, resulting in confusing timouts as the
      kernel measures time 10 times as fast as userspace.
      
      This patch is an attempt to fix this by transforming USER_HZ based timing to
      HZ based timing before storing it in timeout. To make sure that SG_GET_TIMEOUT
      and SG_SET_TIMEOUT behave consistently a field timeout_user is added which
      stores the exact value that's passed by SG_SET_TIMEOUT and it's returned on
      SG_GET_TIMEOUT.
      
      Rolf Fokkens
      fokkensr@fokkensr.vertis.nl
      
      P.S. this is the second post of this patch
      8885e375
    • James Bottomley's avatar
      dfa944ae
    • Andrew Morton's avatar
      scsi_initialise_merge_fn() will only set highio if ->type == TYPE_DISK. · 2b562242
      Andrew Morton authored
      But it's called from scsi_add_lun()->scsi_alloc_sdev() before the type
      is known.  The type is -1 all the time in scsi_initialise_merge_fn()
      and scsi always bounces.
      
      This patch makes it do the right thing - just enable block-highmem for
      all scsi devices.
      
      Jens had this to say:
      
      "I guess that block-highmem has been around long enough, that I can
       use the term 'historically' at least in the kernel sense :-)
      
       This extra check was added for IDE because each device type driver
       (ide-disk, ide-cd, etc) needed to be updated to not assume virtual
       mappings of request data was valid.  I only did that for ide-disk,
       since this is the only one where bounce buffering really hurt
       performance wise.  So while ide-cd and ide-tape etc could have been
       updated, I deemed it uninteresting and not worthwhile.
      
       Now, this was just carried straight into the scsi counter parts,
       conveniently, because of laziness.  A quick glance at sr shows that it
       too can aviod bouncing easily (no changes needed).  st may need some
       changes, though.  So again, for scsi it was a matter of not impacting
       existing code in 2.4 too much.
      
       So TYPE_DISK check can be killed in 2.5 if someone does the work of
       checking that it is safe.  I'm not so sure it will make eg your SCSI
       CD-ROM that much faster :-)"
      
      2b562242
    • David Gibson's avatar
      [PATCH] Squash warning in fs/devfs/base.c · 5dd17103
      David Gibson authored
      This removes an unused label in fs/devfs/base.c
      5dd17103
    • Greg Kroah-Hartman's avatar
      Merge kroah.com:/home/greg/linux/BK/bleeding_edge-2.5 · 1a008d0e
      Greg Kroah-Hartman authored
      into kroah.com:/home/greg/linux/BK/gregkh-2.5
      1a008d0e
    • Randy Dunlap's avatar
      [PATCH] hc_sl811 build and memory leak · 5c1c6931
      Randy Dunlap authored
      It needs s/malloc.h/slab.h/ .
      It also forgets to free some memory on an error exit patch.
      Patch for 2.5.39 follows.
      5c1c6931
    • David Brownell's avatar
      [PATCH] usb_sg_{init,wait,cancel}() · 1e4fece8
      David Brownell authored
      Here are the scatterlist primitives there's been mail about before.
      Now the code has passed basic sanity testing, and is ready to merge
      into Linus' tree to start getting wider use.  Greg, please merge!
      
      To recap, the routines are a utility layer packaging several usb
      core facilities to improve system performance.  It's synchronous.
      The code uses functionality that drivers could use already, but
      generally haven't:
      
          - Request queueing.  This is a big performance win.  It lets
            device drivers help the hcds avoid wasted i/o bandwidth, by
            eliminating irq and scheduling latencies between requests.  It
            can make a huge difference at high speed, when the latencies
            often exceed the time to handle each i/o request!
      
          - The new usb_map_sg() primitives, leveraging IOMMU hardware
            if it's there (better than entry-at-a-time mapping).
      
          - URB_NO_INTERRUPT transfer flag, a hint to hcds that they
            can avoid a 'success irq' for this urb.  Only the urb for
            the last scatterlist entry really needs an IRQ, the others
            can be eliminated or delayed.  (OHCI uses this today, and
            any HCD can safely ignore it.)
      
      The particular functionality in these APIs seemed to meet Matt's
      requirements for usb-storage, so I'd hope the 2.5 usb-storage
      code will start to use these routines in a while.  (And maybe
      those two scanner drivers: hpusbscsi, microtek.)
      
      Brief summary of testing:  this code seems correct for normal
      reads and writes, but the fault paths (including cancelation)
      haven't been tested yet.  Both EHCI and OHCI seem to be mostly
      OK with these more aggressive queued loads, but may need small
      updates (like the two I sent yesterday).  Unfortunately I have
      to report that UHCI and urb queueing will sometimes lock up my
      hardware (PIIX4), so while we're lots better than 2.4 this is
      still a bit of a trouble spot for now.
      
      I'll be making some testing software available shortly, which
      will help track down remaining HCD level problems by giving the
      queuing APIs (and some others!) a more strenuous workout than
      most drivers will, in their day-to-day usage.
      
      - Dave
      1e4fece8
    • Matthew Dharm's avatar
      [PATCH] USB-storage: problem clearing halts · 2eea1938
      Matthew Dharm authored
      Greg, attached is a patch designed for diagnostic purposes.  Please apply
      to the 2.5 tree -- yes, we'll be removing this at some point in the future.
      
      It appears that we have a problem clearing halts.  This patch causes a very
      clear message to be printed whenever a usb_stor_clear_halt() manages to
      work.  So far, I haven't seen such a thing happen.  And I've seen _lots_ of
      STALL conditions.
      
      This problem has likely been around for a while... however, it hasn't been
      noticed before because usb-storage was difficult to use because of other
      bugs.  Heck, the most recent 'bk pull' is the first one for me in _months_
      which let me boot all the way into X11.
      
      I'm going to hold my patch queue until this is resolved.  On my test setup,
      it's easy to see this failing.  I've tried with 4 different devices, with
      both UHCI and EHCI drivers.  I don't want to confuse this problem with
      other patches...
      
      'result' in this function always seems to be -32.  Which is odd, because
      control endpoints shouldn't do that.
      
      I'm open to suggestions as to where to look for this bug, but my instincts
      are telling me that this is a core or HCD issue, not a usb-storage issue.
      
      On a positive note, this means that the error-recovery system gets a good
      workout.
      2eea1938
    • Linus Torvalds's avatar
      Merge bk://bk.arm.linux.org.uk · 2fbc109c
      Linus Torvalds authored
      into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux
      2fbc109c
  3. 01 Oct, 2002 4 commits
  4. 30 Sep, 2002 14 commits