Date: Tue, 2 Dec 2014 22:04:27 +0000 (UTC) From: Brooks Davis <brooks@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-10@freebsd.org Subject: svn commit: r275429 - stable/10/sys/dev/altera/jtag_uart Message-ID: <201412022204.sB2M4RFZ071864@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: brooks Date: Tue Dec 2 22:04:27 2014 New Revision: 275429 URL: https://svnweb.freebsd.org/changeset/base/275429 Log: MFC r274821: Merge from CheriBSD: commit d0c7d235c09fc65dbdb278e7016a96f79c6a49cc Make the Altera JTAG UART device driver slightly more forgiving of the foibles of a sub-par hrdware interface by increasing the timeout for spotting JTAG polling from one to two seconds. commit 19ed45a18832560dab967c179d83b71081c3a220 Update comment. commit 8edfe803f033cc8e33229f99894c2b7496a44d5f Add a comment about a device-driver race condition that could cause the BERI pipeline to wedge awaiting JTAG in the event that both the low-level console and the tty layer decide to write to the JTAG FIFO just before JTAG is disconnected. Resolving this race is a bit tricky as it looks like there isn't a way to 'give the character back' to the tty layer when we discover the race. The easy fix is to drop the character, which we don't yet do, but perhaps should as that is a better outcome than wedging the pipeline. commit 2ea26cf579c9defcf31e413e7c9b0fbc159237fc Add a comment about an inherent race with hardware in the Altera JTAG UART's low-level console code. Submitted by: rwatson Sponsored by: DARPA, AFRL Modified: stable/10/sys/dev/altera/jtag_uart/altera_jtag_uart_cons.c stable/10/sys/dev/altera/jtag_uart/altera_jtag_uart_tty.c Directory Properties: stable/10/ (props changed) Modified: stable/10/sys/dev/altera/jtag_uart/altera_jtag_uart_cons.c ============================================================================== --- stable/10/sys/dev/altera/jtag_uart/altera_jtag_uart_cons.c Tue Dec 2 21:23:13 2014 (r275428) +++ stable/10/sys/dev/altera/jtag_uart/altera_jtag_uart_cons.c Tue Dec 2 22:04:27 2014 (r275429) @@ -221,6 +221,9 @@ aju_cons_write(char ch) * disconnection. * * XXXRW: The polling delay may require tuning. + * + * XXXRW: Notice the inherent race with hardware: in clearing the + * bit, we may race with hardware setting the same bit. */ v = aju_cons_control_read(); if (v & ALTERA_JTAG_UART_CONTROL_AC) { Modified: stable/10/sys/dev/altera/jtag_uart/altera_jtag_uart_tty.c ============================================================================== --- stable/10/sys/dev/altera/jtag_uart/altera_jtag_uart_tty.c Tue Dec 2 21:23:13 2014 (r275428) +++ stable/10/sys/dev/altera/jtag_uart/altera_jtag_uart_tty.c Tue Dec 2 22:04:27 2014 (r275429) @@ -65,9 +65,9 @@ static struct ttydevsw aju_ttydevsw = { /* * When polling for the AC bit, the number of times we have to not see it - * before assuming JTAG has disappeared on us. By default, one second. + * before assuming JTAG has disappeared on us. By default, two seconds. */ -#define AJU_JTAG_MAXMISS 5 +#define AJU_JTAG_MAXMISS 10 /* * Polling intervals for input/output and JTAG connection events. @@ -255,6 +255,22 @@ aju_handle_output(struct altera_jtag_uar if (ttydisc_getc(tp, &ch, sizeof(ch)) != sizeof(ch)) panic("%s: ttydisc_getc", __func__); AJU_LOCK(sc); + + /* + * XXXRW: There is a slight race here in which we test + * for writability, drop the lock, get the character + * from the tty layer, re-acquire the lock, and then + * write. It's possible for other code -- + * specifically, the low-level console -- to have + * written in the mean time, which might mean that + * there is no longer space. The BERI memory bus will + * cause this write to block, wedging the processor + * until space is available -- which could be a while + * if JTAG is not attached! + * + * The 'easy' fix is to drop the character if WSPACE + * has become unset. Not sure what the 'hard' fix is. + */ aju_data_write(sc, ch); } else { /*
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201412022204.sB2M4RFZ071864>