[Acx100-devel] [ acx100-Bugs-911475 ] Switching from XFree86 4.3.0 to console --> IRQ hangup/delay

[SourceForge.net <no...@so...>]

Bugs item #911475, was opened at 2004-03-07 17:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=543745&aid=911475&group_id=75380

Category: None
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Andreas Mohr (andim2)
Assigned to: Andreas Mohr (andim2)
Summary: Switching from XFree86 4.3.0 to console --> IRQ hangup/delay

Initial Comment:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=543745&aid=911475&group_id=75380