Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Oct 2018 18:10:17 -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:  <FF00521B-D8C6-4345-A6E4-0CF48BC280EA@yahoo.com>
In-Reply-To: <39B3886F-CFB2-4DFE-B7C5-517E4836774A@yahoo.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> <39B3886F-CFB2-4DFE-B7C5-517E4836774A@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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:
>=20
>> 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=

>=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.)
>=20
> The same is true when both are plugged into a powered hub
> that is in turn plugged into the rpi3.
>=20
> But with just one of the two plugged in I do not get the
> messages, directly plugged in or via the powered hub.
>=20
> The monitor HDMI connector makes no difference for if it is
> plugged in or not.
>=20
> (Ethernet and the serial console were connected and
> active during the experiments.)
>=20
> 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.)
>=20
> 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.
>=20
> When I instead tried just 2 such readers via the powered hub,
> instead the boot hung up for booting after shutdown -r now,
> showing:
>=20
> 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
>=20
> After a minute(?) wait there was:
>=20
> efipart_readwrite: rw=3D1, blk=3D104383 size=3D8 status=3D7
>=20
> And another wait:
>=20
> efipart_readwrite: rw=3D1, blk=3D2079 size=3D257 status=3D7
> -
>=20
> (That "-" was in the serial console output.)
>=20
> Another wait, then:
>=20
> efipart_readwrite: rw=3D1, blk=3D64 size=3D1 status=3D7
>=20
> EFI: Watchdog timeout
> resetting ...
> MMC:   mmc@7e300000: 1
> Loading Environment from FAT... *** Warning - bad CRC, using default =
environment
> . . .
>=20
> It booted fine from there.
>=20

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.

=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?FF00521B-D8C6-4345-A6E4-0CF48BC280EA>