I have tested the diff (below) to the com driver on my orangepi. It works.
Can this patch be committed?
>From dmesg:
com0 at simplebus0: ns16550a, 64 byte fifo
com0: console
-----Original Message-----
From: owner-...@openbsd.org <owner-...@openbsd.org> On Behalf Of Artturi Alm
Sent: May 2, 2018 2:26 PM
To: s_g...@telus.net
Cc: arm@openbsd.org
Subject: Re: gtk libool slow on arm
On Wed, May 02, 2018 at 10:35:27AM -0700, s_g...@telus.net wrote:
> I realize the orangepi is not the swiftest of machines, but the ld
> issue is more than just SOC performance. The ld process should finish
> within a few seconds to a minute. It is taking 20 minutes.
>
> I am trying to build php as the current bulk build failed on so many
> packages. I think it is the first bulk build since clang. The other
> compiles and processes execute in reasonable time, but when it comes
> to ld something happens.
>
> As I was looking around trying to find what some clues I ran man from
> the serial console and it hung. Man runs fine from an ssh connection
> over the lan. Man on the console was hung in bqwait. What is that?
>
> PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND
> 87860 root 63 0 45M 45M run - 18:26 64.60% ld
> 30014 sysadmin -6 0 832K 1556K sleep bqwait 0:10 15.23% man
>
> Later when I suspect ld finished more started to run and got stuck
> also, probably when ld started up again.
>
> PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND
> 18030 root 59 0 46M 47M run - 23:02 54.54% ld
> 68435 sysadmin 58 0 257M 182M run - 0:57 42.72% more
> 30014 sysadmin 10 0 832K 0K idle wait 4:14 0.00% man
>
> Both man and more seem to be using cpu cycles even though they are stuck.
> Could ld be trying to do something with the console?
>
Hi,
You could also add "stty status ^T" into ~/.profile, to see what's going on
when you press it.
tbh., i've never compiled anything gtk on armv7, so i think it's something i
can't help you with.
for less pressure on 'tty level', you could take advantage of the fifo your hw
has, with the diff below. you can see the effect with systat(1) in the
Interrupts column for com0.
-Artturi
diff --git sys/arch/armv7/dev/com_fdt.c sys/arch/armv7/dev/com_fdt.c index
053064e77c1..8f0f159413f 100644
--- sys/arch/armv7/dev/com_fdt.c
+++ sys/arch/armv7/dev/com_fdt.c
@@ -130,8 +130,11 @@ com_fdt_attach(struct device *parent, struct device *self,
void *aux)
sc->sc_reg_width = OF_getpropint(faa->fa_node, "reg-io-width", 4);
sc->sc_reg_shift = OF_getpropint(faa->fa_node, "reg-shift", 2);
- if (OF_is_compatible(faa->fa_node, "snps,dw-apb-uart"))
+ if (OF_is_compatible(faa->fa_node, "snps,dw-apb-uart")) {
+ sc->sc.sc_uarttype = COM_UART_16550A;
+ sc->sc.sc_fifolen = 64;
intr = com_fdt_intr_designware;
+ }
if (OF_is_compatible(faa->fa_node, "ti,omap3-uart") ||
OF_is_compatible(faa->fa_node, "ti,omap4-uart"))
>
> -----Original Message-----
> From: owner-po...@openbsd.org <owner-po...@openbsd.org> On Behalf Of
> Mark Kettenis
> Sent: May 2, 2018 3:10 AM
> To: s_g...@telus.net
> Cc: po...@openbsd.org; arm@openbsd.org
> Subject: Re: gtk libool slow on arm
>
> > From: <s_g...@telus.net>
> > Date: Tue, 1 May 2018 16:30:28 -0700
> >
> > Why is the gtk libtool so slow on arm? A typical command such as:
>
> It's not libtool, but ld, the link editor that is taking its time.
>
> > libtool: link: cc -o .libs/testentrycompletion -pthread -O2 -pipe -g
> > -Wall -Wl,-rpath-link -Wl,/usr/X11R6/lib -Wl,-rpath-link
> > -Wl,/usr/X11R6/lib testentrycompletion.o -L.libs -lgtk-3 -lgdk-3
> > -lpangocairo-1.0 -lpango-1.0
> > -lgobject-2.0 -lglib-2.0 -liconv -lpcre -lintl -lffi -lc++abi
> > -lgthread-2.0 -lfribidi -lm -lcairo -lpthread -lpixman-1
> > -lfontconfig -lfreetype -lz -lexpat -lpng -lxcb-shm -lxcb
> > -lxcb-render -lXrender
> > -lX11 -lXext
> > -lpangoft2-1.0 -lharfbuzz -lgraphite2 -lgdk_pixbuf-2.0 -lgmodule-2.0
> > -lgio-2.0 -lcairo-gobject -lXinerama -lXi -lXrandr -lXcursor
> > -lXfixes -lXcomposite -lXdamage -lepoxy -latk-1.0 -latk-bridge-2.0
> > -ldbus-1 -latspi
> > -Wl,-rpath-link,/usr/local/lib,-rpath-link,/usr/X11R6/lib
>
> That is linking in quite a number of libraries, some of which are
> fairly sizeable.
>
> > takes from 15 to 20 minutes on arm. It is all cpu time, not i/o:
>
> The binutils linker is quite crappy. The LLVM linker is better.
>
> > load averages: 2.03, 2.02, 2.00 op1bsdsnap.graf.lan
> > 16:26:21
> >
> > 78 processes: 1 running, 76 idle, 1 on processor up 4 days,
> > 7:42
> >
> > CPU states: 99.6% user, 0.0% nice, 0.4% system, 0.0% interrupt,
> > 0.0% idle
> >
> > Memory: Real: 59M/234M act/tot Free: 259M Cache: 98M Swap: 11M/516M
> >
> >
> >
> > PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU
> COMMAND
> >
> > 12051 root 64 0 7680K 8532K run - 6:44 99.12% ld
> >
> > 27209 sysadmin 2 0 972K 984K idle select 0:49 0.00% sshd
> >
> > 65728 _pflogd 4 0 716K 172K sleep bpf 0:29 0.00% pflogd
> >
> > I set up an i386 virtual system with one cpu at 3 GHz and the whole
> > gtk build including all the dependencies took a few hours. My gtk
> > build on an arm orangepi with a 1.2GHz cpu has been running for over
> > 48 hours, all due to libtool. A cc compile finishes in seconds.
>
> The orangepi probably runs at a lower speed since DVFS isn't
> implemented yet. And the Cortex-A7 simply isn't a very powerful CPU
> as it is completely in-order. Memory bandwidth on the orangepi is probably
> limited as well.
>
>
