* [LTP] [PATCH][RFC] network: test_net.sh: allow to run tests on a single machine
From: Alexey Kodanev @ 2016-11-14 13:33 UTC (permalink / raw)
To: ltp
When 'TST_USE_NETNS' environment variable is defined, test_net.sh
will setup 'ltp_ns' netns and configure veth pair according to
other LTP network variables. Then, each tst_rhost_run() call will
be executed in the new netns on the same host.
Usage:
TST_USE_NETNS=1... ./network.sh -i
Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
---
testcases/lib/test_net.sh | 50 ++++++++++++++++++++++++++++++++++++---------
1 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/testcases/lib/test_net.sh b/testcases/lib/test_net.sh
index dc52d95..67c702b 100644
--- a/testcases/lib/test_net.sh
+++ b/testcases/lib/test_net.sh
@@ -20,6 +20,31 @@
[ -z "$TST_LIB_LOADED" ] && . test.sh
+init_ltp_netspace()
+{
+ if [ ! -f /var/run/netns/ltp_ns ]; then
+ ROD ip net add ltp_ns
+ ROD ip li add name ltp_veth1 type veth peer name ltp_veth2
+ ROD ip li set dev ltp_veth1 netns ltp_ns
+ fi
+
+ LHOST_IFACES=${LHOST_IFACES:-"ltp_ns_veth2"}
+ RHOST_IFACES=${RHOST_IFACES:-"ltp_ns_veth1"}
+
+ export TST_INIT_NETNS="no"
+ export LTP_NETNS=${LTP_NETNS:-"ip netns exec ltp_ns"}
+
+ tst_init_iface
+ tst_init_iface rhost
+
+ tst_add_ipaddr
+ tst_add_ipaddr rhost
+
+ TST_IPV6=6 tst_add_ipaddr
+ TST_IPV6=6 tst_add_ipaddr rhost
+
+}
+
# Run command on remote host.
# Options:
# -b run in background
@@ -67,6 +92,9 @@ tst_rhost_run()
if [ -n "$TST_USE_SSH" ]; then
output=`ssh -n -q $user@$RHOST "sh -c \
'$pre_cmd $cmd $post_cmd'" $out 2>&1 || echo 'RTERR'`
+ elif [ -n "$TST_USE_NETNS" ]; then
+ output=`$LTP_NETNS sh -c \
+ "$pre_cmd $cmd $post_cmd" $out 2>&1 || echo 'RTERR'`
else
output=`rsh -n -l $user $RHOST "sh -c \
'$pre_cmd $cmd $post_cmd'" $out 2>&1 || echo 'RTERR'`
@@ -346,22 +374,14 @@ tst_ping()
}
# Management Link
-[ -z "$RHOST" ] && tst_brkm TBROK "RHOST variable not defined"
+[ -z "$RHOST" -a -z "$TST_USE_NETNS" ] && \
+ tst_brkm TBROK "RHOST variable not defined"
export RHOST="$RHOST"
export PASSWD=${PASSWD:-""}
# Don't use it in new tests, use tst_rhost_run() from test_net.sh instead.
export LTP_RSH=${LTP_RSH:-"rsh -n"}
# Test Links
-# Warning: make sure to set valid interface names and IP addresses below.
-# Set names for test interfaces, e.g. "eth0 eth1"
-export LHOST_IFACES=${LHOST_IFACES:-"eth0"}
-export RHOST_IFACES=${RHOST_IFACES:-"eth0"}
-
-# Set corresponding HW addresses, e.g. "00:00:00:00:00:01 00:00:00:00:00:02"
-export LHOST_HWADDRS=${LHOST_HWADDRS:-"$(tst_get_hwaddrs lhost)"}
-export RHOST_HWADDRS=${RHOST_HWADDRS:-"$(tst_get_hwaddrs rhost)"}
-
# Set first three octets of the network address, default is '10.0.0'
export IPV4_NETWORK=${IPV4_NETWORK:-"10.0.0"}
# Set local host last octet, default is '2'
@@ -408,5 +428,15 @@ export UPLOAD_REGFILESIZE=${UPLOAD_REGFILESIZE:-"1024"}
export MCASTNUM_NORMAL=${MCASTNUM_NORMAL:-"20"}
export MCASTNUM_HEAVY=${MCASTNUM_HEAVY:-"40000"}
+[ -n "$TST_USE_NETNS" -a "$TST_INIT_NETNS" != "no" ] && init_ltp_netspace
+
+# Warning: make sure to set valid interface names and IP addresses below.
+# Set names for test interfaces, e.g. "eth0 eth1"
+export LHOST_IFACES=${LHOST_IFACES:-"eth0"}
+export RHOST_IFACES=${RHOST_IFACES:-"eth0"}
+# Set corresponding HW addresses, e.g. "00:00:00:00:00:01 00:00:00:00:00:02"
+export LHOST_HWADDRS=${LHOST_HWADDRS:-"$(tst_get_hwaddrs lhost)"}
+export RHOST_HWADDRS=${RHOST_HWADDRS:-"$(tst_get_hwaddrs rhost)"}
+
# More information about network parameters can be found
# in the following document: testcases/network/stress/README
--
1.7.1
^ permalink raw reply related
* [LTP] [PATCH] runalltests.sh: remove obsolete data from Makefile
From: Cyril Hrubis @ 2016-11-14 13:33 UTC (permalink / raw)
To: ltp
In-Reply-To: <1479117309-3611-1-git-send-email-yangx.jy@cn.fujitsu.com>
Hi!
> Installation failed because runalltests.sh has been removed in:
I've added a removal of mention of the script in INSTALL and doc/,
changed commit message accordingly and pushed, thanks.
FYI: I've also added a follow up commit that removes obsolete scripts
that were depending on the runalltests.sh script.
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply
* Re: Change call ABI on PA-RISC
From: Carlos O'Donell @ 2016-11-14 13:32 UTC (permalink / raw)
To: John David Anglin
Cc: Helge Deller, linux-parisc@vger.kernel.org List, Jeff Law
In-Reply-To: <0E3ABDFC-D082-4DA8-9D5B-12FC7E95335F@bell.net>
On Sat, Nov 12, 2016 at 1:00 PM, John David Anglin <dave.anglin@bell.net> wrote:
> I'm thinking about adding a "-mabi=" option to change the call ABI. Currently, objects larger than 64 bits
> in the 32-bit runtime are passed by reference and the callee copies the object when necessary. This is
> opposite to x86 where the caller does the copies. Most targets are caller copies.
>
> The problem with callee copies is that it doesn't work with openmp. There are race problems and sometimes
> we get internal compiler errors with openmp code due to this problem. This became apparent when new testcases
> were added to gcc-6. It's tough to fix this problem in gcc.
>
> This is gcc PR:
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68733>.
>
> This is fixed if we change abi to caller copies (maybe "-mabi=gnu" and "-mabi=hp"). The default could be set
> by a configure options. Probably, we would want the new gnu abi on linux as the default. However, there is
> the potential to break stuff during the migration to the new abi.
>
> Opinions?
I think this is a good idea.
Anything that brings us slowly towards parity with other arches is
better in the long-run.
Any idea how to test the impact?
Cheers,
Carlos.
^ permalink raw reply
* usb otg port not working on an imx25 soc
From: iw3gtf @ 2016-11-14 12:57 UTC (permalink / raw)
To: barebox
Hi,
I'm currently working on an embedded board with an imx25 soc and I want
to enable the usb otg port of the soc; in my use case I just want the otg port
to be configured in usb host mode and use the integrated UTMI phy.
I built barebox with usb support and the usb ports are actually found:
barebox:/ usb
usb: USB: scanning bus for devices...
imx-usb imx-usb0: req=6 (0x6), type=128 (0x80), value=256, index=0
imx-usb imx-usb0: USB_DT_DEVICE request
imx-usb imx-usb0: req=5 (0x5), typ(0xe=0 0), value=1, index=0
imx-usb imx-usb0: USB_REQ_SET_ADDRESS
imx-usb imx-usb0: Len is 0
imx-usb imx-usb0: req=6 (0x6), type=128 (0x80), value=256, index=0
imx-usb imx-usb0: USB_DT_DEVICE request
imx-usb imx-usb0: req=6 (0x6), type=128 (0x80), value=512, index=0
imx-usb imx-usb0: USB_DT_CONFIG config
imx-usb imx-usb0: req=6 (0x6), type=128 (0x80), value=512, index=0
imx-usb imx-usb0: USB_DT_CONFIG config
imx- iumsbx-usb0: req=9 (0x9), type=0 (0x0), value=1, index=0
imx-usb imx-usb0: USB_REQ_SET_CONFIGURATION
imx-usb imx-usb0: Len is 0
imx-usb imx-usb0: req=6 (0x6), type=128 (0x80), value=768, index=0
imx-usb imx-usb0: USB_DT_STRING config
imx-usb imx-usb0: req=6 (0x6), type=128 (0x80), value=769, index=1
imx-usb imx-usb0: USB_DT_STRING config
imx-usb imx-usb0: req=6 (0x6), type=128 (0x80), value=770, index=1
imx-usb imx-usb0: USB_DT_STRING config
usb: Bus 001 Device 001: ID 000000: 00EHCI Host Controller
imx-usb imx-usb0: req=6 (0x6), type=160 (0xa0), value=10496, index=0
omx-usb imx-usb0: USB_DT_HUB figc
nimx-usb imx-usb0: req=6 (0x6), type=160 (0xa0), value=10496, index=0
imx-usb imx-usb0: USB_DT_HUB config
imx-usb imx-usb0: req=0 (0x0), type=160 (0xa0), value=0, index=0
imx-usb imx-usb0: req=1 (0x1), type=35 (0x23), value=8, index=1
imx-usb imx-usb0: Len is 0
imx-usb imx-usb0: req=3 (0x3), type=35 (0x23), value=8, index=1
imx-usb imx-usb0: Len is 0
imx-usb imx-usb0: req=0 (0x0), type=163 (0xa3), value=0, index=1
imx-usb imx-usb1: req=6 (0x6), type=128 (0x80), value=256, index=0
imx-usb imx-usb1: USB_DT_DEVICE request
imx-usb imx-usb1: req=5 (0x5), type=0 (0x0), value=2, index=0
imx-usb imx-usb1: USB_REQ_SET_ADDRESS
imx-usb imx-usb1: Len is 0
imx-usb imx-usb1: req=6 (0x6), type=128 (0x80), value=256, index=0
imx-usb imx-usb1: USB_DT_DEVICE request
imx-usb imx-usb1: req=6 (0x6), type=128 (0x80), value=512, index=0
imx-usb imx-usb1: USB_DT_CONFIG config
imx-usb imx-usb1: req=6 (0x6), type=128 (0x80), value=512, index=0
imx-usb imx-usb1: USB_DT_CONFIG config
imx-usb imx-usb1: req=9 (0x9), type=0 (0x0), value=1, index=0
imx-usb imx-usb1: USB_REQ_SET_CONFIGURATION
imx-usb imx-usb1: Len is 0
imx-usb imx-usb1: req=6 (0x6), type=128 (0x80), value=768, index=0
imx-usb imx-usb1: USB_DT_STRING config
imx-usb imx-usb1: req=6 (0x6), type=128 (0x80), value=769, index=1
imx-usb imx-usb1: USB_DT_STRING config
imx-usb imx-usb1: req=6 (0x6), type=128 (0x80), value=770, index=1
imx-usb imx-usb1: USB_DT_STRING config
usb: Bus 002 Device 002: ID 0000:0000 EHCI Host Controller
imx-usb imx-usb1: req=6 (0x6), type=160 (0xa0), value=10496, index=0
imx-usb imx-usb1: USB_DT_HUB config
imx-usb imx-usb1: req=6 (0x6), type=160 (0xa0), value=10496, index=0
imx-usb imx-usb1: USB_DT_HUB config
imx-usb imx-usb1: req=0 (0x0), type=160 (0xa0), value=0, index=0
imx-usb imx-usb1: req=1 (0x1), type=35 (0x23), value=8, index=1
imx-usb imxb1:- usLen is 0
imx-usb imx-usb1: req=3 (0x3), type=35 (0x23), value=8, index=1
imx-usb imx-usb1: Len is 0
imx-usb imx-usb1: req=0 (0x0), type=163 (0x)a, 3value=0, index=1
usUb: 2 SB Device(s) found
barebox:/
but if I plug a usb device (usb memory stick) in the otg port:
barebox:/ usb
usb: USB: scanning bus for devices...
imx-usb imx-usb0: req=6 (0x6), type=128 (0x80), value=256, index=0
imx-usb imx-usb0: USB_DT_DEVICE request
imx-usb imx-usb0: req=5 (0x5), type=0 (0x0), value=1, index=0
imx-usb imx-usb0: USB_REQ_SET_ADDRESS
imx-usb imx-usb0: Len is 0
imx-usb imx-usb0: req=6 (0x6), type=128 (0x80), value=256, index=0
imx-usb imx-usb0: USB_DT_DEVICE request
imx-usb imx-usb0: req=6 (0x6), type=128 (0x80), value=512, index=0
imx-usb imx-usb0: USB_DT_CONFIG config
imx-usb imx-usb0: req=6 (0 typex6),=128 (0x80), value=512, nidex=0
imx-usb imx-usb0: USB_DT_CONFIG config
imx-usb imx-usb0: req=9 (0x9), type=0 (0x0), value=1, index=0
imx-usb imx-usb0: USB_REQ_SET_CONFIGURATION
imx-usb imx-usb0: Len is 0
imx-usb imx-usb0: req=6 (0x6), type=128 0(0x8), value=768, index=0
imx-usb imx-usb0: USB_DT_STRING config
imx-usb imx-usb0: req=6 (0x6)28, type= 1(0x80), value=769, index=1
imx-usb imx-usb0: USB_DT_STRING config
imx-usb imx-usb0: req=6 (0x6), type=128 (0x80), value=770, index=1
imx-usb imx-usb0: USB_DT_STRING config
usb: Bus 001 Device 001: ID 0000:0000 EHCI Host Controller
imx-usb imx-usb0: req(=06x 6), type=160 (0xa0), value=10496, index=0
imx-usb imx-usb0: USB_DT_HUB config
imx-usb imx-usb0: req=6 (0x6), type=160 (0xa0), value=10496, index=0
imx-usb imx-usb0: USB_DT_HUB config
imx-usb imx-usb0: req=0 (0x0), type=160 (0xa0), value=0, index=0
imx-usb imx-usb0: req=1 (0x1), type=35 (0x23), value=8, index=1
imx-usb imx-usb0: Len is 0
imx-usb imx-usb0: req=3 (0x3), type=35 (0x23), va=lue8, index=1
imx-usb imx-usb0: Len is 0
imx-usb imx-usb0: req=0 (0x0), type=163 (0xa3), value=0, index=1
usb-hub usb1: usb_hub_port_connect_change: called. port 1, dev->speed: 3
imx-usb imx-usb0: req=0 (0x0), type=163 (0xa3), value=0, index=1
usb-hub usb1: portstatus 101, change 1
usb-hub usb1: portstatus 101, change 1, 12 Mb/s
imx-usb imx-usb0: req=1 (0x1), type=35 (0x23), value=16, index=1
imx-usb imx-usb0: Len is 0
usb-hub usb1: hub_port_reset: resetting port 1...
imx-usb imx-usb0: req=3 (0x3), type=35 (0x23), value=4, index=1
imx-usb imx-usb0: Len is 0
imx-usb imx-usb0: req=0 (0x0), type=163 (0xa3), value=0, index=1
usb-hub usb1: portstatus 101, change 13, 12 Mb/s
usb-hub usb1: STAT_C_CONNECTION = 1 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 0
usb-hub usb1: hub_port_reset: trace 1: go out here. portchange: 0x00000013, portstatus: 0x00000101
usb-hub usb1: cannot reset port 1!?
imx-usb imx-usb1: req=6 (0x6), type=128 l(ue=0x80), va256, index=0
imx-usb imx-usb1: USB_DT_DEVICE request
imx-usb imx-usb1: req=5 (0x5), type=0 (0x0), value=2, index=0
imx-usb imx-usb1: USB_REQ_SET_ADDRESS
imx-usb imx-usb1: Len is 0
imx-usb imx-usb1: req=6 (0x6), type=128 (0x80), value=256, ind
ex=0imx-usb imx-usb1: USB_DT_DEVICE request
imx-usb imx-usb1: req=6 (0x6), type=128 (0x80), value=512, index=0
imx-usb imx-usb1: USB_DT_CONFIG config
imx-usb imx-usb1: req=6 (0x ty6),pe=128 (0x80), value=512, index=0
imx-usb imx-usb1: USB_DT_CONFIG config
imx-usb imx-usb1: req=9 (0x9), type=0 (0x0), value=1, index=0
imx-usb imx-usb1: USB_REQ_SET_CONFIGURATION
imx-usb imx-usb1: Len is 0
imx-usb imx-usb1: req=6 (0x6), type=128 (0x80), value=768, index=0
imx-usb imx-usb1:B _USDT_STRING config
imx-usb imx-usb1: req=6 (0x6), type=128 (0x80), value=769, index=1
imx-usb imx-usb1: USB_DT_STRING config
imx-usb imx-usb1: req=6 (0x6), type=128 (0x80),v alue=770, index=1
imx-usb imx-usb1: USB_DT_STRING config
usb: Bus 002 Device 002: ID 0000:0000 EHCI Host Controller
imx-usb imx-usb1: req=6 (0x6), type=160 (0xa0), value=10496, index=0
imx-usb imx-usb1: USB_DT_HUB config
imx-usb imx-usb1: req=6 (0x6), type=160 (0xa0), value=10496, index=0
imx-usb imx-usb1: USB_DT_HUB config
imx-usb imx-usb1: req=0 (0x0), type=160 (0xa0), value=0, index=0
imx-usb imx-usb1: req=1 (0x1), type=35 (0x23), value=8, index=1
imx-usb imx-usb1: Len is 0
imx-usb imx-usb1: req=3 (0x3), type=35 (0x23), value=8, index=1
imx-usb imx-usb1: Len is 0
imx-usb imx-usb1: req=0 (0x0), type=163 (0xa3), value=0, index=1
usb: 2 USB Device(s) found
barebox:/
I get a port reset error:
...
usb-hub usb1: cannot reset port 1!?
...
I added some trace dev_info's in the code and exactly found the failing test,
in the source file 'barebox/drivers/usb/core/hub.c':
int hub_port_reset(struct usb_device *dev, int port,
unsigned short *portstat)
{
...
if ((portchange & USB_PORT_STAT_C_CONNECTION) ||
!(portstatus & USB_PORT_STAT_CONNECTION)) {
dev_info(&dev->dev, "%s: trace 1: go out here. portchange: 0x%08x, portstatus: 0x%08x\n",
__func__, portchange, portstatus);
return -1;
}
if (portstatus & USB_PORT_STAT_ENABLE)
break;
mdelay(200);
...
The failing expression is (portchange & USB_PORT_STAT_C_CONNECTION).
On the other end I'm able to upload and start a barebox image with the tool 'imx-usb-loader',
so the usb otg related HW cannot be badly broken on my custom dev board.
My first basic question is if someone here in the list is also working with an imx25 and can confirm that
the usb otg is .
The second question is about the meaning of the failing expression, in case it could give a hint of
what goes wrong on my board.
thanks,
giorgio
Giorgio, iw3gtf@arcor.de
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [bug report] [media] dib0700_core: don't use stack on I2C reads
From: Dan Carpenter @ 2016-11-14 13:30 UTC (permalink / raw)
To: mchehab; +Cc: linux-media
In-Reply-To: <20161114132142.GA15220@mwanda>
Same for the legacy functions as well.
drivers/media/usb/dvb-usb/dib0700_core.c:338 dib0700_i2c_xfer_legacy() warn: inconsistent returns 'mutex:&d->i2c_mutex'.
Locked on: line 301
line 322
Unlocked on: line 287
line 291
line 338
drivers/media/usb/dvb-usb/dib0700_core.c:338 dib0700_i2c_xfer_legacy() warn: inconsistent returns 'mutex:&d->usb_mutex'.
Locked on: line 301
line 322
Unlocked on: line 287
line 291
line 338
regards,
dan carpenter
^ permalink raw reply
* Re: Including images on Sphinx documents
From: Mauro Carvalho Chehab @ 2016-11-14 13:30 UTC (permalink / raw)
To: Jonathan Corbet
Cc: linux-kernel, linux-media, Jani Nikula, linux-doc,
ksummit-discuss
In-Reply-To: <20161113125250.779df4dd@lwn.net>
Em Sun, 13 Nov 2016 12:52:50 -0700
Jonathan Corbet <corbet@lwn.net> escreveu:
> On Mon, 7 Nov 2016 07:55:24 -0200
> Mauro Carvalho Chehab <mchehab@s-opensource.com> wrote:
>
> > So, we have a few alternatives:
> >
> > 1) copy (or symlink) all rst files to Documentation/output (or to the
> > build dir specified via O= directive) and generate the *.pdf there,
> > and produce those converted images via Makefile.;
> >
> > 2) add an Sphinx extension that would internally call ImageMagick and/or
> > inkscape to convert the bitmap;
> >
> > 3) if possible, add an extension to trick Sphinx for it to consider the
> > output dir as a source dir too.
>
> So, obviously, I've been letting this go by while dealing with other
> stuff...
>
> I really think that 2) is the one we want. Copying all the stuff and
> operating on the copies, beyond being a bit of a hack, just seems like a
> recipe for weird build problems in the future.
Yes, (2) sounds to be the best option.
> We should figure out why PNG files don't work. Maybe I'll give that a
> try at some point soon, if I can find a moment. Working around tools
> bugs seems like the wrong approach.
I appreciate any efforts on that.
> Working from .svg seems optimial, but I don't like the --shell-escape
> thing at all.
>
> [Along those lines, we've picked up a lot of lines like this:
>
> restricted \write18 enabled.
>
> That, too, is shell execution stuff. I've not been able to figure out
> where it came from, but I would sure like to get rid of it...]
Didn't know that! I'm new to LaTeX. Frankly, the log output sounds
very scary to me, as there are lots of warnings there, and debugging
each of them takes time. I don't see any \write18 inside the generated
.tex files or inside the sphinx.sty file. Perhaps it comes from some
Tex extension, like adjustbox?
>
> jon
Thanks,
Mauro
^ permalink raw reply
* Re: [Ksummit-discuss] Including images on Sphinx documents
From: Mauro Carvalho Chehab @ 2016-11-14 13:30 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc, linux-kernel, ksummit-discuss, linux-media
In-Reply-To: <20161113125250.779df4dd@lwn.net>
Em Sun, 13 Nov 2016 12:52:50 -0700
Jonathan Corbet <corbet@lwn.net> escreveu:
> On Mon, 7 Nov 2016 07:55:24 -0200
> Mauro Carvalho Chehab <mchehab@s-opensource.com> wrote:
>
> > So, we have a few alternatives:
> >
> > 1) copy (or symlink) all rst files to Documentation/output (or to the
> > build dir specified via O= directive) and generate the *.pdf there,
> > and produce those converted images via Makefile.;
> >
> > 2) add an Sphinx extension that would internally call ImageMagick and/or
> > inkscape to convert the bitmap;
> >
> > 3) if possible, add an extension to trick Sphinx for it to consider the
> > output dir as a source dir too.
>
> So, obviously, I've been letting this go by while dealing with other
> stuff...
>
> I really think that 2) is the one we want. Copying all the stuff and
> operating on the copies, beyond being a bit of a hack, just seems like a
> recipe for weird build problems in the future.
Yes, (2) sounds to be the best option.
> We should figure out why PNG files don't work. Maybe I'll give that a
> try at some point soon, if I can find a moment. Working around tools
> bugs seems like the wrong approach.
I appreciate any efforts on that.
> Working from .svg seems optimial, but I don't like the --shell-escape
> thing at all.
>
> [Along those lines, we've picked up a lot of lines like this:
>
> restricted \write18 enabled.
>
> That, too, is shell execution stuff. I've not been able to figure out
> where it came from, but I would sure like to get rid of it...]
Didn't know that! I'm new to LaTeX. Frankly, the log output sounds
very scary to me, as there are lots of warnings there, and debugging
each of them takes time. I don't see any \write18 inside the generated
.tex files or inside the sphinx.sty file. Perhaps it comes from some
Tex extension, like adjustbox?
>
> jon
Thanks,
Mauro
^ permalink raw reply
* [OpenRISC] [PATCH v2 9/9] openrisc: include l.swa in check for write data pagefault
From: Stafford Horne @ 2016-11-14 13:30 UTC (permalink / raw)
To: openrisc
In-Reply-To: <1479130239-30707-1-git-send-email-shorne@gmail.com>
From: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
During page fault handling we check the last instruction to understand
if the fault was for a read or for a write. By default we fall back to
read. New instructions were added to the openrisc 1.1 spec for an
atomic load/store pair (l.lwa/l.swa).
This patch adds the opcode for l.swa (0x33) allowing it to be treated as
a write operation.
Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
[shorne at gmail.com: expanded a bit on the comment]
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
arch/openrisc/kernel/entry.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/openrisc/kernel/entry.S b/arch/openrisc/kernel/entry.S
index 572d223..aac0bde 100644
--- a/arch/openrisc/kernel/entry.S
+++ b/arch/openrisc/kernel/entry.S
@@ -264,7 +264,7 @@ EXCEPTION_ENTRY(_data_page_fault_handler)
l.srli r6,r6,26 // check opcode for write access
#endif
- l.sfgeui r6,0x34 // check opcode for write access
+ l.sfgeui r6,0x33 // check opcode for write access
l.bnf 1f
l.sfleui r6,0x37
l.bnf 1f
--
2.7.4
^ permalink raw reply related
* [OpenRISC] [PATCH v2 8/9] openrisc: Updates after openrisc.net has been lost
From: Stafford Horne @ 2016-11-14 13:30 UTC (permalink / raw)
To: openrisc
In-Reply-To: <1479130239-30707-1-git-send-email-shorne@gmail.com>
The openrisc.net domain expired and was taken over by squatters.
These updates point documentation to the new domain, mailing lists
and git repos.
Also, Jonas is not the main maintainer anylonger, he reviews changes
but does not maintain a repo or sent pull requests. Updating this to
add Stafford and Stefan who are the active maintainers.
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
MAINTAINERS | 6 ++++--
arch/openrisc/README.openrisc | 8 ++++----
arch/openrisc/kernel/setup.c | 2 +-
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 851b89b..d84a585 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8958,9 +8958,11 @@ F: drivers/of/resolver.c
OPENRISC ARCHITECTURE
M: Jonas Bonn <jonas@southpole.se>
-W: http://openrisc.net
+M: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
+M: Stafford Horne <shorne@gmail.com>
+L: openrisc at lists.librecores.org
+W: http://openrisc.io
S: Maintained
-T: git git://openrisc.net/~jonas/linux
F: arch/openrisc/
OPENVSWITCH
diff --git a/arch/openrisc/README.openrisc b/arch/openrisc/README.openrisc
index c9f7edf..072069a 100644
--- a/arch/openrisc/README.openrisc
+++ b/arch/openrisc/README.openrisc
@@ -6,7 +6,7 @@ target architecture, specifically, is the 32-bit OpenRISC 1000 family (or1k).
For information about OpenRISC processors and ongoing development:
- website http://openrisc.net
+ website http://openrisc.io
For more information about Linux on OpenRISC, please contact South Pole AB.
@@ -24,17 +24,17 @@ In order to build and run Linux for OpenRISC, you'll need at least a basic
toolchain and, perhaps, the architectural simulator. Steps to get these bits
in place are outlined here.
-1) The toolchain can be obtained from openrisc.net. Instructions for building
+1) The toolchain can be obtained from openrisc.io. Instructions for building
a toolchain can be found at:
-http://openrisc.net/toolchain-build.html
+https://github.com/openrisc/tutorials
2) or1ksim (optional)
or1ksim is the architectural simulator which will allow you to actually run
your OpenRISC Linux kernel if you don't have an OpenRISC processor at hand.
- git clone git://openrisc.net/jonas/or1ksim-svn
+ git clone https://github.com/openrisc/or1ksim.git
cd or1ksim
./configure --prefix=$OPENRISC_PREFIX
diff --git a/arch/openrisc/kernel/setup.c b/arch/openrisc/kernel/setup.c
index 6329d7a..cb797a3 100644
--- a/arch/openrisc/kernel/setup.c
+++ b/arch/openrisc/kernel/setup.c
@@ -295,7 +295,7 @@ void __init setup_arch(char **cmdline_p)
*cmdline_p = boot_command_line;
- printk(KERN_INFO "OpenRISC Linux -- http://openrisc.net\n");
+ printk(KERN_INFO "OpenRISC Linux -- http://openrisc.io\n");
}
static int show_cpuinfo(struct seq_file *m, void *v)
--
2.7.4
^ permalink raw reply related
* [OpenRISC] [PATCH v2 7/9] openrisc: Consolidate setup to use memblock instead of bootmem
From: Stafford Horne @ 2016-11-14 13:30 UTC (permalink / raw)
To: openrisc
In-Reply-To: <1479130239-30707-1-git-send-email-shorne@gmail.com>
Clearing out one todo item. Use the memblock boot time memory
which is the current standard.
Signed-off-by: Stafford Horne <shorne@gmail.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Jonas <jonas@southpole.se>
---
arch/openrisc/Kconfig | 1 +
arch/openrisc/TODO.openrisc | 3 ---
arch/openrisc/include/asm/pgalloc.h | 1 -
arch/openrisc/kernel/setup.c | 36 ++++++++++++------------------------
arch/openrisc/mm/init.c | 2 +-
arch/openrisc/mm/ioremap.c | 4 ----
6 files changed, 14 insertions(+), 33 deletions(-)
diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
index 691e1af..8d22015 100644
--- a/arch/openrisc/Kconfig
+++ b/arch/openrisc/Kconfig
@@ -26,6 +26,7 @@ config OPENRISC
select HAVE_DEBUG_STACKOVERFLOW
select OR1K_PIC
select CPU_NO_EFFICIENT_FFS if !OPENRISC_HAVE_INST_FF1
+ select NO_BOOTMEM
config MMU
def_bool y
diff --git a/arch/openrisc/TODO.openrisc b/arch/openrisc/TODO.openrisc
index acfeef9..0eb04c8 100644
--- a/arch/openrisc/TODO.openrisc
+++ b/arch/openrisc/TODO.openrisc
@@ -5,9 +5,6 @@ that are due for investigation shortly, i.e. our TODO list:
-- Implement the rest of the DMA API... dma_map_sg, etc.
--- Consolidate usage of memblock and bootmem... move everything over to
- memblock.
-
-- Finish the renaming cleanup... there are references to or32 in the code
which was an older name for the architecture. The name we've settled on is
or1k and this change is slowly trickling through the stack. For the time
diff --git a/arch/openrisc/include/asm/pgalloc.h b/arch/openrisc/include/asm/pgalloc.h
index 87eebd1..3e1a466 100644
--- a/arch/openrisc/include/asm/pgalloc.h
+++ b/arch/openrisc/include/asm/pgalloc.h
@@ -23,7 +23,6 @@
#include <linux/threads.h>
#include <linux/mm.h>
#include <linux/memblock.h>
-#include <linux/bootmem.h>
extern int mem_init_done;
diff --git a/arch/openrisc/kernel/setup.c b/arch/openrisc/kernel/setup.c
index d2f78cf..6329d7a 100644
--- a/arch/openrisc/kernel/setup.c
+++ b/arch/openrisc/kernel/setup.c
@@ -50,18 +50,16 @@
#include "vmlinux.h"
-static unsigned long __init setup_memory(void)
+static void __init setup_memory(void)
{
- unsigned long bootmap_size;
unsigned long ram_start_pfn;
- unsigned long free_ram_start_pfn;
unsigned long ram_end_pfn;
phys_addr_t memory_start, memory_end;
struct memblock_region *region;
memory_end = memory_start = 0;
- /* Find main memory where is the kernel */
+ /* Find main memory where is the kernel, we assume its the only one */
for_each_memblock(memory, region) {
memory_start = region->base;
memory_end = region->base + region->size;
@@ -74,10 +72,11 @@ static unsigned long __init setup_memory(void)
}
ram_start_pfn = PFN_UP(memory_start);
- /* free_ram_start_pfn is first page after kernel */
- free_ram_start_pfn = PFN_UP(__pa(_end));
ram_end_pfn = PFN_DOWN(memblock_end_of_DRAM());
+ /* setup bootmem globals (we use no_bootmem, but mm still depends on this) */
+ min_low_pfn = ram_start_pfn;
+ max_low_pfn = ram_end_pfn;
max_pfn = ram_end_pfn;
/*
@@ -85,22 +84,13 @@ static unsigned long __init setup_memory(void)
*
* This makes the memory from the end of the kernel to the end of
* RAM usable.
- * init_bootmem sets the global values min_low_pfn, max_low_pfn.
*/
- bootmap_size = init_bootmem(free_ram_start_pfn,
- ram_end_pfn - ram_start_pfn);
- free_bootmem(PFN_PHYS(free_ram_start_pfn),
- (ram_end_pfn - free_ram_start_pfn) << PAGE_SHIFT);
- reserve_bootmem(PFN_PHYS(free_ram_start_pfn), bootmap_size,
- BOOTMEM_DEFAULT);
-
- for_each_memblock(reserved, region) {
- printk(KERN_INFO "Reserved - 0x%08x-0x%08x\n",
- (u32) region->base, (u32) region->size);
- reserve_bootmem(region->base, region->size, BOOTMEM_DEFAULT);
- }
+ memblock_reserve(__pa(_stext), _end - _stext);
+
+ early_init_fdt_reserve_self();
+ early_init_fdt_scan_reserved_mem();
- return ram_end_pfn;
+ memblock_dump_all();
}
struct cpuinfo cpuinfo;
@@ -272,8 +262,6 @@ void calibrate_delay(void)
void __init setup_arch(char **cmdline_p)
{
- unsigned long max_low_pfn;
-
unflatten_and_copy_device_tree();
setup_cpuinfo();
@@ -294,8 +282,8 @@ void __init setup_arch(char **cmdline_p)
initrd_below_start_ok = 1;
#endif
- /* setup bootmem allocator */
- max_low_pfn = setup_memory();
+ /* setup memblock allocator */
+ setup_memory();
/* paging_init() sets up the MMU and marks all pages as reserved */
paging_init();
diff --git a/arch/openrisc/mm/init.c b/arch/openrisc/mm/init.c
index b782ce9..f67d82b 100644
--- a/arch/openrisc/mm/init.c
+++ b/arch/openrisc/mm/init.c
@@ -106,7 +106,7 @@ static void __init map_ram(void)
}
/* Alloc one page for holding PTE's... */
- pte = (pte_t *) alloc_bootmem_low_pages(PAGE_SIZE);
+ pte = (pte_t *) __va(memblock_alloc(PAGE_SIZE, PAGE_SIZE));
set_pmd(pme, __pmd(_KERNPG_TABLE + __pa(pte)));
/* Fill the newly allocated page with PTE'S */
diff --git a/arch/openrisc/mm/ioremap.c b/arch/openrisc/mm/ioremap.c
index fa60b81..8705a46 100644
--- a/arch/openrisc/mm/ioremap.c
+++ b/arch/openrisc/mm/ioremap.c
@@ -124,11 +124,7 @@ pte_t __ref *pte_alloc_one_kernel(struct mm_struct *mm,
if (likely(mem_init_done)) {
pte = (pte_t *) __get_free_page(GFP_KERNEL);
} else {
- pte = (pte_t *) alloc_bootmem_low_pages(PAGE_SIZE);
-#if 0
- /* FIXME: use memblock... */
pte = (pte_t *) __va(memblock_alloc(PAGE_SIZE, PAGE_SIZE));
-#endif
}
if (pte)
--
2.7.4
^ permalink raw reply related
* [OpenRISC] [PATCH v2 6/9] openrisc: remove the redundant of_platform_populate
From: Stafford Horne @ 2016-11-14 13:30 UTC (permalink / raw)
To: openrisc
In-Reply-To: <1479130239-30707-1-git-send-email-shorne@gmail.com>
From: Rob Herring <robh@kernel.org>
The of_platform_populate call in the openrisc arch code is now redundant
as the DT core provides a default call. Openrisc has a NULL match table
which means only top level nodes with compatible strings will have
devices creates. The default version will also descend nodes in the
match table such as "simple-bus" which should be fine as openrisc
doesn't have any of these (though it is preferred that memory-mapped
peripherals be grouped under a bus node(s)).
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Jonas Bonn <jonas@southpole.se>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
arch/openrisc/kernel/setup.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/arch/openrisc/kernel/setup.c b/arch/openrisc/kernel/setup.c
index b4ed8b3..d2f78cf 100644
--- a/arch/openrisc/kernel/setup.c
+++ b/arch/openrisc/kernel/setup.c
@@ -38,7 +38,6 @@
#include <linux/of.h>
#include <linux/memblock.h>
#include <linux/device.h>
-#include <linux/of_platform.h>
#include <asm/sections.h>
#include <asm/segment.h>
@@ -219,15 +218,6 @@ void __init or32_early_setup(void *fdt)
early_init_devtree(fdt);
}
-static int __init openrisc_device_probe(void)
-{
- of_platform_populate(NULL, NULL, NULL, NULL);
-
- return 0;
-}
-
-device_initcall(openrisc_device_probe);
-
static inline unsigned long extract_value_bits(unsigned long reg,
short bit_nr, short width)
{
--
2.7.4
^ permalink raw reply related
* [OpenRISC] [PATCH v2 5/9] openrisc: add NR_CPUS Kconfig default value
From: Stafford Horne @ 2016-11-14 13:30 UTC (permalink / raw)
To: openrisc
In-Reply-To: <1479130239-30707-1-git-send-email-shorne@gmail.com>
The build system now expects that NR_CPUS is defined.
Follow 4cbbbb4 ("microblaze: Fix missing NR_CPUS in menuconfig")
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
arch/openrisc/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
index 489e7f9..691e1af 100644
--- a/arch/openrisc/Kconfig
+++ b/arch/openrisc/Kconfig
@@ -98,6 +98,9 @@ config OPENRISC_HAVE_INST_DIV
Select this if your implementation has a hardware divide instruction
endmenu
+config NR_CPUS
+ int
+ default "1"
source kernel/Kconfig.hz
source kernel/Kconfig.preempt
--
2.7.4
^ permalink raw reply related
* [OpenRISC] [PATCH v2 4/9] openrisc: Support both old (or32) and new (or1k) toolchain
From: Stafford Horne @ 2016-11-14 13:30 UTC (permalink / raw)
To: openrisc
In-Reply-To: <1479130239-30707-1-git-send-email-shorne@gmail.com>
From: Guenter Roeck <linux@roeck-us.net>
The output file format for or1k has changed from "elf32-or32"
to "elf32-or1k". Select the correct output format automatically
to be able to compile the kernel with both toolchain variants.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
arch/openrisc/kernel/vmlinux.lds.S | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/openrisc/kernel/vmlinux.lds.S b/arch/openrisc/kernel/vmlinux.lds.S
index d68b9ed..ef31fc2 100644
--- a/arch/openrisc/kernel/vmlinux.lds.S
+++ b/arch/openrisc/kernel/vmlinux.lds.S
@@ -30,7 +30,13 @@
#include <asm/cache.h>
#include <asm-generic/vmlinux.lds.h>
-OUTPUT_FORMAT("elf32-or32", "elf32-or32", "elf32-or32")
+#ifdef __OR1K__
+#define __OUTPUT_FORMAT "elf32-or1k"
+#else
+#define __OUTPUT_FORMAT "elf32-or32"
+#endif
+
+OUTPUT_FORMAT(__OUTPUT_FORMAT, __OUTPUT_FORMAT, __OUTPUT_FORMAT)
jiffies = jiffies_64 + 4;
SECTIONS
--
2.7.4
^ permalink raw reply related
* [OpenRISC] [PATCH v2 3/9] openrisc: Add thread-local storage (TLS) support
From: Stafford Horne @ 2016-11-14 13:30 UTC (permalink / raw)
To: openrisc
In-Reply-To: <1479130239-30707-1-git-send-email-shorne@gmail.com>
From: Christian Svensson <blue@cmd.nu>
Historically OpenRISC GCC has reserved r10 which we now use to hold
the thread pointer for thread-local storage (TLS).
Signed-off-by: Christian Svensson <blue@cmd.nu>
Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Signed-off-by: Stafford Horne <shorne@gmail.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
---
arch/openrisc/kernel/process.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/openrisc/kernel/process.c b/arch/openrisc/kernel/process.c
index 7095dfe..277123b 100644
--- a/arch/openrisc/kernel/process.c
+++ b/arch/openrisc/kernel/process.c
@@ -173,6 +173,19 @@ copy_thread(unsigned long clone_flags, unsigned long usp,
if (usp)
userregs->sp = usp;
+
+ /*
+ * For CLONE_SETTLS set "tp" (r10) to the TLS pointer passed to sys_clone.
+ *
+ * The kernel entry is:
+ * int clone (long flags, void *child_stack, int *parent_tid,
+ * int *child_tid, struct void *tls)
+ *
+ * This makes the source r7 in the kernel registers.
+ */
+ if (clone_flags & CLONE_SETTLS)
+ userregs->gpr[10] = userregs->gpr[7];
+
userregs->gpr[11] = 0; /* Result from fork() */
kregs->gpr[20] = 0; /* Userspace thread */
--
2.7.4
^ permalink raw reply related
* [OpenRISC] [PATCH v2 2/9] openrisc: restore all regs on rt_sigreturn
From: Stafford Horne @ 2016-11-14 13:30 UTC (permalink / raw)
To: openrisc
In-Reply-To: <1479130239-30707-1-git-send-email-shorne@gmail.com>
From: Jonas Bonn <jonas@southpole.se>
Fix signal handling for when signals are handled as the result of timers
or exceptions, previous code assumed syscalls. This was noticeable with X
crashing where it uses SIGALRM.
This patch restores all regs before returning to userspace via
_resume_userspace instead of via syscall return path.
The rt_sigreturn syscall is more like a context switch than a function
call; it entails a return from one context (the signal handler) to another
(the process in question). For a context switch like this there are
effectively no call-saved regs that remain constant across the transition.
Reported-by: Sebastian Macke <sebastian@macke.de>
Signed-off-by: Jonas Bonn <jonas@southpole.se>
Tested-by: Guenter Roeck <linux@roeck-us.net>
[shorne at gmail.com: Updated comment better reflect change and issue]
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
arch/openrisc/kernel/entry.S | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/openrisc/kernel/entry.S b/arch/openrisc/kernel/entry.S
index fec8bf9..572d223 100644
--- a/arch/openrisc/kernel/entry.S
+++ b/arch/openrisc/kernel/entry.S
@@ -1101,8 +1101,16 @@ ENTRY(__sys_fork)
l.addi r3,r1,0
ENTRY(sys_rt_sigreturn)
- l.j _sys_rt_sigreturn
+ l.jal _sys_rt_sigreturn
l.addi r3,r1,0
+ l.sfne r30,r0
+ l.bnf _no_syscall_trace
+ l.nop
+ l.jal do_syscall_trace_leave
+ l.addi r3,r1,0
+_no_syscall_trace:
+ l.j _resume_userspace
+ l.nop
/* This is a catch-all syscall for atomic instructions for the OpenRISC 1000.
* The functions takes a variable number of parameters depending on which
--
2.7.4
^ permalink raw reply related
* [OpenRISC] [PATCH v2 1/9] openrisc: fix PTRS_PER_PGD define
From: Stafford Horne @ 2016-11-14 13:30 UTC (permalink / raw)
To: openrisc
In-Reply-To: <1479130239-30707-1-git-send-email-shorne@gmail.com>
From: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
On OpenRISC, with its 8k pages, PAGE_SHIFT is defined to be 13.
That makes the expression (1UL << (PAGE_SHIFT-2)) evaluate
to 2048.
The correct value for PTRS_PER_PGD should be 256.
Correcting the PTRS_PER_PGD define unveiled a bug in map_ram(),
where PTRS_PER_PGD was used when the intent was to iterate
over a set of page table entries.
This patch corrects that issue as well.
Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Signed-off-by: Stafford Horne <shorne@gmail.com>
Acked-by: Jonas Bonn <jonas@southpole.se>
Tested-by: Guenter Roeck <linux@roeck-us.net>
---
arch/openrisc/include/asm/pgtable.h | 2 +-
arch/openrisc/mm/init.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/openrisc/include/asm/pgtable.h b/arch/openrisc/include/asm/pgtable.h
index 69c7df0..3567aa7 100644
--- a/arch/openrisc/include/asm/pgtable.h
+++ b/arch/openrisc/include/asm/pgtable.h
@@ -69,7 +69,7 @@ extern void paging_init(void);
*/
#define PTRS_PER_PTE (1UL << (PAGE_SHIFT-2))
-#define PTRS_PER_PGD (1UL << (PAGE_SHIFT-2))
+#define PTRS_PER_PGD (1UL << (32-PGDIR_SHIFT))
/* calculate how many PGD entries a user-level program can use
* the first mappable virtual address is 0
diff --git a/arch/openrisc/mm/init.c b/arch/openrisc/mm/init.c
index 7f94652..b782ce9 100644
--- a/arch/openrisc/mm/init.c
+++ b/arch/openrisc/mm/init.c
@@ -110,7 +110,7 @@ static void __init map_ram(void)
set_pmd(pme, __pmd(_KERNPG_TABLE + __pa(pte)));
/* Fill the newly allocated page with PTE'S */
- for (j = 0; p < e && j < PTRS_PER_PGD;
+ for (j = 0; p < e && j < PTRS_PER_PTE;
v += PAGE_SIZE, p += PAGE_SIZE, j++, pte++) {
if (v >= (u32) _e_kernel_ro ||
v < (u32) _s_kernel_ro)
--
2.7.4
^ permalink raw reply related
* [OpenRISC] [PATCH v2 0/9] openrisc: Misc fixes from backlog
From: Stafford Horne @ 2016-11-14 13:30 UTC (permalink / raw)
To: openrisc
Hello,
This patch is a small set of fixes from the openrisc backlog. These
changes fix several issues with the openrisc build on modern tool chains
and address other issues which have cropped up as the kernel has been
getting updated.
Consider for Pull:
The following changes since commit a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6:
Linux 4.9-rc5 (2016-11-13 10:32:32 -0800)
are available in the git repository at:
https://github.com/stffrdhrn/linux.git tags/or1k-fixes-4.9
for you to fetch changes up to a9fae5563e34217ff99efafde7e7bf607a5d5ec6:
openrisc: include l.swa in check for write data pagefault (2016-11-14 21:58:33 +0900)
Regards,
Stafford
Changes since V1:
- Removed SMP option patch and replaced with NR_CPUS default value
- Removed Apply transparent_union on semun patch as its handled by libc
- Added memblock patch as suggested by Jonas
- Added MAINTAINERS patch as suggested by Guenter
- Added l.swa patch as its needed to fix musl programs
- Improved commit message on rt_sigreturn patch
Christian Svensson (1):
openrisc: Add thread-local storage (TLS) support
Guenter Roeck (1):
openrisc: Support both old (or32) and new (or1k) toolchain
Jonas Bonn (1):
openrisc: restore all regs on rt_sigreturn
Rob Herring (1):
openrisc: remove the redundant of_platform_populate
Stafford Horne (3):
openrisc: add NR_CPUS Kconfig default value
openrisc: Consolidate setup to use memblock instead of bootmem
openrisc: Updates after openrisc.net has been lost
Stefan Kristiansson (2):
openrisc: fix PTRS_PER_PGD define
openrisc: include l.swa in check for write data pagefault
MAINTAINERS | 6 +++--
arch/openrisc/Kconfig | 4 ++++
arch/openrisc/README.openrisc | 8 +++----
arch/openrisc/TODO.openrisc | 3 ---
arch/openrisc/include/asm/pgalloc.h | 1 -
arch/openrisc/include/asm/pgtable.h | 2 +-
arch/openrisc/kernel/entry.S | 12 ++++++++--
arch/openrisc/kernel/process.c | 13 ++++++++++
arch/openrisc/kernel/setup.c | 48 ++++++++++---------------------------
arch/openrisc/kernel/vmlinux.lds.S | 8 ++++++-
arch/openrisc/mm/init.c | 4 ++--
arch/openrisc/mm/ioremap.c | 4 ----
12 files changed, 58 insertions(+), 55 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/1] ARM: dts: enable GPIO-b for Broadcom NSP
From: Yendapally Reddy Dhananjaya Reddy @ 2016-11-14 13:30 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King, Ray Jui, Scott Branden,
Jon Mason
Cc: bcm-kernel-feedback-list, devicetree, linux-arm-kernel,
linux-kernel, Yendapally Reddy Dhananjaya Reddy
This enables the GPIO-b support for Broadcom NSP SoC
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
---
arch/arm/boot/dts/bcm-nsp.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 7c9e0fa..2f699a0 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -241,6 +241,16 @@
brcm,nand-has-wp;
};
+ gpiob: gpio@30000 {
+ compatible = "brcm,iproc-nsp-gpio", "brcm,iproc-gpio";
+ reg = <0x30000 0x50>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ ngpios = <4>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
pwm: pwm@31000 {
compatible = "brcm,iproc-pwm";
reg = <0x31000 0x28>;
--
2.1.0
^ permalink raw reply related
* [PATCH 1/1] ARM: dts: enable GPIO-b for Broadcom NSP
From: Yendapally Reddy Dhananjaya Reddy @ 2016-11-14 13:30 UTC (permalink / raw)
To: linux-arm-kernel
This enables the GPIO-b support for Broadcom NSP SoC
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
---
arch/arm/boot/dts/bcm-nsp.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 7c9e0fa..2f699a0 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -241,6 +241,16 @@
brcm,nand-has-wp;
};
+ gpiob: gpio at 30000 {
+ compatible = "brcm,iproc-nsp-gpio", "brcm,iproc-gpio";
+ reg = <0x30000 0x50>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ ngpios = <4>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
pwm: pwm at 31000 {
compatible = "brcm,iproc-pwm";
reg = <0x31000 0x28>;
--
2.1.0
^ permalink raw reply related
* Re: Debugging Ethernet issues
From: Mason @ 2016-11-14 13:28 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn
Cc: netdev, Mans Rullgard, Sergei Shtylyov, Tom Lendacky, Zach Brown,
Shaohui Xie, Tim Beale, Brian Hill, Vince Bridgers,
Balakumaran Kannan, David S. Miller, Sebastian Frias,
Kirill Kapranov
In-Reply-To: <9d1f28a7-959b-fdde-3403-f6da5f521125@gmail.com>
On 13/11/2016 20:55, Florian Fainelli wrote:
> Le 13/11/2016 à 11:51, Mason a écrit :
>> On 13/11/2016 04:09, Andrew Lunn wrote:
>>
>>> Mason wrote:
>>>
>>>> When connected to a Gigabit switch
>>>> 3.4 negotiates a LAN DHCP setup instantly
>>>> 4.7 requires over 5 seconds to do so
>>>
>>> When you run tcpdump on the DHCP server, are you noticing the first
>>> request is missing?
>>>
>>> What can happen is the dhclient gets started immediately and sends out
>>> its first request before auto-negotiation has finished. So this first packet
>>> gets lost. The retransmit after a few seconds is then successful.
>>
>> I will run tcpdump on the server as I run udhcpc on the client
>> for Linux 3.4 vs 4.7
>>
>> Do you know what would make auto-negotiation fail at 100 Mbps
>> on 4.7? (whereas it succeeds on 3.4)
>>
>> (Thinking out loud) If the problem were in auto-negotiation,
>> then if should work if I hard-code speed and duplex using
>> ethtool, right? (IIRC, hard-coding doesn't help.)
>
> I would start with checking basic things:
>
> - does your Ethernet driver get a link UP being reported correctly
> (netif_carrier_ok returns 1)?
I don't see any calls to netif_carrier_ok() in the network driver
( drivers/net/ethernet/aurora/nb8800.c )
Maybe it is using some generic infrastructure?
> - if you let the bootloader configure the PHY and utilize the Generic
> PHY driver instead of the Atheros PHY driver, does the problem appear as
> well?
How exactly does one use the generic PHY driver?
Do you mean the following?
Documentation/devicetree/bindings/net/fixed-link.txt
Regards.
^ permalink raw reply
* Re: [RFC v3 00/21] Make use of kref in media device, grab references as needed
From: Sakari Ailus @ 2016-11-14 13:27 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Shuah Khan, Sakari Ailus, linux-media, hverkuil, laurent.pinchart
In-Reply-To: <20161109154608.1e578f9e@vento.lan>
Hi Mauro,
I'm replying below but let me first summarise the remaining problem area
that this patchset addresses.
The problems you and Shuah have seen and partially addressed are related to
a larger picture which is the lifetime of (mostly) memory resources related
to various objects used by as well both the Media controller and V4L2
frameworks (including videobuf2) as the drivers which make use of these
frameworks.
The Media controller and V4L2 interfaces exposed by drivers consist of
multiple devices nodes, data structures with interdependencies within the
frameworks themselves and dependencies from the driver's own data structures
towards the framework data structures. The Media device and the media graph
objects are central to the problem area as well.
So what are the issues then? Until now, we've attempted to regulate the
users' ability to access the devices at the time they're being unregistered
(and the associated memory released), but that approach does not really
scale: you have to make sure that the unregistering also will not take place
_during_ the system call --- not just in the beginning of it.
The media graph contains media graph objects, some of which are media
entities (contained in struct video_device or struct v4l2_subdev, for
instance). Media entities as graph nodes have links to other entities. In
order to implement the system calls, the drivers do parse this graph in
order to obtain information they need to obtain from it. For instance, it's
not uncommon for an implementation for video node format enumeration to
figure out which sub-device the link from that video nodes leads to. Drivers
may also have similar paths they follow.
Interrupt handling may also be taking place during the device removal during
which a number of data structures are now freed. This really does call for a
solution based on reference counting.
This leads to the conclusion that all the memory resources that could be
accessed by the drivers or the kernel frameworks must stay intact until the
last file handle to the said devices is closed. Otherwise, there is a
possibility of accessing released memory.
Right now in a lot of the cases, such as for video device and sub-device
nodes, we do release the memory when a device (as in struct device) is being
unregistered. There simply is in the current mainline kernel a way to do
this in a safe way. Drivers do use devm_() family of functions to allocate
the memory of the media graph object and their internal data structures.
With this patchset:
- The media_device which again contains the media_devnode is allocated
dynamically. The lifetime of the media device --- and the media graph
objects it contains --- is bound to device nodes that are bound to the
media device (video and sub-device nodes) as well as open file handles.
- Care is taken that the unregistration process and releasing memory happens
in the right order. This was not always the case previously.
- The driver remains responsible for the memory of the video and sub-device
nodes. However, now the Media controller provides a convenient callback to
the driver to release any memory resources when the time has come to do
so. This takes place just before the media device memory is released.
- Drivers that do not strictly need to be removable require no changes. The
benefits of this set become tangible for any driver by changing how the
driver allocates memory for the data structures. Ideally at least
drivers for hot-removable devices should be converted.
In order to make the current drivers to behave well it is necessary to make
changes to how memory is allocated in the drivers. If you look at the sample
patches that are part of the set for the omap3isp driver, you'll find that
around 95% of the changes are related to removing the user of devm_() family
of functions instead of Media controller API changes. In this regard, the
approach taken here requires very little if any additional overhead.
On Wed, Nov 09, 2016 at 03:46:08PM -0200, Mauro Carvalho Chehab wrote:
> Em Wed, 9 Nov 2016 10:00:58 -0700
> Shuah Khan <shuahkh@osg.samsung.com> escreveu:
>
> > > Maybe we can get the Media Device Allocator API work in and then we can
> > > get your RFC series in after that. Here is what I propose:
> > >
> > > - Keep the fixes in 4.9
>
> Fixes should always be kept. Reverting a fix is not an option.
> Instead, do incremental patches on the top of it.
>
> > > - Get Media Device Allocator API patches into 4.9.
> >
> > I meant 4.10 not 4.9
> >
> > > - snd-usb-auido work go into 4.10
>
> Sounds like a plan.
>
> > > Then your RFC series could go in. I am looking at the RFC series and that
> > > the drivers need to change as well, so this RFC work could take longer.
> > > Since we have to make media_device sharable, it is necessary to have a
> > > global list approach Media Device Allocator API takes. So it is possible
> > > for your RFC series to go on top of the Media Device Allocator API.
>
> Firstly, the RFC series should be converted into something that can
> be applicable upstream, e. g.:
>
> - doing the changes over the top of upstream, instead of needing to
> revert patches;
The patches are in fact on top of the current media-tree, or were when they
were sent (v4).
The reason I'm reverting patches is that the reason why these patches were
merged was not because they would have been a sound way forward for the
Media controller framework, but because they partially worked around issues
in a device being in use while it was removed.
They never were a complete fix for these problems nor I do think they could
be extended to be such. There were also unaddressed issues in these patches
pointed out during the review. For these reasons I'm reverting the three
patches. In more detail:
* media: fix media devnode ioctl/syscall and unregister race
6f0dd24a084a
The patch clears the registered bit before performing the steps related to
unregistering a media device, but the bit is checked only at the beginning
of the IOCTL call. As unregistering a device and an IOCTL call on a file
handle of that device are not serialised, nothing guarantees the IOCTL call
will finish with the registered bit still in the same state. Serialising the
two e.g. by using a mutex is hardly a feasible solution for this.
I may have pointed out the original problem but this is not the solution.
<URL:http://www.spinics.net/lists/linux-media/msg101295.html>
The right solution is instead to make sure the data structures related to
the media device will not disappear while the IOCTL call is in progress (at
least).
* media: fix use-after-free in cdev_put() when app exits after driver unbind
5b28dde51d0c
The patch avoids the problem of deleting a character device (cdev_del())
after its memory has been released. The change is sound as such but the
problem is addressed by another, a lot more simple patch in my series:
<URL:http://git.retiisi.org.uk/?p=~sailus/linux.git;a=commitdiff;h=26fa8c1a3df5859d34cef8ef953e3a29a432a17b>
It might be possible to reasonably continue from here if the next patch to
be reverted did not depend on this one.
* media-device: dynamically allocate struct media_devnode
This creates a two-way dependency between struct media_devnode and
media_device. This is very much against the original design which clearly
separates the two: media_devnode is entirely independent of media_device.
The original intent was that another sub-system in the kernel such as the
V4L2 could make use of media_devnode as well and while that hasn't happened,
perhaps the two could be merged. There simply are no other reasons to keep
the two structs separate.
The patch is certainly a workaround, as it (partially, again) works around
issues in timing of releasing memory and accessing it.
The proper solutions regarding the media_device and media_devnode are either
maintain the separation or unify the two, and this patch does nor suggests
either of these. To the contrary: it makes either of these impossible by
design, and this reason alone is enough to revert it.
The set I'm pushing maintains the separation and leaves the option of either
merging the two (media_device and media_devnode) or making use of
media_devnode elsewhere open.
> - change all drivers as the kAPI changes;
The patchset actually adds new APIs rather than changing the OLD one --- as
the old one was simply that drivers were responsible for allocating the data
structures related to a media device. Existing drivers should continue to
work as they did before without changes.
Naturally, to get full benetifs of the changes, driver changes will be also
required (see the beginning of the message).
The set has been posted as RFC in order to get reviews. It makes no sense to
convert all the drivers and then start changing APIs, affecting all those
converted drivers.
>
> - be git bisectable, e. g. all patches should compile and run fine
> after each single patch, without introducing regressions.
Compilation has already been tested (on ARM) on each patch applied in order.
>
> That probably means that the series should be tested not only on
> omap3, but also on some other device drivers.
I fully agree with that. More review, testing and changes to at least some
drivers (mostly for removable devices) will be needed before merging them,
that's for sure.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk
^ permalink raw reply
* Re: min/max mtu field in struct net_device
From: Johannes Berg @ 2016-11-14 13:27 UTC (permalink / raw)
To: Arend Van Spriel, backports@vger.kernel.org
In-Reply-To: <57925560-252e-a547-fe09-959362d9dce4@broadcom.com>
> Me too. This is what I got so far, but the callback is generated
> twice
> for net/mac80211/iface.c for obvious reasons (data and monitor ops).
> These are my first baby steps with spatch so not sure how to solve
> it.
Oh, right, that's problematic - no easy way to link the two and know
which one is which ...
I guess we'll have to carry that as a manual patch. We should probably
also ifdef on the kernel version.
johannes
--
To unsubscribe from this list: send the line "unsubscribe backports" in
^ permalink raw reply
* [PATCH] ovl: fix issue with nftw(3) with FTW_MOUNT flag set
From: Quorum Laval @ 2016-11-14 13:27 UTC (permalink / raw)
To: miklos; +Cc: vmlinuz386, linux-unionfs, linux-kernel, quorum.laval
>From glibc2-24/io/ftw.c:
<snippet>
if (result == 0
&& (flag == FTW_NS
|| !(data->flags & FTW_MOUNT) || st.st_dev == data->dev))
<snippet>
st.st_dev == data->dev is false in the cases of non-directory objects,
since st_dev is reported from upper/lower filesystem and ->dev is
reported from overlayfs [0]. So when FTW_NS and FTW_MOUNT are
positionned, non-directory objects will not be reported by nftw(3) [1]. The patch
fixes this.
[0] Documentation/filesystems/overlayfs.txt
[1] https://bugzilla.kernel.org/show_bug.cgi?id=114951
Signed-off-by: Quorum Laval <quorum.laval@gmail.com>
Reported-by: Gerardo Exequiel Pozzi <vmlinuz386@gmail.com>
---
fs/overlayfs/inode.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c
index 7fb53d0..565a7a9 100644
--- a/fs/overlayfs/inode.c
+++ b/fs/overlayfs/inode.c
@@ -116,6 +116,10 @@ static int ovl_getattr(struct vfsmount *mnt, struct dentry *dentry,
old_cred = ovl_override_creds(dentry->d_sb);
err = vfs_getattr(&realpath, stat);
revert_creds(old_cred);
+
+ stat->dev = dentry->d_sb->s_dev;
+ stat->ino = dentry->d_inode->i_ino;
+
return err;
}
--
2.7.4
^ permalink raw reply related
* Re: [Bug 186671] New: OOM on system with just rsync running 32GB of ram 30GB of pagecache
From: E V @ 2016-11-14 13:27 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Andrew Morton, bugzilla-daemon, linux-mm, Michal Hocko,
linux-btrfs
In-Reply-To: <a8cf869e-f527-9c65-d16d-ac70cf66472a@suse.cz>
System is an intel dual socket Xeon E5620, 7500/5520/5500/X58 ICH10
family according to lspci. Anyways 4.8.4 OOM'd while I was gone. I'll
download the current 4.9rc and reboot, but in the mean time here's
xxd, vmstat & kern.log output:
8532039 0000000000000000
9324 0100000000000000
2226 0200000000000000
405 0300000000000000
80 0400000000000000
34 0500000000000000
48 0600000000000000
17 0700000000000000
17 0800000000000000
32 0900000000000000
19 0a00000000000000
1 0c00000000000000
1 0d00000000000000
1 0e00000000000000
12 1000000000000000
8 1100000000000000
32 1200000000000000
10 1300000000000000
2 1400000000000000
11 1500000000000000
12 1600000000000000
7 1700000000000000
3 1800000000000000
5 1900000000000000
6 1a00000000000000
11 1b00000000000000
22 1c00000000000000
3 1d00000000000000
19 1e00000000000000
21 1f00000000000000
18 2000000000000000
28 2100000000000000
40 2200000000000000
38 2300000000000000
85 2400000000000000
59 2500000000000000
40520 81ffffffffffffff
/proc/vmstat:
nr_free_pages 60965
nr_zone_inactive_anon 4646
nr_zone_active_anon 3265
nr_zone_inactive_file 633882
nr_zone_active_file 7017458
nr_zone_unevictable 0
nr_zone_write_pending 0
nr_mlock 0
nr_slab_reclaimable 299205
nr_slab_unreclaimable 195497
nr_page_table_pages 935
nr_kernel_stack 4976
nr_bounce 0
numa_hit 3577063288
numa_miss 541393191
numa_foreign 541393191
numa_interleave 19415
numa_local 3577063288
numa_other 0
nr_free_cma 0
nr_inactive_anon 4646
nr_active_anon 3265
nr_inactive_file 633882
nr_active_file 7017458
nr_unevictable 0
nr_isolated_anon 0
nr_isolated_file 0
nr_pages_scanned 0
workingset_refault 42685891
workingset_activate 15247281
workingset_nodereclaim 26375216
nr_anon_pages 5067
nr_mapped 5630
nr_file_pages 7654746
nr_dirty 0
nr_writeback 0
nr_writeback_temp 0
nr_shmem 2504
nr_shmem_hugepages 0
nr_shmem_pmdmapped 0
nr_anon_transparent_hugepages 0
nr_unstable 0
nr_vmscan_write 5243750485
nr_vmscan_immediate_reclaim 4207633857
nr_dirtied 1839143430
nr_written 1832626107
nr_dirty_threshold 1147728
nr_dirty_background_threshold 151410
pgpgin 166731189
pgpgout 7328142335
pswpin 98608
pswpout 117794
pgalloc_dma 29504
pgalloc_dma32 1006726216
pgalloc_normal 5275218188
pgalloc_movable 0
allocstall_dma 0
allocstall_dma32 0
allocstall_normal 36461
allocstall_movable 5867
pgskip_dma 0
pgskip_dma32 0
pgskip_normal 6417890
pgskip_movable 0
pgfree 6309223401
pgactivate 35076483
pgdeactivate 63556974
pgfault 35753842
pgmajfault 69126
pglazyfreed 0
pgrefill 70008598
pgsteal_kswapd 3567289713
pgsteal_direct 5878057
pgscan_kswapd 9059309872
pgscan_direct 4239367903
pgscan_direct_throttle 0
zone_reclaim_failed 0
pginodesteal 102916
slabs_scanned 460790262
kswapd_inodesteal 9130243
kswapd_low_wmark_hit_quickly 10634373
kswapd_high_wmark_hit_quickly 7348173
pageoutrun 18349115
pgrotated 16291322
drop_pagecache 0
drop_slab 0
pgmigrate_success 18912908
pgmigrate_fail 63382146
compact_migrate_scanned 2986269789
compact_free_scanned 190451505123
compact_isolated 109549437
compact_stall 3544
compact_fail 8
compact_success 3536
compact_daemon_wake 1403515
htlb_buddy_alloc_success 0
htlb_buddy_alloc_fail 0
unevictable_pgs_culled 12473
unevictable_pgs_scanned 0
unevictable_pgs_rescued 11979
unevictable_pgs_mlocked 14556
unevictable_pgs_munlocked 14556
unevictable_pgs_cleared 0
unevictable_pgs_stranded 0
thp_fault_alloc 0
thp_fault_fallback 0
thp_collapse_alloc 0
thp_collapse_alloc_failed 0
thp_file_alloc 0
thp_file_mapped 0
thp_split_page 0
thp_split_page_failed 0
thp_deferred_split_page 0
thp_split_pmd 0
thp_zero_page_alloc 0
thp_zero_page_alloc_failed 0
kern.log OOM message:
[737778.724194] snmpd invoked oom-killer:
gfp_mask=0x24200ca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
[737778.724246] snmpd cpuset=/ mems_allowed=0-1
[737778.724278] CPU: 15 PID: 2976 Comm: snmpd Tainted: G W I 4.8.4 #1
[737778.724352] 0000000000000000 ffffffff81292069 ffff88041e043c48
ffff88041e043c48
[737778.724403] ffffffff8118d1f6 ffff88041dd70fc0 ffff88041e043c48
000000000136236f
[737778.724454] ffffffff8170e11e 0000000000000001 ffffffff8112a700
000000000000030f
[737778.724505] Call Trace:
[737778.724533] [<ffffffff81292069>] ? dump_stack+0x46/0x5d
[737778.727077] [<ffffffff8118d1f6>] ? dump_header.isra.16+0x56/0x185
[737778.727108] [<ffffffff8112a700>] ? oom_kill_process+0x210/0x3c0
[737778.727136] [<ffffffff8112ac4b>] ? out_of_memory+0x34b/0x420
[737778.727165] [<ffffffff8112fcca>] ? __alloc_pages_nodemask+0xd9a/0xde0
[737778.727195] [<ffffffff811768e1>] ? alloc_pages_vma+0xc1/0x240
[737778.727223] [<ffffffff81126512>] ? pagecache_get_page+0x22/0x230
[737778.727253] [<ffffffff81169f44>] ? __read_swap_cache_async+0x104/0x180
[737778.727282] [<ffffffff81169fcf>] ? read_swap_cache_async+0xf/0x30
[737778.727311] [<ffffffff8116a0dc>] ? swapin_readahead+0xec/0x1a0
[737778.727340] [<ffffffff81156270>] ? do_swap_page+0x420/0x5c0
[737778.727369] [<ffffffff813f36d8>] ? SYSC_recvfrom+0xa8/0x110
[737778.727397] [<ffffffff81157a39>] ? handle_mm_fault+0x629/0xe30
[737778.727426] [<ffffffff81048fc5>] ? __do_page_fault+0x1b5/0x480
[737778.727456] [<ffffffff814fbaa2>] ? page_fault+0x22/0x30
[737778.727497] Mem-Info:
[737778.727524] active_anon:24 inactive_anon:49 isolated_anon:0
[737778.727524] active_file:6920154 inactive_file:798043 isolated_file:576
[737778.727524] unevictable:0 dirty:800528 writeback:1307 unstable:0
[737778.727524] slab_reclaimable:264367 slab_unreclaimable:193348
[737778.727524] mapped:4063 shmem:0 pagetables:1719 bounce:0
[737778.727524] free:39225 free_pcp:47 free_cma:0
[737778.727677] Node 0 active_anon:16kB inactive_anon:76kB
active_file:14249324kB inactive_file:1296908kB unevictable:0kB
isolated(anon):0kB isolated(file):1920kB mapped:10432kB
dirty:1308528kB writeback:0kB shmem:0kB shmem_thp: 0kB
shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB unstable:0kB
pages_scanned:23557303 all_unreclaimable? yes
[737778.727806] Node 1 active_anon:80kB inactive_anon:120kB
active_file:13431292kB inactive_file:1895264kB unevictable:0kB
isolated(anon):0kB isolated(file):384kB mapped:5820kB dirty:1893584kB
writeback:5228kB shmem:0kB shmem_thp: 0kB shmem_pmdmapped: 0kB
anon_thp: 0kB writeback_tmp:0kB unstable:0kB pages_scanned:25598673
all_unreclaimable? yes
[737778.727930] Node 0 Normal free:44864kB min:45192kB low:61736kB
high:78280kB active_anon:16kB inactive_anon:76kB
active_file:14249324kB inactive_file:1296908kB unevictable:0kB
writepending:1308528kB present:16777216kB managed:16544856kB
mlocked:0kB slab_reclaimable:562644kB slab_unreclaimable:317504kB
kernel_stack:3840kB pagetables:3672kB bounce:0kB free_pcp:20kB
local_pcp:0kB free_cma:0kB
[737778.728066] lowmem_reserve[]: 0 0 0 0
[737778.728100] Node 1 DMA free:15896kB min:40kB low:52kB high:64kB
active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB
unevictable:0kB writepending:0kB present:15996kB managed:15896kB
mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:0kB
kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB
free_cma:0kB
[737778.728228] lowmem_reserve[]: 0 3216 16044 16044
[737778.728263] Node 1 DMA32 free:60300kB min:8996kB low:12288kB
high:15580kB active_anon:4kB inactive_anon:4kB active_file:2660988kB
inactive_file:474956kB unevictable:0kB writepending:475116kB
present:3378660kB managed:3304720kB mlocked:0kB
slab_reclaimable:83612kB slab_unreclaimable:16668kB kernel_stack:320kB
pagetables:16kB bounce:0kB free_pcp:4kB local_pcp:4kB free_cma:0kB
[737778.728397] lowmem_reserve[]: 0 0 12827 12827
[737778.728431] Node 1 Normal free:35840kB min:35876kB low:49008kB
high:62140kB active_anon:76kB inactive_anon:116kB
active_file:10770304kB inactive_file:1420308kB unevictable:0kB
writepending:1423696kB present:13369344kB managed:13135424kB
mlocked:0kB slab_reclaimable:411212kB slab_unreclaimable:439220kB
kernel_stack:2864kB pagetables:3188kB bounce:0kB free_pcp:164kB
local_pcp:36kB free_cma:0kB
[737778.728568] lowmem_reserve[]: 0 0 0 0
[737778.728601] Node 0 Normal: 11208*4kB (UME) 4*8kB (U) 0*16kB 0*32kB
0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 44864kB
[737778.728686] Node 1 DMA: 0*4kB 1*8kB (U) 1*16kB (U) 0*32kB 2*64kB
(U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB
(M) = 15896kB
[737778.728786] Node 1 DMA32: 11759*4kB (UME) 1658*8kB (UM) 0*16kB
0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB =
60300kB
[737778.728875] Node 1 Normal: 7984*4kB (UME) 470*8kB (UME) 3*16kB (U)
3*32kB (UM) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB
= 35840kB
[737778.728973] Node 0 hugepages_total=0 hugepages_free=0
hugepages_surp=0 hugepages_size=1048576kB
[737778.729019] Node 0 hugepages_total=0 hugepages_free=0
hugepages_surp=0 hugepages_size=2048kB
[737778.729065] Node 1 hugepages_total=0 hugepages_free=0
hugepages_surp=0 hugepages_size=1048576kB
[737778.729111] Node 1 hugepages_total=0 hugepages_free=0
hugepages_surp=0 hugepages_size=2048kB
[737778.729156] 7718841 total pagecache pages
[737778.729179] 68 pages in swap cache
[737778.729202] Swap cache stats: add 193888, delete 193820, find 160188/213014
[737778.729231] Free swap = 48045076kB
[737778.729254] Total swap = 48300028kB
[737778.729277] 8385304 pages RAM
[737778.729299] 0 pages HighMem/MovableOnly
[737778.729322] 135080 pages reserved
[737778.729344] 0 pages hwpoisoned
[737778.729365] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds
swapents oom_score_adj name
[737778.729417] [ 1927] 0 1927 9941 447 22 3
299 -1000 systemd-udevd
[737778.729465] [ 2812] 0 2812 9289 412 23 4
161 0 rpcbind
[737778.729512] [ 2836] 102 2836 9320 414 23 3
151 0 rpc.statd
[737778.729560] [ 2851] 104 2851 162257 276 75 3
7489 0 apt-cacher-ng
[737778.729608] [ 2856] 0 2856 13796 345 31 3
167 -1000 sshd
[737778.729655] [ 2857] 0 2857 64668 504 27 4
355 0 rsyslogd
[737778.729702] [ 2858] 0 2858 6876 518 18 3
83 0 cron
[737778.729748] [ 2859] 0 2859 4756 360 14 3
44 0 atd
[737778.729795] [ 2860] 0 2860 7059 523 18 3
591 0 smartd
[737778.729842] [ 2864] 0 2864 7082 559 19 4
96 0 systemd-logind
[737778.729890] [ 2865] 106 2865 10563 528 24 3
110 -900 dbus-daemon
[737778.729938] [ 2925] 0 2925 3604 421 12 3
38 0 agetty
[737778.729985] [ 2974] 0 2974 4852 365 13 3
73 0 irqbalance
[737778.730032] [ 2976] 105 2976 14299 496 29 3
1534 0 snmpd
[737778.730078] [ 2992] 0 2992 3180 227 11 3
38 0 mcelog
[737778.730125] [ 3095] 0 3095 26571 344 43 3
259 0 sfcbd
[737778.730172] [ 3172] 0 3172 20392 261 40 3
236 0 sfcbd
[737778.730219] [ 3248] 0 3248 22441 0 41 3
238 0 sfcbd
[737778.730265] [ 3249] 0 3249 39376 155 44 3
357 0 sfcbd
[737778.730312] [ 3450] 0 3450 39377 104 44 3
244 0 sfcbd
[737778.730359] [ 3467] 0 3467 58324 301 46 3
284 0 sfcbd
[737778.730405] [ 3548] 0 3548 262686 643 66 4
4097 0 dsm_sa_datamgrd
[737778.730453] [ 3563] 101 3563 13312 403 29 3
162 0 exim4
[737778.730499] [ 3576] 107 3576 7293 493 19 3
148 0 ntpd
[737778.730546] [ 3585] 0 3585 61531 577 117 3
496 0 winbindd
[737778.730593] [ 3586] 0 3586 61531 578 118 3
512 0 winbindd
[737778.730640] [ 3651] 0 3651 48584 566 36 3
487 0 dsm_sa_eventmgr
[737778.730688] [ 3674] 0 3674 99593 576 47 3
1402 0 dsm_sa_snmpd
[737778.730736] [ 3717] 0 3717 7923 285 18 3
115 0 dsm_om_connsvcd
[737778.730784] [ 3718] 0 3718 740234 1744 202 7
30685 0 dsm_om_connsvcd
[737778.730832] [ 3736] 0 3736 178651 0 55 3
3789 0 dsm_sa_datamgrd
[737778.730880] [ 4056] 0 4056 26472 498 57 3
252 0 sshd
[737778.730926] [ 4060] 1000 4060 8973 501 23 3
184 0 systemd
[737778.730973] [ 4061] 1000 4061 15702 0 34 4
612 0 (sd-pam)
[737778.731020] [ 4063] 1000 4063 26472 158 54 3
260 0 sshd
[737778.731067] [ 4064] 1000 4064 6041 739 16 3
686 0 bash
[737778.731113] [ 4083] 1000 4083 16853 493 37 3
128 0 su
[737778.731160] [ 4084] 0 4084 5501 756 15 3
160 0 bash
[737778.731207] [15150] 0 15150 3309 678 10 3
57 0 run_mirror.sh
[737778.731256] [24296] 0 24296 1450 139 8 3
23 0 flock
[737778.731302] [24297] 0 24297 9576 622 22 3
3990 0 rsync
[737778.731349] [24298] 0 24298 7552 541 18 3
1073 0 rsync
[737778.731395] [24299] 0 24299 9522 401 22 3
2416 0 rsync
[737778.731445] [25910] 0 25910 10257 522 23 3
81 0 systemd-journal
[737778.731494] [25940] 0 25940 16365 617 37 3
126 0 cron
[737778.731540] Out of memory: Kill process 3718 (dsm_om_connsvcd)
score 1 or sacrifice child
[737778.731644] Killed process 3718 (dsm_om_connsvcd)
total-vm:2960936kB, anon-rss:0kB, file-rss:6976kB, shmem-rss:0kB
[737778.768375] oom_reaper: reaped process 3718 (dsm_om_connsvcd), now
anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
On Fri, Nov 4, 2016 at 5:00 PM, Vlastimil Babka <vbabka@suse.cz> wrote:
> On 11/04/2016 03:13 PM, E V wrote:
>> After the system panic'd yesterday I booted back into 4.8.4 and
>> restarted the rsync's. I'm away on vacation next week, so when I get
>> back I'll get rc4 or rc5 and try again. In the mean time here's data
>> from the system running 4.8.4 without problems for about a day. I'm
>> not familiar with xxd and didn't see a -e option, so used -E:
>> xxd -E -g8 -c8 /proc/kpagecount | cut -d" " -f2 | sort | uniq -c
>> 8258633 0000000000000000
>> 216440 0100000000000000
>
> The lack of -e means it's big endian, which is not a big issue. So here
> most of memory is free, some pages have just one pin, and only
> relatively few have more. The vmstats also doesn't show anything bad, so
> we'll have to wait if something appears within the week, or after you
> try 4.9 again. Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [Bug 186671] New: OOM on system with just rsync running 32GB of ram 30GB of pagecache
From: E V @ 2016-11-14 13:27 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Andrew Morton, bugzilla-daemon, linux-mm, Michal Hocko,
linux-btrfs
In-Reply-To: <a8cf869e-f527-9c65-d16d-ac70cf66472a@suse.cz>
System is an intel dual socket Xeon E5620, 7500/5520/5500/X58 ICH10
family according to lspci. Anyways 4.8.4 OOM'd while I was gone. I'll
download the current 4.9rc and reboot, but in the mean time here's
xxd, vmstat & kern.log output:
8532039 0000000000000000
9324 0100000000000000
2226 0200000000000000
405 0300000000000000
80 0400000000000000
34 0500000000000000
48 0600000000000000
17 0700000000000000
17 0800000000000000
32 0900000000000000
19 0a00000000000000
1 0c00000000000000
1 0d00000000000000
1 0e00000000000000
12 1000000000000000
8 1100000000000000
32 1200000000000000
10 1300000000000000
2 1400000000000000
11 1500000000000000
12 1600000000000000
7 1700000000000000
3 1800000000000000
5 1900000000000000
6 1a00000000000000
11 1b00000000000000
22 1c00000000000000
3 1d00000000000000
19 1e00000000000000
21 1f00000000000000
18 2000000000000000
28 2100000000000000
40 2200000000000000
38 2300000000000000
85 2400000000000000
59 2500000000000000
40520 81ffffffffffffff
/proc/vmstat:
nr_free_pages 60965
nr_zone_inactive_anon 4646
nr_zone_active_anon 3265
nr_zone_inactive_file 633882
nr_zone_active_file 7017458
nr_zone_unevictable 0
nr_zone_write_pending 0
nr_mlock 0
nr_slab_reclaimable 299205
nr_slab_unreclaimable 195497
nr_page_table_pages 935
nr_kernel_stack 4976
nr_bounce 0
numa_hit 3577063288
numa_miss 541393191
numa_foreign 541393191
numa_interleave 19415
numa_local 3577063288
numa_other 0
nr_free_cma 0
nr_inactive_anon 4646
nr_active_anon 3265
nr_inactive_file 633882
nr_active_file 7017458
nr_unevictable 0
nr_isolated_anon 0
nr_isolated_file 0
nr_pages_scanned 0
workingset_refault 42685891
workingset_activate 15247281
workingset_nodereclaim 26375216
nr_anon_pages 5067
nr_mapped 5630
nr_file_pages 7654746
nr_dirty 0
nr_writeback 0
nr_writeback_temp 0
nr_shmem 2504
nr_shmem_hugepages 0
nr_shmem_pmdmapped 0
nr_anon_transparent_hugepages 0
nr_unstable 0
nr_vmscan_write 5243750485
nr_vmscan_immediate_reclaim 4207633857
nr_dirtied 1839143430
nr_written 1832626107
nr_dirty_threshold 1147728
nr_dirty_background_threshold 151410
pgpgin 166731189
pgpgout 7328142335
pswpin 98608
pswpout 117794
pgalloc_dma 29504
pgalloc_dma32 1006726216
pgalloc_normal 5275218188
pgalloc_movable 0
allocstall_dma 0
allocstall_dma32 0
allocstall_normal 36461
allocstall_movable 5867
pgskip_dma 0
pgskip_dma32 0
pgskip_normal 6417890
pgskip_movable 0
pgfree 6309223401
pgactivate 35076483
pgdeactivate 63556974
pgfault 35753842
pgmajfault 69126
pglazyfreed 0
pgrefill 70008598
pgsteal_kswapd 3567289713
pgsteal_direct 5878057
pgscan_kswapd 9059309872
pgscan_direct 4239367903
pgscan_direct_throttle 0
zone_reclaim_failed 0
pginodesteal 102916
slabs_scanned 460790262
kswapd_inodesteal 9130243
kswapd_low_wmark_hit_quickly 10634373
kswapd_high_wmark_hit_quickly 7348173
pageoutrun 18349115
pgrotated 16291322
drop_pagecache 0
drop_slab 0
pgmigrate_success 18912908
pgmigrate_fail 63382146
compact_migrate_scanned 2986269789
compact_free_scanned 190451505123
compact_isolated 109549437
compact_stall 3544
compact_fail 8
compact_success 3536
compact_daemon_wake 1403515
htlb_buddy_alloc_success 0
htlb_buddy_alloc_fail 0
unevictable_pgs_culled 12473
unevictable_pgs_scanned 0
unevictable_pgs_rescued 11979
unevictable_pgs_mlocked 14556
unevictable_pgs_munlocked 14556
unevictable_pgs_cleared 0
unevictable_pgs_stranded 0
thp_fault_alloc 0
thp_fault_fallback 0
thp_collapse_alloc 0
thp_collapse_alloc_failed 0
thp_file_alloc 0
thp_file_mapped 0
thp_split_page 0
thp_split_page_failed 0
thp_deferred_split_page 0
thp_split_pmd 0
thp_zero_page_alloc 0
thp_zero_page_alloc_failed 0
kern.log OOM message:
[737778.724194] snmpd invoked oom-killer:
gfp_mask=0x24200ca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
[737778.724246] snmpd cpuset=/ mems_allowed=0-1
[737778.724278] CPU: 15 PID: 2976 Comm: snmpd Tainted: G W I 4.8.4 #1
[737778.724352] 0000000000000000 ffffffff81292069 ffff88041e043c48
ffff88041e043c48
[737778.724403] ffffffff8118d1f6 ffff88041dd70fc0 ffff88041e043c48
000000000136236f
[737778.724454] ffffffff8170e11e 0000000000000001 ffffffff8112a700
000000000000030f
[737778.724505] Call Trace:
[737778.724533] [<ffffffff81292069>] ? dump_stack+0x46/0x5d
[737778.727077] [<ffffffff8118d1f6>] ? dump_header.isra.16+0x56/0x185
[737778.727108] [<ffffffff8112a700>] ? oom_kill_process+0x210/0x3c0
[737778.727136] [<ffffffff8112ac4b>] ? out_of_memory+0x34b/0x420
[737778.727165] [<ffffffff8112fcca>] ? __alloc_pages_nodemask+0xd9a/0xde0
[737778.727195] [<ffffffff811768e1>] ? alloc_pages_vma+0xc1/0x240
[737778.727223] [<ffffffff81126512>] ? pagecache_get_page+0x22/0x230
[737778.727253] [<ffffffff81169f44>] ? __read_swap_cache_async+0x104/0x180
[737778.727282] [<ffffffff81169fcf>] ? read_swap_cache_async+0xf/0x30
[737778.727311] [<ffffffff8116a0dc>] ? swapin_readahead+0xec/0x1a0
[737778.727340] [<ffffffff81156270>] ? do_swap_page+0x420/0x5c0
[737778.727369] [<ffffffff813f36d8>] ? SYSC_recvfrom+0xa8/0x110
[737778.727397] [<ffffffff81157a39>] ? handle_mm_fault+0x629/0xe30
[737778.727426] [<ffffffff81048fc5>] ? __do_page_fault+0x1b5/0x480
[737778.727456] [<ffffffff814fbaa2>] ? page_fault+0x22/0x30
[737778.727497] Mem-Info:
[737778.727524] active_anon:24 inactive_anon:49 isolated_anon:0
[737778.727524] active_file:6920154 inactive_file:798043 isolated_file:576
[737778.727524] unevictable:0 dirty:800528 writeback:1307 unstable:0
[737778.727524] slab_reclaimable:264367 slab_unreclaimable:193348
[737778.727524] mapped:4063 shmem:0 pagetables:1719 bounce:0
[737778.727524] free:39225 free_pcp:47 free_cma:0
[737778.727677] Node 0 active_anon:16kB inactive_anon:76kB
active_file:14249324kB inactive_file:1296908kB unevictable:0kB
isolated(anon):0kB isolated(file):1920kB mapped:10432kB
dirty:1308528kB writeback:0kB shmem:0kB shmem_thp: 0kB
shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB unstable:0kB
pages_scanned:23557303 all_unreclaimable? yes
[737778.727806] Node 1 active_anon:80kB inactive_anon:120kB
active_file:13431292kB inactive_file:1895264kB unevictable:0kB
isolated(anon):0kB isolated(file):384kB mapped:5820kB dirty:1893584kB
writeback:5228kB shmem:0kB shmem_thp: 0kB shmem_pmdmapped: 0kB
anon_thp: 0kB writeback_tmp:0kB unstable:0kB pages_scanned:25598673
all_unreclaimable? yes
[737778.727930] Node 0 Normal free:44864kB min:45192kB low:61736kB
high:78280kB active_anon:16kB inactive_anon:76kB
active_file:14249324kB inactive_file:1296908kB unevictable:0kB
writepending:1308528kB present:16777216kB managed:16544856kB
mlocked:0kB slab_reclaimable:562644kB slab_unreclaimable:317504kB
kernel_stack:3840kB pagetables:3672kB bounce:0kB free_pcp:20kB
local_pcp:0kB free_cma:0kB
[737778.728066] lowmem_reserve[]: 0 0 0 0
[737778.728100] Node 1 DMA free:15896kB min:40kB low:52kB high:64kB
active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB
unevictable:0kB writepending:0kB present:15996kB managed:15896kB
mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:0kB
kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB
free_cma:0kB
[737778.728228] lowmem_reserve[]: 0 3216 16044 16044
[737778.728263] Node 1 DMA32 free:60300kB min:8996kB low:12288kB
high:15580kB active_anon:4kB inactive_anon:4kB active_file:2660988kB
inactive_file:474956kB unevictable:0kB writepending:475116kB
present:3378660kB managed:3304720kB mlocked:0kB
slab_reclaimable:83612kB slab_unreclaimable:16668kB kernel_stack:320kB
pagetables:16kB bounce:0kB free_pcp:4kB local_pcp:4kB free_cma:0kB
[737778.728397] lowmem_reserve[]: 0 0 12827 12827
[737778.728431] Node 1 Normal free:35840kB min:35876kB low:49008kB
high:62140kB active_anon:76kB inactive_anon:116kB
active_file:10770304kB inactive_file:1420308kB unevictable:0kB
writepending:1423696kB present:13369344kB managed:13135424kB
mlocked:0kB slab_reclaimable:411212kB slab_unreclaimable:439220kB
kernel_stack:2864kB pagetables:3188kB bounce:0kB free_pcp:164kB
local_pcp:36kB free_cma:0kB
[737778.728568] lowmem_reserve[]: 0 0 0 0
[737778.728601] Node 0 Normal: 11208*4kB (UME) 4*8kB (U) 0*16kB 0*32kB
0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 44864kB
[737778.728686] Node 1 DMA: 0*4kB 1*8kB (U) 1*16kB (U) 0*32kB 2*64kB
(U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB
(M) = 15896kB
[737778.728786] Node 1 DMA32: 11759*4kB (UME) 1658*8kB (UM) 0*16kB
0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB =
60300kB
[737778.728875] Node 1 Normal: 7984*4kB (UME) 470*8kB (UME) 3*16kB (U)
3*32kB (UM) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB
= 35840kB
[737778.728973] Node 0 hugepages_total=0 hugepages_free=0
hugepages_surp=0 hugepages_size=1048576kB
[737778.729019] Node 0 hugepages_total=0 hugepages_free=0
hugepages_surp=0 hugepages_size=2048kB
[737778.729065] Node 1 hugepages_total=0 hugepages_free=0
hugepages_surp=0 hugepages_size=1048576kB
[737778.729111] Node 1 hugepages_total=0 hugepages_free=0
hugepages_surp=0 hugepages_size=2048kB
[737778.729156] 7718841 total pagecache pages
[737778.729179] 68 pages in swap cache
[737778.729202] Swap cache stats: add 193888, delete 193820, find 160188/213014
[737778.729231] Free swap = 48045076kB
[737778.729254] Total swap = 48300028kB
[737778.729277] 8385304 pages RAM
[737778.729299] 0 pages HighMem/MovableOnly
[737778.729322] 135080 pages reserved
[737778.729344] 0 pages hwpoisoned
[737778.729365] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds
swapents oom_score_adj name
[737778.729417] [ 1927] 0 1927 9941 447 22 3
299 -1000 systemd-udevd
[737778.729465] [ 2812] 0 2812 9289 412 23 4
161 0 rpcbind
[737778.729512] [ 2836] 102 2836 9320 414 23 3
151 0 rpc.statd
[737778.729560] [ 2851] 104 2851 162257 276 75 3
7489 0 apt-cacher-ng
[737778.729608] [ 2856] 0 2856 13796 345 31 3
167 -1000 sshd
[737778.729655] [ 2857] 0 2857 64668 504 27 4
355 0 rsyslogd
[737778.729702] [ 2858] 0 2858 6876 518 18 3
83 0 cron
[737778.729748] [ 2859] 0 2859 4756 360 14 3
44 0 atd
[737778.729795] [ 2860] 0 2860 7059 523 18 3
591 0 smartd
[737778.729842] [ 2864] 0 2864 7082 559 19 4
96 0 systemd-logind
[737778.729890] [ 2865] 106 2865 10563 528 24 3
110 -900 dbus-daemon
[737778.729938] [ 2925] 0 2925 3604 421 12 3
38 0 agetty
[737778.729985] [ 2974] 0 2974 4852 365 13 3
73 0 irqbalance
[737778.730032] [ 2976] 105 2976 14299 496 29 3
1534 0 snmpd
[737778.730078] [ 2992] 0 2992 3180 227 11 3
38 0 mcelog
[737778.730125] [ 3095] 0 3095 26571 344 43 3
259 0 sfcbd
[737778.730172] [ 3172] 0 3172 20392 261 40 3
236 0 sfcbd
[737778.730219] [ 3248] 0 3248 22441 0 41 3
238 0 sfcbd
[737778.730265] [ 3249] 0 3249 39376 155 44 3
357 0 sfcbd
[737778.730312] [ 3450] 0 3450 39377 104 44 3
244 0 sfcbd
[737778.730359] [ 3467] 0 3467 58324 301 46 3
284 0 sfcbd
[737778.730405] [ 3548] 0 3548 262686 643 66 4
4097 0 dsm_sa_datamgrd
[737778.730453] [ 3563] 101 3563 13312 403 29 3
162 0 exim4
[737778.730499] [ 3576] 107 3576 7293 493 19 3
148 0 ntpd
[737778.730546] [ 3585] 0 3585 61531 577 117 3
496 0 winbindd
[737778.730593] [ 3586] 0 3586 61531 578 118 3
512 0 winbindd
[737778.730640] [ 3651] 0 3651 48584 566 36 3
487 0 dsm_sa_eventmgr
[737778.730688] [ 3674] 0 3674 99593 576 47 3
1402 0 dsm_sa_snmpd
[737778.730736] [ 3717] 0 3717 7923 285 18 3
115 0 dsm_om_connsvcd
[737778.730784] [ 3718] 0 3718 740234 1744 202 7
30685 0 dsm_om_connsvcd
[737778.730832] [ 3736] 0 3736 178651 0 55 3
3789 0 dsm_sa_datamgrd
[737778.730880] [ 4056] 0 4056 26472 498 57 3
252 0 sshd
[737778.730926] [ 4060] 1000 4060 8973 501 23 3
184 0 systemd
[737778.730973] [ 4061] 1000 4061 15702 0 34 4
612 0 (sd-pam)
[737778.731020] [ 4063] 1000 4063 26472 158 54 3
260 0 sshd
[737778.731067] [ 4064] 1000 4064 6041 739 16 3
686 0 bash
[737778.731113] [ 4083] 1000 4083 16853 493 37 3
128 0 su
[737778.731160] [ 4084] 0 4084 5501 756 15 3
160 0 bash
[737778.731207] [15150] 0 15150 3309 678 10 3
57 0 run_mirror.sh
[737778.731256] [24296] 0 24296 1450 139 8 3
23 0 flock
[737778.731302] [24297] 0 24297 9576 622 22 3
3990 0 rsync
[737778.731349] [24298] 0 24298 7552 541 18 3
1073 0 rsync
[737778.731395] [24299] 0 24299 9522 401 22 3
2416 0 rsync
[737778.731445] [25910] 0 25910 10257 522 23 3
81 0 systemd-journal
[737778.731494] [25940] 0 25940 16365 617 37 3
126 0 cron
[737778.731540] Out of memory: Kill process 3718 (dsm_om_connsvcd)
score 1 or sacrifice child
[737778.731644] Killed process 3718 (dsm_om_connsvcd)
total-vm:2960936kB, anon-rss:0kB, file-rss:6976kB, shmem-rss:0kB
[737778.768375] oom_reaper: reaped process 3718 (dsm_om_connsvcd), now
anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
On Fri, Nov 4, 2016 at 5:00 PM, Vlastimil Babka <vbabka@suse.cz> wrote:
> On 11/04/2016 03:13 PM, E V wrote:
>> After the system panic'd yesterday I booted back into 4.8.4 and
>> restarted the rsync's. I'm away on vacation next week, so when I get
>> back I'll get rc4 or rc5 and try again. In the mean time here's data
>> from the system running 4.8.4 without problems for about a day. I'm
>> not familiar with xxd and didn't see a -e option, so used -E:
>> xxd -E -g8 -c8 /proc/kpagecount | cut -d" " -f2 | sort | uniq -c
>> 8258633 0000000000000000
>> 216440 0100000000000000
>
> The lack of -e means it's big endian, which is not a big issue. So here
> most of memory is free, some pages have just one pin, and only
> relatively few have more. The vmstats also doesn't show anything bad, so
> we'll have to wait if something appears within the week, or after you
> try 4.9 again. Thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.