From nobody Thu Nov 11 17:42:42 2021 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7BD04183A0A5 for ; Thu, 11 Nov 2021 17:42:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hqpvk2v86z3Gst for ; Thu, 11 Nov 2021 17:42:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 453F4109CE for ; Thu, 11 Nov 2021 17:42:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 1ABHggSr071106 for ; Thu, 11 Nov 2021 17:42:42 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1ABHggGF071105 for bugs@FreeBSD.org; Thu, 11 Nov 2021 17:42:42 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 259781] Serial ports intermittently not getting any data Date: Thu, 11 Nov 2021 17:42:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: mark@kane.mn X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259781 Bug ID: 259781 Summary: Serial ports intermittently not getting any data Product: Base System Version: 13.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: mark@kane.mn Created attachment 229433 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D229433&action= =3Dedit dmesg_amd64 I'm running into an issue with serial ports randomly not seeing any data on certain boots where nothing has changed, except rebooting. After hundreds of boot tests the problem occurs about 40% of the time.=20 For debugging purposes I have simplified the setup down to just 2 serial po= rts and seeing if cu(1) in base is able to see data. The actual application is 4 serial ports each accessed by their own Java application. - For example, /dev/ttyu1 is connected to a temperature sensor that constan= tly outputs data and /dev/ttyu4 is connected to a GPS receiver that constantly outputs data. - On any given boot of FreeBSD, cu(1) may see data from one, both, or neith= er of the ports. In the case where a port isn't receiving data, cu(1) prints "Connected" but there is no data from the serial port. - Without making any changes to the system, rebooting via `shutdown -r now`, `shutdown -p now`, or `shutdown -c now` may allow one or both of the serial ports to start seeing data again. - On the next boot with no changes the behavior seems random whether one, b= oth, or neither port will have data. - On a test round with 200 reboots and no changes made, 85 boots have at le= ast one of the serial ports in the broken state with no data and the other 115 reboots have both ports working correctly. - No amount of fiddling with stty options has changed this behavior. The default lines for these ports in /etc/ttys being present or commented out a= lso seems to have no effect. - hw.puc.msi_disable=3D1 has no effect. - I have not found any way to "reset" the ports back to a working state with data while FreeBSD is booted short of trying a reboot, which may or may not allow either/both ports to work again. - Does not appear to be a hardware issue. Testing the same serial ports on OpenBSD or Linux has 0 failures after 100+ boots of each OS. - Tested on both amd64 hardware and i386-only hardware, and multiple identi= cal units of each arch. Attached are dmesgs from both the amd64 and i386 hardware. Any thoughts or potential workarounds to try would be much appreciated. Thanks. --=20 You are receiving this mail because: You are the assignee for the bug.=