Re: SMSC91C111 interrupt service routine

From: Derek Ou (douatsiconixdotcom_at_hatespam.com)
Date: 07/09/04


Date: Fri, 9 Jul 2004 15:11:33 -0600

That's right, Art. I disconnect the chip from the network and it passed
through the driver loading. Thanks a lot for your help. I will try your
fix then.

"Art" <Art@discussions.microsoft.com> wrote in message
news:9EFC108F-CF6B-4519-995A-972A79DD7498@microsoft.com...
> Derek, I am not sure if this is same problem I had, but I also stuggled
with initial interrupt activation. I think, the SMSC driver activates the
receiver way too early, see AdapterReset(), line: Adapter->RCR = RCR_RX_EN;
>
> This caused the device to be able to receive frames from the network
before LAN91C111_MiniportInitialize() returns to NDIS. Therefore, as soon as
you enable device interrupt you get an interrupt event (for frames in RX
FIFO) which your driver process and signals to NDIS, but NDIS is not ready
yet to handle these event as you mini-port has not completed initialization
yet. This causes the hang similar to what you observed. Disconnect your
device from the network and see if this problem goes away. If yes, then most
likely this is a problem.
>
> Also, to debug set a breakpoint in LAN91C111_MiniportISR and
LAN91C111_MiniPortHandleInterrupt. Setting brekapoints in
OEMInterruptHandler won't work. The debug message might work though.
>
> My fix was:
> ** in AdapterReset do not enable receiver
> ** in LAN91C111_MiniportInitialize(), in the very end after you enable
Interrupts, add a code to activate receiver.
>
> This way you first enable interrupts and only after that you activate
receiver. There is still a small window of opportunity that you can get a
frame before you return from LAN91C111_MiniportInitialize, but much smaller.
If this is a case you would have to change 5th parameter in
NdisMRegisterInterrupt() to be FALSE and modify LAN91C111_MiniportISR to ack
and handle all asserted interrupts right there without calling
LAN91C111_MiniPortHandleInterrupt() (simply clear pending interrupts and
return with *QueueMiniportHandleInterrupt = FALSE; See MSDN for explanation.
>
> This is what I had to do on my platform to get SMSC driver going.
>
>
> "Derek Ou" wrote:
>
> > Hi all,
> >
> > I need some help on the SMSC91C111 interrupt service routine. Currently
the
> > CE .net driver hangs the CE system as soon as the interrupt hardware is
> > enabled.
> >
> > To be exactly, it happens near the end of the
LAN91C111_MiniportInitialize
> > function of LAN91C111_Init.C around line 276, NdisTawWritePortUshort
> > (Adapter->IOBase + BANK2_INT_STS, (USHORT) (ENABLE_INTS << 8));. Before
> > this line is executed, the SMSC91C111 chip successfully finds the hub
and
> > the network. (So the IO address and the chip are fine.) But as soon as
> > this line is executed, the interrupt line INTR0 goes high and CE system
> > stops. I am thinking maybe the CE system can't find the interrupt
handler.
> > How can I trace it? I tried to put a breakpoint at the beginning of the
> > OEMInterruptHandler and CE didn't even start. I put a breakpoint inside
the
> > same function where if (v_pGPIOReg->GEDR_x & GPIO_14) and this
breakpoint
> > has never been reached. Can you give a hand here? I am really stuck.
> >
> > Additional information:
> > Platform: Intel DBPXA25x based custom board with Intel PXA255 CPU
> > Tools: MS Platform Builder 4.2
> > Driver: SMSC91C111 Win CE .net driver V2 for Xscale,
> > Interrupt: GPIO14 of PXA255, InterruptNumber: 10, sysintr: 32
> >
> > Your generous advices will be highly appreciated!
> > Derek
> >
> >
> >



Relevant Pages

  • Re: Patch available for shared em interrupts (Re: em, bge, network problems survey.)
    ... I'm seeing some patterns here with all of the network driver problem ... Are you experiencing network hangs and/or "timeout" messages on the ... If your em device is using a shared interrupt, ... Note that this patch will not help you if you are not using the em ...
    (freebsd-stable)
  • Re: splxxx level?
    ... ::> a question about interrupt priority levels. ... ::> There are currently three entry points into the driver: ... the network reception can cause a buf to be completed ... :: the appropriate spl level regardless. ...
    (freebsd-arch)
  • Re: splxxx level?
    ... :> I'm almost to testing on my AoE driver for 4.x and have ... :> a question about interrupt priority levels. ... the network reception can cause a buf to be completed ... the appropriate spl level regardless. ...
    (freebsd-arch)
  • Re: 64-bit system hang in KiInterruptDispatch
    ... we could be in any of various places in the driver. ... > break and a clock interrupt, ... > KiInterruptDispatch, but that function never returns back to our driver. ... I set a breakpoint at KiInterruptDispatchNoLock+122. ...
    (microsoft.public.development.device.drivers)
  • Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
    ... If the system fails in ACPI mode, but works in non-ACPI mode, ... Using ACPI for SMP configuration information ... Using IOAPIC for interrupt routing ... Non-volatile memory driver v1.2 ...
    (Linux-Kernel)