Re: LAN91C111 driver keep reset itself

From: Paul G. Tobey [eMVP] (ptobey)
Date: 02/28/05 

Date: Mon, 28 Feb 2005 11:31:33 -0700

You brought up the transfer of a file. Are you doing that via your
client-server program? Are you sure you aren't getting a file-based error
when you try to write the file to the 'disk' you are targeting?

Once-a-day would probably qualify as very occasional, as far as RESETs go.
More frequently than that and I'd say that you really are missing
interrupts, which you don't want to do.

Paul T.

"J.C." <JC@discussions.microsoft.com> wrote in message
news:B62F76A4-0245-4DA3-A3DE-ED464CA95D39@microsoft.com...
> 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/
>> >>
>> >>
>> >>
>>
>>
>>