(Actually, I'm frustrated enough I'm just going to say it explicitly,
rather than indirectly: it looks like you didn't read my comment, as
even the thrust of your response--that "it's not just about installing
different versions of linux-tools"--isn't something I even hinted at as
the reason; the
I not only understood that but explicitly stated as such; not just the
reasoning, but also the policy... however, that only applies to dynamic
linking: other packages--as I also explicitly demonstrated--link against
libbfd statically for this very reason; are you saying that there has
been a
I am leaving a comment to the effect that my issue is not something for
which logs are relevant.
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Public bug reported:
The perf tool has an optional dependency on libbfd. Per Debian policy,
and due to some situation involving parallel installations of this
library, no packages should link dynamically against libbfd. In the
past, bugs have been filed to link perf statically against libbfd in
Public bug reported:
Using code from the documentation for libbenchmark-timer-perl causes an
error finding Statistics::PointEstimation (which I do not believe has
even been packaged for Ubuntu).
# perl -e 'use Benchmark::Timer; my $t = Benchmark::Timer-new(skip = 1,
confidence = 97.5, error =
Public bug reported:
When an error occurs from mod_python on Saucy (which uses Apache 2.4)
there is nothing logged. I have tracked this issue down to the value of
APLOG_NOERRNO being incorrect. This value is defined to be
(APLOG_LEVELMASK + 1); on Apache 2.2, APLOG_LEVELMASK was 7, but on
Apache
Public bug reported:
When an error occurs from mod_python on Saucy (which uses Apache 2.4)
there is nothing logged. I have tracked this issue down to the value of
APLOG_NOERRNO being incorrect. This value is defined to be
(APLOG_LEVELMASK + 1); on Apache 2.2, APLOG_LEVELMASK was 7, but on
Apache
Other people experiencing this issue may want to explicitly note the
comment on this bug from Stefan (which is now somewhat buried) regarding
the potential Xen IRQ misconfiguration in these kernels, and attempt
that fix. Unfortunately, my test case is run my business on this system
for a day and
In case this is saves anyone's time: the top of those stack traces is
garbage. Really, all of those processes are simply blocked in the
scheduler: the second from the top entry in all the call stacks is a
call to schedule() (which I presume is scrambling the registers enough
to confuse the stack
Yes: I'm just telling you that the ? entries at the top of these stacks
are all in the scheduler. jbd2 and run-parts are blocked in
io_schedule(), and pgbouncer is blocked in do_get_write_access(). Both
of those functions are calling into schedule(), and that's what is
actually at the top of the
@scott: I have attached a dmesg dump from a system that had failed.
** Attachment added: dmesg log from a system that had gotten hung up
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/666211/+attachment/1728897/+files/hung.dmesg
--
maverick on ec2 64bit ext4 deadlock
Stefan,
I'm not certain what you mean by something not used in the common
images. To be clear, I do not even know how to make my own images.
That's not to say I'm not certain I couldn't figure it out very quickly,
but I never have as I personally do not think that is a good way of
using EC2: I
Stefan,
To be clear, both Timo and I were using m1.xlarge instances, which are
supposed to have four cores. (You mentioned the hardware you were
testing on only had two cores, and therefore you weren't getting the
same seemingly-bad and probably-should-be-fixed error messages.)
Also, that log
Stefan,
These stack traces for pgbouncer are all in sys_write(), btw, which is
then backed by ext4. Both from what I know about how pgbouncer operates,
and from greping through its source code, the only file-backed operation
it performs is writing to its log file, which it normally does only once
We are also getting the following error message from the kernel:
JBD: barrier-based sync failed on sda1-8 - disabling barriers
My theory was that this has to do with the root partition being used as
ext4. I do not know much about bundling of AMIs: is this something that
is easy for you to
Somehow I thought I said this in the last comment, but I see that I
didn't: using the instance's normal root partition, not an EBS root
boot.
--
maverick on ec2 64bit ext4 deadlock
https://bugs.launchpad.net/bugs/666211
You received this bug notification because you are a member of Ubuntu
Bugs,
16 matches
Mail list logo
