FYI, I think the patch made it to 4.4 stable as well
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1573062
Title:
memory_stress_ng failing for Power architecture for 16.04
To manage notifications
Can we build the latest 4.8, may be we should wait for 4.8-rc7. I've got
all the fixes upstream, with the latest being
135e8c9250dd5c8c9aae5984fde6f230d0cbfeaf
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Can we please get answers to 1, 2 and 4 for comment #128. Also Kalpana
has a request for a new kernel build.
Thanks,
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1573062
Title:
memory_stress_ng
Thank you for the excellent summary. Questions
1. Can we get the configurations of the machines.
2. The first column is the number of times the test ran?
3. I see that 4.4.0-31-generic-50-Ubuntu passed on all machines across several
runs, is that true?
4. Did any of the tests result in system
I just posted another patch @ http://www.mail-archive.com/linux-
ker...@vger.kernel.org/msg1219903.html, I am testing this patch at the
moment.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1573062
Thanks Jeff. I see that the ARM64 might have failed -
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1610320
Can we know the git commit id that fixed the ARM64 failure in mainline?
BTW, could you please share the full machine configurations -
threads+RAM+swap for each of the other
Do we know what change fixed the issue? commit id?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1610320
Title:
stress-ng memory testing causes Arm64 system to hang
To manage notifications about
These logs are something I've not seen here in my testing. This shows
that we are stuck doing an up_write() on root->rwsem in the anon_vma
path. It looks like we are contending on the rwsem's sem->wait_lock. I
don't have a reproduction of this issue, it will be interesting to
examine what is
I am unable to reproduce the failure either, but your system with 32G
and 128 threads seems like the test would start 128 hogs each hogging up
32GB. How much swap do you have on them? Could you post the dmesg to see
what failed and the logs around it? It looks like the stack stressor
failed.
--
Can I quickly check if the oom_reaper patches are there in the built
kernel or is it just the fix I posted?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1573062
Title:
memory_stress_ng failing for
Had several other runs of success. I would like to see runs from others
as well.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1573062
Title:
memory_stress_ng failing for IBM Power
At my end, I ran two runs with success. More runs in progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1573062
Title:
memory_stress_ng failing for IBM Power S812LC(TN71-BP012) for 16.04
To
I just looked at the directory and I can find just the arm64 kernel.
Could you please confirm if I am looking at the right thing and at the
right place?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Sorry the 14.04 should be 16.04 in comment #61
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1573062
Title:
memory_stress_ng failing for IBM Power S812LC(TN71-BP012) for 16.04
To manage
I have 14.04 installed with 4.4.0-28 and I can see the following
In the bad case
1. OOM'ing of stress-ng-brk is slow, I can see it making progress -- see tasks
being scheduled/console output and sysrq output on Ctrl-o h
2. stress-ng-brk is trying to make progress in OOM, but is heavily
On Thu, May 3, 2012 at 11:59 PM, Christian Kujau
493...@bugs.launchpad.net wrote:
Whooha, language!
And I think they fixed it, albeit in a weird way:
CONFIG_TASK_DELAY_ACCT is enabled in the kernel config, but the feature
is still disabled unless the kernel is booted with delayacct as a boot
I took a quick look and found all rtnl paths waiting on mutex_lock. The
stuck tasks were gnome-panel, ureadahead and workqueues (modprobe,
waiting on a lock).. I also found wpa_supplicant waiting on
[ 240.393172] [c05739d5] schedule_timeout+0x185/0x200
[ 240.393181] [c012e7a0] ?
Can someone help characterize the performance hit with perf data or
oprofile data using a standard benchmark? When we developed the feature
we ran a large set of benchmarks to ensure there is no visible
performance hit. If there is a hit or a side-effect, I would be
interested in fixing it
Hi, Jon, Others
Could someone confirm the license change. I like the split of the
packages, we would like the work to LGPL'ed, dpkg --license shows GPL.
Am I missing something?
Balbir Singh.
--
[needs-packaging] libcgroup
https://bugs.launchpad.net/bugs/268714
You received this bug
Hi, Jon,
We need to change the licensing of parse.[ch] to LGPL (the copyright
says that we can distribute the generated files under a different
license if it is a part of a larger program) and we prefer LGPL. Could
you please change the copyright to reflect that. In the case of
pam_cgroup, I need
Thanks, Jon,
I saw some review comments there, In the beginning I had mentioned the
license as LGPL, I wonder why it is being interpreted as GPL or am I
missing something?
--
[needs-packaging] libcgroup
https://bugs.launchpad.net/bugs/268714
You received this bug notification because you are a
Hi, Jon,
Could you post your changes to libcg mailing list. libcg-
de...@lists.sourceforge.net. We'll review and make the changes needed
and also put a longer term TODO to fix RPATH correctly
Thanks,
--
[needs-packaging] libcgroup
https://bugs.launchpad.net/bugs/268714
You received this bug
Hi, Jon
Thanks for all your effort with the entire packaging, I've been starved
for bandwidth due to various reasons. I'll take a TODO to fix the rpath
issue in the library and work on it. Thanks again!
--
[needs-packaging] libcgroup
https://bugs.launchpad.net/bugs/268714
You received this bug
Thanks, I'll take a look. I was in the process of figuring out how to
remove rpath, chrpath looks like a good solution, but I wanted to change
automake and libtool to do the right thing.
--
[needs-packaging] libcgroup
https://bugs.launchpad.net/bugs/268714
You received this bug notification
Sorry for holding you up Jon, I was in the process of getting debian up
and running so that I could try the same build scripts on my machine,
but alas migration is very hard. I am trying to setup a virtual machine
for it. Thanks for the offer to write lsb compliant scripts, I think
that would
Yes, you are right we need to change that to /etc/default on
debian/ubuntu, we could change the script for debian. What that means
for us upstream is the need to have distro specific changes to the
scripts. I'll see how to best handle that.
I'd be happy to help resolve any issues. We'll remove
OK, I am uploading what I have for debian packaging as a tarball (done
as a part of libcgroup FOSS.IN workout). The man pages are missing and
this was done for old code, please review/update. I'll help out, feel
free to use this forum or any other to help drive this to completion.
Thanks,
Balbir
I was hoping to get this packaged in Jaunty, but we could not. I have
some initial work done for packaging for Ubuntu, should I find the right
forum and post it. I'll probably need help and guidance.
Balbir
--
[needs-packaging] libcgroup
https://bugs.launchpad.net/bugs/268714
You received this
I know it is sort of late for Intrepid, but it would be a nice feature
to have given that we've enabled cgroups and a bunch of other
controllers. One way would be to add it to Jaunty and backport it? I
don't know if that is acceptable. I would really like to make libcgroup
available to Ubuntu
I am not sure which individual(s) to subscribe to this report. I tried
asking on the #ubuntu-kernel. I'll try again.
--
[needs-packaging] libcgroup
https://bugs.launchpad.net/bugs/268714
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Public bug reported:
URL: libcg.sourceforge.net
Provides a user space library, initscripts and commands to exploit the
new resource management features in the kernel. Hardy and Intrepid
enable the CPU controller, it would be nice to provide the user space
tooling for exploitation of these
Public bug reported:
Binary package hint: update-manager
I tried upgrading from Feisty to Gutsy and at the end the upgrade failed
without a suitable reason.
ProblemType: Package
Date: Sat Nov 17 10:48:41 2007
ErrorMessage: ErrorMessage: SystemError in cache.commit(): E:I wasn't able to
locate
Looks like it might be a problem with the software channels. Re-
installing to update since upgrade does not work
** Changed in: update-manager (Ubuntu)
Status: New = Invalid
--
[apport] package update-manager failed to install/upgrade: ErrorMessage:
SystemError in cache.commit(): E:I
33 matches
Mail list logo
