Re: [gentoo-user] USB-C PD delivery & Lenovo USB-C hub.
On Thu, 26 Sep 2019 at 21:52, Alexey Mishustin wrote: > > чт, 26 сент. 2019 г. в 23:39, Dom Rodriguez : > > > > OK, after much deliberation, I've determined the issue! I'm banging my head > > on > > the wall here after realising the cause. > > > > I was using an Anker power adaptor, which supplies 60W in *total* to both > > ports > > on it - a USB-C port, and a USB-A port. The USB-A port consumes 15W, and the > > USB-C port is left with 45W. > > > > The USB-C hub - for example, the one I've got now consumes 18W from the 45W > > supplied - which leaves the laptop with 27W. My Thinkpad has a minimum > > required > > USB-C PD wattage of 45W - so that's why it wasn't working! > > > > Thanks to all who helped with this problem. > > Hello Dom, > > Thanks to you for the information! > > Do not bang your head too much ) This result is a good result, could > be useful to others. > > -- > Best regards, > Alex > Very interesting finding! Thanks for sharing. :-) -- Regards, Mick
Re: [gentoo-user] USB-C PD delivery & Lenovo USB-C hub.
чт, 26 сент. 2019 г. в 23:39, Dom Rodriguez : > > OK, after much deliberation, I've determined the issue! I'm banging my head on > the wall here after realising the cause. > > I was using an Anker power adaptor, which supplies 60W in *total* to both > ports > on it - a USB-C port, and a USB-A port. The USB-A port consumes 15W, and the > USB-C port is left with 45W. > > The USB-C hub - for example, the one I've got now consumes 18W from the 45W > supplied - which leaves the laptop with 27W. My Thinkpad has a minimum > required > USB-C PD wattage of 45W - so that's why it wasn't working! > > Thanks to all who helped with this problem. Hello Dom, Thanks to you for the information! Do not bang your head too much ) This result is a good result, could be useful to others. -- Best regards, Alex
Re: [gentoo-user] USB-C PD delivery & Lenovo USB-C hub.
Hello, On this date - Tue, Sep 24, 2019 at 05:54:09PM +0100, Dom Rodriguez wrote: > On this date - Mon, Sep 23, 2019 at 06:16:25PM +0100, Dom Rodriguez wrote: > > Hello, > > > > On this date - Mon, Sep 23, 2019 at 05:55:46PM +0100, Mick wrote: > > > On Monday, 23 September 2019 17:39:22 BST Dom Rodriguez wrote: > > > > On this date - Mon, Sep 23, 2019 at 07:20:56PM +0300, Alexey Mishustin > > > wrote: > > > > > пн, 23 сент. 2019 г. в 19:13, Dom Rodriguez : > > > > > > Hello, > > > > > > > > > > > > On this date - Mon, Sep 23, 2019 at 07:01:08PM +0300, Alexey > > > > > > Mishustin > > > wrote: > > > > > > > пн, 23 сент. 2019 г. в 18:36, Dom Rodriguez > > > > > > > : > > > > > > > > Alright, I've managed to isolate the issue to the `tps6598.ko' > > > > > > > > USB-C > > > > > > > > PD kernel module. > > > > > > > > > > > > > > > > I've reached out to the manufacturer of the hub to see if they > > > > > > > > can > > > > > > > > advise, but for now, knowing the problem kernel module has > > > > > > > > definitely helped getting close to solving the problem. > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > What's the model code of your hub? > > > > > > > > > > > > > > -- > > > > > > > Best regards, > > > > > > > Alex > > > > > > > > > > > > Sorry, meant to mention that.. its a Lenovo USb-C Hub C109. I > > > > > > bought it > > > > > > from Amazon, but the manufacturer sells it under the Lenovo brand - > > > > > > http://www.novolk.com/productinfo/54884.html> > > > > > OK. Thanks. It's useful to know which one potentially to avoid. > > > > > > > > The thing is, I've tried with a fair few hubs with this laptop, and it > > > > hasn't been very successful... same issue persists. > > > > > > Have you had a look at the UEFI/BIOS settings? There may be a setting > > > you > > > need to enable in there. > > > > I'm afraid there's no options in the UEFI settings for USB-C power delivery. > > I've tested the hub and PD power adapter (Anker) on the same laptop on the > Windows 10 partition. No luck. The PD chip in the laptop is recognised by > Windows 10 though. > > I've ordered a replacement adapter (Anker), and hub, which should arrive > tomorrow - I'll see how that goes. > > At this point, its either one of three things: > > - The laptop hardware. > - The USB-C hub. > - The Anker power adapter. > > Time will tell OK, after much deliberation, I've determined the issue! I'm banging my head on the wall here after realising the cause. I was using an Anker power adaptor, which supplies 60W in *total* to both ports on it - a USB-C port, and a USB-A port. The USB-A port consumes 15W, and the USB-C port is left with 45W. The USB-C hub - for example, the one I've got now consumes 18W from the 45W supplied - which leaves the laptop with 27W. My Thinkpad has a minimum required USB-C PD wattage of 45W - so that's why it wasn't working! Thanks to all who helped with this problem. -- Sincerely, Dom Rodriguez (shymega). signature.asc Description: PGP signature
Re: [gentoo-user] UEFI data corruption? [FIXED]
On Thu, 26 Sep 2019 at 15:47, Peter Humphrey wrote: > > On Thursday, 26 September 2019 10:16:54 BST Adam Carter wrote: > > > > The Gentoo Handbook says to create a small unformatted partition at the > > > > beginning of the (primary?) disk, then to create a FAT-32 partition for > > > > /boot, then whatever other partitions are required. Strictly speaking the FAT32 partition is the ESP, which is typically mounted under /boot and it should be marked with the corresponding ESP GUID. As I mentioned before, the initial disk space (rather than partition) starting at LBA0 contains either a legacy MBR with its time honoured 4 partition table, or a Protective MBR containing a fake single whole-disk partition in its table. Either the legacy MBR or Protective MBR blocks are not processed by the UEFI firmware, which goes to LBA1 and reads the GPT tables to find the ESP. Therefore, it is not clear to me why a small empty partition might be necessary at the start of the disk, unless earlier versions of partitioning tools were not as clever and started at LBA0, or some some weird UEFI firmware implementations were devised by some OEMs. > > > Another question answered: yes, it has to be the primary disk. I installed > > > a small test system on another disk. It has its own FAT-32 /boot > > > partition, in which I set up a similar directory structure to the main > > > system's. Efibootmgr still insisted on adding the UEFI entry to the main > > > set, in spite of my telling it to use the secondary disk. And the BIOS > > > couldn't see the image on the secondary disk. I believe you'll need a bootloader to jump to different disks. I don't think the UEFI firmware in its current version can handle more than one ESP in any number of drives. Some OS auto-scripted installation media will fail if the same disk has two FAT32 partitions marked as ESP (e.g. Windows 7). > > I found my BIOS didn't recognise the UEFI setup until it was > > specified/setup by efibootmgr, so that checks out. What was the efibootmgr > > command you were using for the second disk? > > efibootmgr -c -p 3 -d /dev/sda -L "TestSys" -l '\EFI\BOOT\bootX64.efi' Did you try specifying the disk device before the partition? efibootmgr -c -d /dev/sdXX -p 3 . to see if it is recognised then? > > > The conclusion is that, at least on this motherboard, there is precisely > > > one set of UEFI boot images, and it lives on the primary disk of the > > > system. Well, I haven't yet worked out how much of it is on the disk and > > > how much in BIOS storage. The point remains, however, that I can't spread > > > boot images over several disks. > > > > That's pretty poor. > > It isn't what I expected either. The UEFI firmware implementation (should) follow its specification, which has evolved over time. The specification mentions OS boot loaders, or kernels, or EFI applications, should be stored within EFI/ subdirectories, one per vendor. The EFI/ directory itself must be at the root of the ESP filesystem. Each OS subdirectory must contain only one bootable image, or the boot behaviour for the system won't be deterministic. [1] There may be an EFI/BOOT/ subdirectory in which a recovery bootable image can be stored. This will be used if other OS' images fail to boot. With removable media the directory structure is slightly different. All bootable images (one per supported arch) should be stored under EFI/BOOT/. This will ensure the removable device will boot automatically. Additional UEFI executables must be in directories other than BOOT/. The moment you start deviating from the above you need to manually edit the boot menu with e.g. efibootmgr. It used to be the case only the primary disk was used/usable by the UEFI firmware and only one ESP. Later versions of the specification say they may cater for more flexible ESP arrangements in the future. The older the OEM UEFI implementation the less flexible it would be. > > What does efibootmgr show? > > # efibootmgr > BootCurrent: > Timeout: 1 seconds > BootOrder: ,0004,0005,0001,0002,0003,0006,0007,0008,0009,000A,000B > Boot* Gentoo Linux > Boot0001* UEFI:CD/DVD Drive > Boot0002* UEFI:Removable Device > Boot0003* UEFI:Network Device > Boot0004* CD/DVD Drive > Boot0005 Hard Drive > Boot0006* UEFI:CD/DVD Drive > Boot0007* UEFI:Removable Device > Boot0008* UEFI:Network Device > Boot0009* UEFI:CD/DVD Drive > Boot000A* UEFI:Removable Device > Boot000B* UEFI:Network Device > > I'll delete all those duplicates. I don't know what's creating them. It's > happened a few times since this mess started, but I never saw it once before > then. The UEFI firmware can also use the Simple File System Protocol, if the disk supports it. In this case, it will scan the GPT, jump to the root of a partition and read bootable files on it. Then it will populate its boot menu with them. Presently this will only work with FAT(12/16/32) fs formats. Some of the duplicates may have been created in this fashion.
Re: [gentoo-user] VA-API support on Chrome
>> Does anyone have VA-API working on Chromium or Chrome? I've chased >> down a few possibilities but ended up at dead ends. >> >> - Grant >> > > I finally managed to get chromium-74.0.3729.108 working with vaapi. > > See: > https://www.reddit.com/r/Gentoo/comments/bgizgb/help_enabling_h264_decoding_support_through/enhyy3q?utm_source=share_medium=web2x Thanks for circling back! After reading it over I'm not sure I'm up to the challenge. Any reason to believe it's gotten easier? - Grant
Re: [gentoo-user] UEFI data corruption? [FIXED]
On Thursday, 26 September 2019 10:16:54 BST Adam Carter wrote: > > > The Gentoo Handbook says to create a small unformatted partition at the > > > beginning of the (primary?) disk, then to create a FAT-32 partition for > > > /boot, then whatever other partitions are required. > > > > Another question answered: yes, it has to be the primary disk. I installed > > a small test system on another disk. It has its own FAT-32 /boot > > partition, in which I set up a similar directory structure to the main > > system's. Efibootmgr still insisted on adding the UEFI entry to the main > > set, in spite of my telling it to use the secondary disk. And the BIOS > > couldn't see the image on the secondary disk. > > I found my BIOS didn't recognise the UEFI setup until it was > specified/setup by efibootmgr, so that checks out. What was the efibootmgr > command you were using for the second disk? efibootmgr -c -p 3 -d /dev/sda -L "TestSys" -l '\EFI\BOOT\bootX64.efi' > > The conclusion is that, at least on this motherboard, there is precisely > > one set of UEFI boot images, and it lives on the primary disk of the > > system. Well, I haven't yet worked out how much of it is on the disk and > > how much in BIOS storage. The point remains, however, that I can't spread > > boot images over several disks. > > That's pretty poor. It isn't what I expected either. > What does efibootmgr show? # efibootmgr BootCurrent: Timeout: 1 seconds BootOrder: ,0004,0005,0001,0002,0003,0006,0007,0008,0009,000A,000B Boot* Gentoo Linux Boot0001* UEFI:CD/DVD Drive Boot0002* UEFI:Removable Device Boot0003* UEFI:Network Device Boot0004* CD/DVD Drive Boot0005 Hard Drive Boot0006* UEFI:CD/DVD Drive Boot0007* UEFI:Removable Device Boot0008* UEFI:Network Device Boot0009* UEFI:CD/DVD Drive Boot000A* UEFI:Removable Device Boot000B* UEFI:Network Device I'll delete all those duplicates. I don't know what's creating them. It's happened a few times since this mess started, but I never saw it once before then. > I got the impression that I would be able to UEFI boot from multiple > different devices, eg a USB drive with UEFI as well as the hard disk. Oh yes, removable devices can be booted, but not secondary, internal hard drives. Apparently. On this system. Today. -- Regards, Peter.
Re: [gentoo-user] Re: Thunderbird-60,9.0
"Nikos Chantziaras" , 26.09.2019, 11:22: > On 25/09/2019 21:44, james wrote: >> [...] >> not sure why/where I set something to get the latest versions , that do >> not show up with 'eix Thunderbird' > Did you forget to run eix-update? You need to do that after every emerge > --sync. or just use "eix-sync" right away. s.
Re: [gentoo-user] UEFI data corruption? [FIXED]
> > I got the impression that I would be able to UEFI boot from multiple > different devices, eg a USB drive with UEFI as well as the hard disk. > FYI, after rebooting with the USB drive in; # efibootmgr BootCurrent: Timeout: 1 seconds BootOrder: ,0004,0001,0003,0002 Boot* Gentoo <- this is the UEFI booted OS Boot0001* Hard Drive <- this the same drive as Boot, but IIRC fails to boot Boot0002* Network Card Boot0003* USB HDD <- this is the same device as Boot0004 Boot0004* UEFI: Patriot Memory PMAP, Partition 1
[gentoo-user] Re: Thunderbird-60,9.0
On 25/09/2019 21:44, james wrote: [...] not sure why/where I set something to get the latest versions , that do not show up with 'eix Thunderbird' Did you forget to run eix-update? You need to do that after every emerge --sync.
Re: [gentoo-user] UEFI data corruption? [FIXED]
> > > The Gentoo Handbook says to create a small unformatted partition at the > > beginning of the (primary?) disk, then to create a FAT-32 partition for > > /boot, then whatever other partitions are required. > > Another question answered: yes, it has to be the primary disk. I installed > a > small test system on another disk. It has its own FAT-32 /boot partition, > in > which I set up a similar directory structure to the main system's. > Efibootmgr > still insisted on adding the UEFI entry to the main set, in spite of my > telling it to use the secondary disk. And the BIOS couldn't see the image > on > the secondary disk. > I found my BIOS didn't recognise the UEFI setup until it was specified/setup by efibootmgr, so that checks out. What was the efibootmgr command you were using for the second disk? The conclusion is that, at least on this motherboard, there is precisely > one > set of UEFI boot images, and it lives on the primary disk of the system. > Well, > I haven't yet worked out how much of it is on the disk and how much in > BIOS > storage. The point remains, however, that I can't spread boot images over > several disks. > That's pretty poor. What does efibootmgr show? I got the impression that I would be able to UEFI boot from multiple different devices, eg a USB drive with UEFI as well as the hard disk.
Re: [gentoo-user] Slow UI for firefox 68
> > Ok, just for the history, it's the hwaccel flag that causes the problem. > > It could be a combination of things and not just a firefox bug, but ok. > Apart from full screen youtube which seems to run slower than before, > it's ok > > I can reproduce the same behaviour if I turn on > layers.acceleration.force-enabled. > What graphics card / driver are you using? about:support -> GPU #1 -> Description & Driver Vendor & Driver Version So far i've not had any problems with AMD Radeon R9 380 and RX 580, with mesa/radeonsi
Re: [gentoo-user] UEFI data corruption? [FIXED]
On Tuesday, 24 September 2019 09:50:44 BST I wrote: > The Gentoo Handbook says to create a small unformatted partition at the > beginning of the (primary?) disk, then to create a FAT-32 partition for > /boot, then whatever other partitions are required. Another question answered: yes, it has to be the primary disk. I installed a small test system on another disk. It has its own FAT-32 /boot partition, in which I set up a similar directory structure to the main system's. Efibootmgr still insisted on adding the UEFI entry to the main set, in spite of my telling it to use the secondary disk. And the BIOS couldn't see the image on the secondary disk. The conclusion is that, at least on this motherboard, there is precisely one set of UEFI boot images, and it lives on the primary disk of the system. Well, I haven't yet worked out how much of it is on the disk and how much in BIOS storage. The point remains, however, that I can't spread boot images over several disks. -- Regards, Peter.
Re: [gentoo-user] Slow UI for firefox 68
On 21/9/19 12:18 μ.μ., Emmanuel Vasilakis wrote: On 17/9/19 6:16 μ.μ., Emmanuel Vasilakis wrote: Hi! Just finished compiling www-client/firefox 68.1.0 and I'm seeing a very big lag mainly in UI operations. I.e., clicking on the menu button (or any other button on the UI) takes 5-6 seconds for the menu to appear, during which firefox goes up to using 100% of my CPU. Even typing something in the URI bar has a lag of 1 sec between key presses and text appearing. I've compiled firefox using these use flags: clang custom-cflags custom-optimization dbus gmp-autoupdate hwaccel lto pgo screenshot startup-notification system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-sqlite system-webp (Didn't really change anything from previous firefox versions I compiled). firefox-bin (69.0) behaves ok. firefox using --safe-mode is also ok. I did use refresh firefox which wiped clean firefox and removed all extensions, but I'm getting the same laggy behaviour. Anyone else having similar experience? Previous firefox versions where all okay. Thanks, Emmanuel Ok, so by disabling hwaccell and all system-* flags, I got a build that works. Now to see which one causes the problem... Thanks! Emmanuel Ok, just for the history, it's the hwaccel flag that causes the problem. It could be a combination of things and not just a firefox bug, but ok. Apart from full screen youtube which seems to run slower than before, it's ok I can reproduce the same behaviour if I turn on layers.acceleration.force-enabled. Thanks, Emmanuel
