Timeout poll on interrupt endpoint for RPI3 with keyboard and mouse

[Mark Millard]

On 2018-Oct-1, at 4:00 PM, Mark Millard <marklmi at yahoo.com> wrote:

> On 2018-Sep-30, at 7:24 PM, bob prohaska <fbsd at www.zefox.net> wrote:
> 
>> On Mon, Oct 01, 2018 at 08:57:04AM +1000, Trevor Roydhouse wrote:
>>> 
>>> You just need to change one character in the file 
>>> .../sys/arm64/include/pte.h - change the 4 to an 8 in this existing line:
>>> 
>>> #define        PMAP_MAPDEV_EARLY_SIZE  (L2_SIZE * 4)
>>> 
>> 
>> Ok, that wasn't hard 8-)
>> 
>> The machine now boots with the monitor connected and continues to run 
>> correctly when keyboard and mouse are plugged in.
>> 
>> With monitor, keyboard and mouse connected it still spits out a stream of
>> Timeout poll on interrupt endpoint
>> Timeout poll on interrupt endpoint
>> ....
>> during the boot process. The spew seems continuous, but when I typed
>> boot
>> into the spew, it looks as if the kernel took over and the machine is
>> now multi-user. 
>> 
>> Evidently it got stuck in loader, the boot command got it unstuck and
>> after that all is normal.
>> 
>> So, I guess the video issue was a distraction that's now fixed. The 
>> problem with USB mouse and keyboard remain unresolved but nonfatal.  
> 
> I've replicated the issue in my current environment in that any
> time both a keyboard and a mouse are attached during power-up I
> get the: "Timeout poll on interrupt endpoint" messages. (I've
> found some other behavior as well.)
> 
> The same is true when both are plugged into a powered hub
> that is in turn plugged into the rpi3.
> 
> But with just one of the two plugged in I do not get the
> messages, directly plugged in or via the powered hub.
> 
> The monitor HDMI connector makes no difference for if it is
> plugged in or not.
> 
> (Ethernet and the serial console were connected and
> active during the experiments.)
> 
> It seems that multiple USB input devices are mishandled in
> very early time frames, lasting at least to during the kernel
> 10 sec count down for getting to the loader prompt. (10 sec
> is just the default.)
> 
> Similarly, having, say, a keyboard and a reader (with a usd card
> in it) seems to cause 1 MB/s classification instead of 40 MB/s
> classification for the reader's lun's, possibly carry over
> from u-boot time frame activity.  The keyboard worked. Without
> the keyboard it boots assigning 40 MB/s to the lun's. These
> experiments were done using the powered hub.
> 
> When I instead tried just 2 such readers via the powered hub,
> instead the boot hung up for booting after shutdown -r now,
> showing:
> 
> In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> USB0:   scanning bus 0 for devices... Device NOT ready
>   Request Sense returned 02 3A 00
> Device NOT ready
>   Request Sense returned 02 3A 00
> Device NOT ready
>   Request Sense returned 02 3A 00
> Device NOT ready
>   Request Sense returned 02 3A 00
> Device NOT ready
>   Request Sense returned 02 3A 00
> Device NOT ready
>   Request Sense returned 02 3A 00
> Device NOT ready
>   Request Sense returned 02 3A 00
> 7 USB Device(s) found
>       scanning usb for storage devices... 8 Storage Device(s) found
> Hit any key to stop autoboot:  0 
> MMC Device 0 not found
> no mmc device at slot 0
> switch to partitions #0, OK
> mmc1 is current device
> Scanning mmc 1:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> Scanning disk mmc at 7e300000.blk...
> Scanning disk usb_mass_storage.lun0...
> Disk usb_mass_storage.lun0 not ready
> Scanning disk usb_mass_storage.lun1...
> Disk usb_mass_storage.lun1 not ready
> Scanning disk usb_mass_storage.lun2...
> Disk usb_mass_storage.lun2 not ready
> Scanning disk usb_mass_storage.lun3...
> Scanning disk usb_mass_storage.lun0...
> Disk usb_mass_storage.lun0 not ready
> Scanning disk usb_mass_storage.lun1...
> Disk usb_mass_storage.lun1 not ready
> Scanning disk usb_mass_storage.lun2...
> Disk usb_mass_storage.lun2 not ready
> Scanning disk usb_mass_storage.lun3...
> Disk usb_mass_storage.lun3 not ready
> Found 6 disks
> FDT memrsv map 0: Failed to add to map
> 637000 bytes read in 59 ms (10.3 MiB/s)
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> FDT memrsv map 0: Failed to add to map
> ## Starting EFI application at 00080000 ...
> Consoles: EFI console  
> efipart_readwrite: rw=1, blk=64 size=1 status=7
> efipart_readwrite: rw=1, blk=1 size=1 status=7
> 
> After a minute(?) wait there was:
> 
> efipart_readwrite: rw=1, blk=104383 size=8 status=7
> 
> And another wait:
> 
> efipart_readwrite: rw=1, blk=2079 size=257 status=7
> -
> 
> (That "-" was in the serial console output.)
> 
> Another wait, then:
> 
> efipart_readwrite: rw=1, blk=64 size=1 status=7
> 
> EFI: Watchdog timeout
> resetting ...
> MMC:   mmc at 7e300000: 1
> Loading Environment from FAT... *** Warning - bad CRC, using default environment
> . . .
> 
> It booted fine from there.
> 

Repeated testing shows that "EFI: Watchdog timeout" normally
leads to the problem repeating. I've only had the one boot.

Also: Each "efipart_readwrite" message has a wait before it,
not just the ones that I listed.

I've not been able to repeat the problem on a Pine64+ 2GB.
I do not have access to any other aarch64 FreeBSD contexts
at this time.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)