atyfb & lockups

atyfb & lockups

[Benjamin Herrenschmidt]

I have an old PowerBook Wallstreet I here with a Rage LT-G. I've been
booting it from Open Firmware instead of MacOS lately (thus didn't give
a chance to the MacOS driver to do it's own tweaking of the chip) and
the machine has been reliably locking up on me. Solid lockups. I finally
figured out that the lockups appear to be atyfb related and that booting
with video=atyfb:noaccel fixes it.

It seems that when it's lockup, the whole machine is down, that is it
won't take interrupts to get to the xmon low level debugger nor
anything, thus I suspect the PCI is locked up.

Are there any ideas of where to look for the source of the problem ?

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

Re: atyfb & lockups

[Knut Petersen]

>I have an old PowerBook Wallstreet I here with a Rage LT-G. I've been
>booting it from Open Firmware instead of MacOS lately (thus didn't give
>a chance to the MacOS driver to do it's own tweaking of the chip) and
>the machine has been reliably locking up on me. Solid lockups. I finally
>figured out that the lockups appear to be atyfb related and that booting
>with video=atyfb:noaccel fixes it.
>It seems that when it's lockup, the whole machine is down, that is it
>won't take interrupts to get to the xmon low level debugger nor
>anything, thus I suspect the PCI is locked up.
>  
>
Well, there are other possibilities.

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

>Are there any ideas of where to look for the source of the problem ?
>
>  
>

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.
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.

cu,
 knut


-------------------------------------------------------
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

Re: atyfb & lockups

[Benjamin Herrenschmidt]

> 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