Well, the adapters I researched would not fit into the space available to a notebook drive…All the adapters need adapters 
The coup de grâce is the same transfer speed: no performance enhancement…The reason for these drives, as you likely know, is less power consumption . At least there was a reason 
1 Like
I’m unaffected by either of those… both seem maybe related to intel GPU? My E495 is the AMD Ryzen variant with Vega 8 APU / GPU.
One thing that really CHEESES me off is the DisplayLink driver for Linux is a piece of crap!
Last year users were reporting it on Dell branded D6000 USBC/3 docks, eating up their CPU cycles (on Dell and non Dell devices) and very laggy performance… I tried it myself yesterday, and yes, it is a problem… a major problem, and unusable not fit for purpose, problem…
Seems the issue’s been fixed/addressed for NVidia GPU, but not for Intel or AMD… Doh! This only affects Linux users, not Mac or Windows (I usually use my Macbook Pro M1 on it - but it’s going into the shop tomorrow, issue with random keys getting “stuck” on).
Quick fix? Undock the E495 and hook it up via onboard HDMI port and problem goes away… Who even writes and deploys this FUCKING software without testing it “in the wild” and how can they get away with leaving a hideous fault in place for OVER TWELVE MONTHS!
Shame DisplayLink people - you SUCK!
1 Like
E495 has only the AMD variant. Both are related to AMD. The GPU related problem in the first link can be checked by using radeontop. If there is an issue the Memory Clock row will be 100% when you run radeontop. This issue drains the battery and will make the PC a little hot even on idle. If not it’ll scale as is demaned and everything should be fine.
The next one in the link is about TSC broken. This can be checked using the following command on the term:
sudo dmesg | egrep -i ‘tsc|hpet|clocksource’
If there is a problem the clocksource will change from tsc to hpet.
Thinkpad E495 is not Linux certified however the laptop which it is very similar to in internal config: T495 is certified. Any bugs for that PC is also there in E495. The GPU problem can be fixed by downgrading the linux-firware package(though not fixed yet) but the TSC one is still not fixed even after bug report from 2019. There is a patch to fix the TSC one but I haven’t tried it.
1 Like
I stand corrected…
I installed radeontop, ran it, memory use only showed 66% but it basically crashed my laptop… wouldn’t respond, SSH, “ctrl+alt+f4” etc… had to IML (i.e. in IBM parlance, hit the big red button, “initial machine load”).
I don’t use it on battery… but recently (on Ubuntu 21.04) I let it run until it died, on battery, I reckon 3-4 hours? Haven’t tried since I rebuilt it with Ubuntu 20.04 from scratch…
I also ran “sudo dmesg | egrep -i 'tsc|hpet|clocksource'”
sheeze I f–king HATE the way discourse converts quotes into inverted commas - what a POS!
But wasn’t sure what to look for…
╭─x@fenrir ~
╰─➤ sudo dmesg | egrep -i 'tsc|hpet|clocksource'
[ 0.000000] tsc: Fast TSC calibration using PIT
[ 0.000000] tsc: Detected 2096.155 MHz processor
[ 0.004885] ACPI: HPET 0x00000000BB200000 000038 (v01 LENOVO TP-R11 00001210 PTEC 00000002)
[ 0.004953] ACPI: Reserving HPET table memory at [mem 0xbb200000-0xbb200037]
[ 0.035815] ACPI: HPET id: 0x43538210 base: 0xfed00000
[ 0.035890] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
[ 0.100105] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484873504 ns
[ 0.120136] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x1e37005745f, max_idle_ns: 440795263448 ns
[ 0.240141] TSC synchronization [CPU#0 -> CPU#1]:
[ 0.240141] Measured 7039309557 cycles TSC warp between CPUs, turning off TSC clock.
[ 0.240141] tsc: Marking TSC unstable due to check_tsc_sync_source failed
[ 0.244978] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 0.305554] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[ 0.305554] hpet0: 3 comparators, 32-bit 14.318180 MHz counter
[ 0.306654] clocksource: Switched to clocksource hpet
[ 0.321457] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[ 0.799836] rtc_cmos 00:01: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
[ 22.512515] vboxdrv: TSC mode is Invariant, tentative frequency 2096081554 Hz
1 Like
You graphics is working properly then. Can you tell me the package version of the linux-firmware package?
The TSC problem exists still:
[ 0.240141] Measured 7039309557 cycles TSC warp between CPUs, turning off TSC clock.
[ 0.240141] tsc: Marking TSC unstable due to check_tsc_sync_source failed
[ 0.306654] clocksource: Switched to clocksource hpet
This problem was first reported in the amd 2000 series mobile cpu. Don’t know when AMD will fix it.
Not sure why - but - my system aint running “firmware-amd-graphics” or doesn’t seem to anyway…
╭─x@fenrir ~
╰─➤ sudo dpkg -l \*firmware\* 2 ↵
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=========================-============-============-=================================
un atmel-firmware <none> <none> (no description available)
un firmware-amd-graphics <none> <none> (no description available)
un firmware-misc-nonfree <none> <none> (no description available)
ii linux-firmware 1.187.17 all Firmware for Linux kernel drivers
un linux-firmware-raspi2 <none> <none> (no description available)
un linux-firmware-snapdragon <none> <none> (no description available)
╭─x@fenrir ~
╰─➤ dpkg -l |grep firmware
ii amd64-microcode 3.20191218.1ubuntu1 amd64 Processor microcode firmware for AMD CPUs
ii intel-microcode 3.20210608.0ubuntu0.20.04.1 amd64 Processor microcode firmware for Intel CPUs
ii linux-firmware 1.187.17 all Firmware for Linux kernel drivers
That’s the one. Thanks for the info.