On Sat, May 05, 2018 at 08:18:01PM -0700, s_g...@telus.net wrote:
> I have tested the diff (below) to the com driver on my orangepi. It works.
> Can this patch be committed?
>
Atleast in _theory_, there could be "snps,dw-apb-uart" without fifo,
and the diff doesn't properly detect such. So the answer was/is no.
I don't remember the specifics, and I'm not sure if i ever sent out
the diff doing it properly, but linux has safe(?) procedure for
detecting these fifos.
-Artturi
> 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.
> >
> >
>
>
