PC Engines APU NIC (RTL8111E) performance

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

PC Engines APU NIC (RTL8111E) performance

Momtchil Momtchev
     Hello,


     Does anyone with a working knowledge of re(4) have any idea why the
PC Engines APU NICs perform so poorly in OpenBSD? Throughput is 300 to
320 MBit/s with about 30 pf rules, NAT and 10000 states when running
5.9. This is much less than an APU running Linux or FreeBSD or an
OpenBSD running on comparable CPU with another NIC. I wonder how do
other motherboards with that same NIC (it is very common on the lower
end) perform?

     Here is my top output when running iperf routing through the APU :

CPU0 states:  1.0% user,  0.0% nice, 51.5% system, 26.9% interrupt,
20.6% idle
CPU1 states:  1.2% user,  0.0% nice, 24.2% system, 50.1% interrupt,
24.6% idle

Reply | Threaded
Open this post in threaded view
|

Re: PC Engines APU NIC (RTL8111E) performance

Darren Tucker
On Wed, Aug 3, 2016 at 8:07 PM, Momtchil Momtchev <[hidden email]> wrote:
>     Does anyone with a working knowledge of re(4) have any idea why the PC
> Engines APU NICs perform so poorly in OpenBSD?

Most likely lack of hardware interrupt moderation in the driver.
There's code in re_setup_hw_im() that looks like might do something
plausible with the interrupt moderation register but AFAICT it'll
never be called because rl_imtype is always set to "RL_IMTYPE_SIM".

I tried to get hardware interrupt moderation working a while back but
it didn't seem to make a difference (which is probably an indication
that I did something wrong).  I could dig up the patch if you'd like
to try it.

The other thing to be aware of is that if you're following current,
POOL_DEBUG is usually set in your config, which will be quite
expensive when pushing packets.

--
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Reply | Threaded
Open this post in threaded view
|

Re: PC Engines APU NIC (RTL8111E) performance

Momtchil Momtchev
On 04/08/16 09:13, Darren Tucker wrote:
> On Wed, Aug 3, 2016 at 8:07 PM, Momtchil Momtchev <[hidden email]> wrote:
>>      Does anyone with a working knowledge of re(4) have any idea why the PC
>> Engines APU NICs perform so poorly in OpenBSD?
> Most likely lack of hardware interrupt moderation in the driver.
> There's code in re_setup_hw_im() that looks like might do something
> plausible with the interrupt moderation register but AFAICT it'll
> never be called because rl_imtype is always set to "RL_IMTYPE_SIM".

     What is the problem with software interrupt moderation? That it has
a fixed timer while the hardware one scales with the RX rate? This
shouldn't halve the performance? It should be more like 10% to 15% and
some latency benefit? I have also noticed that the TX rate is higher
than the RX rate (about 320 Mbit/s vs 260 Mbit/s). Could it be that the
FreeBSD driver uses MSI interrupts and the OpenBSD one does not?
     PS. On the APU my interrupt rate is about 6000 IRQ/s when doing 320
MBit/s, this is one IRQ every 165us or one IRQ for about 3 or 4 packets.
I will make rl_sim_time tunable and I will test if it affects performance.

Reply | Threaded
Open this post in threaded view
|

Re: PC Engines APU NIC (RTL8111E) performance

Darren Tucker
On Thu, Aug 04, 2016 at 02:46:44PM +0200, Momtchil Momtchev wrote:
[...]
> What is the problem with software interrupt moderation? That it has a
> fixed timer while the hardware one scales with the RX rate?

The hardware moderation can do per-N-packets in addition to a timer.

> This shouldn't
> halve the performance? It should be more like 10% to 15% and some latency
> benefit? I have also noticed that the TX rate is higher than the RX rate
> (about 320 Mbit/s vs 260 Mbit/s). Could it be that the FreeBSD driver uses
> MSI interrupts and the OpenBSD one does not?

Dunno.  If I knew what the cause was I'd have fixed it :-(

>     PS. On the APU my interrupt rate is about 6000 IRQ/s when doing 320
> MBit/s, this is one IRQ every 165us or one IRQ for about 3 or 4 packets. I
> will make rl_sim_time tunable and I will test if it affects performance.

I dug up my patch.  If you're experimenting, making the value used to
set the RL_IM register tunable then seeing what impact various values
have on throughput would be interesting.

Index: dev/ic/re.c
===================================================================
RCS file: /cvs/src/sys/dev/ic/re.c,v
retrieving revision 1.192
diff -u -p -r1.192 re.c
--- dev/ic/re.c 20 Apr 2016 12:15:24 -0000 1.192
+++ dev/ic/re.c 5 Aug 2016 00:31:04 -0000
@@ -747,7 +747,7 @@ re_attach(struct rl_softc *sc, const cha
  sc->rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_PHYWAKE_PM |
     RL_FLAG_PAR | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT |
     RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD | RL_FLAG_JUMBOV2 |
-    RL_FLAG_WOL_MANLINK;
+    RL_FLAG_WOL_MANLINK | RL_FLAG_HWIM;
  sc->rl_max_mtu = RL_JUMBO_MTU_9K;
  break;
  case RL_HWREV_8168E_VL:
@@ -821,13 +821,19 @@ re_attach(struct rl_softc *sc, const cha
  /* Reset the adapter. */
  re_reset(sc);
 
- sc->rl_tx_time = 5; /* 125us */
- sc->rl_rx_time = 2; /* 50us */
- if (sc->rl_flags & RL_FLAG_PCIE)
- sc->rl_sim_time = 75; /* 75us */
- else
- sc->rl_sim_time = 125; /* 125us */
- sc->rl_imtype = RL_IMTYPE_SIM; /* simulated interrupt moderation */
+ if (sc->rl_flags & RL_FLAG_HWIM) {
+ /* hardware interrupt moderation */
+ sc->rl_imtype = RL_IMTYPE_HW;
+ sc->rl_tx_time = 5; /* 125us */
+ sc->rl_rx_time = 2; /* 50us */
+ } else {
+ /* simulated interrupt moderation */
+ sc->rl_imtype = RL_IMTYPE_SIM;
+ if (sc->rl_flags & RL_FLAG_PCIE)
+ sc->rl_sim_time = 75; /* 75us */
+ else
+ sc->rl_sim_time = 125; /* 125us */
+ }
 
  if (sc->sc_hwrev == RL_HWREV_8139CPLUS)
  sc->rl_bus_speed = 33; /* XXX */
@@ -2233,6 +2239,8 @@ re_stop(struct ifnet *ifp)
 void
 re_setup_hw_im(struct rl_softc *sc)
 {
+ u_int16_t im;
+
  KASSERT(sc->rl_flags & RL_FLAG_HWIM);
 
  /*
@@ -2258,11 +2266,15 @@ re_setup_hw_im(struct rl_softc *sc)
  * Currently we only know how to set 'timer', but not
  * 'number of packets', which should be ~30, as far as I
  * tested (sink ~900Kpps, interrupt rate is 30KHz)
- */
- CSR_WRITE_2(sc, RL_IM,
-    RL_IM_RXTIME(sc->rl_rx_time) |
-    RL_IM_TXTIME(sc->rl_tx_time) |
-    RL_IM_MAGIC);
+ *
+ * According to the Linux driver, supposedly:
+ * (TxTimer << 12) | (TxPackets << 8) | (RxTimer << 4) | RxPackets
+ * Linux uses hard coded 0x5151.
+ */
+ im = RL_IM_TXTIME(sc->rl_tx_time) | RL_IM_TXPKTS(4) |
+    RL_IM_RXTIME(sc->rl_rx_time)  | RL_IM_RXPKTS(4);
+ printf("setting interrupt moderation %hx\n", im); /* XXX */
+ CSR_WRITE_2(sc, RL_IM, im);
 }
 
 void
Index: dev/ic/rtl81x9reg.h
===================================================================
RCS file: /cvs/src/sys/dev/ic/rtl81x9reg.h,v
retrieving revision 1.98
diff -u -p -r1.98 rtl81x9reg.h
--- dev/ic/rtl81x9reg.h 20 Apr 2016 12:15:24 -0000 1.98
+++ dev/ic/rtl81x9reg.h 5 Aug 2016 00:31:04 -0000
@@ -570,7 +570,9 @@
 
 #define RL_IM_MAGIC 0x5050
 #define RL_IM_RXTIME(t) ((t) & 0xf)
+#define RL_IM_RXPKTS(t) (((t) & 0xf) << 4)
 #define RL_IM_TXTIME(t) (((t) & 0xf) << 8)
+#define RL_IM_TXPKTS(t) (((t) & 0xf) << 12)
 
 struct rl_chain_data {
  u_int16_t cur_rx;

--
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Reply | Threaded
Open this post in threaded view
|

Re: PC Engines APU NIC (RTL8111E) performance

Darren Tucker
On Fri, Aug 05, 2016 at 11:56:15AM +1000, Darren Tucker wrote:

> On Thu, Aug 04, 2016 at 02:46:44PM +0200, Momtchil Momtchev wrote:
> [...]
> > What is the problem with software interrupt moderation? That it has a
> > fixed timer while the hardware one scales with the RX rate?
>
> The hardware moderation can do per-N-packets in addition to a timer.
>
> > This shouldn't
> > halve the performance? It should be more like 10% to 15% and some latency
> > benefit? I have also noticed that the TX rate is higher than the RX rate
> > (about 320 Mbit/s vs 260 Mbit/s). Could it be that the FreeBSD driver uses
> > MSI interrupts and the OpenBSD one does not?
>
> Dunno.  If I knew what the cause was I'd have fixed it :-(

Hey, I might have found it.  From my other diff:

> + * According to the Linux driver, supposedly:
> + * (TxTimer << 12) | (TxPackets << 8) | (RxTimer << 4) | RxPackets

however in the header the RXTIME/TXTIME macros didn't match that:

>  #define RL_IM_RXTIME(t) ((t) & 0xf)
> +#define RL_IM_RXPKTS(t) (((t) & 0xf) << 4)
>  #define RL_IM_TXTIME(t) (((t) & 0xf) << 8)
> +#define RL_IM_TXPKTS(t) (((t) & 0xf) << 12)

so assuming the comment was correct, I wasn't actually setting the holdoff
timers :-(

A quick test with this diff (just routing through it, no PF, no pool
debug) gives me:

$ iperf -c host -i 10 -t 60
------------------------------------------------------------
Client connecting to nfs, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.32.1 port 43092 connected with 192.168.33.44 port
5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   803 MBytes   674 Mbits/sec
[  3] 10.0-20.0 sec   844 MBytes   708 Mbits/sec
[  3] 20.0-30.0 sec   876 MBytes   735 Mbits/sec
[  3] 30.0-40.0 sec   915 MBytes   768 Mbits/sec
[  3] 40.0-50.0 sec   929 MBytes   779 Mbits/sec
[  3] 50.0-60.0 sec   917 MBytes   769 Mbits/sec
[  3]  0.0-60.0 sec  5.16 GBytes   739 Mbits/sec

Index: dev/ic/re.c
===================================================================
RCS file: /cvs/src/sys/dev/ic/re.c,v
retrieving revision 1.192
diff -u -p -r1.192 re.c
--- dev/ic/re.c 20 Apr 2016 12:15:24 -0000 1.192
+++ dev/ic/re.c 9 Aug 2016 00:52:45 -0000
@@ -747,7 +747,7 @@ re_attach(struct rl_softc *sc, const cha
  sc->rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_PHYWAKE_PM |
     RL_FLAG_PAR | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT |
     RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD | RL_FLAG_JUMBOV2 |
-    RL_FLAG_WOL_MANLINK;
+    RL_FLAG_WOL_MANLINK | RL_FLAG_HWIM;
  sc->rl_max_mtu = RL_JUMBO_MTU_9K;
  break;
  case RL_HWREV_8168E_VL:
@@ -821,13 +821,19 @@ re_attach(struct rl_softc *sc, const cha
  /* Reset the adapter. */
  re_reset(sc);
 
- sc->rl_tx_time = 5; /* 125us */
- sc->rl_rx_time = 2; /* 50us */
- if (sc->rl_flags & RL_FLAG_PCIE)
- sc->rl_sim_time = 75; /* 75us */
- else
- sc->rl_sim_time = 125; /* 125us */
- sc->rl_imtype = RL_IMTYPE_SIM; /* simulated interrupt moderation */
+ if (sc->rl_flags & RL_FLAG_HWIM) {
+ /* hardware interrupt moderation */
+ sc->rl_imtype = RL_IMTYPE_HW;
+ sc->rl_tx_time = 5; /* 125us */
+ sc->rl_rx_time = 2; /* 50us */
+ } else {
+ /* simulated interrupt moderation */
+ sc->rl_imtype = RL_IMTYPE_SIM;
+ if (sc->rl_flags & RL_FLAG_PCIE)
+ sc->rl_sim_time = 75; /* 75us */
+ else
+ sc->rl_sim_time = 125; /* 125us */
+ }
 
  if (sc->sc_hwrev == RL_HWREV_8139CPLUS)
  sc->rl_bus_speed = 33; /* XXX */
@@ -2233,6 +2239,8 @@ re_stop(struct ifnet *ifp)
 void
 re_setup_hw_im(struct rl_softc *sc)
 {
+ u_int16_t im;
+
  KASSERT(sc->rl_flags & RL_FLAG_HWIM);
 
  /*
@@ -2258,11 +2266,15 @@ re_setup_hw_im(struct rl_softc *sc)
  * Currently we only know how to set 'timer', but not
  * 'number of packets', which should be ~30, as far as I
  * tested (sink ~900Kpps, interrupt rate is 30KHz)
- */
- CSR_WRITE_2(sc, RL_IM,
-    RL_IM_RXTIME(sc->rl_rx_time) |
-    RL_IM_TXTIME(sc->rl_tx_time) |
-    RL_IM_MAGIC);
+ *
+ * According to the Linux driver, supposedly:
+ * (TxTimer << 12) | (TxPackets << 8) | (RxTimer << 4) | RxPackets
+ * Linux uses hard coded 0x5151.
+ */
+ im = RL_IM_TXTIME(sc->rl_tx_time) | RL_IM_TXPKTS(15) |
+    RL_IM_RXTIME(sc->rl_rx_time)  | RL_IM_RXPKTS(2);
+ printf("setting interrupt moderation %hx\n", im); /* XXX */
+ CSR_WRITE_2(sc, RL_IM, im);
 }
 
 void
Index: dev/ic/rtl81x9reg.h
===================================================================
RCS file: /cvs/src/sys/dev/ic/rtl81x9reg.h,v
retrieving revision 1.98
diff -u -p -r1.98 rtl81x9reg.h
--- dev/ic/rtl81x9reg.h 20 Apr 2016 12:15:24 -0000 1.98
+++ dev/ic/rtl81x9reg.h 9 Aug 2016 00:52:45 -0000
@@ -568,9 +568,14 @@
 #define RL_RXCFG_CONFIG (RL_RX_FIFOTHRESH|RL_RX_MAXDMA|RL_RX_BUF_SZ)
 #define RL_TXCFG_CONFIG (RL_TXCFG_IFG|RL_TX_MAXDMA)
 
-#define RL_IM_MAGIC 0x5050
-#define RL_IM_RXTIME(t) ((t) & 0xf)
-#define RL_IM_TXTIME(t) (((t) & 0xf) << 8)
+/*
+ * Interrupt moderation.  According to the Linux driver, supposedly:
+ * (TxTimer << 12) | (TxPackets << 8) | (RxTimer << 4) | RxPackets
+ */
+#define RL_IM_RXPKTS(t) ((t) & 0xf)
+#define RL_IM_RXTIME(t) (((t) & 0xf) << 4)
+#define RL_IM_TXPKTS(t) (((t) & 0xf) << 8)
+#define RL_IM_TXTIME(t) (((t) & 0xf) << 12)
 
 struct rl_chain_data {
  u_int16_t cur_rx;

--
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Reply | Threaded
Open this post in threaded view
|

Re: PC Engines APU NIC (RTL8111E) performance

Momtchil Momtchev
On 09/08/16 03:03, Darren Tucker wrote:
> On Fri, Aug 05, 2016 at 11:56:15AM +1000, Darren Tucker wrote:
>> On Thu, Aug 04, 2016 at 02:46:44PM +0200, Momtchil Momtchev wrote:
>> [...]
>>
> A quick test with this diff (just routing through it, no PF, no pool
> debug) gives me:
>
> $ iperf -c host -i 10 -t 60

> [  3]  0.0-60.0 sec  5.16 GBytes   739 Mbits/sec
>
>

     I tried this patch (5f22 in the RL_IM register) on 5.9-stable, no
POOL_DEBUG, 30 pf rules and about 10k states and I got about 8000 IRQ/s
(up from 6000/s on vanilla) and iperf RX throughput was down to 280
MBit/s. I then tried upping the RXPKTS to 15 and the RXTIME to 4 (100us)
- this is 5f4f in RL_IM. The IRQs dropped to 5000 IRQ/s and the CPU
utilisation went down, but RX throughput went further down to 240
MBit/s. Next I tried the magic value 5151 and IRQs dropped to 4000 IRQ/s
(???), CPU went down and throughput went down to 200 MBit/s.
     All these are RX values. On the TX side I get slightly higher
throughput and a higher IRQ rate.
     There are no public datasheets for the 8111E and I think there is
something fishy with those values. The original source of the 5151 magic
is the open-source driver by Realtek. Hopefully they know what they are
doing. They have a Linux and a FreeBSD driver on their site. The one for
FreeBSD seems to be based on that same driver by Bill Paul from
Windriver and it uses this magic value which doesn't make any sense if 1
is the number of packets to wait before sending an interrupt.

     Also what I find very puzzling is that lower IRQ rates lead to
lower CPU utilization but not higher throughput??

     What hardware are you using? This is not an APU? Maybe there is
some other bottleneck on the APU? Are you getting higher performance
than on vanilla?

Reply | Threaded
Open this post in threaded view
|

Re: PC Engines APU NIC (RTL8111E) performance

Momtchil Momtchev
In reply to this post by Darren Tucker
On 09/08/16 03:03, Darren Tucker wrote:
> On Fri, Aug 05, 2016 at 11:56:15AM +1000, Darren Tucker wrote:
>> On Thu, Aug 04, 2016 at 02:46:44PM +0200, Momtchil Momtchev wrote:
>> [...]
>>> What is the problem with software interrupt moderation? That it has a
>>> fixed timer while the hardware one scales with the RX rate?
>> The hardware moderation can do per-N-packets in addition to a timer.
>>

     I just went through the two Linux drivers. There is the GPLd r8169
that is built into the official kernel written by someone at Realtek.
This one uses hardware interrupt moderation with the 0x5151 magic. Then
there is the r8168 driver distributed by Realtek on their site. It is
also GPLd. That one is considered to be of better quality in the Linux
world and it is repackaged by some Linux distros (Debian and Ubuntu for
example) as a replacement for the built-in driver. This second driver
uses a strategy similar to the current OpenBSD driver - schedule an
interrupt, then whenever the queue is not empty, reschedule the next
interrupt using a hardware timer (register 0x58) on the chip (ie.
"simulated" interrupt moderation) and still has exceptional performance.
The Realtek timer value in Linux is fixed 0x2600. The OpenBSD driver
deduces it from the bus speed. Anyway I think that at least on the PC
Engines APU the bottleneck is not CPU- or IRQ-related.

Reply | Threaded
Open this post in threaded view
|

Re: PC Engines APU NIC (RTL8111E) performance

Momtchil Momtchev
In reply to this post by Momtchil Momtchev
On 09/08/16 12:26, Momtchil Momtchev wrote:
> On 09/08/16 03:03, Darren Tucker wrote:
>> On Fri, Aug 05, 2016 at 11:56:15AM +1000, Darren Tucker wrote:
>>> On Thu, Aug 04, 2016 at 02:46:44PM +0200, Momtchil Momtchev wrote:
>>> [...] .
>>>
>
>     Also what I find very puzzling is that lower IRQ rates lead to
> lower CPU utilization but not higher throughput??
>
     I just completely disabled the interrupt moderation by bypassing
the code. 1 packet = 1 IRQ. Now I get a whopping 30k+ IRQ/s and the RX
performance is still the same, even a little bit higher - 350 MBit/s -
with the pf rules and everything. Now I am definitely CPU-bound - idle
is about 5%, the interrupt load is about 110% and the system load is
about 80% (the APU has 2 cores). Idle was 50% to 60% with interrupt
moderation. I am testing on a remote board so I can't easily disable pf
(it does NAT). I will try to properly test it with routing-only.
     Then I did another test with interrupt moderation and mutithreaded
iperf. This way the board goes up to 500 MBit/s and idle is down to
practically 0% - which is consistent with your 600 MBit/s result without
pf. So the main problem seems to be the interrupt moderation-induced
latency which confuses the end-point TCP. I also get slightly higher
performance with a larger TCP window. So one should actually aim to
transfer less packets per IRQ in order to minimize the latency. 2
packets per IRQ seems a very good compromise. So maybe this explains the
0x5151 value? Where 1 is every second packet?

Reply | Threaded
Open this post in threaded view
|

Re: PC Engines APU NIC (RTL8111E) performance

Darren Tucker
In reply to this post by Momtchil Momtchev
On Tue, Aug 09, 2016 at 12:26:00PM +0200, Momtchil Momtchev wrote:
>     I tried this patch (5f22 in the RL_IM register) on 5.9-stable, no
> POOL_DEBUG, 30 pf rules and about 10k states and I got about 8000 IRQ/s (up
> from 6000/s on vanilla) and iperf RX throughput was down to 280 MBit/s.

Are you running iperf on the APU?  I'm running it on separate machines
either side.

> I then tried upping the RXPKTS to 15 and the RXTIME to 4 (100us) - this is
> 5f4f in RL_IM. The IRQs dropped to 5000 IRQ/s and the CPU utilisation went
> down, but RX throughput went further down to 240 MBit/s. Next I tried the
> magic value 5151 and IRQs dropped to 4000 IRQ/s (???), CPU went down and
> throughput went down to 200 MBit/s.
>     All these are RX values. On the TX side I get slightly higher throughput
> and a higher IRQ rate.
>     There are no public datasheets for the 8111E and I think there is
> something fishy with those values. The original source of the 5151 magic is
> the open-source driver by Realtek. Hopefully they know what they are doing.
> They have a Linux and a FreeBSD driver on their site. The one for FreeBSD
> seems to be based on that same driver by Bill Paul from Windriver and it
> uses this magic value which doesn't make any sense if 1 is the number of
> packets to wait before sending an interrupt.
>
>     Also what I find very puzzling is that lower IRQ rates lead to lower CPU
> utilization but not higher throughput??
>
>     What hardware are you using? This is not an APU? Maybe there is some
> other bottleneck on the APU?

It's an early (2 core) APU.  dmesg below.

> Are you getting higher performance than on vanilla?

It's not consistent and I think there's a variable I haven't controlled
for. I've been fiddling a lot but right now a stock -current kernel
performance is about in the same ballpark as with the diff.  Have you
tested with -current?  I might try 5.9 for comparison.

Things I've tried to control for:
hw.perfpolicy=manual
hw.setperf=0 (also 100)
kern.pool_debug=0

I did find that the results seemed a bit more consistent when disabling
Nagle (iperf -N) which would probably make it less sensitive to latency
or loss during TCP slow start.

OpenBSD 6.0 (GENERIC) #2135: Sun Jul 24 10:30:11 MDT 2016
    [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 2098520064 (2001MB)
avail mem = 2030505984 (1936MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7e16d820 (7 entries)
bios0: vendor coreboot version "4.0" date 09/08/2014
bios0: PC Engines APU
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD G-T40N Processor, 1000.13 MHz
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache
cpu0: 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu0: mwait min=64, max=64, IBE
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec00000, version 21, 24 pins
acpiprt0 at acpi0: bus -1 (AGPB)
acpiprt1 at acpi0: bus -1 (HDMI)
acpiprt2 at acpi0: bus 1 (PBR4)
acpiprt3 at acpi0: bus 2 (PBR5)
acpiprt4 at acpi0: bus 3 (PBR6)
acpiprt5 at acpi0: bus -1 (PBR7)
acpiprt6 at acpi0: bus 5 (PE20)
acpiprt7 at acpi0: bus -1 (PE21)
acpiprt8 at acpi0: bus -1 (PE22)
acpiprt9 at acpi0: bus -1 (PE23)
acpiprt10 at acpi0: bus 0 (PCI0)
acpiprt11 at acpi0: bus 4 (PIBR)
acpicpu0 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS
acpibtn0 at acpi0: PWRB
cpu0: 1000 MHz: speeds: 1000 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD AMD64 14h Host" rev 0x00
ppb0 at pci0 dev 4 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:31:30:74
rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 4
ppb1 at pci0 dev 5 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci2 at ppb1 bus 2
re1 at pci2 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:31:30:75
rgephy1 at re1 phy 7: RTL8169S/8110S/8211 PHY, rev. 4
ppb2 at pci0 dev 6 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci3 at ppb2 bus 3
re2 at pci3 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:31:30:76
rgephy2 at re2 phy 7: RTL8169S/8110S/8211 PHY, rev. 4
ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x40: apic 2 int 19, AHCI 1.2
ahci0: port 0: 6.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: <ATA, GLOWAY VAL32GS3-, V1BB> SCSI3 0/direct fixed naa.0000000000000000
sd0: 30029MB, 512 bytes/sector, 61500000 sectors, thin
ohci0 at pci0 dev 18 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18, version 1.0, legacy support
ehci0 at pci0 dev 18 function 2 "ATI SB700 USB2" rev 0x00: apic 2 int 17
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "ATI EHCI root hub" rev 2.00/1.00 addr 1
ohci1 at pci0 dev 19 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18, version 1.0, legacy support
ehci1 at pci0 dev 19 function 2 "ATI SB700 USB2" rev 0x00: apic 2 int 17
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 "ATI EHCI root hub" rev 2.00/1.00 addr 1
piixpm0 at pci0 dev 20 function 0 "ATI SBx00 SMBus" rev 0x42: polling
iic0 at piixpm0
pcib0 at pci0 dev 20 function 3 "ATI SB700 ISA" rev 0x40
ppb3 at pci0 dev 20 function 4 "ATI SB600 PCI" rev 0x40
pci4 at ppb3 bus 4
ohci2 at pci0 dev 20 function 5 "ATI SB700 USB" rev 0x00: apic 2 int 18, version 1.0, legacy support
ppb4 at pci0 dev 21 function 0 "ATI SB800 PCIE" rev 0x00
pci5 at ppb4 bus 5
ohci3 at pci0 dev 22 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18, version 1.0, legacy support
ehci2 at pci0 dev 22 function 2 "ATI SB700 USB2" rev 0x00: apic 2 int 17
usb2 at ehci2: USB revision 2.0
uhub2 at usb2 "ATI EHCI root hub" rev 2.00/1.00 addr 1
pchb1 at pci0 dev 24 function 0 "AMD AMD64 14h Link Cfg" rev 0x43
pchb2 at pci0 dev 24 function 1 "AMD AMD64 14h Address Map" rev 0x00
pchb3 at pci0 dev 24 function 2 "AMD AMD64 14h DRAM Cfg" rev 0x00
km0 at pci0 dev 24 function 3 "AMD AMD64 14h Misc Cfg" rev 0x00
pchb4 at pci0 dev 24 function 4 "AMD AMD64 14h CPU Power" rev 0x00
pchb5 at pci0 dev 24 function 5 "AMD AMD64 14h Reserved" rev 0x00
pchb6 at pci0 dev 24 function 6 "AMD AMD64 14h NB Power" rev 0x00
pchb7 at pci0 dev 24 function 7 "AMD AMD64 14h Reserved" rev 0x00
usb3 at ohci0: USB revision 1.0
uhub3 at usb3 "ATI OHCI root hub" rev 1.00/1.00 addr 1
usb4 at ohci1: USB revision 1.0
uhub4 at usb4 "ATI OHCI root hub" rev 1.00/1.00 addr 1
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
wbsio0 at isa0 port 0x2e/2: NCT5104D rev 0x52
usb5 at ohci2: USB revision 1.0
uhub5 at usb5 "ATI OHCI root hub" rev 1.00/1.00 addr 1
usb6 at ohci3: USB revision 1.0
uhub6 at usb6 "ATI OHCI root hub" rev 1.00/1.00 addr 1
umass0 at uhub2 port 1 configuration 1 interface 0 "Generic Flash Card Reader/Writer" rev 2.01/1.00 addr 2
umass0: using SCSI over Bulk-Only
scsibus2 at umass0: 2 targets, initiator 0
sd1 at scsibus2 targ 1 lun 0: <Multiple, Card Reader, 1.00> SCSI2 0/direct removable serial.058f6366058F63666485
vscsi0 at root
scsibus3 at vscsi0: 256 targets
softraid0 at root
scsibus4 at softraid0: 256 targets
root on sd0a (2b4cdf5e1e14b9e7.a) swap on sd0b dump on sd0b
--
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.