r128 driver problem

I'm looking for someone to help me with a problem I'm having with the r128 driver. See attached messages for a description of the problem. I think I've proven that the problem is related to the driver/device, but I don't know enough about the device and how it works to fix the problem myself. Any help would be much appreciated.

Thanks!

Bill Shannon

Hi guys. I got your names from r128_irq.c. I'm hoping you can help me or point me in the right direction.

I upgraded my Dell 4550 from Fedora Core 1 to Fedora Core 2 and I'm having problems that I reported here:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132930

I've been trying to debug this myself and so far it looks like as soon as the r128 driver is closed, I get a flood of interrupts that aren't handled, eventually causing the kernel to disable IRQ 11. My theory is that these are VBLANK interrupts from the video card that are no longer handled because the r128 interrupt handler has been removed from the IRQ handler list. It's pretty clear that the driver is attempting to disable such interrupts before removing the driver from the list. I don't know anything about how this device works so I can't say whether or not it's doing that correctly.

I've tried hacking the IRQ handler to call back into the r128 driver when it finds that the IRQ hasn't been handled by any of the drivers on the list, so that the r128 driver can determine if it was the cause of the interrupt after all. Unfortunately, I don't understand enough about how devices work in Linux (or on x86 hardware) and I can't seem to get this to work. As soon as I try to touch the device the kernel hangs.

I noticed that in FC1 the r128 driver didn't appear to use interrupts. That seems to be a capability added in the 2.6 kernel, in the r128_irq.c file that has your names in it! :-) So that would explain why FC1 works fine on the same hardware.

Oh, and I've tried all the frequently recommended tips like booting with pci=noacpi and acpi=off. They don't make any difference.

Anyway, I was hoping that one of you might have some idea of what the problem might be or what I could do to further debug the problem.

Oh yes, the video card is an "ATI Rage 128 Pro Ultra".

Thanks for any help you might offer!

Bill Shannon

Ok, I think I've now proven that my ATI Rage 128 device is generating interrupts even after the r128 driver disables interrupts.

In r128_driver_irq_uninstall, after it writes to the device to disable interrupts, I set a global variable that says interrupts are disabled. I then use vblank_wait to wait for the next vblank interrupt. If interrupts were really disabled, I would expect vblank_wait to return indicating that the timeout expired. It doesn't, it returns success.

In r128_dma_service, if I get an interrupt while the global "interrupts are disabled" flag is set, I increment a counter. After vblank_wait returns in r128_driver_irq_uninstall, I check the count. It indicates that an interrupt was received after interrupts were disabled.

To me, that looks like proof that there's something wrong here. Maybe the hardware is broken, or maybe it's just not working the way the driver expects. Or maybe the driver is not doing the right thing to really disable interrupts.

At this point I need some help. Are either of you the right person to help? If not, can you point me to someone else who might be able to help?

Thanks much!

Bill Shannon

Looks like this is for the DRI people <[email protected]>.

Tony

PS: The latest kernel snapshot contains an aty change that also installs an interrupt handler that waits for vblank. I doubt this is the cause of your problems, but it's better to disable atyfb before sending mail to the DRI list (in case you're using the latest kernel).

-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click