Re: LAN91C111 driver keep reset itself

From: J.C. (JC_at_discussions.microsoft.com)
Date: 02/28/05 

Date: Mon, 28 Feb 2005 09:35:03 -0800

We have a simple client/server program using socket to transfer the data.
When you say error generated, do you mean error from the driver or the
application above it? I have not looked into the test application. But that
could be a source of error, right? How often is *very* occasional? Thanks.

J.C.

"Paul G. Tobey [eMVP]" wrote:

> There is no case where I get *that* sort of behavior. I just ran a quick
> transfer of a 25MB file over 100BaseT from a network server to the device.
> As long as there's enough disk space on the device to receive that size of
> file, it works fine. What method of transfer are you using? Are you sure
> an error is not being generated.
>
> If you're still getting more than a *very* ccasional RESET, you're probably
> still dropping interrupts...
>
> Paul T.
>
> "J.C." <JC@discussions.microsoft.com> wrote in message
> news:F08FE196-348F-4377-AA2B-BDEB2C019C31@microsoft.com...
> > Yes, we made similiar changes to the interrupt handler as Leif described
> > (without changing buffer allocation), and the throughput improved a lot.
> > But
> > we still see reset happening. Another strange behavior is that when we
> > transfer a large file (20MB) to the device, it just ignore it when it
> > cannot
> > handle it. So it only works if I send through 10Mb pipe, not 100Mb pipe.
> > Have
> > you seen that? I am guessing the driver just cannot handle such large
> > burst.
> > Thanks,
> >
> > --Juliet
> >
> >
> >
> > "Paul G. Tobey [eMVP]" wrote:
> >
> >> Your changes sound very much like mine and I'm not licensed to distribute
> >> derivative works. I think that what you're doing is the right thing.
> >> You
> >> might verify that buffer allocation in the chip is being handled
> >> correctly,
> >> especially when, initially, there is no buffer to be allocated (I'm
> >> talking
> >> about packet buffers inside the chip itself).
> >>
> >> The performance improvement was because of the number of RESETs of the
> >> controller that were occurring because of missed interrupts...
> >>
> >> Paul T.
> >>
> >> "Leif O" <leif_nospam@vmetro.no> wrote in message
> >> news:opsmoyj5h00siefu@msnews.microsoft.com...
> >> > Paul,
> >> > I'm using the SMSC supplied XScale driver which I've modified slightly
> >> > to
> >> > adapt to our custom hardware. The code is based on version 2 of the
> >> > driver
> >> > (for Windows CE 4.2), which I think is (still) the latest publicly
> >> > available version. Since they've more recently released an x86 driver
> >> > for
> >> > Windows CE 5.0, I've asked SMSC if there would soon be a corresponding
> >> > update of the XScale driver as well, but I was told that although their
> >> > road-map includes such a driver, it will be scheduled against demand.
> >> >
> >> > The changes I had to make to the interrupt handling was mostly moving
> >> > the
> >> > parts of the driver code in
> >> > LAN91C111_EnableInterrupt/LAN91C111_DisableInterrupt into the OAL
> >> > kernel
> >> > interrupt code, avoiding the normal NDIS callbacks for
> >> > masking/unmasking
> >> > the interrupts on the adapter.
> >> >
> >> > Since your changes made a big difference in throughput, you wouldn't
> >> > mind
> >> > sharing them ?
> >> >
> >> > Regards,
> >> > Leif O
> >> >
> >> > On Wed, 23 Feb 2005 08:50:47 -0700, Paul G. Tobey [eMVP] <ptobey no
> >> > spam
> >> > AT no instrument no spam DOT com> wrote:
> >> >
> >> >> Yes, interrupt handling. I was getting those resets all over the
> >> >> place
> >> >> with
> >> >> the driver I got from SMSC several years ago. I reworked the
> >> >> interrupt
> >> >> handling in the kernel and the driver and eliminated them. Made a big
> >> >> difference in throughput. I sent back my changes to SMSC so I'd
> >> >> expect
> >> >> that
> >> >> they at least know something about the problem. What driver are you
> >> >> using?
> >> >>
> >> >> Paul T.
> >> >>
> >> >> "Leif O" <leif_nospam@vmetro.no> wrote in message
> >> >> news:opsmm4h10w0siefu@msnews.microsoft.com...
> >> >>> I had a few Reset issues with my LAN91C111 driver when moving it from
> >> >>> my
> >> >>> proprietary 4.2 device to a 5.0 build for the MainstoneII evaluation
> >> >>> board. As far as I can recall, though, these issues where related to
> >> >>> platform specific differences that I needed to attend to in my
> >> >>> interrupt
> >> >>> handling (masking etc). If you're running your 5.0 build on the same
> >> >>> device as your 4.2 build, such issues might not be a problem for you,
> >> >>> but
> >> >>> you should at least look for any added Windows CE version-specific
> >> >>> #ifdefs
> >> >>> in your code.
> >> >>>
> >> >>> Regards,
> >> >>> Leif O
> >> >>>
> >> >>>
> >> >>> On Tue, 22 Feb 2005 17:15:02 -0800, J.C.
> >> >>> <JC@discussions.microsoft.com>
> >> >>> wrote:
> >> >>>
> >> >>>> Hi all,
> >> >>>>
> >> >>>> We ported LAN91C111 driver for WinCE4.2 to Win5.0 on Xscale
> >> >>>> platform.
> >> >>>> we
> >> >>>> can
> >> >>>> send and receive data okay. But when I transfer a large chuck of
> >> >>>> data
> >> >>>> in
> >> >>>> a
> >> >>>> burst, I see the driver keep reset itself. Have anyone experienced
> >> >>>> this
> >> >>>> before? And any idea on how to resolve this problem? Thanks for
> >> >>>> replying.
> >> >>>>
> >> >>>> J.C.
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> leif AT vmetro DOT no
> >> >>>
> >> >>> Using M2, Opera's revolutionary e-mail client:
> >> >>> http://www.opera.com/m2/
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > leif AT vmetro DOT no
> >> >
> >> > Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
> >>
> >>
> >>
>
>
>

Relevant Pages