I have never been comfortable using apport
because I've never found a way to be 100%
sure I can see exactly what it submits before
it sends it, so it's a privacy problem. If a developer
actually wants to work on this and has difficulties
reproducing it, I would be happy to share configuration
This is problematic because it lays a trap. Just because the special package
sets up mailbox_command to do this doesn't mean the bug won't screw someone
who thinks that deliver will obey inclusions. It's -especially- bad if someone
tries
to use virtual domains and hence removes that
This is problematic because it lays a trap. Just because the special package
sets up mailbox_command to do this doesn't mean the bug won't screw someone
who thinks that deliver will obey inclusions. It's -especially- bad if someone
tries
to use virtual domains and hence removes that
...and I'd like to point out that I've done a ton of NFS (v3 only, since
I'm talking to hosts running Hoary---yes, really) with the Intel NIC and
had no problems whatsoever. To everyone who is blaming NFS here, TRY
NETCAT. And DO NOT try scp or ssh because they're doing crypto which
will slow
Public bug reported:
Binary package hint: live-installer
Using the daily build of 4/8 (AMD64 desktop) and trying to install to a
disk that was NOT /dev/sda, I discovered that the manual partitioner
kept RESETTING the device on which to install the bootloader to /dev/sda
every single time I added
I just installed Natty and brought it up-to-date as of about 4/8; this
is using kernel 2.6.38-8-generic.
Two identical 2TB 4K-sector disks show about a 2x slowdown in LUKS using
XTS and 512-bit keys: doing time find usr -ls | wc -l reported about
37 seconds on the ext4 disk, and 1m4s on the
To follow up: using the Intel PCIe NIC instantly solved all my
problems. No more lockups under combined network and PCI load. I won't
be going back to Realtek NICs ever. (If someone can point to a specific
purported bugfix that's in some kernel I can simply download and install
without
To follow up: Trying 2.6.38-8 (installed the beta and let it update to
whatever was current as of 4/9) fixed the problem. kswapd0 no longer
hogs CPU, and unlike the OP's report of 4/5, I don't see kworker chewing
up time and I see no freezes or other issues. For me, it Just Works.
Note that my
It's not just AMD64, or this is two different bugs---I think it's
actually 10.10 in both AMD64 and i386.
I just installed 10.10 on a WD 500GB IDE disk inside a -non- encrypted
LVM using the alternate installer last week. I spent some time last
night benchmarking I/O using (a) a 2TB SATA
It's not just USB access---it's anything that hits a filesystem hard.
I can confirm that 2.6.38-7-generic on AMD64 freaks out exactly the same way:
kswapd0 goes
to 100% if driven by 'nc -l 1234 | tar xvfp -' to ext4 (no crypto, no LVM, no
RAID, just an ordinary
partition) on an ordinary SATA
Oh yuck, sorry for the horrible formatting of the previous;
I usually yank in text from Emacs, but this time I typed it
directly into the box. Apparently it's hard-wrapped at 80
columns, but the box is about double that width. Yet another
bug in Launchpad, but I've learned that reporting those
** Description changed:
TL;DR: Disk I/O with LUKS is extremely slow on amd64 builds, however, it
is much faster on i386 builds. This has been verified by testing on
multiple hardware platforms and with multiple versions of Ubuntu. The
possible cause of the slowness has been shown to
I just happened to trip over this report, and at least
one of the lcpci entries shows a Realtek NIC, which
makes me suspicious in light of the report I just
filed at bug #746914. You might want to take a
look at that in case it seems relevant and/or try
the nc | tar pipelines I was using (I
Public bug reported:
I'm submitting this bug report to encourage driver developers to try
this particular use case because a network-only test would not uncover
the bug. I know (now, alas :) that the Realtek NIC is the subject of
many prior bug reports, but someone who thinks those are fixed in
I'm the original reporter of this bug thread.
I have to say, I'm completely dissatisfied so far. Every proposal has
been to effectively kick this downrange and make it someone else's
problem, and I'm -particularly- unhappy that this is viewed as a
window manager issue! It means the (a) behavior
Aha! In that case, I agree with everything you've said. :)
(Yes, I agree that it's pointlessly incompatible, but I thought someone
must have had a good reason for it---e.g., I'd simply assumed there was
-some- point that I was missing, and that Ubuntu had gone along. I also
agree that -having-
Wait, what? Are you saying that nc -should- accept -p with -l? In
other words, that nc -l -p 1234 is the same thing as nc -l 1234 in
OpenBSD nc? If so, I very much agree with that sentiment!
But that wasn't what the manpage seemed to indicate -at all-. It goes
out of its way, in several
I'll try one more time to make the point I'm trying to make, and then
I'll give up until someone who seems to understand it chimes in. (And
by the way, calling a usability complaint flamebait isn't exactly
setting the right tone yourself.)
100% of my usage of nc is in building tunnels. 50% of
Public bug reported:
Binary package hint: netcat-openbsd
In a recent Lucid installation, I just got screwed by the substitution
of the netcat that's been around for decades with the so-called better
OpenBSD version. There are a LOT of problems here:
(a) The version you're shipping does not
I believe I was quite clear:
(a) nc -l -p 1234 spits out a usage message. The traditional version
actually listens on port 1234. Having finally found nc's manpage, I see that
the OpenBSD version uses completely incompatible arguments, hence breaking
scripts that expect the decades-old
Public bug reported:
In Ubuntu server 10.04 LTS, I typed passwd to change my password and
accidentally typed the new password in response to the prompt for the
current password. Instead of saying incorrect password or something
equally reasonable, which would have caused me to smack my forehead
I'm dubious that the testing you want me to do is either useful or
feasible:
(a) The current ISO image is only 2 days later than when I filed this bug
report, and the machine was absolutely up-to-date on available package via
update-manager at that time. Does the current CD image really
I just noticed, in case it isn't completely obvious to anyone reading
this report, that I misreported the machine model. it's a Dell Inspiron
1150, not a Dell Inspiration. *sigh*
--
Kernel 2.6.32-21-generic freezes Dell Inspiration 1150 on boot; 2.6.32-20 is
fine
Public bug reported:
On a Dell Inspiration 1150 running Lucid, I took the update of 4/16/10
and discovered that the machine froze reproduceably on boot with kernel
2.6.32-21. Only dropping back to the kernel just before the update
(kernel 2.6.32-20) enabled the machine to boot. The machine is
Public bug reported:
Binary package hint: usb-creator
usb-creator needs some serious QA. Here's a laundry list of bugs that
have made it almost unusable for me. (I was running it under an up-to-
date Karmic amd64 on a desktop, trying to create an i386 image for a
ThinkPad whose CDROM drive is
Yes, I agree re part 3---safer to leave it in as long as metacity claims
responsibility. (But it has no business claiming responsibility---leave
that to PulseAudio.)
We haven't heard yet about getting this bug punted to the metacity
folks, so it may be time take more direct action in letting
Confirmed---your patch fixes the issue. Now I can migrate to Karmic
without going mad. (I'll make a post showing all the extant bugs what
fixes them, since this is but one part of all the bell lossage we've
discovered, but this is certainly the most-annoying one and the one that
got us
Oh btw, someone else will to have to verify if the patch is well-formed;
I applied it by hand, since I was poking around to verify each piece.
--
System beep broken in Karmic despite heroic efforts to fix it
https://bugs.launchpad.net/bugs/486154
You received this bug notification because you
Okay, for anyone who's trying to restore the pre-Karmic behavior of
beeping, here's what to do. It will give you old-style motherboard
beeps when you hit rubout at an empty shell prompt in gnome-terminal or
at an empty password prompt during gdm login; it will make xkbbell work;
all rate-limiting
I can't quite reproduce your it-must-be-metacity results, because when
-I- try compiz, I just lose X bells completely. BUT---metacity is
-definitely- doing something wacky. Read on.
Starting from metacity, xkbbell (and rubout at an empty shell prompt)
work in the same not-really-working manner
Oy.
I know this is probably going to be an unpopular discovery, but I am no
longer sure this is necessarily a metacity bug. The problem is, then,
whose bug -is- it?
I just spent a couple hours hacking around in the metacity source code
doing things like commenting out XkbSelectEvents and
I just got hit with exactly the same bug. Fresh install from the Karmic
9.10 amd64 LiveCD and up-to-date as of today. Various other packages
installed over the last few days. Just noticed that typing myth into
Quick Search shows only a few hits, but adding a b to the end of the
string doubles
I'm beginning to wonder if this might be a gtk issue. Or gdm. Or gdk.
Does anyone know how to tell which application might have called
XkbSelectEvents or XkbChangeEnabledControls? Can I ask X somehow?
For the moment, I'm reduced to, e.g., doing apt-get --dry-run build-dep
gdm, noting which
Aha! You've done -exactly- the debugging I was thinking of asking you
to do... :) [More, even, since I didn't realize you could easily try
out 9.04; I don't have any 9.04 systems and didn't really want to
install one just for testing, though i guess I could. I'd assumed this
was broken before
Yes, I had the same behavior with killall metacity (which I was using because
I was recompiling it with various things commented out). I'll run some compiz
tests and make sure I can reproduce your results. I think there -is- some
negotiation going on, and I'm not sure what happens if a
I've rerun all my tests. I've attached a table and legends for it, since no
doubt it would
otherwise be smashed by the automatic reformatting done by launchpad (is there
any way to
turn that off?).
Note that EVERYTHING works fine in Hoary, Dapper, and Breezy. I did not test
9.04.
But 9.10
Robert: Re the rmmod/modprobe fandango I'm doing: I've done a bunch of
testing (my next post will detail it), but I'm pretty sure what's going
on with rmmod/modprobe is simply a kernel regression---if pcspkr is
loaded too early, it doesn't work correctly. So if it's blacklisted,
and then loaded
Robert: Thanks for the summary. I'm going to prepare a little table
for the studio audience to try to make things clearer, especially since
you correctly pointed out in comment #27 that there's ambiguity over
whether I'm talking about bell.ogg or the squarewave beep coming out of
line-out
Daniel: If this bug is truly independent of PulseAudio, then why does
renaming /usr/share/sounds/ubuntu/stereo/bell.ogg change the behavior?
If your argument is that libcanberra is looking at that file, then why
is it necessary to remove a -PA- cache file to fix the bell after
renaming the file
The OP just directed my attention to this bug, which -might- be a
duplicate of bug #486154; interested parties might want to take a look
at it. (Robert Schroll and I have spent the last three weeks
characterizing the multiple problems with the Karmic system bell in that
report; I think there are
Thanks! I just put a pointer in your bug back to here, so hopefully
people will see both and figure out if we're talking about the same
thing.
--
System beep broken in Karmic despite heroic efforts to fix it
https://bugs.launchpad.net/bugs/486154
You received this bug notification because you
[IG: I don't understand your comments re the bell working in metacity
-instead of- compiz. If that's true, you're talking about something
different than we are. You should also strive to be more precise in
your description. For example, when you say system bell, I'm not sure
if you're talking
Robert: I think actually we had exactly the same problem, and your
workaround works for me. I'll explain, 'cause it'll help in debugging
this for real.
First off, I've now gotten to a state where my system bell is coming out
of line-out. It wasn't before. I'm reasonably sure that this was
I now think that Gnome, Metacity, or Pulseaudio are implicated. The
hardware and X itself are probably not. Details:
I think I've managed to pry this bug quite a bit farther open, but it's
not quite there yet. In particular, I -can- get the system bell to work
under bare X as any user. And I
Robert: It looks like the reason module-x11-bell isn't loaded by
default is because it's commented out in /etc/pulse/default.pa (along
with the load-sample mentioning it near the top of that file).
Presumably, uncommenting and restarting pulse (or just rebooting) would
load it. But of course,
[If you're happy with the data I attached, can someone please mark this
as something other than Incomplete so it won't vanish? Thanks.]
I now think that this bug might not implicate X, or it might be a bad
interaction where X's bell event is being mishandled by
gnome/metacity/pulseaudio. Please
Oh, right, so some quick research indicates the .tdb files in ~/.pulse
are Trivial Database Files. Installing the tdbtools package (bug
#557819 already complains about their total lack of documentation) lets
you run tdbtool on 'em and use commands like keys and dump, although
the values of the
Sure thing. I'm attaching two slightly-different X logs (I don't know
why the older one is talking about evdev but the newer one isn't).
They're both from the amd64 LiveCD. I'd purged PulseAudio at some point
and had been restarting X after various changes to see if anything
happened; I don't
** Attachment added: Xorg.0.log
http://launchpadlibrarian.net/36234483/Xorg.0.log
--
System bell broken under X in Karmic
https://bugs.launchpad.net/bugs/489855
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing
** Attachment added: Xorg.0.log.old
http://launchpadlibrarian.net/36234423/Xorg.0.log.old
--
System bell broken under X in Karmic
https://bugs.launchpad.net/bugs/489855
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
** Attachment added: lspci
http://launchpadlibrarian.net/36234514/lspci
--
System bell broken under X in Karmic
https://bugs.launchpad.net/bugs/489855
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Just for yucks, here's the Xorg.log from the same LiveCD, freshly
booted. (System bell doesn't work there, either, of course.)
** Attachment added: Xorg.0.log.virgin
http://launchpadlibrarian.net/36243854/Xorg.0.log.virgin
--
System bell broken under X in Karmic
Public bug reported:
Binary package hint: xorg
As far as I can determine, the system bell (e.g., built-in motherboard
beeper) is completely broken in Karmic under X. Non-X beeping does work
after extensive workarounds; please see bug #486154 for my hardware
software versions, what I did to
Still no joy.
I just tried booting the Karmic LiveCD---hence running in 32-bit mode.
I repeated all of the steps listed above, and the behavior is unchanged.
The beep program continues to work (assuming, of course, that you've
modprobed pcspkr, which is the first thing I did while reproducing all
Ah, and my comment above about reboot---I just tried shutdown -r 3
from the LiveCD, and -that- beeped the speaker! echo foo | wall also
beeps.
I rebooted the normal 64-bit system and noticed that echo foo | wall
didn't beep the system bell. (Although I was also ssh'ed in from
elsewhere and
Btw, these tests under X that I'm doing---I'm doing them typing directly
on the machine's actual keyboard and using its actual display. Don't
get confused by my comments about ssh'ing in from elsewhere---I'm making
sure to run the tests directly on the machine's actual I/O hardware so I
can't get
Btw, I just verified that the missing system bell is -not- coming out of
either the line-out or the center-out jacks on my motherboard; I hooked
up speakers and verified that both jacks give output when I play a
random audio file through mplayer, but the missing system bell isn't
there.
Oddly
Yes, I'd seen bug #77010 very early on when trying to debug this, and I also
tried the workaround in bug #398161 (which is to rmmod and then modprobe the
module again), and the workaround does not work for me. (I can easily
see that rmmod made the module vanish and that modprobe puts it back,
Public bug reported:
In a fully up-to-date AMD64 Karmic on an MSI MS-7511 aka a K9N2G Neo-FD
motherboard
(2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64
GNU/Linux):
I -know- my hardware works, but I cannot get the motherboard-based
system beep to work at all. I also know
59 matches
Mail list logo
