Timeout poll on interrupt endpoint for RPI3 with keyboard and mouse

[bob prohaska]

On Tue, Oct 02, 2018 at 08:31:35PM +0200, Emmanuel Vadot wrote:
> On Sun, 30 Sep 2018 19:24:16 -0700
> 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.  
> 
>  So I've just tested ALPHA8 on my RPI3 and RPI3B+.
> 
>  With *just* keyboard and mouse plugged in I do not have any problem at
> all.
>  If I plug a cheap usb stick, same, no problem.
>  But if I plug my Corsair Voyager USB3, u-boot is really slow to probe
> usb devices. I didn't see the Timeout poll message but I didn't have
> serial connected (I think it doesn't matter since u-boot send all
> prints to every console).
>  The RPI u-boot maintainer is aware that there is issue regarding USB
> on RPI3B+, now he's aware that there is some on RPI3.
> 
>  I see in your mail that you have some usb harddrive or usb stick
> plugged too, can you try without them ?
> 

There were two USB flash drives connected in my test, taking them out
seems to have no effect on early boot behavior (up to the point the
kernel starts). There is a streem of
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
and, without a manually-typed 
boot
command the machine just sits, evidently in loader.

In this setup, the Dell mouse was plugged into a USB
port on the Dell keyboard, so apparently there's a hub
inside the keyboard. When I unplugged the mouse from
the keyboard and power cycled the Pi the Timeout poll....
messages were sparser but still present, and the kernel
booted without manual intervention. Startup eventually 
failed because of the missing storage devices, which
makes sense.

It appears that in my case the keyboard alone is enough
to make mischief. Next, an ALPHA8 image downloaded yesterday
written to an identical microSD card (Sandisk Ultra Plus
16 GB) was tried, with monitor and keyboard only connected. 

Again, Timeout poll messages appeared, but it looks as if
the machine again got stuck in loader. Typing boot seems
to have started the kernel, but then it got stuck with

Timeout poll on interrupt endpoint
bootTimeout poll on interrupt endpoint

Using DTB provided by EFI at 0x7ff7000.
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
EFI framebuffer information:
addr, size     0x3e330000, 0x8ca000
dimensions     1920 x 1200
stride         1920
masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
panic: Too many early devmap mappings 2
cpuid = 0
time = 1
KDB: stack backtrace:
#0 0xffff0000003cc644 at ??+0
#1 0xffff000000387e7c at ??+0
#2 0xffff000000387c28 at ??+0
#3 0xffff0000006e4884 at ??+0
#4 0xffff000000250c1c at ??+0
#5 0xffff00000025314c at ??+0
#6 0xffff00000032b800 at ??+0
#7 0xffff0000006a6108 at ??+0
Uptime: 1s

In my case the keyboard seems to be the root of the trouble.
It's a Dell model SK-8125, probably ten years old, bought
from a University surplus store.

As a final test, I unplugged the PL2303 USB-serial adapter which
had been in place throughout (I'd forgotten about it). On reboot
the  video console emitted sporadic non-latin characters and
didn't progress past loader, far as I can tell.

Output on the Pi3's serial console turned to complete gobbldygook,
mostly unprintable with a few latin characters sprinkled in.

In complete confusion, I tried again with the ALPHA8 snapshot,
same story. 

At wit's end, I again removed both USB flash drives, leaving only
the keyboard connected: No mouse, no PL2303. Same story.

Finally, I pulled the keyboard plug. Both microSD cards put
on the video console

Net: No Ethernet found

Starting USB
USB0: Scanning Bus 0......3 devices found
      Scanning for storage devices.....0 found
Hit any key to stop autoboot: 0
U-boot> [unprintable]

In the meantime a flood of non-ASCII characters came out of the serial console,
interspersed with familiar text.

That pulling the PL2303 made matters worse was a real shock. Putting it back
repeated former behavior, stopping with
panic: Too many early devmap mappings 2`
so it's not a fluke. 

If there is something you'd like me to try please
let me know. 

Thanks for reading, apologies for the convoluted  story!

bob prohaska