1. 27 Nov, 2004 2 commits
  2. 26 Nov, 2004 12 commits
    • Linus Torvalds's avatar
      Merge bk://bk.arm.linux.org.uk/linux-2.6-rmk · 38838b73
      Linus Torvalds authored
      into ppc970.osdl.org:/home/torvalds/v2.6/linux
      38838b73
    • Peter Chubb's avatar
      [ARM PATCH] 2269/2: Updated Pleb-1 support patch for Linux 2.6 · a304bd27
      Peter Chubb authored
      Patch from Peter Chubb
      
      This patch REPLACES patch #2269/1
      
      Instead of using the almost-obsolete SMC9194 driver, use the new
      SMC91xx driver.
      
      Signed-off-by: Peter Chubb
      Signed-off-by: Russell King
      a304bd27
    • Ben Dooks's avatar
      [ARM PATCH] 2273/1: S3C2410 - timex.h CLOCK_TICK_RATE fix · 3b17edb6
      Ben Dooks authored
      Patch from Ben Dooks
      
      CLOCK_TICK_RATE is 12MHz on at least 2 s3c2410 based
      machines, or close to it. Although this doesn't seem
      to have any effect on loops_per_jiffie, it is best
      to try and be accurate.
      
      Signed-off-by: Ben Dooks
      Signed-off-by: Russell King
      3b17edb6
    • Deepak Saxena's avatar
      [ARM PATCH] 2261/1: Cleanup use of ixp_reg_write in arch/arm/mach-ixp2000 · 963423ad
      Deepak Saxena authored
      Patch from Lennert Buytenhek
        
      Several files in this directory directly dereference pointers
      to on-chip I/O instead of using ixp_reg_write, making them
      susceptible to IXP2400 erratum #66. This changset fixes those.
      We do not touch any files that will only be built for IXP2800
      systems as the 2800 does not have this issue.
        
      
      Signed-off-by: Lennert Buytenhek
      Signed-off-by: Deepak Saxena
      Signed-off-by: Russell King
      963423ad
    • Deepak Saxena's avatar
      [ARM PATCH] 2260/1: Rename IXP2000_IRQ_SWI to reduce user confusion · 0364f754
      Deepak Saxena authored
      Patch from Lennert Buytenhek
      
      IXP2000 interrupt source zero is a software-generated interrupt source,
      but it is not an SWI in the ARM sense of the word.  Rename the interrupt
      source to reduce any confusion.
        
      
      Signed-off-by: Lennert Buytenhek
      Signed-off-by: Deepak Saxena
      Signed-off-by: Russell King
      0364f754
    • Deepak Saxena's avatar
      [ARM PATCH] 2259/1: Rip out ixp2000 IRQ_ERR_STATUS demultiplexing · ac1e7b88
      Deepak Saxena authored
      Patch from Lennert Buytenhek
        
      There are thirteen different IRQs chained off IRQ_ERR_STATUS, one for
      each possible error class that the IXP can signal an interrupt for, but
      there are no in-tree users of these interrupts, and it doesn't make much
      sense to treat them as separate interrupts if we can just have one
      handler checking each of the thirteen errors in one go instead.
        
      Besides that, the error interrupt handling can't even have been working
      properly in the first place as the chained handler was testing the wrong
      bits in the IRQ_ERR_STATUS register.
        
      So this patch rips it all out.
        
      
      Signed-off-by: Lennert Buytenhek
      Signed-off-by: Deepak Saxena
      Signed-off-by: Russell King
      ac1e7b88
    • Deepak Saxena's avatar
      [ARM PATCH] 2257/1: Add I2C device to IXDP2x01 platforms · 9ddd6ad2
      Deepak Saxena authored
      Patch from Deepak Saxena
      
      Signed-off-by: Deepak Saxena
      Signed-off-by: Russell King
      9ddd6ad2
    • Deepak Saxena's avatar
      [ARM PATCH] 2255/1: Add IXDPG425 platform support · 68f1bfbb
      Deepak Saxena authored
      Patch from Deepak Saxena
      
      New IXP425 based platform from Intel. This machine is similar to
      an ADI Coyote except for the addition of an on-board NEC ECHI
      controller. Patch also fixes issue with board setup for Coyote
      (and IXDPG425) that would cause the MTD driver to fail.
      
      Signed-off-by: Deepak Saxena
      Signed-off-by: Russell King
      68f1bfbb
    • Ingo Molnar's avatar
      [PATCH] floppy boot-time detection fix · 53373504
      Ingo Molnar authored
      When the FDC hardware is initialized, it sometimes generates a floppy
      interrupt right away - without being told to.  This interrupt can hit
      the detection code that executes right after the initialization code, in
      particular it can get intermixed with user_reset_fdc() that the
      detection code uses.  The fd driver is fundamentally single-threaded
      when it comes to handling events: an unexpected irq that arrives in the
      wrong moment can confuse the reset_fdc() code, which, with softirq and
      hardirq threading on, executes in keventd.
      
      In the stock kernel this stale irq doesnt seem to hit the detection code
      in the wrong moment, but i think under certain circumstances it may
      still happen.  One of the typical incarnations of the race was the
      following message:
      
       reset set in interrupt, calling c0258400
      
      and googling for "reset set in interrupt, calling" does turn up a fair
      number of bootlogs (most of them 2.4 ones) that show such a detection
      failure, so i think upstream wants to have the fix too.
      
      the fix is simple: delay a bit after initialization, to make sure the
      stale irq does not interfere with the detection code. It will be safely
      ignored, since do_floppy is still NULL. It might look sloppy that i went
      for a delay, but delay i think it is better than waiting for the irq to
      occur, because i dont think there's a guarantee that fdc initialization
      triggers an interrupt, so waiting for it could hang the boot process. A
      delay OTOH is totally harmless.
      
      The attached patch implements this fix, which resolves the detection
      problem on my testbox.
      
      here's again how a failure looks like:
      
       Floppy drive(s): fd0 is 1.44M
       reset set in interrupt, calling c0258400
       floppy0: no floppy controllers found
      
      and this is how it works with the fix:
      
       Floppy drive(s): fd0 is 1.44M
       FDC 0 is a post-1991 82077
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      53373504
    • Jens Axboe's avatar
      [PATCH] bio: fix leak in failure case in bio_copy_user() · d0b7fcbf
      Jens Axboe authored
      There's a leak in the error case in bio_copy_user().  If we fail
      allocating a page or adding a page to the bio, we will leak the bio map
      data. 
      Signed-off-by: default avatarJens Axboe <axboe@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      d0b7fcbf
    • Jens Axboe's avatar
      [PATCH] cfq-iosched: fix allocation increment race #3 · 8c86608b
      Jens Axboe authored
      There is a stupid error in cfq-iosched that spews a warning on
      (typically) SMP systems because cfqq->allocated[rw] goes below zero. The
      error is that the increment on alloc happens outside of the queue lock.
      Signed-off-by: default avatarJens Axboe <axboe@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      8c86608b
    • Paul Mackerras's avatar
      [PATCH] ppc64: fix hang on legacy iSeries · 5bc58b21
      Paul Mackerras authored
      Recently we have uncovered a bug in the kernel exception exit path
      which can cause iSeries machines to hang with interrupts disabled,
      typically when unloading a module.  This patch fixes the bug and
      should go in 2.6.10.  Here is the detailed explanation:
      
      There are a couple of places in the exception exit path in entry.S
      where we disable interrupts and then later reenable them.  We
      hard-disable interrupts even on legacy iSeries (rather than
      soft-disabling them) because the final part of the exception exit path
      needs interrupts hard-disabled (even on legacy iSeries), because
      otherwise an incoming interrupt could trash SRR0 and SRR1 and cause us
      to lose state.
      
      The intention was that each path that hard-disabled interrupts would
      hard-enable them again, either explicitly or by executing an rfid
      instruction (return from interrupt, doubleword).  However there was
      one path where we didn't correctly hard-enable interrupts.  This meant
      we could end up calling schedule() with interrupts hard-disabled and
      then switch to the stopmachine thread (used in removing a module),
      which spins polling a variable until another cpu changes it.  Since
      local_irq_enable() etc. on legacy iSeries only soft-enable interrupts,
      we got into the stopmachine thread with interrupts hard-disabled, and
      the machine hung at that point.
      
      This patch fixes it by making sure that when we go to re-enable
      interrupts, the MSR value we are loading up actually does have the
      MSR.EE (external interrupt enable) bit set.  Stephen Rothwell has
      verified that this actually does fix the bug on iSeries.  The bug
      also potentially exists on pSeries (and this patch fixes it), but
      there it doesn't really matter, because schedule() will enable
      interrupts (and on pSeries that means hard-enabling them), and because
      the hypervisor doesn't mind you having interrupts hard-disabled for
      extended periods on pSeries.  Note that all these comments about
      pSeries also apply to POWER5 iSeries (i5) machines.
      
      While I was there I noticed that we were jumping to ret_from_except
      after calling do_IRQ on iSeries, rather than ret_from_except_lite,
      meaning that we will restore registers 14-31 twice, unnecessarily.  I
      changed it to jump to ret_from_except_lite instead, and Stephen
      checked that this change doesn't cause any breakage.
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      5bc58b21
  3. 25 Nov, 2004 15 commits
  4. 24 Nov, 2004 9 commits
  5. 23 Nov, 2004 2 commits