This is a note to let you know that I've just added the patch titled
serial: 8250_pci: Add support for new HPE serial device
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From e0e24208792080135248f23fdf6d51aa2e04df05 Mon Sep 17 00:00:00 2001
From: Randy Wright <rwright(a)hpe.com>
Date: Fri, 14 May 2021 10:26:54 -0600
Subject: serial: 8250_pci: Add support for new HPE serial device
Add support for new HPE serial device. It is MSI enabled,
but otherwise similar to legacy HP server serial devices.
Tested-by: Jerry Hoemann <jerry.hoemann(a)hpe.com>
Signed-off-by: Randy Wright <rwright(a)hpe.com>
Cc: stable <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/1621009614-28836-1-git-send-email-rwright@hpe.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_pci.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index 689d8227f95f..04fe42469990 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -56,6 +56,8 @@ struct serial_private {
int line[];
};
+#define PCI_DEVICE_ID_HPE_PCI_SERIAL 0x37e
+
static const struct pci_device_id pci_use_msi[] = {
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9900,
0xA000, 0x1000) },
@@ -63,6 +65,8 @@ static const struct pci_device_id pci_use_msi[] = {
0xA000, 0x1000) },
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9922,
0xA000, 0x1000) },
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_HP_3PAR, PCI_DEVICE_ID_HPE_PCI_SERIAL,
+ PCI_ANY_ID, PCI_ANY_ID) },
{ }
};
@@ -1997,6 +2001,16 @@ static struct pci_serial_quirk pci_serial_quirks[] = {
.init = pci_hp_diva_init,
.setup = pci_hp_diva_setup,
},
+ /*
+ * HPE PCI serial device
+ */
+ {
+ .vendor = PCI_VENDOR_ID_HP_3PAR,
+ .device = PCI_DEVICE_ID_HPE_PCI_SERIAL,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .setup = pci_hp_diva_setup,
+ },
/*
* Intel
*/
@@ -4973,6 +4987,10 @@ static const struct pci_device_id serial_pci_tbl[] = {
{ PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_DIVA_AUX,
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
pbn_b2_1_115200 },
+ /* HPE PCI serial device */
+ { PCI_VENDOR_ID_HP_3PAR, PCI_DEVICE_ID_HPE_PCI_SERIAL,
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ pbn_b1_1_115200 },
{ PCI_VENDOR_ID_DCI, PCI_DEVICE_ID_DCI_PCCOM2,
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
--
2.31.1
This is a note to let you know that I've just added the patch titled
serial: 8250: Add UART_BUG_TXRACE workaround for Aspeed VUART
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From df8f2be2fd0b44b2cb6077068f52e05f0ac40897 Mon Sep 17 00:00:00 2001
From: Andrew Jeffery <andrew(a)aj.id.au>
Date: Thu, 20 May 2021 11:43:33 +0930
Subject: serial: 8250: Add UART_BUG_TXRACE workaround for Aspeed VUART
Aspeed Virtual UARTs directly bridge e.g. the system console UART on the
LPC bus to the UART interface on the BMC's internal APB. As such there's
no RS-232 signalling involved - the UART interfaces on each bus are
directly connected as the producers and consumers of the one set of
FIFOs.
The APB in the AST2600 generally runs at 100MHz while the LPC bus peaks
at 33MHz. The difference in clock speeds exposes a race in the VUART
design where a Tx data burst on the APB interface can result in a byte
lost on the LPC interface. The symptom is LSR[DR] remains clear on the
LPC interface despite data being present in its Rx FIFO, while LSR[THRE]
remains clear on the APB interface as the host has not consumed the data
the BMC has transmitted. In this state, the UART has stalled and no
further data can be transmitted without manual intervention (e.g.
resetting the FIFOs, resulting in loss of data).
The recommended work-around is to insert a read cycle on the APB
interface between writes to THR.
Cc: ChiaWei Wang <chiawei_wang(a)aspeedtech.com>
Tested-by: ChiaWei Wang <chiawei_wang(a)aspeedtech.com>
Reviewed-by: Jiri Slaby <jirislaby(a)kernel.org>
Signed-off-by: Andrew Jeffery <andrew(a)aj.id.au>
Cc: stable <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/20210520021334.497341-2-andrew@aj.id.au
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250.h | 1 +
drivers/tty/serial/8250/8250_aspeed_vuart.c | 1 +
drivers/tty/serial/8250/8250_port.c | 12 ++++++++++++
3 files changed, 14 insertions(+)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index 52bb21205bb6..34aa2714f3c9 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -88,6 +88,7 @@ struct serial8250_config {
#define UART_BUG_NOMSR (1 << 2) /* UART has buggy MSR status bits (Au1x00) */
#define UART_BUG_THRE (1 << 3) /* UART has buggy THRE reassertion */
#define UART_BUG_PARITY (1 << 4) /* UART mishandles parity if FIFO enabled */
+#define UART_BUG_TXRACE (1 << 5) /* UART Tx fails to set remote DR */
#ifdef CONFIG_SERIAL_8250_SHARE_IRQ
diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
index 61550f24a2d3..d035d08cb987 100644
--- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
+++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
@@ -437,6 +437,7 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
port.port.status = UPSTAT_SYNC_FIFO;
port.port.dev = &pdev->dev;
port.port.has_sysrq = IS_ENABLED(CONFIG_SERIAL_8250_CONSOLE);
+ port.bugs |= UART_BUG_TXRACE;
rc = sysfs_create_group(&vuart->dev->kobj, &aspeed_vuart_attr_group);
if (rc < 0)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index d45dab1ab316..fc5ab2032282 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1809,6 +1809,18 @@ void serial8250_tx_chars(struct uart_8250_port *up)
count = up->tx_loadsz;
do {
serial_out(up, UART_TX, xmit->buf[xmit->tail]);
+ if (up->bugs & UART_BUG_TXRACE) {
+ /*
+ * The Aspeed BMC virtual UARTs have a bug where data
+ * may get stuck in the BMC's Tx FIFO from bursts of
+ * writes on the APB interface.
+ *
+ * Delay back-to-back writes by a read cycle to avoid
+ * stalling the VUART. Read a register that won't have
+ * side-effects and discard the result.
+ */
+ serial_in(up, UART_SCR);
+ }
xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
port->icount.tx++;
if (uart_circ_empty(xmit))
--
2.31.1
Even with rate limited reporting this is very spammy and since
it is remote device that is providing bogus data there is no
need to report this as error.
Since real_len variable was used only to allow conditional error
message it is now also removed.
[72454.143336] bt_err_ratelimited: 10 callbacks suppressed
[72454.143337] Bluetooth: hci0: advertising data len corrected
[72454.296314] Bluetooth: hci0: advertising data len corrected
[72454.892329] Bluetooth: hci0: advertising data len corrected
[72455.051319] Bluetooth: hci0: advertising data len corrected
[72455.357326] Bluetooth: hci0: advertising data len corrected
[72455.663295] Bluetooth: hci0: advertising data len corrected
[72455.787278] Bluetooth: hci0: advertising data len corrected
[72455.942278] Bluetooth: hci0: advertising data len corrected
[72456.094276] Bluetooth: hci0: advertising data len corrected
[72456.249137] Bluetooth: hci0: advertising data len corrected
[72459.416333] bt_err_ratelimited: 13 callbacks suppressed
[72459.416334] Bluetooth: hci0: advertising data len corrected
[72459.721334] Bluetooth: hci0: advertising data len corrected
[72460.011317] Bluetooth: hci0: advertising data len corrected
[72460.327171] Bluetooth: hci0: advertising data len corrected
[72460.638294] Bluetooth: hci0: advertising data len corrected
[72460.946350] Bluetooth: hci0: advertising data len corrected
[72461.225320] Bluetooth: hci0: advertising data len corrected
[72461.690322] Bluetooth: hci0: advertising data len corrected
[72462.118318] Bluetooth: hci0: advertising data len corrected
[72462.427319] Bluetooth: hci0: advertising data len corrected
[72464.546319] bt_err_ratelimited: 7 callbacks suppressed
[72464.546319] Bluetooth: hci0: advertising data len corrected
[72464.857318] Bluetooth: hci0: advertising data len corrected
[72465.163332] Bluetooth: hci0: advertising data len corrected
[72465.278331] Bluetooth: hci0: advertising data len corrected
[72465.432323] Bluetooth: hci0: advertising data len corrected
[72465.891334] Bluetooth: hci0: advertising data len corrected
[72466.045334] Bluetooth: hci0: advertising data len corrected
[72466.197321] Bluetooth: hci0: advertising data len corrected
[72466.340318] Bluetooth: hci0: advertising data len corrected
[72466.498335] Bluetooth: hci0: advertising data len corrected
[72469.803299] bt_err_ratelimited: 10 callbacks suppressed
Signed-off-by: Szymon Janc <szymon.janc(a)codecoup.pl>
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=203753
Cc: stable(a)vger.kernel.org
---
net/bluetooth/hci_event.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 5e99968939ce..f15d8b85571a 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -5441,7 +5441,7 @@ static void process_adv_report(struct hci_dev *hdev, u8 type, bdaddr_t *bdaddr,
struct hci_conn *conn;
bool match;
u32 flags;
- u8 *ptr, real_len;
+ u8 *ptr;
switch (type) {
case LE_ADV_IND:
@@ -5472,14 +5472,10 @@ static void process_adv_report(struct hci_dev *hdev, u8 type, bdaddr_t *bdaddr,
break;
}
- real_len = ptr - data;
-
- /* Adjust for actual length */
- if (len != real_len) {
- bt_dev_err_ratelimited(hdev, "advertising data len corrected %u -> %u",
- len, real_len);
- len = real_len;
- }
+ /* Adjust for actual length. This handles the case when remote
+ * device is advertising with incorrect data length.
+ */
+ len = ptr - data;
/* If the direct address is present, then this report is from
* a LE Direct Advertising Report event. In that case it is
--
2.31.1
From: Joerg M. Sigle <joerg.sigle(a)jsigle.com>
Patch 416fa531c816 commit 416fa531c8160151090206a51b829b9218b804d9 caused
an immediate kernel panic on boot at RIP: 0010:__domain_mapping+0xa7/0x3a0
with longterm kernel 5.10.37 configured w/ CONFIG_INTEL_IOMMU_DEFAULT_ON=y
due to removal of a check. Putting the check back in place fixes this.
The kernel panic was observed on various Intel Core i7 i5 i3 CPUs from
Sandy Bridge, Haswell, Broadwell and Kaby Lake generations (at least).
It may NOT be reproducible on some older CPU generations.
Suppressing the panic with boot parameter intel_iommu=off is diagnostic.
See: https://bugzilla.kernel.org/show_bug.cgi?id=213077https://bugzilla.kernel.org/show_bug.cgi?id=213087https://bugzilla.kernel.org/show_bug.cgi?id=213095
Signed-off-by: Joerg M. Sigle <joerg.sigle(a)jsigle.com>
Acked-by: Lu Baolu <baolu.lu(a)linux.intel.com>
---
Hi Greg, thanks for your response.
> Are you sure that 5.10.38 doesn't already fix this issue? We resolved
> an issue in this area.
Yes, I'm sure.
Your a282b76166b13496967c70bd61ea8f03609d8a76 simply reverts the offending patch.
My approach corrects it instead.
I have submitted that properly before, don't know why it hasn't found you yet.
I'm including the "proper" submission info above.
The file with the patch is attached again again.
If I should send it to another address, please tell me.
Communication with Lu Baolu who saw it last Monday is also attached below.
Hope this contribution is helpful. Thanks & kind regards! Joerg
Am 20.05.2021 um 10:52 schrieb Greg KH:
> On Thu, May 20, 2021 at 09:47:40AM +0200, Joerg M. Sigle wrote:
>> Dear colleaguse
>>
>> I've submitted a patch for 5.10.37 that wasn't included in 5.10.38,
>> which would have corrected a patch that has been reverted instead.
>>
>> More info:
>> https://bugzilla.kernel.org/show_bug.cgi?id=213077
>>
>> Now sending to the other kernel list, according to autoresponse
>> from Greg Kroah-Hartman.
>>
>> Thanks for any feedback & Kind regards, Joerg Sigle
>
> Are you sure that 5.10.38 doesn't already fix this issue? We resolved
> an issue in this area.
>
> And where is the patch, I can't find it in this email, can you submit it
> "properly" so that it can be reviewed?
>
> thanks,
>
> greg k-h
>
---
Dear colleagues,
Please find the suggested patch in the attachment, now reformatted to include the affected C function.
It fixes a problem in LT kernel 5.10.37; I'm asking for inclusion into LT kernel 5.10.38.
I'm submitting this now, after receiving Lu Baolu's positive response attached below.
Baolu, I hope that the line "Acked-by: Lu Baolu ..." is ok given your comment.
I hope I'm providing this in a useful way, following
https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html
I'm still unsure whether this line should be added above:
Cc: stable(a)vger.kernel.org
Please add this if needed, also considering Baolu's comment re. upstream/backported.
Thanks and kind regards to all! Joerg
Am 17.05.2021 um 04:51 schrieb Lu Baolu:
> Hi Joerg,
>
> On 5/16/21 7:57 AM, Joerg M. Sigle wrote:
>> Dear colleagues at Intel
>>
>> could you please check the enclosed bug report
>> and confirm whether the suggested patch is valid.
>>
>> Thank you very much & kind regards - Joerg
>>
>>
>> -------- Weitergeleitete Nachricht --------
>> From: bugzilla-daemon(a)bugzilla.kernel.org
>> To: joerg.sigle(a)jsigle.com
>> Subject: [Bug 213077] Kernel 5.10.37 immediately panics at boot w/ Intel Core i7-4910MQ Haswell or Core i3-5010U Broadwell w/ custom .config CONFIG_INTEL_IOMMU_DEFAULT_ON=y, same config worked with 5.10.36, due to commit 416fa531c816 =
>> a8ce9ebbecdfda3322bbcece6b3b25888217f8e3
>> Date: Sat, 15 May 2021 23:47:39 +0000
>> X-Envelope-To: joerg.sigle(a)jsigle.com
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=213077
>>
>> --- Comment #7 from Joerg M. Sigle (joerg.sigle(a)jsigle.com) ---
>> This patch:
>>
>> 416fa531c816 iommu/vt-d: Preset Access/Dirty bits for IOVA over FL
>> commit 416fa531c8160151090206a51b829b9218b804d9
>> Upstream commit a8ce9ebbecdfda3322bbcece6b3b25888217f8e3
>>
>> https://github.com/arter97/x86-kernel/commit/416fa531c8160151090206a51b829b…
>>
>> while doing other things, changed the conditional:
>>
>> if (!sg) { ...
>> sg_res = nr_pages;
>> pteval = ((phys_addr_t)phys_pfn << VTD_PAGE_SHIFT) | attr;
>> }
>>
>> to an unconditional:
>>
>> pteval = ((phys_addr_t)phys_pfn << VTD_PAGE_SHIFT) | attr;
>>
>> Reinserting the check for !sg fixed the immediate panic on boot for me.
>> Reverting the remainder of the same patch had not helped before.
>>
>> Here's a possible patch for 5.10.37:
>>
>> -------------------------------------------------------------------------
>> --- a/drivers/iommu/intel/iommu.c 2021-05-14 09:50:46.000000000 +0200
>> +++ b/drivers/iommu/intel/iommu.c 2021-05-16 01:02:17.816810690 +0200
>> @@ -2373,7 +2373,10 @@
>> }
>> }
>>
>> - pteval = ((phys_addr_t)phys_pfn << VTD_PAGE_SHIFT) | attr;
>> + if (!sg) {
>> + sg_res = nr_pages;
>> + pteval = ((phys_addr_t)phys_pfn << VTD_PAGE_SHIFT) | attr;
>> + }
>>
>> while (nr_pages > 0) {
>> uint64_t tmp;
>> -------------------------------------------------------------------------
>>
>> Could you please check this patch submission and pass it to upstream?
>
>
> Above fix looks good to me.
>
> This issue is caused by the back-ported patch for stable v5.10.37.
> There's no need for upstream.
>
> Best regards,
> baolu
>
>>
>> I have, however, NOT tried to understand what the code really does.
>> So please ask the suppliers of patch 416fa531c816 whether their
>> removal of the condition was intentional or a mere lapsus. Thanks!
>>
>> Thanks and kind regards, Joerg
>>
>
--
-------------------------------------------------------------------
Dr. med. Jörg M. Sigle +41 76 276 86 94
http://www.ql-recorder.com +41 32 510 23 46
http://www.jsigle.com +49 176 96 43 54 13