[Kernel-packages] [Bug 1983071] Re: [L860-R+] Need to manually reconnect to cellular after waking from cold boot/reboot/airplane mode/wwan radio disabled/reboot/s0ix state
** Information type changed from Private to Public ** Information type changed from Public to Private Security -- 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/1983071 Title: [L860-R+] Need to manually reconnect to cellular after waking from cold boot/reboot/airplane mode/wwan radio disabled/reboot/s0ix state Status in Canonical HWE Sutton: New Status in linux package in Ubuntu: New Bug description: [Description] After resuming from states such as airplane mode, reboot, cold boot, s0ix and wwan radio disabled, user needs to manually connect using the "nmcli conn up " command or turn off Mobile broadband and connect to the APN profile to be able to connect to cellular. Need more information why stalling is happening with reconnection using this kernel. [Expected Result] After resuming from the mentioned states, user should be able to establish Mobile broadband connection right after selecting the APN profile right away. [Actual Result] After resuming from the mentioned states, user is unable to establish Mobile broadband connection right after selecting the APN profile right away. [Workaround] User needs to manually reconnect to cellular by either of the following: 1) running nmcli conn up '' 2) turning off Mobile broadband and then reconnecting to the APN profile via Mobile broadband GUI In the attached zip file, modem logs were collected following the results: [Airplane mode] 1 minute - PASS 5 minutes - FAIL 15 minutes - FAIL [WWAN radio] 1 minute - PASS 5 minutes - PASS 15 minutes - FAIL [S0ix] 1 minute - PASS 5 minutes - FAIL ([manufacturer unknown] model unknown/mobile broadband unavailable error appears) 15 minutes - N/A According to Intel, "In logs it is observed that there is ~1 minute gap between modem being enabled back after airplane mode and pdp getting established. This stall is not alone in MM. Syslog indicates that there is stall in entire system level logging for almost a min. After this stall, MM is able to establish successful PDP connection within the same second." Jul 13 16:05:56 ubuntu-ThinkPad-T14-Gen-3 systemd[1]: systemd-rfkill.service: Succeeded. Jul 13 16:06:51 ubuntu-ThinkPad-T14-Gen-3 ModemManager[811]: [modem1] 3GPP registration state changed (home -> idle) Jul 13 16:06:51 ubuntu-ThinkPad-T14-Gen-3 ModemManager[811]: [modem1] state changed (connecting -> connected) Jul 13 16:06:51 ubuntu-ThinkPad-T14-Gen-3 ModemManager[811]: [modem1] simple connect state (8/8): all done "In the provided logs I can see that there is no issue or delay observed in establishment of PDP connection. It is taking approximately 4-6 seconds for PDP establishment. Please find file level analysis as below." radio.txt- - "Only one instance of airplane mode toggling was observed. PDP re-established within ~4 seconds of switching off airplane mode and within ~2 seconds of registration." ModemManager[4773]: [1658906907.307452] [modem0] updating power state: 'on'... ModemManager[4773]: [1658906909.236937] [modem0] state changed (enabled -> registered) ModemManager[4773]: [1658906911.841261] [modem0] simple connect started... ModemManager[4773]: [1658906911.854284] [modem0] state changed (connecting -> connected) s0ix.txt- -- "No instance of airplane mode toggling. During boot up PDP has been established within the same second of PDP connection request." ModemManager[5412]: [1658908777.915076] [modem0] updating power state: 'on'... ModemManager[5412]: [1658908779.774030] [modem0] state changed (enabled -> registered) ModemManager[5412]: [1658908789.113728] [modem0] simple connect started... ModemManager[5412]: [1658908789.129582] [modem0] state changed (connecting -> connected) "There seems to be an issue with data connection observed later though. MM is triggering PDP connection request and modem is responding with error. Need to be analysed from modem end what is the issue." ModemManager[5412]: [1658908877.516999] [modem1/bearer3] connection attempt #1 failed: Unknown error ModemManager[5412]: [1658908877.613880] [modem1/bearer3] connection attempt #2 failed: Unknown error ModemManager[5412]: [1658908877.717007] [modem1/bearer3] connection attempt #3 failed: Unknown error ModemManager[5412]: [1658908877.821648] [modem1/bearer3] connection attempt #4 failed: Unknown error ModemManager[5412]: [1658908877.933048] [modem1/bearer4] connection attempt #1 failed: Unknown error ModemManager[5412]: [1658908877.989101] [modem1/bearer5] connection attempt #1 failed: Unknown error ModemManager[5412]: [1658908878.073209] [modem1/bearer6] connection attempt #1 failed: Unknown error ModemManager[5412]: [1658908878.173125] [modem1/bearer4] connection
[Kernel-packages] [Bug 1983071] [NEW] [L860-R+] Need to manually reconnect to cellular after waking from cold boot/reboot/airplane mode/wwan radio disabled/reboot/s0ix state
Private bug reported: [Description] After resuming from states such as airplane mode, reboot, cold boot, s0ix and wwan radio disabled, user needs to manually connect using the "nmcli conn up " command or turn off Mobile broadband and connect to the APN profile to be able to connect to cellular. Need more information why stalling is happening with reconnection using this kernel. [Expected Result] After resuming from the mentioned states, user should be able to establish Mobile broadband connection right after selecting the APN profile right away. [Actual Result] After resuming from the mentioned states, user is unable to establish Mobile broadband connection right after selecting the APN profile right away. [Workaround] User needs to manually reconnect to cellular by either of the following: 1) running nmcli conn up '' 2) turning off Mobile broadband and then reconnecting to the APN profile via Mobile broadband GUI In the attached zip file, modem logs were collected following the results: [Airplane mode] 1 minute - PASS 5 minutes - FAIL 15 minutes - FAIL [WWAN radio] 1 minute - PASS 5 minutes - PASS 15 minutes - FAIL [S0ix] 1 minute - PASS 5 minutes - FAIL ([manufacturer unknown] model unknown/mobile broadband unavailable error appears) 15 minutes - N/A According to Intel, "In logs it is observed that there is ~1 minute gap between modem being enabled back after airplane mode and pdp getting established. This stall is not alone in MM. Syslog indicates that there is stall in entire system level logging for almost a min. After this stall, MM is able to establish successful PDP connection within the same second." Jul 13 16:05:56 ubuntu-ThinkPad-T14-Gen-3 systemd[1]: systemd-rfkill.service: Succeeded. Jul 13 16:06:51 ubuntu-ThinkPad-T14-Gen-3 ModemManager[811]: [modem1] 3GPP registration state changed (home -> idle) Jul 13 16:06:51 ubuntu-ThinkPad-T14-Gen-3 ModemManager[811]: [modem1] state changed (connecting -> connected) Jul 13 16:06:51 ubuntu-ThinkPad-T14-Gen-3 ModemManager[811]: [modem1] simple connect state (8/8): all done "In the provided logs I can see that there is no issue or delay observed in establishment of PDP connection. It is taking approximately 4-6 seconds for PDP establishment. Please find file level analysis as below." radio.txt- - "Only one instance of airplane mode toggling was observed. PDP re-established within ~4 seconds of switching off airplane mode and within ~2 seconds of registration." ModemManager[4773]: [1658906907.307452] [modem0] updating power state: 'on'... ModemManager[4773]: [1658906909.236937] [modem0] state changed (enabled -> registered) ModemManager[4773]: [1658906911.841261] [modem0] simple connect started... ModemManager[4773]: [1658906911.854284] [modem0] state changed (connecting -> connected) s0ix.txt- -- "No instance of airplane mode toggling. During boot up PDP has been established within the same second of PDP connection request." ModemManager[5412]: [1658908777.915076] [modem0] updating power state: 'on'... ModemManager[5412]: [1658908779.774030] [modem0] state changed (enabled -> registered) ModemManager[5412]: [1658908789.113728] [modem0] simple connect started... ModemManager[5412]: [1658908789.129582] [modem0] state changed (connecting -> connected) "There seems to be an issue with data connection observed later though. MM is triggering PDP connection request and modem is responding with error. Need to be analysed from modem end what is the issue." ModemManager[5412]: [1658908877.516999] [modem1/bearer3] connection attempt #1 failed: Unknown error ModemManager[5412]: [1658908877.613880] [modem1/bearer3] connection attempt #2 failed: Unknown error ModemManager[5412]: [1658908877.717007] [modem1/bearer3] connection attempt #3 failed: Unknown error ModemManager[5412]: [1658908877.821648] [modem1/bearer3] connection attempt #4 failed: Unknown error ModemManager[5412]: [1658908877.933048] [modem1/bearer4] connection attempt #1 failed: Unknown error ModemManager[5412]: [1658908877.989101] [modem1/bearer5] connection attempt #1 failed: Unknown error ModemManager[5412]: [1658908878.073209] [modem1/bearer6] connection attempt #1 failed: Unknown error ModemManager[5412]: [1658908878.173125] [modem1/bearer4] connection attempt #2 failed: Unknown error ModemManager[5412]: [1658908878.253013] [modem1/bearer5] connection attempt #2 failed: Unknown error ModemManager[5412]: [1658908878.333056] [modem1/bearer6] connection attempt #2 failed: Unknown error ModemManager[5412]: [1658908878.440927] [modem1/bearer4] connection attempt #3 failed: Unknown error ModemManager[5412]: [1658908878.521164] [modem1/bearer5] connection attempt #3 failed: Unknown error ModemManager[5412]: [1658908878.601119] [modem1/bearer6] connection attempt #3 failed: Unknown error ModemManager[5412]: [1658908878.684948] [modem1/bearer4] connection attempt #4 failed: Unknown error ModemManager[5412]:
[Kernel-packages] [Bug 1978745] [NEW] Need to delete existing APN profiles in Mobile broadband GUI to connect to cellular
Public bug reported: [Description] During initial setup, user needs to delete all the existing APN profiles listed in the Mobile broadband GUI and create a new one in order to connect to cellular [Expected results] If an APN profile of the current sim is already existing in the mobile broadband GUI, system should be able to connect to cellular by using the existing profile [Actual results] If an APN profile of the current sim being used is already existing in the mobile broadband GUI, the system fails to connect using the existing profile. [Steps to reproduce] 1. Create the APN profile for the sim card to be used. 2. Turn off the system and insert the sim card into the sim card slot. 3. Turn on the system and enter the password (if needed). Boot to OS. 4. Connect to cellular by selecting "Mobile broadband" under the system tray and selecting the name of the APN profile previously created. Notice that connection is unable to be established ==> PROBLEM [Workaround] Delete all existing APN profiles and create a new APN profile. Ubuntu release version: Ubuntu 20.04.4 LTS Kernel version: 5.15.0-33-generic (hwe-kernel) ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.15.0-33-generic 5.15.0-33.34~20.04.1 ProcVersionSignature: Ubuntu 5.15.0-33.34~20.04.1-generic 5.15.30 Uname: Linux 5.15.0-33-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Wed Jun 15 10:03:28 2022 InstallationDate: Installed on 2022-06-01 (13 days ago) InstallationMedia: Ubuntu 20.04.4 LTS "Focal Fossa" - Release amd64 (20220223) SourcePackage: linux-signed-hwe-5.15 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: linux-signed-hwe-5.15 (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal third-party-packages -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-hwe-5.15 in Ubuntu. https://bugs.launchpad.net/bugs/1978745 Title: Need to delete existing APN profiles in Mobile broadband GUI to connect to cellular Status in linux-signed-hwe-5.15 package in Ubuntu: New Bug description: [Description] During initial setup, user needs to delete all the existing APN profiles listed in the Mobile broadband GUI and create a new one in order to connect to cellular [Expected results] If an APN profile of the current sim is already existing in the mobile broadband GUI, system should be able to connect to cellular by using the existing profile [Actual results] If an APN profile of the current sim being used is already existing in the mobile broadband GUI, the system fails to connect using the existing profile. [Steps to reproduce] 1. Create the APN profile for the sim card to be used. 2. Turn off the system and insert the sim card into the sim card slot. 3. Turn on the system and enter the password (if needed). Boot to OS. 4. Connect to cellular by selecting "Mobile broadband" under the system tray and selecting the name of the APN profile previously created. Notice that connection is unable to be established ==> PROBLEM [Workaround] Delete all existing APN profiles and create a new APN profile. Ubuntu release version: Ubuntu 20.04.4 LTS Kernel version: 5.15.0-33-generic (hwe-kernel) ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.15.0-33-generic 5.15.0-33.34~20.04.1 ProcVersionSignature: Ubuntu 5.15.0-33.34~20.04.1-generic 5.15.30 Uname: Linux 5.15.0-33-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Wed Jun 15 10:03:28 2022 InstallationDate: Installed on 2022-06-01 (13 days ago) InstallationMedia: Ubuntu 20.04.4 LTS "Focal Fossa" - Release amd64 (20220223) SourcePackage: linux-signed-hwe-5.15 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.15/+bug/1978745/+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 1888164] Re: Cannot re-pair Bluetooth Keyboard when wrong pairing code is entered
I'm attaching the captured btsnoop logs ** Description changed: Expected behavior: 1.Pressing the “Cancel” button during device pairing should close the pairing code prompt 2.Re-pairing BT keyboard after cancelling initial pairing should re-open the pairing code prompt Problem: 1.Pressing the “Cancel” button during device pairing does not close the pairing code prompt 2.Re-pairing BT keyboard after cancelling initial pairing does not show the pairing code prompt. Steps: 1.Turn on the system’s Bluetooth (usually turned on by default on boot) 2.Try to pair the system with the BT Keyboard via the Bluetooth Settings UI 3.When the pairing code prompt appears, input the wrong code and press enter. This should generate a new code 4.Press “Cancel” on the pairing code prompt. Notice that the cancel button is not working. 5.Press the Esc button on the system’s keyboard. This should close the pairing code prompt. 6.Try re-pairing the system with the BT Keyboard via the Bluetooth Settings UI. 7.Notice that the connection is loading but the pairing code prompt does not reappear. The system and the BT keyboard cannot be re-paired. Workaround: 1.When a new code is generated in Step 3, input the correct code. This would successfully pair the system and the BT keyboard. 2.Try rebooting the system after Step 7 to recover the connection. Notes: - Keyboards tested: - > ThinkPad Compact Bluetooth Keyboard - > Microsoft Designer Keyboard + > ThinkPad Compact Bluetooth Keyboard + > Microsoft Designer Keyboard - Issue does not happen in Windows OS + - I have reported this issue to Intel and they didn't see any error from the connection logs. We are suspecting that this has to do with the Bluetooth UI instead. ** Package changed: bluez (Ubuntu) => gnome-bluetooth (Ubuntu) ** Attachment added: "btsnoop logs" https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/1888164/+attachment/5394187/+files/new_ubuntu_btsnoop.log -- 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/1888164 Title: Cannot re-pair Bluetooth Keyboard when wrong pairing code is entered Status in gnome-bluetooth package in Ubuntu: New Bug description: Expected behavior: 1.Pressing the “Cancel” button during device pairing should close the pairing code prompt 2.Re-pairing BT keyboard after cancelling initial pairing should re-open the pairing code prompt Problem: 1.Pressing the “Cancel” button during device pairing does not close the pairing code prompt 2.Re-pairing BT keyboard after cancelling initial pairing does not show the pairing code prompt. Steps: 1.Turn on the system’s Bluetooth (usually turned on by default on boot) 2.Try to pair the system with the BT Keyboard via the Bluetooth Settings UI 3.When the pairing code prompt appears, input the wrong code and press enter. This should generate a new code 4.Press “Cancel” on the pairing code prompt. Notice that the cancel button is not working. 5.Press the Esc button on the system’s keyboard. This should close the pairing code prompt. 6.Try re-pairing the system with the BT Keyboard via the Bluetooth Settings UI. 7.Notice that the connection is loading but the pairing code prompt does not reappear. The system and the BT keyboard cannot be re-paired. Workaround: 1.When a new code is generated in Step 3, input the correct code. This would successfully pair the system and the BT keyboard. 2.Try rebooting the system after Step 7 to recover the connection. Notes: - Keyboards tested: > ThinkPad Compact Bluetooth Keyboard > Microsoft Designer Keyboard - Issue does not happen in Windows OS - I have reported this issue to Intel and they didn't see any error from the connection logs. We are suspecting that this has to do with the Bluetooth UI instead. - Bluez version: 5.53 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/1888164/+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 1888164] [NEW] Cannot re-pair Bluetooth Keyboard when wrong pairing code is entered
Public bug reported: Expected behavior: 1. Pressing the “Cancel” button during device pairing should close the pairing code prompt 2. Re-pairing BT keyboard after cancelling initial pairing should re-open the pairing code prompt Problem: 1. Pressing the “Cancel” button during device pairing does not close the pairing code prompt 2. Re-pairing BT keyboard after cancelling initial pairing does not show the pairing code prompt. Steps: 1. Turn on the system’s Bluetooth (usually turned on by default on boot) 2. Try to pair the system with the BT Keyboard via the Bluetooth Settings UI 3. When the pairing code prompt appears, input the wrong code and press enter. This should generate a new code 4. Press “Cancel” on the pairing code prompt. Notice that the cancel button is not working. 5. Press the Esc button on the system’s keyboard. This should close the pairing code prompt. 6. Try re-pairing the system with the BT Keyboard via the Bluetooth Settings UI. 7. Notice that the connection is loading but the pairing code prompt does not reappear. The system and the BT keyboard cannot be re-paired. Workaround: 1. When a new code is generated in Step 3, input the correct code. This would successfully pair the system and the BT keyboard. 2. Try rebooting the system after Step 7 to recover the connection. Notes: - Keyboards tested: > ThinkPad Compact Bluetooth Keyboard > Microsoft Designer Keyboard - Issue does not happen in Windows OS ** 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/1888164 Title: Cannot re-pair Bluetooth Keyboard when wrong pairing code is entered Status in bluez package in Ubuntu: New Bug description: Expected behavior: 1.Pressing the “Cancel” button during device pairing should close the pairing code prompt 2.Re-pairing BT keyboard after cancelling initial pairing should re-open the pairing code prompt Problem: 1.Pressing the “Cancel” button during device pairing does not close the pairing code prompt 2.Re-pairing BT keyboard after cancelling initial pairing does not show the pairing code prompt. Steps: 1.Turn on the system’s Bluetooth (usually turned on by default on boot) 2.Try to pair the system with the BT Keyboard via the Bluetooth Settings UI 3.When the pairing code prompt appears, input the wrong code and press enter. This should generate a new code 4.Press “Cancel” on the pairing code prompt. Notice that the cancel button is not working. 5.Press the Esc button on the system’s keyboard. This should close the pairing code prompt. 6.Try re-pairing the system with the BT Keyboard via the Bluetooth Settings UI. 7.Notice that the connection is loading but the pairing code prompt does not reappear. The system and the BT keyboard cannot be re-paired. Workaround: 1.When a new code is generated in Step 3, input the correct code. This would successfully pair the system and the BT keyboard. 2.Try rebooting the system after Step 7 to recover the connection. Notes: - Keyboards tested: > ThinkPad Compact Bluetooth Keyboard > Microsoft Designer Keyboard - Issue does not happen in Windows OS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1888164/+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 1879438] Re: bluetooth file transfer via bluetooth UI is too slow
Hi @Sebastien, sorry for the late reply. I have reported the bug on bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208227 ** Bug watch added: Linux Kernel Bug Tracker #208227 https://bugzilla.kernel.org/show_bug.cgi?id=208227 -- 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/1879438 Title: bluetooth file transfer via bluetooth UI is too slow Status in bluez package in Ubuntu: New Bug description: OS: Ubuntu 20.04 Kernel: 5.4.0-31-generic When using the UI to connect and transfer the file form one machine to another machine, BASIC mode is getting selected in the L2CAP configuration and continuous scan is not going on in both sides. the L2CAP MTU size is also in 672, which is very small. Even with the patch applied by Intel, it does not increase the TPT because the UI always selects BASIC mode. Sample File transfer duration: sending - (8MB) 5min 18s sending - (12MB) 7min36s receiving - (8MB) 4min 8s receiving - (12MB) 5min 48s **This issue was also observed in Ubuntu 18.04 OS ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: bluetooth (not installed) ProcVersionSignature: Ubuntu 5.4.0-31.35-generic 5.4.34 Uname: Linux 5.4.0-31-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Tue May 19 14:46:11 2020 InstallationDate: Installed on 2020-05-19 (0 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) InterestingModules: rfcomm bnep btusb bluetooth MachineType: LENOVO 20U9SITR39 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-31-generic root=UUID=6716936f-20b8-4840-8a75-00f4279d9062 ro quiet splash vt.handoff=7 SourcePackage: bluez UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/12/2020 dmi.bios.vendor: LENOVO dmi.bios.version: N2WET11C (1.01C ) dmi.board.asset.tag: Not Available dmi.board.name: 20U9SITR39 dmi.board.vendor: LENOVO dmi.board.version: Not Defined dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN2WET11C(1.01C):bd02/12/2020:svnLENOVO:pn20U9SITR39:pvrThinkPadX1CarbonGen8:rvnLENOVO:rn20U9SITR39:rvrNotDefined:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon Gen 8 dmi.product.name: 20U9SITR39 dmi.product.sku: LENOVO_MT_20U9_BU_Think_FM_ThinkPad X1 Carbon Gen 8 dmi.product.version: ThinkPad X1 Carbon Gen 8 dmi.sys.vendor: LENOVO hciconfig: hci0:Type: Primary Bus: USB BD Address: D8:3B:BF:7A:E4:22 ACL MTU: 1021:4 SCO MTU: 96:6 UP RUNNING RX bytes:22494299 acl:63654 sco:0 events:77112 errors:0 TX bytes:45158198 acl:65574 sco:0 commands:7661 errors:0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1879438/+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 1879438] Re: bluetooth file transfer via bluetooth UI is too slow
** Attachment added: "logs for file transfer (sending)" https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1879438/+attachment/5373901/+files/btsnoop.log -- 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/1879438 Title: bluetooth file transfer via bluetooth UI is too slow Status in bluez package in Ubuntu: New Bug description: OS: Ubuntu 20.04 Kernel: 5.4.0-31-generic When using the UI to connect and transfer the file form one machine to another machine, BASIC mode is getting selected in the L2CAP configuration and continuous scan is not going on in both sides. the L2CAP MTU size is also in 672, which is very small. Even with the patch applied by Intel, it does not increase the TPT because the UI always selects BASIC mode. Sample File transfer duration: sending - (8MB) 5min 18s sending - (12MB) 7min36s receiving - (8MB) 4min 8s receiving - (12MB) 5min 48s **This issue was also observed in Ubuntu 18.04 OS ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: bluetooth (not installed) ProcVersionSignature: Ubuntu 5.4.0-31.35-generic 5.4.34 Uname: Linux 5.4.0-31-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Tue May 19 14:46:11 2020 InstallationDate: Installed on 2020-05-19 (0 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) InterestingModules: rfcomm bnep btusb bluetooth MachineType: LENOVO 20U9SITR39 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-31-generic root=UUID=6716936f-20b8-4840-8a75-00f4279d9062 ro quiet splash vt.handoff=7 SourcePackage: bluez UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/12/2020 dmi.bios.vendor: LENOVO dmi.bios.version: N2WET11C (1.01C ) dmi.board.asset.tag: Not Available dmi.board.name: 20U9SITR39 dmi.board.vendor: LENOVO dmi.board.version: Not Defined dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN2WET11C(1.01C):bd02/12/2020:svnLENOVO:pn20U9SITR39:pvrThinkPadX1CarbonGen8:rvnLENOVO:rn20U9SITR39:rvrNotDefined:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon Gen 8 dmi.product.name: 20U9SITR39 dmi.product.sku: LENOVO_MT_20U9_BU_Think_FM_ThinkPad X1 Carbon Gen 8 dmi.product.version: ThinkPad X1 Carbon Gen 8 dmi.sys.vendor: LENOVO hciconfig: hci0:Type: Primary Bus: USB BD Address: D8:3B:BF:7A:E4:22 ACL MTU: 1021:4 SCO MTU: 96:6 UP RUNNING RX bytes:22494299 acl:63654 sco:0 events:77112 errors:0 TX bytes:45158198 acl:65574 sco:0 commands:7661 errors:0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1879438/+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 1879438] [NEW] bluetooth file transfer via bluetooth UI is too slow
Public bug reported: OS: Ubuntu 20.04 Kernel: 5.4.0-31-generic When using the UI to connect and transfer the file form one machine to another machine, BASIC mode is getting selected in the L2CAP configuration and continuous scan is not going on in both sides. the L2CAP MTU size is also in 672, which is very small. Even with the patch applied by Intel, it does not increase the TPT because the UI always selects BASIC mode. Sample File transfer duration: sending - (8MB) 5min 18s sending - (12MB) 7min36s receiving - (8MB) 4min 8s receiving - (12MB) 5min 48s **This issue was also observed in Ubuntu 18.04 OS ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: bluetooth (not installed) ProcVersionSignature: Ubuntu 5.4.0-31.35-generic 5.4.34 Uname: Linux 5.4.0-31-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Tue May 19 14:46:11 2020 InstallationDate: Installed on 2020-05-19 (0 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) InterestingModules: rfcomm bnep btusb bluetooth MachineType: LENOVO 20U9SITR39 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-31-generic root=UUID=6716936f-20b8-4840-8a75-00f4279d9062 ro quiet splash vt.handoff=7 SourcePackage: bluez UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/12/2020 dmi.bios.vendor: LENOVO dmi.bios.version: N2WET11C (1.01C ) dmi.board.asset.tag: Not Available dmi.board.name: 20U9SITR39 dmi.board.vendor: LENOVO dmi.board.version: Not Defined dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN2WET11C(1.01C):bd02/12/2020:svnLENOVO:pn20U9SITR39:pvrThinkPadX1CarbonGen8:rvnLENOVO:rn20U9SITR39:rvrNotDefined:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon Gen 8 dmi.product.name: 20U9SITR39 dmi.product.sku: LENOVO_MT_20U9_BU_Think_FM_ThinkPad X1 Carbon Gen 8 dmi.product.version: ThinkPad X1 Carbon Gen 8 dmi.sys.vendor: LENOVO hciconfig: hci0: Type: Primary Bus: USB BD Address: D8:3B:BF:7A:E4:22 ACL MTU: 1021:4 SCO MTU: 96:6 UP RUNNING RX bytes:22494299 acl:63654 sco:0 events:77112 errors:0 TX bytes:45158198 acl:65574 sco:0 commands:7661 errors:0 ** Affects: bluez (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- 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/1879438 Title: bluetooth file transfer via bluetooth UI is too slow Status in bluez package in Ubuntu: New Bug description: OS: Ubuntu 20.04 Kernel: 5.4.0-31-generic When using the UI to connect and transfer the file form one machine to another machine, BASIC mode is getting selected in the L2CAP configuration and continuous scan is not going on in both sides. the L2CAP MTU size is also in 672, which is very small. Even with the patch applied by Intel, it does not increase the TPT because the UI always selects BASIC mode. Sample File transfer duration: sending - (8MB) 5min 18s sending - (12MB) 7min36s receiving - (8MB) 4min 8s receiving - (12MB) 5min 48s **This issue was also observed in Ubuntu 18.04 OS ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: bluetooth (not installed) ProcVersionSignature: Ubuntu 5.4.0-31.35-generic 5.4.34 Uname: Linux 5.4.0-31-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Tue May 19 14:46:11 2020 InstallationDate: Installed on 2020-05-19 (0 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) InterestingModules: rfcomm bnep btusb bluetooth MachineType: LENOVO 20U9SITR39 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-31-generic root=UUID=6716936f-20b8-4840-8a75-00f4279d9062 ro quiet splash vt.handoff=7 SourcePackage: bluez UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/12/2020 dmi.bios.vendor: LENOVO dmi.bios.version: N2WET11C (1.01C ) dmi.board.asset.tag: Not Available dmi.board.name: 20U9SITR39 dmi.board.vendor: LENOVO dmi.board.version: Not Defined dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN2WET11C(1.01C):bd02/12/2020:svnLENOVO:pn20U9SITR39:pvrThinkPadX1CarbonGen8:rvnLENOVO:rn20U9SITR39:rvrNotDefined:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon Gen 8 dmi.product.name: 20U9SITR39 dmi.product.sku: LENOVO_MT_20U9_BU_Think_FM_ThinkPad X1 Carbon Gen 8 dmi.product.version: ThinkPad X1 Carbon Gen 8 dmi.sys.vendor: LENOVO hciconfig: hci0:Type: Primary Bus: USB BD Address: D8:3B:BF:7A:E4:22 ACL MTU: 1021:4 SCO MTU: 96:6 UP
[Kernel-packages] [Bug 1879438] Re: bluetooth file transfer via bluetooth UI is too slow
** Attachment added: "logs for file transfer (receiving)" https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1879438/+attachment/5373902/+files/btsnoop_receive.log -- 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/1879438 Title: bluetooth file transfer via bluetooth UI is too slow Status in bluez package in Ubuntu: New Bug description: OS: Ubuntu 20.04 Kernel: 5.4.0-31-generic When using the UI to connect and transfer the file form one machine to another machine, BASIC mode is getting selected in the L2CAP configuration and continuous scan is not going on in both sides. the L2CAP MTU size is also in 672, which is very small. Even with the patch applied by Intel, it does not increase the TPT because the UI always selects BASIC mode. Sample File transfer duration: sending - (8MB) 5min 18s sending - (12MB) 7min36s receiving - (8MB) 4min 8s receiving - (12MB) 5min 48s **This issue was also observed in Ubuntu 18.04 OS ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: bluetooth (not installed) ProcVersionSignature: Ubuntu 5.4.0-31.35-generic 5.4.34 Uname: Linux 5.4.0-31-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Tue May 19 14:46:11 2020 InstallationDate: Installed on 2020-05-19 (0 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) InterestingModules: rfcomm bnep btusb bluetooth MachineType: LENOVO 20U9SITR39 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-31-generic root=UUID=6716936f-20b8-4840-8a75-00f4279d9062 ro quiet splash vt.handoff=7 SourcePackage: bluez UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/12/2020 dmi.bios.vendor: LENOVO dmi.bios.version: N2WET11C (1.01C ) dmi.board.asset.tag: Not Available dmi.board.name: 20U9SITR39 dmi.board.vendor: LENOVO dmi.board.version: Not Defined dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN2WET11C(1.01C):bd02/12/2020:svnLENOVO:pn20U9SITR39:pvrThinkPadX1CarbonGen8:rvnLENOVO:rn20U9SITR39:rvrNotDefined:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon Gen 8 dmi.product.name: 20U9SITR39 dmi.product.sku: LENOVO_MT_20U9_BU_Think_FM_ThinkPad X1 Carbon Gen 8 dmi.product.version: ThinkPad X1 Carbon Gen 8 dmi.sys.vendor: LENOVO hciconfig: hci0:Type: Primary Bus: USB BD Address: D8:3B:BF:7A:E4:22 ACL MTU: 1021:4 SCO MTU: 96:6 UP RUNNING RX bytes:22494299 acl:63654 sco:0 events:77112 errors:0 TX bytes:45158198 acl:65574 sco:0 commands:7661 errors:0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1879438/+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 1850886] Re: Auto-rotate is not working properly when system is booted up while not in its regular orientation
Hi Bin, Ok, I'll take note of this. Thank you very much! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-meta-oem in Ubuntu. https://bugs.launchpad.net/bugs/1850886 Title: Auto-rotate is not working properly when system is booted up while not in its regular orientation Status in GNOME Shell: New Status in linux-meta-oem package in Ubuntu: Confirmed Bug description: [RELEASE VERSION] Description: Ubuntu 18.04.3 LTS Release: 18.04 [PACKAGE VERSION] linux-oem: Installed: 4.15.0.1057.61 Candidate: 4.15.0.1057.61 Version table: *** 4.15.0.1057.61 500 500 http://jp.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 100 /var/lib/dpkg/status 4.15.0.1004.2 500 500 http://jp.archive.ubuntu.com/ubuntu bionic/main amd64 Packages [EXPECTED OUTPUT] Upon boot up with auto-rotation enabled, display should show the proper screen orientation of the system accordingly [ACTUAL OUTPUT] Auto-rotation is not working properly when system is booted up while not in its regular orientation [STEPS] 1. Make sure auto-rotation is enabled on the system 2. Before turning the system on, put it on tablet mode, with the inverted landscape rotation (the top part/the part with the camera is adjacent to the surface). The system should follow this orientation when the login screen appears. 3. Login to the system 4. Switch to the clam shell mode. The display suddenly becomes inverted/the opposite direction of the expected output. 5. Switch back to the tablet mode. The display also ends up being inverted/in the opposite direction of the expected output [REMARKS] *Using WHL *The system seems to be setting the orientation according to the orientation during boot up ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: linux-oem 4.15.0.1057.61 ProcVersionSignature: Ubuntu 5.0.0-1024.27-oem-osp1 5.0.21 Uname: Linux 5.0.0-1024-oem-osp1 x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Nov 1 14:23:14 2019 DistributionChannelDescriptor: # This is the distribution channel descriptor for the OEM CDs # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-sutton-bionic-amd64-20190722-12+sutton-dijkstra-bionic-amd64+iso InstallationDate: Installed on 2019-07-25 (98 days ago) InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20190722-05:40 SourcePackage: linux-meta-oem UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell/+bug/1850886/+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 1850886] Re: Auto-rotate is not working properly when system is booted up while not in its regular orientation
Hi Bin Li, Thanks for the updates. Could you specify a target date for the bug fix? Thank you! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-meta-oem in Ubuntu. https://bugs.launchpad.net/bugs/1850886 Title: Auto-rotate is not working properly when system is booted up while not in its regular orientation Status in GNOME Shell: New Status in linux-meta-oem package in Ubuntu: Confirmed Bug description: [RELEASE VERSION] Description: Ubuntu 18.04.3 LTS Release: 18.04 [PACKAGE VERSION] linux-oem: Installed: 4.15.0.1057.61 Candidate: 4.15.0.1057.61 Version table: *** 4.15.0.1057.61 500 500 http://jp.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 100 /var/lib/dpkg/status 4.15.0.1004.2 500 500 http://jp.archive.ubuntu.com/ubuntu bionic/main amd64 Packages [EXPECTED OUTPUT] Upon boot up with auto-rotation enabled, display should show the proper screen orientation of the system accordingly [ACTUAL OUTPUT] Auto-rotation is not working properly when system is booted up while not in its regular orientation [STEPS] 1. Make sure auto-rotation is enabled on the system 2. Before turning the system on, put it on tablet mode, with the inverted landscape rotation (the top part/the part with the camera is adjacent to the surface). The system should follow this orientation when the login screen appears. 3. Login to the system 4. Switch to the clam shell mode. The display suddenly becomes inverted/the opposite direction of the expected output. 5. Switch back to the tablet mode. The display also ends up being inverted/in the opposite direction of the expected output [REMARKS] *Using WHL *The system seems to be setting the orientation according to the orientation during boot up ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: linux-oem 4.15.0.1057.61 ProcVersionSignature: Ubuntu 5.0.0-1024.27-oem-osp1 5.0.21 Uname: Linux 5.0.0-1024-oem-osp1 x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Nov 1 14:23:14 2019 DistributionChannelDescriptor: # This is the distribution channel descriptor for the OEM CDs # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-sutton-bionic-amd64-20190722-12+sutton-dijkstra-bionic-amd64+iso InstallationDate: Installed on 2019-07-25 (98 days ago) InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20190722-05:40 SourcePackage: linux-meta-oem UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell/+bug/1850886/+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 1850886] [NEW] Auto-rotate is not working properly when system is booted up while not in its regular orientation
Public bug reported: [RELEASE VERSION] Description:Ubuntu 18.04.3 LTS Release:18.04 [PACKAGE VERSION] linux-oem: Installed: 4.15.0.1057.61 Candidate: 4.15.0.1057.61 Version table: *** 4.15.0.1057.61 500 500 http://jp.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 100 /var/lib/dpkg/status 4.15.0.1004.2 500 500 http://jp.archive.ubuntu.com/ubuntu bionic/main amd64 Packages [EXPECTED OUTPUT] Upon boot up with auto-rotation enabled, display should show the proper screen orientation of the system accordingly [ACTUAL OUTPUT] Auto-rotation is not working properly when system is booted up while not in its regular orientation [STEPS] 1. Make sure auto-rotation is enabled on the system 2. Before turning the system on, put it on tablet mode, with the inverted landscape rotation (the top part/the part with the camera is adjacent to the surface). The system should follow this orientation when the login screen appears. 3. Login to the system 4. Switch to the clam shell mode. The display suddenly becomes inverted/the opposite direction of the expected output. 5. Switch back to the tablet mode. The display also ends up being inverted/in the opposite direction of the expected output [REMARKS] *Using WHL *The system seems to be setting the orientation according to the orientation during boot up ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: linux-oem 4.15.0.1057.61 ProcVersionSignature: Ubuntu 5.0.0-1024.27-oem-osp1 5.0.21 Uname: Linux 5.0.0-1024-oem-osp1 x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Nov 1 14:23:14 2019 DistributionChannelDescriptor: # This is the distribution channel descriptor for the OEM CDs # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-sutton-bionic-amd64-20190722-12+sutton-dijkstra-bionic-amd64+iso InstallationDate: Installed on 2019-07-25 (98 days ago) InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20190722-05:40 SourcePackage: linux-meta-oem UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: linux-meta-oem (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic third-party-packages -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-meta-oem in Ubuntu. https://bugs.launchpad.net/bugs/1850886 Title: Auto-rotate is not working properly when system is booted up while not in its regular orientation Status in linux-meta-oem package in Ubuntu: New Bug description: [RELEASE VERSION] Description: Ubuntu 18.04.3 LTS Release: 18.04 [PACKAGE VERSION] linux-oem: Installed: 4.15.0.1057.61 Candidate: 4.15.0.1057.61 Version table: *** 4.15.0.1057.61 500 500 http://jp.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 100 /var/lib/dpkg/status 4.15.0.1004.2 500 500 http://jp.archive.ubuntu.com/ubuntu bionic/main amd64 Packages [EXPECTED OUTPUT] Upon boot up with auto-rotation enabled, display should show the proper screen orientation of the system accordingly [ACTUAL OUTPUT] Auto-rotation is not working properly when system is booted up while not in its regular orientation [STEPS] 1. Make sure auto-rotation is enabled on the system 2. Before turning the system on, put it on tablet mode, with the inverted landscape rotation (the top part/the part with the camera is adjacent to the surface). The system should follow this orientation when the login screen appears. 3. Login to the system 4. Switch to the clam shell mode. The display suddenly becomes inverted/the opposite direction of the expected output. 5. Switch back to the tablet mode. The display also ends up being inverted/in the opposite direction of the expected output [REMARKS] *Using WHL *The system seems to be setting the orientation according to the orientation during boot up ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: linux-oem 4.15.0.1057.61 ProcVersionSignature: Ubuntu 5.0.0-1024.27-oem-osp1 5.0.21 Uname: Linux 5.0.0-1024-oem-osp1 x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Nov 1 14:23:14 2019 DistributionChannelDescriptor: # This is the distribution channel descriptor for the OEM CDs # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-sutton-bionic-amd64-20190722-12+sutton-dijkstra-bionic-amd64+iso InstallationDate: Installed on 2019-07-25 (98 days ago) InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20190722-05:40 SourcePackage: linux-meta-oem UpgradeStatus: No upgrade log
