[En-Nut-Discussion] Serious bug in Realtek driver - concerning RC3.4.3

Harald Kipp harald.kipp at egnite.de
Tue Apr 20 14:17:13 CEST 2004


There had been some remarks on formatting, but also some
comments on possible flaws. Nevertheless, Bengt spent
a lot of time and I'm using a slightly modified version
of his contribution with success for some time now.

Here are the main remarks I made:

*** NicOverflow
I do not understand, what's going on here. We wait for TXP to clear,
but still check TXP later for possible resend. I see no way how
TXP should become set again. Am I missing something? In the previous
version, the status had been saved before waiting for completion.
Now that doesn't make sense to me neither, because it had been
waiting after reading the register. Anyway, your code works, so
I leave it as it is for now. We also had a change in version
3.5 and are not allowed to handle nested interrupts anymore on
AVR systems.

*** Transmitter polling
If polling is used, any high priority thread will occupy the
CPU while transmission is in progress. This may break existing
applications. In general, it simplifies the code.

*** Protecting Get-PutPacket
These routines had been protected from interrupts ever since.
Otherwise the interrupt routine may not be able to access
the ISR register in page 0 without changing PS0, PS1, which
would be fatal also. So, it's not the problem to protect the
Get/Put routines from overflows, but to protect the interrupt
routine from changes of register pages.

*** GetPacket return 0xFFFF
In the previous version the driver adds another try before
finally resetting the controller. As far as I can remember,
this had been helpful. Any reason, why this had been removed
and NicStart is called immediately without another try?
But may be I'm too confused to see the trick.




More information about the En-Nut-Discussion mailing list