Date: Tue, 2 Oct 2018 18:19:30 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: Trevor Roydhouse <trev@sentry.org>, freebsd-arm@freebsd.org, Mark Millard <marklmi@yahoo.com>, bob prohaska <fbsd@www.zefox.net> Subject: Re: Timeout poll on interrupt endpoint for RPI3 with keyboard and mouse Message-ID: <20181003011930.GA84788@www.zefox.net> In-Reply-To: <20181002203135.245edff2acfcbd8441d67cc3@bidouilliste.com> References: <20180929185213.GA58381@www.zefox.net> <20180930111208.5df04f5b7fb336cdfcf2fd74@bidouilliste.com> <20180930130930.GB58381@www.zefox.net> <20180930132928.GC58381@www.zefox.net> <20180930155055.2c35693431e8dfff4eb7d7bd@bidouilliste.com> <20180930145702.GD58381@www.zefox.net> <ace02a4a-3a79-6d3f-69ee-82d6c3477388@sentry.org> <20181001022415.GA63212@www.zefox.net> <20181002203135.245edff2acfcbd8441d67cc3@bidouilliste.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181003011930.GA84788>