|
Mario Charest
05/01/2008 4:43 PM
post7577
|
Doesn't detect network speed, nicinfop shows unknown for network connection type and speed.
Same hardware works fine with io-net and related driver.
Device id is 10b9
|
|
|
|
|
|
Robert Craig
05/01/2008 5:48 PM
post7579
|
Hi Mario:
Just tried here with my card and it's the same type. I think the problem is
that you may not have "upped" the interface.
ifconfig wm0 up
Unlike io-net, in which the init routine is run at dll load time, the driver
initialization routine isn't executed until the interface is brought up.
The init routine in the io-pkt drivers is run pretty much every time you
re-configure the interface which gives you a lot more control of the
settings (e.g. you can now change the speed and duplex on a running
interface).
This may also be what's happening with the bge driver.
Robert.
-----Original Message-----
From: Mario Charest [mailto:mcharest@zinformatic.com]
Sent: Thursday, May 01, 2008 4:43 PM
To: drivers-networking
Subject: devnp-i82544.so M1
Doesn't detect network speed, nicinfop shows unknown for network connection
type and speed.
Same hardware works fine with io-net and related driver.
Device id is 10b9
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post7577
|
|
|
|
|
|
Mario Charest
|
Re: RE: devnp-i82544.so M1
|
|
Mario Charest
05/02/2008 8:53 AM
post7584
|
Re: RE: devnp-i82544.so M1
> Hi Mario:
>
> Just tried here with my card and it's the same type. I think the problem is
> that you may not have "upped" the interface.
Before I up the interface nicinfo show the type to be unknown after upping it it show "0 half-duplex". After that
nothing seems to be happening.
What I find odd is that the /net directory is empty. With io-net even if there is no network it at least show itself.
>
> ifconfig wm0 up
>
> Unlike io-net, in which the init routine is run at dll load time, the driver
> initialization routine isn't executed until the interface is brought up.
>
> The init routine in the io-pkt drivers is run pretty much every time you
> re-configure the interface which gives you a lot more control of the
> settings (e.g. you can now change the speed and duplex on a running
> interface).
>
> This may also be what's happening with the bge driver.
>
> Robert.
>
> -----Original Message-----
> From: Mario Charest [mailto:mcharest@zinformatic.com]
> Sent: Thursday, May 01, 2008 4:43 PM
> To: drivers-networking
> Subject: devnp-i82544.so M1
>
>
> Doesn't detect network speed, nicinfop shows unknown for network connection
> type and speed.
>
> Same hardware works fine with io-net and related driver.
>
> Device id is 10b9
>
>
>
> _______________________________________________
> Networking Drivers
> http://community.qnx.com/sf/go/post7577
|
|
|
|
|
|
Robert Craig
|
RE: RE: devnp-i82544.so M1
|
|
Robert Craig
05/02/2008 10:46 AM
post7602
|
RE: RE: devnp-i82544.so M1
Hi Mario:
The new stack driver model is tightly aligned with the NetBSD
implementation. As a result, we don't create driver mount points anymore.
All driver configuration transactions are handled through the stack (see
http://community.qnx.com/sf/wiki/do/viewPage/projects.networking/wiki/IoNet_
migration )
There's definitely something missing here since I have that same card (PCI
Express Intel Pro 1000/PT) and it works fine.
Robert.
-----Original Message-----
From: Mario Charest [mailto:mcharest@zinformatic.com]
Sent: Friday, May 02, 2008 8:54 AM
To: drivers-networking
Subject: Re: RE: devnp-i82544.so M1
> Hi Mario:
>
> Just tried here with my card and it's the same type. I think the problem
is
> that you may not have "upped" the interface.
Before I up the interface nicinfo show the type to be unknown after upping
it it show "0 half-duplex". After that nothing seems to be happening.
What I find odd is that the /net directory is empty. With io-net even if
there is no network it at least show itself.
>
> ifconfig wm0 up
>
> Unlike io-net, in which the init routine is run at dll load time, the
driver
> initialization routine isn't executed until the interface is brought up.
>
> The init routine in the io-pkt drivers is run pretty much every time you
> re-configure the interface which gives you a lot more control of the
> settings (e.g. you can now change the speed and duplex on a running
> interface).
>
> This may also be what's happening with the bge driver.
>
> Robert.
>
> -----Original Message-----
> From: Mario Charest [mailto:mcharest@zinformatic.com]
> Sent: Thursday, May 01, 2008 4:43 PM
> To: drivers-networking
> Subject: devnp-i82544.so M1
>
>
> Doesn't detect network speed, nicinfop shows unknown for network
connection
> type and speed.
>
> Same hardware works fine with io-net and related driver.
>
> Device id is 10b9
>
>
>
> _______________________________________________
> Networking Drivers
> http://community.qnx.com/sf/go/post7577
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post7584
|
|
|
|
|
|
Mario Charest
|
Re: RE: RE: devnp-i82544.so M1
|
|
Mario Charest
05/02/2008 1:08 PM
post7612
|
Re: RE: RE: devnp-i82544.so M1
> Hi Mario:
> The new stack driver model is tightly aligned with the NetBSD
> implementation. As a result, we don't create driver mount points anymore.
> All driver configuration transactions are handled through the stack (see
> http://community.qnx.com/sf/wiki/do/viewPage/projects.networking/wiki/IoNet_>; migration )
How does that related to /net being empty.
>
> There's definitely something missing here since I have that same card (PCI
> Express Intel Pro 1000/PT) and it works fine.
Yeah.
I had the wrong libsocket version ( I used the one I build myself ). Updating to the M1 version had helped a bit.
With 82544 nicinfo shows the 0 Half-Duplex and that the link is down. Yet I now get RX packet. But after about 500
packets the number of dropped packet start increasing.
If I ping a machine I can see the Transmit count increasing.
wm0:
INTEL 82544 Gigabit (Copper) Ethernet Controller
Link is DOWN
Physical Node ID ........................... 001B21 006E5E
Current Physical Node ID ................... 001B21 006E5E
Current Operation Rate ..................... 0 kb/s half-duplex
Active Interface Type ...................... MII
Active PHY address ....................... 0
Maximum Transmittable data Unit ............ 1500
Maximum Receivable data Unit ............... 0
Hardware Interrupt ......................... 0x7
Memory Aperture ............................ 0xd0120000 - 0xd013ffff
Promiscuous Mode ........................... Off
Multicast Support .......................... Enabled
Packets Transmitted OK ..................... 3
Bytes Transmitted OK ....................... 192
Broadcast Packets Transmitted OK ........... 3
Multicast Packets Transmitted OK ........... 0
Memory Allocation Failures on Transmit ..... 0
Packets Received OK ........................ 540
Bytes Received OK .......................... 43153
Broadcast Packets Received OK .............. 367
Multicast Packets Received OK .............. 2
Memory Allocation Failures on Receive ...... 0
Single Collisions on Transmit .............. 0
Multiple Collisions on Transmit ............ 0
Deferred Transmits ......................... 0
Late Collision on Transmit errors .......... 0
Transmits aborted (excessive collisions) ... 0
Jabber detected ............................ 0
Receive Alignment errors ................... 0
Received packets with CRC errors ........... 0
Packets Dropped on receive ................. 29
Oversized Packets received ................. 0
Short packets .............................. 0
Squelch Test errors ........................ 0
Invalid Symbol Errors ......................
Here is the syslog
bge0 at pci1 dev 0 function 0: Broadcom BCM5721 Gigabit Ethernet
May 03 00:05:17 5 14 0 bge0: interrupting at irq 7
May 03 00:05:17 5 14 0 bge0: pcie mode=0x105000
May 03 00:05:17 5 14 0 bge0: ASIC unknown BCM575x family (0x4201), Ethernet address 00:1a:64:6f:45:7f
May 03 00:05:17 5 14 0 bge0: setting short Tx thresholds
May 03 00:05:17 5 14 0 Find PHY, oui = 00001018, model = 00000018
May 03 00:05:17 5 14 0 ukphy0 at bge0 phy 1: Generic IEEE 802.3u media interface
May 03 00:05:17 5 14 0 ukphy0: OUI 0x001018, model 0x0018, rev. 0
May 03 00:05:17 5 14 0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
May 03 00:05:17 5 14 0 bge1 at pci3 dev 0 function 0: Broadcom BCM5721 Gigabit Ethernet
May 03 00:05:17 5 14 0 bge1: interrupting at irq 10
May 03 00:05:18 5 14 0 bge1: pcie mode=0x105000
May 03 00:05:18 5 14 0 bge1: ASIC unknown BCM575x family (0x4201), Ethernet address 00:1a:64:6f:45:80
May 03 00:05:18 5 14 0 bge1: setting short Tx thresholds
May 03 00:05:18 5 14 0 Find PHY, oui = 00001018, model...
View Full Message
|
|
|
|
|
|
Robert Craig
05/02/2008 1:30 PM
post7614
|
/net is empty because io-pkt drivers simply don't create /dev/io-net/???
entries any more. You'll see entries if you run an io-net driver inside of
io-pkt, but never for a native / NetBSD style driver. There's still a
/dev/socket created for IP though.
Hmmm... Just to confirm, what's the checksum for your driver?
cksum devnp-i82544.so
558885883 38292 devnp-i82544.so
What does ifconfig report for the interface?
I wonder if there's something else being mismatched in the build... Is it
possible to put the whole milestone build on your target and create the
appropriate environment vars to use it?
Script to change the vars would look something like this:
#!/bin/sh
export
LD_LIBRARY_PATH=$HOME/patches/630SP3-CN-Milestone-1/target/qnx6/x86/lib:$HOM
E/patches/630SP3-CN-Milestone-1/target/qnx6/x86/lib/dll:$LD_LIBRARY_PATH
export
PATH=$HOME/patches/630SP3-CN-Milestone-1/target/qnx6stage/x86/bin:$HOME/patc
hes/630SP3-CN-Milestone-1/target/qnx6/x86/sbin:\
$HOME/patches/630SP3-CN-Milestone-1/target/qnx6/x86/usr/bin:$HOME/patches/63
0SP3-CN-Milestone-1/target/qnx6/x86/usr/sbin:$PATH
Robert.
-----Original Message-----
From: Mario Charest [mailto:mcharest@zinformatic.com]
Sent: Friday, May 02, 2008 1:08 PM
To: drivers-networking
Subject: Re: RE: RE: devnp-i82544.so M1
> Hi Mario:
> The new stack driver model is tightly aligned with the NetBSD
> implementation. As a result, we don't create driver mount points anymore.
> All driver configuration transactions are handled through the stack (see
>
http://community.qnx.com/sf/wiki/do/viewPage/projects.networking/wiki/IoNet_
> migration )
How does that related to /net being empty.
>
> There's definitely something missing here since I have that same card (PCI
> Express Intel Pro 1000/PT) and it works fine.
Yeah.
I had the wrong libsocket version ( I used the one I build myself ).
Updating to the M1 version had helped a bit.
With 82544 nicinfo shows the 0 Half-Duplex and that the link is down. Yet I
now get RX packet. But after about 500 packets the number of dropped packet
start increasing.
If I ping a machine I can see the Transmit count increasing.
wm0:
INTEL 82544 Gigabit (Copper) Ethernet Controller
Link is DOWN
Physical Node ID ........................... 001B21 006E5E
Current Physical Node ID ................... 001B21 006E5E
Current Operation Rate ..................... 0 kb/s half-duplex
Active Interface Type ...................... MII
Active PHY address ....................... 0
Maximum Transmittable data Unit ............ 1500
Maximum Receivable data Unit ............... 0
Hardware Interrupt ......................... 0x7
Memory Aperture ............................ 0xd0120000 - 0xd013ffff
Promiscuous Mode ........................... Off
Multicast Support .......................... Enabled
Packets Transmitted OK ..................... 3
Bytes Transmitted OK ....................... 192
Broadcast Packets Transmitted OK ........... 3
Multicast Packets Transmitted OK ........... 0
Memory Allocation Failures on Transmit ..... 0
Packets Received OK ........................ 540
Bytes Received OK .......................... 43153
Broadcast Packets Received OK .............. 367
Multicast Packets Received OK .............. 2
Memory Allocation Failures on Receive ...... 0
Single Collisions on Transmit .............. 0
Multiple Collisions on Transmit ............ 0
Deferred Transmits ......................... 0
Late Collision on Transmit errors .......... 0
Transmits aborted (excessive collisions) ... 0
Jabber detected ............................ 0
Receive Alignment errors ................... 0
Received packets with CRC errors ........... 0
Packets Dropped on receive ................. 29
Oversized Packets received ................. 0
Short packets...
View Full Message
|
|
|
|
|
|
Mario Charest
|
Re: RE: devnp-i82544.so M1
|
|
Mario Charest
05/02/2008 2:39 PM
post7616
|
Re: RE: devnp-i82544.so M1
>
> /net is empty because io-pkt drivers simply don't create /dev/io-net/???
> entries any more. You'll see entries if you run an io-net driver inside of
> io-pkt, but never for a native / NetBSD style driver. There's still a
> /dev/socket created for IP though.
Are you saying that if i do ls /net I won't see the other machine's name?
>
> Hmmm... Just to confirm, what's the checksum for your driver?
>
> cksum devnp-i82544.so
> 558885883 38292 devnp-i82544.so
Yes it's the same
>
> What does ifconfig report for the interface?
>
> I wonder if there's something else being mismatched in the build... Is it
> possible to put the whole milestone build on your target and create the
> appropriate environment vars to use it?
Something is definitely odd, I used devn-i82544.so ( through shim ) and I get the same behavior. But with io-net it
works fine.
I'm using 6.4 M6 for the OS.
>
> Script to change the vars would look something like this:
This will take some work ( it's a custom image ) but I'll see what I can do.
>
> #!/bin/sh
> export
> LD_LIBRARY_PATH=$HOME/patches/630SP3-CN-Milestone-1/target/qnx6/x86/lib:$HOM
> E/patches/630SP3-CN-Milestone-1/target/qnx6/x86/lib/dll:$LD_LIBRARY_PATH
> export
> PATH=$HOME/patches/630SP3-CN-Milestone-1/target/qnx6stage/x86/bin:$HOME/patc
> hes/630SP3-CN-Milestone-1/target/qnx6/x86/sbin:\
> $HOME/patches/630SP3-CN-Milestone-1/target/qnx6/x86/usr/bin:$HOME/patches/63
> 0SP3-CN-Milestone-1/target/qnx6/x86/usr/sbin:$PATH
>
> Robert.
>
>
> -----Original Message-----
> From: Mario Charest [mailto:mcharest@zinformatic.com]
> Sent: Friday, May 02, 2008 1:08 PM
> To: drivers-networking
> Subject: Re: RE: RE: devnp-i82544.so M1
>
> > Hi Mario:
> > The new stack driver model is tightly aligned with the NetBSD
> > implementation. As a result, we don't create driver mount points anymore.
>
> > All driver configuration transactions are handled through the stack (see
> >
> http://community.qnx.com/sf/wiki/do/viewPage/projects.networking/wiki/IoNet_
> > migration )
>
> How does that related to /net being empty.
>
> >
> > There's definitely something missing here since I have that same card (PCI
> > Express Intel Pro 1000/PT) and it works fine.
>
> Yeah.
>
> I had the wrong libsocket version ( I used the one I build myself ).
> Updating to the M1 version had helped a bit.
>
> With 82544 nicinfo shows the 0 Half-Duplex and that the link is down. Yet I
> now get RX packet. But after about 500 packets the number of dropped packet
> start increasing.
>
> If I ping a machine I can see the Transmit count increasing.
>
> wm0:
> INTEL 82544 Gigabit (Copper) Ethernet Controller
>
> Link is DOWN
>
> Physical Node ID ........................... 001B21 006E5E
> Current Physical Node ID ................... 001B21 006E5E
> Current Operation Rate ..................... 0 kb/s half-duplex
> Active Interface Type ...................... MII
> Active PHY address ....................... 0
> Maximum Transmittable data Unit ............ 1500
> Maximum Receivable data Unit ............... 0
> Hardware Interrupt ......................... 0x7
> Memory Aperture ............................ 0xd0120000 - 0xd013ffff
> Promiscuous Mode ........................... Off
> Multicast Support .......................... Enabled
>
> Packets Transmitted OK ..................... 3
> Bytes Transmitted OK ....................... 192
> Broadcast Packets Transmitted OK ........... 3
> Multicast Packets Transmitted OK ........... 0
> Memory Allocation Failures on Transmit ..... 0
>
>...
View Full Message
|
|
|
|
|
|
Robert Craig
|
RE: RE: devnp-i82544.so M1
|
|
Robert Craig
05/02/2008 2:44 PM
post7617
|
RE: RE: devnp-i82544.so M1
I wonder if we have some sort of weird build compatibility issue here. The
milestone build was built against 6.3.2 so it SHOULD be binary compatible
with 6.4.0. I haven't tried the milestone build out against 6.4... Looks
like I should do so.
Out of curiosity... o you have a 6.3.x system easily accessible that you can
try out?
Robert.
-----Original Message-----
From: Mario Charest [mailto:mcharest@zinformatic.com]
Sent: Friday, May 02, 2008 2:39 PM
To: drivers-networking
Subject: Re: RE: devnp-i82544.so M1
>
> /net is empty because io-pkt drivers simply don't create /dev/io-net/???
> entries any more. You'll see entries if you run an io-net driver inside
of
> io-pkt, but never for a native / NetBSD style driver. There's still a
> /dev/socket created for IP though.
Are you saying that if i do ls /net I won't see the other machine's name?
>
> Hmmm... Just to confirm, what's the checksum for your driver?
>
> cksum devnp-i82544.so
> 558885883 38292 devnp-i82544.so
Yes it's the same
>
> What does ifconfig report for the interface?
>
> I wonder if there's something else being mismatched in the build... Is it
> possible to put the whole milestone build on your target and create the
> appropriate environment vars to use it?
Something is definitely odd, I used devn-i82544.so ( through shim ) and I
get the same behavior. But with io-net it works fine.
I'm using 6.4 M6 for the OS.
>
> Script to change the vars would look something like this:
This will take some work ( it's a custom image ) but I'll see what I can do.
>
> #!/bin/sh
> export
>
LD_LIBRARY_PATH=$HOME/patches/630SP3-CN-Milestone-1/target/qnx6/x86/lib:$HOM
> E/patches/630SP3-CN-Milestone-1/target/qnx6/x86/lib/dll:$LD_LIBRARY_PATH
> export
>
PATH=$HOME/patches/630SP3-CN-Milestone-1/target/qnx6stage/x86/bin:$HOME/patc
> hes/630SP3-CN-Milestone-1/target/qnx6/x86/sbin:\
>
$HOME/patches/630SP3-CN-Milestone-1/target/qnx6/x86/usr/bin:$HOME/patches/63
> 0SP3-CN-Milestone-1/target/qnx6/x86/usr/sbin:$PATH
>
> Robert.
>
>
> -----Original Message-----
> From: Mario Charest [mailto:mcharest@zinformatic.com]
> Sent: Friday, May 02, 2008 1:08 PM
> To: drivers-networking
> Subject: Re: RE: RE: devnp-i82544.so M1
>
> > Hi Mario:
> > The new stack driver model is tightly aligned with the NetBSD
> > implementation. As a result, we don't create driver mount points
anymore.
>
> > All driver configuration transactions are handled through the stack (see
> >
>
http://community.qnx.com/sf/wiki/do/viewPage/projects.networking/wiki/IoNet_
> > migration )
>
> How does that related to /net being empty.
>
> >
> > There's definitely something missing here since I have that same card
(PCI
> > Express Intel Pro 1000/PT) and it works fine.
>
> Yeah.
>
> I had the wrong libsocket version ( I used the one I build myself ).
> Updating to the M1 version had helped a bit.
>
> With 82544 nicinfo shows the 0 Half-Duplex and that the link is down. Yet
I
> now get RX packet. But after about 500 packets the number of dropped
packet
> start increasing.
>
> If I ping a machine I can see the Transmit count increasing.
>
> wm0:
> INTEL 82544 Gigabit (Copper) Ethernet Controller
>
> Link is DOWN
>
> Physical Node ID ........................... 001B21 006E5E
> Current Physical Node ID ................... 001B21 006E5E
> Current Operation Rate ..................... 0 kb/s half-duplex
> Active Interface Type ...................... MII
> Active PHY address ....................... 0
> Maximum Transmittable data Unit ............ 1500
> Maximum Receivable data Unit...
View Full Message
|
|
|
|
|
|
Robert Craig
|
RE: RE: devnp-i82544.so M1
|
|
Robert Craig
05/02/2008 3:09 PM
post7621
|
RE: RE: devnp-i82544.so M1
Just realized I missed out on the /net question.
As soon as you said "ls" I realized that you were talking about QNET and not
the drivers. QNET operates in exactly the same way as before, so if you're
not seeing a /net entry, qnet isn't working properly. Given the fact that
the drivers are obviously not working, let's concentrate on that first.
Robert.
-----Original Message-----
From: Mario Charest [mailto:mcharest@zinformatic.com]
Sent: Friday, May 02, 2008 2:39 PM
To: drivers-networking
Subject: Re: RE: devnp-i82544.so M1
>
> /net is empty because io-pkt drivers simply don't create /dev/io-net/???
> entries any more. You'll see entries if you run an io-net driver inside
of
> io-pkt, but never for a native / NetBSD style driver. There's still a
> /dev/socket created for IP though.
Are you saying that if i do ls /net I won't see the other machine's name?
>
> Hmmm... Just to confirm, what's the checksum for your driver?
>
> cksum devnp-i82544.so
> 558885883 38292 devnp-i82544.so
Yes it's the same
>
> What does ifconfig report for the interface?
>
> I wonder if there's something else being mismatched in the build... Is it
> possible to put the whole milestone build on your target and create the
> appropriate environment vars to use it?
Something is definitely odd, I used devn-i82544.so ( through shim ) and I
get the same behavior. But with io-net it works fine.
I'm using 6.4 M6 for the OS.
>
> Script to change the vars would look something like this:
This will take some work ( it's a custom image ) but I'll see what I can do.
>
> #!/bin/sh
> export
>
LD_LIBRARY_PATH=$HOME/patches/630SP3-CN-Milestone-1/target/qnx6/x86/lib:$HOM
> E/patches/630SP3-CN-Milestone-1/target/qnx6/x86/lib/dll:$LD_LIBRARY_PATH
> export
>
PATH=$HOME/patches/630SP3-CN-Milestone-1/target/qnx6stage/x86/bin:$HOME/patc
> hes/630SP3-CN-Milestone-1/target/qnx6/x86/sbin:\
>
$HOME/patches/630SP3-CN-Milestone-1/target/qnx6/x86/usr/bin:$HOME/patches/63
> 0SP3-CN-Milestone-1/target/qnx6/x86/usr/sbin:$PATH
>
> Robert.
>
>
> -----Original Message-----
> From: Mario Charest [mailto:mcharest@zinformatic.com]
> Sent: Friday, May 02, 2008 1:08 PM
> To: drivers-networking
> Subject: Re: RE: RE: devnp-i82544.so M1
>
> > Hi Mario:
> > The new stack driver model is tightly aligned with the NetBSD
> > implementation. As a result, we don't create driver mount points
anymore.
>
> > All driver configuration transactions are handled through the stack (see
> >
>
http://community.qnx.com/sf/wiki/do/viewPage/projects.networking/wiki/IoNet_
> > migration )
>
> How does that related to /net being empty.
>
> >
> > There's definitely something missing here since I have that same card
(PCI
> > Express Intel Pro 1000/PT) and it works fine.
>
> Yeah.
>
> I had the wrong libsocket version ( I used the one I build myself ).
> Updating to the M1 version had helped a bit.
>
> With 82544 nicinfo shows the 0 Half-Duplex and that the link is down. Yet
I
> now get RX packet. But after about 500 packets the number of dropped
packet
> start increasing.
>
> If I ping a machine I can see the Transmit count increasing.
>
> wm0:
> INTEL 82544 Gigabit (Copper) Ethernet Controller
>
> Link is DOWN
>
> Physical Node ID ........................... 001B21 006E5E
> Current Physical Node ID ................... 001B21 006E5E
> Current Operation Rate ..................... 0 kb/s half-duplex
> Active Interface Type ...................... MII
> Active PHY address ....................... 0
> Maximum Transmittable data Unit ............ 1500
> Maximum Receivable data Unit...
View Full Message
|
|
|
|
|
|
Mario Charest
|
Re: RE: RE: devnp-i82544.so M1
|
|
Mario Charest
05/02/2008 4:06 PM
post7632
|
Re: RE: RE: devnp-i82544.so M1
> Just realized I missed out on the /net question.
>
> As soon as you said "ls" I realized that you were talking about QNET and not
> the drivers. QNET operates in exactly the same way as before, so if you're
> not seeing a /net entry, qnet isn't working properly. Given the fact that
> the drivers are obviously not working, let's concentrate on that first.
Got it.
I was using io-pkt -pqnet -ptcpip -i82544 but it seems the order is very important. Once I started doing io-pkt -i82544
-pqnet -ptcpip everything started to work.
|
|
|
|
|
|
Robert Craig
05/02/2008 4:50 PM
post7635
|
I just tried the command line that you gave and funnily enough the driver
seems to work fine for me.
There's some initial fluctuation of the PHY (takes a few seconds for the
auto-negotiation to kick in) in which I see the 0 / half negotiation, but
that soon fixes itself and I end up with a completely operational interface
after that (just flood pinged a couple of million packets with no dropped
packets). So IP is good.
HOWEVER, qnet doesn't work. /net is empty.
The "-ptcpip" doesn't do anything in this case since the IP stack is already
compiled into io-pkt (you really only need it if you want to pass in options
to the IP stack), so there's definitely something strange going on there.
This seems to be a generic QNET problem. If you don't have an interface
loaded when qnet is loaded it doesn't seem to pick up on any new interface
loaded afterwards. It happens with mount as well. If you start io-pkt-v4
-pqnet and subsequently mount a driver, qnet doesn't kick in.
PR generated (57806)... Thanks for digging into that one for us!
Robert.
-----Original Message-----
From: Mario Charest [mailto:mcharest@zinformatic.com]
Sent: Friday, May 02, 2008 4:07 PM
To: drivers-networking
Subject: Re: RE: RE: devnp-i82544.so M1
> Just realized I missed out on the /net question.
>
> As soon as you said "ls" I realized that you were talking about QNET and
not
> the drivers. QNET operates in exactly the same way as before, so if
you're
> not seeing a /net entry, qnet isn't working properly. Given the fact that
> the drivers are obviously not working, let's concentrate on that first.
Got it.
I was using io-pkt -pqnet -ptcpip -i82544 but it seems the order is very
important. Once I started doing io-pkt -i82544 -pqnet -ptcpip everything
started to work.
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post7632
|
|
|
|
|
|
