Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Oct 2018 16:00:54 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        bob prohaska <fbsd@www.zefox.net>
Cc:        Trevor Roydhouse <trev@sentry.org>, freebsd-arm@freebsd.org
Subject:   Re: Timeout poll on interrupt endpoint for RPI3 with keyboard and mouse
Message-ID:  <39B3886F-CFB2-4DFE-B7C5-517E4836774A@yahoo.com>
In-Reply-To: <20181001022415.GA63212@www.zefox.net>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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:
>>=20
>> You just need to change one character in the file=20
>> .../sys/arm64/include/pte.h - change the 4 to an 8 in this existing =
line:
>>=20
>> #define        PMAP_MAPDEV_EARLY_SIZE  (L2_SIZE * 4)
>>=20
>=20
> Ok, that wasn't hard 8-)
>=20
> The machine now boots with the monitor connected and continues to run=20=

> correctly when keyboard and mouse are plugged in.
>=20
> 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.=20
>=20
> Evidently it got stuck in loader, the boot command got it unstuck and
> after that all is normal.
>=20
> So, I guess the video issue was a distraction that's now fixed. The=20
> problem with USB mouse and keyboard remain unresolved but nonfatal. =20=


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=20
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@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 =20
efipart_readwrite: rw=3D1, blk=3D64 size=3D1 status=3D7
efipart_readwrite: rw=3D1, blk=3D1 size=3D1 status=3D7

After a minute(?) wait there was:

efipart_readwrite: rw=3D1, blk=3D104383 size=3D8 status=3D7

And another wait:

efipart_readwrite: rw=3D1, blk=3D2079 size=3D257 status=3D7
-

(That "-" was in the serial console output.)

Another wait, then:

efipart_readwrite: rw=3D1, blk=3D64 size=3D1 status=3D7

EFI: Watchdog timeout
resetting ...
MMC:   mmc@7e300000: 1
Loading Environment from FAT... *** Warning - bad CRC, using default =
environment
. . .

It booted fine from there.

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39B3886F-CFB2-4DFE-B7C5-517E4836774A>