Well, there are other possibilities.

When does the lockup occure?  Immediately when booting? Later? During 
start of 
xdm/kdm? Random?

During boot, when drawing text in console mode, usually when it starts
scrolling but not necessarily.

I would start to investigate the case by instrumenting and extending the 
fb_sync code.
Try to include code there that resets the chip and switches to the 
noaccel counterparts of the
accelerated functions when a timeout occures. That way you should have a 
chance to resume.

Yah, I should do something like that. I remember trying to track that
bug down a while ago now, and I think I had it working by adding syncs
all over the place.

However, I think the problem is more likely to be some bad fifo or
bandwidth setting in the engine causing it to lockup when loaded. It
works if I boot MacOS and use BootX to then boot linux, though I then
have different display problems (definitely look like incorrect settings
of the display fifo).

Is the timeout counter ok? Maybe you should decrease/increase it.   If 
switching to
the noaccel function works, include a register dump before resetting the 
chip, use show_trace()
etc for further debugging.

Will do all of these as soon as I find some time. My initial post was
mostly to ping in case it was a known issue or somebody else already
tracked it down.

Ben.




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click