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(-) -- 2.24.1
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 > > >
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 > > > > > > >
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 > > > > > > > > > > >
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 > > > > > > > > > > > > > > >
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
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 >
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 >
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
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 > > >
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 > >
© 2016 - 2024 Red Hat, Inc.