Re: Possible critical VIA vt82c686a chip bug (private question)

Vojtech Pavlik
2000-10-26T18:02:53Z

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.