Timeout poll on interrupt endpoint for RPI3 with keyboard and mouse

[Mark Millard]

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.

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