Skip to content

L
linux
Switch branch/tag
  1. 26 Nov, 2004 4 commits
    • 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
  5. 24 Nov, 2004 9 commits
  7. 23 Nov, 2004 9 commits
  9. 22 Nov, 2004 3 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7