Problem booting with Intel82559 driver + host on different subnet

Problem booting with Intel82559 driver + host on different subnet

Post by James Marshal » Sat, 23 Dec 2000 05:10:05



Hi Everyone.

I'm using the Intel 82559ER-supporting VxWorks driver to boot a PC target from a
host on a different subnet and getting nowhere.

My target is on 10.225.0.158:ffffff00 (255.255.255.0) and the host is on
15.144.180.226:fffff000 (255.255.240.0). Both are subnetted Class A addresses.
When I add the gateway parameter, g=10.225.0.1, the bootConfig.c code adds a
route [with routeAdd()] to 15.0.0.0 through this gateway, ignoring the netmask.

When I use the BSD/SENS variant of the driver (version 1.00.05) I just get the
"Loading..." prompt and nothing else. The target doesn't respond to pings at any
time.

When I use the MUX/END variant of the driver (version 1.00.01) I get the
"Loading..." prompt, the first number (text size) then nothing. The target
responds to pings until the text size displays, then stops. I have to leave the
network cable unplugged until "Loading..." appears (see also Further Info at the
end) otherwise I get the message "Panic: where are those rfd buffers" printed
out regularly. *Very occasionally* the pings continue to get through after the
text size displays, but only every 4th ping comes back and with a response of
about 1600ms instead of the usual 0-10ms. The two times that this happened, the
TCP link used by rcmd() *eventually* loaded all the main image and started
VxWorks.

When the target and host are on the same subnet, booting over the LAN works fine
as expected.

Further Info:
- there is 30-50 packets/sec broadcast traffic on the LAN.
- the physical (ie. layer 2) network carries traffic for both logical (layer 3)
IP networks. This means we can make the gateway parameter g=10.225.0.158 - the
same as the target's IP address - so the correct 15.x.x.x packets are generated
directly on the wire by the stack. But it's a shortcut and doesn't appear to
affect the lack of bootloading.
- the symptoms are the same when using the same driver on an 82558 LAN
controller.
- I can use the WindRiver FEI END driver with the 82558 and boot successfully
with target and host on different subnets.
- although the main image is just over 2MB (2,122,344 bytes), it does boot
successfully in other scenarios.
- I've tried replacing the routeAdd() used by bootConfig.c with mRouteAdd(). The
behaviour with netmasks seems to be broken in different and confusing ways, but
it still works with another driver so this shouldn't be stopping bootloading.

I know it's close to Christmas but this scenario needs to work when we come back
next year so if you're feeling bored over the next week...

Best Regards
James.

 
 
 

Problem booting with Intel82559 driver + host on different subnet

Post by James Marshal » Sat, 23 Dec 2000 21:44:33


Guess what? I went back to using WindRiver's FEI END driver and just added another
line to sys557PciInit() so it accepts the 82559ER's PCI device ID (0x1209) as well
as the 82557/8/9's (0x1229).

And it just works!

The answer seems to be do not use Intel's driver in the VxWorks boot image.

Merry Christmas!

James.


> Hi Everyone.

> I'm using the Intel 82559ER-supporting VxWorks driver to boot a PC target from a
> host on a different subnet and getting nowhere.

> My target is on 10.225.0.158:ffffff00 (255.255.255.0) and the host is on
> 15.144.180.226:fffff000 (255.255.240.0). Both are subnetted Class A addresses.
> When I add the gateway parameter, g=10.225.0.1, the bootConfig.c code adds a
> route [with routeAdd()] to 15.0.0.0 through this gateway, ignoring the netmask.

> When I use the BSD/SENS variant of the driver (version 1.00.05) I just get the
> "Loading..." prompt and nothing else. The target doesn't respond to pings at any
> time.

> When I use the MUX/END variant of the driver (version 1.00.01) I get the
> "Loading..." prompt, the first number (text size) then nothing. The target
> responds to pings until the text size displays, then stops. I have to leave the
> network cable unplugged until "Loading..." appears (see also Further Info at the
> end) otherwise I get the message "Panic: where are those rfd buffers" printed
> out regularly. *Very occasionally* the pings continue to get through after the
> text size displays, but only every 4th ping comes back and with a response of
> about 1600ms instead of the usual 0-10ms. The two times that this happened, the
> TCP link used by rcmd() *eventually* loaded all the main image and started
> VxWorks.

> When the target and host are on the same subnet, booting over the LAN works fine
> as expected.

> Further Info:
> - there is 30-50 packets/sec broadcast traffic on the LAN.
> - the physical (ie. layer 2) network carries traffic for both logical (layer 3)
> IP networks. This means we can make the gateway parameter g=10.225.0.158 - the
> same as the target's IP address - so the correct 15.x.x.x packets are generated
> directly on the wire by the stack. But it's a shortcut and doesn't appear to
> affect the lack of bootloading.
> - the symptoms are the same when using the same driver on an 82558 LAN
> controller.
> - I can use the WindRiver FEI END driver with the 82558 and boot successfully
> with target and host on different subnets.
> - although the main image is just over 2MB (2,122,344 bytes), it does boot
> successfully in other scenarios.
> - I've tried replacing the routeAdd() used by bootConfig.c with mRouteAdd(). The
> behaviour with netmasks seems to be broken in different and confusing ways, but
> it still works with another driver so this shouldn't be stopping bootloading.

> I know it's close to Christmas but this scenario needs to work when we come back
> next year so if you're feeling bored over the next week...

> Best Regards
> James.


 
 
 

Problem booting with Intel82559 driver + host on different subnet

Post by James Marshal » Thu, 04 Jan 2001 17:51:37


One drawback: the "fei" driver doesn't seem to recognise the 82559ER PHY properly
because it forces the link to 10M/half duplex.

Haven't yet found any other ways that it's broken.

James.


> Guess what? I went back to using WindRiver's FEI END driver and just added another
> line to sys557PciInit() so it accepts the 82559ER's PCI device ID (0x1209) as well
> as the 82557/8/9's (0x1229).

> And it just works!

> The answer seems to be do not use Intel's driver in the VxWorks boot image.

> Merry Christmas!

> James.


> > Hi Everyone.

> > I'm using the Intel 82559ER-supporting VxWorks driver to boot a PC target from a
> > host on a different subnet and getting nowhere.

> > My target is on 10.225.0.158:ffffff00 (255.255.255.0) and the host is on
> > 15.144.180.226:fffff000 (255.255.240.0). Both are subnetted Class A addresses.
> > When I add the gateway parameter, g=10.225.0.1, the bootConfig.c code adds a
> > route [with routeAdd()] to 15.0.0.0 through this gateway, ignoring the netmask.

> > When I use the BSD/SENS variant of the driver (version 1.00.05) I just get the
> > "Loading..." prompt and nothing else. The target doesn't respond to pings at any
> > time.

> > When I use the MUX/END variant of the driver (version 1.00.01) I get the
> > "Loading..." prompt, the first number (text size) then nothing. The target
> > responds to pings until the text size displays, then stops. I have to leave the
> > network cable unplugged until "Loading..." appears (see also Further Info at the
> > end) otherwise I get the message "Panic: where are those rfd buffers" printed
> > out regularly. *Very occasionally* the pings continue to get through after the
> > text size displays, but only every 4th ping comes back and with a response of
> > about 1600ms instead of the usual 0-10ms. The two times that this happened, the
> > TCP link used by rcmd() *eventually* loaded all the main image and started
> > VxWorks.

> > When the target and host are on the same subnet, booting over the LAN works fine
> > as expected.

> > Further Info:
> > - there is 30-50 packets/sec broadcast traffic on the LAN.
> > - the physical (ie. layer 2) network carries traffic for both logical (layer 3)
> > IP networks. This means we can make the gateway parameter g=10.225.0.158 - the
> > same as the target's IP address - so the correct 15.x.x.x packets are generated
> > directly on the wire by the stack. But it's a shortcut and doesn't appear to
> > affect the lack of bootloading.
> > - the symptoms are the same when using the same driver on an 82558 LAN
> > controller.
> > - I can use the WindRiver FEI END driver with the 82558 and boot successfully
> > with target and host on different subnets.
> > - although the main image is just over 2MB (2,122,344 bytes), it does boot
> > successfully in other scenarios.
> > - I've tried replacing the routeAdd() used by bootConfig.c with mRouteAdd(). The
> > behaviour with netmasks seems to be broken in different and confusing ways, but
> > it still works with another driver so this shouldn't be stopping bootloading.

> > I know it's close to Christmas but this scenario needs to work when we come back
> > next year so if you're feeling bored over the next week...

> > Best Regards
> > James.

 
 
 

Problem booting with Intel82559 driver + host on different subnet

Post by James Marshal » Sat, 06 Jan 2001 22:55:15


One drawback: the "fei" driver doesn't seem to recognise the 82559ER PHY properly
because it forces the link to 10M/half duplex.

Haven't yet found any other ways that it's broken.

James.


> Guess what? I went back to using WindRiver's FEI END driver and just added another
> line to sys557PciInit() so it accepts the 82559ER's PCI device ID (0x1209) as well
> as the 82557/8/9's (0x1229).

> And it just works!

> The answer seems to be do not use Intel's driver in the VxWorks boot image.

> Merry Christmas!

> James.


> > Hi Everyone.

> > I'm using the Intel 82559ER-supporting VxWorks driver to boot a PC target from a
> > host on a different subnet and getting nowhere.

> > My target is on 10.225.0.158:ffffff00 (255.255.255.0) and the host is on
> > 15.144.180.226:fffff000 (255.255.240.0). Both are subnetted Class A addresses.
> > When I add the gateway parameter, g=10.225.0.1, the bootConfig.c code adds a
> > route [with routeAdd()] to 15.0.0.0 through this gateway, ignoring the netmask.

> > When I use the BSD/SENS variant of the driver (version 1.00.05) I just get the
> > "Loading..." prompt and nothing else. The target doesn't respond to pings at any
> > time.

> > When I use the MUX/END variant of the driver (version 1.00.01) I get the
> > "Loading..." prompt, the first number (text size) then nothing. The target
> > responds to pings until the text size displays, then stops. I have to leave the
> > network cable unplugged until "Loading..." appears (see also Further Info at the
> > end) otherwise I get the message "Panic: where are those rfd buffers" printed
> > out regularly. *Very occasionally* the pings continue to get through after the
> > text size displays, but only every 4th ping comes back and with a response of
> > about 1600ms instead of the usual 0-10ms. The two times that this happened, the
> > TCP link used by rcmd() *eventually* loaded all the main image and started
> > VxWorks.

> > When the target and host are on the same subnet, booting over the LAN works fine
> > as expected.

> > Further Info:
> > - there is 30-50 packets/sec broadcast traffic on the LAN.
> > - the physical (ie. layer 2) network carries traffic for both logical (layer 3)
> > IP networks. This means we can make the gateway parameter g=10.225.0.158 - the
> > same as the target's IP address - so the correct 15.x.x.x packets are generated
> > directly on the wire by the stack. But it's a shortcut and doesn't appear to
> > affect the lack of bootloading.
> > - the symptoms are the same when using the same driver on an 82558 LAN
> > controller.
> > - I can use the WindRiver FEI END driver with the 82558 and boot successfully
> > with target and host on different subnets.
> > - although the main image is just over 2MB (2,122,344 bytes), it does boot
> > successfully in other scenarios.
> > - I've tried replacing the routeAdd() used by bootConfig.c with mRouteAdd(). The
> > behaviour with netmasks seems to be broken in different and confusing ways, but
> > it still works with another driver so this shouldn't be stopping bootloading.

> > I know it's close to Christmas but this scenario needs to work when we come back
> > next year so if you're feeling bored over the next week...

> > Best Regards
> > James.

 
 
 

Problem booting with Intel82559 driver + host on different subnet

Post by James Marshal » Sat, 13 Jan 2001 00:34:27


The 10M half duplex link problem was due to the higher system tick rate we use. The fei
driver has delays specified in ticks instead of scaled by sysClkRateGet(). This was why
it worked okay in the boot image with the system tick rate unchanged from its default of
60Hz, and failed in our main image.

This problem has been fixed by the WindRiver support guys (thanks Antonio!) and you
should see the official SPR and patch soon. This means VxWorks now has a fairly reliable
driver that supports all the Intel LAN chips and we can toss out Intel's unsupported(?)
fragile "eeE" driver.

James.


> One drawback: the "fei" driver doesn't seem to recognise the 82559ER PHY properly
> because it forces the link to 10M/half duplex.

> Haven't yet found any other ways that it's broken.

> James.


> > Guess what? I went back to using WindRiver's FEI END driver and just added another
> > line to sys557PciInit() so it accepts the 82559ER's PCI device ID (0x1209) as well
> > as the 82557/8/9's (0x1229).

> > And it just works!

> > The answer seems to be do not use Intel's driver in the VxWorks boot image.

> > Merry Christmas!

> > James.


> > > Hi Everyone.

> > > I'm using the Intel 82559ER-supporting VxWorks driver to boot a PC target from a
> > > host on a different subnet and getting nowhere.

> > > My target is on 10.225.0.158:ffffff00 (255.255.255.0) and the host is on
> > > 15.144.180.226:fffff000 (255.255.240.0). Both are subnetted Class A addresses.
> > > When I add the gateway parameter, g=10.225.0.1, the bootConfig.c code adds a
> > > route [with routeAdd()] to 15.0.0.0 through this gateway, ignoring the netmask.

> > > When I use the BSD/SENS variant of the driver (version 1.00.05) I just get the
> > > "Loading..." prompt and nothing else. The target doesn't respond to pings at any
> > > time.

> > > When I use the MUX/END variant of the driver (version 1.00.01) I get the
> > > "Loading..." prompt, the first number (text size) then nothing. The target
> > > responds to pings until the text size displays, then stops. I have to leave the
> > > network cable unplugged until "Loading..." appears (see also Further Info at the
> > > end) otherwise I get the message "Panic: where are those rfd buffers" printed
> > > out regularly. *Very occasionally* the pings continue to get through after the
> > > text size displays, but only every 4th ping comes back and with a response of
> > > about 1600ms instead of the usual 0-10ms. The two times that this happened, the
> > > TCP link used by rcmd() *eventually* loaded all the main image and started
> > > VxWorks.

> > > When the target and host are on the same subnet, booting over the LAN works fine
> > > as expected.

> > > Further Info:
> > > - there is 30-50 packets/sec broadcast traffic on the LAN.
> > > - the physical (ie. layer 2) network carries traffic for both logical (layer 3)
> > > IP networks. This means we can make the gateway parameter g=10.225.0.158 - the
> > > same as the target's IP address - so the correct 15.x.x.x packets are generated
> > > directly on the wire by the stack. But it's a shortcut and doesn't appear to
> > > affect the lack of bootloading.
> > > - the symptoms are the same when using the same driver on an 82558 LAN
> > > controller.
> > > - I can use the WindRiver FEI END driver with the 82558 and boot successfully
> > > with target and host on different subnets.
> > > - although the main image is just over 2MB (2,122,344 bytes), it does boot
> > > successfully in other scenarios.
> > > - I've tried replacing the routeAdd() used by bootConfig.c with mRouteAdd(). The
> > > behaviour with netmasks seems to be broken in different and confusing ways, but
> > > it still works with another driver so this shouldn't be stopping bootloading.

> > > I know it's close to Christmas but this scenario needs to work when we come back
> > > next year so if you're feeling bored over the next week...

> > > Best Regards
> > > James.

 
 
 

1. Intel82559 ethernet driver for PowerPC

Hello,

I'am working on a PPC board with a i82559 ethernet chip. I am searching
ethernet driver for the chip like this old post (see below).
Does anyone know where I can found this driver.

Regards,

Nicolas Saouzanet

Newsgroups: comp.os.vxworks
Subject: Intel82559 ethernet driver for PowerPC
Date: Thu, 11 May 2000 15:34:52 -0700

Organization: Raytheon Company

I'm looking for an existing ethernet driver for the Intel82559 ethernet
controller that runs on the PowerPC processor with vxWorks.  Instead of
starting from scratch, I like to find an existing one or one I can
modify from. The one driver posted in the Intel site only runs on the
Pentium processor and not PowerPC.  Can anyone give me some ideas on
where I can possibly find one?

Polly Low

2. Bad Keyboard

3. Looking for DEC BCC17 (Rainbow - VR241 cable)

4. Boot vxWorks with different ethernet drivers

5. CDROM Spin up problems

6. OrbixTalk Question: Consumers and Suppliers on different subnets

7. Maximun SCSI throughput

8. OrbixTalk: Consumers and Suppliers on different subnets

9. How to find the subnet Address of the host

10. booting and subnet

11. Help with subnet mask booting

12. HELP! Boot error with a subnet mask!