On Fri, 2003-10-31 at 19:58, Michael Schmitz wrote: > > > Can the classic emulation be used for this? > > > > No. Unfortunately, Macsbug is useful for tracking HW access, but classic > > emulation does no HW access, it all gets routed to underlying OS X drivers > > That's what I feared. I'll leave it to others, then. > > On the 2.6 front, I've _once_ been able to get the kernel to boot all the > way, and backlight control did work as expected. 99% of the time though, > the kernel barfs sometime after rivafb init. xmon output goes to serial > which is utterly pointless on a flat panel iMac
Tried forcing use_screen to 1 in xmon ? if that doesn't work, you have the option of using firewire debugging :) I pushed a working xmon over firewire to my 2.6 tree, though to use it, you'd have to hack ordering so that OHCI gets loaded before rivbafb, and probably hack a delay so you have time to "attach" from the remote host > so I'm resorting to poor > man's debugger techniques. The console code appears to tweak the backlight > state a couple of times (upon registering the backlight controller, the > backlight gets turned on, then off, then on again) and depending on the > amount of delay I introduce by adding printk() output, the crash happens > at different times after rivafb init. I'm suspecting stray interrupts, or > concurrent access to the graphics adapter by other code, or high bogon > flux, or some such. > Is there a way to delay registering the backlight controller until later time > during boot? I wouldn't trust such a solution. If there is a race, you'll only "move" it by doing so. If for some reason, for example, we mustn't touch the card while doing the backlight bit for a while, then you'd rather add delays here or there and eventually a spinlock. Maybe those accesses are fifoed or you need to make sure the engine is empty before doing them ? tried without acceleration ? Or it's just a delay to wait for the PLL to lock properly. Ben.
