[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in unity-control-center
** Changed in: unity-settings-daemon (Ubuntu) Status: Invalid => In Progress ** Changed in: hwdata (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in unity-control-center Status in hwdata package in Ubuntu: In Progress Status in unity-settings-daemon package in Ubuntu: In Progress Bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1721988] Re: Ubuntu 17.10 full disk encryption + Nvidia drivers not booting
Hi, Could anyone that has it working on 18.04 add plymouth:debug to their kernel cmdline, reboot and share the /var/log/plymouth-debug.log? I'm looking into this, but also experience the issue on 18.04. I'm curious where the difference comes from. Thanks! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to nvidia-graphics-drivers-384 in Ubuntu. https://bugs.launchpad.net/bugs/1721988 Title: Ubuntu 17.10 full disk encryption + Nvidia drivers not booting Status in nvidia-graphics-drivers-384 package in Ubuntu: Confirmed Status in plymouth package in Ubuntu: New Bug description: I've installed ubuntu 17.10 with full disk encryption and then installed the nvidia drivers (v 384). when I boot the computer I will get the graphics interface to enter the encryption key but the system will stop to work, like it has hang. Basically I'm not able to enter the password! I've to restart in safe mode to be able to enter the password for the encryption, after that I can just resume the boot and all works. There seems to be some issues with the initial boot screen and nvidia drivers... I'm not able to press any combination of Control+Alt+Fx key to get any extra info about what is going on (not able to get any text mode). ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: nvidia-384 384.90-0ubuntu2 ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3 Uname: Linux 4.13.0-12-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.7-0ubuntu2 Architecture: amd64 CurrentDesktop: GNOME Date: Sat Oct 7 20:07:29 2017 InstallationDate: Installed on 2017-09-25 (11 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170919) SourcePackage: nvidia-graphics-drivers-384 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-384/+bug/1721988/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1721988] Re: Ubuntu 17.10 full disk encryption + Nvidia drivers not booting
Thanks @goingwc, I have managed to reproduce it here so I can use my own plymouth log. Turns out I couldn't get even 18.04 working correctly, because I had integrated GPU enabled in my motherboard settings (i7-6700K with HD 530) despite nvidia being set to "primary GPU". I had to disable the integrated one completely. After doing some experiments I noticed that this is not related to nvidia, but to modesetting - I was able to reproduce this issue without nvidia drivers installed, just by adding nomodeset to kernel cmdline on pre-bionic releases (tested on Xenial and Artful). -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to nvidia-graphics-drivers-384 in Ubuntu. https://bugs.launchpad.net/bugs/1721988 Title: Ubuntu 17.10 full disk encryption + Nvidia drivers not booting Status in nvidia-graphics-drivers-384 package in Ubuntu: Confirmed Status in plymouth package in Ubuntu: New Bug description: I've installed ubuntu 17.10 with full disk encryption and then installed the nvidia drivers (v 384). when I boot the computer I will get the graphics interface to enter the encryption key but the system will stop to work, like it has hang. Basically I'm not able to enter the password! I've to restart in safe mode to be able to enter the password for the encryption, after that I can just resume the boot and all works. There seems to be some issues with the initial boot screen and nvidia drivers... I'm not able to press any combination of Control+Alt+Fx key to get any extra info about what is going on (not able to get any text mode). ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: nvidia-384 384.90-0ubuntu2 ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3 Uname: Linux 4.13.0-12-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.7-0ubuntu2 Architecture: amd64 CurrentDesktop: GNOME Date: Sat Oct 7 20:07:29 2017 InstallationDate: Installed on 2017-09-25 (11 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170919) SourcePackage: nvidia-graphics-drivers-384 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-384/+bug/1721988/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1721988] Re: Ubuntu 17.10 full disk encryption + Nvidia drivers not booting
** No longer affects: nvidia-graphics-drivers-384 (Ubuntu) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to nvidia-graphics-drivers-384 in Ubuntu. https://bugs.launchpad.net/bugs/1721988 Title: Ubuntu 17.10 full disk encryption + Nvidia drivers not booting Status in plymouth package in Ubuntu: New Bug description: I've installed ubuntu 17.10 with full disk encryption and then installed the nvidia drivers (v 384). when I boot the computer I will get the graphics interface to enter the encryption key but the system will stop to work, like it has hang. Basically I'm not able to enter the password! I've to restart in safe mode to be able to enter the password for the encryption, after that I can just resume the boot and all works. There seems to be some issues with the initial boot screen and nvidia drivers... I'm not able to press any combination of Control+Alt+Fx key to get any extra info about what is going on (not able to get any text mode). ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: nvidia-384 384.90-0ubuntu2 ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3 Uname: Linux 4.13.0-12-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.7-0ubuntu2 Architecture: amd64 CurrentDesktop: GNOME Date: Sat Oct 7 20:07:29 2017 InstallationDate: Installed on 2017-09-25 (11 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170919) SourcePackage: nvidia-graphics-drivers-384 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1721988/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in unity-control-center
** Description changed: + [Impact] + + * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). + This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. + + [Test Case] + + 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). + 2. Open the Displays section of Unity settings. + 3. Look for the newly connected display. + + [Regression Potential] + + * This affects the way the display name will be formatted for any + software using unity-settings-daemon. If anything is testing/comparing + display names - it may fail. + + [Other Info] + + * Original bug description: + After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in unity-control-center Status in hwdata package in Ubuntu: In Progress Status in unity-settings-daemon package in Ubuntu: In Progress Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the newly connected display. [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in unity-control-center
** Description changed: [Impact] - * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). + * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] - 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). - 2. Open the Displays section of Unity settings. - 3. Look for the newly connected display. + 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). + 2. Open the Displays section of Unity settings. + 3. Look for the name of the newly connected display in the settings window. + + Expected result: + Display name should contain it's real diagonal. + + Actual result: + Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] - * This affects the way the display name will be formatted for any + * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] - + * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in unity-control-center Status in hwdata package in Ubuntu: In Progress Status in unity-settings-daemon package in Ubuntu: In Progress Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain it's real diagonal. Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in unity-control-center
seb128: it's also fixed in hwdb upstream (https://github.com/systemd/systemd/pull/10051). I need to check if that's already present in Bionic. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in unity-control-center Status in hwdata package in Ubuntu: Fix Committed Status in unity-settings-daemon package in Ubuntu: Fix Released Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain it's real diagonal. Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in unity-control-center
seb128: I checked and sadly none of the releases (including disco) contains the hwdb fix - looks like it hasn't been released yet upstream - latest systemd release (239) has been published before the fix has been comitted. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in unity-control-center Status in hwdata package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: Fix Released Status in unity-settings-daemon source package in Bionic: Fix Committed Status in unity-settings-daemon source package in Cosmic: Fix Committed Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain it's real diagonal. Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in unity-control-center
** Description changed: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: - Display name should contain it's real diagonal. + Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in unity-control-center Status in hwdata package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: Fix Released Status in unity-settings-daemon source package in Bionic: Fix Committed Status in unity-settings-daemon source package in Cosmic: Fix Committed Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in gnome/unity-control-center
I have just verified both: bionic (15.04.1+18.04.20180413-0ubuntu1.2) and cosmic (15.04.1+18.04.20180413-0ubuntu3) u-s-d packages. In both cases it calculates the diagonal correctly or puts the model name if the real dimensions are not available. However, there is a problem I didn't see coming: hwdata is not installed by default on bionic & cosmic, so the PNP codes are not resolved to vendor names, e.g. u-s-d returned DEL for Dell and GSM for LG Electronics. What are your thoughts on this Seb? Is it worth pulling in hwdata as dependency of u-s-d? It's clearly safer than changing the implementation to use systemd's hwdb. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in gnome/unity-control- center Status in hwdata package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: Fix Released Status in unity-settings-daemon source package in Bionic: Fix Committed Status in unity-settings-daemon source package in Cosmic: Fix Committed Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in gnome/unity-control-center
Alright, thanks Seb. It makes it verified then. ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic ** Tags removed: verification-needed ** Tags added: verification-done ** Tags removed: verification-needed-cosmic ** Tags added: verification-done-cosmic -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in gnome/unity-control- center Status in hwdata package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: Fix Released Status in unity-settings-daemon source package in Bionic: Fix Committed Status in unity-settings-daemon source package in Cosmic: Fix Committed Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in gnome/unity-control-center
hwdata SRU proposal for bionic. ** Patch added: "bionic_hwdata_0.290-1ubuntu1.debdiff" https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+attachment/5216710/+files/bionic_hwdata_0.290-1ubuntu1.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in gnome/unity-control- center Status in hwdata package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: Fix Released Status in unity-settings-daemon source package in Xenial: Fix Committed Status in unity-settings-daemon source package in Bionic: Fix Committed Status in unity-settings-daemon source package in Cosmic: Fix Committed Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in gnome/unity-control-center
hwdata SRU proposal for cosmic. ** Patch added: "cosmic_hwdata_0.290-1ubuntu1.debdiff" https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+attachment/5216709/+files/cosmic_hwdata_0.290-1ubuntu1.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in gnome/unity-control- center Status in hwdata package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: Fix Released Status in unity-settings-daemon source package in Xenial: Fix Committed Status in unity-settings-daemon source package in Bionic: Fix Committed Status in unity-settings-daemon source package in Cosmic: Fix Committed Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in gnome/unity-control-center
hwdata SRU proposal for xenial. ** Patch added: "xenial_hwdata_0.267-1ubuntu1.debdiff" https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+attachment/5216711/+files/xenial_hwdata_0.267-1ubuntu1.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in gnome/unity-control- center Status in hwdata package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: Fix Released Status in unity-settings-daemon source package in Xenial: Fix Committed Status in unity-settings-daemon source package in Bionic: Fix Committed Status in unity-settings-daemon source package in Cosmic: Fix Committed Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in gnome/unity-control-center
I have also provided debdiffs for hwdata (disco is already synced with upstream) so that LG devices are not shown under Goldstar label. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in gnome/unity-control- center Status in hwdata package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: Fix Released Status in unity-settings-daemon source package in Xenial: Fix Committed Status in unity-settings-daemon source package in Bionic: Fix Committed Status in unity-settings-daemon source package in Cosmic: Fix Committed Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in gnome/unity-control-center
I've just verified it on xenial (15.04.1+16.04.20160701-0ubuntu3). Works as expected. Thanks! ** Tags removed: verification-needed verification-needed-xenial ** Tags added: verification-done verification-done-xenial -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in gnome/unity-control- center Status in hwdata package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: Fix Released Status in unity-settings-daemon source package in Xenial: Fix Committed Status in unity-settings-daemon source package in Bionic: Fix Committed Status in unity-settings-daemon source package in Cosmic: Fix Committed Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in gnome/unity-control-center
Brian: afaik disco version of hwdata has been synced with latest upstream by Sebastien. Upstream has this change already applied. With the disco package source: grep GSM hwdata-0.317/pnp.ids* hwdata-0.317/pnp.ids:GSMLG Electronics hwdata-0.317/pnp.ids.patch:-GSM Goldstar Company Ltd hwdata-0.317/pnp.ids.patch:+GSM LG Electronics -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in gnome/unity-control- center Status in hwdata package in Ubuntu: Incomplete Status in unity-settings-daemon package in Ubuntu: Fix Released Status in unity-settings-daemon source package in Xenial: Fix Committed Status in unity-settings-daemon source package in Bionic: Fix Released Status in unity-settings-daemon source package in Cosmic: Fix Released Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in gnome/unity-control-center
Looks like the latest hwdata update (0.267-1ubuntu1) doesn't have full debdiff applied. The change to hwdata-0.267/pnp.ids is missing, it contains only changes to hwdata-0.267/pnp.ids.patch. It doesn't fix the issue this way. ** Tags removed: verification-needed-xenial ** Tags added: verification-failed-xenial ** Tags removed: verification-needed ** Tags added: verification-failed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in gnome/unity-control- center Status in hwdata package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: Fix Released Status in hwdata source package in Xenial: Fix Committed Status in unity-settings-daemon source package in Xenial: Fix Committed Status in unity-settings-daemon source package in Bionic: Fix Released Status in unity-settings-daemon source package in Cosmic: Fix Released Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in gnome/unity-control-center
Run the verifications for: hwdata | 0.267-1ubuntu2 | xenial-proposed hwdata | 0.290-1ubuntu0.18.04.1 | bionic-proposed hwdata | 0.290-1ubuntu0.18.10.1 | cosmic-proposed ** Tags removed: verification-needed-bionic verification-needed-cosmic verification-needed-xenial ** Tags added: verification-done-bionic verification-done-cosmic verification-done-xenial ** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in gnome/unity-control- center Status in hwdata package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: Fix Released Status in hwdata source package in Xenial: Fix Committed Status in unity-settings-daemon source package in Xenial: Fix Committed Status in hwdata source package in Bionic: Fix Committed Status in unity-settings-daemon source package in Bionic: Fix Released Status in hwdata source package in Cosmic: Fix Committed Status in unity-settings-daemon source package in Cosmic: Fix Released Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in gnome/unity-control-center
I checked hwdata output in Unity Settings Displays menu with 2 different devices (vendors: LG and Dell) on LiveCDs for xenial, bionic, cosmic with the proposed patch installed (and with ubuntu-unity-desktop installed from universe in case of bionic and comsmic). Worked as expected (i.e. in the Test Case section of the bug description). -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in gnome/unity-control- center Status in hwdata package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: Fix Released Status in hwdata source package in Xenial: Fix Committed Status in unity-settings-daemon source package in Xenial: Fix Committed Status in hwdata source package in Bionic: Fix Committed Status in unity-settings-daemon source package in Bionic: Fix Released Status in hwdata source package in Cosmic: Fix Committed Status in unity-settings-daemon source package in Cosmic: Fix Released Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in gnome/unity-control-center
gnome-desktop SRU proposal for trusty. ** Patch added: "trusty_gnome-desktop3_3.8.4-0ubuntu3.3.debdiff" https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+attachment/5217608/+files/trusty_gnome-desktop3_3.8.4-0ubuntu3.3.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in gnome/unity-control- center Status in hwdata package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: Fix Released Status in hwdata source package in Xenial: Fix Committed Status in unity-settings-daemon source package in Xenial: Fix Committed Status in hwdata source package in Bionic: Fix Committed Status in unity-settings-daemon source package in Bionic: Fix Released Status in hwdata source package in Cosmic: Fix Committed Status in unity-settings-daemon source package in Cosmic: Fix Released Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in gnome/unity-control-center
It was brought to my attention by Dan that trusty is also worth fixing. The patch to hwdata is identical, however somewhere between trusty and xenial the make_display_name implementation has been moved from gnome- desktop to u-s-d. Hence, despite display-name.c being almost identical in both cases for trusty patching g-d is needed instead of u-s-d. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in gnome/unity-control- center Status in hwdata package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: Fix Released Status in hwdata source package in Xenial: Fix Committed Status in unity-settings-daemon source package in Xenial: Fix Committed Status in hwdata source package in Bionic: Fix Committed Status in unity-settings-daemon source package in Bionic: Fix Released Status in hwdata source package in Cosmic: Fix Committed Status in unity-settings-daemon source package in Cosmic: Fix Released Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in gnome/unity-control-center
hwdata SRU proposal for trusty ** Patch added: "trusty_hwdata_0.249-1ubuntu1.debdiff" https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+attachment/5217607/+files/trusty_hwdata_0.249-1ubuntu1.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in gnome/unity-control- center Status in hwdata package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: Fix Released Status in hwdata source package in Xenial: Fix Committed Status in unity-settings-daemon source package in Xenial: Fix Committed Status in hwdata source package in Bionic: Fix Committed Status in unity-settings-daemon source package in Bionic: Fix Released Status in hwdata source package in Cosmic: Fix Committed Status in unity-settings-daemon source package in Cosmic: Fix Released Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in gnome/unity-control-center
gnome-desktop SRU proposal for trusty ** Patch removed: "trusty_gnome-desktop3_3.8.4-0ubuntu3.3.debdiff" https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+attachment/5217608/+files/trusty_gnome-desktop3_3.8.4-0ubuntu3.3.debdiff ** Patch added: "trusty_gnome-desktop3_3.8.4-0ubuntu3.3.debdiff" https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+attachment/5217619/+files/trusty_gnome-desktop3_3.8.4-0ubuntu3.3.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in gnome/unity-control- center Status in hwdata package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: Fix Released Status in hwdata source package in Xenial: Fix Committed Status in unity-settings-daemon source package in Xenial: Fix Committed Status in hwdata source package in Bionic: Fix Committed Status in unity-settings-daemon source package in Bionic: Fix Released Status in hwdata source package in Cosmic: Fix Committed Status in unity-settings-daemon source package in Cosmic: Fix Released Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in gnome/unity-control-center
** Also affects: gnome-desktop3 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in gnome/unity-control- center Status in gnome-desktop3 package in Ubuntu: New Status in hwdata package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: Fix Released Status in hwdata source package in Xenial: Fix Committed Status in unity-settings-daemon source package in Xenial: Fix Committed Status in hwdata source package in Bionic: Fix Committed Status in unity-settings-daemon source package in Bionic: Fix Released Status in hwdata source package in Cosmic: Fix Committed Status in unity-settings-daemon source package in Cosmic: Fix Released Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-desktop3/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in gnome/unity-control-center
unity-settings-daemon should NOT be nominated for trusty, but I can't fix that. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in gnome/unity-control- center Status in gnome-desktop3 package in Ubuntu: New Status in hwdata package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: Fix Released Status in hwdata source package in Xenial: Fix Committed Status in unity-settings-daemon source package in Xenial: Fix Committed Status in hwdata source package in Bionic: Fix Committed Status in unity-settings-daemon source package in Bionic: Fix Released Status in hwdata source package in Cosmic: Fix Committed Status in unity-settings-daemon source package in Cosmic: Fix Released Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-desktop3/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in gnome/unity-control-center
I have also verified unity-settings-daemon 15.04.1+16.04.20160701-0ubuntu3 for Xenial. After connecting a faulty-EDID display - I saw the product name. With a display device with correct dimensions in EDID - screen diagonal in inches was displayed. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in gnome/unity-control- center Status in gnome-desktop3 package in Ubuntu: Fix Released Status in hwdata package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: Fix Released Status in gnome-desktop3 source package in Trusty: In Progress Status in hwdata source package in Trusty: In Progress Status in unity-settings-daemon source package in Trusty: Invalid Status in hwdata source package in Xenial: Fix Committed Status in unity-settings-daemon source package in Xenial: Fix Committed Status in hwdata source package in Bionic: Fix Committed Status in unity-settings-daemon source package in Bionic: Fix Released Status in hwdata source package in Cosmic: Fix Committed Status in unity-settings-daemon source package in Cosmic: Fix Released Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-desktop3/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in gnome/unity-control-center
I have verified the following packages on Trusty: hwdata - 0.249-1ubuntu1 gnome-desktop-3 - 3.8.4-0ubuntu3.3 With the above packages installed from -proposed the labels presented in the 'Displays' panel of u-c-c are correct: when real size is available in EDID data diagonal is displayed, otherwise the model/product name is used. In all cases vendor PNP codes were resolved to vendor names according to hwdata records. ** Tags removed: verification-needed verification-needed-trusty ** Tags added: verification-done verification-done-trusty -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in gnome/unity-control- center Status in gnome-desktop3 package in Ubuntu: Fix Released Status in hwdata package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: Fix Released Status in gnome-desktop3 source package in Trusty: Fix Committed Status in hwdata source package in Trusty: Fix Committed Status in unity-settings-daemon source package in Trusty: Invalid Status in hwdata source package in Xenial: Fix Committed Status in unity-settings-daemon source package in Xenial: Fix Released Status in hwdata source package in Bionic: Fix Committed Status in unity-settings-daemon source package in Bionic: Fix Released Status in hwdata source package in Cosmic: Fix Committed Status in unity-settings-daemon source package in Cosmic: Fix Released Bug description: [Impact] * There is a number of display devices that misuse the width & height field in EDID. Instead of real size in centimeters it contains encoded aspect ratio (e.g. 1600x900, 16x10, 160x90). This leads to incorrect calculation of diagonal for the purpose of e.g. Unity settings app. [Test Case] 1. Connect a display device that provides incorrect EDID data (e.g. LG 49UB850T-DA TV). 2. Open the Displays section of Unity settings. 3. Look for the name of the newly connected display in the settings window. Expected result: Display name should contain its real diagonal or model name (if dimensions are not availabe). Actual result: Display name contains a ridiculous diagonal (e.g. 72" in case of a 49" display). [Regression Potential] * This affects the way the display name will be formatted for any software using unity-settings-daemon. If anything is testing/comparing display names - it may fail. [Other Info] * Original bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-desktop3/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in unity-control-center
It's still valid. hwdata fixed the "vendor name" part of the issue. u-s-d needs to be patched to fix the "nonsense diagonal calculation" part. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in unity-control-center Status in hwdata package in Ubuntu: In Progress Status in unity-settings-daemon package in Ubuntu: In Progress Bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1908219] [NEW] [drm:qxl_enc_commit [qxl]] *ERROR* head number too large or missing monitors config:
Public bug reported:
[Impact]
* Ubuntu 18.04 used as a guest in KVM with Spice/QXL in use may lead to a DRM
error displayed during xorg launch:
[drm:qxl_enc_commit [qxl]] *ERROR* head number too large or missing monitors
config: (ptrval), 0
[Fix]
* 00e5d217fa19bcbec13135898e1b9ca2c1c3e89b qxl: hook monitors_config
updates into crtc, not encoder.
[Test Case]
* Ubuntu 18.04 desktop guest with 4.15-series kernel with Spice/QXL.
* I used Ubuntu 20.04 as the host, but I was reported that the issue is similar
also on Centos 7.8 used as a host.
[Regression Potential]
* Fix is limited to the QXL driver, so any regressions will be related
to graphics (either potential drm errors or graphical artifacts).
[Other]
* This has been fixed in HWE kernels and in later Ubuntu releases. Only Bionic
is affected.
* According to the description in drivers/gpu/drm/qxl/qxl_dev.h:
struct qxl_monitors_config {
(...)
uint16_t max_allowed; /* If it is 0 no fixed limit is given by the
driver */
(...)
};
In the message this value is 0 which should be a completely correct situation
in that context. However, it is incorrectly compared against current qxl_output.
This has been fixed soon after Bionic release and in Bionic is marked with:
/* TODO: ugly, do better */
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Fix Released
** Affects: linux (Ubuntu Bionic)
Importance: Medium
Status: New
** Also affects: linux (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu)
Status: New => Fix Released
** Changed in: linux (Ubuntu Bionic)
Importance: Undecided => Medium
--
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/1908219
Title:
[drm:qxl_enc_commit [qxl]] *ERROR* head number too large or missing
monitors config:
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Bionic:
New
Bug description:
[Impact]
* Ubuntu 18.04 used as a guest in KVM with Spice/QXL in use may lead to a DRM
error displayed during xorg launch:
[drm:qxl_enc_commit [qxl]] *ERROR* head number too large or missing monitors
config: (ptrval), 0
[Fix]
* 00e5d217fa19bcbec13135898e1b9ca2c1c3e89b qxl: hook monitors_config
updates into crtc, not encoder.
[Test Case]
* Ubuntu 18.04 desktop guest with 4.15-series kernel with Spice/QXL.
* I used Ubuntu 20.04 as the host, but I was reported that the issue is
similar also on Centos 7.8 used as a host.
[Regression Potential]
* Fix is limited to the QXL driver, so any regressions will be related
to graphics (either potential drm errors or graphical artifacts).
[Other]
* This has been fixed in HWE kernels and in later Ubuntu releases. Only
Bionic is affected.
* According to the description in drivers/gpu/drm/qxl/qxl_dev.h:
struct qxl_monitors_config {
(...)
uint16_t max_allowed; /* If it is 0 no fixed limit is given by the
driver */
(...)
};
In the message this value is 0 which should be a completely correct situation
in that context. However, it is incorrectly compared against current qxl_output.
This has been fixed soon after Bionic release and in Bionic is marked with:
/* TODO: ugly, do better */
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1908219/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1908219] Re: [drm:qxl_enc_commit [qxl]] *ERROR* head number too large or missing monitors config:
** Changed in: linux (Ubuntu Bionic)
Assignee: (unassigned) => Dariusz Gadomski (dgadomski)
--
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/1908219
Title:
[drm:qxl_enc_commit [qxl]] *ERROR* head number too large or missing
monitors config:
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Bionic:
New
Bug description:
[Impact]
* Ubuntu 18.04 used as a guest in KVM with Spice/QXL in use may lead to a DRM
error displayed during xorg launch:
[drm:qxl_enc_commit [qxl]] *ERROR* head number too large or missing monitors
config: (ptrval), 0
[Fix]
* 00e5d217fa19bcbec13135898e1b9ca2c1c3e89b qxl: hook monitors_config
updates into crtc, not encoder.
[Test Case]
* Ubuntu 18.04 desktop guest with 4.15-series kernel with Spice/QXL.
* I used Ubuntu 20.04 as the host, but I was reported that the issue is
similar also on Centos 7.8 used as a host.
[Regression Potential]
* Fix is limited to the QXL driver, so any regressions will be related
to graphics (either potential drm errors or graphical artifacts).
[Other]
* This has been fixed in HWE kernels and in later Ubuntu releases. Only
Bionic is affected.
* According to the description in drivers/gpu/drm/qxl/qxl_dev.h:
struct qxl_monitors_config {
(...)
uint16_t max_allowed; /* If it is 0 no fixed limit is given by the
driver */
(...)
};
In the message this value is 0 which should be a completely correct situation
in that context. However, it is incorrectly compared against current qxl_output.
This has been fixed soon after Bionic release and in Bionic is marked with:
/* TODO: ugly, do better */
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1908219/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1908219] Re: [drm:qxl_enc_commit [qxl]] *ERROR* head number too large or missing monitors config:
Patches posted to the kernel-team list:
https://lists.ubuntu.com/archives/kernel-team/2020-December/115620.html
--
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/1908219
Title:
[drm:qxl_enc_commit [qxl]] *ERROR* head number too large or missing
monitors config:
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Bionic:
New
Bug description:
[Impact]
* Ubuntu 18.04 used as a guest in KVM with Spice/QXL in use may lead to a DRM
error displayed during xorg launch:
[drm:qxl_enc_commit [qxl]] *ERROR* head number too large or missing monitors
config: (ptrval), 0
[Fix]
* 00e5d217fa19bcbec13135898e1b9ca2c1c3e89b qxl: hook monitors_config
updates into crtc, not encoder.
[Test Case]
* Ubuntu 18.04 desktop guest with 4.15-series kernel with Spice/QXL.
* I used Ubuntu 20.04 as the host, but I was reported that the issue is
similar also on Centos 7.8 used as a host.
[Regression Potential]
* Fix is limited to the QXL driver, so any regressions will be related
to graphics (either potential drm errors or graphical artifacts).
[Other]
* This has been fixed in HWE kernels and in later Ubuntu releases. Only
Bionic is affected.
* According to the description in drivers/gpu/drm/qxl/qxl_dev.h:
struct qxl_monitors_config {
(...)
uint16_t max_allowed; /* If it is 0 no fixed limit is given by the
driver */
(...)
};
In the message this value is 0 which should be a completely correct situation
in that context. However, it is incorrectly compared against current qxl_output.
This has been fixed soon after Bionic release and in Bionic is marked with:
/* TODO: ugly, do better */
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1908219/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information about display shown in unity-control-center
After examining raw EDID data from 2 different LG TVs I can see that both of them set bytes 21 and 22 of the EDID data in a wrong way. They both state that the display size is 160x90 cm which in turn corresponds to a approximately 72" diagonal. So unity-settings-daemon does its job correctly and EDID from LG is buggy. Trying to find more info about it. ** Changed in: unity-settings-daemon (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in unity-control-center Status in hwdata package in Ubuntu: New Status in unity-settings-daemon package in Ubuntu: Invalid Bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1746482] [NEW] mount.cifs stopped working with protocol version != 1.0
Public bug reported: On a Xenial installation after upgrading to the HWE 4.13.0-32-generic kernel it is not possible to use mount.cifs with -o vers=x.y different than 1.0. Steps to reproduce: 1. Setup a local Samba share. 2. Run: mount.cifs -o user=,vers=2.0 //localhost/theshare/ /mnt/theshare (please note that not specifying the vers= option results in using protocol SMB2.1 which also results in the error). 3. This may be repeated for the following versions: 2.0, 2.1, 3.0. Expected result: The share gets mounted at /mnt/theshare. Actual result: The share is not mounted, this gets printed in the console (and in dmesg): [ 232.439162] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-2 ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: sts -- 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/1746482 Title: mount.cifs stopped working with protocol version != 1.0 Status in linux package in Ubuntu: New Bug description: On a Xenial installation after upgrading to the HWE 4.13.0-32-generic kernel it is not possible to use mount.cifs with -o vers=x.y different than 1.0. Steps to reproduce: 1. Setup a local Samba share. 2. Run: mount.cifs -o user=,vers=2.0 //localhost/theshare/ /mnt/theshare (please note that not specifying the vers= option results in using protocol SMB2.1 which also results in the error). 3. This may be repeated for the following versions: 2.0, 2.1, 3.0. Expected result: The share gets mounted at /mnt/theshare. Actual result: The share is not mounted, this gets printed in the console (and in dmesg): [ 232.439162] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1746482/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1746482] Re: mount.cifs stopped working with protocol version != 1.0
As discussed with cascardo I tested the mainline builds from [1]. After some tests the results were: v4.12.14 - good v4.13 - bad So the regression seems to be introduced in v4.13. [1] http://kernel.ubuntu.com/~kernel-ppa/mainline/ -- 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/1746482 Title: mount.cifs stopped working with protocol version != 1.0 Status in linux package in Ubuntu: Incomplete Bug description: On a Xenial installation after upgrading to the HWE 4.13.0-32-generic kernel it is not possible to use mount.cifs with -o vers=x.y different than 1.0. Steps to reproduce: 1. Setup a local Samba share. 2. Run: mount.cifs -o user=,vers=2.0 //localhost/theshare/ /mnt/theshare (please note that not specifying the vers= option results in using protocol SMB2.1 which also results in the error). 3. This may be repeated for the following versions: 2.0, 2.1, 3.0. Expected result: The share gets mounted at /mnt/theshare. Actual result: The share is not mounted, this gets printed in the console (and in dmesg): [ 232.439162] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1746482/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1746482] Re: mount.cifs stopped working with protocol version != 1.0
dmesg output after reproducing the issue with echo 7 > /proc/fs/cifs/cifsFYI ** Attachment added: "dmesg.txt" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1746482/+attachment/5046387/+files/dmesg.txt -- 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/1746482 Title: mount.cifs stopped working with protocol version != 1.0 Status in linux package in Ubuntu: Incomplete Bug description: On a Xenial installation after upgrading to the HWE 4.13.0-32-generic kernel it is not possible to use mount.cifs with -o vers=x.y different than 1.0. Steps to reproduce: 1. Setup a local Samba share. 2. Run: mount.cifs -o user=,vers=2.0 //localhost/theshare/ /mnt/theshare (please note that not specifying the vers= option results in using protocol SMB2.1 which also results in the error). 3. This may be repeated for the following versions: 2.0, 2.1, 3.0. Expected result: The share gets mounted at /mnt/theshare. Actual result: The share is not mounted, this gets printed in the console (and in dmesg): [ 232.439162] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1746482/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1746482] Re: mount.cifs stopped working with protocol version != 1.0
Surprisingly it works perfectly fine for 4.15.0-041500-generic. I have tested vers= parameter from 1.0 to 3.0 - no issues at all. I went forward and tested v4.14 - it is not affected by the issue as well. -- 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/1746482 Title: mount.cifs stopped working with protocol version != 1.0 Status in linux package in Ubuntu: Incomplete Bug description: On a Xenial installation after upgrading to the HWE 4.13.0-32-generic kernel it is not possible to use mount.cifs with -o vers=x.y different than 1.0. Steps to reproduce: 1. Setup a local Samba share. 2. Run: mount.cifs -o user=,vers=2.0 //localhost/theshare/ /mnt/theshare (please note that not specifying the vers= option results in using protocol SMB2.1 which also results in the error). 3. This may be repeated for the following versions: 2.0, 2.1, 3.0. Expected result: The share gets mounted at /mnt/theshare. Actual result: The share is not mounted, this gets printed in the console (and in dmesg): [ 232.439162] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1746482/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1746482] Re: mount.cifs stopped working with protocol version != 1.0
Added updated dmesg (with verbose error message). ** Attachment added: "dmesg.log" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1746482/+attachment/5047510/+files/dmesg_latest.log -- 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/1746482 Title: mount.cifs stopped working with protocol version != 1.0 Status in linux package in Ubuntu: Incomplete Bug description: On a Xenial installation after upgrading to the HWE 4.13.0-32-generic kernel it is not possible to use mount.cifs with -o vers=x.y different than 1.0. Steps to reproduce: 1. Setup a local Samba share with ntlm auth = yes. 2. Run: mount.cifs -o user=,sec=ntlm,vers=2.0 //localhost/theshare/ /mnt/theshare 3. This may be repeated for the following versions: 2.0, 2.1, 3.0. Expected result: The share gets mounted at /mnt/theshare. Actual result: The share is not mounted, this gets printed in the console: mount error(22): Invalid argument Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and in dmesg: [ 61.935687] CIFS VFS: Unable to select appropriate authentication method! [ 61.935689] CIFS VFS: Send error in SessSetup = -22 [ 61.935744] CIFS VFS: cifs_mount failed w/return code = -22 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1746482/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1746482] Re: mount.cifs stopped working with protocol version != 1.0
Added updated dmesg (with verbose error message). ** Attachment added: "dmesg.log" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1746482/+attachment/5047511/+files/dmesg_latest.log ** Attachment removed: "dmesg.txt" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1746482/+attachment/5046387/+files/dmesg.txt ** Attachment removed: "dmesg.log" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1746482/+attachment/5047510/+files/dmesg_latest.log -- 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/1746482 Title: mount.cifs stopped working with protocol version != 1.0 Status in linux package in Ubuntu: Incomplete Bug description: On a Xenial installation after upgrading to the HWE 4.13.0-32-generic kernel it is not possible to use mount.cifs with -o vers=x.y different than 1.0. Steps to reproduce: 1. Setup a local Samba share with ntlm auth = yes. 2. Run: mount.cifs -o user=,sec=ntlm,vers=2.0 //localhost/theshare/ /mnt/theshare 3. This may be repeated for the following versions: 2.0, 2.1, 3.0. Expected result: The share gets mounted at /mnt/theshare. Actual result: The share is not mounted, this gets printed in the console: mount error(22): Invalid argument Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and in dmesg: [ 61.935687] CIFS VFS: Unable to select appropriate authentication method! [ 61.935689] CIFS VFS: Send error in SessSetup = -22 [ 61.935744] CIFS VFS: cifs_mount failed w/return code = -22 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1746482/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1746482] Re: mount.cifs stopped working with protocol version != 1.0
Looks like I've been mislead by the man page of mount.cifs and
linux/fs/cifs/connect.c which state:
man mount.cifs:
vers=
SMB protocol version. Allowed values are:
· 1.0 - The classic CIFS/SMBv1 protocol. This is the
default.
4.13 kernel code:
pr_warn("No dialect specified on mount. Default has changed to "
"a more secure dialect, SMB2.1 or later (e.g. SMB3),
from CIFS "
"(SMB1). To use the less secure SMB1 dialect to access "
"old servers which do not support SMB3 (or SMB2.1)
specify vers=1.0"
" on mount.\n");
So looks like I need to explicitly apply the version number to
mount.cifs argument to have consistent results.
More over sec=ntlm is needed in smb.conf and mount.cifs cmdline.
Updating the description.
** Description changed:
On a Xenial installation after upgrading to the HWE 4.13.0-32-generic
kernel it is not possible to use mount.cifs with -o vers=x.y different
than 1.0.
Steps to reproduce:
- 1. Setup a local Samba share.
+ 1. Setup a local Samba share with ntlm auth = yes.
2. Run:
- mount.cifs -o user=,sec=ntlm //localhost/theshare/ /mnt/theshare
- (please note that not specifying the vers= option results in using protocol
SMB2.1 which also results in the error).
+ mount.cifs -o user=,sec=ntlm,vers=2.0 //localhost/theshare/
/mnt/theshare
3. This may be repeated for the following versions: 2.0, 2.1, 3.0.
Expected result:
The share gets mounted at /mnt/theshare.
Actual result:
The share is not mounted, this gets printed in the console (and in dmesg):
[ 232.439162] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-2
** Description changed:
On a Xenial installation after upgrading to the HWE 4.13.0-32-generic
kernel it is not possible to use mount.cifs with -o vers=x.y different
than 1.0.
Steps to reproduce:
1. Setup a local Samba share with ntlm auth = yes.
2. Run:
mount.cifs -o user=,sec=ntlm,vers=2.0 //localhost/theshare/
/mnt/theshare
3. This may be repeated for the following versions: 2.0, 2.1, 3.0.
Expected result:
The share gets mounted at /mnt/theshare.
Actual result:
- The share is not mounted, this gets printed in the console (and in dmesg):
- [ 232.439162] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-2
+ The share is not mounted, this gets printed in the console:
+ mount error(22): Invalid argument
+ Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
+
+ and in dmesg:
+ [ 61.935687] CIFS VFS: Unable to select appropriate authentication method!
+ [ 61.935689] CIFS VFS: Send error in SessSetup = -22
+ [ 61.935744] CIFS VFS: cifs_mount failed w/return code = -22
--
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/1746482
Title:
mount.cifs stopped working with protocol version != 1.0
Status in linux package in Ubuntu:
Incomplete
Bug description:
On a Xenial installation after upgrading to the HWE 4.13.0-32-generic
kernel it is not possible to use mount.cifs with -o vers=x.y different
than 1.0.
Steps to reproduce:
1. Setup a local Samba share with ntlm auth = yes.
2. Run:
mount.cifs -o user=,sec=ntlm,vers=2.0 //localhost/theshare/
/mnt/theshare
3. This may be repeated for the following versions: 2.0, 2.1, 3.0.
Expected result:
The share gets mounted at /mnt/theshare.
Actual result:
The share is not mounted, this gets printed in the console:
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
and in dmesg:
[ 61.935687] CIFS VFS: Unable to select appropriate authentication method!
[ 61.935689] CIFS VFS: Send error in SessSetup = -22
[ 61.935744] CIFS VFS: cifs_mount failed w/return code = -22
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1746482/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1746482] Re: mount.cifs stopped working with protocol version != 1.0
Conclusion after correcting the parameters in my test procedure: v4.10 - good v4.11 - bad v4.15 - bad I'm performing a bisect between v4.10 and v4.11. -- 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/1746482 Title: mount.cifs stopped working with protocol version != 1.0 Status in linux package in Ubuntu: Incomplete Bug description: On a Xenial installation after upgrading to the HWE 4.13.0-32-generic kernel it is not possible to use mount.cifs with -o vers=x.y different than 1.0. Steps to reproduce: 1. Setup a local Samba share with ntlm auth = yes. 2. Run: mount.cifs -o user=,sec=ntlm,vers=2.0 //localhost/theshare/ /mnt/theshare 3. This may be repeated for the following versions: 2.0, 2.1, 3.0. Expected result: The share gets mounted at /mnt/theshare. Actual result: The share is not mounted, this gets printed in the console: mount error(22): Invalid argument Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and in dmesg: [ 61.935687] CIFS VFS: Unable to select appropriate authentication method! [ 61.935689] CIFS VFS: Send error in SessSetup = -22 [ 61.935744] CIFS VFS: cifs_mount failed w/return code = -22 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1746482/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1746482] Re: mount.cifs stopped working with protocol version != 1.0
** Description changed: On a Xenial installation after upgrading to the HWE 4.13.0-32-generic kernel it is not possible to use mount.cifs with -o vers=x.y different than 1.0. Steps to reproduce: 1. Setup a local Samba share. 2. Run: - mount.cifs -o user=,vers=2.0 //localhost/theshare/ /mnt/theshare + mount.cifs -o user=,sec=ntlm //localhost/theshare/ /mnt/theshare (please note that not specifying the vers= option results in using protocol SMB2.1 which also results in the error). 3. This may be repeated for the following versions: 2.0, 2.1, 3.0. Expected result: The share gets mounted at /mnt/theshare. Actual result: The share is not mounted, this gets printed in the console (and in dmesg): [ 232.439162] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-2 -- 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/1746482 Title: mount.cifs stopped working with protocol version != 1.0 Status in linux package in Ubuntu: Incomplete Bug description: On a Xenial installation after upgrading to the HWE 4.13.0-32-generic kernel it is not possible to use mount.cifs with -o vers=x.y different than 1.0. Steps to reproduce: 1. Setup a local Samba share. 2. Run: mount.cifs -o user=,sec=ntlm //localhost/theshare/ /mnt/theshare (please note that not specifying the vers= option results in using protocol SMB2.1 which also results in the error). 3. This may be repeated for the following versions: 2.0, 2.1, 3.0. Expected result: The share gets mounted at /mnt/theshare. Actual result: The share is not mounted, this gets printed in the console (and in dmesg): [ 232.439162] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1746482/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1746482] Re: mount.cifs stopped working with protocol version != 1.0
Bisecting between v4.10 and v4.11 resulted in finding that this was caused by the following commit: [ef65aaede23f75977af56a8c330bb9be8c6e125c] smb2: Enforce sec= mount option Reverting it on top of v4.11 makes it go away. Looking more into it. -- 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/1746482 Title: mount.cifs stopped working with protocol version != 1.0 Status in linux package in Ubuntu: Incomplete Bug description: On a Xenial installation after upgrading to the HWE 4.13.0-32-generic kernel it is not possible to use mount.cifs with -o vers=x.y different than 1.0. Steps to reproduce: 1. Setup a local Samba share with ntlm auth = yes. 2. Run: mount.cifs -o user=,sec=ntlm,vers=2.0 //localhost/theshare/ /mnt/theshare 3. This may be repeated for the following versions: 2.0, 2.1, 3.0. Expected result: The share gets mounted at /mnt/theshare. Actual result: The share is not mounted, this gets printed in the console: mount error(22): Invalid argument Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and in dmesg: [ 61.935687] CIFS VFS: Unable to select appropriate authentication method! [ 61.935689] CIFS VFS: Send error in SessSetup = -22 [ 61.935744] CIFS VFS: cifs_mount failed w/return code = -22 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1746482/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1746482] Re: mount.cifs stopped working with protocol version>1 and sec=ntlm
** Summary changed: - mount.cifs stopped working with protocol version != 1.0 + mount.cifs stopped working with protocol version>1 and sec=ntlm -- 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/1746482 Title: mount.cifs stopped working with protocol version>1 and sec=ntlm Status in linux package in Ubuntu: Incomplete Bug description: On a Xenial installation after upgrading to the HWE 4.13.0-32-generic kernel it is not possible to use mount.cifs with -o vers=x.y different than 1.0. Steps to reproduce: 1. Setup a local Samba share with ntlm auth = yes. 2. Run: mount.cifs -o user=,sec=ntlm,vers=2.0 //localhost/theshare/ /mnt/theshare 3. This may be repeated for the following versions: 2.0, 2.1, 3.0. Expected result: The share gets mounted at /mnt/theshare. Actual result: The share is not mounted, this gets printed in the console: mount error(22): Invalid argument Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and in dmesg: [ 61.935687] CIFS VFS: Unable to select appropriate authentication method! [ 61.935689] CIFS VFS: Send error in SessSetup = -22 [ 61.935744] CIFS VFS: cifs_mount failed w/return code = -22 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1746482/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1746482] Re: mount.cifs stopped working with protocol version>1 and sec=ntlm
After the preliminary analysis my understanding is as follows: since the change found thanks to the bisection the behaviour change in a way that if an unsupported security mode is requested it results in an error (invalid argument in this case). Looks like NTLM was not supported even before the change in question, it was just unnoticed since it was silently mapped to NTLMSSP. So no actual regression in functionality is observed, but rather regression in UI being less restrictive before the kernel change. -- 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/1746482 Title: mount.cifs stopped working with protocol version>1 and sec=ntlm Status in linux package in Ubuntu: Incomplete Bug description: On a Xenial installation after upgrading to the HWE 4.13.0-32-generic kernel it is not possible to use mount.cifs with -o vers=x.y different than 1.0. Steps to reproduce: 1. Setup a local Samba share with ntlm auth = yes. 2. Run: mount.cifs -o user=,sec=ntlm,vers=2.0 //localhost/theshare/ /mnt/theshare 3. This may be repeated for the following versions: 2.0, 2.1, 3.0. Expected result: The share gets mounted at /mnt/theshare. Actual result: The share is not mounted, this gets printed in the console: mount error(22): Invalid argument Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and in dmesg: [ 61.935687] CIFS VFS: Unable to select appropriate authentication method! [ 61.935689] CIFS VFS: Send error in SessSetup = -22 [ 61.935744] CIFS VFS: cifs_mount failed w/return code = -22 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1746482/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] [NEW] Incorrect information about display shown in unity-control-center
Public bug reported: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. ** Affects: hwdata (Ubuntu) Importance: Undecided Status: New ** Affects: unity-settings-daemon (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in unity-control-center Status in hwdata package in Ubuntu: New Status in unity-settings-daemon package in Ubuntu: New Bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information displayed in unity-control-center
Goldstar seems to be a former name of LG (before the Lucky-Goldstar merge). I've made a pull request upstream to update it: https://github.com/vcrhonek/hwdata/pull/1 ** Also affects: unity-settings-daemon (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in unity-control-center Status in hwdata package in Ubuntu: New Status in unity-settings-daemon package in Ubuntu: New Bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755490] Re: Incorrect information displayed in unity-control-center
Another thing is the diagonal length calculation. From my quick look this is done based on EDID data in unity-settings-daemon. ** Summary changed: - Incorrect information displayed in unity-control-center + Incorrect information about display shown in unity-control-center -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to hwdata in Ubuntu. https://bugs.launchpad.net/bugs/1755490 Title: Incorrect information about display shown in unity-control-center Status in hwdata package in Ubuntu: New Status in unity-settings-daemon package in Ubuntu: New Bug description: After connecting a LG 49UB850T-DA TV the following information is displayed in the unity-control-center: Goldstar Company Ltd 72" It's misleading since neither the company name nor the diagonal matches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hwdata/+bug/1755490/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1718688] [NEW] Can't connect to a Cisco AP with Wi-Fi Direct Client Policy enabled
Public bug reported: There is a setting available on selected Cisco hardware named "Wi-Fi Direct Client Policy". One of the allowed option there is 'not-allow'. It's intention is to block WiFi P2P capable devices from connecting to it. If a device trying to associate with an AP with this setting enabled is identified as "P2P capable" it gets blacklisted (I believe for a preconfigured time). More info about the option available at [1] and [2]. This leads to a situation that it is impossible to connect to certain APs using certain WiFi chips using iwlwifi driver. I was able to determine that this at least affects Intel 8260 chip. What's going on on the WiFi level is: The AP broadcasts beacon frames with P2P IE: Tag: Vendor Specific: Wi-FiAll: P2P Tag Number: Vendor Specific (221) Tag length: 8 OUI: 50-6f-9a (Wi-FiAll) Vendor Specific OUI Type: 9 P2P Manageability: Bitmap field 0x5 Attribute Type: P2P Manageability (10) Attribute Length: 1 Manageability Bitmap field: 0x05 ...1 = P2P Device Management: 0x1 ..0. = Cross Connection Permitted: 0x0 .1.. = Coexistence Optional: 0x1 The client then sends a Probe Request, also with a P2P IE in it: Tag: Vendor Specific: Wi-FiAll: P2P Tag Number: Vendor Specific (221) Tag length: 17 OUI: 50-6f-9a (Wi-FiAll) Vendor Specific OUI Type: 9 P2P Capability: Device 0x25 Group 0x0 Attribute Type: P2P Capability (2) Attribute Length: 2 Device Capability Bitmap: 0x25 ...1 = Service Discovery: 0x1 ..0. = P2P Client Discoverability: 0x0 .1.. = Concurrent Operation: 0x1 0... = P2P Infrastructure Managed: 0x0 ...0 = P2P Device Limit: 0x0 ..1. = P2P Invitation Procedure: 0x1 Group Capability Bitmap: 0x00 ...0 = P2P Group Owner: 0x0 ..0. = Persistent P2P Group: 0x0 .0.. = P2P Group Limit: 0x0 0... = Intra-BSS Distribution: 0x0 ...0 = Cross Connection: 0x0 ..0. = Persistent Reconnect: 0x0 .0.. = Group Formation: 0x0 Listen Channel: Operating Class 81 Channel Number 1 Attribute Type: Listen Channel (6) Attribute Length: 5 Country String: XX\004 Operating Class: 81 Channel Number: 1 The AP never replies to that Probe Request and blacklists the device for a given period of time from all communication. I was able to test a custom kernel with all P2P interfaces commented out from iwlwifi/mvm/mac80211.c - it was able to connect to the AP without any issues. For instance this issue does not affect bcm43224 device running with brcm80211 - in this case the client device sends a Probe Request without the P2P IE. Despite it's is actually P2P-capable the AP does not recognize it as such and allows it to connect. I have also started a mailing list thread about it [3]. What I think could fix it is either: * making it behave more like the broadcom driver so it allows users to connect * provide an user-friendly option of disabling p2p capabilites (including transmitting probe reuqests without P2P IE) * as suggested on the ML [4] implement sections 3.4.3/3.4.4 of the WiFi Direct spec in the driver According to my knowledge it affects all currently supported releases: Trusty, Xenial, Zesty plus Artful. [1] https://supportforums.cisco.com/t5/security-and-network-management/wi-fi-direct-client-policy/td-p/2253033 [2] https://www.cisco.com/c/en/us/td/docs/wireless/controller/7-4/configuration/guides/consolidated/b_cg74_CONSOLIDATED/b_cg74_CONSOLIDATED_chapter_01010.html [3] https://marc.info/?l=linux-wireless&m=150306048824814&w=2 [4] https://marc.info/?l=linux-wireless&m=150461784431430&w=2 ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Description changed: There is a setting available on selected Cisco hardware named "Wi-Fi Direct Client Policy". One of the allowed option there is 'not-allow'. It's intention is to block WiFi P2P capable devices from connecting to it. If a device trying to associate with an AP with this setting enabled is identified as "P2P capable" it gets blacklisted (I believe for a preconfigured time). More info about the option available at [1] and [2]. This leads to a situation that it is impossible to connect to certain APs using certain WiFi chips using iwlwifi driver. I was able to determine that this at least affects Intel 8260 chip. What's going on on the WiFi level is: The AP broadcasts beacon frames with P2P IE: Tag: Vendor Specific: Wi-FiAll: P2P - Tag Number: Vendor Specific (221) - Tag length: 8 - OUI: 50-6f-9a (Wi-FiAll) - Vendor Specific OUI Type: 9 - P2P Manageability: Bitmap field 0x5 - Attribute Type: P2P Manageability (10) - Attribute Length: 1 - Manageability Bitmap field: 0x05 - ..
[Kernel-packages] [Bug 1718688] Re: Can't connect to a Cisco AP with Wi-Fi Direct Client Policy enabled
Since I don't have access to the actual Cisco hardware for testing I have been experimenting with hostapd lately. After rebuilding it with CONFIG_P2P_MANAGER=y I was able to reproduce similar behavior as observed with Cisco hw (except for blacklisting) and as described in WiFi P2P spec v1.7 section 3.4. I was able to prevent my laptop from transmitting any P2P IEs after disabling P2P capabilities with wpa_cli -i p2p_set disabled 1 This however is different from what may be observed with other WiFi devices/drivers (as mentioned in the description) and the final paragraph of [1] suggests that it may be something missing/broken in the driver. [1] https://marc.info/?l=linux-wireless&m=150461784431430&w=2 -- 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/1718688 Title: Can't connect to a Cisco AP with Wi-Fi Direct Client Policy enabled Status in linux package in Ubuntu: Confirmed Bug description: There is a setting available on selected Cisco hardware named "Wi-Fi Direct Client Policy". One of the allowed option there is 'not-allow'. It's intention is to block WiFi P2P capable devices from connecting to it. If a device trying to associate with an AP with this setting enabled is identified as "P2P capable" it gets blacklisted (I believe for a preconfigured time). More info about the option available at [1] and [2]. This leads to a situation that it is impossible to connect to certain APs using certain WiFi chips using iwlwifi driver. I was able to determine that this at least affects Intel 8260 chip. What's going on on the WiFi level is: The AP broadcasts beacon frames with P2P IE: Tag: Vendor Specific: Wi-FiAll: P2P Tag Number: Vendor Specific (221) Tag length: 8 OUI: 50-6f-9a (Wi-FiAll) Vendor Specific OUI Type: 9 P2P Manageability: Bitmap field 0x5 Attribute Type: P2P Manageability (10) Attribute Length: 1 Manageability Bitmap field: 0x05 ...1 = P2P Device Management: 0x1 ..0. = Cross Connection Permitted: 0x0 .1.. = Coexistence Optional: 0x1 The client then sends a Probe Request, also with a P2P IE in it: Tag: Vendor Specific: Wi-FiAll: P2P Tag Number: Vendor Specific (221) Tag length: 17 OUI: 50-6f-9a (Wi-FiAll) Vendor Specific OUI Type: 9 P2P Capability: Device 0x25 Group 0x0 Attribute Type: P2P Capability (2) Attribute Length: 2 Device Capability Bitmap: 0x25 ...1 = Service Discovery: 0x1 ..0. = P2P Client Discoverability: 0x0 .1.. = Concurrent Operation: 0x1 0... = P2P Infrastructure Managed: 0x0 ...0 = P2P Device Limit: 0x0 ..1. = P2P Invitation Procedure: 0x1 Group Capability Bitmap: 0x00 ...0 = P2P Group Owner: 0x0 ..0. = Persistent P2P Group: 0x0 .0.. = P2P Group Limit: 0x0 0... = Intra-BSS Distribution: 0x0 ...0 = Cross Connection: 0x0 ..0. = Persistent Reconnect: 0x0 .0.. = Group Formation: 0x0 Listen Channel: Operating Class 81 Channel Number 1 Attribute Type: Listen Channel (6) Attribute Length: 5 Country String: XX\004 Operating Class: 81 Channel Number: 1 The AP never replies to that Probe Request and blacklists the device for a given period of time from all communication. I was able to test a custom kernel with all P2P interfaces commented out from iwlwifi/mvm/mac80211.c - it was able to connect to the AP without any issues. For instance this issue does not affect bcm43224 device running with brcm80211 - in this case the client device sends a Probe Request without the P2P IE. Despite it's is actually P2P-capable the AP does not recognize it as such and allows it to connect. I have also started a mailing list thread about it [3]. What I think could fix it is either: * making it behave more like the broadcom driver so it allows users to connect * provide an user-friendly option of disabling p2p capabilites (including transmitting probe reuqests without P2P IE) * as suggested on the ML [4] implement sections 3.4.3/3.4.4 of the WiFi Direct spec in the driver According to my knowledge it affects all currently supported releases: Trusty, Xenial, Zesty plus Artful. [1] https://supportforums.cisco.com/t5/security-and-network-management/wi-fi-direct-client-policy/td-p/2253033 [2] https://www.cisco.com/c/en/us/td/docs/wireless/controller/7-4/configuration/guides/consolidated/b_cg74_CONSOLIDATED/b_cg74_CONSOLIDATED_chapter_01010.html [3] https://marc.info/?l=linux-wireless&m=150306048824814&w=2 [4] https://marc.info/?l=linux-wireless&m=150461784431430&w=2 To manage notifications a
[Kernel-packages] [Bug 1674680] Re: Deprecated rfcomm.conf still mentioned in bluetooth.conf and README
Artful patch proposal. ** Patch added: "artful_bluez_5.45-0ubuntu3.debdiff" https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+attachment/4928336/+files/artful_bluez_5.45-0ubuntu3.debdiff ** Patch removed: "zesty_bluez_5.43-0ubuntu2.debdiff" https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+attachment/4841667/+files/zesty_bluez_5.43-0ubuntu2.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1674680 Title: Deprecated rfcomm.conf still mentioned in bluetooth.conf and README Status in bluez package in Ubuntu: New Status in bluez source package in Xenial: New Status in bluez source package in Yakkety: Won't Fix Status in bluez package in Debian: New Bug description: [Impact] * The package contains misleading documentation mentioning the use of /etc/bluetooth/rfcomm.conf for rfcomm setup while the support for config file has been dropped after 14.04 release. I have directly received a question about it from a user mislead by the documentation. * Additionally deprecated -f option is still used in legacy upstart /etc/init/bluetooth.conf. Actually this does not seem longer required due to upstart being removed. [Test Case] * Install bluez. * Look for misleading rfcomm.conf mentions in /etc/init/bluetooth.conf, /usr/share/doc/bluez/README.Debian.gz [Regression Potential] * This is mostly a documentation correction, however if somebody still depends bluetooth started with Ubuntu 16.04+ by upstart (or possibly some kind of upstart compatibility in systemd, is that even possible?) he/she may end up with bluetooth not being started. This seems highly unlikely. [Other Info] * Original bug description: Support for config files has been dropped upstream in 2012 (however version shipped with Trusty still supports it), but the latest versions (including Xenial and Zesty) still mention it in the docs and in the legacy /etc/init/bluetooth.conf file. Additionally the /etc/init/bluetooth.conf don't seem necessary these days. In fact it has been dropped by Debian already. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1674680] Re: Deprecated rfcomm.conf still mentioned in bluetooth.conf and README
Patch proposal for Artful. ** Patch added: "artful_bluez_5.45-0ubuntu3.debdiff" https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+attachment/4928420/+files/artful_bluez_5.45-0ubuntu3.debdiff ** Patch removed: "artful_bluez_5.45-0ubuntu3.debdiff" https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+attachment/4928336/+files/artful_bluez_5.45-0ubuntu3.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1674680 Title: Deprecated rfcomm.conf still mentioned in bluetooth.conf and README Status in bluez package in Ubuntu: New Status in bluez source package in Xenial: New Status in bluez source package in Yakkety: Won't Fix Status in bluez source package in Artful: New Status in bluez package in Debian: New Bug description: [Impact] * The package contains misleading documentation mentioning the use of /etc/bluetooth/rfcomm.conf for rfcomm setup while the support for config file has been dropped after 14.04 release. I have directly received a question about it from a user mislead by the documentation. * Additionally deprecated -f option is still used in legacy upstart /etc/init/bluetooth.conf. Actually this does not seem longer required due to upstart being removed. [Test Case] * Install bluez. * Look for misleading rfcomm.conf mentions in /etc/init/bluetooth.conf, /usr/share/doc/bluez/README.Debian.gz [Regression Potential] * This is mostly a documentation correction, however if somebody still depends bluetooth started with Ubuntu 16.04+ by upstart (or possibly some kind of upstart compatibility in systemd, is that even possible?) he/she may end up with bluetooth not being started. This seems highly unlikely. [Other Info] * Original bug description: Support for config files has been dropped upstream in 2012 (however version shipped with Trusty still supports it), but the latest versions (including Xenial and Zesty) still mention it in the docs and in the legacy /etc/init/bluetooth.conf file. Additionally the /etc/init/bluetooth.conf don't seem necessary these days. In fact it has been dropped by Debian already. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1674680] [NEW] Dropped rfcomm.conf still mentioned
Public bug reported: Support for config files has been dropped upstream in 2012 (however version shipped with Trusty still supports it), but the latest versions (including Xenial and Zesty) still mention it in the docs and in the legacy /etc/init/bluetooth.conf file. ** Affects: bluez (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1674680 Title: Dropped rfcomm.conf still mentioned Status in bluez package in Ubuntu: New Bug description: Support for config files has been dropped upstream in 2012 (however version shipped with Trusty still supports it), but the latest versions (including Xenial and Zesty) still mention it in the docs and in the legacy /etc/init/bluetooth.conf file. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1674680] Re: Deprecated rfcomm.conf still mentioned
** Summary changed: - Dropped rfcomm.conf still mentioned + Deprecated rfcomm.conf still mentioned ** Description changed: Support for config files has been dropped upstream in 2012 (however version shipped with Trusty still supports it), but the latest versions (including Xenial and Zesty) still mention it in the docs and in the legacy /etc/init/bluetooth.conf file. + + Additionally the /etc/init/bluetooth.conf don't seem necessary these + days. In fact it has been dropped by Debian already. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1674680 Title: Deprecated rfcomm.conf still mentioned Status in bluez package in Ubuntu: New Bug description: Support for config files has been dropped upstream in 2012 (however version shipped with Trusty still supports it), but the latest versions (including Xenial and Zesty) still mention it in the docs and in the legacy /etc/init/bluetooth.conf file. Additionally the /etc/init/bluetooth.conf don't seem necessary these days. In fact it has been dropped by Debian already. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1674680] Re: Deprecated rfcomm.conf still mentioned
Patch proposal for Zesty. ** Tags added: sts sts-sponsor ** Patch added: "zesty_bluez_5.43-0ubuntu2.debdiff" https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+attachment/4841667/+files/zesty_bluez_5.43-0ubuntu2.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1674680 Title: Deprecated rfcomm.conf still mentioned Status in bluez package in Ubuntu: New Bug description: Support for config files has been dropped upstream in 2012 (however version shipped with Trusty still supports it), but the latest versions (including Xenial and Zesty) still mention it in the docs and in the legacy /etc/init/bluetooth.conf file. Additionally the /etc/init/bluetooth.conf don't seem necessary these days. In fact it has been dropped by Debian already. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1674680] Re: Deprecated rfcomm.conf still mentioned
** Description changed: + [Impact] + + * The package contains misleading documentation mentioning the use of + /etc/bluetooth/rfcomm.conf for rfcomm setup while the support for config + file has been dropped after 14.04 release. I have directly received a + question about it from a user mislead by the documentation. + + * Additionally deprecated -f option is still used in legacy upstart + /etc/init/bluetooth.conf. Actually this does not seem longer required + due to upstart being removed. + + [Test Case] + + * Install bluez. + + * Look for misleading rfcomm.conf mentions in /etc/init/bluetooth.conf, + /usr/share/doc/bluez/README.Debian.gz + + [Regression Potential] + + * This is mostly a documentation correction, however if somebody still + depends bluetooth started with Ubuntu 16.04+ by upstart (or possibly + some kind of upstart compatibility in systemd, is that even possible?) + he/she may end up with bluetooth not being started. This seems highly + unlikely. + + [Other Info] + + * Original bug description: + Support for config files has been dropped upstream in 2012 (however version shipped with Trusty still supports it), but the latest versions (including Xenial and Zesty) still mention it in the docs and in the legacy /etc/init/bluetooth.conf file. Additionally the /etc/init/bluetooth.conf don't seem necessary these days. In fact it has been dropped by Debian already. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1674680 Title: Deprecated rfcomm.conf still mentioned Status in bluez package in Ubuntu: New Status in bluez source package in Xenial: New Status in bluez source package in Yakkety: New Bug description: [Impact] * The package contains misleading documentation mentioning the use of /etc/bluetooth/rfcomm.conf for rfcomm setup while the support for config file has been dropped after 14.04 release. I have directly received a question about it from a user mislead by the documentation. * Additionally deprecated -f option is still used in legacy upstart /etc/init/bluetooth.conf. Actually this does not seem longer required due to upstart being removed. [Test Case] * Install bluez. * Look for misleading rfcomm.conf mentions in /etc/init/bluetooth.conf, /usr/share/doc/bluez/README.Debian.gz [Regression Potential] * This is mostly a documentation correction, however if somebody still depends bluetooth started with Ubuntu 16.04+ by upstart (or possibly some kind of upstart compatibility in systemd, is that even possible?) he/she may end up with bluetooth not being started. This seems highly unlikely. [Other Info] * Original bug description: Support for config files has been dropped upstream in 2012 (however version shipped with Trusty still supports it), but the latest versions (including Xenial and Zesty) still mention it in the docs and in the legacy /etc/init/bluetooth.conf file. Additionally the /etc/init/bluetooth.conf don't seem necessary these days. In fact it has been dropped by Debian already. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1124250] Re: Partially incorrect uid mapping with nfs4/idmapd/ldap-auth
I believe this is the commit in question: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0b0a84154eff56913e91df29de5c3a03a0029e38 Looks like a good canditate for considering a cherry-pick. -- 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/1124250 Title: Partially incorrect uid mapping with nfs4/idmapd/ldap-auth Status in linux package in Ubuntu: Confirmed Status in nfs-utils package in Ubuntu: Confirmed Status in linux source package in Trusty: Won't Fix Status in nfs-utils source package in Trusty: Confirmed Status in linux source package in Utopic: Won't Fix Status in nfs-utils source package in Utopic: Confirmed Status in nfs-utils package in Debian: Incomplete Status in Fedora: Unknown Bug description: I'm running a nfs4 server exporting a directory /home (ext4,usrquota). This server is running Ubuntu 12.04 amd64(up-to-date). This directory is handling 662 homedirs for ldap authenticated users. /etc/exports is : /exports 192.168.0.0/24(rw,fsid=0,no_subtree_check) Important lines in /etc/idmapd.conf : domain=my-domain.org [Translation] Method=nsswitch. In /etc/default/nfs-common : NEED_IDMAPD=yes In /etc/default/nfs-kernel-server : RPCNFSDCOUNT=75 RPCMOUNTDOPTS=--manage-gids 2 Clients (rhel6 x86 & Ubuntu 12.04.2 i686) are mounting this nfs4 exported directory with no problems : When doing ls -l /home on this clients, I have : ... drwx-- 4 user100 oldusers 4096 sept. 21 2011 user100 drwx-- 4 user101 oldusers 4096 sept. 21 2011 user101 drwx-- 37 user102 oldusers 4096 oct. 1 19:06 user102 drwx-- 36 user103 users4096 févr. 5 21:08 user103 drwx-- 36 user104 users4096 févr. 8 14:03 user104 drwx-- 30 user105 users4096 févr. 4 18:01 user105 drwx-- 28 user106 oldusers 4096 oct. 5 2011 user106 drwx-- 37 user107 oldusers 4096 janv. 8 14:52 user107 drwx-- 31 user108 users4096 déc. 4 11:52 user108 drwx-- 4 user109 oldusers 4096 sept. 21 2011 user109 drwx--x--x 45 user110 oldusers 4096 janv. 22 15:53 user109 drwx-- 31 user111 users4096 janv. 29 12:03 user110 ... uid/gid mapping works fine, authldap works fine, ... All Clients running Ubuntu 12.10 i686 or Ubuntu 12.10 amd64 are experiencing the same problem : The config files are the same that used in ubuntu 12.04. Auth ldap is correctly configured, user can log in. This is the /etc/fstab entry for /home : 192.168.0.1:/ /home nfs rw,nfsvers=4 0 0 Important lines in /etc/idmapd.conf : domain=my-domain.org [Translation] Method=nsswitch In /etc/default/nfs-common : NEED_IDMAPD=yes /etc/nsswitch.conf is : passwd: files ldap group: files ldap shadow: files ldap When doing ls -l /home there is a strange problem : drwx-- 4 4294967294 oldusers 4096 sept. 21 2011 user100 drwx-- 4 user101oldusers 4096 sept. 21 2011 user101 drwx-- 37 user102oldusers 4096 oct. 1 19:06 user102 drwx-- 36 4294967294 users4096 févr. 5 21:08 user103 drwx-- 36 4294967294 users4096 févr. 8 14:03 user104 drwx-- 30 4294967294 users4096 févr. 4 18:01 user105 drwx-- 28 4294967294 oldusers 4096 oct. 5 2011 user106 drwx-- 37 4294967294 oldusers 4096 janv. 8 14:52 user107 drwx-- 31 4294967294 users4096 déc. 4 11:52 user108 drwx-- 4 user109oldusers 4096 sept. 21 2011 user109 drwx--x--x 45 4294967294 oldusers 4096 janv. 22 15:53 user110 drwx-- 31 4294967294 users4096 janv. 29 12:03 user111 for 571 homedirs (this number varies at each reboot)/662, the owner is the value 4294967294. For the 91 remaining homedirs, the owner is correct. The gidnumber is correctly mapped for all (only 5 differents values used for gidNumber). In /var/log/syslog, I can see : For example : user110 is mapped as 4294967294. but the command "id user110" returns : uid=31124(user110) gid=666(oldusers) groupes=666(oldusers) user110 logs in (auth ldap) from tty1. He runs "ls -l /home/user110/" : drwxr-xr-x 8 4294967294 oldusers 4096 janv. 19 2012 Bureau drwxr-xr-x 3 4294967294 oldusers 4096 déc. 2 2011 Documents drwxr-xr-x 2 4294967294 oldusers 4096 déc. 2 2011 Images Then, he runs "touch /home/user110/test" : drwxr-xr-x 8 4294967294 oldusers 4096 janv. 19 2012 Bureau drwxr-xr-x 3 4294967294 oldusers 4096 déc. 2 2011 Documents drwxr-xr-x 2 4294967294 oldusers 4096 déc. 2 2011 Images drwxr-xr-x 2 4294967294 oldusers0 févr. 13 16:01 test On the nfs server, If i do a ls -l in the same directory : drwxr-xr-x 8 user110 oldusers 4096 janv. 19 2012 Bureau drwxr-xr-x 3 user110 olduser
[Kernel-packages] [Bug 1124250] Re: Partially incorrect uid mapping with nfs4/idmapd/ldap-auth
Carl, I have backported the fixes to trusty kernel. Could you please give them a try in your environment? The build is available in my PPA (ppa:dgadomski/kernel-nfs). Thanks! -- 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/1124250 Title: Partially incorrect uid mapping with nfs4/idmapd/ldap-auth Status in linux package in Ubuntu: Confirmed Status in nfs-utils package in Ubuntu: Confirmed Status in linux source package in Trusty: Won't Fix Status in nfs-utils source package in Trusty: Confirmed Status in linux source package in Utopic: Won't Fix Status in nfs-utils source package in Utopic: Confirmed Status in nfs-utils package in Debian: Incomplete Status in Fedora: Unknown Bug description: I'm running a nfs4 server exporting a directory /home (ext4,usrquota). This server is running Ubuntu 12.04 amd64(up-to-date). This directory is handling 662 homedirs for ldap authenticated users. /etc/exports is : /exports 192.168.0.0/24(rw,fsid=0,no_subtree_check) Important lines in /etc/idmapd.conf : domain=my-domain.org [Translation] Method=nsswitch. In /etc/default/nfs-common : NEED_IDMAPD=yes In /etc/default/nfs-kernel-server : RPCNFSDCOUNT=75 RPCMOUNTDOPTS=--manage-gids 2 Clients (rhel6 x86 & Ubuntu 12.04.2 i686) are mounting this nfs4 exported directory with no problems : When doing ls -l /home on this clients, I have : ... drwx-- 4 user100 oldusers 4096 sept. 21 2011 user100 drwx-- 4 user101 oldusers 4096 sept. 21 2011 user101 drwx-- 37 user102 oldusers 4096 oct. 1 19:06 user102 drwx-- 36 user103 users4096 févr. 5 21:08 user103 drwx-- 36 user104 users4096 févr. 8 14:03 user104 drwx-- 30 user105 users4096 févr. 4 18:01 user105 drwx-- 28 user106 oldusers 4096 oct. 5 2011 user106 drwx-- 37 user107 oldusers 4096 janv. 8 14:52 user107 drwx-- 31 user108 users4096 déc. 4 11:52 user108 drwx-- 4 user109 oldusers 4096 sept. 21 2011 user109 drwx--x--x 45 user110 oldusers 4096 janv. 22 15:53 user109 drwx-- 31 user111 users4096 janv. 29 12:03 user110 ... uid/gid mapping works fine, authldap works fine, ... All Clients running Ubuntu 12.10 i686 or Ubuntu 12.10 amd64 are experiencing the same problem : The config files are the same that used in ubuntu 12.04. Auth ldap is correctly configured, user can log in. This is the /etc/fstab entry for /home : 192.168.0.1:/ /home nfs rw,nfsvers=4 0 0 Important lines in /etc/idmapd.conf : domain=my-domain.org [Translation] Method=nsswitch In /etc/default/nfs-common : NEED_IDMAPD=yes /etc/nsswitch.conf is : passwd: files ldap group: files ldap shadow: files ldap When doing ls -l /home there is a strange problem : drwx-- 4 4294967294 oldusers 4096 sept. 21 2011 user100 drwx-- 4 user101oldusers 4096 sept. 21 2011 user101 drwx-- 37 user102oldusers 4096 oct. 1 19:06 user102 drwx-- 36 4294967294 users4096 févr. 5 21:08 user103 drwx-- 36 4294967294 users4096 févr. 8 14:03 user104 drwx-- 30 4294967294 users4096 févr. 4 18:01 user105 drwx-- 28 4294967294 oldusers 4096 oct. 5 2011 user106 drwx-- 37 4294967294 oldusers 4096 janv. 8 14:52 user107 drwx-- 31 4294967294 users4096 déc. 4 11:52 user108 drwx-- 4 user109oldusers 4096 sept. 21 2011 user109 drwx--x--x 45 4294967294 oldusers 4096 janv. 22 15:53 user110 drwx-- 31 4294967294 users4096 janv. 29 12:03 user111 for 571 homedirs (this number varies at each reboot)/662, the owner is the value 4294967294. For the 91 remaining homedirs, the owner is correct. The gidnumber is correctly mapped for all (only 5 differents values used for gidNumber). In /var/log/syslog, I can see : For example : user110 is mapped as 4294967294. but the command "id user110" returns : uid=31124(user110) gid=666(oldusers) groupes=666(oldusers) user110 logs in (auth ldap) from tty1. He runs "ls -l /home/user110/" : drwxr-xr-x 8 4294967294 oldusers 4096 janv. 19 2012 Bureau drwxr-xr-x 3 4294967294 oldusers 4096 déc. 2 2011 Documents drwxr-xr-x 2 4294967294 oldusers 4096 déc. 2 2011 Images Then, he runs "touch /home/user110/test" : drwxr-xr-x 8 4294967294 oldusers 4096 janv. 19 2012 Bureau drwxr-xr-x 3 4294967294 oldusers 4096 déc. 2 2011 Documents drwxr-xr-x 2 4294967294 oldusers 4096 déc. 2 2011 Images drwxr-xr-x 2 4294967294 oldusers0 févr. 13 16:01 test On the nfs server, If i do a ls -l in the same directory : drwxr-xr-x 8 user110 oldusers 4096 janv. 19 2012 Bureau drwxr-xr-x 3 user110 oldusers 4096 déc. 2 2011 Documents drwxr-
[Kernel-packages] [Bug 1124250] Re: Partially incorrect uid mapping with nfs4/idmapd/ldap-auth
Hello Bryan, The commit that has fixed this was https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=738c5d190f6540539a04baf36ce21d46b5da04bd I think we can make use of it. -- 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/1124250 Title: Partially incorrect uid mapping with nfs4/idmapd/ldap-auth Status in “linux” package in Ubuntu: Confirmed Status in “nfs-utils” package in Ubuntu: Confirmed Status in “linux” source package in Trusty: Won't Fix Status in “nfs-utils” source package in Trusty: Confirmed Status in “linux” source package in Utopic: Won't Fix Status in “nfs-utils” source package in Utopic: Confirmed Status in “nfs-utils” package in Debian: Incomplete Status in Fedora: Unknown Bug description: I'm running a nfs4 server exporting a directory /home (ext4,usrquota). This server is running Ubuntu 12.04 amd64(up-to-date). This directory is handling 662 homedirs for ldap authenticated users. /etc/exports is : /exports 192.168.0.0/24(rw,fsid=0,no_subtree_check) Important lines in /etc/idmapd.conf : domain=my-domain.org [Translation] Method=nsswitch. In /etc/default/nfs-common : NEED_IDMAPD=yes In /etc/default/nfs-kernel-server : RPCNFSDCOUNT=75 RPCMOUNTDOPTS=--manage-gids 2 Clients (rhel6 x86 & Ubuntu 12.04.2 i686) are mounting this nfs4 exported directory with no problems : When doing ls -l /home on this clients, I have : ... drwx-- 4 user100 oldusers 4096 sept. 21 2011 user100 drwx-- 4 user101 oldusers 4096 sept. 21 2011 user101 drwx-- 37 user102 oldusers 4096 oct. 1 19:06 user102 drwx-- 36 user103 users4096 févr. 5 21:08 user103 drwx-- 36 user104 users4096 févr. 8 14:03 user104 drwx-- 30 user105 users4096 févr. 4 18:01 user105 drwx-- 28 user106 oldusers 4096 oct. 5 2011 user106 drwx-- 37 user107 oldusers 4096 janv. 8 14:52 user107 drwx-- 31 user108 users4096 déc. 4 11:52 user108 drwx-- 4 user109 oldusers 4096 sept. 21 2011 user109 drwx--x--x 45 user110 oldusers 4096 janv. 22 15:53 user109 drwx-- 31 user111 users4096 janv. 29 12:03 user110 ... uid/gid mapping works fine, authldap works fine, ... All Clients running Ubuntu 12.10 i686 or Ubuntu 12.10 amd64 are experiencing the same problem : The config files are the same that used in ubuntu 12.04. Auth ldap is correctly configured, user can log in. This is the /etc/fstab entry for /home : 192.168.0.1:/ /home nfs rw,nfsvers=4 0 0 Important lines in /etc/idmapd.conf : domain=my-domain.org [Translation] Method=nsswitch In /etc/default/nfs-common : NEED_IDMAPD=yes /etc/nsswitch.conf is : passwd: files ldap group: files ldap shadow: files ldap When doing ls -l /home there is a strange problem : drwx-- 4 4294967294 oldusers 4096 sept. 21 2011 user100 drwx-- 4 user101oldusers 4096 sept. 21 2011 user101 drwx-- 37 user102oldusers 4096 oct. 1 19:06 user102 drwx-- 36 4294967294 users4096 févr. 5 21:08 user103 drwx-- 36 4294967294 users4096 févr. 8 14:03 user104 drwx-- 30 4294967294 users4096 févr. 4 18:01 user105 drwx-- 28 4294967294 oldusers 4096 oct. 5 2011 user106 drwx-- 37 4294967294 oldusers 4096 janv. 8 14:52 user107 drwx-- 31 4294967294 users4096 déc. 4 11:52 user108 drwx-- 4 user109oldusers 4096 sept. 21 2011 user109 drwx--x--x 45 4294967294 oldusers 4096 janv. 22 15:53 user110 drwx-- 31 4294967294 users4096 janv. 29 12:03 user111 for 571 homedirs (this number varies at each reboot)/662, the owner is the value 4294967294. For the 91 remaining homedirs, the owner is correct. The gidnumber is correctly mapped for all (only 5 differents values used for gidNumber). In /var/log/syslog, I can see : For example : user110 is mapped as 4294967294. but the command "id user110" returns : uid=31124(user110) gid=666(oldusers) groupes=666(oldusers) user110 logs in (auth ldap) from tty1. He runs "ls -l /home/user110/" : drwxr-xr-x 8 4294967294 oldusers 4096 janv. 19 2012 Bureau drwxr-xr-x 3 4294967294 oldusers 4096 déc. 2 2011 Documents drwxr-xr-x 2 4294967294 oldusers 4096 déc. 2 2011 Images Then, he runs "touch /home/user110/test" : drwxr-xr-x 8 4294967294 oldusers 4096 janv. 19 2012 Bureau drwxr-xr-x 3 4294967294 oldusers 4096 déc. 2 2011 Documents drwxr-xr-x 2 4294967294 oldusers 4096 déc. 2 2011 Images drwxr-xr-x 2 4294967294 oldusers0 févr. 13 16:01 test On the nfs server, If i do a ls -l in the same directory : drwxr-xr-x 8 user110 oldusers 4096 janv. 19 2012 Bureau drwxr-xr-x 3 user110 oldusers 4096
[Kernel-packages] [Bug 1124250] Re: Partially incorrect uid mapping with nfs4/idmapd/ldap-auth
@Bryan Yes, you're right. It should hit vivid and since it is already configurable by sysctl there is no point in backporting. -- 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/1124250 Title: Partially incorrect uid mapping with nfs4/idmapd/ldap-auth Status in “linux” package in Ubuntu: Confirmed Status in “nfs-utils” package in Ubuntu: Confirmed Status in “linux” source package in Trusty: Won't Fix Status in “nfs-utils” source package in Trusty: Confirmed Status in “linux” source package in Utopic: Won't Fix Status in “nfs-utils” source package in Utopic: Confirmed Status in “nfs-utils” package in Debian: Incomplete Status in Fedora: Unknown Bug description: I'm running a nfs4 server exporting a directory /home (ext4,usrquota). This server is running Ubuntu 12.04 amd64(up-to-date). This directory is handling 662 homedirs for ldap authenticated users. /etc/exports is : /exports 192.168.0.0/24(rw,fsid=0,no_subtree_check) Important lines in /etc/idmapd.conf : domain=my-domain.org [Translation] Method=nsswitch. In /etc/default/nfs-common : NEED_IDMAPD=yes In /etc/default/nfs-kernel-server : RPCNFSDCOUNT=75 RPCMOUNTDOPTS=--manage-gids 2 Clients (rhel6 x86 & Ubuntu 12.04.2 i686) are mounting this nfs4 exported directory with no problems : When doing ls -l /home on this clients, I have : ... drwx-- 4 user100 oldusers 4096 sept. 21 2011 user100 drwx-- 4 user101 oldusers 4096 sept. 21 2011 user101 drwx-- 37 user102 oldusers 4096 oct. 1 19:06 user102 drwx-- 36 user103 users4096 févr. 5 21:08 user103 drwx-- 36 user104 users4096 févr. 8 14:03 user104 drwx-- 30 user105 users4096 févr. 4 18:01 user105 drwx-- 28 user106 oldusers 4096 oct. 5 2011 user106 drwx-- 37 user107 oldusers 4096 janv. 8 14:52 user107 drwx-- 31 user108 users4096 déc. 4 11:52 user108 drwx-- 4 user109 oldusers 4096 sept. 21 2011 user109 drwx--x--x 45 user110 oldusers 4096 janv. 22 15:53 user109 drwx-- 31 user111 users4096 janv. 29 12:03 user110 ... uid/gid mapping works fine, authldap works fine, ... All Clients running Ubuntu 12.10 i686 or Ubuntu 12.10 amd64 are experiencing the same problem : The config files are the same that used in ubuntu 12.04. Auth ldap is correctly configured, user can log in. This is the /etc/fstab entry for /home : 192.168.0.1:/ /home nfs rw,nfsvers=4 0 0 Important lines in /etc/idmapd.conf : domain=my-domain.org [Translation] Method=nsswitch In /etc/default/nfs-common : NEED_IDMAPD=yes /etc/nsswitch.conf is : passwd: files ldap group: files ldap shadow: files ldap When doing ls -l /home there is a strange problem : drwx-- 4 4294967294 oldusers 4096 sept. 21 2011 user100 drwx-- 4 user101oldusers 4096 sept. 21 2011 user101 drwx-- 37 user102oldusers 4096 oct. 1 19:06 user102 drwx-- 36 4294967294 users4096 févr. 5 21:08 user103 drwx-- 36 4294967294 users4096 févr. 8 14:03 user104 drwx-- 30 4294967294 users4096 févr. 4 18:01 user105 drwx-- 28 4294967294 oldusers 4096 oct. 5 2011 user106 drwx-- 37 4294967294 oldusers 4096 janv. 8 14:52 user107 drwx-- 31 4294967294 users4096 déc. 4 11:52 user108 drwx-- 4 user109oldusers 4096 sept. 21 2011 user109 drwx--x--x 45 4294967294 oldusers 4096 janv. 22 15:53 user110 drwx-- 31 4294967294 users4096 janv. 29 12:03 user111 for 571 homedirs (this number varies at each reboot)/662, the owner is the value 4294967294. For the 91 remaining homedirs, the owner is correct. The gidnumber is correctly mapped for all (only 5 differents values used for gidNumber). In /var/log/syslog, I can see : For example : user110 is mapped as 4294967294. but the command "id user110" returns : uid=31124(user110) gid=666(oldusers) groupes=666(oldusers) user110 logs in (auth ldap) from tty1. He runs "ls -l /home/user110/" : drwxr-xr-x 8 4294967294 oldusers 4096 janv. 19 2012 Bureau drwxr-xr-x 3 4294967294 oldusers 4096 déc. 2 2011 Documents drwxr-xr-x 2 4294967294 oldusers 4096 déc. 2 2011 Images Then, he runs "touch /home/user110/test" : drwxr-xr-x 8 4294967294 oldusers 4096 janv. 19 2012 Bureau drwxr-xr-x 3 4294967294 oldusers 4096 déc. 2 2011 Documents drwxr-xr-x 2 4294967294 oldusers 4096 déc. 2 2011 Images drwxr-xr-x 2 4294967294 oldusers0 févr. 13 16:01 test On the nfs server, If i do a ls -l in the same directory : drwxr-xr-x 8 user110 oldusers 4096 janv. 19 2012 Bureau drwxr-xr-x 3 user110 oldusers 4096 déc. 2 2011 Documents drwxr-xr-x 2 user110 oldusers 4096 déc.
[Kernel-packages] [Bug 1386781] [NEW] Failure initializing radeon (as /dev/card1) renderer: unexpectedly disconnected from boot status daemon
Public bug reported:
Log from a failed run.
In a setup as follows:
1. Ubuntu 14.04 booting from a live CD with updated plymouth (0.9.0 from
https://launchpad.net/~xnox/+archive/ubuntu/backports)
2. Hardware is an iMac 12,1 with an integrated intel (/dev/card0) and a
discrete radeon (/dev/card1). The display is connected to the radeon and a
prompt for an disk encryption password is needed.
Expected results:
A password prompt should be displayed on each display (including the main
display connected to the radeon).
Actual result:
On the only display connected to radeon right after leaving GRUB all what may
be seen is:
error: unexpectedly disconnected from boot status daemon
/dev/loop0: UUID="" TYPE="crypto_LUKS"
According to the plymouth changelog it should have been fixed by
https://bugs.freedesktop.org/show_bug.cgi?id=25943
(http://cgit.freedesktop.org/plymouth/commit/?id=e982dc255c0f471e67eb7bd0858c170d103d39ce)
but according to the plymouth debug log (attached) radeon fails to open.
** Affects: plymouth
Importance: Unknown
Status: Unknown
** Affects: plymouth (Ubuntu)
Importance: Undecided
Assignee: Dariusz Gadomski (dgadomski)
Status: New
** Tags: cts
** Attachment added: "plymouth-debug.log"
https://bugs.launchpad.net/bugs/1386781/+attachment/4247247/+files/plymouth-debug.log
** Bug watch added: freedesktop.org Bugzilla #85522
https://bugs.freedesktop.org/show_bug.cgi?id=85522
** Also affects: linux via
https://bugs.freedesktop.org/show_bug.cgi?id=85522
Importance: Unknown
Status: Unknown
** Project changed: linux => plymouth
** Package changed: linux (Ubuntu) => plymouth (Ubuntu)
** Changed in: plymouth (Ubuntu)
Assignee: (unassigned) => Dariusz Gadomski (dgadomski)
--
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/1386781
Title:
Failure initializing radeon (as /dev/card1) renderer: unexpectedly
disconnected from boot status daemon
Status in The Plymouth splash screen:
Unknown
Status in “plymouth” package in Ubuntu:
New
Bug description:
Log from a failed run.
In a setup as follows:
1. Ubuntu 14.04 booting from a live CD with updated plymouth (0.9.0 from
https://launchpad.net/~xnox/+archive/ubuntu/backports)
2. Hardware is an iMac 12,1 with an integrated intel (/dev/card0) and a
discrete radeon (/dev/card1). The display is connected to the radeon and a
prompt for an disk encryption password is needed.
Expected results:
A password prompt should be displayed on each display (including the main
display connected to the radeon).
Actual result:
On the only display connected to radeon right after leaving GRUB all what may
be seen is:
error: unexpectedly disconnected from boot status daemon
/dev/loop0: UUID="" TYPE="crypto_LUKS"
According to the plymouth changelog it should have been fixed by
https://bugs.freedesktop.org/show_bug.cgi?id=25943
(http://cgit.freedesktop.org/plymouth/commit/?id=e982dc255c0f471e67eb7bd0858c170d103d39ce)
but according to the plymouth debug log (attached) radeon fails to open.
To manage notifications about this bug go to:
https://bugs.launchpad.net/plymouth/+bug/1386781/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1124250] Re: Partially incorrect uid mapping with nfs4/idmapd/ldap-auth
The fix has been tagged as: - Ubuntu-3.13.0-50.82 for Trusty - Ubuntu-3.16.0-35.46 for Utopic I don't see those version available in -updates yet, so please give it some more time to be release. Thanks! -- 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/1124250 Title: Partially incorrect uid mapping with nfs4/idmapd/ldap-auth Status in linux package in Ubuntu: Fix Released Status in linux source package in Trusty: Fix Committed Status in linux source package in Utopic: Fix Committed Status in nfs-utils package in Debian: Fix Released Status in Fedora: Unknown Bug description: [Impact] * This bug is likely to cause an incorrect UID/GID mapping for NFS shares in case of large numbers of differend UIDs/GIDs or in case of expired UID/GID mappings (stored as keys in the kernel). [Test Case] 1. Setup a nfs4 server exporting /home with a large number of different users and ldap-based authentication. 2. Mount the share on a ldap-connected client machine. 3. List the mounted /home directory. 4. Wait more than 10 minutes (the default key expiration time) and list it again with ls -l. Expected result - all directories are listed with correct UIDs/GIDs. Actual result - some of the directories may be listed with incorrect UID/GID of 4294967294. [Regression Potential] * This issue has been merged upstream in the 3.18 kernel and is also present in Debian's 3.16 kernel. [Other Info] * Original bug description: I'm running a nfs4 server exporting a directory /home (ext4,usrquota). This server is running Ubuntu 12.04 amd64(up-to-date). This directory is handling 662 homedirs for ldap authenticated users. /etc/exports is : /exports 192.168.0.0/24(rw,fsid=0,no_subtree_check) Important lines in /etc/idmapd.conf : domain=my-domain.org [Translation] Method=nsswitch. In /etc/default/nfs-common : NEED_IDMAPD=yes In /etc/default/nfs-kernel-server : RPCNFSDCOUNT=75 RPCMOUNTDOPTS=--manage-gids 2 Clients (rhel6 x86 & Ubuntu 12.04.2 i686) are mounting this nfs4 exported directory with no problems : When doing ls -l /home on this clients, I have : ... drwx-- 4 user100 oldusers 4096 sept. 21 2011 user100 drwx-- 4 user101 oldusers 4096 sept. 21 2011 user101 drwx-- 37 user102 oldusers 4096 oct. 1 19:06 user102 drwx-- 36 user103 users4096 févr. 5 21:08 user103 drwx-- 36 user104 users4096 févr. 8 14:03 user104 drwx-- 30 user105 users4096 févr. 4 18:01 user105 drwx-- 28 user106 oldusers 4096 oct. 5 2011 user106 drwx-- 37 user107 oldusers 4096 janv. 8 14:52 user107 drwx-- 31 user108 users4096 déc. 4 11:52 user108 drwx-- 4 user109 oldusers 4096 sept. 21 2011 user109 drwx--x--x 45 user110 oldusers 4096 janv. 22 15:53 user109 drwx-- 31 user111 users4096 janv. 29 12:03 user110 ... uid/gid mapping works fine, authldap works fine, ... All Clients running Ubuntu 12.10 i686 or Ubuntu 12.10 amd64 are experiencing the same problem : The config files are the same that used in ubuntu 12.04. Auth ldap is correctly configured, user can log in. This is the /etc/fstab entry for /home : 192.168.0.1:/ /home nfs rw,nfsvers=4 0 0 Important lines in /etc/idmapd.conf : domain=my-domain.org [Translation] Method=nsswitch In /etc/default/nfs-common : NEED_IDMAPD=yes /etc/nsswitch.conf is : passwd: files ldap group: files ldap shadow: files ldap When doing ls -l /home there is a strange problem : drwx-- 4 4294967294 oldusers 4096 sept. 21 2011 user100 drwx-- 4 user101oldusers 4096 sept. 21 2011 user101 drwx-- 37 user102oldusers 4096 oct. 1 19:06 user102 drwx-- 36 4294967294 users4096 févr. 5 21:08 user103 drwx-- 36 4294967294 users4096 févr. 8 14:03 user104 drwx-- 30 4294967294 users4096 févr. 4 18:01 user105 drwx-- 28 4294967294 oldusers 4096 oct. 5 2011 user106 drwx-- 37 4294967294 oldusers 4096 janv. 8 14:52 user107 drwx-- 31 4294967294 users4096 déc. 4 11:52 user108 drwx-- 4 user109oldusers 4096 sept. 21 2011 user109 drwx--x--x 45 4294967294 oldusers 4096 janv. 22 15:53 user110 drwx-- 31 4294967294 users4096 janv. 29 12:03 user111 for 571 homedirs (this number varies at each reboot)/662, the owner is the value 4294967294. For the 91 remaining homedirs, the owner is correct. The gidnumber is correctly mapped for all (only 5 differents values used for gidNumber). In /var/log/syslog, I can see : For example : user110 is mapped as 4294967294. but the command "id user110" returns : uid=31124(user110) gid=666(oldusers) groupes=666(oldusers) u
[Kernel-packages] [Bug 1124250] Re: Partially incorrect uid mapping with nfs4/idmapd/ldap-auth
stef: can you please check after you observe the problem if your key quota is not exceeded? You may do this with: $ sudo cat /proc/key-users This fix is known to solve the expired keys problem, but if the cause of the issue you are experiencing is the capacity of the key quota you may have to extend it (please see comment #2). Thanks! -- 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/1124250 Title: Partially incorrect uid mapping with nfs4/idmapd/ldap-auth Status in linux package in Ubuntu: Fix Released Status in linux source package in Trusty: Fix Committed Status in linux source package in Utopic: Fix Committed Status in nfs-utils package in Debian: Fix Released Status in Fedora: Unknown Bug description: [Impact] * This bug is likely to cause an incorrect UID/GID mapping for NFS shares in case of large numbers of differend UIDs/GIDs or in case of expired UID/GID mappings (stored as keys in the kernel). [Test Case] 1. Setup a nfs4 server exporting /home with a large number of different users and ldap-based authentication. 2. Mount the share on a ldap-connected client machine. 3. List the mounted /home directory. 4. Wait more than 10 minutes (the default key expiration time) and list it again with ls -l. Expected result - all directories are listed with correct UIDs/GIDs. Actual result - some of the directories may be listed with incorrect UID/GID of 4294967294. [Regression Potential] * This issue has been merged upstream in the 3.18 kernel and is also present in Debian's 3.16 kernel. [Other Info] * Original bug description: I'm running a nfs4 server exporting a directory /home (ext4,usrquota). This server is running Ubuntu 12.04 amd64(up-to-date). This directory is handling 662 homedirs for ldap authenticated users. /etc/exports is : /exports 192.168.0.0/24(rw,fsid=0,no_subtree_check) Important lines in /etc/idmapd.conf : domain=my-domain.org [Translation] Method=nsswitch. In /etc/default/nfs-common : NEED_IDMAPD=yes In /etc/default/nfs-kernel-server : RPCNFSDCOUNT=75 RPCMOUNTDOPTS=--manage-gids 2 Clients (rhel6 x86 & Ubuntu 12.04.2 i686) are mounting this nfs4 exported directory with no problems : When doing ls -l /home on this clients, I have : ... drwx-- 4 user100 oldusers 4096 sept. 21 2011 user100 drwx-- 4 user101 oldusers 4096 sept. 21 2011 user101 drwx-- 37 user102 oldusers 4096 oct. 1 19:06 user102 drwx-- 36 user103 users4096 févr. 5 21:08 user103 drwx-- 36 user104 users4096 févr. 8 14:03 user104 drwx-- 30 user105 users4096 févr. 4 18:01 user105 drwx-- 28 user106 oldusers 4096 oct. 5 2011 user106 drwx-- 37 user107 oldusers 4096 janv. 8 14:52 user107 drwx-- 31 user108 users4096 déc. 4 11:52 user108 drwx-- 4 user109 oldusers 4096 sept. 21 2011 user109 drwx--x--x 45 user110 oldusers 4096 janv. 22 15:53 user109 drwx-- 31 user111 users4096 janv. 29 12:03 user110 ... uid/gid mapping works fine, authldap works fine, ... All Clients running Ubuntu 12.10 i686 or Ubuntu 12.10 amd64 are experiencing the same problem : The config files are the same that used in ubuntu 12.04. Auth ldap is correctly configured, user can log in. This is the /etc/fstab entry for /home : 192.168.0.1:/ /home nfs rw,nfsvers=4 0 0 Important lines in /etc/idmapd.conf : domain=my-domain.org [Translation] Method=nsswitch In /etc/default/nfs-common : NEED_IDMAPD=yes /etc/nsswitch.conf is : passwd: files ldap group: files ldap shadow: files ldap When doing ls -l /home there is a strange problem : drwx-- 4 4294967294 oldusers 4096 sept. 21 2011 user100 drwx-- 4 user101oldusers 4096 sept. 21 2011 user101 drwx-- 37 user102oldusers 4096 oct. 1 19:06 user102 drwx-- 36 4294967294 users4096 févr. 5 21:08 user103 drwx-- 36 4294967294 users4096 févr. 8 14:03 user104 drwx-- 30 4294967294 users4096 févr. 4 18:01 user105 drwx-- 28 4294967294 oldusers 4096 oct. 5 2011 user106 drwx-- 37 4294967294 oldusers 4096 janv. 8 14:52 user107 drwx-- 31 4294967294 users4096 déc. 4 11:52 user108 drwx-- 4 user109oldusers 4096 sept. 21 2011 user109 drwx--x--x 45 4294967294 oldusers 4096 janv. 22 15:53 user110 drwx-- 31 4294967294 users4096 janv. 29 12:03 user111 for 571 homedirs (this number varies at each reboot)/662, the owner is the value 4294967294. For the 91 remaining homedirs, the owner is correct. The gidnumber is correctly mapped for all (only 5 differents values used for gidNumber). In /var/log/syslog, I can see : For example : use
[Kernel-packages] [Bug 1124250] Re: Partially incorrect uid mapping with nfs4/idmapd/ldap-auth
Stef, thanks for the update. Can you please confirm that you have upgraded your kernel to version 3.13.0-51.84 or later? This is the first release that has this fix. The version you mentioned earlier (3.13.0.51.44) is expected to be still affected by this bug. Thank you. -- 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/1124250 Title: Partially incorrect uid mapping with nfs4/idmapd/ldap-auth Status in linux package in Ubuntu: Fix Released Status in linux source package in Trusty: Fix Released Status in linux source package in Utopic: Fix Released Status in nfs-utils package in Debian: Fix Released Status in Fedora: Unknown Bug description: [Impact] * This bug is likely to cause an incorrect UID/GID mapping for NFS shares in case of large numbers of differend UIDs/GIDs or in case of expired UID/GID mappings (stored as keys in the kernel). [Test Case] 1. Setup a nfs4 server exporting /home with a large number of different users and ldap-based authentication. 2. Mount the share on a ldap-connected client machine. 3. List the mounted /home directory. 4. Wait more than 10 minutes (the default key expiration time) and list it again with ls -l. Expected result - all directories are listed with correct UIDs/GIDs. Actual result - some of the directories may be listed with incorrect UID/GID of 4294967294. [Regression Potential] * This issue has been merged upstream in the 3.18 kernel and is also present in Debian's 3.16 kernel. [Other Info] * Original bug description: I'm running a nfs4 server exporting a directory /home (ext4,usrquota). This server is running Ubuntu 12.04 amd64(up-to-date). This directory is handling 662 homedirs for ldap authenticated users. /etc/exports is : /exports 192.168.0.0/24(rw,fsid=0,no_subtree_check) Important lines in /etc/idmapd.conf : domain=my-domain.org [Translation] Method=nsswitch. In /etc/default/nfs-common : NEED_IDMAPD=yes In /etc/default/nfs-kernel-server : RPCNFSDCOUNT=75 RPCMOUNTDOPTS=--manage-gids 2 Clients (rhel6 x86 & Ubuntu 12.04.2 i686) are mounting this nfs4 exported directory with no problems : When doing ls -l /home on this clients, I have : ... drwx-- 4 user100 oldusers 4096 sept. 21 2011 user100 drwx-- 4 user101 oldusers 4096 sept. 21 2011 user101 drwx-- 37 user102 oldusers 4096 oct. 1 19:06 user102 drwx-- 36 user103 users4096 févr. 5 21:08 user103 drwx-- 36 user104 users4096 févr. 8 14:03 user104 drwx-- 30 user105 users4096 févr. 4 18:01 user105 drwx-- 28 user106 oldusers 4096 oct. 5 2011 user106 drwx-- 37 user107 oldusers 4096 janv. 8 14:52 user107 drwx-- 31 user108 users4096 déc. 4 11:52 user108 drwx-- 4 user109 oldusers 4096 sept. 21 2011 user109 drwx--x--x 45 user110 oldusers 4096 janv. 22 15:53 user109 drwx-- 31 user111 users4096 janv. 29 12:03 user110 ... uid/gid mapping works fine, authldap works fine, ... All Clients running Ubuntu 12.10 i686 or Ubuntu 12.10 amd64 are experiencing the same problem : The config files are the same that used in ubuntu 12.04. Auth ldap is correctly configured, user can log in. This is the /etc/fstab entry for /home : 192.168.0.1:/ /home nfs rw,nfsvers=4 0 0 Important lines in /etc/idmapd.conf : domain=my-domain.org [Translation] Method=nsswitch In /etc/default/nfs-common : NEED_IDMAPD=yes /etc/nsswitch.conf is : passwd: files ldap group: files ldap shadow: files ldap When doing ls -l /home there is a strange problem : drwx-- 4 4294967294 oldusers 4096 sept. 21 2011 user100 drwx-- 4 user101oldusers 4096 sept. 21 2011 user101 drwx-- 37 user102oldusers 4096 oct. 1 19:06 user102 drwx-- 36 4294967294 users4096 févr. 5 21:08 user103 drwx-- 36 4294967294 users4096 févr. 8 14:03 user104 drwx-- 30 4294967294 users4096 févr. 4 18:01 user105 drwx-- 28 4294967294 oldusers 4096 oct. 5 2011 user106 drwx-- 37 4294967294 oldusers 4096 janv. 8 14:52 user107 drwx-- 31 4294967294 users4096 déc. 4 11:52 user108 drwx-- 4 user109oldusers 4096 sept. 21 2011 user109 drwx--x--x 45 4294967294 oldusers 4096 janv. 22 15:53 user110 drwx-- 31 4294967294 users4096 janv. 29 12:03 user111 for 571 homedirs (this number varies at each reboot)/662, the owner is the value 4294967294. For the 91 remaining homedirs, the owner is correct. The gidnumber is correctly mapped for all (only 5 differents values used for gidNumber). In /var/log/syslog, I can see : For example : user110 is mapped as 4294967294. but the command "id user110" return
[Kernel-packages] [Bug 1124250] Re: Partially incorrect uid mapping with nfs4/idmapd/ldap-auth
Thank you Stef. I have verified the fix on trusty with trusty kernel. I will try to set up a precise environment with trusty kernel and reproduce this issue. -- 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/1124250 Title: Partially incorrect uid mapping with nfs4/idmapd/ldap-auth Status in linux package in Ubuntu: Fix Released Status in linux source package in Trusty: Fix Released Status in linux source package in Utopic: Fix Released Status in nfs-utils package in Debian: Fix Released Status in Fedora: Unknown Bug description: [Impact] * This bug is likely to cause an incorrect UID/GID mapping for NFS shares in case of large numbers of differend UIDs/GIDs or in case of expired UID/GID mappings (stored as keys in the kernel). [Test Case] 1. Setup a nfs4 server exporting /home with a large number of different users and ldap-based authentication. 2. Mount the share on a ldap-connected client machine. 3. List the mounted /home directory. 4. Wait more than 10 minutes (the default key expiration time) and list it again with ls -l. Expected result - all directories are listed with correct UIDs/GIDs. Actual result - some of the directories may be listed with incorrect UID/GID of 4294967294. [Regression Potential] * This issue has been merged upstream in the 3.18 kernel and is also present in Debian's 3.16 kernel. [Other Info] * Original bug description: I'm running a nfs4 server exporting a directory /home (ext4,usrquota). This server is running Ubuntu 12.04 amd64(up-to-date). This directory is handling 662 homedirs for ldap authenticated users. /etc/exports is : /exports 192.168.0.0/24(rw,fsid=0,no_subtree_check) Important lines in /etc/idmapd.conf : domain=my-domain.org [Translation] Method=nsswitch. In /etc/default/nfs-common : NEED_IDMAPD=yes In /etc/default/nfs-kernel-server : RPCNFSDCOUNT=75 RPCMOUNTDOPTS=--manage-gids 2 Clients (rhel6 x86 & Ubuntu 12.04.2 i686) are mounting this nfs4 exported directory with no problems : When doing ls -l /home on this clients, I have : ... drwx-- 4 user100 oldusers 4096 sept. 21 2011 user100 drwx-- 4 user101 oldusers 4096 sept. 21 2011 user101 drwx-- 37 user102 oldusers 4096 oct. 1 19:06 user102 drwx-- 36 user103 users4096 févr. 5 21:08 user103 drwx-- 36 user104 users4096 févr. 8 14:03 user104 drwx-- 30 user105 users4096 févr. 4 18:01 user105 drwx-- 28 user106 oldusers 4096 oct. 5 2011 user106 drwx-- 37 user107 oldusers 4096 janv. 8 14:52 user107 drwx-- 31 user108 users4096 déc. 4 11:52 user108 drwx-- 4 user109 oldusers 4096 sept. 21 2011 user109 drwx--x--x 45 user110 oldusers 4096 janv. 22 15:53 user109 drwx-- 31 user111 users4096 janv. 29 12:03 user110 ... uid/gid mapping works fine, authldap works fine, ... All Clients running Ubuntu 12.10 i686 or Ubuntu 12.10 amd64 are experiencing the same problem : The config files are the same that used in ubuntu 12.04. Auth ldap is correctly configured, user can log in. This is the /etc/fstab entry for /home : 192.168.0.1:/ /home nfs rw,nfsvers=4 0 0 Important lines in /etc/idmapd.conf : domain=my-domain.org [Translation] Method=nsswitch In /etc/default/nfs-common : NEED_IDMAPD=yes /etc/nsswitch.conf is : passwd: files ldap group: files ldap shadow: files ldap When doing ls -l /home there is a strange problem : drwx-- 4 4294967294 oldusers 4096 sept. 21 2011 user100 drwx-- 4 user101oldusers 4096 sept. 21 2011 user101 drwx-- 37 user102oldusers 4096 oct. 1 19:06 user102 drwx-- 36 4294967294 users4096 févr. 5 21:08 user103 drwx-- 36 4294967294 users4096 févr. 8 14:03 user104 drwx-- 30 4294967294 users4096 févr. 4 18:01 user105 drwx-- 28 4294967294 oldusers 4096 oct. 5 2011 user106 drwx-- 37 4294967294 oldusers 4096 janv. 8 14:52 user107 drwx-- 31 4294967294 users4096 déc. 4 11:52 user108 drwx-- 4 user109oldusers 4096 sept. 21 2011 user109 drwx--x--x 45 4294967294 oldusers 4096 janv. 22 15:53 user110 drwx-- 31 4294967294 users4096 janv. 29 12:03 user111 for 571 homedirs (this number varies at each reboot)/662, the owner is the value 4294967294. For the 91 remaining homedirs, the owner is correct. The gidnumber is correctly mapped for all (only 5 differents values used for gidNumber). In /var/log/syslog, I can see : For example : user110 is mapped as 4294967294. but the command "id user110" returns : uid=31124(user110) gid=666(oldusers) groupes=666(oldusers) user110 logs in (auth ldap) from tty1. He runs "ls
[Kernel-packages] [Bug 1124250] Re: Partially incorrect uid mapping with nfs4/idmapd/ldap-auth
** Description changed: + [Impact] + + * This bug is likely to cause an incorrect UID/GID mapping for NFS + shares in case of large numbers of differend UIDs/GIDs or in case of + expired UID/GID mappings (stored as keys in the kernel). + + [Test Case] + + 1. Setup a nfs4 server exporting /home with a large number of different users and ldap-based authentication. + 2. Mount the share on a ldap-connected client machine. + 3. List the mounted /home directory. + 4. Wait more than 10 minutes (the default key expiration time) and list it again with ls -l. + + Expected result - all directories are listed with correct UIDs/GIDs. + Actual result - some of the directories may be listed with incorrect UID/GID of 4294967294. + + [Regression Potential] + + * This issue has been merged upstream in the 3.18 kernel and is also + present in Debian's 3.16 kernel. + + [Other Info] + + * Original bug description: + I'm running a nfs4 server exporting a directory /home (ext4,usrquota). This server is running Ubuntu 12.04 amd64(up-to-date). This directory is handling 662 homedirs for ldap authenticated users. /etc/exports is : /exports 192.168.0.0/24(rw,fsid=0,no_subtree_check) Important lines in /etc/idmapd.conf : domain=my-domain.org [Translation] Method=nsswitch. In /etc/default/nfs-common : NEED_IDMAPD=yes In /etc/default/nfs-kernel-server : RPCNFSDCOUNT=75 RPCMOUNTDOPTS=--manage-gids 2 Clients (rhel6 x86 & Ubuntu 12.04.2 i686) are mounting this nfs4 exported directory with no problems : When doing ls -l /home on this clients, I have : ... drwx-- 4 user100 oldusers 4096 sept. 21 2011 user100 drwx-- 4 user101 oldusers 4096 sept. 21 2011 user101 drwx-- 37 user102 oldusers 4096 oct. 1 19:06 user102 drwx-- 36 user103 users4096 févr. 5 21:08 user103 drwx-- 36 user104 users4096 févr. 8 14:03 user104 drwx-- 30 user105 users4096 févr. 4 18:01 user105 drwx-- 28 user106 oldusers 4096 oct. 5 2011 user106 drwx-- 37 user107 oldusers 4096 janv. 8 14:52 user107 drwx-- 31 user108 users4096 déc. 4 11:52 user108 drwx-- 4 user109 oldusers 4096 sept. 21 2011 user109 drwx--x--x 45 user110 oldusers 4096 janv. 22 15:53 user109 drwx-- 31 user111 users4096 janv. 29 12:03 user110 ... uid/gid mapping works fine, authldap works fine, ... All Clients running Ubuntu 12.10 i686 or Ubuntu 12.10 amd64 are experiencing the same problem : The config files are the same that used in ubuntu 12.04. Auth ldap is correctly configured, user can log in. This is the /etc/fstab entry for /home : 192.168.0.1:/ /home nfs rw,nfsvers=4 0 0 Important lines in /etc/idmapd.conf : domain=my-domain.org [Translation] Method=nsswitch In /etc/default/nfs-common : NEED_IDMAPD=yes /etc/nsswitch.conf is : passwd: files ldap group: files ldap shadow: files ldap When doing ls -l /home there is a strange problem : drwx-- 4 4294967294 oldusers 4096 sept. 21 2011 user100 drwx-- 4 user101oldusers 4096 sept. 21 2011 user101 drwx-- 37 user102oldusers 4096 oct. 1 19:06 user102 drwx-- 36 4294967294 users4096 févr. 5 21:08 user103 drwx-- 36 4294967294 users4096 févr. 8 14:03 user104 drwx-- 30 4294967294 users4096 févr. 4 18:01 user105 drwx-- 28 4294967294 oldusers 4096 oct. 5 2011 user106 drwx-- 37 4294967294 oldusers 4096 janv. 8 14:52 user107 drwx-- 31 4294967294 users4096 déc. 4 11:52 user108 drwx-- 4 user109oldusers 4096 sept. 21 2011 user109 drwx--x--x 45 4294967294 oldusers 4096 janv. 22 15:53 user110 drwx-- 31 4294967294 users4096 janv. 29 12:03 user111 for 571 homedirs (this number varies at each reboot)/662, the owner is the value 4294967294. For the 91 remaining homedirs, the owner is correct. The gidnumber is correctly mapped for all (only 5 differents values used for gidNumber). In /var/log/syslog, I can see : For example : user110 is mapped as 4294967294. but the command "id user110" returns : uid=31124(user110) gid=666(oldusers) groupes=666(oldusers) user110 logs in (auth ldap) from tty1. He runs "ls -l /home/user110/" : drwxr-xr-x 8 4294967294 oldusers 4096 janv. 19 2012 Bureau drwxr-xr-x 3 4294967294 oldusers 4096 déc. 2 2011 Documents drwxr-xr-x 2 4294967294 oldusers 4096 déc. 2 2011 Images Then, he runs "touch /home/user110/test" : drwxr-xr-x 8 4294967294 oldusers 4096 janv. 19 2012 Bureau drwxr-xr-x 3 4294967294 oldusers 4096 déc. 2 2011 Documents drwxr-xr-x 2 4294967294 oldusers 4096 déc. 2 2011 Images drwxr-xr-x 2 4294967294 oldusers0 févr. 13 16:01 test On the nfs server, If i do a ls -l in the same directory
[Kernel-packages] [Bug 1410779] Re: Bluetooth adapter is not working in Ubuntu 14.04
Thanks Victor for your report. I am aware that you were trying: sudo rfkill unblock 3 [sudo] password for vestival: vestival@vestival01:~$ sudo rfkill list 0: tpacpi_wwan_sw: Wireless WAN Soft blocked: no Hard blocked: no 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no 3: hci0: Bluetooth Soft blocked: yes Hard blocked: no -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1410779 Title: Bluetooth adapter is not working in Ubuntu 14.04 Status in bluez package in Ubuntu: New Bug description: Bluetooth is not working on Ubuntu 14.04 in a Lenovo t430s is not working ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: bluez 4.101-0ubuntu13 ProcVersionSignature: Ubuntu 3.13.0-43.72-generic 3.13.11.11 Uname: Linux 3.13.0-43-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.6 Architecture: amd64 CurrentDesktop: Unity Date: Wed Jan 14 13:37:16 2015 InstallationDate: Installed on 2014-08-29 (137 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) InterestingModules: btusb bnep rfcomm bluetooth MachineType: LENOVO 23554M2 ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.13.0-43-generic.efi.signed root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7 SourcePackage: bluez UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/12/2013 dmi.bios.vendor: LENOVO dmi.bios.version: G7ET96WW (2.56 ) dmi.board.asset.tag: Not Available dmi.board.name: 23554M2 dmi.board.vendor: LENOVO dmi.board.version: 0B98401 Pro dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvrG7ET96WW(2.56):bd09/12/2013:svnLENOVO:pn23554M2:pvrThinkPadT430s:rvnLENOVO:rn23554M2:rvr0B98401Pro:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 23554M2 dmi.product.version: ThinkPad T430s dmi.sys.vendor: LENOVO hciconfig: mtime.conffile..etc.init.bluetooth.conf: 2015-01-02T13:44:45.063731 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1410779/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1410779] Re: Bluetooth adapter is not working in Ubuntu 14.04
Adding syslog with enhannced debugging information from bluetoothd. ** Attachment added: "Syslog with -d passed to bluetoothd" https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1410779/+attachment/4298384/+files/syslog -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1410779 Title: Bluetooth adapter is not working in Ubuntu 14.04 Status in bluez package in Ubuntu: New Bug description: Bluetooth is not working on Ubuntu 14.04 in a Lenovo t430s is not working ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: bluez 4.101-0ubuntu13 ProcVersionSignature: Ubuntu 3.13.0-43.72-generic 3.13.11.11 Uname: Linux 3.13.0-43-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.6 Architecture: amd64 CurrentDesktop: Unity Date: Wed Jan 14 13:37:16 2015 InstallationDate: Installed on 2014-08-29 (137 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) InterestingModules: btusb bnep rfcomm bluetooth MachineType: LENOVO 23554M2 ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.13.0-43-generic.efi.signed root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7 SourcePackage: bluez UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/12/2013 dmi.bios.vendor: LENOVO dmi.bios.version: G7ET96WW (2.56 ) dmi.board.asset.tag: Not Available dmi.board.name: 23554M2 dmi.board.vendor: LENOVO dmi.board.version: 0B98401 Pro dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvrG7ET96WW(2.56):bd09/12/2013:svnLENOVO:pn23554M2:pvrThinkPadT430s:rvnLENOVO:rn23554M2:rvr0B98401Pro:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 23554M2 dmi.product.version: ThinkPad T430s dmi.sys.vendor: LENOVO hciconfig: mtime.conffile..etc.init.bluetooth.conf: 2015-01-02T13:44:45.063731 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1410779/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2045891] [NEW] Regression: MODE_H_ILLEGAL starting from kernel v5.5 for UHD 605 [8086:2212]
*** This bug is a duplicate of bug 2044131 *** https://bugs.launchpad.net/bugs/2044131 Public bug reported: [ Impact ] Commit 8f4b1068e7fc3df1a77ac8151767e56b208cc87f introduced some timing checks which have been proven invalid for at least some hardware setups. A user trying to run Focal with HWE 5.15 kernel is not able to get any video output. After going through bisection between 5.4 and 5.5 this commit was identified. Reverting it on top of Focal HWE kernel fixes the issue. The issue has been addressed upstream in DRM tree (20c2dbff342aec13bf93c2f6c951da198916a455) and has been merge into linux-next (e0ef2daa8ca8ce4dbc2fd0959e383b753a87fd7d). dmesg and lspci from the affected configuration are attached to this bug. [ Test Plan ] 1. Boot the affected hardware with Ubuntu desktop running kernel v5.5 or higher. 2. Wait until boot finishes and see the blank screen. Actual result: there is no video output visible. Expected result: normal boot process should be visible (e.g. splash), then GUI should appear. [ Where problem could occur ] This bug was a result of assumptions in the checks that turned out to be not valid for some hardware. The checks were removed from global intel_mode_valid function and moved into connector specific .mode_valid() hooks, entirely skiping BXT/GLK DSI connectors. This should keep the checks where appropriate and skip for hardware that does not comply to them. [ Other info ] Upstream bug description: Prior to kernel v5.5 the setup was working fine. Starting with that release the display goes blank. What is visible in the logs: UBSAN: array-index-out-of-bounds in /build/linux-hwe-5.15-5Tb11x/linux-hwe-5.15-5.15.0/drivers/gpu/drm/i915/display/intel_display.c:12564:20 index 5 is out of range for type 'u32 [5]' After a bisection I was able to determine that it started with commit 8f4b1068e7fc3df1a77ac8151767e56b208cc87f. Apparently what happens is this test causes intel_mode_valid to exit with MODE_H_ILLEGAL: if (mode->htotal - mode->hdisplay < 32) return MODE_H_ILLEGAL; According to the output in the journal: [drm]] Modeline "800x1280": 50 54000 800 810 820 830 1280 1290 1300 1310 0x8 0xa so in this case htotal is 830 and hdisplay is 800 which makes this condition true and determines the mode is illegal. As a result the display is blank. Reverting the commit in question restores full functionality ** Affects: linux Importance: Unknown Status: Unknown ** Affects: linux (Ubuntu) Importance: High Status: New ** Affects: linux (Ubuntu Focal) Importance: High Status: New ** Affects: linux (Ubuntu Jammy) Importance: High Status: New ** Affects: linux (Ubuntu Mantic) Importance: High Status: New ** Affects: linux (Ubuntu Noble) Importance: High Status: New ** Tags: regression ** Bug watch added: gitlab.freedesktop.org/drm/intel/-/issues #9720 https://gitlab.freedesktop.org/drm/intel/-/issues/9720 ** Also affects: linux via https://gitlab.freedesktop.org/drm/intel/-/issues/9720 Importance: Unknown Status: Unknown ** Also affects: linux (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Mantic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Focal) Importance: Undecided => High ** Changed in: linux (Ubuntu Jammy) Importance: Undecided => High ** Changed in: linux (Ubuntu Mantic) Importance: Undecided => High ** Changed in: linux (Ubuntu Noble) Importance: Undecided => High -- 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/2045891 Title: Regression: MODE_H_ILLEGAL starting from kernel v5.5 for UHD 605 [8086:2212] Status in Linux: Unknown Status in linux package in Ubuntu: New Status in linux source package in Focal: New Status in linux source package in Jammy: New Status in linux source package in Mantic: New Status in linux source package in Noble: New Bug description: [ Impact ] Commit 8f4b1068e7fc3df1a77ac8151767e56b208cc87f introduced some timing checks which have been proven invalid for at least some hardware setups. A user trying to run Focal with HWE 5.15 kernel is not able to get any video output. After going through bisection between 5.4 and 5.5 this commit was identified. Reverting it on top of Focal HWE kernel fixes the issue. The issue has been addressed upstream in DRM tree (20c2dbff342aec13bf93c2f6c951da198916a455) and has been merge into linux-next (e0ef2daa8ca8ce4dbc2fd0959e383b753a87fd7d). dmesg and lspci from the affected configuration are attached to this bug. [ Test Plan ] 1. Boot the affected hardware with Ubuntu desktop running kernel v5.5
[Kernel-packages] [Bug 2045891] Re: Regression: MODE_H_ILLEGAL starting from kernel v5.5 for UHD 605 [8086:2212]
*** This bug is a duplicate of bug 2044131 *** https://bugs.launchpad.net/bugs/2044131 ** Attachment added: "lspci" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045891/+attachment/5727217/+files/lspci -- 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/2045891 Title: Regression: MODE_H_ILLEGAL starting from kernel v5.5 for UHD 605 [8086:2212] Status in Linux: Unknown Status in linux package in Ubuntu: New Status in linux source package in Focal: New Status in linux source package in Jammy: New Status in linux source package in Mantic: New Status in linux source package in Noble: New Bug description: [ Impact ] Commit 8f4b1068e7fc3df1a77ac8151767e56b208cc87f introduced some timing checks which have been proven invalid for at least some hardware setups. A user trying to run Focal with HWE 5.15 kernel is not able to get any video output. After going through bisection between 5.4 and 5.5 this commit was identified. Reverting it on top of Focal HWE kernel fixes the issue. The issue has been addressed upstream in DRM tree (20c2dbff342aec13bf93c2f6c951da198916a455) and has been merge into linux-next (e0ef2daa8ca8ce4dbc2fd0959e383b753a87fd7d). dmesg and lspci from the affected configuration are attached to this bug. [ Test Plan ] 1. Boot the affected hardware with Ubuntu desktop running kernel v5.5 or higher. 2. Wait until boot finishes and see the blank screen. Actual result: there is no video output visible. Expected result: normal boot process should be visible (e.g. splash), then GUI should appear. [ Where problem could occur ] This bug was a result of assumptions in the checks that turned out to be not valid for some hardware. The checks were removed from global intel_mode_valid function and moved into connector specific .mode_valid() hooks, entirely skiping BXT/GLK DSI connectors. This should keep the checks where appropriate and skip for hardware that does not comply to them. [ Other info ] Upstream bug description: Prior to kernel v5.5 the setup was working fine. Starting with that release the display goes blank. What is visible in the logs: UBSAN: array-index-out-of-bounds in /build/linux-hwe-5.15-5Tb11x/linux-hwe-5.15-5.15.0/drivers/gpu/drm/i915/display/intel_display.c:12564:20 index 5 is out of range for type 'u32 [5]' After a bisection I was able to determine that it started with commit 8f4b1068e7fc3df1a77ac8151767e56b208cc87f. Apparently what happens is this test causes intel_mode_valid to exit with MODE_H_ILLEGAL: if (mode->htotal - mode->hdisplay < 32) return MODE_H_ILLEGAL; According to the output in the journal: [drm]] Modeline "800x1280": 50 54000 800 810 820 830 1280 1290 1300 1310 0x8 0xa so in this case htotal is 830 and hdisplay is 800 which makes this condition true and determines the mode is illegal. As a result the display is blank. Reverting the commit in question restores full functionality To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/2045891/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2045891] Re: Regression: MODE_H_ILLEGAL starting from kernel v5.5 for UHD 605 [8086:2212]
*** This bug is a duplicate of bug 2044131 *** https://bugs.launchpad.net/bugs/2044131 Adding dmesg and lspci from affected system ** Attachment added: "dmesg" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045891/+attachment/5727216/+files/dmesg -- 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/2045891 Title: Regression: MODE_H_ILLEGAL starting from kernel v5.5 for UHD 605 [8086:2212] Status in Linux: Unknown Status in linux package in Ubuntu: New Status in linux source package in Focal: New Status in linux source package in Jammy: New Status in linux source package in Mantic: New Status in linux source package in Noble: New Bug description: [ Impact ] Commit 8f4b1068e7fc3df1a77ac8151767e56b208cc87f introduced some timing checks which have been proven invalid for at least some hardware setups. A user trying to run Focal with HWE 5.15 kernel is not able to get any video output. After going through bisection between 5.4 and 5.5 this commit was identified. Reverting it on top of Focal HWE kernel fixes the issue. The issue has been addressed upstream in DRM tree (20c2dbff342aec13bf93c2f6c951da198916a455) and has been merge into linux-next (e0ef2daa8ca8ce4dbc2fd0959e383b753a87fd7d). dmesg and lspci from the affected configuration are attached to this bug. [ Test Plan ] 1. Boot the affected hardware with Ubuntu desktop running kernel v5.5 or higher. 2. Wait until boot finishes and see the blank screen. Actual result: there is no video output visible. Expected result: normal boot process should be visible (e.g. splash), then GUI should appear. [ Where problem could occur ] This bug was a result of assumptions in the checks that turned out to be not valid for some hardware. The checks were removed from global intel_mode_valid function and moved into connector specific .mode_valid() hooks, entirely skiping BXT/GLK DSI connectors. This should keep the checks where appropriate and skip for hardware that does not comply to them. [ Other info ] Upstream bug description: Prior to kernel v5.5 the setup was working fine. Starting with that release the display goes blank. What is visible in the logs: UBSAN: array-index-out-of-bounds in /build/linux-hwe-5.15-5Tb11x/linux-hwe-5.15-5.15.0/drivers/gpu/drm/i915/display/intel_display.c:12564:20 index 5 is out of range for type 'u32 [5]' After a bisection I was able to determine that it started with commit 8f4b1068e7fc3df1a77ac8151767e56b208cc87f. Apparently what happens is this test causes intel_mode_valid to exit with MODE_H_ILLEGAL: if (mode->htotal - mode->hdisplay < 32) return MODE_H_ILLEGAL; According to the output in the journal: [drm]] Modeline "800x1280": 50 54000 800 810 820 830 1280 1290 1300 1310 0x8 0xa so in this case htotal is 830 and hdisplay is 800 which makes this condition true and determines the mode is illegal. As a result the display is blank. Reverting the commit in question restores full functionality To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/2045891/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2045891] Re: Regression: MODE_H_ILLEGAL starting from kernel v5.5 for UHD 605 [8086:2212]
*** This bug is a duplicate of bug 2044131 *** https://bugs.launchpad.net/bugs/2044131 ** Patch added: "0001-drm-i915-Skip-some-timing-checks-on-BXT-GLK-DSI-tran.patch" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045891/+attachment/5727218/+files/0001-drm-i915-Skip-some-timing-checks-on-BXT-GLK-DSI-tran.patch ** Description changed: [ Impact ] Commit 8f4b1068e7fc3df1a77ac8151767e56b208cc87f introduced some timing checks which have been proven invalid for at least some hardware setups. A user trying to run Focal with HWE 5.15 kernel is not able to get any video output. After going through bisection between 5.4 and 5.5 this commit was identified. Reverting it on top of Focal HWE kernel fixes the issue. The issue has been addressed upstream in DRM tree (20c2dbff342aec13bf93c2f6c951da198916a455) and has been merge into linux-next (e0ef2daa8ca8ce4dbc2fd0959e383b753a87fd7d). dmesg and lspci from the affected configuration are attached to this bug. [ Test Plan ] 1. Boot the affected hardware with Ubuntu desktop running kernel v5.5 or higher. 2. Wait until boot finishes and see the blank screen. Actual result: there is no video output visible. Expected result: normal boot process should be visible (e.g. splash), then GUI should appear. [ Where problem could occur ] This bug was a result of assumptions in the checks that turned out to be not valid for some hardware. The checks were removed from global intel_mode_valid function and moved into connector specific .mode_valid() hooks, entirely skiping BXT/GLK DSI connectors. This should keep the checks where appropriate and skip for hardware that does not comply to them. [ Other info ] Upstream bug description: Prior to kernel v5.5 the setup was working fine. Starting with that release the display goes blank. What is visible in the logs: UBSAN: array-index-out-of-bounds in /build/linux-hwe-5.15-5Tb11x/linux-hwe-5.15-5.15.0/drivers/gpu/drm/i915/display/intel_display.c:12564:20 index 5 is out of range for type 'u32 [5]' After a bisection I was able to determine that it started with commit 8f4b1068e7fc3df1a77ac8151767e56b208cc87f. Apparently what happens is this test causes intel_mode_valid to exit with MODE_H_ILLEGAL: if (mode->htotal - mode->hdisplay < 32) - return MODE_H_ILLEGAL; + return MODE_H_ILLEGAL; According to the output in the journal: [drm]] Modeline "800x1280": 50 54000 800 810 820 830 1280 1290 1300 1310 0x8 0xa so in this case htotal is 830 and hdisplay is 800 which makes this condition true and determines the mode is illegal. As a result the display is blank. Reverting the commit in question restores full functionality ** This bug has been marked a duplicate of bug 2044131 i915 regression introduced with 5.5 kernel -- 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/2045891 Title: Regression: MODE_H_ILLEGAL starting from kernel v5.5 for UHD 605 [8086:2212] Status in Linux: Unknown Status in linux package in Ubuntu: New Status in linux source package in Focal: New Status in linux source package in Jammy: New Status in linux source package in Mantic: New Status in linux source package in Noble: New Bug description: [ Impact ] Commit 8f4b1068e7fc3df1a77ac8151767e56b208cc87f introduced some timing checks which have been proven invalid for at least some hardware setups. A user trying to run Focal with HWE 5.15 kernel is not able to get any video output. After going through bisection between 5.4 and 5.5 this commit was identified. Reverting it on top of Focal HWE kernel fixes the issue. The issue has been addressed upstream in DRM tree (20c2dbff342aec13bf93c2f6c951da198916a455) and has been merge into linux-next (e0ef2daa8ca8ce4dbc2fd0959e383b753a87fd7d). dmesg and lspci from the affected configuration are attached to this bug. [ Test Plan ] 1. Boot the affected hardware with Ubuntu desktop running kernel v5.5 or higher. 2. Wait until boot finishes and see the blank screen. Actual result: there is no video output visible. Expected result: normal boot process should be visible (e.g. splash), then GUI should appear. [ Where problem could occur ] This bug was a result of assumptions in the checks that turned out to be not valid for some hardware. The checks were removed from global intel_mode_valid function and moved into connector specific .mode_valid() hooks, entirely skiping BXT/GLK DSI connectors. This should keep the checks where appropriate and skip for hardware that does not comply to them. [ Other info ] Upstream bug description: Prior to kernel v5.5 the setup was working fine. Starting with that release the display goes blank. What is visible in the logs: UBSAN: array-index-out-of-bounds in /build/linux-hwe-5.15-5Tb11x/linux-hwe-5.15-5.15.0/
[Kernel-packages] [Bug 2044131] Re: i915 regression introduced with 5.5 kernel
** Description changed: + [ Impact ] + Commit 8f4b1068e7fc3df1a77ac8151767e56b208cc87f introduced some timing checks which have been proven invalid for at least some hardware setups. A user trying to run Focal with HWE 5.15 kernel is not able to get any video output. + After going through bisection between 5.4 and 5.5 this commit was identified. Reverting it on top of Focal HWE kernel fixes the issue. + + The issue has been addressed upstream in DRM tree + (20c2dbff342aec13bf93c2f6c951da198916a455) and has been merge into + linux-next (e0ef2daa8ca8ce4dbc2fd0959e383b753a87fd7d). + + dmesg and lspci from the affected configuration are attached to this + bug. + + [ Test Plan ] + 1. Boot the affected hardware with Ubuntu desktop running kernel v5.5 or higher. + 2. Wait until boot finishes and see the blank screen. + + Actual result: there is no video output visible. + Expected result: normal boot process should be visible (e.g. splash), then GUI should appear. + + [ Where problem could occur ] + This bug was a result of assumptions in the checks that turned out to be not valid for some hardware. The checks were removed from global intel_mode_valid function and moved into connector specific .mode_valid() hooks, entirely skiping BXT/GLK DSI connectors. + + This should keep the checks where appropriate and skip for hardware that + does not comply to them. + + [ Other info ] + + Original bug description: + There is a regression preventing a user to upgrade from 5.4 kernel to anything that's higher than 5.5. When using such kernel the image orientation is wrong (rotated by 90°C). Also the kernel log contains: wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] Unknown revid 0x06 wrz 15 09:19:49 desktop kernel: rtw_8821ce :01:00.0: Firmware version 24.8.0, H2C version 12 wrz 15 09:19:49 desktop kernel: Console: switching to colour dummy device 80x25 wrz 15 09:19:49 desktop kernel: i915 :00:02.0: vgaarb: deactivate vga console wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] couldn't get memory information wrz 15 09:19:49 desktop kernel: i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:o> wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v> wrz 15 09:19:49 desktop kernel: wrz 15 09:19:49 desktop kernel: UBSAN: array-index-out-of-bounds in /build/linux-hwe-5.15-DZkSuT/linux-hwe-5.15-5.> wrz 15 09:19:49 desktop kernel: index 5 is out of range for type 'u32 [5]' (full stack trace attached) The video hardware in use is: 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 605 [8086:3185] (rev 06) (prog-if 00 [VGA controller]) (...) Kernel driver in use: i915 Kernel modules: i915 The user wanted to upgrade from bionic to focal with HWE kernel (they needed it due to some networking hardware they wanted to have supported by the newer kernel). The user was testing mainline stable kernels and noticed that the last working kernel was the 5.4 series, while anything starting from 5.5 and above is BROKEN (symptoms as described in the first paragraph above). Together with the user we have run a bisection between v5.4 and v5.5 on the upstream stable kernel and we were able to identify the first broken commit to be: 8f4b1068e7fc3df1a77ac8151767e56b208cc87f drm/i915: Check some transcoder timing minimum limits To confirm I have reverted this change on top of the HWE kernel for focal and the user have confirmed that this resolved the issue (test build available at ppa:dgadomski/kernel-sf368743). I am not fully sure what the purpose of this patch was, but I assume the regression was not intended and the hardware should be still supported. Attaching lshw and lspci output. ** Bug watch added: gitlab.freedesktop.org/drm/intel/-/issues #9720 https://gitlab.freedesktop.org/drm/intel/-/issues/9720 ** Also affects: linux via https://gitlab.freedesktop.org/drm/intel/-/issues/9720 Importance: Unknown Status: Unknown ** Also affects: linux (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Mantic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Patch added: "0001-drm-i915-Skip-some-timing-checks-on-BXT-GLK-DSI-tran.patch" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2044131/+attachment/5727219/+files/0001-drm-i915-Skip-some-timing-checks-on-BXT-GLK-DSI-tran.patch -- 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/2044131 Title: i915 regression introduced with 5.5 kernel Statu
[Kernel-packages] [Bug 2044131] Re: i915 regression introduced with 5.5 kernel
The fix has been merged into upstream Linux tree as 20c2dbff342aec13bf93c2f6c951da198916a455. -- 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/2044131 Title: i915 regression introduced with 5.5 kernel Status in Linux: Fix Released Status in linux package in Ubuntu: New Status in linux source package in Focal: New Status in linux source package in Jammy: New Status in linux source package in Mantic: New Status in linux source package in Noble: New Bug description: [ Impact ] Commit 8f4b1068e7fc3df1a77ac8151767e56b208cc87f introduced some timing checks which have been proven invalid for at least some hardware setups. A user trying to run Focal with HWE 5.15 kernel is not able to get any video output. After going through bisection between 5.4 and 5.5 this commit was identified. Reverting it on top of Focal HWE kernel fixes the issue. The issue has been addressed upstream in DRM tree (20c2dbff342aec13bf93c2f6c951da198916a455) and has been merge into linux-next (e0ef2daa8ca8ce4dbc2fd0959e383b753a87fd7d). dmesg and lspci from the affected configuration are attached to this bug. [ Test Plan ] 1. Boot the affected hardware with Ubuntu desktop running kernel v5.5 or higher. 2. Wait until boot finishes and see the blank screen. Actual result: there is no video output visible. Expected result: normal boot process should be visible (e.g. splash), then GUI should appear. [ Where problem could occur ] This bug was a result of assumptions in the checks that turned out to be not valid for some hardware. The checks were removed from global intel_mode_valid function and moved into connector specific .mode_valid() hooks, entirely skiping BXT/GLK DSI connectors. This should keep the checks where appropriate and skip for hardware that does not comply to them. [ Other info ] Original bug description: There is a regression preventing a user to upgrade from 5.4 kernel to anything that's higher than 5.5. When using such kernel the image orientation is wrong (rotated by 90°C). Also the kernel log contains: wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] Unknown revid 0x06 wrz 15 09:19:49 desktop kernel: rtw_8821ce :01:00.0: Firmware version 24.8.0, H2C version 12 wrz 15 09:19:49 desktop kernel: Console: switching to colour dummy device 80x25 wrz 15 09:19:49 desktop kernel: i915 :00:02.0: vgaarb: deactivate vga console wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] couldn't get memory information wrz 15 09:19:49 desktop kernel: i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:o> wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v> wrz 15 09:19:49 desktop kernel: wrz 15 09:19:49 desktop kernel: UBSAN: array-index-out-of-bounds in /build/linux-hwe-5.15-DZkSuT/linux-hwe-5.15-5.> wrz 15 09:19:49 desktop kernel: index 5 is out of range for type 'u32 [5]' (full stack trace attached) The video hardware in use is: 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 605 [8086:3185] (rev 06) (prog-if 00 [VGA controller]) (...) Kernel driver in use: i915 Kernel modules: i915 The user wanted to upgrade from bionic to focal with HWE kernel (they needed it due to some networking hardware they wanted to have supported by the newer kernel). The user was testing mainline stable kernels and noticed that the last working kernel was the 5.4 series, while anything starting from 5.5 and above is BROKEN (symptoms as described in the first paragraph above). Together with the user we have run a bisection between v5.4 and v5.5 on the upstream stable kernel and we were able to identify the first broken commit to be: 8f4b1068e7fc3df1a77ac8151767e56b208cc87f drm/i915: Check some transcoder timing minimum limits To confirm I have reverted this change on top of the HWE kernel for focal and the user have confirmed that this resolved the issue (test build available at ppa:dgadomski/kernel-sf368743). I am not fully sure what the purpose of this patch was, but I assume the regression was not intended and the hardware should be still supported. Attaching lshw and lspci output. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/2044131/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2063308] Re: lenovo p1g5 suspend issues with docking stations
Sure Mark. I have some information handy: grep "model name" /proc/cpuinfo | head -n 1 model name : 12th Gen Intel(R) Core(TM) i9-12900H GPU: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2438] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device [17aa:22f8] The dock is: ThinkPad Thunderbolt 4 Dock: │ │ Device ID: c0170efdf195b859fa21474253c0d97e7335 │ │ Current version:10.11 │ │ Vendor: Lenovo (USB:0x17EF) No WWAN seems to be in use according to the logs. I'm checking with the user about the AMT status. -- 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/2063308 Title: lenovo p1g5 suspend issues with docking stations Status in linux package in Ubuntu: Triaged Bug description: Lenovo Docking Station Issue with Ubuntu 22.04 Sleep mode Recovery Hello, We are having trouble with our lenovo p1 laptops docking stations. When waking from suspend on Ubuntu with a docking station is an issue for some users even with Intel AMT disabled in BIOS. The exact steps to reproduce are as follows: 1) Suspend/sleep the laptop 2) Plug the docking station into the laptop 3) Wake the laptop The sleep settings in BIOS are set to Linux S3. Docking station issues, such as Ethernet not working after waking, do not occur with Windows/Linux sleep settings, but the laptop doesn't properly suspend processes in Windows/Linux sleep mode and will overheat the laptop when in an enclosed space such as a bag. Linux S3 is the only way we've found laptops to not overheat after suspending, but we that makes the dock inoperable after waking from suspend. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2063308/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2063308] Re: lenovo p1g5 suspend issues with docking stations
>From what I have just received: AMT is disabled on that machine. -- 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/2063308 Title: lenovo p1g5 suspend issues with docking stations Status in linux package in Ubuntu: Triaged Bug description: Lenovo Docking Station Issue with Ubuntu 22.04 Sleep mode Recovery Hello, We are having trouble with our lenovo p1 laptops docking stations. When waking from suspend on Ubuntu with a docking station is an issue for some users even with Intel AMT disabled in BIOS. The exact steps to reproduce are as follows: 1) Suspend/sleep the laptop 2) Plug the docking station into the laptop 3) Wake the laptop The sleep settings in BIOS are set to Linux S3. Docking station issues, such as Ethernet not working after waking, do not occur with Windows/Linux sleep settings, but the laptop doesn't properly suspend processes in Windows/Linux sleep mode and will overheat the laptop when in an enclosed space such as a bag. Linux S3 is the only way we've found laptops to not overheat after suspending, but we that makes the dock inoperable after waking from suspend. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2063308/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2063308] Re: lenovo p1g5 suspend issues with docking stations
@Aaron: You mean downgrade ME FW? To which version? -- 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/2063308 Title: lenovo p1g5 suspend issues with docking stations Status in linux package in Ubuntu: Triaged Bug description: Lenovo Docking Station Issue with Ubuntu 22.04 Sleep mode Recovery Hello, We are having trouble with our lenovo p1 laptops docking stations. When waking from suspend on Ubuntu with a docking station is an issue for some users even with Intel AMT disabled in BIOS. The exact steps to reproduce are as follows: 1) Suspend/sleep the laptop 2) Plug the docking station into the laptop 3) Wake the laptop The sleep settings in BIOS are set to Linux S3. Docking station issues, such as Ethernet not working after waking, do not occur with Windows/Linux sleep settings, but the laptop doesn't properly suspend processes in Windows/Linux sleep mode and will overheat the laptop when in an enclosed space such as a bag. Linux S3 is the only way we've found laptops to not overheat after suspending, but we that makes the dock inoperable after waking from suspend. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2063308/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2063308] Re: lenovo p1g5 suspend issues with docking stations
@Aaron: afaik the user is on ME FW 1.25.1932 the whole time. They have not tried to upgrade it yet. -- 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/2063308 Title: lenovo p1g5 suspend issues with docking stations Status in linux package in Ubuntu: Triaged Bug description: Lenovo Docking Station Issue with Ubuntu 22.04 Sleep mode Recovery Hello, We are having trouble with our lenovo p1 laptops docking stations. When waking from suspend on Ubuntu with a docking station is an issue for some users even with Intel AMT disabled in BIOS. The exact steps to reproduce are as follows: 1) Suspend/sleep the laptop 2) Plug the docking station into the laptop 3) Wake the laptop The sleep settings in BIOS are set to Linux S3. Docking station issues, such as Ethernet not working after waking, do not occur with Windows/Linux sleep settings, but the laptop doesn't properly suspend processes in Windows/Linux sleep mode and will overheat the laptop when in an enclosed space such as a bag. Linux S3 is the only way we've found laptops to not overheat after suspending, but we that makes the dock inoperable after waking from suspend. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2063308/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1959681] [NEW] mic not working on HP-EliteBook-830-G7
Public bug reported: There is no audio input from the built-in mic available on Bionic & Focal on certain intel audio hw (00:1f.3 Multimedia audio controller [0401]: Intel Corporation Device [8086:02c8]) despite trying different kernel cmdline options (snd_hda_intel.dmic_detect=0 or snd_intel_dspcfg.dsp_driver=1). The behavior was similar on Bionic and Focal - no mic listed in alsa/pulseaudio mixers. Additionally the following can be found in the kernel log: sof-audio-pci :00:1f.3: Digital mics found on Skylake+ platform, using SOF driver sof-audio-pci :00:1f.3: enabling device ( -> 0002) sof-audio-pci :00:1f.3: warning: No matching ASoC machine driver found The situation is different on impish - on this release the mic is available out of the box. I made a simple test of overwriting sof files inside Focal's linux- firmware package with the contents of firmware-sof-signed package from impish finding it solved the issue without any trace of errors in the logs. The same approach did not work on Bionic (despite similar kernel versions used in both 5.4.0) - due to HWE). These are some excerpts from Bionic launching impish SOF firmware: sof-audio-pci :00:1f.3: Firmware: ABI 3:17:0 Kernel ABI 3:10:0 sof-audio-pci :00:1f.3: warn: FW ABI is more recent than kernel sof-audio-pci :00:1f.3: firmware boot complete sof-audio-pci :00:1f.3: Topology: ABI 3:17:0 Kernel ABI 3:10:0 sof-audio-pci :00:1f.3: warn: topology ABI is more recent than kernel sof-audio-pci :00:1f.3: warning: widget type 7 name iDisp3 Tx not handled sof-audio-pci :00:1f.3: warning: widget type 0 name codec0_in not handled sof-audio-pci :00:1f.3: warning: widget type 7 name iDisp2 Tx not handled sof-audio-pci :00:1f.3: warning: widget type 0 name codec1_in not handled sof-audio-pci :00:1f.3: warning: widget type 7 name iDisp1 Tx not handled sof-audio-pci :00:1f.3: warning: widget type 1 name codec0_out not handled sof-audio-pci :00:1f.3: warning: widget type 7 name Analog CPU Playback not handled sof-audio-pci :00:1f.3: warning: widget type 1 name codec1_out not handled sof-audio-pci :00:1f.3: warning: widget type 7 name Digital CPU Playback not handled sof-audio-pci :00:1f.3: warning: widget type 0 name codec2_in not handled sof-audio-pci :00:1f.3: warning: widget type 7 name Alt Analog CPU Playback not handled sof-audio-pci :00:1f.3: warning: widget type 1 name codec2_out not handled sof-audio-pci :00:1f.3: warning: widget type 0 name Analog CPU Capture not handled sof-audio-pci :00:1f.3: warning: widget type 1 name iDisp1_out not handled sof-audio-pci :00:1f.3: warning: widget type 0 name Digital CPU Capture not handled sof-audio-pci :00:1f.3: warning: widget type 1 name iDisp2_out not handled sof-audio-pci :00:1f.3: warning: widget type 0 name Alt Analog CPU Capture not handled sof-audio-pci :00:1f.3: warning: widget type 1 name iDisp3_out not handled [ Test Plan ] 1. Launch Ubuntu desktop on affected hardware. 2. Open audio mixer (e.g. pulsemixer). 3. Look for built-in audio input (e.g. Built-in Audio Analog Stereo). Expected result: Built-in mic is available for use. Actual result: Built-in mic is missing. ** Affects: linux-firmware (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: linux-firmware (Ubuntu Bionic) Importance: Medium Status: New ** Affects: linux-firmware (Ubuntu Focal) Importance: Medium Status: New ** Tags: sts ** Changed in: linux-firmware (Ubuntu) Status: New => Fix Released ** Also affects: linux-firmware (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: linux-firmware (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: linux-firmware (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: linux-firmware (Ubuntu Focal) Importance: Undecided => Medium -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-firmware in Ubuntu. https://bugs.launchpad.net/bugs/1959681 Title: mic not working on HP-EliteBook-830-G7 Status in linux-firmware package in Ubuntu: Fix Released Status in linux-firmware source package in Bionic: New Status in linux-firmware source package in Focal: New Bug description: There is no audio input from the built-in mic available on Bionic & Focal on certain intel audio hw (00:1f.3 Multimedia audio controller [0401]: Intel Corporation Device [8086:02c8]) despite trying different kernel cmdline options (snd_hda_intel.dmic_detect=0 or snd_intel_dspcfg.dsp_driver=1). The behavior was similar on Bionic and Focal - no mic listed in alsa/pulseaudio mixers. Additionally the following can be found in the kernel log: sof-audio-pci :00:1f.3: Digital mics found on Skylake+ platform, using SOF driver sof-audio-pci :00:1f.3: enabling device (
[Kernel-packages] [Bug 1959681] Re: mic not working on HP-EliteBook-830-G7
The packages I used for testing are available at ppa:dgadomski/firmware- mic -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-firmware in Ubuntu. https://bugs.launchpad.net/bugs/1959681 Title: mic not working on HP-EliteBook-830-G7 Status in linux-firmware package in Ubuntu: Fix Released Status in linux-firmware source package in Bionic: New Status in linux-firmware source package in Focal: New Bug description: There is no audio input from the built-in mic available on Bionic & Focal on certain intel audio hw (00:1f.3 Multimedia audio controller [0401]: Intel Corporation Device [8086:02c8]) despite trying different kernel cmdline options (snd_hda_intel.dmic_detect=0 or snd_intel_dspcfg.dsp_driver=1). The behavior was similar on Bionic and Focal - no mic listed in alsa/pulseaudio mixers. Additionally the following can be found in the kernel log: sof-audio-pci :00:1f.3: Digital mics found on Skylake+ platform, using SOF driver sof-audio-pci :00:1f.3: enabling device ( -> 0002) sof-audio-pci :00:1f.3: warning: No matching ASoC machine driver found The situation is different on impish - on this release the mic is available out of the box. I made a simple test of overwriting sof files inside Focal's linux- firmware package with the contents of firmware-sof-signed package from impish finding it solved the issue without any trace of errors in the logs. The same approach did not work on Bionic (despite similar kernel versions used in both 5.4.0) - due to HWE). These are some excerpts from Bionic launching impish SOF firmware: sof-audio-pci :00:1f.3: Firmware: ABI 3:17:0 Kernel ABI 3:10:0 sof-audio-pci :00:1f.3: warn: FW ABI is more recent than kernel sof-audio-pci :00:1f.3: firmware boot complete sof-audio-pci :00:1f.3: Topology: ABI 3:17:0 Kernel ABI 3:10:0 sof-audio-pci :00:1f.3: warn: topology ABI is more recent than kernel sof-audio-pci :00:1f.3: warning: widget type 7 name iDisp3 Tx not handled sof-audio-pci :00:1f.3: warning: widget type 0 name codec0_in not handled sof-audio-pci :00:1f.3: warning: widget type 7 name iDisp2 Tx not handled sof-audio-pci :00:1f.3: warning: widget type 0 name codec1_in not handled sof-audio-pci :00:1f.3: warning: widget type 7 name iDisp1 Tx not handled sof-audio-pci :00:1f.3: warning: widget type 1 name codec0_out not handled sof-audio-pci :00:1f.3: warning: widget type 7 name Analog CPU Playback not handled sof-audio-pci :00:1f.3: warning: widget type 1 name codec1_out not handled sof-audio-pci :00:1f.3: warning: widget type 7 name Digital CPU Playback not handled sof-audio-pci :00:1f.3: warning: widget type 0 name codec2_in not handled sof-audio-pci :00:1f.3: warning: widget type 7 name Alt Analog CPU Playback not handled sof-audio-pci :00:1f.3: warning: widget type 1 name codec2_out not handled sof-audio-pci :00:1f.3: warning: widget type 0 name Analog CPU Capture not handled sof-audio-pci :00:1f.3: warning: widget type 1 name iDisp1_out not handled sof-audio-pci :00:1f.3: warning: widget type 0 name Digital CPU Capture not handled sof-audio-pci :00:1f.3: warning: widget type 1 name iDisp2_out not handled sof-audio-pci :00:1f.3: warning: widget type 0 name Alt Analog CPU Capture not handled sof-audio-pci :00:1f.3: warning: widget type 1 name iDisp3_out not handled [ Test Plan ] 1. Launch Ubuntu desktop on affected hardware. 2. Open audio mixer (e.g. pulsemixer). 3. Look for built-in audio input (e.g. Built-in Audio Analog Stereo). Expected result: Built-in mic is available for use. Actual result: Built-in mic is missing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1959681/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1959681] Re: mic not working on HP-EliteBook-830-G7
Thanks for looking into that Hui. I have checked that with the user who experience it - you are right, the mic was working fine *without* the need to install firmware-sof-signed. Regarding firmware: what do you mean by "original sof-firmware" in this context? Do you need dmesg from vanilla focal or from focal with the sof firmware from impish shipping in linux-firmware? Thanks! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-firmware in Ubuntu. https://bugs.launchpad.net/bugs/1959681 Title: mic not working on HP-EliteBook-830-G7 Status in linux-firmware package in Ubuntu: Incomplete Status in linux-firmware source package in Bionic: New Status in linux-firmware source package in Focal: New Bug description: There is no audio input from the built-in mic available on Bionic & Focal on certain intel audio hw (00:1f.3 Multimedia audio controller [0401]: Intel Corporation Device [8086:02c8]) despite trying different kernel cmdline options (snd_hda_intel.dmic_detect=0 or snd_intel_dspcfg.dsp_driver=1). The behavior was similar on Bionic and Focal - no mic listed in alsa/pulseaudio mixers. Additionally the following can be found in the kernel log: sof-audio-pci :00:1f.3: Digital mics found on Skylake+ platform, using SOF driver sof-audio-pci :00:1f.3: enabling device ( -> 0002) sof-audio-pci :00:1f.3: warning: No matching ASoC machine driver found The situation is different on impish - on this release the mic is available out of the box. I made a simple test of overwriting sof files inside Focal's linux- firmware package with the contents of firmware-sof-signed package from impish finding it solved the issue without any trace of errors in the logs. The same approach did not work on Bionic (despite similar kernel versions used in both 5.4.0) - due to HWE). These are some excerpts from Bionic launching impish SOF firmware: sof-audio-pci :00:1f.3: Firmware: ABI 3:17:0 Kernel ABI 3:10:0 sof-audio-pci :00:1f.3: warn: FW ABI is more recent than kernel sof-audio-pci :00:1f.3: firmware boot complete sof-audio-pci :00:1f.3: Topology: ABI 3:17:0 Kernel ABI 3:10:0 sof-audio-pci :00:1f.3: warn: topology ABI is more recent than kernel sof-audio-pci :00:1f.3: warning: widget type 7 name iDisp3 Tx not handled sof-audio-pci :00:1f.3: warning: widget type 0 name codec0_in not handled sof-audio-pci :00:1f.3: warning: widget type 7 name iDisp2 Tx not handled sof-audio-pci :00:1f.3: warning: widget type 0 name codec1_in not handled sof-audio-pci :00:1f.3: warning: widget type 7 name iDisp1 Tx not handled sof-audio-pci :00:1f.3: warning: widget type 1 name codec0_out not handled sof-audio-pci :00:1f.3: warning: widget type 7 name Analog CPU Playback not handled sof-audio-pci :00:1f.3: warning: widget type 1 name codec1_out not handled sof-audio-pci :00:1f.3: warning: widget type 7 name Digital CPU Playback not handled sof-audio-pci :00:1f.3: warning: widget type 0 name codec2_in not handled sof-audio-pci :00:1f.3: warning: widget type 7 name Alt Analog CPU Playback not handled sof-audio-pci :00:1f.3: warning: widget type 1 name codec2_out not handled sof-audio-pci :00:1f.3: warning: widget type 0 name Analog CPU Capture not handled sof-audio-pci :00:1f.3: warning: widget type 1 name iDisp1_out not handled sof-audio-pci :00:1f.3: warning: widget type 0 name Digital CPU Capture not handled sof-audio-pci :00:1f.3: warning: widget type 1 name iDisp2_out not handled sof-audio-pci :00:1f.3: warning: widget type 0 name Alt Analog CPU Capture not handled sof-audio-pci :00:1f.3: warning: widget type 1 name iDisp3_out not handled [ Test Plan ] 1. Launch Ubuntu desktop on affected hardware. 2. Open audio mixer (e.g. pulsemixer). 3. Look for built-in audio input (e.g. Built-in Audio Analog Stereo). Expected result: Built-in mic is available for use. Actual result: Built-in mic is missing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1959681/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1908219] Re: [drm:qxl_enc_commit [qxl]] *ERROR* head number too large or missing monitors config:
I have tested this in a VM with kernel 4.15.0-131.135 installed and I
can confirm the issue is gone.
** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic
--
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/1908219
Title:
[drm:qxl_enc_commit [qxl]] *ERROR* head number too large or missing
monitors config:
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Bionic:
Fix Committed
Bug description:
[Impact]
* Ubuntu 18.04 used as a guest in KVM with Spice/QXL in use may lead to a DRM
error displayed during xorg launch:
[drm:qxl_enc_commit [qxl]] *ERROR* head number too large or missing monitors
config: (ptrval), 0
[Fix]
* 00e5d217fa19bcbec13135898e1b9ca2c1c3e89b qxl: hook monitors_config
updates into crtc, not encoder.
[Test Case]
* Ubuntu 18.04 desktop guest with 4.15-series kernel with Spice/QXL.
* I used Ubuntu 20.04 as the host, but I was reported that the issue is
similar also on Centos 7.8 used as a host.
[Regression Potential]
* Fix is limited to the QXL driver, so any regressions will be related
to graphics (either potential drm errors or graphical artifacts).
[Other]
* This has been fixed in HWE kernels and in later Ubuntu releases. Only
Bionic is affected.
* According to the description in drivers/gpu/drm/qxl/qxl_dev.h:
struct qxl_monitors_config {
(...)
uint16_t max_allowed; /* If it is 0 no fixed limit is given by the
driver */
(...)
};
In the message this value is 0 which should be a completely correct situation
in that context. However, it is incorrectly compared against current qxl_output.
This has been fixed soon after Bionic release and in Bionic is marked with:
/* TODO: ugly, do better */
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1908219/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2044131] Re: i915 regression introduced with 5.5 kernel
** Attachment added: "stacktrace" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2044131/+attachment/5721684/+files/stacktrace -- 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/2044131 Title: i915 regression introduced with 5.5 kernel Status in linux package in Ubuntu: New Bug description: There is a regression preventing a user to upgrade from 5.4 kernel to anything that's higher than 5.5. When using such kernel the image orientation is wrong (rotated by 90°C). Also the kernel log contains: wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] Unknown revid 0x06 wrz 15 09:19:49 desktop kernel: rtw_8821ce :01:00.0: Firmware version 24.8.0, H2C version 12 wrz 15 09:19:49 desktop kernel: Console: switching to colour dummy device 80x25 wrz 15 09:19:49 desktop kernel: i915 :00:02.0: vgaarb: deactivate vga console wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] couldn't get memory information wrz 15 09:19:49 desktop kernel: i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:o> wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v> wrz 15 09:19:49 desktop kernel: wrz 15 09:19:49 desktop kernel: UBSAN: array-index-out-of-bounds in /build/linux-hwe-5.15-DZkSuT/linux-hwe-5.15-5.> wrz 15 09:19:49 desktop kernel: index 5 is out of range for type 'u32 [5]' (full stack trace attached) The video hardware in use is: 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 605 [8086:3185] (rev 06) (prog-if 00 [VGA controller]) (...) Kernel driver in use: i915 Kernel modules: i915 The user wanted to upgrade from bionic to focal with HWE kernel (they needed it due to some networking hardware they wanted to have supported by the newer kernel). The user was testing mainline stable kernels and noticed that the last working kernel was the 5.4 series, while anything starting from 5.5 and above is BROKEN (symptoms as described in the first paragraph above). Together with the user we have run a bisection between v5.4 and v5.5 on the upstream stable kernel and we were able to identify the first broken commit to be: 8f4b1068e7fc3df1a77ac8151767e56b208cc87f drm/i915: Check some transcoder timing minimum limits To confirm I have reverted this change on top of the HWE kernel for focal and the user have confirmed that this resolved the issue (test build available at ppa:dgadomski/kernel-sf368743). I am not fully sure what the purpose of this patch was, but I assume the regression was not intended and the hardware should be still supported. Attaching lshw and lspci output. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2044131/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2044131] Re: i915 regression introduced with 5.5 kernel
** Attachment added: "lshw" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2044131/+attachment/5721685/+files/lshw -- 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/2044131 Title: i915 regression introduced with 5.5 kernel Status in linux package in Ubuntu: New Bug description: There is a regression preventing a user to upgrade from 5.4 kernel to anything that's higher than 5.5. When using such kernel the image orientation is wrong (rotated by 90°C). Also the kernel log contains: wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] Unknown revid 0x06 wrz 15 09:19:49 desktop kernel: rtw_8821ce :01:00.0: Firmware version 24.8.0, H2C version 12 wrz 15 09:19:49 desktop kernel: Console: switching to colour dummy device 80x25 wrz 15 09:19:49 desktop kernel: i915 :00:02.0: vgaarb: deactivate vga console wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] couldn't get memory information wrz 15 09:19:49 desktop kernel: i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:o> wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v> wrz 15 09:19:49 desktop kernel: wrz 15 09:19:49 desktop kernel: UBSAN: array-index-out-of-bounds in /build/linux-hwe-5.15-DZkSuT/linux-hwe-5.15-5.> wrz 15 09:19:49 desktop kernel: index 5 is out of range for type 'u32 [5]' (full stack trace attached) The video hardware in use is: 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 605 [8086:3185] (rev 06) (prog-if 00 [VGA controller]) (...) Kernel driver in use: i915 Kernel modules: i915 The user wanted to upgrade from bionic to focal with HWE kernel (they needed it due to some networking hardware they wanted to have supported by the newer kernel). The user was testing mainline stable kernels and noticed that the last working kernel was the 5.4 series, while anything starting from 5.5 and above is BROKEN (symptoms as described in the first paragraph above). Together with the user we have run a bisection between v5.4 and v5.5 on the upstream stable kernel and we were able to identify the first broken commit to be: 8f4b1068e7fc3df1a77ac8151767e56b208cc87f drm/i915: Check some transcoder timing minimum limits To confirm I have reverted this change on top of the HWE kernel for focal and the user have confirmed that this resolved the issue (test build available at ppa:dgadomski/kernel-sf368743). I am not fully sure what the purpose of this patch was, but I assume the regression was not intended and the hardware should be still supported. Attaching lshw and lspci output. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2044131/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2044131] [NEW] i915 regression introduced with 5.5 kernel
Public bug reported: There is a regression preventing a user to upgrade from 5.4 kernel to anything that's higher than 5.5. When using such kernel the image orientation is wrong (rotated by 90°C). Also the kernel log contains: wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] Unknown revid 0x06 wrz 15 09:19:49 desktop kernel: rtw_8821ce :01:00.0: Firmware version 24.8.0, H2C version 12 wrz 15 09:19:49 desktop kernel: Console: switching to colour dummy device 80x25 wrz 15 09:19:49 desktop kernel: i915 :00:02.0: vgaarb: deactivate vga console wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] couldn't get memory information wrz 15 09:19:49 desktop kernel: i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:o> wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v> wrz 15 09:19:49 desktop kernel: wrz 15 09:19:49 desktop kernel: UBSAN: array-index-out-of-bounds in /build/linux-hwe-5.15-DZkSuT/linux-hwe-5.15-5.> wrz 15 09:19:49 desktop kernel: index 5 is out of range for type 'u32 [5]' (full stack trace attached) The video hardware in use is: 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 605 [8086:3185] (rev 06) (prog-if 00 [VGA controller]) (...) Kernel driver in use: i915 Kernel modules: i915 The user wanted to upgrade from bionic to focal with HWE kernel (they needed it due to some networking hardware they wanted to have supported by the newer kernel). The user was testing mainline stable kernels and noticed that the last working kernel was the 5.4 series, while anything starting from 5.5 and above is BROKEN (symptoms as described in the first paragraph above). Together with the user we have run a bisection between v5.4 and v5.5 on the upstream stable kernel and we were able to identify the first broken commit to be: 8f4b1068e7fc3df1a77ac8151767e56b208cc87f drm/i915: Check some transcoder timing minimum limits To confirm I have reverted this change on top of the HWE kernel for focal and the user have confirmed that this resolved the issue (test build available at ppa:dgadomski/kernel-sf368743). I am not fully sure what the purpose of this patch was, but I assume the regression was not intended and the hardware should be still supported. Attaching lshw and lspci output. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: se sts -- 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/2044131 Title: i915 regression introduced with 5.5 kernel Status in linux package in Ubuntu: New Bug description: There is a regression preventing a user to upgrade from 5.4 kernel to anything that's higher than 5.5. When using such kernel the image orientation is wrong (rotated by 90°C). Also the kernel log contains: wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] Unknown revid 0x06 wrz 15 09:19:49 desktop kernel: rtw_8821ce :01:00.0: Firmware version 24.8.0, H2C version 12 wrz 15 09:19:49 desktop kernel: Console: switching to colour dummy device 80x25 wrz 15 09:19:49 desktop kernel: i915 :00:02.0: vgaarb: deactivate vga console wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] couldn't get memory information wrz 15 09:19:49 desktop kernel: i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:o> wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v> wrz 15 09:19:49 desktop kernel: wrz 15 09:19:49 desktop kernel: UBSAN: array-index-out-of-bounds in /build/linux-hwe-5.15-DZkSuT/linux-hwe-5.15-5.> wrz 15 09:19:49 desktop kernel: index 5 is out of range for type 'u32 [5]' (full stack trace attached) The video hardware in use is: 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 605 [8086:3185] (rev 06) (prog-if 00 [VGA controller]) (...) Kernel driver in use: i915 Kernel modules: i915 The user wanted to upgrade from bionic to focal with HWE kernel (they needed it due to some networking hardware they wanted to have supported by the newer kernel). The user was testing mainline stable kernels and noticed that the last working kernel was the 5.4 series, while anything starting from 5.5 and above is BROKEN (symptoms as described in the first paragraph above). Together with the user we have run a bisection between v5.4 and v5.5 on the upstream stable kernel and we were able to identify the first broken commit to be: 8f4b1068e7fc3df1a77ac8151767e56b208cc87f drm/i915: Check some transcoder timing minimum limits To confirm I have reverted this change on top of the HWE kernel for
[Kernel-packages] [Bug 2044131] Re: i915 regression introduced with 5.5 kernel
** Attachment added: "lspci" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2044131/+attachment/5721686/+files/lspci ** Tags added: se sts -- 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/2044131 Title: i915 regression introduced with 5.5 kernel Status in linux package in Ubuntu: New Bug description: There is a regression preventing a user to upgrade from 5.4 kernel to anything that's higher than 5.5. When using such kernel the image orientation is wrong (rotated by 90°C). Also the kernel log contains: wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] Unknown revid 0x06 wrz 15 09:19:49 desktop kernel: rtw_8821ce :01:00.0: Firmware version 24.8.0, H2C version 12 wrz 15 09:19:49 desktop kernel: Console: switching to colour dummy device 80x25 wrz 15 09:19:49 desktop kernel: i915 :00:02.0: vgaarb: deactivate vga console wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] couldn't get memory information wrz 15 09:19:49 desktop kernel: i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:o> wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v> wrz 15 09:19:49 desktop kernel: wrz 15 09:19:49 desktop kernel: UBSAN: array-index-out-of-bounds in /build/linux-hwe-5.15-DZkSuT/linux-hwe-5.15-5.> wrz 15 09:19:49 desktop kernel: index 5 is out of range for type 'u32 [5]' (full stack trace attached) The video hardware in use is: 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 605 [8086:3185] (rev 06) (prog-if 00 [VGA controller]) (...) Kernel driver in use: i915 Kernel modules: i915 The user wanted to upgrade from bionic to focal with HWE kernel (they needed it due to some networking hardware they wanted to have supported by the newer kernel). The user was testing mainline stable kernels and noticed that the last working kernel was the 5.4 series, while anything starting from 5.5 and above is BROKEN (symptoms as described in the first paragraph above). Together with the user we have run a bisection between v5.4 and v5.5 on the upstream stable kernel and we were able to identify the first broken commit to be: 8f4b1068e7fc3df1a77ac8151767e56b208cc87f drm/i915: Check some transcoder timing minimum limits To confirm I have reverted this change on top of the HWE kernel for focal and the user have confirmed that this resolved the issue (test build available at ppa:dgadomski/kernel-sf368743). I am not fully sure what the purpose of this patch was, but I assume the regression was not intended and the hardware should be still supported. Attaching lshw and lspci output. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2044131/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2044131] Re: i915 regression introduced with 5.5 kernel
The commit in question (8f4b1068e7fc3df1a77ac8151767e56b208cc87f)
introduces the following logic in intel_mode_valid function
(drivers/gpu/drm/i915/display/intel_display.c):
+ if (DISPLAY_VER(dev_priv) >= 5) {
+ if (mode->hdisplay < 64 ||
+ mode->htotal - mode->hdisplay < 32)
+ return MODE_H_ILLEGAL;
+
+ if (mode->vtotal - mode->vdisplay < 5)
+ return MODE_V_ILLEGAL;
+ } else {
+ if (mode->htotal - mode->hdisplay < 32)
+ return MODE_H_ILLEGAL;
+
+ if (mode->vtotal - mode->vdisplay < 3)
+ return MODE_V_ILLEGAL;
+ }
In case of this particular hardware the following condition is met:
if (mode->htotal - mode->hdisplay < 32)
return MODE_H_ILLEGAL;
with values: htotal==830 and hdisplay=800 resulting in returning
MODE_H_ILLEGAL.
I am looking into where does the htotal value come from.
--
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/2044131
Title:
i915 regression introduced with 5.5 kernel
Status in linux package in Ubuntu:
New
Bug description:
There is a regression preventing a user to upgrade from 5.4 kernel to
anything that's higher than 5.5. When using such kernel the image orientation
is wrong (rotated by 90°C). Also the kernel log contains:
wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] Unknown revid 0x06
wrz 15 09:19:49 desktop kernel: rtw_8821ce :01:00.0: Firmware version
24.8.0, H2C version 12
wrz 15 09:19:49 desktop kernel: Console: switching to colour dummy device
80x25
wrz 15 09:19:49 desktop kernel: i915 :00:02.0: vgaarb: deactivate vga
console
wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] couldn't get memory
information
wrz 15 09:19:49 desktop kernel: i915 :00:02.0: vgaarb: changed VGA
decodes: olddecodes=io+mem,decodes=io+mem:o>
wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] Finished loading DMC
firmware i915/glk_dmc_ver1_04.bin (v>
wrz 15 09:19:49 desktop kernel:
wrz 15 09:19:49 desktop kernel: UBSAN: array-index-out-of-bounds in
/build/linux-hwe-5.15-DZkSuT/linux-hwe-5.15-5.>
wrz 15 09:19:49 desktop kernel: index 5 is out of range for type 'u32 [5]'
(full stack trace attached)
The video hardware in use is:
00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 605
[8086:3185] (rev 06) (prog-if 00 [VGA controller])
(...)
Kernel driver in use: i915
Kernel modules: i915
The user wanted to upgrade from bionic to focal with HWE kernel (they
needed it due to some networking hardware they wanted to have
supported by the newer kernel).
The user was testing mainline stable kernels and noticed that the last
working kernel was the 5.4 series, while anything starting from 5.5
and above is BROKEN (symptoms as described in the first paragraph
above).
Together with the user we have run a bisection between v5.4 and v5.5 on the
upstream stable kernel and we were able to identify the first broken commit to
be:
8f4b1068e7fc3df1a77ac8151767e56b208cc87f drm/i915: Check some transcoder
timing minimum limits
To confirm I have reverted this change on top of the HWE kernel for
focal and the user have confirmed that this resolved the issue (test
build available at ppa:dgadomski/kernel-sf368743).
I am not fully sure what the purpose of this patch was, but I assume
the regression was not intended and the hardware should be still
supported.
Attaching lshw and lspci output.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2044131/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2044131] Re: i915 regression introduced with 5.5 kernel
Looks like this is hardware-specific and read from BIOS: [drm:intel_bios_init [i915]] Found panel mode in BIOS VBT legacy lfp table: [drm:drm_mode_debug_printmodeline [drm]] Modeline "800x1280": 50 54000 800 810 820 830 1280 1290 1300 1310 0x8 0xa -- 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/2044131 Title: i915 regression introduced with 5.5 kernel Status in linux package in Ubuntu: New Bug description: There is a regression preventing a user to upgrade from 5.4 kernel to anything that's higher than 5.5. When using such kernel the image orientation is wrong (rotated by 90°C). Also the kernel log contains: wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] Unknown revid 0x06 wrz 15 09:19:49 desktop kernel: rtw_8821ce :01:00.0: Firmware version 24.8.0, H2C version 12 wrz 15 09:19:49 desktop kernel: Console: switching to colour dummy device 80x25 wrz 15 09:19:49 desktop kernel: i915 :00:02.0: vgaarb: deactivate vga console wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] couldn't get memory information wrz 15 09:19:49 desktop kernel: i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:o> wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v> wrz 15 09:19:49 desktop kernel: wrz 15 09:19:49 desktop kernel: UBSAN: array-index-out-of-bounds in /build/linux-hwe-5.15-DZkSuT/linux-hwe-5.15-5.> wrz 15 09:19:49 desktop kernel: index 5 is out of range for type 'u32 [5]' (full stack trace attached) The video hardware in use is: 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 605 [8086:3185] (rev 06) (prog-if 00 [VGA controller]) (...) Kernel driver in use: i915 Kernel modules: i915 The user wanted to upgrade from bionic to focal with HWE kernel (they needed it due to some networking hardware they wanted to have supported by the newer kernel). The user was testing mainline stable kernels and noticed that the last working kernel was the 5.4 series, while anything starting from 5.5 and above is BROKEN (symptoms as described in the first paragraph above). Together with the user we have run a bisection between v5.4 and v5.5 on the upstream stable kernel and we were able to identify the first broken commit to be: 8f4b1068e7fc3df1a77ac8151767e56b208cc87f drm/i915: Check some transcoder timing minimum limits To confirm I have reverted this change on top of the HWE kernel for focal and the user have confirmed that this resolved the issue (test build available at ppa:dgadomski/kernel-sf368743). I am not fully sure what the purpose of this patch was, but I assume the regression was not intended and the hardware should be still supported. Attaching lshw and lspci output. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2044131/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2044131] Re: i915 regression introduced with 5.5 kernel
Fields in the "Modeline" output are: (m)->name, drm_mode_vrefresh(m), (m)->clock, \ (m)->hdisplay, (m)->hsync_start, (m)->hsync_end, (m)->htotal, \ (m)->vdisplay, (m)->vsync_start, (m)->vsync_end, (m)->vtotal, \ (m)->type, (m)->flags -- 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/2044131 Title: i915 regression introduced with 5.5 kernel Status in linux package in Ubuntu: New Bug description: There is a regression preventing a user to upgrade from 5.4 kernel to anything that's higher than 5.5. When using such kernel the image orientation is wrong (rotated by 90°C). Also the kernel log contains: wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] Unknown revid 0x06 wrz 15 09:19:49 desktop kernel: rtw_8821ce :01:00.0: Firmware version 24.8.0, H2C version 12 wrz 15 09:19:49 desktop kernel: Console: switching to colour dummy device 80x25 wrz 15 09:19:49 desktop kernel: i915 :00:02.0: vgaarb: deactivate vga console wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] couldn't get memory information wrz 15 09:19:49 desktop kernel: i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:o> wrz 15 09:19:49 desktop kernel: i915 :00:02.0: [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v> wrz 15 09:19:49 desktop kernel: wrz 15 09:19:49 desktop kernel: UBSAN: array-index-out-of-bounds in /build/linux-hwe-5.15-DZkSuT/linux-hwe-5.15-5.> wrz 15 09:19:49 desktop kernel: index 5 is out of range for type 'u32 [5]' (full stack trace attached) The video hardware in use is: 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 605 [8086:3185] (rev 06) (prog-if 00 [VGA controller]) (...) Kernel driver in use: i915 Kernel modules: i915 The user wanted to upgrade from bionic to focal with HWE kernel (they needed it due to some networking hardware they wanted to have supported by the newer kernel). The user was testing mainline stable kernels and noticed that the last working kernel was the 5.4 series, while anything starting from 5.5 and above is BROKEN (symptoms as described in the first paragraph above). Together with the user we have run a bisection between v5.4 and v5.5 on the upstream stable kernel and we were able to identify the first broken commit to be: 8f4b1068e7fc3df1a77ac8151767e56b208cc87f drm/i915: Check some transcoder timing minimum limits To confirm I have reverted this change on top of the HWE kernel for focal and the user have confirmed that this resolved the issue (test build available at ppa:dgadomski/kernel-sf368743). I am not fully sure what the purpose of this patch was, but I assume the regression was not intended and the hardware should be still supported. Attaching lshw and lspci output. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2044131/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
