From owner-freebsd-arm@freebsd.org Tue Oct 2 01:10:26 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D113A10AF9E3 for ; Tue, 2 Oct 2018 01:10:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-22.consmr.mail.ne1.yahoo.com (sonic305-22.consmr.mail.ne1.yahoo.com [66.163.185.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5FB577482F for ; Tue, 2 Oct 2018 01:10:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: EQHejeIVM1lVhXtwzv_KKxnBA55KcH8BOTh72W_OoSc5fBw6N8WKAumFnCiY4c3 j8ASlu015LLvGosDn_EYZ4kOVwWvbz9Q.3YNSRVeSWMgvWrffFrfPyAxtqlg_2BswQHaFQksoeSW wbF5KDps.BrE_aNFX4SQu1Xb1Pu6pW87TEigPThEjLdw19o71SyE5g9weF5jOvsidy3mvuzlO8jO 78bzVwDXySYk827DtJ7BPZpHBnQcGgmMBlSXygxNJHgFXZzxQBnG0WyBpF_l.MS0wKhPGXFkLZqg AkVFsSAPaqltIlhQbQZu4HIOv5EFz55CeUuBPonDQcGETdlc9QsnMLixAEUWLKopKWcb7cTleg5S nLT0I1DqC3B8dpC26rCcw71USGzG1QRgyeOmthTGrVXztFgHfVOsnit8yPnuyKViMxJsLJXFLWZw aLXmcvO6up0fV_Tw_kLiDhQJwBAECIV4dbRDGR0QySio8f6JG3464CUw6NuZ642BZ75sYNDTyloM jJPBBm8A4GDda1RuVF7zpKbmJXOpG2mD6X6TSkFVAfIQhe5SRM5NMsJrYcsMB8Q9FWMBQXdZiOD1 rrrYhd1BwvbF6ybYJWP2pHn2T3_.WKhkKGFh7MGiRe4Tkb_GGwVEoHi..8LuUyJ0WPJspX.X_Q3i ny2YyNJbswnHN9FSQ7nXQJ4VA55fWFOc0KnWDhN9tDRlnDEuJVYKGTgh4t5uurrdnagydDPE6fYD KTdoPqiP7S5mDz5plG52CtB6__ClwyTGDHfAbrzGc.FI6z0XAfuaGKlfqe7hX6_0UlnT8a_k1MH3 XW1_dn8y6Pcz.gSwXoLWa2Z__gVJjCGFaMS2dobyKxcy6vodWrceXoFdbdJA1kCctPJ1qKmrD_2g GeX5pCUZZeN1Z6G6XQ9CdiZ0Ji0bVbcqA5LrGI9mdiV7W0tqmvkrFML0kAmXI.XRMQjIrR4ZPvP0 I6z.RCTGWJA6TRqNAdbeycl9OLon2VLS6b2wFcQHwy_18i0t_aV9e7NqANCO9MwYM7fDr31VlMMa sorkQHcE7u9yB5R8Yyw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Tue, 2 Oct 2018 01:10:23 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.101]) ([76.115.7.162]) by smtp405.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 29f6b4cc1a8b50f6fba573fcae5942ca; Tue, 02 Oct 2018 01:10:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Timeout poll on interrupt endpoint for RPI3 with keyboard and mouse From: Mark Millard In-Reply-To: <39B3886F-CFB2-4DFE-B7C5-517E4836774A@yahoo.com> Date: Mon, 1 Oct 2018 18:10:17 -0700 Cc: Trevor Roydhouse , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: 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> <20181001022415.GA63212@www.zefox.net> <39B3886F-CFB2-4DFE-B7C5-517E4836774A@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 01:10:26 -0000 On 2018-Oct-1, at 4:00 PM, Mark Millard wrote: > On 2018-Sep-30, at 7:24 PM, bob prohaska = 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)