SEMI-SOLVED: IRQ hangup after switch from XF86 4.3.0 to text

Hi all,

I just installed the new XFree86 4.3.0 on my Debian
box, resulting in a complete and hard lockup of the
ring buffers of the driver due to them filling up at
the very moment of switching from XFree86 to a text
console, which is caused by the IRQ getting disabled
for some strange reason.
Not even an ifconfig down/up helps to reestablish
proper operation, I need to eject/reinsert the card!

After some analysis I *know* that it's an IRQ problem
(which then leads to both all Rx and Tx buffers filling
up completely
due to no required IRQs arriving to be able to service
the buffers).
The thing is, the firmware still does generate host
interrupts (host irq
diag counter increasing),
but cat /proc/interrupts doesn't show any interrupt
arriving (as does
the driver 0xffff log, which is soooo lost and lonely
without irq activity,
it's not even funny any more).
Also, triggering a host interrupt manually in the card
doesn't manage even
one bit to trigger an interrupt in the host.

All interrupt related I/O registers of the card are
totally non-suspicious
when compared with the working state (no changes).

I'm completely and totally at a loss as to what the
he** makes the irqs
totally disappear (this happens immediately once I
switch from XFree86 4.3.0
to console).
And like I said, I strongly suspect it's not only
occurring during my XFree86 thingy, but instead this
problem is responsible for many hickups other people
have reported.

Various cardctl commands don't show any issue with the
CardBus socket either.

Also, reenabling irqs in Linux (local_irq_enable()) via
the test ioctl
didn't help either.

The only way to reestablish operation is to actually
eject and reinsert the
card, nothing else short of that helps.

oes anyone know what could make irqs of my CardBus card
completely disappear
despite the firmware assuring me that it DOES generate
irqs?
(keep in mind that I didn't manage to generate a host
interrupt
via the host interrupt trigger I/O register either!)
How many and which mechanisms are there in Linux to
control/enable/disable
IRQ invocation?
And what the he** could be the reason that the acx100
irq is non-functional
after the XFree86 console switch? What does XFree86 do
there???

Needless to say, the card itself plus firmware is still
active, since I can
still tell it to pass me the firmware status printout,
so it cannot
be stuck somewhere in some firmware code.

cat /proc/interrupts:
andi@note:/home/andi/acx100/CVS/acx100$ cat
/proc/interrupts
CPU0
0: 4837096 XT-PIC timer
1: 13752 XT-PIC i8042
2: 0 XT-PIC cascade
4: 10 XT-PIC serial
5: 0 XT-PIC Maestro3
10: 161465 XT-PIC uhci_hcd, yenta,
yenta, wlan0
12: 196984 XT-PIC i8042
14: 126015 XT-PIC ide0
NMI: 0
ERR: 2
andi@note:/home/andi/acx100/CVS/acx100$

The same problem occurs on the notebook of my
girlfriend (P3/500 w/ 256MB compared to my P3/700 w/
512MB), although there the IRQs get delayed instead of
completely hanging, which then results in pinging still
being possible, albeit in patterns of 2221ms, 1221ms,
21ms, 2221ms, 1221ms...

Conclusion: now I'm completely confused and baffled,
and I just hope I'll be able to find out what the he**
is causing that issue.
I'll (s/l)trace X server operation now (I'll also
remove unneeded XFree86 modules to isolate the issue).
Also, I'll try to implement a horribly hard reset in
the driver that actually succeeds in getting proper
card operation back. I'm not at all sure whether I'll
succeed here, though.