Alex Pavloff
|
Xilinx devn-xemac not fully functioning with shim layer
|
Alex Pavloff
11/21/2008 2:56 PM
post17095
|
Xilinx devn-xemac not fully functioning with shim layer
(Originally posted in the io-pkt migration, which was the wrong place, sorry).
Hi all,
I'm trying to use the devn-xemac driver with io-pkt, using the shim. This driver is present in the Xilinx Virtex II-Pro
BSP, and is basically a thin QNX layer around Xilinx's EDK-provided source function.
No problems in 6.3.2.
Here's what's happening in 6.4 (using io-pkt-v4).
# io-pkt -ptcpip
# mount -T io-net -o mac=00112233445566 devn-xemac.so
# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192
inet 127.0.0.1 netmask 0xff000000
en0: flags=80008802<BROADCAST,SIMPLEX,MULTICAST,SHIM> mtu 1500
address: 00:00:00:00:00:00
# ifconfig en0 192.168.230.100
# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192
inet 127.0.0.1 netmask 0xff000000
en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> mtu 1500
address: 00:00:00:00:00:00
inet 192.168.230.100 netmask 0xffffff00 broadcast 192.168.230.255
Now, when I try to ping another host, I see outgoing ARP packets, I see the response from the target host... but it
looks like the packets aren't being processed by io-pkt properly. nicinfo report bytes transmitted just fine, but
nothing recieved.
Another issue appears to be that the shim layer isn't picking up the mac address, as it comes in at the default.
I suspect the problem is in the xemac driver not quite agreeing with the shim -- any suggestions on where to look?
|
|
|
Robert Craig
|
RE: Xilinx devn-xemac not fully functioning with shim layer
|
Robert Craig
11/21/2008 3:04 PM
post17098
|
RE: Xilinx devn-xemac not fully functioning with shim layer
And my turn to post in the wrong group :>. I'll move the answer here as
well:
This certainly looks like a MAC problem of some sort. All 0's
for the MAC is a bad thing...
I think that your MAC is incorrectly specified on the command line. It
should be 001122334455. While I don't think that this is the cause of
the problem, let's start there and see if it makes any difference. You
can also try:
io-pkt-v4 -dxemac.so verbose
To start up the stack with the driver in verbose mode and then you can
post the output from sloginfo (assuming that you have slogger running)
and that might give us a bit more info.
Robert.
-----Original Message-----
From: Alex Pavloff [mailto:community-noreply@qnx.com]
Sent: Friday, November 21, 2008 2:57 PM
To: drivers-networking
Subject: Xilinx devn-xemac not fully functioning with shim layer
(Originally posted in the io-pkt migration, which was the wrong place,
sorry).
Hi all,
I'm trying to use the devn-xemac driver with io-pkt, using the shim.
This driver is present in the Xilinx Virtex II-Pro BSP, and is
basically a thin QNX layer around Xilinx's EDK-provided source function.
No problems in 6.3.2.
Here's what's happening in 6.4 (using io-pkt-v4).
# io-pkt -ptcpip
# mount -T io-net -o mac=00112233445566 devn-xemac.so # ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192
inet 127.0.0.1 netmask 0xff000000
en0: flags=80008802<BROADCAST,SIMPLEX,MULTICAST,SHIM> mtu 1500
address: 00:00:00:00:00:00
# ifconfig en0 192.168.230.100
# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192
inet 127.0.0.1 netmask 0xff000000
en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> mtu
1500
address: 00:00:00:00:00:00
inet 192.168.230.100 netmask 0xffffff00 broadcast
192.168.230.255
Now, when I try to ping another host, I see outgoing ARP packets, I see
the response from the target host... but it looks like the packets
aren't being processed by io-pkt properly. nicinfo report bytes
transmitted just fine, but nothing recieved.
Another issue appears to be that the shim layer isn't picking up the mac
address, as it comes in at the default.
I suspect the problem is in the xemac driver not quite agreeing with the
shim -- any suggestions on where to look?
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post17095
|
|
|
Andrew Boyd(deleted)
|
RE: Xilinx devn-xemac not fully functioning with shim layer
|
Andrew Boyd(deleted)
11/21/2008 3:35 PM
post17102
|
RE: Xilinx devn-xemac not fully functioning with shim layer
> nicinfo report bytes transmitted just fine, but nothing received
Often that's a sign of an interrupt problem - it's
not unmasked or firing or functional on the platform.
What does
# pidin irq
say?
--
aboyd
|
|
|
Alex Pavloff
|
Re: RE: Xilinx devn-xemac not fully functioning with shim layer
|
Alex Pavloff
11/21/2008 4:07 PM
post17106
|
Re: RE: Xilinx devn-xemac not fully functioning with shim layer
It tells me that the irq isn't hooked.
Going through the driver, the xemac driver looks like a barely 6.3 driver -- it didn't implement DCMD_IO_NET_GET_CONFIG
or DCMD_IO_NET_GET_STATS, rather, using the old DCMD_IO_NET_NICINFO and DCMD_IO_NET_TXRX_COUNT.
Does the shim driver expect DCMD_IO_NET_GET_CONFIG with a proper config structure, and since it ain't getting, doesn't
know irq and MAC address and everything it's expecting?
|
|
|
Robert Craig
|
RE: RE: Xilinx devn-xemac not fully functioning with shim layer
|
Robert Craig
11/21/2008 4:26 PM
post17107
|
RE: RE: Xilinx devn-xemac not fully functioning with shim layer
Hmmm... The DCMD..._GET are simply for displaying stat and config and
likely won't affect the driver implementation (other than not properly
displaying the information externally). (I say "likely", because I can't
say that I've seen a driver that doesn't do this properly...). The
driver itself takes care of registering for interrupts and setting the
MAC. This isn't done by the shim.
The xemac driver looks quite old. I take it that it worked OK with
io-net on 6.3.x?
What does "pidin irq" report?
Robert.
-----Original Message-----
From: Alex Pavloff [mailto:community-noreply@qnx.com]
Sent: Friday, November 21, 2008 4:07 PM
To: drivers-networking
Subject: Re: RE: Xilinx devn-xemac not fully functioning with shim layer
It tells me that the irq isn't hooked.
Going through the driver, the xemac driver looks like a barely 6.3
driver -- it didn't implement DCMD_IO_NET_GET_CONFIG or
DCMD_IO_NET_GET_STATS, rather, using the old DCMD_IO_NET_NICINFO and
DCMD_IO_NET_TXRX_COUNT.
Does the shim driver expect DCMD_IO_NET_GET_CONFIG with a proper config
structure, and since it ain't getting, doesn't know irq and MAC address
and everything it's expecting?
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post17106
|
|
|
Alex Pavloff
|
Re: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
|
Alex Pavloff
11/21/2008 4:33 PM
post17108
|
Re: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
The driver did work fine on 6.3.2.
Here's the pidin irqs.
1216519 1 bin/io-pkt
1216519 2 bin/io-pkt
3 0x80010000 0 T-- @0x4808131c:0x480d2fc0
4 0 0 TP- =PULSE 0x40000010:21 0:0xfe39f958
1216519 3 bin/io-pkt
|
|
|
Alex Pavloff
|
Re: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
|
Alex Pavloff
11/21/2008 6:59 PM
post17114
|
Re: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
After modifying the driver to be more like a 6.3 driver, things work a little better -- the MAC gets picked up properly
by ifconfig, and it pings and responds.
Now, there's some herky jerky things going on that I'm still trying to figure out.
|
|
|
Alex Pavloff
|
Re: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
|
Alex Pavloff
11/21/2008 7:19 PM
post17115
|
Re: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
> After modifying the driver to be more like a 6.3 driver, things work a little
> better -- the MAC gets picked up properly by ifconfig, and it pings and
> responds.
>
> Now, there's some herky jerky things going on that I'm still trying to figure
> out.
I must clarify. The MAC is picked up correctly, but I haven't gotten a ping since the one time it worked.
One other thing odd I noticed is that, even if I just start io-pkt on the command line, with no drivers whatsoever, it
chews up 10% of the CPU.
Any ideas?
|
|
|
Sean Boudreau(deleted)
|
RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
|
Sean Boudreau(deleted)
11/21/2008 10:36 PM
post17121
|
RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
Is that from hogs? It's probably not accurate. io-pkt attaches
to the timer interrupt so it happens to be busy while hogs is
doing its accounting.
-seanb
-----Original Message-----
From: Alex Pavloff [mailto:community-noreply@qnx.com]
Sent: Fri 11/21/2008 7:19 PM
To: drivers-networking
Subject: Re: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
> After modifying the driver to be more like a 6.3 driver, things work a little
> better -- the MAC gets picked up properly by ifconfig, and it pings and
> responds.
>
> Now, there's some herky jerky things going on that I'm still trying to figure
> out.
I must clarify. The MAC is picked up correctly, but I haven't gotten a ping since the one time it worked.
One other thing odd I noticed is that, even if I just start io-pkt on the command line, with no drivers whatsoever, it
chews up 10% of the CPU.
Any ideas?
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post17115
|
|
|
Robert Craig
|
RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
|
Robert Craig
11/24/2008 11:45 AM
post17198
|
RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
So it worked ONCE and then stopped? I'd try instrumenting the driver
(specifically the receive path) to see if you're actually getting
packets delivered...
In 99% of the cases where we've had drivers not working with the shim,
they have proven to be latent bugs in the io-net driver that had to be
fixed, so that's probably indicative of something :->>
If you really want to get a view of CPU usage, you're always better off
using the system profiler with the instrumented kernel. Hogs hooks into
the system tick just like a number of other utilities, so if often
produces aliased results that are way out of whack with reality (we also
see this all the time with the USB utility). Hogs is OK for generic
things, but you have to be very careful with it's usage when viewing
anything that connects to the system tick.
Robert.
-----Original Message-----
From: Alex Pavloff [mailto:community-noreply@qnx.com]
Sent: Friday, November 21, 2008 7:20 PM
To: drivers-networking
Subject: Re: RE: RE: Xilinx devn-xemac not fully functioning with shim
layer
> After modifying the driver to be more like a 6.3 driver, things work a
> little better -- the MAC gets picked up properly by ifconfig, and it
> pings and responds.
>
> Now, there's some herky jerky things going on that I'm still trying to
> figure out.
I must clarify. The MAC is picked up correctly, but I haven't gotten a
ping since the one time it worked.
One other thing odd I noticed is that, even if I just start io-pkt on
the command line, with no drivers whatsoever, it chews up 10% of the
CPU.
Any ideas?
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post17115
|
|
|
Alex Pavloff
|
Re: RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
|
Alex Pavloff
11/24/2008 12:48 PM
post17202
|
Re: RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
So if io-pkt taking 10% is an artifact of the measuring strategy, I think I'm good.
Taking a massive hack at the driver using a more recent one as a template appears to have made everything work the way
it's expected, both from a "respond to packets" as well as a "get the proper MAC address" behavior, which I blame on not
implementing the right devctl messages.
|
|
|
Robert Craig
|
RE: RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
|
Robert Craig
11/24/2008 12:51 PM
post17204
|
RE: RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
Hi Alex:
You can always double check with the instrumented kernel. We
did recently have a report that the stack was using slightly more CPU
than io-net (something like 1.5% instead of .5%) in the idle case and
this was due to a timer running at 10ms instead of 50 ms. We've changed
that in the source already.
Glad to hear that the driver is working for you now.
Robert.
-----Original Message-----
From: Alex Pavloff [mailto:community-noreply@qnx.com]
Sent: Monday, November 24, 2008 12:49 PM
To: drivers-networking
Subject: Re: RE: RE: RE: Xilinx devn-xemac not fully functioning with
shim layer
So if io-pkt taking 10% is an artifact of the measuring strategy, I
think I'm good.
Taking a massive hack at the driver using a more recent one as a
template appears to have made everything work the way it's expected,
both from a "respond to packets" as well as a "get the proper MAC
address" behavior, which I blame on not implementing the right devctl
messages.
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post17202
|
|
|
Alex Pavloff
|
Re: RE: RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
|
Alex Pavloff
11/26/2008 9:02 PM
post17438
|
Re: RE: RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
I will check that.
I have one more issue -- I'm unable to set the broadcast flag or broadcast address with ifconfig.
I configure the drivers with:
io-pkt-v4
waitfor /dev/socket/ 1
mount -T io-net -o mac=$XEMAC_MAC1,verbose devn-xemac.so
waitfor /dev/io-net/en0 1
ifconfig en0 $XEMAC_IP1
mount -T io-net -o mac=$XEMAC_MAC2,ioport=$XEMAC_IOPORT2,irq=$XEMAC_IRQ2,verbose devn-xemac.so
waitfor /dev/io-net/en1 1
ifconfig en1 $XEMAC_IP2 broadcast $XEMAC_IP2_BROADCAST
ifconfig returns with:
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192
inet 127.0.0.1 netmask 0xff000000
en0: flags=80000041<UP,RUNNING,SHIM> mtu 1500
address: 00:30:b2:ca:fe:99
inet 192.168.230.100 netmask 0xffffff00
en1: flags=80000041<UP,RUNNING,SHIM> mtu 1500
address: 00:30:b2:be:ef:44
inet 10.1.0.230 netmask 0xff000000
ifconfig en1 broadcast 10.1.0.255 (for example) has no effect, and the programs that are trying to broadcast ARP (and
fail the sendto call).
Is this the driver or something in ifconfig that I'm not understanding?
|
|
|
Sean Boudreau(deleted)
|
Re: RE: RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
|
Sean Boudreau(deleted)
11/27/2008 9:29 AM
post17463
|
Re: RE: RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
On Wed, Nov 26, 2008 at 09:02:41PM -0500, Alex Pavloff wrote:
> I will check that.
>
> I have one more issue -- I'm unable to set the broadcast flag or broadcast address with ifconfig.
>
> I configure the drivers with:
>
> io-pkt-v4
> waitfor /dev/socket/ 1
>
> mount -T io-net -o mac=$XEMAC_MAC1,verbose devn-xemac.so
> waitfor /dev/io-net/en0 1
> ifconfig en0 $XEMAC_IP1
>
> mount -T io-net -o mac=$XEMAC_MAC2,ioport=$XEMAC_IOPORT2,irq=$XEMAC_IRQ2,verbose devn-xemac.so
> waitfor /dev/io-net/en1 1
> ifconfig en1 $XEMAC_IP2 broadcast $XEMAC_IP2_BROADCAST
>
> ifconfig returns with:
>
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192
> inet 127.0.0.1 netmask 0xff000000
> en0: flags=80000041<UP,RUNNING,SHIM> mtu 1500
> address: 00:30:b2:ca:fe:99
> inet 192.168.230.100 netmask 0xffffff00
> en1: flags=80000041<UP,RUNNING,SHIM> mtu 1500
> address: 00:30:b2:be:ef:44
> inet 10.1.0.230 netmask 0xff000000
>
> ifconfig en1 broadcast 10.1.0.255 (for example) has no effect, and the programs that are trying to broadcast ARP (and
fail the sendto call).
>
> Is this the driver or something in ifconfig that I'm not understanding?
>
The stack doesn't think the interface supports broadcast
as IFF_BROADCAST isn't set. Is this flag still being set
in the driver's advertise packet? The source I have here
does:
int
xtemac_advertise(int reg_hdl, void *func_hdl)
{
...
...
io_net_msg_dl_advert_t *ap;
...
...
ap->iflags = IFF_SIMPLEX | IFF_BROADCAST | IFF_RUNNING /* |IFF_MULTICAST*/;
...
}
|
|
|
Alex Pavloff
|
Re: RE: RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
|
Alex Pavloff
12/01/2008 12:20 PM
post17655
|
Re: RE: RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
That's the "xtemac", which is similar, but the same line appears.
int
xemac_advertise(int reg_hdl, void *func_hdl)
{
...
ap->iflags = IFF_SIMPLEX | IFF_BROADCAST | IFF_RUNNING;
...
}
Multicast isn't there because that code wasn't finished in the xemac driver.
|
|
|
Alex Pavloff
|
Re: RE: RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
|
Alex Pavloff
12/01/2008 9:32 PM
post17701
|
Re: RE: RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
Replying to myself, the problem is fixed.
The advertise function wasn't being called.
Following the model of the other network driver I have (the mpc5200), I added a direct call to the advertise function
from the register_device function, and now all the flags are set properly and the broadcast is working.
|
|
|
Robert Craig
|
RE: RE: RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
|
Robert Craig
12/01/2008 9:50 PM
post17702
|
RE: RE: RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
Hi Alex:
Thanks for the update! It's good to have a thread finish off on a positive note.
Robert.
-----Original Message-----
From: Alex Pavloff [mailto:community-noreply@qnx.com]
Sent: Mon 12/1/2008 9:32 PM
To: drivers-networking
Subject: Re: RE: RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
Replying to myself, the problem is fixed.
The advertise function wasn't being called.
Following the model of the other network driver I have (the mpc5200), I added a direct call to the advertise function
from the register_device function, and now all the flags are set properly and the broadcast is working.
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post17701
|
|
|
Alex Pavloff
|
Re: RE: RE: RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
|
Alex Pavloff
12/02/2008 11:54 AM
post17764
|
Re: RE: RE: RE: RE: RE: Xilinx devn-xemac not fully functioning with shim layer
It just really bugs me when people show up with a GIANT PROBLEM, get some help, say "I'll try that", and never respond
as to whether or not their problem is fixed.
It's like a giant cliffhanger!
|
|
|
|