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.m...@gmail.com <mailto:aleksandar.m.m...@gmail.com>> је
написао/ла:
2:06 AM Sre, 19.02.2020. Finn Thain <fth...@telegraphics.com.au
<mailto:fth...@telegraphics.com.au>> је написао/ла:
On Tue, 18 Feb 2020, Aleksandar Markovic wrote:
On Wednesday, January 29, 2020, Finn Thain
<fth...@telegraphics.com.au <mailto:fth...@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
