[Fault-injection-developer] E100 test result Draft tested by FITH

[Gao, K. <kev...@in...>]

The test result of e100 tested by FITH is as follow:

1. When driver reads the SCB command register, we set the value of SCB
   command register to CU_RESUME(or other command but not zero), the
   driver only check whether the value is zero.

   Just because we cannot distinguish the read and write operation when =

   driver access this register, so we cannot guarantee the detailed
   access order that we intercept. Now the newest FITH minimal can do
   it properly, so we will test this issue again.

2. The driver always sets 'S(uspend)' bit to every TCB when it will be
   sent. So only one TCB package will be sent when there is a CU_RESUME
   command. I think the performance is not good.

   We should negotiate with EID's colleague, and knows the real reason
   to do that.

3. When driver writes the 'CU_RESME' command into SCB command register,
   we set the 'I(nterrupt)' bit to 1. According to the information we
   get we find that driver never clear the 'I' bit.

   Just because driver always sets 'S' bit to current TCB, so 'I' bit
   can ignored. And when we tests this instance, The net translation
   works properly, so driver ignore 'i' bit is acceptable.

4. When driver writes the 'CU_RESUME' command into SCB command =
register,
   we set the 'U(nderrun)' bit to 1. The driver ignores this issue.

   Driver should check this bit before writing 'CU_RESUME' command, so
   we should set 'U' bit when driver reads the SCB status register.

5. When driver writes the 'CU_RESUME' command into SCB command =
register,
   we set the 'C(omplete)' bit to 1, and 'OK' bit to 1, driver ignores
   this issue.

   Driver should check this bit, before writing 'CU_RESUME' command,=20
   so this operation is reasonable.

6. When driver writes the 'CU_RESUME' command into SCB command =
register,
   we set the 'C(omplete)' bit to 0, and 'OK' bit to 1. The network =
will
   break after transmit package for short time. =20

   Driver should check this bit, before writing 'CU_RESUME' command, so
   we think drvier should ignore this corrupt operation. We will test =
it
   again to proofing it.=20

   We have no idea for it, and we should verify it again.

7. When driver writes the 'CU_RESUME' command into SCB command =
register,
   we set the 'C(omplete)' bit to 1, and 'OK' bit to 0. Driver will not
   set 'S' bit to current TCB.

   We think the  proper way driver deals with this corruption is ignore
   it. But maybe some error from our TCB tracking code. So we will =
revise
   the code, and test again to find the root cause.=20

   We have no idea for it, and we should verify it again.

8.When driver reads SCB status register, we change the TCB status=20
   register (OK =3D 0, C=3D0) which was just transmitted, After =
succesfully
   sending several package, driver will read status register forever.

   The driver check =A1=B0C=A1=B1 bit only. If not set, it will wait =
until the
  =A1=B0C=A1=B1 bit is set. If =A1=B0C=A1=B1 bit will never be set, the =
TCP pool will=20
   be empty after a while. And driver can also receive packet now.

9. After driver writes the CU_RESUME(CU_START, RU_START, RU_RESUME) to
   SCB command register, we set CU_RESUME command (current value should
   be 0) to SCB command register when driver read SCB command register,
   we found that driver do not read the command register after writing
   command to check.

   Before driver writes command to SCB command register, it must check
   whether it is 0. if not, the driver should wait for a moment and=20
   check again. The driver should also have a timer, so that when =
timeout,
   the SCB command register is still not zero, the driver should quit =
the
   operation, and give the warning report.
=20
10.When driver writes the CU_RESUME(CU_START, RU_START, RU_RESUME) to =
SCB
   command register, we corrupt the value to 0, and after it, if driver
   reads SCB command register to check, we corrupt the command to=20
   CU_RESUME. After do the fault injection, the send functionality will =

   hanged.=20

   When writes CU_RESUME command, the device cannot accept. The driver=20
   should give a warning report.
=20
11.When driver reads SCB status register, we change the TCB status=20
   register (OK =3D 1, C=3D0) which was just transmitted, After =
succesfully=20
   sending several package, driver will read status register forever.

   The same issue of 8.
=20
12.When driver reads SCB status register, we change the TCB status =
register
   (OK =3D 0, C=3D1) which was just transmitted, the driver will ignore =
it.

   The driver never checks the 'OK' bit in TCB status register.
=20
13.When driver reads SCB status register, we set the TCB 'U'nderrun bit =

   which was just transmitted, After succesfully sending several =
package,
   driver will read status register forever.

   We should check it again.

14.Set =A1=AES=A1=AF bit of RFD which is under received when driver =
reads the SCB
   status register. Driver always send a RU_START command.

    The e100 driver checks the hardware status and reacts properly    =20

15.Set =A1=AES=A1=AF bit of RFD which has been received when driver =
reads the SCB
   status register. Driver ignores the operation.

   The 'S' bit is set by driver and read by hardware. Hence the driver=20
   doesn't care it.=20

16.Set both =A1=AEC=A1=AF and =A1=AEOK=A1=AF bit of RFD to zero when =
driver reads the
   SCB status register, Driver cannot receive any package and read the
   RFD forever.

   If the 'C' bit equals zero, the driver will treat this rfd as an=20
   incomplete packet and just wait untile 'C' equals one.=20

17.Set =A1=AEC=A1=AF bit of RFD to 0, and set =A1=AEOK=A1=AF bit of RFD =
to 1 when driver
   reads the SCB status register, the result is the same as process =
2.5.

   The same issue as 16.

18.Set =A1=AEC=A1=AF bit of RFD to 1, and set =A1=AEOK=A1=AF bit of RFD =
to 0 when driver
   reads the SCB status register, driver will hanged, cannot receive =
any
   package.

   When driver find current package is not OK, it will ignore the =
package
   and track next package of the RFL.

19.Set =A1=AECRC=A1=AF bit of RFD to 1 when driver reads the SCB status =
register,
   the driver ignores this operation.

   The driver should check this bit.

20.Set =A1=AEAlignment error=A1=AF bit of RFD to 1 when driver reads =
the SCB=20
   status register, the driver ignores this operation.

   The driver should check this bit.

21.Set =A1=AERun out of buffer=A1=AF bit of RFD to 1 when driver reads =
the=20
   SCB status register, the driver ignores this operation.
  =20
   The driver should check this bit.=20

22.Set =A1=AEFrame too short=A1=AF bit of RFD to 1 when driver reads =
the SCB
    status register, the driver ignores this operation.

   The driver should check this bit.=20


-Kevin