[Bug 1953076] [NEW] Ubuntu 20.04 - NVIDIA GPU consuming power even when using only integrated graphics card (Intel iGPU)
Public bug reported: The issue is pretty simple: using Nvidia X Sever Settings GUI to switch from NVIDIA GPU to Intel iGPU doesn't work and the NVIDIA GPU does still consume some power after rebooting and, as a consequence, it generates uneccesary heat. Same thing (obviously) happens if I use prime-select from the terminal. I can see from powertop that when I have everything on idle, I am still consuming around 18-22W which is at least 10W more than I would expect. This seems to be a rather old bug and supposedly it got "fixed". I can find at least two launchpad bug reports (https://bugs.launchpad.net/ubuntu/+source/nvidia-prime/+bug/1765363) and there are some workaround there. Problem is that at this point I am not even sure what works and what doesn't since most posts are over 3 years old. I tried for example installing ubuntu without selecting "install third party drivers" since someone suggested it would fix the problem but it didn't work in my case. Someone else here recently posted about this issue again -> https://discourse.ubuntu.com/t/nvidia-prime-not-powering-off-the-dgpu/21856 I used to have another Optimus laptop years ago and I remember it worked fine in older Ubuntu versions but now something seems wrong. Config: - Zephyrus M16, 11800H, 3070 - Ubuntu 20.04 (but same problem with 21.10) - Nvidia Driver 470 and 460 tested. ** Affects: nvidia-prime (Ubuntu) Importance: Undecided Status: New ** Tags: gpu nvidia prime -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1953076 Title: Ubuntu 20.04 - NVIDIA GPU consuming power even when using only integrated graphics card (Intel iGPU) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvidia-prime/+bug/1953076/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1765363] Re: prime-select intel is not powering off the nvidia card
This is still happening even on Ubuntu 20.04. I even tried installing without "Additional Drivers" checked and the problem is still there. I tried some workarounds posted here but they don't work or they might be out of date. Any update on this? Zephyrus M16 - 11800H - 3070 - Nvidia Driver 470 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1765363 Title: prime-select intel is not powering off the nvidia card To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvidia-prime/+bug/1765363/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1306657] Re: libmms vulnerability
There is no CVE number. I am one of the libmms maintainers and was privately notified of this vulnerability. I can provide the details, if needed. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1306657 Title: libmms vulnerability To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libmms/+bug/1306657/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1241101] Re: Java crash in libglib-2.0 after upgrade from 13.04 to 13.10
I've also tested this using Juno (the version included in Zend Studio 10) and unfortunately share auspex's experience, it doesn't solve the issue for me. I also tried explicitly launching the application with an affinity: taskset 0x0001 zend-studio with the same reslult. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1241101 Title: Java crash in libglib-2.0 after upgrade from 13.04 to 13.10 To manage notifications about this bug go to: https://bugs.launchpad.net/eclipse/+bug/1241101/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1241101] Re: Java crash in libglib-2.0 after upgrade from 13.04 to 13.10
It's probably worth mentioning that with the latest Eclipse (Kepler) this bug does not occur. Perhaps looking at the differences between what happens on close in the find dialog in Kepler and Juno will shed some light on what is causing the crash. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1241101 Title: Java crash in libglib-2.0 after upgrade from 13.04 to 13.10 To manage notifications about this bug go to: https://bugs.launchpad.net/eclipse/+bug/1241101/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1241101] Re: Java crash in libglib-2.0 after upgrade from 13.04 to 13.10
Unfortunately running Eclipse via sudo does not fix the issue for me and I get the exact same crash: Stack: [0x7f252c76,0x7f252c861000], sp=0x7f252c85d040, free space=1012k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libgobject-2.0.so.0+0x19a48] g_object_get_qdata+0x18 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1241101 Title: Java crash in libglib-2.0 after upgrade from 13.04 to 13.10 To manage notifications about this bug go to: https://bugs.launchpad.net/eclipse/+bug/1241101/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1241101] Re: Java crash in libglib-2.0 after upgrade from 13.04 to 13.10
This may also be relevant: It doesn't seem to be an Ubuntu/Debian based distro specific bug. I also have an Arch Linux installation and it happens on that 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/1241101 Title: Java crash in libglib-2.0 after upgrade from 13.04 to 13.10 To manage notifications about this bug go to: https://bugs.launchpad.net/eclipse/+bug/1241101/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1241101] Re: Java crash in libglib-2.0 after upgrade from 13.04 to 13.10
I'm not sure this is helpful or not but: I don't have Unity installed. I'm running Linux Mint which is built from Ubuntu and I'm running KDE. Whether that rules out a unity bug or not I don't know. Setting UBUNTU_MENUPROXY has no effect at all. Using GTK2_RC_FILES=/usr/share/themes/Raleigh/gtk-2.0/gtkrc works, but it's the same workaround as previously because it just disables the oxygen-gtk theme. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1241101 Title: Java crash in libglib-2.0 after upgrade from 13.04 to 13.10 To manage notifications about this bug go to: https://bugs.launchpad.net/eclipse/+bug/1241101/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1241101] Re: Java crash in libglib-2.0 after upgrade from 13.04 to 13.10
Has anyone managed to track the package which is the source of this bug? Here's my understanding so far: It's not an Eclipse bug as the same version of Eclipse running on Ubuntu 13.04 does not suffer the problem It doesn't appear to stem directly from oxygen-gtk as the QtCurve theme suffers from the same problem which hints that it's something in a library that QtCurve and oxygen-gtk both rely on that other themes do not. It's unlikely to be a Java bug as it affects both OpenJDK and Oracle's JDK. A similar problem from 2010 is mentioned here: https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/598371 It's very similar, but this was certainly fixed somehow since then because 13.04 was unaffected. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1241101 Title: Java crash in libglib-2.0 after upgrade from 13.04 to 13.10 To manage notifications about this bug go to: https://bugs.launchpad.net/java-common/+bug/1241101/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1241101] Re: Java crash in libglib-2.0 after upgrade from 13.04 to 13.10
That's a different bug. I can confirm that does fix several issues with oxygen-gtk but not the g_object_get_qdata crash. See https://bugs.kde.org/show_bug.cgi?id=329814 for the g_object_get_qdata crash. ** Bug watch added: KDE Bug Tracking System #329814 https://bugs.kde.org/show_bug.cgi?id=329814 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1241101 Title: Java crash in libglib-2.0 after upgrade from 13.04 to 13.10 To manage notifications about this bug go to: https://bugs.launchpad.net/java-common/+bug/1241101/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 343490] [NEW] The partition utility in the setup program reports a bogus disk percentage used.
Public bug reported: In Ubuntu 9.04 (Jaunty Jackalope) Alpha 6, the disk partitioner reports a bogus percentage disk space used. It is probably a really easy bug to fix, if someone can give me a rough idea of where to find the source code. I think the disk utility is reporting the disk size as a percentage. It should either report a percentage, or the disk size, but never the disk size converted to percent. The problem is that the percentage calculation probably breaks down when only one partition is present, or in some related special circumstance. ** Affects: ubuntu Importance: Undecided Status: New -- The partition utility in the setup program reports a bogus disk percentage used. https://bugs.launchpad.net/bugs/343490 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 317781] Re: Ext4 data loss
@Volodymyr I finished recompiling the kernel with Theodore Ts'o patches, and reran Volodymyr's test cases with the patched kernel. The results are: File System Method Performance (Typical, Minimum, Maximum) #Lost %Lost ext4patch 1 0.440.410.501 1.00% ext4patch 2 0.320.320.400 0.00% ext4patch 3 0.200.180.200 0.00% ext4patch 4 0.250.250.250 0.00% ext4patch 5 0.260.260.330 0.00% ext4patch 6 0.410.330.420 0.00% Essentially, the patches work. Ext4, with the patch, has the same data loss as the ext3 file system. Adding fsync() to the code results in a significant decrease in loop speed. As such, for the application writers, only add fsync() to your code when you want to be really sure the data has been written to disk, like when you are writing a database. ** Attachment added: Benchmarks in OpenOffice V2 http://launchpadlibrarian.net/23897042/Ext3Ext4BenchmarksV2.ods -- Ext4 data loss https://bugs.launchpad.net/bugs/317781 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 343490] Re: The partition utility in the setup program reports a bogus disk percentage used.
** Attachment added: PictureOfPercentage http://launchpadlibrarian.net/23897297/UbuntuInstallBug.png -- The partition utility in the setup program reports a bogus disk percentage used. https://bugs.launchpad.net/bugs/343490 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 317781] Re: Ext4 data loss
@Volodymyr I did some experimenting with your test cases. My results so far are: File System Method Performance (Typical, Minimum, Maximum) #Lost %Lost ext31 0.430.420.501 1.00% ext32 0.320.300.330 0.00% ext33 0.190.160.200 0.00% ext34 0.250.200.250 0.00% ext35 0.250.200.250 0.00% ext36 0.440.330.460 0.00% ext41 0.450.440.50100 100.00% ext42 0.330.330.33100 100.00% ext43 0.200.200.210 0.00% ext44 0.250.250.330 0.00% ext45 0.250.250.260 0.00% ext46 0.440.330.410 0.00% Ext4 will zero-length all the files in Ext 4 with test cases 1 and 2. I am working on downloading a revised kernel with the patch. This is my first time doing a recompile for a jaunty release, so this may take a while. ** Attachment added: Benchmarks in OpenOffice http://launchpadlibrarian.net/23871702/Ext3Ext4Benchmarks.ods -- Ext4 data loss https://bugs.launchpad.net/bugs/317781 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 317781] Re: Ext4 data loss
@CowBoyTim I agree with you. I work with real-time industrial systems, where the shop floor systems are considered unreliable. We have all the same issues as a regular desktop user, except our users have bigger hammers. The attraction of ext3 was the journalling with the ordered data mode. If power was cut, it was possible to reassemble something to a recent point in time, with only the most recent data lost. This bug in ext4, results in zero-length files, and not only in the most recent files either. All fsync() does is bypass one layer of write-back caching. This just makes the window of data loss smaller, in the specific case of infrequent fsync() calls. By itself, fsync() does nothing to guarantee data integrity. I think this is why Bogdan was complaining about defective MySQL databases. Given the benchmarks, it is likely that the file system zero-lengthed the entire database file. Specifically, fsync() guarantees the data is on the disk, it doesn't guarantee the file system knows where the file is. As such, one could call fsync(), and still not be able to get at the data after a reboot. The arguments against telling every application developer to use fsync() are: 1. Under heavy file I/O, fsync() could potentially decrease your average I/O speed by defeating the write-back caching. This could make the window of data loss larger, especially with a real-time system where the incoming data rate is fixed. 2. Repeated calls to fsync() would be very rough on laptop mode and on SSDs (Solid State Disks). 3. Repeated calls to fsync() will limit maximum file system performance for desktop applications. Eventually, the file system developers will replace fsync() with an empty function, just like Apple did. 4. If everyone will want fsync(), why don't we just modify close() function to call fsync()? 5. There is a strong correlation between user activity and system crashes. Not using the fsync() leads to much more understandable system behavior. Imagine a typical self-inflicted system crash. This can be caused either directly: Press Save then turn off the Computer, or indirectly: edit video game config, hit play, and then watch the video driver crash. If the write-back cache is enabled, and fsync() is not used, the program will write data to the cache, cause a bunch of disk reads, and then during idle time, the data will be written to disk. If the user generated activity results in disk reads, then the write-back cache will protect the old version of the file. The user will learn that crashing the machine results in him losing his most recent changes. On the other hand, if fsync() is used to disable the write back cache, then programmers will start calling fsync() and close() from background threads. This will result in a poor user experience, as the hard disk will be thrashing during program startup (when all the disk reads are happening), and anything could happen when the system crashes during the fsync(). In the case that system crashes correlate to user activity, it is really tempting from a software point of view, to try to get the fsync() to happen before the system crash occurs. Unfortunately, in practice this is really tough to do. The journaled file system with an ordered data mode is a really good compromise for many desktop and real-time type applications. Additionally, limited fsync() use preserves the effectiveness of fsync() for applications that really need it, like databases. -- Ext4 data loss https://bugs.launchpad.net/bugs/317781 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
