Hi, Todd;
"Todd L. Miller" wrote:
>
> > I think I made a mistake in failing to recognize a fairly nasty (and
> > pretty obvious in hindsight) interrupt-related hazard in the interrupt
> > notification schema. In order to fix it, I'd like to muck about the
> > scheduler::notifyOfInterrupts and other related routines.
>
> Would this be the 'why aren't using InterruptHandler' problem?
No. Not only that, I spoke too soon. I actually *did* put the critical
sections in -- only I put them in the accessor/mutator methods. Whoops.
Having said that, you do bring up another problem. Sorry, but I have
not been able to devote much time recently, beyond a problem I'm chasing
down.
Please, anybody out there please feel free to let me know if you've seen
this failure mode... When I run the VGA driver, it hangs after writing
the blue test pixels over about 3/4 of the screen. After about another
minute of no activity, the box resets itself. I don't ever see it go
back to the "text mode." However, if I change the increment so that it
only draw every other line, then I *do* see this go to text mode. I
have done the obvious things to figure out why it's hanging, but have
pretty much come up dry. I've commented out the "out8" calls in the
native code, and replaced them with "kprintf" calls -- when I do this,
it runs all the way to the end, and does a GC successfully.
Thomas, if I were to want to go back to text mode from native code so
that I could do a sort of "Blue Screen of Death," what calls must I make
to the VGA hardware to do that? Do you know off the top of your head?
I know you have done this in the Java code...
> Part of why I was asking about the JavaOS docs earlier was that I wanted
> to fix this problem (interrupt lossage, among other things) before fixing
> the keyboard driver, and as long as I was mucking about with it, I might
> as well muck about in a fashion at least vaguely resembling what it
> 'should be'.
Cool. This is fine with me if you do this.
> Anyway, I haven't been doing almost nothing recently, but if I get
> any work done this weekend, I'll try to make work on JNI/classpath...
I'll have to wait on this until this weekend, which will unfortunately
be shortened due to my having to go to recruiting at a local university
on Friday.
> Oh, BTW, parts of the NATIVE_CLOCK bit had to do with the
> HANDLE_CLOCK bits because Bocek (I believe) requested use of the rtc for
> the floppy driver.
Hmm... is the "real time clock" the CMOS read-only one, as opposed to
the system interrupt-generating clock (he asked, confusedly, and away
from his PC documents)?
-jm
--
==== John Morrison
==== MaK Technologies Inc.
==== 185 Alewife Brook Parkway, Cambridge, MA 02138
==== http://www.mak.com/welcome.html
==== vox:617-876-8085 x115
==== fax:617-876-9208
==== [EMAIL PROTECTED]
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
