mbox series

[v4,00/14] Fixes for DP8393X SONIC device emulation

Message ID cover.1580290069.git.fthain@telegraphics.com.au (mailing list archive)
Headers show
Series Fixes for DP8393X SONIC device emulation | expand

Message

Finn Thain Jan. 29, 2020, 9:27 a.m. UTC
Hi All,

There are bugs in the emulated dp8393x device that can stop packet
reception in a Linux/m68k guest (q800 machine).

With a Linux/m68k v5.5 guest (q800), it's possible to remotely trigger
an Oops by sending ping floods.

With a Linux/mips guest (magnum machine), the driver fails to probe
the dp8393x device.

With a NetBSD/arc 5.1 guest (magnum), the bugs in the device can be
fatal to the guest kernel.

Whilst debugging the device, I found that the receiver algorithm
differs from the one described in the National Semiconductor
datasheet.

This patch series resolves these bugs.

AFAIK, all bugs in the Linux sonic driver were fixed in Linux v5.5.
---
Changed since v1:
 - Minor revisions as described beneath commit logs.
 - Dropped patches 4/10 and 7/10.
 - Added 5 new patches.

Changed since v2:
 - Minor revisions as described beneath commit logs.
 - Dropped patch 13/13.
 - Added 2 new patches.

Changed since v3:
 - Replaced patch 13/14 with patch suggested by Philippe Mathieu-Daudé.


Finn Thain (14):
  dp8393x: Mask EOL bit from descriptor addresses
  dp8393x: Always use 32-bit accesses
  dp8393x: Clean up endianness hacks
  dp8393x: Have dp8393x_receive() return the packet size
  dp8393x: Update LLFA and CRDA registers from rx descriptor
  dp8393x: Clear RRRA command register bit only when appropriate
  dp8393x: Implement packet size limit and RBAE interrupt
  dp8393x: Don't clobber packet checksum
  dp8393x: Use long-word-aligned RRA pointers in 32-bit mode
  dp8393x: Pad frames to word or long word boundary
  dp8393x: Clear descriptor in_use field to release packet
  dp8393x: Always update RRA pointers and sequence numbers
  dp8393x: Don't reset Silicon Revision register
  dp8393x: Don't stop reception upon RBE interrupt assertion

 hw/net/dp8393x.c | 202 +++++++++++++++++++++++++++++++----------------
 1 file changed, 134 insertions(+), 68 deletions(-)

Comments

Jason Wang Feb. 4, 2020, 3:58 a.m. UTC | #1
On 2020/1/29 下午5:27, Finn Thain wrote:
> Hi All,
>
> There are bugs in the emulated dp8393x device that can stop packet
> reception in a Linux/m68k guest (q800 machine).
>
> With a Linux/m68k v5.5 guest (q800), it's possible to remotely trigger
> an Oops by sending ping floods.
>
> With a Linux/mips guest (magnum machine), the driver fails to probe
> the dp8393x device.
>
> With a NetBSD/arc 5.1 guest (magnum), the bugs in the device can be
> fatal to the guest kernel.
>
> Whilst debugging the device, I found that the receiver algorithm
> differs from the one described in the National Semiconductor
> datasheet.
>
> This patch series resolves these bugs.
>
> AFAIK, all bugs in the Linux sonic driver were fixed in Linux v5.5.
> ---
> Changed since v1:
>   - Minor revisions as described beneath commit logs.
>   - Dropped patches 4/10 and 7/10.
>   - Added 5 new patches.
>
> Changed since v2:
>   - Minor revisions as described beneath commit logs.
>   - Dropped patch 13/13.
>   - Added 2 new patches.
>
> Changed since v3:
>   - Replaced patch 13/14 with patch suggested by Philippe Mathieu-Daudé.
>
>
> Finn Thain (14):
>    dp8393x: Mask EOL bit from descriptor addresses
>    dp8393x: Always use 32-bit accesses
>    dp8393x: Clean up endianness hacks
>    dp8393x: Have dp8393x_receive() return the packet size
>    dp8393x: Update LLFA and CRDA registers from rx descriptor
>    dp8393x: Clear RRRA command register bit only when appropriate
>    dp8393x: Implement packet size limit and RBAE interrupt
>    dp8393x: Don't clobber packet checksum
>    dp8393x: Use long-word-aligned RRA pointers in 32-bit mode
>    dp8393x: Pad frames to word or long word boundary
>    dp8393x: Clear descriptor in_use field to release packet
>    dp8393x: Always update RRA pointers and sequence numbers
>    dp8393x: Don't reset Silicon Revision register
>    dp8393x: Don't stop reception upon RBE interrupt assertion
>
>   hw/net/dp8393x.c | 202 +++++++++++++++++++++++++++++++----------------
>   1 file changed, 134 insertions(+), 68 deletions(-)


Applied.

Thanks
Aleksandar Markovic Feb. 18, 2020, 6:25 p.m. UTC | #2
On Wednesday, January 29, 2020, Finn Thain <fthain@telegraphics.com.au>
wrote:

> Hi All,
>
> There are bugs in the emulated dp8393x device that can stop packet
> reception in a Linux/m68k guest (q800 machine).
>
> With a Linux/m68k v5.5 guest (q800), it's possible to remotely trigger
> an Oops by sending ping floods.
>
> With a Linux/mips guest (magnum machine), the driver fails to probe
> the dp8393x device.
>
> With a NetBSD/arc 5.1 guest (magnum), the bugs in the device can be
> fatal to the guest kernel.
>
> Whilst debugging the device, I found that the receiver algorithm
> differs from the one described in the National Semiconductor
> datasheet.
>
> This patch series resolves these bugs.
>
> AFAIK, all bugs in the Linux sonic driver were fixed in Linux v5.5.
> ---


Herve,

Do your Jazz tests pass with these changes?

Regards,
Aleksandar



> Changed since v1:
>  - Minor revisions as described beneath commit logs.
>  - Dropped patches 4/10 and 7/10.
>  - Added 5 new patches.
>
> Changed since v2:
>  - Minor revisions as described beneath commit logs.
>  - Dropped patch 13/13.
>  - Added 2 new patches.
>
> Changed since v3:
>  - Replaced patch 13/14 with patch suggested by Philippe Mathieu-Daudé.
>
>
> Finn Thain (14):
>   dp8393x: Mask EOL bit from descriptor addresses
>   dp8393x: Always use 32-bit accesses
>   dp8393x: Clean up endianness hacks
>   dp8393x: Have dp8393x_receive() return the packet size
>   dp8393x: Update LLFA and CRDA registers from rx descriptor
>   dp8393x: Clear RRRA command register bit only when appropriate
>   dp8393x: Implement packet size limit and RBAE interrupt
>   dp8393x: Don't clobber packet checksum
>   dp8393x: Use long-word-aligned RRA pointers in 32-bit mode
>   dp8393x: Pad frames to word or long word boundary
>   dp8393x: Clear descriptor in_use field to release packet
>   dp8393x: Always update RRA pointers and sequence numbers
>   dp8393x: Don't reset Silicon Revision register
>   dp8393x: Don't stop reception upon RBE interrupt assertion
>
>  hw/net/dp8393x.c | 202 +++++++++++++++++++++++++++++++----------------
>  1 file changed, 134 insertions(+), 68 deletions(-)
>
> --
> 2.24.1
>
>
>
Aleksandar Markovic Feb. 18, 2020, 6:30 p.m. UTC | #3
On Tuesday, February 4, 2020, Jason Wang <jasowang@redhat.com> wrote:

>
> On 2020/1/29 下午5:27, Finn Thain wrote:
>
>> Hi All,
>>
>> There are bugs in the emulated dp8393x device that can stop packet
>> reception in a Linux/m68k guest (q800 machine).
>>
>> With a Linux/m68k v5.5 guest (q800), it's possible to remotely trigger
>> an Oops by sending ping floods.
>>
>> With a Linux/mips guest (magnum machine), the driver fails to probe
>> the dp8393x device.
>>
>> With a NetBSD/arc 5.1 guest (magnum), the bugs in the device can be
>> fatal to the guest kernel.
>>
>> Whilst debugging the device, I found that the receiver algorithm
>> differs from the one described in the National Semiconductor
>> datasheet.
>>
>> This patch series resolves these bugs.
>>
>> AFAIK, all bugs in the Linux sonic driver were fixed in Linux v5.5.
>> ---
>> Changed since v1:
>>   - Minor revisions as described beneath commit logs.
>>   - Dropped patches 4/10 and 7/10.
>>   - Added 5 new patches.
>>
>> Changed since v2:
>>   - Minor revisions as described beneath commit logs.
>>   - Dropped patch 13/13.
>>   - Added 2 new patches.
>>
>> Changed since v3:
>>   - Replaced patch 13/14 with patch suggested by Philippe Mathieu-Daudé.
>>
>>
>> Finn Thain (14):
>>    dp8393x: Mask EOL bit from descriptor addresses
>>    dp8393x: Always use 32-bit accesses
>>    dp8393x: Clean up endianness hacks
>>    dp8393x: Have dp8393x_receive() return the packet size
>>    dp8393x: Update LLFA and CRDA registers from rx descriptor
>>    dp8393x: Clear RRRA command register bit only when appropriate
>>    dp8393x: Implement packet size limit and RBAE interrupt
>>    dp8393x: Don't clobber packet checksum
>>    dp8393x: Use long-word-aligned RRA pointers in 32-bit mode
>>    dp8393x: Pad frames to word or long word boundary
>>    dp8393x: Clear descriptor in_use field to release packet
>>    dp8393x: Always update RRA pointers and sequence numbers
>>    dp8393x: Don't reset Silicon Revision register
>>    dp8393x: Don't stop reception upon RBE interrupt assertion
>>
>>   hw/net/dp8393x.c | 202 +++++++++++++++++++++++++++++++----------------
>>   1 file changed, 134 insertions(+), 68 deletions(-)
>>
>
>
> Applied.
>
>
Hi, Jason,

I generally have some reservations towards patches that did not receive any
R-bs. I think we should hear from Herve in this case, to confirm that this
change doesn't cause other problems while solving the original ones.

I hope this is not the case.

Regards,
Aleksandar




> Thanks
>
>
>
Finn Thain Feb. 19, 2020, 1:06 a.m. UTC | #4
On Tue, 18 Feb 2020, Aleksandar Markovic wrote:

> On Wednesday, January 29, 2020, Finn Thain <fthain@telegraphics.com.au>
> wrote:
> 
> > Hi All,
> >
> > There are bugs in the emulated dp8393x device that can stop packet
> > reception in a Linux/m68k guest (q800 machine).
> >
> > With a Linux/m68k v5.5 guest (q800), it's possible to remotely trigger
> > an Oops by sending ping floods.
> >
> > With a Linux/mips guest (magnum machine), the driver fails to probe
> > the dp8393x device.
> >
> > With a NetBSD/arc 5.1 guest (magnum), the bugs in the device can be
> > fatal to the guest kernel.
> >
> > Whilst debugging the device, I found that the receiver algorithm
> > differs from the one described in the National Semiconductor
> > datasheet.
> >
> > This patch series resolves these bugs.
> >
> > AFAIK, all bugs in the Linux sonic driver were fixed in Linux v5.5.
> > ---
> 
> 
> Herve,
> 
> Do your Jazz tests pass with these changes?
> 

AFAIK those tests did not expose the NetBSD panic that is caused by 
mainline QEMU (mentioned above).

I have actually run the tests you requested (Hervé described them in an 
earlier thread). There was no regression. Quite the reverse -- it's no 
longer possible to remotely crash the NetBSD kernel.

Apparently my testing was also the first time that the jazzsonic driver 
(from the Linux/mips Magnum port) was tested successfully with QEMU. It 
doesn't work in mainline QEMU.

Anyway, more testing is always nice, and I'd certainly welcome an 
'acked-by' or 'tested-by' if Hervé would like to send one.

Please consider backporting this series of bug fixes to QEMU stable 
branch(es).

Regards,
Finn

> Regards,
> Aleksandar
> 
> 
> 
> > Changed since v1:
> >  - Minor revisions as described beneath commit logs.
> >  - Dropped patches 4/10 and 7/10.
> >  - Added 5 new patches.
> >
> > Changed since v2:
> >  - Minor revisions as described beneath commit logs.
> >  - Dropped patch 13/13.
> >  - Added 2 new patches.
> >
> > Changed since v3:
> >  - Replaced patch 13/14 with patch suggested by Philippe Mathieu-Daudé.
> >
> >
> > Finn Thain (14):
> >   dp8393x: Mask EOL bit from descriptor addresses
> >   dp8393x: Always use 32-bit accesses
> >   dp8393x: Clean up endianness hacks
> >   dp8393x: Have dp8393x_receive() return the packet size
> >   dp8393x: Update LLFA and CRDA registers from rx descriptor
> >   dp8393x: Clear RRRA command register bit only when appropriate
> >   dp8393x: Implement packet size limit and RBAE interrupt
> >   dp8393x: Don't clobber packet checksum
> >   dp8393x: Use long-word-aligned RRA pointers in 32-bit mode
> >   dp8393x: Pad frames to word or long word boundary
> >   dp8393x: Clear descriptor in_use field to release packet
> >   dp8393x: Always update RRA pointers and sequence numbers
> >   dp8393x: Don't reset Silicon Revision register
> >   dp8393x: Don't stop reception upon RBE interrupt assertion
> >
> >  hw/net/dp8393x.c | 202 +++++++++++++++++++++++++++++++----------------
> >  1 file changed, 134 insertions(+), 68 deletions(-)
> >
> > --
> > 2.24.1
> >
> >
> >
>
Aleksandar Markovic Feb. 19, 2020, 1:54 a.m. UTC | #5
2:06 AM Sre, 19.02.2020. Finn Thain <fthain@telegraphics.com.au> је
написао/ла:
>
> On Tue, 18 Feb 2020, Aleksandar Markovic wrote:
>
> > On Wednesday, January 29, 2020, Finn Thain <fthain@telegraphics.com.au>
> > wrote:
> >
> > > Hi All,
> > >
> > > There are bugs in the emulated dp8393x device that can stop packet
> > > reception in a Linux/m68k guest (q800 machine).
> > >
> > > With a Linux/m68k v5.5 guest (q800), it's possible to remotely trigger
> > > an Oops by sending ping floods.
> > >
> > > With a Linux/mips guest (magnum machine), the driver fails to probe
> > > the dp8393x device.
> > >
> > > With a NetBSD/arc 5.1 guest (magnum), the bugs in the device can be
> > > fatal to the guest kernel.
> > >
> > > Whilst debugging the device, I found that the receiver algorithm
> > > differs from the one described in the National Semiconductor
> > > datasheet.
> > >
> > > This patch series resolves these bugs.
> > >
> > > AFAIK, all bugs in the Linux sonic driver were fixed in Linux v5.5.
> > > ---
> >
> >
> > Herve,
> >
> > Do your Jazz tests pass with these changes?
> >
>
> AFAIK those tests did not expose the NetBSD panic that is caused by
> mainline QEMU (mentioned above).
>
> I have actually run the tests you requested (Hervé described them in an
> earlier thread). There was no regression. Quite the reverse -- it's no
> longer possible to remotely crash the NetBSD kernel.
>
> Apparently my testing was also the first time that the jazzsonic driver
> (from the Linux/mips Magnum port) was tested successfully with QEMU. It
> doesn't work in mainline QEMU.
>

Well, I appologize if I missed all these facts. I just did not notice them,
at least not in this form. And, yes, some "Tested-by:" by Herve would be
desirable and nice.

Yours,
Aleksandae

> Anyway, more testing is always nice, and I'd certainly welcome an
> 'acked-by' or 'tested-by' if Hervé would like to send one.
>
> Please consider backporting this series of bug fixes to QEMU stable
> branch(es).
>
> Regards,
> Finn
>
> > Regards,
> > Aleksandar
> >
> >
> >
> > > Changed since v1:
> > >  - Minor revisions as described beneath commit logs.
> > >  - Dropped patches 4/10 and 7/10.
> > >  - Added 5 new patches.
> > >
> > > Changed since v2:
> > >  - Minor revisions as described beneath commit logs.
> > >  - Dropped patch 13/13.
> > >  - Added 2 new patches.
> > >
> > > Changed since v3:
> > >  - Replaced patch 13/14 with patch suggested by Philippe
Mathieu-Daudé.
> > >
> > >
> > > Finn Thain (14):
> > >   dp8393x: Mask EOL bit from descriptor addresses
> > >   dp8393x: Always use 32-bit accesses
> > >   dp8393x: Clean up endianness hacks
> > >   dp8393x: Have dp8393x_receive() return the packet size
> > >   dp8393x: Update LLFA and CRDA registers from rx descriptor
> > >   dp8393x: Clear RRRA command register bit only when appropriate
> > >   dp8393x: Implement packet size limit and RBAE interrupt
> > >   dp8393x: Don't clobber packet checksum
> > >   dp8393x: Use long-word-aligned RRA pointers in 32-bit mode
> > >   dp8393x: Pad frames to word or long word boundary
> > >   dp8393x: Clear descriptor in_use field to release packet
> > >   dp8393x: Always update RRA pointers and sequence numbers
> > >   dp8393x: Don't reset Silicon Revision register
> > >   dp8393x: Don't stop reception upon RBE interrupt assertion
> > >
> > >  hw/net/dp8393x.c | 202
+++++++++++++++++++++++++++++++----------------
> > >  1 file changed, 134 insertions(+), 68 deletions(-)
> > >
> > > --
> > > 2.24.1
> > >
> > >
> > >
> >
Aleksandar Markovic Feb. 19, 2020, 1:57 a.m. UTC | #6
2:54 AM Sre, 19.02.2020. Aleksandar Markovic <aleksandar.m.mail@gmail.com>
је написао/ла:
>
> 2:06 AM Sre, 19.02.2020. Finn Thain <fthain@telegraphics.com.au> је
написао/ла:
> >
> > On Tue, 18 Feb 2020, Aleksandar Markovic wrote:
> >
> > > On Wednesday, January 29, 2020, Finn Thain <fthain@telegraphics.com.au
>
> > > wrote:
> > >
> > > > Hi All,
> > > >
> > > > There are bugs in the emulated dp8393x device that can stop packet
> > > > reception in a Linux/m68k guest (q800 machine).
> > > >
> > > > With a Linux/m68k v5.5 guest (q800), it's possible to remotely
trigger
> > > > an Oops by sending ping floods.
> > > >
> > > > With a Linux/mips guest (magnum machine), the driver fails to probe
> > > > the dp8393x device.
> > > >
> > > > With a NetBSD/arc 5.1 guest (magnum), the bugs in the device can be
> > > > fatal to the guest kernel.
> > > >
> > > > Whilst debugging the device, I found that the receiver algorithm
> > > > differs from the one described in the National Semiconductor
> > > > datasheet.
> > > >
> > > > This patch series resolves these bugs.
> > > >
> > > > AFAIK, all bugs in the Linux sonic driver were fixed in Linux v5.5.
> > > > ---
> > >
> > >
> > > Herve,
> > >
> > > Do your Jazz tests pass with these changes?
> > >
> >
> > AFAIK those tests did not expose the NetBSD panic that is caused by
> > mainline QEMU (mentioned above).
> >
> > I have actually run the tests you requested (Hervé described them in an
> > earlier thread). There was no regression. Quite the reverse -- it's no
> > longer possible to remotely crash the NetBSD kernel.
> >
> > Apparently my testing was also the first time that the jazzsonic driver
> > (from the Linux/mips Magnum port) was tested successfully with QEMU. It
> > doesn't work in mainline QEMU.
> >
>
> Well, I appologize if I missed all these facts. I just did not notice
them, at least not in this form. And, yes, some "Tested-by:" by Herve would
be desirable and nice.
>

Or, perhaps, even "Reviewed-by:".

> Yours,
> Aleksandae
>
> > Anyway, more testing is always nice, and I'd certainly welcome an
> > 'acked-by' or 'tested-by' if Hervé would like to send one.
> >
> > Please consider backporting this series of bug fixes to QEMU stable
> > branch(es).
> >
> > Regards,
> > Finn
> >
> > > Regards,
> > > Aleksandar
> > >
> > >
> > >
> > > > Changed since v1:
> > > >  - Minor revisions as described beneath commit logs.
> > > >  - Dropped patches 4/10 and 7/10.
> > > >  - Added 5 new patches.
> > > >
> > > > Changed since v2:
> > > >  - Minor revisions as described beneath commit logs.
> > > >  - Dropped patch 13/13.
> > > >  - Added 2 new patches.
> > > >
> > > > Changed since v3:
> > > >  - Replaced patch 13/14 with patch suggested by Philippe
Mathieu-Daudé.
> > > >
> > > >
> > > > Finn Thain (14):
> > > >   dp8393x: Mask EOL bit from descriptor addresses
> > > >   dp8393x: Always use 32-bit accesses
> > > >   dp8393x: Clean up endianness hacks
> > > >   dp8393x: Have dp8393x_receive() return the packet size
> > > >   dp8393x: Update LLFA and CRDA registers from rx descriptor
> > > >   dp8393x: Clear RRRA command register bit only when appropriate
> > > >   dp8393x: Implement packet size limit and RBAE interrupt
> > > >   dp8393x: Don't clobber packet checksum
> > > >   dp8393x: Use long-word-aligned RRA pointers in 32-bit mode
> > > >   dp8393x: Pad frames to word or long word boundary
> > > >   dp8393x: Clear descriptor in_use field to release packet
> > > >   dp8393x: Always update RRA pointers and sequence numbers
> > > >   dp8393x: Don't reset Silicon Revision register
> > > >   dp8393x: Don't stop reception upon RBE interrupt assertion
> > > >
> > > >  hw/net/dp8393x.c | 202
+++++++++++++++++++++++++++++++----------------
> > > >  1 file changed, 134 insertions(+), 68 deletions(-)
> > > >
> > > > --
> > > > 2.24.1
> > > >
> > > >
> > > >
> > >
Jason Wang Feb. 19, 2020, 3:13 a.m. UTC | #7
On 2020/2/19 上午2:30, Aleksandar Markovic wrote:
>
>
> On Tuesday, February 4, 2020, Jason Wang <jasowang@redhat.com 
> <mailto:jasowang@redhat.com>> wrote:
>
>
>     On 2020/1/29 下午5:27, Finn Thain wrote:
>
>         Hi All,
>
>         There are bugs in the emulated dp8393x device that can stop packet
>         reception in a Linux/m68k guest (q800 machine).
>
>         With a Linux/m68k v5.5 guest (q800), it's possible to remotely
>         trigger
>         an Oops by sending ping floods.
>
>         With a Linux/mips guest (magnum machine), the driver fails to
>         probe
>         the dp8393x device.
>
>         With a NetBSD/arc 5.1 guest (magnum), the bugs in the device
>         can be
>         fatal to the guest kernel.
>
>         Whilst debugging the device, I found that the receiver algorithm
>         differs from the one described in the National Semiconductor
>         datasheet.
>
>         This patch series resolves these bugs.
>
>         AFAIK, all bugs in the Linux sonic driver were fixed in Linux
>         v5.5.
>         ---
>         Changed since v1:
>           - Minor revisions as described beneath commit logs.
>           - Dropped patches 4/10 and 7/10.
>           - Added 5 new patches.
>
>         Changed since v2:
>           - Minor revisions as described beneath commit logs.
>           - Dropped patch 13/13.
>           - Added 2 new patches.
>
>         Changed since v3:
>           - Replaced patch 13/14 with patch suggested by Philippe
>         Mathieu-Daudé.
>
>
>         Finn Thain (14):
>            dp8393x: Mask EOL bit from descriptor addresses
>            dp8393x: Always use 32-bit accesses
>            dp8393x: Clean up endianness hacks
>            dp8393x: Have dp8393x_receive() return the packet size
>            dp8393x: Update LLFA and CRDA registers from rx descriptor
>            dp8393x: Clear RRRA command register bit only when appropriate
>            dp8393x: Implement packet size limit and RBAE interrupt
>            dp8393x: Don't clobber packet checksum
>            dp8393x: Use long-word-aligned RRA pointers in 32-bit mode
>            dp8393x: Pad frames to word or long word boundary
>            dp8393x: Clear descriptor in_use field to release packet
>            dp8393x: Always update RRA pointers and sequence numbers
>            dp8393x: Don't reset Silicon Revision register
>            dp8393x: Don't stop reception upon RBE interrupt assertion
>
>           hw/net/dp8393x.c | 202
>         +++++++++++++++++++++++++++++++----------------
>           1 file changed, 134 insertions(+), 68 deletions(-)
>
>
>
>     Applied.
>
>
> Hi, Jason,
>
> I generally have some reservations towards patches that did not 
> receive any R-bs. I think we should hear from Herve in this case, to 
> confirm that this change doesn't cause other problems while solving 
> the original ones.


That's fine but if it's agreed that we should hear from somebody for a 
specific part of the code, it's better to have the one as 
maintainer/reviewer in MAINTAINERS.

Thanks


>
> I hope this is not the case.
>
> Regards,
> Aleksandar
>
>
Laurent Vivier Feb. 19, 2020, 7:55 a.m. UTC | #8
Le 19/02/2020 à 02:57, Aleksandar Markovic a écrit :
> 2:54 AM Sre, 19.02.2020. Aleksandar Markovic
> <aleksandar.m.mail@gmail.com <mailto:aleksandar.m.mail@gmail.com>> је
> написао/ла:
>>
>> 2:06 AM Sre, 19.02.2020. Finn Thain <fthain@telegraphics.com.au
> <mailto:fthain@telegraphics.com.au>> је написао/ла:
>> >
>> > On Tue, 18 Feb 2020, Aleksandar Markovic wrote:
>> >
>> > > On Wednesday, January 29, 2020, Finn Thain
> <fthain@telegraphics.com.au <mailto:fthain@telegraphics.com.au>>
>> > > wrote:
>> > >
>> > > > Hi All,
>> > > >
>> > > > There are bugs in the emulated dp8393x device that can stop packet
>> > > > reception in a Linux/m68k guest (q800 machine).
>> > > >
>> > > > With a Linux/m68k v5.5 guest (q800), it's possible to remotely
> trigger
>> > > > an Oops by sending ping floods.
>> > > >
>> > > > With a Linux/mips guest (magnum machine), the driver fails to probe
>> > > > the dp8393x device.
>> > > >
>> > > > With a NetBSD/arc 5.1 guest (magnum), the bugs in the device can be
>> > > > fatal to the guest kernel.
>> > > >
>> > > > Whilst debugging the device, I found that the receiver algorithm
>> > > > differs from the one described in the National Semiconductor
>> > > > datasheet.
>> > > >
>> > > > This patch series resolves these bugs.
>> > > >
>> > > > AFAIK, all bugs in the Linux sonic driver were fixed in Linux v5.5.
>> > > > ---
>> > >
>> > >
>> > > Herve,
>> > >
>> > > Do your Jazz tests pass with these changes?
>> > >
>> >
>> > AFAIK those tests did not expose the NetBSD panic that is caused by
>> > mainline QEMU (mentioned above).
>> >
>> > I have actually run the tests you requested (Hervé described them in an
>> > earlier thread). There was no regression. Quite the reverse -- it's no
>> > longer possible to remotely crash the NetBSD kernel.
>> >
>> > Apparently my testing was also the first time that the jazzsonic driver
>> > (from the Linux/mips Magnum port) was tested successfully with QEMU. It
>> > doesn't work in mainline QEMU.
>> >
>>
>> Well, I appologize if I missed all these facts. I just did not notice
> them, at least not in this form. And, yes, some "Tested-by:" by Herve
> would be desirable and nice.
>>
> 
> Or, perhaps, even "Reviewed-by:".
> 

It would be nice to have this merged before next release because q800
machine networking is not reliable without them.

And thank you to Finn for all his hard work on this device emulation.

Laurent
Philippe Mathieu-Daudé Feb. 19, 2020, 8:27 a.m. UTC | #9
On 2/19/20 8:55 AM, Laurent Vivier wrote:
> Le 19/02/2020 à 02:57, Aleksandar Markovic a écrit :
>> 2:54 AM Sre, 19.02.2020. Aleksandar Markovic
>> <aleksandar.m.mail@gmail.com <mailto:aleksandar.m.mail@gmail.com>> је
>> написао/ла:
>>>
>>> 2:06 AM Sre, 19.02.2020. Finn Thain <fthain@telegraphics.com.au
>> <mailto:fthain@telegraphics.com.au>> је написао/ла:
>>>>
>>>> On Tue, 18 Feb 2020, Aleksandar Markovic wrote:
>>>>
>>>>> On Wednesday, January 29, 2020, Finn Thain
>> <fthain@telegraphics.com.au <mailto:fthain@telegraphics.com.au>>
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> There are bugs in the emulated dp8393x device that can stop packet
>>>>>> reception in a Linux/m68k guest (q800 machine).
>>>>>>
>>>>>> With a Linux/m68k v5.5 guest (q800), it's possible to remotely
>> trigger
>>>>>> an Oops by sending ping floods.
>>>>>>
>>>>>> With a Linux/mips guest (magnum machine), the driver fails to probe
>>>>>> the dp8393x device.
>>>>>>
>>>>>> With a NetBSD/arc 5.1 guest (magnum), the bugs in the device can be
>>>>>> fatal to the guest kernel.
>>>>>>
>>>>>> Whilst debugging the device, I found that the receiver algorithm
>>>>>> differs from the one described in the National Semiconductor
>>>>>> datasheet.
>>>>>>
>>>>>> This patch series resolves these bugs.
>>>>>>
>>>>>> AFAIK, all bugs in the Linux sonic driver were fixed in Linux v5.5.
>>>>>> ---
>>>>>
>>>>>
>>>>> Herve,
>>>>>
>>>>> Do your Jazz tests pass with these changes?
>>>>>
>>>>
>>>> AFAIK those tests did not expose the NetBSD panic that is caused by
>>>> mainline QEMU (mentioned above).
>>>>
>>>> I have actually run the tests you requested (Hervé described them in an
>>>> earlier thread). There was no regression. Quite the reverse -- it's no
>>>> longer possible to remotely crash the NetBSD kernel.
>>>>
>>>> Apparently my testing was also the first time that the jazzsonic driver
>>>> (from the Linux/mips Magnum port) was tested successfully with QEMU. It
>>>> doesn't work in mainline QEMU.
>>>>
>>>
>>> Well, I appologize if I missed all these facts. I just did not notice
>> them, at least not in this form. And, yes, some "Tested-by:" by Herve
>> would be desirable and nice.

FWIW I tested Finn kernel and QEMU part following:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg667432.html
to check than its series doesn't introduce regressions, booting Linux 
and NetBSD.
I haven't run the thorough networking tests Laurent do with the q800 
(scp of big files, fetch over http in loop).

Hervé testing is welcomed, but as a hobbyist he doesn't spend more than 
1h every 2 months on this, so I don't think his approval is a blocker.
We are not talking about business critical emulation, so we can fix 
regressions on top.

--

That said, I'm spending some hobby time on a Magnum boot code to be able 
to test the board upstream (without depending on proprietary BIOS and 
painful graphical setup).

Currently I get NetBSD to kdb and Linux get stuck there:
https://paste.debian.net/plain/1129965

>>>
>>
>> Or, perhaps, even "Reviewed-by:".
>>
> 
> It would be nice to have this merged before next release because q800
> machine networking is not reliable without them.
> 
> And thank you to Finn for all his hard work on this device emulation.
> 
> Laurent
>
Jason Wang Feb. 20, 2020, 6:55 a.m. UTC | #10
On 2020/2/19 下午3:55, Laurent Vivier wrote:
> Le 19/02/2020 à 02:57, Aleksandar Markovic a écrit :
>> 2:54 AM Sre, 19.02.2020. Aleksandar Markovic
>> <aleksandar.m.mail@gmail.com <mailto:aleksandar.m.mail@gmail.com>> је
>> написао/ла:
>>> 2:06 AM Sre, 19.02.2020. Finn Thain <fthain@telegraphics.com.au
>> <mailto:fthain@telegraphics.com.au>> је написао/ла:
>>>> On Tue, 18 Feb 2020, Aleksandar Markovic wrote:
>>>>
>>>>> On Wednesday, January 29, 2020, Finn Thain
>> <fthain@telegraphics.com.au <mailto:fthain@telegraphics.com.au>>
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> There are bugs in the emulated dp8393x device that can stop packet
>>>>>> reception in a Linux/m68k guest (q800 machine).
>>>>>>
>>>>>> With a Linux/m68k v5.5 guest (q800), it's possible to remotely
>> trigger
>>>>>> an Oops by sending ping floods.
>>>>>>
>>>>>> With a Linux/mips guest (magnum machine), the driver fails to probe
>>>>>> the dp8393x device.
>>>>>>
>>>>>> With a NetBSD/arc 5.1 guest (magnum), the bugs in the device can be
>>>>>> fatal to the guest kernel.
>>>>>>
>>>>>> Whilst debugging the device, I found that the receiver algorithm
>>>>>> differs from the one described in the National Semiconductor
>>>>>> datasheet.
>>>>>>
>>>>>> This patch series resolves these bugs.
>>>>>>
>>>>>> AFAIK, all bugs in the Linux sonic driver were fixed in Linux v5.5.
>>>>>> ---
>>>>>
>>>>> Herve,
>>>>>
>>>>> Do your Jazz tests pass with these changes?
>>>>>
>>>> AFAIK those tests did not expose the NetBSD panic that is caused by
>>>> mainline QEMU (mentioned above).
>>>>
>>>> I have actually run the tests you requested (Hervé described them in an
>>>> earlier thread). There was no regression. Quite the reverse -- it's no
>>>> longer possible to remotely crash the NetBSD kernel.
>>>>
>>>> Apparently my testing was also the first time that the jazzsonic driver
>>>> (from the Linux/mips Magnum port) was tested successfully with QEMU. It
>>>> doesn't work in mainline QEMU.
>>>>
>>> Well, I appologize if I missed all these facts. I just did not notice
>> them, at least not in this form. And, yes, some "Tested-by:" by Herve
>> would be desirable and nice.
>> Or, perhaps, even "Reviewed-by:".
>>
> It would be nice to have this merged before next release because q800
> machine networking is not reliable without them.


I will send the pull request that contains this series before the end of 
this week.

Thanks


>
> And thank you to Finn for all his hard work on this device emulation.
>
> Laurent



>