On Thu, Oct 26, 2000 at 01:42:29PM -0400, Richard B. Johnson wrote:
> > > ../drivers/block/ide.c, line 162, on version 2.2.17 does bad things
> > > to the timer. It writes 0 to the control-word for timer 0. This
> > > does the following:
> [Snipped...]
> >
> > Well, at least on 2.4.0-test9, the above timing code is #ifed to
> > DISK_RECOVERY_TIME > 0, which in turn is #defined to 0 in
> > include/linux/ide.h.
> >
> > So this is not our problem here. Anyway I guess it's time to hunt for
> > i8259 accesses in the kernel that lack the necessary spinlock, even when
> > they're not probably the cause of the problem we see here.
>
> Okay, good.
Ok, here is a list of places within the kernel that access the PIT
timer, plus the method of locking (i386 arch only):
Usage: Lock method:
arch/i386/kernel/time.c:170: spin_lock()
arch/i386/kernel/time.c:491: spin_lock()
arch/i386/kernel/time.c:575: none (init)
arch/i386/kernel/i8259.c:491: none (init)
arch/i386/kernel/apm.c:871: cli()
arch/i386/kernel/apic.c:398: spin_lock_irqsave()
drivers/char/vt.c:121: cli()
drivers/char/ftape/lowlevel/ftape-calibr.c:80: cli()
drivers/char/ftape/lowlevel/ftape-calibr.c:99: cli()
drivers/char/joystick/analog.c:142: cli() __cli()
drivers/char/joystick/gameport.c:66: cli()
drivers/ide/hd.c:137: cli()
drivers/ide/ide.c:206: __cli()
I guess we'll need to fix this. While races here are not likely (the
most likely is a beep by vt.c at a wrong moment), they're possible.
However, these don't seem to be the cause of the problem we see here
anyway.
-- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:19 EST