From: Jun Sun (jsun_at_junsun.net)
Date: 2002-07-21 05:31:57 UTC
On Sat, Jul 20, 2002 at 11:38:50AM +0300, Jouni Malinen wrote:
> On Fri, Jul 19, 2002 at 04:12:49PM -0700, Jun Sun wrote:
>
> > On one of my systems, I found host ap driver caused many spurious
> > interrupts.
>
> I haven't noticed this on any of the systems I'm using (though, I
> haven't really looked for it either). Is there anything special about
> the system that sees this?
>
I don't think so. It is a normal MIPS boards with PCI slot. I just plugged in the PCI card.
I think this problem may exist on other systems too, because most system choose to ignore spurious interrupts rather than printing anonnying messages.
> Before using very much energy on this issue, I would first check whether
> it causes any real problems. I'm assuming you are using default driver
> configuration (i.e., compile it with cmd completion events for transmit
> command). In this case normal TX and RX paths do not use hfa384x_cmd()
> at all. In other words, hfa384x_cmd() is used only for configuration
> reads/writes and having few extra interrupts with these should not be a
> problems.
>
Ahh, that explains. So far I only see the messages when I do iwconfig, presumably it is doing the configuration.
> However, there is an exception for this: if you have stations using
> power saving, TIM bit needs to be set for every TX to that station and
> this will currently use hfa384x_cmd() (though, I have planned on doing a
> TIM set queue that would work somewhat like transmit command handling,
> i.e., without busy waiting command completion).
>
No power saving yet.
> > The problem is at the end of hfa384x_cmd() function in prism2.c file:
> > HFA384X_OUTW(HFA384X_EV_CMD, HFA384X_EVACK_OFF);
> > spin_unlock_irqrestore(&local->cmdlock, flags);
>
> > It appears HFA384X_OUTW() would do an interrupt acknowledgement, followed
> > by immediately opening interrupts again. What might have happened is
> > that interrupt acknowledge does not propagrate fast enough. So when
> > interrupts are opened again, CPU still sees a pending interrupt.
> > When we actually take the interrupt, the irq ack propagates to CPU
> > and we found no IRQ.
>
> Yes, this sounds possible. I don't know how long it takes for the card
> to remove pending interrupt indication after an individual event is
> ACKed, but it may well be enough for the CPU to be interrupted after
> spin_unlock_irqrestore.
>
> > If this is true, is there any way we can shuffle the code around so that
> > the IRQ ack happens a little earlier than the intr re-opening?
>
> With current hfa384x_cmd() this is not really doable (apart from using
> extra delay which is not that nice), since it busy waits for the command
> completion event and then reads the response and status. These registers
> have to be read before ACKing the event and since there is nothing more
> to do in hfa384x_cmd(), interrupts will be re-enabled quite soon.
>
> Some minor changes can be done by first reading resp0 and status to
> local variables and then ACK EV_CMD. After this, do res = local_resp0 &
> (bits) and the #ifndef final_version block before
> spin_unlock_irqrestore. However, this will have only a tiny delay
> between ACK and irq restore and might not help at all. How long delay
> you used to get rid of those extra interrupts?
>
I will do an experiement and let you know the more accurate number.
> I have planned on experimenting with quite a bit different driver
> structure as far as command completion is concerned, but this would
> change the driver quite a bit. The commands could be queued in a
> host-side list and then performed without busy waiting the command
> completion event. Interrupt handler would get the command completions
> and it would then issue the next pending command if one is in the queue.
> The interrupt handler would also call whatever code would be needed to
> finish handling the completed command.
>
Sounds more complicated but definitely seems more appropriate.
> Current driver does this for the transmit command, but it could be
> extented also for other commands. This would make the transmit command
> handling cleaner, but there are some problems with doing all commands
> without busy waiting.
>
> Things like RID reads from code that must not sleep or return
> immediately would require busy waiting for the interrupt handler to get
> the event (and this could take a while, if the pending command queue had
> many entries). In addition, this would be impossible if the command
> would need to be done in a situation where the interrupts are disabled
> and an old command is being completed. Although, I do not remember
> whether such situations are used in the current driver code.
>
> Changing the command completion handling completely will certainly
> require quite a bit of planning and testing, so it won't happen
> immediately. The minor changes in hfa384x_cmd() can be done (and I will
> probably do them even if they don't show any noticeable help since they
> will anyway make the interrupts disabled time a bit smaller).
>
Thanks for the explaining. It helps my understanding quite a bit.
Jun