Re: [Etherboot-developers] Re: Possibly [PRISM] driver limitation?

[Michael B. <mb...@fe...>]

On 27 Aug 2002, Eric W. Biederman wrote:
> > > Today I have been doing a bunch of tests. My test machine has 128mb of
> > > RAM and I was testing different size images and different network
> > > card/drivers to check for problems. Here are the results
> > > Realtek 8139 card with rtl8139 driver: 43mb,20mb, 19.3mb, 19.1mb, 17.6mb,
> > 16.2mb, 15.2mb image files all booted OK.
> > > Realtek 8029 card with rtl8029 driver: 43mb,20mb, 19.3mb, 19.1mb, 17.6mb,
> > 16.2mb, 15.2mb image files all booted OK also.
> > > Dlink DWL-520 with PRISM driver: 43mb failed, 20mb failed, 19.3mb ok, 19.1mb
> > ok, 17.6mb,16.2mb ok, 15.2mb ok.
> > > It seems their seems to be a limitation in file size in the PRISM
> > > driver. Somewhere between 19.3mb-20mb's, the driver cannot allocate
> > > space or initialize the data from the image file. Hopefully we could
> > > fix this issue? [sooner the better..hehehe]
> > I'll help where I can, but I don't see this as an urgent problem - why
> > would you want to transfer images of 20MB and more anyway, particularly
> > over a slow wireless link?
> If problem is just related to the packet count, it may be easier to
> tickle the problem when the signal is degradded, and a lot of
> retransmissions are happening.  Fixing bugs like this that can never
> really happen is then kind of thing that let's me sleep at night.

Have reviewed the code and one immediate suspect appears.  Basic transmit
pattern is:

1. Request a FID (Frame ID, I think).
2. Wait for event signalling FID allocation.
3. Fill FID buffer with the packet to be transmitted.
4. Transmit the frame.
5. Wait for transmission to complete.

Now, there is an option in step 4 to say "please re-use the FID after
transmission", in which case you will receive a "FID allocated" event
shortly after the transmission is completed, without having to re-request
a FID.  I chose not to use this option in the interests of simplicity -
AFAICT if you don't ask for re-use then you just pay the penalty of having
to re-request a FID.  I assumed that the FID that was "used" (but not
"re-used") was not lost forever.  It is possible, but very unlikely, that
this assumption is incorrect.

One test worth trying would be a very simple use of the "reclaim" mode:

In "prism2_transmit":

Make "fid" static:
  #define FID_NOT_YET_ALLOCATED = 0;
  static UINT16 fid = FID_NOT_YET_ALLOCATED;

Modify the line
  result = hfa384x_docmd_wait(hw,
			      HFA384x_CMD_CMDCODE_SET(HFA384x_CMDCODE_TX),
			      fid, 0, 0);
to
  result = hfa384x_docmd_wait(hw,
			      HFA384x_CMD_CMDCODE_SET(HFA384x_CMDCODE_TX) |
				HFA384x_CMD_RECL_SET(reclaim),
			      fid, 0, 0);

then wait for the reused "FID allocated" event at the end of the transmit
routine:

  if ( !hfa384x_wait_for_event(hw, HFA384x_EVSTAT_ALLOC, 10, 50,
			       "Tx FID to be allocated\n" ) ) return;
  fid = hfa384x_getreg(hw, HFA384x_ALLOCFID);

and finally, at the beginning of the routine, only allocate a new FID if
fid == FID_NOT_YET_ALLOCATED.

This may or may not work - I don't have time to test it right now.  Anyone
else want to give it a go?

Michael Brown
http://www.fensystems.co.uk