On 06/26/2018 05:34 AM, Alexander Graf wrote:
On 06/21/2018 10:37 AM, Peter Robinson wrote:
On Mon, Jun 18, 2018 at 7:56 PM, Andrew Thomas andrew.thomas@oracle.com wrote:
This bug is the combination of dwc2 USB controller and lan78xx USB ethernet controller, which is the combination in use on the Raspberry Pi Model 3 B+.
When the host attempts to receive a packet, but a packet has not arrived, the lan78xx controller responds by setting BIR (Bulk-In Empty Response) to NAK. Unfortunately, this hangs the USB controller and requires the USB controller to be reset.
The fix proposed is to have the lan78xx controller respond by setting BIR to ZLP.
Signed-off-by: Andrew Thomas andrew.thomas@oracle.com
Tested-by: Peter Robinson pbrobinson@gmail.com
Tested on the RPi 3B+ and certainly improves this situation a number of Fedora users have seen.
What exactly have you tested?
Even with this patch, I am not reliably to reliably boot into grub.
Can you say which version of grub? I am using the gcdaa64.efi binary in this RPM:
http://yum.oracle.com/repo/OracleLinux/OL7/latest/aarch64/getPackage/grub2-e...
The same binary is named EFI/BOOT/grubaa64.efi on the "ISO" CD/DVD install image -- the point, for me, of getting the lan controller "functioning" is to allow network kickstart install.
I have had a peculiar USB/lan problem with a DVI monitor attached; while a different brand HDMI monitor worked OK.
FWIW: I use fairly recent "firmware":
https://github.com/raspberrypi/firmware eeaaf5e2b5aee29f31e989c0dddd186fb68b2144
And in the u-boot configuration I have:
CONFIG_OF_BOARD=y # CONFIG_OF_EMBED is not set
As an aside, I did post [to this list] a related fix ARP for efi networking...
It almost seems as if the packet buffer keeps getting overwritten by newer packets so that by the time we process the old ones, the ones we wanted to see are gone.
From the polling structure of the EFI networking code, it seems inevitable that some packets would be lost on a busy network??
I have to admit that I had both the Pi and dhcp/tftp server on a "silent" lan.
I should also mention that while trying to debug this issue, the lan driver would occasionally receive what appeared to be bogus frames -- with packet sizes which made absolutely no sense as jumbo frames are not enabled on the switch to which the PI is attached...