Thread (20 messages) 20 messages, 7 authors, 2021-07-16

Re: [EXT] Re: [PATCH v1 3/4] serial: 8250_pci: Always try MSI/MSI-X

From: Ralf Ramsauer <hidden>
Date: 2021-07-16 13:07:23
Also in: lkml


On 14/07/2021 15:35, Andy Shevchenko wrote:
On Wed, Jul 14, 2021 at 3:56 PM Ralf Ramsauer
[off-list ref] wrote:
quoted
On 14/07/2021 08:54, Jiri Slaby wrote:
quoted
On 13. 07. 21, 12:40, Andy Shevchenko wrote:
quoted
quoted
Hmm, have you checked the commit which introduced the whitelist?

    Nevertheless, this needs to handled with care: while many 8250 devices
    actually claim to support MSI(-X) interrupts it should not be
enabled be
    default. I had at least one device in my hands with broken MSI
    implementation.

    So better introduce a whitelist with devices that are known to support
    MSI(-X) interrupts. I tested all devices mentioned in the patch.


You should have at least CCed the author for an input.
Yep, back then I was testing three different 8250 pci cards. All of them
claimed to support MSI, while one really worked with MSI, the one that I
whitelisted. So I thought it would be better to use legacy IRQs as long
as no one tested a specific card to work with MSI.
Can you shed a light eventually what those cards are?
So I found a no-name el-cheapo card that has some issues with MSI:

18:00.0 Serial controller: Device 1c00:3253 (rev 10) (prog-if 05 [16850])

The card comes with two serial lines. It comes perfectly up, if I enable
it to use MSI in the whitelist:

serial 0000:18:00.0: Using MSI(-X) interrupts
serial 0000:18:00.0: Setup PCI port: port 40c0, irq 104, type 0
0000:18:00.0: ttyS6 at I/O 0x40c0 (irq = 104, base_baud = 115200) is a
XR16850
serial 0000:18:00.0: Setup PCI port: port 40c8, irq 104, type 0
0000:18:00.0: ttyS7 at I/O 0x40c8 (irq = 104, base_baud = 115200) is a
XR16850

After loading 8250_pci, lspci -vvs 18:0.0 tells:

	Capabilities: [68] MSI: Enable+ Count=1/32 Maskable+ 64bit+
		Address: 00000000fee000b8  Data: 0000
		Masking: ffffffff  Pending: 00000000

Looks good so far. Now let's echo to the device.

$ echo asdf > /dev/ttyS6

-- stuck. The echoing process stucks at close():

write(1, "asdf\n", 5)                   = 5
close(1

Stuck in the sense of: the echo is still killable, no crashes. The same
happens if I try to access the device with stty. So something is odd
here. However, the Netmos cards that I whitelisted do a great job.

So I can't tell if I was just unlucky to grab a card that has issues
with MSI, and this is an exception rather than the rule…

HTH,
  Ralf

quoted
Don't do that… And don't convert it to a blacklist. A blacklist will
break users until they report that something doesn't work.
White list is not okay either. MSI in general is a right thing to do.
preventing users from MSI is asking for the performance degradation
and IRQ resource conflicts (in case the IRQ line is shared).

Besides that, shouldn't it be rather the specific field in private (to
8250_pci) structure than constantly growing list?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help