I'm experiencing a similar issue on Thinkpad x220 running Linux Mint 18
(based on Ubuntu 16.04) with kernel 4.4.0-21. In my case, rfkill
unblock needs to be called twice in order to fully enable (and soft
unblock) bluetooth:
# rfkill block bluetooth
# rfkill list bluetooth
0:
After spending a couple hours trying to fix or work around this issue, I
eventually just decided that the only workaround for now is a downgrade.
So I installed jetty and libjetty-extra-java 6.1.26-ubuntu1, but then
bumped into a problem with the most recent version of libtomcat6-java
That fix was from three hours ago, and made it into mainline 3.6, I
believe. I've long since switched computers and haven't tested it
recently, but I would assume it has long since made it into Ubuntu's
releases.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
*** This bug is a duplicate of bug 816859 ***
https://bugs.launchpad.net/bugs/816859
Aha! I figured it out -- I'd worked around this in the previous release
but forgotten about it. It's a bad interaction between uswsusp and
plymouth. So this is basically a duplicate of #816859, which has an
I don't think this is a kernel bug per se -- I just tried reinstalling
the 3.5.0-27 kernel that was working from debs, and now resume from
hibernate is broken with that kernel as well. As a result, I've restored
my backups from quantal, since this functionality is important to me.
Could the might
I just tested with a variety of mainline kernels from kernel-ppa, and am
confused by what I found. I observed similar freezes while trying to
resume from hibernate using all of the following versions: 3.5.0, 3.5.7,
3.6.11, 3.7.10, 3.9.0. I don't understand why resume from hibernate
works fine with
This is happening for me on my Thinkpad R61 after upgrading to Ubuntu
13.04 (kernel 3.8.0-19), but it was working fine with the leftover
kernel from Ubuntu 12.10 (kernel 3.5.0-27).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Just to keep the record complete, the changes markusj suggested didn't
work on my R61. I'd imagine this is probably the case for others too.
For now, I've worked around it by using CompizConfig Settings Manager to
assign Super-F12 to a command that invokes hibernate, but this seems
like it ought
OK, here's a stack trace (with breakpoint on _XError)...
** Attachment added: backtrace at _XError for WINE-related
gtk-window-decorator crash
I'm seeing the same problem trying to get a backgrace. Even if I respond
'y' to gdb's prompt regarding gdk_x_error, I still get no break, just an
exit with code 01.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I've already uploaded a patch to the upstream bug tracker, but I just
thought I'd note here that the fix is to turn on USB_QUIRK_RESET_RESUME
for this webcam in drivers/usb/core/quirks.c. Any chance that such a
fix could be backported into the Ubuntu kernel as well?
--
You received this bug
One more comment (which is already in the upstream log): this webcam
actually appears to work fine even after a suspend/resume cycle in
2.6.38 and earlier, but fails after system suspend/resume or runtime USB
autosuspend/resume in 2.6.39-rc1 and later. So now I'm not sure where
the issue lies...
Well, I found something. After 13 kernel builds (not counting working
around broken commits several times) and countless reboots, I found
myself staring at this as the culprit:
commit e1620d591a75a10b15cf61dbf8243a0b7e6731a2
Author: Rafael J. Wysocki r...@sisk.pl
Date: Fri Mar 18 19:55:36 2011
I just found a way to turn off autosuspend for just the webcam (by
writing to the appropriate power/control attribute under
/sys/bus/usb/devices/*) but this seems like a kludge -- and having to do
it after each time I plug in the webcam is not too elegant either.
--
You received this bug
One more note: the same issue occurs, even with runtime USB power
management turned off, if I suspend my system with the webcam connect
and then resume. So it appears to be a problem not with runtime power
management per se, but with the way this particular webcam reacts to a
suspend/resume
** Bug watch added: Linux Kernel Bug Tracker #44191
http://bugzilla.kernel.org/show_bug.cgi?id=44191
** Changed in: linux
Importance: Undecided = Unknown
** Changed in: linux
Status: New = Unknown
** Changed in: linux
Remote watch: None = Linux Kernel Bug Tracker #44191
--
You
Christopher, I already downloaded v2.6.39-rc1 (mainline kernel build
from ubuntu ppa) and confirmed that the bug happens there. So I am left
to conclude that the bug was introduced between v2.6.38 (in which the
bug doesn't happen) and v2.6.39-rc1; so what would you now suggest? I'm
preparing to
Hi Christopher, where oh where have you gone? :-)
Since I couldn't build from Ubuntu-2.6.39-0.0 (which appears to actually
be 2.6.38 in some form), I did some more reading and started to make use
of git bisect skip. Three git bisect skips and three git bisect
goods later, git bisect just tells
I've now tried it on 2.6.39-0.5; for some reason, it takes many more
tries before it happens, but I can still coax this bug to show up in
this version. I haven't been able to reproduce it, however, in 2.6.38-8
(from Oneiric) or in 2.6.38-15 (from Natty).
So how do I proceed with bisection here?
OK, a brief update from the land of trying to build a kernel in Ubuntu
regression land for the first time: I built a kernel from the tag
Ubuntu-2.6.39-0.1, and confirmed that the regression still happens
there.
When I tried building from Ubuntu-2.6.39-0.0 (a logical step, no?), the
build
I'll try to do so sometime soon -- but I think it needs to be a kernel
bisect from Natty, based on comment #5 in bug 865131. There's an awfully
wide gap between 2.6.38 and 3.2.0; which kernel/git branch do I pull
down to start the process: the one from Natty or the one from Precise?
--
You
Hi Christopher, thanks for your help so far. I've determined that the
webcam worked with the Natty kernel but fails with the latest Oneiric
kernel. So I'm ready to start the bisection process, but I'm a little
unclear: the document on kernel bisection seems to assume that the
working and
Public bug reported:
The first time I plug in this webcam, it seems to work ok (e.g., in
guvcview). If I turn off the webcam and then turn it on again, all I see
is a noisy screen with lots of multicolored horizontal lines (see
attached; colors change in response to waving my hand in front of
** Attachment added: video captured in guvcview when webcam not working
properly
https://bugs.launchpad.net/bugs/1017072/+attachment/3202254/+files/SecondTime.avi
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I just tested with 3.5.0-030500rc3-generic #201206162135
3.5.0-030500rc3-generic #201206162135 SMP and can still reproduce the
issue.
** Tags removed: needs-upstream-testing
** Tags added: kernel-bug-exists-upstream
--
You received this bug notification because you are a member of Ubuntu
Bugs,
I see this problem after upgrading from Maverick straight to Precise.
The webcam works when first plugged in, but after turning off the webcam
and back on, I get all sorts of problems. Even when it works the first
time, the image is significantly underexposed (way too dark). Can this
bug be
@Sebastien: Ben may have been a little crass about it, but the fact is
that this is a regression since 12.04 was released. It worked in 12.04
out of the box, but then stopped working with the Unity 5.12 upgrade.
Surely you can't be serious in saying that we can only expect Ubuntu to
work if we
27 matches
Mail list logo
