UARTs not working on a Supermicro A2SAV / Linux works ;-(

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

UARTs not working on a Supermicro A2SAV / Linux works ;-(

Andre Albsmeier-7
The UARTs on the brand new Supermicro A2SAV mainboard
(https://www.supermicro.com/products/motherboard/Atom/A2SAV.cfm)
are detected on 11.1-STABLE as

uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0

which is consistent with the BIOS settings.

Everything seems to work when it comes to setting of parameters and even
the DTR and RTS lines change state when opening cuau0 or cuau1, e.g. with
minicom.

But sending or receiving characters fails -- to be exact, no single
character will be received and only the very first one will be sent to
the remote device.

We remember this behaviour from the good old times when we had to jumper
base port addresses and IRQs on ISA cards: If we got the IRQ wrong the
same effect happened: The first char could be sent because the TX register
was empty but the IRQ telling the kernel that it can send the next char
never arrived.

When using debug.uart_force_poll=1 in loader.conf it works (at least if
we type in characters slowly, of course).

So it really seems to have to do with interrupts again but I have no
idea where to look.

The A2SAV manual talks about the Super I/O being a Nuvoton NCT5523D. Can
it be that we miss some support for this? But if the devices really behave
like standard 16550s we shouldn't need any specific support at all, I think.

I disabled the corresponding ACPI functions by using

debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1 \_SB_.PCI0.SBRG.UAR2"

and the devices were detected properly as

uart0: <16550 or compatible> at port 0x3f8 irq 4 flags 0x10 on isa0
uart1: <16550 or compatible> at port 0x2f8 irq 3 on isa0

but this didn't help (same behaviour).

The really bad news are: Using Linux (Ubuntu 16.04) it works. Devices are
detected here as:
...
[    0.261209] pnp 00:01: [dma 0 disabled]
[    0.261295] pnp 00:01: Plug and Play ACPI device, IDs PNP0501 (active)
[    0.261774] pnp 00:02: [dma 0 disabled]
[    0.261868] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active)
...
[    1.479082] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[    1.499962] 00:01: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[    1.520943] 00:02: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A

and we can send and receive characters without problems.

So it really seems FreeBSD does something wrong on the A2SAV board when
it comes to interrupts of the serial ports.

Any ideas how to start?
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: UARTs not working on a Supermicro A2SAV / Linux works ;-(

Konstantin Belousov
On Tue, Mar 13, 2018 at 06:14:32PM +0100, Andre Albsmeier wrote:

> The UARTs on the brand new Supermicro A2SAV mainboard
> (https://www.supermicro.com/products/motherboard/Atom/A2SAV.cfm)
> are detected on 11.1-STABLE as
>
> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
>
> which is consistent with the BIOS settings.
>
> Everything seems to work when it comes to setting of parameters and even
> the DTR and RTS lines change state when opening cuau0 or cuau1, e.g. with
> minicom.
>
> But sending or receiving characters fails -- to be exact, no single
> character will be received and only the very first one will be sent to
> the remote device.
>
> We remember this behaviour from the good old times when we had to jumper
> base port addresses and IRQs on ISA cards: If we got the IRQ wrong the
> same effect happened: The first char could be sent because the TX register
> was empty but the IRQ telling the kernel that it can send the next char
> never arrived.
>
> When using debug.uart_force_poll=1 in loader.conf it works (at least if
> we type in characters slowly, of course).
>
> So it really seems to have to do with interrupts again but I have no
> idea where to look.
>
> The A2SAV manual talks about the Super I/O being a Nuvoton NCT5523D. Can
> it be that we miss some support for this? But if the devices really behave
> like standard 16550s we shouldn't need any specific support at all, I think.
>
> I disabled the corresponding ACPI functions by using
>
> debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1 \_SB_.PCI0.SBRG.UAR2"
>
> and the devices were detected properly as
>
> uart0: <16550 or compatible> at port 0x3f8 irq 4 flags 0x10 on isa0
> uart1: <16550 or compatible> at port 0x2f8 irq 3 on isa0
>
> but this didn't help (same behaviour).
>
> The really bad news are: Using Linux (Ubuntu 16.04) it works. Devices are
> detected here as:
> ...
> [    0.261209] pnp 00:01: [dma 0 disabled]
> [    0.261295] pnp 00:01: Plug and Play ACPI device, IDs PNP0501 (active)
> [    0.261774] pnp 00:02: [dma 0 disabled]
> [    0.261868] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active)
> ...
> [    1.479082] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
> [    1.499962] 00:01: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
> [    1.520943] 00:02: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
>
> and we can send and receive characters without problems.
>
> So it really seems FreeBSD does something wrong on the A2SAV board when
> it comes to interrupts of the serial ports.
>
> Any ideas how to start?

Bay Trail and later Atoms UARTS are not standard UARTs controllers, AFAIR
the registers are memory mapped, to start with.  They also support DMA, as
you can see from the linux dmesg.  Perhaps there are some incompatibilities
with the new implementation.

Can you show the vmstat -i output ? Are there any other non-MSI
interrupts used on the machine, do they work ?
For a minor chance, try to set hw.lapic_eoi_suppression to 0 at the
loader prompt.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: UARTs not working on a Supermicro A2SAV / Linux works ;-(

Luiz Otavio O Souza-4
On 13 March 2018 at 15:10, Konstantin Belousov <[hidden email]> wrote:

> On Tue, Mar 13, 2018 at 06:14:32PM +0100, Andre Albsmeier wrote:
>> The UARTs on the brand new Supermicro A2SAV mainboard
>> (https://www.supermicro.com/products/motherboard/Atom/A2SAV.cfm)
>> are detected on 11.1-STABLE as
>>
>> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
>> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
>>
>> which is consistent with the BIOS settings.
>>
>> Everything seems to work when it comes to setting of parameters and even
>> the DTR and RTS lines change state when opening cuau0 or cuau1, e.g. with
>> minicom.
>>
>> But sending or receiving characters fails -- to be exact, no single
>> character will be received and only the very first one will be sent to
>> the remote device.
>>
>> We remember this behaviour from the good old times when we had to jumper
>> base port addresses and IRQs on ISA cards: If we got the IRQ wrong the
>> same effect happened: The first char could be sent because the TX register
>> was empty but the IRQ telling the kernel that it can send the next char
>> never arrived.
>>
>> When using debug.uart_force_poll=1 in loader.conf it works (at least if
>> we type in characters slowly, of course).
>>
>> So it really seems to have to do with interrupts again but I have no
>> idea where to look.
>>
>> The A2SAV manual talks about the Super I/O being a Nuvoton NCT5523D. Can
>> it be that we miss some support for this? But if the devices really behave
>> like standard 16550s we shouldn't need any specific support at all, I think.
>>
>> I disabled the corresponding ACPI functions by using
>>
>> debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1 \_SB_.PCI0.SBRG.UAR2"
>>
>> and the devices were detected properly as
>>
>> uart0: <16550 or compatible> at port 0x3f8 irq 4 flags 0x10 on isa0
>> uart1: <16550 or compatible> at port 0x2f8 irq 3 on isa0
>>
>> but this didn't help (same behaviour).
>>
>> The really bad news are: Using Linux (Ubuntu 16.04) it works. Devices are
>> detected here as:
>> ...
>> [    0.261209] pnp 00:01: [dma 0 disabled]
>> [    0.261295] pnp 00:01: Plug and Play ACPI device, IDs PNP0501 (active)
>> [    0.261774] pnp 00:02: [dma 0 disabled]
>> [    0.261868] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active)
>> ...
>> [    1.479082] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
>> [    1.499962] 00:01: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
>> [    1.520943] 00:02: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
>>
>> and we can send and receive characters without problems.
>>
>> So it really seems FreeBSD does something wrong on the A2SAV board when
>> it comes to interrupts of the serial ports.
>>
>> Any ideas how to start?
>
> Bay Trail and later Atoms UARTS are not standard UARTs controllers, AFAIR
> the registers are memory mapped, to start with.  They also support DMA, as
> you can see from the linux dmesg.  Perhaps there are some incompatibilities
> with the new implementation.

The system has both, UARTs and HSUARTs, the later will not work.

Some recent BIOS have an option to route the system console to the first UART.

>
> Can you show the vmstat -i output ? Are there any other non-MSI
> interrupts used on the machine, do they work ?
> For a minor chance, try to set hw.lapic_eoi_suppression to 0 at the
> loader prompt.

There was an IOAPIC programming issue affecting these machines, it was
fixed by r327314.

Please Andre, can you check if this system boots fine with -head ?

Luiz
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: UARTs not working on a Supermicro A2SAV / Linux works ;-(

Kurt Lidl-2
In reply to this post by Andre Albsmeier-7
On 3/13/18 1:14 PM, Andre Albsmeier wrote:

> The UARTs on the brand new Supermicro A2SAV mainboard
> (https://www.supermicro.com/products/motherboard/Atom/A2SAV.cfm)
> are detected on 11.1-STABLE as
>
> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
>
> which is consistent with the BIOS settings.
>
> Everything seems to work when it comes to setting of parameters and even
> the DTR and RTS lines change state when opening cuau0 or cuau1, e.g. with
> minicom.
>
> But sending or receiving characters fails -- to be exact, no single
> character will be received and only the very first one will be sent to
> the remote device.
>
> We remember this behaviour from the good old times when we had to jumper
> base port addresses and IRQs on ISA cards: If we got the IRQ wrong the
> same effect happened: The first char could be sent because the TX register
> was empty but the IRQ telling the kernel that it can send the next char
> never arrived.
>
> When using debug.uart_force_poll=1 in loader.conf it works (at least if
> we type in characters slowly, of course).
>
> So it really seems to have to do with interrupts again but I have no
> idea where to look.
>
> The A2SAV manual talks about the Super I/O being a Nuvoton NCT5523D. Can
> it be that we miss some support for this? But if the devices really behave
> like standard 16550s we shouldn't need any specific support at all, I think.
>
> I disabled the corresponding ACPI functions by using
>
> debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1 \_SB_.PCI0.SBRG.UAR2"
>
> and the devices were detected properly as
>
> uart0: <16550 or compatible> at port 0x3f8 irq 4 flags 0x10 on isa0
> uart1: <16550 or compatible> at port 0x2f8 irq 3 on isa0
>
> but this didn't help (same behaviour).
>
> The really bad news are: Using Linux (Ubuntu 16.04) it works. Devices are
> detected here as:
> ...
> [    0.261209] pnp 00:01: [dma 0 disabled]
> [    0.261295] pnp 00:01: Plug and Play ACPI device, IDs PNP0501 (active)
> [    0.261774] pnp 00:02: [dma 0 disabled]
> [    0.261868] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active)
> ...
> [    1.479082] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
> [    1.499962] 00:01: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
> [    1.520943] 00:02: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
>
> and we can send and receive characters without problems.
>
> So it really seems FreeBSD does something wrong on the A2SAV board when
> it comes to interrupts of the serial ports.
>
> Any ideas how to start?

So, at my prior job, we had a custom board that used the Novuton NCT5104
as the chip that provided the serial ports.  One of the interesting
things about the NCT5104 is that one can use in a PCI-only environments
to provide serial ports.  It offers the serial ports that traditionally
would be provided by the traditonal Super I/O chipset, except that
rather than having a large number of I/O lines, it's a LPC
"low pin count" device.  We had no legacy parts on the boards we
manufactured, but we really, really wanted serial ports, so we ended up
with this chip to provide the serial ports.

Anyhow -- we had pretty much the same exact problem with the serial
ports on our card.  To make a long story short, I wrote a low-level
register dumper for the NCT5104. One can make it act like a traditional
NS16550A part, if you're willing to dink with the specific setup for
the NCT5104.

Here's the diff of the "non-working" serial port diagnostic, compared
to the corrected version:
#
diff results_broken.txt results_fixed.txt
64c64
< sio register 0xf0 - value: 0x00
---
 > sio register 0xf0 - value: 0x40
66c66
< IRQ mode: level
---
 > IRQ mode: pulse mode (for sharing)

If you have a BIOS setting that allows you to control the IRQ method
for the NCT part, try setting it to "pulse mode", rather than "level".

We ended up resolving the issue by having the board manufacturer rev
the BIOS, so that "BIOS defaults" value was set to "pulse mode", rather
than "level" for this controller, and then FreeBSD was happy to use
it as a regular old serial port.  Alternatively, you can probably
stick a little initialization bit of code in, to program the NCT5523D
to change the interrupt setting.

I was able to get the programming guide from Nuvoton just by asking
nicely, so you can probably get it too, if you needed it.

-Kurt
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: UARTs not working on a Supermicro A2SAV / Linux works ;-(

Andre Albsmeier-7
In reply to this post by Luiz Otavio O Souza-4
On Tue, 13-Mar-2018 at 16:31:07 -0300, Luiz Otavio O Souza wrote:

> On 13 March 2018 at 15:10, Konstantin Belousov <[hidden email]> wrote:
> > On Tue, Mar 13, 2018 at 06:14:32PM +0100, Andre Albsmeier wrote:
> >> The UARTs on the brand new Supermicro A2SAV mainboard
> >> (https://www.supermicro.com/products/motherboard/Atom/A2SAV.cfm)
> >> are detected on 11.1-STABLE as
> >>
> >> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
> >> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
> >>
> >> which is consistent with the BIOS settings.
> >>
> >> Everything seems to work when it comes to setting of parameters and even
> >> the DTR and RTS lines change state when opening cuau0 or cuau1, e.g. with
> >> minicom.
> >>
> >> But sending or receiving characters fails -- to be exact, no single
> >> character will be received and only the very first one will be sent to
> >> the remote device.
> >>
> >> We remember this behaviour from the good old times when we had to jumper
> >> base port addresses and IRQs on ISA cards: If we got the IRQ wrong the
> >> same effect happened: The first char could be sent because the TX register
> >> was empty but the IRQ telling the kernel that it can send the next char
> >> never arrived.
> >>
> >> When using debug.uart_force_poll=1 in loader.conf it works (at least if
> >> we type in characters slowly, of course).
> >>
> >> So it really seems to have to do with interrupts again but I have no
> >> idea where to look.
> >>
> >> The A2SAV manual talks about the Super I/O being a Nuvoton NCT5523D. Can
> >> it be that we miss some support for this? But if the devices really behave
> >> like standard 16550s we shouldn't need any specific support at all, I think.
> >>
> >> I disabled the corresponding ACPI functions by using
> >>
> >> debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1 \_SB_.PCI0.SBRG.UAR2"
> >>
> >> and the devices were detected properly as
> >>
> >> uart0: <16550 or compatible> at port 0x3f8 irq 4 flags 0x10 on isa0
> >> uart1: <16550 or compatible> at port 0x2f8 irq 3 on isa0
> >>
> >> but this didn't help (same behaviour).
> >>
> >> The really bad news are: Using Linux (Ubuntu 16.04) it works. Devices are
> >> detected here as:
> >> ...
> >> [    0.261209] pnp 00:01: [dma 0 disabled]
> >> [    0.261295] pnp 00:01: Plug and Play ACPI device, IDs PNP0501 (active)
> >> [    0.261774] pnp 00:02: [dma 0 disabled]
> >> [    0.261868] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active)
> >> ...
> >> [    1.479082] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
> >> [    1.499962] 00:01: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
> >> [    1.520943] 00:02: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
> >>
> >> and we can send and receive characters without problems.
> >>
> >> So it really seems FreeBSD does something wrong on the A2SAV board when
> >> it comes to interrupts of the serial ports.
> >>
> >> Any ideas how to start?
> >
> > Bay Trail and later Atoms UARTS are not standard UARTs controllers, AFAIR
> > the registers are memory mapped, to start with.  They also support DMA, as
> > you can see from the linux dmesg.  Perhaps there are some incompatibilities
> > with the new implementation.
>
> The system has both, UARTs and HSUARTs, the later will not work.

AFAIK the HSUARTs are not used on the A2SAV. The manual talks about
using a Nuvoton NCT5523D as IO chip.

>
> Some recent BIOS have an option to route the system console to the first UART.

Yes, I know this feature from some Atom 38xx BIOSes but on the
A2SAV there is none.

>
> >
> > Can you show the vmstat -i output ? Are there any other non-MSI
> > interrupts used on the machine, do they work ?
> > For a minor chance, try to set hw.lapic_eoi_suppression to 0 at the
> > loader prompt.
>
> There was an IOAPIC programming issue affecting these machines, it was
> fixed by r327314.
>
> Please Andre, can you check if this system boots fine with -head ?

Much better: I copied /sys/x86/x86/io_apic.c from -current to my
11.1-STABLE sources (there were no other differences apart from
the ones of r327314), built a new kernel and now it seems to work!

So this seems to be a MFC candidate and I am happy that I was not
wrong with my interrupt theory.

        -Andre
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: UARTs not working on a Supermicro A2SAV / Linux works ;-(

Andre Albsmeier-7
In reply to this post by Konstantin Belousov
On Tue, 13-Mar-2018 at 20:10:46 +0200, Konstantin Belousov wrote:

> On Tue, Mar 13, 2018 at 06:14:32PM +0100, Andre Albsmeier wrote:
> > The UARTs on the brand new Supermicro A2SAV mainboard
> > (https://www.supermicro.com/products/motherboard/Atom/A2SAV.cfm)
> > are detected on 11.1-STABLE as
> >
> > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
> > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
> >
> > which is consistent with the BIOS settings.
> >
> > Everything seems to work when it comes to setting of parameters and even
> > the DTR and RTS lines change state when opening cuau0 or cuau1, e.g. with
> > minicom.
> >
> > But sending or receiving characters fails -- to be exact, no single
> > character will be received and only the very first one will be sent to
> > the remote device.
> >
> > We remember this behaviour from the good old times when we had to jumper
> > base port addresses and IRQs on ISA cards: If we got the IRQ wrong the
> > same effect happened: The first char could be sent because the TX register
> > was empty but the IRQ telling the kernel that it can send the next char
> > never arrived.
> >
> > When using debug.uart_force_poll=1 in loader.conf it works (at least if
> > we type in characters slowly, of course).
> >
> > So it really seems to have to do with interrupts again but I have no
> > idea where to look.
> >
> > The A2SAV manual talks about the Super I/O being a Nuvoton NCT5523D. Can
> > it be that we miss some support for this? But if the devices really behave
> > like standard 16550s we shouldn't need any specific support at all, I think.
> >
> > I disabled the corresponding ACPI functions by using
> >
> > debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1 \_SB_.PCI0.SBRG.UAR2"
> >
> > and the devices were detected properly as
> >
> > uart0: <16550 or compatible> at port 0x3f8 irq 4 flags 0x10 on isa0
> > uart1: <16550 or compatible> at port 0x2f8 irq 3 on isa0
> >
> > but this didn't help (same behaviour).
> >
> > The really bad news are: Using Linux (Ubuntu 16.04) it works. Devices are
> > detected here as:
> > ...
> > [    0.261209] pnp 00:01: [dma 0 disabled]
> > [    0.261295] pnp 00:01: Plug and Play ACPI device, IDs PNP0501 (active)
> > [    0.261774] pnp 00:02: [dma 0 disabled]
> > [    0.261868] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active)
> > ...
> > [    1.479082] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
> > [    1.499962] 00:01: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
> > [    1.520943] 00:02: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
> >
> > and we can send and receive characters without problems.
> >
> > So it really seems FreeBSD does something wrong on the A2SAV board when
> > it comes to interrupts of the serial ports.
> >
> > Any ideas how to start?
>
> Bay Trail and later Atoms UARTS are not standard UARTs controllers, AFAIR
> the registers are memory mapped, to start with.  They also support DMA, as
> you can see from the linux dmesg.  Perhaps there are some incompatibilities
> with the new implementation.
>
> Can you show the vmstat -i output ? Are there any other non-MSI
> interrupts used on the machine, do they work ?

Just to answer this question: I haven't seen any. When using io_apic.c
from -head (inspired by Luiz' suggestion to try -head because of r327314)
I have:

NOHOST:~>vmstat -i
interrupt                                                      total       rate
irq3: uart1                                                       18          0
cpu0:timer                                                      1516         16
irq264: ahci0                                                   1300         14
irq265: igb0:que 0                                              1965         21
irq266: igb0:que 1                                               414          4
irq267: igb0:que 2                                               539          6
irq268: igb0:que 3                                               251          3
irq269: igb0:link                                                  2          0
irq275: ahci1                                                      6          0
irq276: xhci0                                                    367          4
cpu2:timer                                                       950         10
cpu3:timer                                                       866          9
cpu1:timer                                                      1021         11
Total                                                           9215         97

Before the output has been similar but lacking the irq3 line.

> For a minor chance, try to set hw.lapic_eoi_suppression to 0 at the
> loader prompt.

Not needed, since it seems to work with io_apic.c from -head. But
if you want me to try it for whatever reasons I can do it, of course.

        -Andre
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"