Axel wrote: > Oh, didn't even know about that :-) > I would think that in that case, it might often not even be needed to > touch these, although it's probably a good idea to make sure that > they > are set up properly, anyway. I've briefly looked at the mtrr modules in dano: they also give access to the fixed range registers, not that BeOS uses those though (the only time the mtrr module is loaded at all, is on request of the graphics kernel driver mapping with MTR flags (in practice). > Yup, I guess you have to live with that. Have you tried reading out > the > MTRR flags to see if they were already setup by the BIOS? Or does > BeOS > reset them some way? Next up testing this ;-) I'll keep you posted on my findings. I do not believe(expect) however that BeOS would reset the graphics framebuffer MTRR config if that were done by the BIOS, and I have the feeling that the BIOS also does not setup this specific thing as well. (or my tests for speed with VESA mode would have returned different (faster) results.) > Yes, that's quite confusing, especially with interrupt routines. In > the > syslog, the current running team is printed, and since the app_server > opens the graphics driver, that output will usually be prefixed with > [app_server]. For interrupt routines, any thread of any team can run > which makes this even better :) I'll try to remember that for next time :-) > Right, I came across this one, too - that when I heard about MTRR for > the first time :) I'm only now getting the picture a bit myself about the MTRR stuff and what it's good for. (apart from WC f course ;-) Anyway: tricky on SMP systems apparantly, as all CPU's need to get the exact same setting at the same time... but you already knew that :) > Hm, if I read my post correctly, I couldn't help you that much, > though > ;-) Thanks anyway: it's always good to know the status of things at least :) Bye! Rudolf.