A bit more detail to reproduce this that I think was missed out before:
It happens when the configured desktop mode/scaling is set to a
fractional value. You can have that experimental xrandr setting set, but
be configured to scaling of 100% or 200% (but see below on latter) and
you won't see this
My bug got marked a duplicate of this one but with the latest change
that might be wrong: It affected me on a machine with AMD graphics, not
nVidia. BTW I recently tried it again on the offchance it had been fixed
since (by re-enabling the xrandr scaling setting), and it had not. Also
not fixed on
NB: Post-upgrade upgraded to nvidia-driver-418 from restricted (didn't
re-enable graphics-drivers ppa) and all so far seems well.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to nvidia-graphics-drivers-390 in Ubuntu.
https://bugs.launchpad
Public bug reported:
Just happened trying to upgrade a machine in two immediate steps
bionic->cosmic->disco.
ProblemType: Package
DistroRelease: Ubuntu 19.04
Package: nvidia-dkms-390 390.116-0ubuntu1
ProcVersionSignature: Ubuntu 4.18.0-20.21-generic 4.18.20
Uname: Linux 4.18.0-20-generic x86_64
N
I hid my earlier posts because I reckoned they were noise, tbh. This one
less so. :-)
I have replaced the firmware files with those from the windows driver as
described above and in the linked-to askubuntu. It worked brilliantly
for a few days, no problems at all, but just now failed: Similar to w
typically it waited for me to report that it worked before failing.
Proving a negative blah indeed.
This time my wifi adapter also didn't come back. I suspect this isn't
entirely unrelated as aren't they actually the same physical device? In
fact that almost makes it weird that usually *only* blue
Catching up as I came at this from another direction. Having got a
Windows-installed XPS 13 9370 and installed 18.04 freshly on it itself,
its default suspend mode is s2idle, which means lots of battery life
gets lost while suspended. But no bluetooth problems. See askubuntu:
https://askubuntu.com/
My problem definitely was rEFInd; and i resolved it by using the new
--ownhfs install option as discussed on their discussion forum. However
I don't have hibernate working at all on the linux side, so it may be
that for you too.
--
You received this bug notification because you are a member of Ke
On further googling the problem may lie with rEFInd. It looks like the
problem discussed here: http://askubuntu.com/questions/295105/refind-
breaks-standby-mode-on-macbook-air-5-2
Am currently running without rEFInd (though it does mean having to
select "Windows" to boot Linux, which isn't pretty!
odd coda to add here: Today I've been back using the Mac side of this
computer. So far two out of two times, I've seen the same problem
resuming from suspend in Mac OS X; requiring the same power cycle to
continue.
I don't know what to make of this. It never did this before I made this
machine dua
3.13.0-22 boots fine with stubloader. So the main interest in wanting to
understand why 3.13.0.21 didn't, is to stop it happening again,
otherwise it's history...
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bug
I just installed rEFInd on a UEFI PC also running Ubuntu Trusty. (built
around Asus Z87I-PRO mobo).
rEFInd had no trouble booting the same kernel (3.13.0-21) that I
reported this problem for on the Mac. Entirely default configuration.
(The Mac's rEFInd has an almost entirely default configuration
Tested both. *Both* of them boot fine.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1301524
Title:
Missing EFI Stub Loader support in 3.13.0-21?
Status in “linux” package in Ubuntu:
Public bug reported:
I think that might be the problem: Installed on a Mac (Macbook Air 4,1)
using rEFInd boot manager, 3.13.0-19 and 3.13.0-20 as well as 3.14
(mainline, installed to test something else) all happily booted directly
using the stubloader. But 3.13.0-21 just hangs instantly on load.
OK, it happened on 3.14. Confirmed that, as with the first time, the
pattern was close lid (observe backlight goes off, then momentarily
flashes on again) *then* plug in power; the next morning, unplug power,
open lid. *Keyboard* backlight is on, screen does not wake.
** Tags added: kernel-bug-exi
3.14 installed. in case it means something, i *did* manage, twice, to
get the timing right to cause that backlight flash that, before,
signalled^Wcoincided with the crash, but both times the machine resumed
normally afterwards.
But hesitant to mark it fixed upstream as I couldn't reproduce the err
Would like to mark as dupe of #1299790 (also raised by me - this bug is
just from me trying to repeat it) but that appears not to be in my gift.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bu
After a number of attempts I only managed to repeat it once, and that
was with plugging in mains immediately after (practically
simultaneously) closing the lid; so possibly while suspend mode is being
entered. The time it happened, the backlight had gone off, then it came
on again briefly, then off
Public bug reported:
got it to happen again once (ref: #1299790)
ProblemType: KernelOops
DistroRelease: Ubuntu 14.04
Package: linux-image-3.13.0-20-generic 3.13.0-20.42
ProcVersionSignature: Ubuntu 3.13.0-20.42-generic 3.13.7
Uname: Linux 3.13.0-20-generic x86_64
NonfreeKernelModules: wl
Annotati
No objection in principle to trying. Our main problem here is that the
bug may not even be reliably repeatable with the current kernel
*anyway*, though before doing that upgrade I'll give it a go (having
been avoiding the sequence of events that I *think* triggered it the one
time it did happen).
Public bug reported:
I had shut the lid to suspend the system last night. *After that* I
plugged in the mains lead.
Today I unplugged the mains lead and *then* opened the lid, and tried to
wake it, only to find it wouldn't do so. Had to force-reboot it. On
logging into desktop, this bug report go
FYI this also seems to have fixed a problem I was having with a USB
DVB-S2 receiver, which apparently caused the drivers to hang on load
*only* on xHCI; on EHCI, same kernel, all was fine. So this may not have
been purely a mass storage device issue.
--
You received this bug notification because
22 matches
Mail list logo
