Polled mode functions fail with WTX protocol

[kittu]

Hi,

I have implemented polled mode functions for my ethernet driver on a
custom board for a custom ethernet controller on VxWorks6.7

I am able to swtich from task mode to system mode and vice versa.

After the switchover, I am able to run the host shell and run ping
etc. commands.

However, when I run the WTX tests, the tests on Polled mode are
failing.

I had the following observations.

1. When swtiching the mode from task mode to swtich mode, the packets
are received through a task spawn by interrupt mode function and the
send is done through polledmode function I implemented.

Is this correct? Is the polled mode receive function not used while in
system mode?

When I debugged, observed that the polled mode functions are called in
interrupt context.
i am saying it as interrupt mode becuase the debug messages are
printed as

interrupt: SgPollRecv: received packet etc..

Any inputs?

Thanks,
Vidhumouli

[renan56]

On Sep 16, 2:28 pm, kittu <vidhumo...@gmail.com> wrote:
> Hi,
>
> I have implemented polled mode functions for my ethernet driver on a
> custom board for a custom ethernet controller on VxWorks6.7
>
> I am able to swtich from task mode to system mode and vice versa.
>
> After the switchover, I am able to run the host shell and run ping
> etc. commands.
>
> However, when I run the WTX tests, the tests on Polled mode are
> failing.
>
> I had the following observations.
>
> 1. When swtiching the mode from task mode to swtich mode, the packets
> are received through a task spawn by interrupt mode function and the
> send is done through polledmode function I implemented.
>
> Is this correct? Is the polled mode receive function not used while in
> system mode?

When you switch to system mode, the target can be either:

- In a running mode (i.e interrupts are still enable, the scheduler
is still running, ..)
- Or in a stopped mode (i.e interrupt are locked, the scheduler is no
longer running, only the WDB agent is running).

If the target is running. Input network packets will be handled by the
interrupt handler of the network driver and output packets will be
send via output polling mode routine.
If the target is stopped. Both input and output network packets will
be handled by polling mode routines.

Renan

[Bill]

The polled receive and transmit APIs in an END driver are used
primarily by the WDB agent when the target is running in "system"
mode. In system mode, multitasking and interrupts are disabled, and
the target is running single-threaded under the WDB agent's control.

Given this, the polled RX and TX routines are forbidden to use
blocking kernel calls (taskDelay(), semTake(), etc...). You also can't
rely on help from another task, since no other task can run.

Implementing polled mode is consequently very tricky. Not only do you
have to avoid using blocking kernel calls, you also have to be able to
switch back and forth seamlessly from polled mode to interrupt-driven
mode. Debugging is complicated by the fact when once you get into
system mode, you can't print any output to the console.

One of the things the WTX test script does is switch the target in and
out of system mode several times in rapid succession, which switches
the driver in and out of polled mode as well. This is where being able
to switch seamlessly is important: if you don't save and restore the
device and driver state correctly when transitioning between modes,
you'll have problems.

-Bill

[kittu]

> -Bill- Hide quoted text -
>
> - Show quoted text -

Sorry for the delayed response. I was on a long vacation and came back
and started working again on this issue.

Thanks renan for the very useful information.

Bill,

Thanks for your clear information on WTX.
There seems to issue in my driver during the switchover process.
I think the poll receive and poll send functions are working properly
but the device and driver context retention seems to be an issue
during switch over.

When the mode switch over occurs from task to system mode, I am
seeing the 0x730007 error on tNet0. I am using the IPNET driver.
As you said, I am not able to see the printfs. I am trying to use the
WindRiver probe it is not hitting the break point if there is a
ipcomptr null condition.

Is there any other way we can try debugging the issue.

Thanks
Vidhumouli

[kittu]

On Oct 8, 6:03 pm, kittu <vidhumo...@gmail.com> wrote:
> On Sep 18, 11:26 pm, Bill <noiset...@gmail.com> wrote:
>
>
>
>
>
> > On Sep 16, 5:28 am, kittu <vidhumo...@gmail.com> wrote:
>
> > > Hi,
>

> > > I have implementedpolledmodefunctions for my ethernet driver on a

> > > custom board for a custom ethernet controller on VxWorks6.7
>

> > > I am able to swtich from taskmodeto systemmodeand vice versa.

>
> > > After the switchover, I am able to run the host shell and run ping
> > > etc. commands.
>
> > > However, when I run the WTX tests, the tests onPolledmodeare
> > > failing.
>
> > > I had the following observations.
>

> > > 1. When swtiching themodefrom taskmodeto swtichmode, the packets
> > > are received through a task spawn by interruptmodefunction and the

> > > send is done through polledmode function I implemented.
>

> > > Is this correct? Is thepolledmodereceive function not used while in
> > > systemmode?
>
> > > When I debugged, observed that thepolledmodefunctions are called in
> > > interrupt context.
> > > i am saying it as interruptmodebecuase the debug messages are

> > > printed as
>
> > > interrupt: SgPollRecv: received packet etc..
>
> > > Any inputs?
>
> > > Thanks,
> > > Vidhumouli
>

> > Thepolledreceive and transmit APIs in an END driver are used

> > primarily by the WDB agent when the target is running in "system"

> >mode. In systemmode, multitasking and interrupts are disabled, and

> > the target is running single-threaded under the WDB agent's control.
>

> > Given this, thepolledRX and TX routines are forbidden to use

> > blocking kernel calls (taskDelay(), semTake(), etc...). You also can't
> > rely on help from another task, since no other task can run.
>

> > Implementingpolledmodeis consequently very tricky. Not only do you

> > have to avoid using blocking kernel calls, you also have to be able to

> > switch back and forth seamlessly frompolledmodeto interrupt-driven

> >mode. Debugging is complicated by the fact when once you get into

> > systemmode, you can't print any output to the console.

>
> > One of the things the WTX test script does is switch the target in and

> > out of systemmodeseveral times in rapid succession, which switches
> > the driver in and out ofpolledmodeas well. This is where being able

> > to switch seamlessly is important: if you don't save and restore the
> > device and driver state correctly when transitioning between modes,
> > you'll have problems.
>
> > -Bill- Hide quoted text -
>
> > - Show quoted text -
>
> Sorry for the delayed response. I was on a long vacation and came back
> and started working again on this issue.
>
> Thanks renan for the very useful information.
>
> Bill,
>
> Thanks for your clear information on WTX.
> There seems to issue in my driver during the switchover process.
> I think the poll receive and poll send functions are working properly
> but the device and driver context retention seems to be an issue
> during switch over.
>

> When themodeswitch over occurs from task to systemmode,  I am

> seeing the 0x730007 error on tNet0. I am using the IPNET driver.
> As you said, I am not able to see the printfs.  I am trying to use the
> WindRiver probe it is not hitting the break point if there is a
> ipcomptr null condition.
>
> Is there any other way we can try debugging the issue.
>
> Thanks

> Vidhumouli- Hide quoted text -

>
> - Show quoted text -

Further debugging showed the following observation.

When we select the switch mode function is selected, the mode is
switching properly and am able to run the host shell, run commands
like "i", b etc.

However, when I run the WTX test, upon receiving of the POLLSTART
command from the WDB, the local Recv task spawned in interrupt handler
to process the earlier Rx packets was in not yet completed. It just
sent the last packet received from WTX in interrupt mode to stack and
was yet to do the housekeeping of freeing the buffers and creating new
BDs and attaching the IPCOMs to it.

After completing the ioctl processing, the WDB is calling the
SgPollRecv and the control never comes back to RecvTask until the
POLLSTOP command is received and the context switch occurs.

Due to this, the completely sgdma BDs are going for a toss and BD
mismatch was being shown.

To confirm this, I made a small modification, I made sure in the
recvtask to give the last packet of processing to the stack only after
all the housekeeping is done. This showed the sequence of BDs didn't
go for a toss and polled mode tests are passing. During this
condition, the number of BDs that I kept in the driver was 512.
However, the moment I reduced it to lesser BDs like 64, the Poll tests
are failing but the BD mismatch is not happenning. upon running the
"i" in the shell showed that there is an error of 0x730007 has
occured.
There is no issue with the driver in interrupt mode with BDs as 64. I
could run the 64kPing without any issue and run the netperf tests
etc...very well.

Any thoughts?

Thanks,
Vidhumouli