Re: [PATCH] thinkpad_acpi: fix: use scnprintf instead of snprintf.

On Wed, 06 Jan 2021, Joe Perches wrote: > On Wed, 2021-01-06 at 14:36 +0800, YANG LI wrote: > > The snprintf() function returns the number of characters which would > > have been printed if there were enough space, but the scnprintf() > > returns the number of characters which were actually printed

Re: [PATCH 0/3] Add 3 new keycodes and use them for 3 new hotkeys on new Lenovo Thinkpads

On Mon, 27 Jul 2020, Andy Shevchenko wrote: > On Mon, Jul 27, 2020 at 10:49 AM Andy Shevchenko > wrote: > > On Mon, Jul 27, 2020 at 10:45 AM Hans de Goede wrote: > > > > > > Hi, > > > > > > On 7/27/20 2:50 AM, Henrique de Moraes Holschuh wrote: &g

Re: [PATCH 0/3] Add 3 new keycodes and use them for 3 new hotkeys on new Lenovo Thinkpads

On Tue, 21 Jul 2020, Dmitry Torokhov wrote: > On Sun, Jul 19, 2020 at 07:56:49PM -0300, Henrique de Moraes Holschuh wrote: > > On Fri, 17 Jul 2020, Hans de Goede wrote: > > > This is a simple patch-series adding support for 3 new hotkeys found > > > on various

Re: [PATCH 0/3] Add 3 new keycodes and use them for 3 new hotkeys on new Lenovo Thinkpads

On Fri, 17 Jul 2020, Hans de Goede wrote: > This is a simple patch-series adding support for 3 new hotkeys found > on various new Lenovo Thinkpad models. For all three patches, pending an ack for the new keycodes by the input maintainers: Acked-by: Henrique de Moraes Holschuh -- He

Re: [PATCH] scsi: sd: stop SSD (non-rotational) disks before reboot

On Tue, 30 Jun 2020, Ming Lei wrote: > On Wed, Jun 24, 2020 at 5:01 AM Henrique de Moraes Holschuh > wrote: > > Cache flushes do not matter that much when SSDs and sudden power cuts > > are involved. Power cuts at the wrong time harm the FLASH itself, it is > > not ab

Re: [PATCH] scsi: sd: stop SSD (non-rotational) disks before reboot

On Thu, 18 Jun 2020, Christoph Hellwig wrote: > > For SSDs, I don't think an extra stop should ever be an issue. > > Extra shutdowns will usually cause additional P/E cycles. I am not so sure. We're talking about enforcing clean shutdowns here (from the SSD PoV). A system reboot takes enough ti

Re: [PATCH] scsi: sd: stop SSD (non-rotational) disks before reboot

On Sun, 28 Jun 2020, Simon Arlott wrote: > On 23/06/2020 21:42, Henrique de Moraes Holschuh wrote: > > [1] I have long lost the will and energy to pursue this, so *this* is a > > throw-away anecdote for anyone that cares: I reported here a few years > > ago that many models

Re: [PATCH] scsi: sd: stop SSD (non-rotational) disks before reboot

On Thu, 18 Jun 2020, Damien Le Moal wrote: > Are you experiencing data loss or corruption ? If yes, since a clean reboot or > shutdown issues a synchronize cache to all devices, a corruption would mean > that > your SSD is probably not correctly processing flush cache commands. Cache flushes do n

Re: [PATCH v2 1/2] x86/cpufeature: Add facility to match microcode revisions

On Wed, 10 Oct 2018, Andi Kleen wrote: > v2: > Remove all CPU match, only check boot cpu IMHO, since it looks like a v3 will be necessary anyway, it could benefit from a comment reminding people about how to use it on older systems where "mixed CPU stepping" configurations were common. This is *n

Re: [PATCH] x86-64: use 32-bit XOR to zero registers

On Tue, 26 Jun 2018, Jan Beulich wrote: > >>> On 25.06.18 at 18:33, wrote: > > On 06/25/2018 03:25 AM, Jan Beulich wrote: > >> Some Intel CPUs don't recognize 64-bit XORs as zeroing idioms - use > >> 32-bit ones instead. > > > > Hmph. Is that considered a bug (errata)? > > No. > > > URL/refere

Re: ThinkPad T480s & LED_MUTE, LED_MICMUTE

On Fri, 15 Jun 2018, Pali Rohár wrote: > Henrique, any idea why there are no exported led classes for mute and > micmute? And how are suppose to be controlled? I have to look into the code, it was contributed by someone who had access to the proper hardware to test it. But the way *I* would like

Re: [PATCH 1/1] Update AMD cpu microcode for family 15h

On Wed, 30 May 2018, Ivan Ivanov wrote: > This is still not addressing the outdated 15h microcode version issue > that Rudolf Marek has pointed out. Also, we still hope to see an > updated microcode for 16h architecture as well - it has not received > any updates for two years already True, but no

Re: [PATCH] Add Second Fan Support for Thinkpad P50

igned-off-by: Alexander Kappner I assume you tested this on real hardware? If so: Acked-by: Henrique de Moraes Holschuh > --- > drivers/platform/x86/thinkpad_acpi.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/platform/x86/thinkpad_acpi.c > b/dri

Re: [PATCH 2/2] x86/microcode: Fix CPU synchronization routine

On Thu, 15 Mar 2018, Borislav Petkov wrote: > it is injecting faults and attempting to manipulate some size field - > I'm guessing the encrypted data size. And I'm also guessing that if you > manipulate that size, it would simply take a lot longer to attempt to > decrypt and verify that it is broke

Re: [PATCH 2/2] x86/microcode: Fix CPU synchronization routine

On Thu, 15 Mar 2018, Borislav Petkov wrote: > On Wed, Mar 14, 2018 at 10:00:14PM -0300, Henrique de Moraes Holschuh wrote: > > Intel takes anything from twenty thousand cycles to several *million* > > cycles per core, proportional to microcode update size. > > Got any hard da

Re: [PATCH 2/2] x86/microcode: Fix CPU synchronization routine

On Wed, 14 Mar 2018, Borislav Petkov wrote: > Also, since the update is serialized and it also takes a couple of > thousand cycles per microcode engine, increase the exit timeout by the > number of CPUs on the system. Maybe on AMD it is that fast ;-) Intel takes anything from twenty thousand cycl

Re: [PATCH 4/7] x86/microcode: Do not upload microcode if CPUs are offline

On Wed, 28 Feb 2018, Raj, Ashok wrote: > On Wed, Feb 28, 2018 at 10:11:56AM -0300, Henrique de Moraes Holschuh wrote: > > > Avoid loading microcode if any of the CPUs are offline, and issue a > > > warning. Having different microcode revisions on the system at any time > &

Re: [PATCH 7/7] x86/microcode: Synchronize late microcode loading

On Wed, 28 Feb 2018, Borislav Petkov wrote: > On Wed, Feb 28, 2018 at 10:59:31AM -0300, Henrique de Moraes Holschuh wrote: > > Eek! If I read that right, this effectively halts the entire box until > > every core is updated, with one core entering deep-coma at a time (the > >

Re: [PATCH 7/7] x86/microcode: Synchronize late microcode loading

On Wed, 28 Feb 2018, Borislav Petkov wrote: > + * Late loading dance. Why the heavy-handed stomp_machine effort? > + * > + * - HT siblings must be idle and not execute other code while the other > sibling > + * is loading microcode in order to avoid any negative interactions caused > by > + *

Re: [PATCH 4/7] x86/microcode: Do not upload microcode if CPUs are offline

On Wed, 28 Feb 2018, Borislav Petkov wrote: > Avoid loading microcode if any of the CPUs are offline, and issue a > warning. Having different microcode revisions on the system at any time > is outright dangerous. Even if we update that microcode during CPU early bring-up, before we mark it on-line

Re: [v2 1/3] x86/microcode/intel: Check microcode revision before updating sibling threads

On Thu, 22 Feb 2018, Van De Ven, Arjan wrote: > > > In the past the only guidance was to not load microcode at the same time > > > to > > the > > > thread siblings of a core. We now have new guidance that the sibling must > > > be > > > spinning and not doing other things that can introduce insta

Re: [v2 1/3] x86/microcode/intel: Check microcode revision before updating sibling threads

On Thu, 22 Feb 2018, Raj, Ashok wrote: > On Thu, Feb 22, 2018 at 01:15:06PM +0100, Borislav Petkov wrote: > > On Thu, Feb 22, 2018 at 03:55:54AM -0800, Raj, Ashok wrote: > > > The current code wasn't trying to enforce checking the loaded microcode > > > revision on a thread > > > before attempting

Re: [PATCH] x86/microcode: Check microcode revision before updating sibling threads

On Sat, 17 Feb 2018, Borislav Petkov wrote: > On Sat, Feb 17, 2018 at 11:42:48AM -0200, Henrique de Moraes Holschuh wrote: > > I wonder when this broke, > > It didn't break - we're just printing the update only once. It was before that change, when the microcode subsyste

Re: [PATCH] x86/microcode: Check microcode revision before updating sibling threads

On Fri, 16 Feb 2018, Ashok Raj wrote: > After updating microcode on one of the threads in the core, the > thread sibling automatically gets the update since the microcode > resources are shared. Check the ucode revision on the cpu before > performing a ucode update. I wonder when this broke, becau

Re: [PATCH] platform/x86: thinkpad_acpi: suppress warning about palm detection

> > I'm fine with a signed-off-by or tested-by or suggested-by. There is a > > spelling mistake though, 'hoveres' should be hovers. > > Is there anything else I can do here? I'm not sure any of us have the > ability to find out what lenovo actualy wants this for. I have already acked the patch,

Re: [PATCH] x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel

On Tue, 30 Jan 2018, Borislav Petkov wrote: > On Tue, Jan 30, 2018 at 01:57:21PM +0100, Thomas Gleixner wrote: > > So much for the theory. That's not going to work. If the boot cpu has the > > feature then the alternatives will have been applied. So even if the flag > > mismatch can be observed whe

Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description

On Fri, 26 Jan 2018, Victor Kamensky wrote: > On Fri, 26 Jan 2018, Henrique de Moraes Holschuh wrote: > > On Thu, 25 Jan 2018, Rob Landley wrote: > > > That said, I don't think -h newcx should emit (or recognize) the > > > "TRAILER!!!1!" entry. Tha

Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description

On Thu, 25 Jan 2018, Rob Landley wrote: > That said, I don't think -h newcx should emit (or recognize) the > "TRAILER!!!1!" entry. That's kinda silly in-band signaling for 2018: > files have a length, pipes provide EOF, and each cpiox entry starts with > 6 bytes of c_magic anyway. (I stopped toybox

Re: [RFC 05/10] x86/speculation: Add basic IBRS support infrastructure

On Wed, 24 Jan 2018, David Woodhouse wrote: > I'm kind of tempted to turn it into a whitelist just by adding 1 to the > microcode revision in each table entry. Sure, that N+1 might be another > microcode build that also has issues but never saw the light of day... Watch out for the (AFAIK) still n

Re: dangers of bots on the mailing lists was Re: divide error in ___bpf_prog_run

On Thu, 18 Jan 2018, Dmitry Vyukov wrote: > I've made a bunch of changes yesterday and today. This includes ... > and even per crash/tree. To alleviate this, syzbot will now say e.g. > "So far this crash happened 185 times on linux-next, mmots, net-next, > upstream". So that you can see that it's

Re: dangers of bots on the mailing lists was Re: divide error in ___bpf_prog_run

On Wed, 17 Jan 2018, Dmitry Vyukov wrote: > On Wed, Jan 17, 2018 at 10:32 AM, Pavel Machek wrote: > > On Fri 2018-01-12 17:58:01, syzbot wrote: > >> syzkaller hit the following crash on > >> 19d28fbd306e7ae7c1acf05c3e6968b56f0d196b > > > > What an useful way to describe kernel version. > > > > Cou

Re: [PATCH 2/2] x86/microcode/intel: Extend BDW late-loading with platform id and LLC check

On Mon, 15 Jan 2018, Jia Zhang wrote: > For more details, see erratum BDF90 in document #334165 (Intel Xeon > Processor E7-8800/4800 v4 Product Family Specification Update) from > September 2017. For the record, this erratum may well affect some E5v4 as well. Anything with a LLC/core ratio >= 2.5

Re: Improve retpoline for Skylake

On Fri, 12 Jan 2018, Andi Kleen wrote: > > Skylake still loses if it takes an SMI, right? > > SMMs are usually rare, especially on servers, and are usually > not very predictible, and even if you have FWIW, a data point: SMIs can be generated on demand by userspace on thinkpad laptops, but they

Re: [PATCH] platform/x86: thinkpad_acpi: suppress warning about palm detection

not ABI in any way, so we can change that at any time if we find out it should be named differently). Acked-by: Henrique de Moraes Holschuh > --- > drivers/platform/x86/thinkpad_acpi.c | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/platform/x

Re: platform/x86/thinkpad_acpi: Adjustments for four function implementations

On Tue, 19 Dec 2017, SF Markus Elfring wrote: > >> Delete an error message for a failed memory allocation in three functions > > > > This one is questionable since it prints error messages at ->init() stage. > > I would rather not touch this. > > Do you find the Linux allocation failure report

Re: [PATCH 0/2] platform/x86/thinkpad_acpi: Adjustments for four function implementations

On Tue, 19 Dec 2017, Andy Shevchenko wrote: > On Mon, Dec 18, 2017 at 11:26 PM, SF Markus Elfring > wrote: > > From: Markus Elfring > > Date: Mon, 18 Dec 2017 22:23:45 +0100 > > > > Two update suggestions were taken into account > > from static source code analysis. > > > > Markus Elfring (2): >

Re: [PATCH v3] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

On Sat, 16 Sep 2017, Rob Landley wrote: > So, I added a workaround with a printk in hopes of embarassing them into > someday fixing it. Oh, it will be fixed in Debian alright. I am just waiting the issue to settle a bit to file the bug reports, or maybe even send in the Debian patches myself (not

Re: [PATCH] thinkpad_acpi: Implement tablet mode resolving using GMMS method

rk in other cases. > > Thanks to Peter Zhang of Lenovo for providing information on how to use the > GMMS method to query the tablet mode. > > Signed-off-by: Benjamin Berg > Cc: Peter FP1 Zhang > Cc: Lyude Paul Looks good. Acked-by: Henrique de Moraes Holschuh --- PS: p

Re: boot failure with 4.13.0-rc6 due to ATA errors

On Tue, 29 Aug 2017, Tejun Heo wrote: > On Tue, Aug 29, 2017 at 12:51:02PM -0300, Henrique de Moraes Holschuh wrote: > > > > > ATA-8 and later mirrors the TRUSTED COMPUTING SUPPORTED bit in word > > > > > 48 of > > > > > the IDENTIFY DEVICE

Re: boot failure with 4.13.0-rc6 due to ATA errors

On Tue, 29 Aug 2017, Tejun Heo wrote: > On Tue, Aug 29, 2017 at 09:08:05AM -0600, David Ahern wrote: > > On 8/29/17 6:42 AM, Christoph Hellwig wrote: > > > --- > > > From e661047ec3a25587648b07c02a687a7dac778f3b Mon Sep 17 00:00:00 2001 > > > From: Christoph Hellwig > > > Date: Tue, 29 Aug 2017 14

Re: [PATCH] Do not disable driver and bus shutdown hook when class shutdown hook is set.

On Fri, 11 Aug 2017, Michal Suchánek wrote: > On 2017-08-10 18:30, Jason Gunthorpe wrote: > > On Thu, Aug 10, 2017 at 12:18:11PM +0200, Michal Suchánek wrote: > > > > Existing bus implementations do properly chain to driver shutdown (eg > > > > look at mmc_bus_shutdown) and it appears to have been

Re: [PATCH] turbostat: Running on virtual machine is not supported

On Tue, 25 Jul 2017, Prarit Bhargava wrote: > A common way of determining if the system is a virtual machine is to > search /proc/cpuinfo flags entry for "hypervisor". turbostat must output > a proper error message when found. Maybe you could output that message only if it fails to both use /dev/

Re: An inconsistent behaviour if using built-in initramfs and damaged external one

On Mon, 12 Jun 2017, Henrique de Moraes Holschuh wrote: > So, you can just have /kernel/x86/microcode/.bin > (without leading /kernel, /kernel/x86, /kernel/x86/microcode) in an > early initramfs, and it will *work* for early microcode update purposes. ... > So, if the early initramfs

Re: An inconsistent behaviour if using built-in initramfs and damaged external one

On Mon, 12 Jun 2017, Marcin Szewczyk wrote: > during my experiments with initramfs I have noticed there is something > that looks like a bug in the 9-year old code[1] of the clean_rootfs() > function in init/initramfs.c. An inconsistent behaviour appears when > I have both the built-in initramfs

Re: [PATCH 0/2] microcode: Do early microcode application during resume-from-RAM

On Mon, 12 Jun 2017, Borislav Petkov wrote: > I think I've dreamt of a simple solution to the early microcode > application deal with suspend-to-RAM. The commit message of patch 2 > should explain it in more detail. Patch 1 is a fix for 32-bit when the > ramdisk is being relocated. > > I'm still t

Re: [PATCH 3/6] ccree: use constant time memory comparison for macs and tags

On Sat, 10 Jun 2017, Jason A. Donenfeld wrote: > That's fine. As I mentioned, I really have no clue what this code's > trying to do. If this is just part of some test that doesn't deal with > actual messages that could be forged, then of course there's nothing > that needs to be done and this can b

Re: [PATCH 09/11] platform: thinkpad_acpi: convert to use DRIVER_ATTR_RO/RW

On Fri, 09 Jun 2017, Greg Kroah-Hartman wrote: > We are trying to get rid of DRIVER_ATTR(), and the thinkpad_acpi > driver's attributes can be trivially changed to use DRIVER_ATTR_RO() and > DRIVER_ATTR_RW(). > > Cc: Henrique de Moraes Holschuh > Cc: Darren Hart >

Re: [PATCH] md: don't use flush_signals in userspace processes

On Fri, 09 Jun 2017, NeilBrown wrote: > Or maybe it could be discarded - the md_check_recovery() thing. > The idea was that if you alt-sysrq-K to kill all processes, md arrays > would go into immediate-safe-mode where the metadata is marked clean > immediately after writes finish, rather than waiti

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Wed, 07 Jun 2017, Stephan Müller wrote: > Am Mittwoch, 7. Juni 2017, 00:19:10 CEST schrieb Henrique de Moraes Holschuh: > > On that same idea, one could add an early_initramfs handler for entropy > > data. > > Any data that comes from outside during the boot proc

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Tue, 06 Jun 2017, Theodore Ts'o wrote: > It might be possible, for example, to store a cryptographic key in a > UEFI boot-services variable, where the key becomes inaccessible after > the boot-time services terminate. But you also need either a reliable > time-of-day clock, or a reliable counte

Re: [PATCH 2/3] x86/apic: Add TSC_DEADLINE quirk due to errata

On Thu, 01 Jun 2017, Peter Zijlstra wrote: > On Wed, May 31, 2017 at 06:58:55PM -0300, Henrique de Moraes Holschuh wrote: > > On Wed, 31 May 2017, Peter Zijlstra wrote: > > > + DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_SKYLAKE_X,0x0214), > > ... > >

Re: [PATCH 2/3] x86/apic: Add TSC_DEADLINE quirk due to errata

On Wed, 31 May 2017, Peter Zijlstra wrote: > + DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_SKYLAKE_X,0x0214), ... > + DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_SKYLAKE_MOBILE, 0xb2), > + DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_SKYLAKE_DESKTOP, 0xb2), ... > + DEADLINE_MODEL_MATCH_

Re: [PATCH 0/3] x86: TSC_DEADLINE vs TSC_ADJUST and microcode revisions

On Wed, 31 May 2017, Peter Zijlstra wrote: > These patches rely on the latest microcode data files from Intel [*] > > Without this microcode loaded, we'll print a FW_BUG informing the user to > update their microcode image and disable TSC_DEADLINE support. > > This in turn allows us to remove the

Re: [ibm-acpi-devel] [PATCH 1/1] thinkpad_acpi: Add support for status (external cover) LED

On Fri, 12 May 2017, Pavel Machek wrote: > On Sun 2017-05-07 20:49:03, Henrique de Moraes Holschuh wrote: > > On Sun, 07 May 2017, Pavel Machek wrote: > > > On Thu 2017-01-19 12:21:32, Adam Goode wrote: > > > > This allows the control of the red status LED, which

Re: [PATCH v1 2/3] platform/x86: thinkpad_acpi: Join string literals back

On Wed, 10 May 2017, Andy Shevchenko wrote: > Okay, what I'm going to do is: > 1) drop patch 1 for now; > 2) split patch 2 into two patches (and append your Ack on both); > 3) push to our testing branch (I can send v2 if we need one more round > of review). > > Tell me if there is any objection.

Re: [PATCH v1 2/3] platform/x86: thinkpad_acpi: Join string literals back

On Tue, May 9, 2017, at 14:33, Andy Shevchenko wrote: > On Tue, 2017-05-09 at 14:10 -0300, Henrique de Moraes Holschuh wrote: > > > While here, print negative error without changing a sign as it is a > > > common pattern in the kernel. > > > > A separate patch f

Re: [PATCH v1 2/3] platform/x86: thinkpad_acpi: Join string literals back

bove there were no functional changes intended. > > Signed-off-by: Andy Shevchenko Acked-by: Henrique de Moraes Holschuh > --- > drivers/platform/x86/thinkpad_acpi.c | 182 > +-- > 1 file changed, 65 insertions(+), 117 deletions(-) &g

Re: [PATCH v1 3/3] platform/x86: thinkpad_acpi: Add a comment about 0 in module_param_call()

hy 0 is used as permissions in > module_param_call(). > > [1]: https://patchwork.ozlabs.org/patch/713245/ > > Cc: Richard Weinberger > Signed-off-by: Andy Shevchenko Acked-by: Henrique de Moraes Holschuh > --- > drivers/platform/x86/thinkpad_acpi.c | 1 + > 1 file

Re: [PATCH v1 1/3] platform/x86: thinkpad_acpi: Make logic straight in hotkey_exit()

On Tue, 09 May 2017, Andy Shevchenko wrote: > The commit 4be73005e4dc > > ("thinkpad-acpi: remove uneeded tp_features.hotkey tests in > hotkey_exit") > > adds a complex logic behind hotkey status check in a way > it started mixing logical operations with bitwise ones. > > Refactor the cod

Re: [PATCH 1/1] thinkpad_acpi: Add support for status (external cover) LED

On Sun, 07 May 2017, Pavel Machek wrote: > On Thu 2017-01-19 12:21:32, Adam Goode wrote: > > This allows the control of the red status LED, which is the dot of the "i" > > in the word "ThinkPad" on the outside cover of newer models. > > > > In the manual, both this LED and the power LED are referr

Re: [PATCH v4 1/4] KEYS: Insert incompressible bytes to reserve space in bzImage

On Thu, 20 Apr 2017, Mehmet Kayaalp wrote: > > On Apr 20, 2017, at 7:13 PM, Henrique de Moraes Holschuh > > wrote: > > On Thu, 20 Apr 2017, Mehmet Kayaalp wrote: > >> Include a random filled binary in vmlinux at the space reserved with > >> CONFIG_SYSTEM_E

Re: [PATCH v4 1/4] KEYS: Insert incompressible bytes to reserve space in bzImage

On Thu, 20 Apr 2017, Mehmet Kayaalp wrote: > Include a random filled binary in vmlinux at the space reserved with > CONFIG_SYSTEM_EXTRA_CERTIFICATE. This results in an uncompressed reserved Random data is not always going to be completely incompressible. And just how much it could be compressed a

Re: Race to power off harming SATA SSDs

On Tue, 11 Apr 2017, Martin Steigerwald wrote: > I do have a Crucial M500 and I do have an increase of that counter: > > martin@merkaba:~[…]/Crucial-M500> grep "^174" smartctl-a-201* > smartctl-a-2014-03-05.txt:174 Unexpect_Power_Loss_Ct 0x0032 100 100 > 000 > Old_age Always

Re: Race to power off harming SATA SSDs

On Mon, 10 Apr 2017, James Bottomley wrote: > On Tue, 2017-04-11 at 08:52 +0900, Tejun Heo wrote: > [...] > > > Any comments? Any clues on how to make the delay "smarter" to > > > trigger only once during platform shutdown, but still trigger per > > > -device when doing per-device hotswapping ? >

Re: Race to power off harming SATA SSDs

On Tue, 11 Apr 2017, Tejun Heo wrote: > > The kernel then continues the shutdown path while the SSD is still > > preparing itself to be powered off, and it becomes a race. When the > > kernel + firmware wins, platform power is cut before the SSD has > > finished (i.e. the SSD is subject to an uncl

Re: Race to power off harming SATA SSDs

On Mon, 10 Apr 2017, Bart Van Assche wrote: > On Mon, 2017-04-10 at 20:21 -0300, Henrique de Moraes Holschuh wrote: > > A proof of concept patch is attached > > Thank you for the very detailed write-up. Sorry but no patch was attached > to the e-mail I received from you ...

sd: wait for slow devices on shutdown path

Author: Henrique de Moraes Holschuh Date: Wed Feb 1 20:42:02 2017 -0200 sd: wait for slow devices on shutdown path Wait 1s during suspend/shutdown for the device to settle after we issue the STOP command. Otherwise we race ATA SSDs to powerdown, possibly causing

Race to power off harming SATA SSDs

Summary: Linux properly issues the SSD prepare-to-poweroff command to SATA SSDs, but it does not wait for long enough to ensure the SSD has carried it through. This causes a race between the platform power-off path, and the SSD device. When the SSD loses the race, its power is cut while it is st

Re: [PATCH] Revert "md: raid1: use bio helper in process_checks()"

On Tue, 28 Mar 2017, Wols Lists wrote: > What Arnd is doing is commonly called "defensive programming", and > unfortunately reality shows us that it is usually worth its weight in > gold. That's why you put ASSERTs in code - so that if somebody does > something stupid by accident, it blows up. This

Re: Arrays of variable length

On Sun, 05 Mar 2017, Måns Rullgård wrote: > Tomas Winkler writes: > > Sparse complains for arrays declared with variable length > > > > 'warning: Variable length array is used' > > > > Prior to c99 this was not allowed but lgcc (c99) doesn't have problem > > with that https://gcc.gnu.org/onlinedo

Re: [ibm-acpi-devel] [PATCH 1/1] thinkpad_acpi: Add support for status (external cover) LED

Hello Adam, I apologise for the delay on answering you. On Tue, 31 Jan 2017, Adam Goode wrote: > On Thu, Jan 19, 2017 at 12:21 PM, Adam Goode wrote: > > This allows the control of the red status LED, which is the dot of the "i" > > in the word "ThinkPad" on the outside cover of newer models. > >

Re: Can't boot as Xen dom0 due to commit fe055896

On Fri, 16 Dec 2016, Borislav Petkov wrote: > What for? We don't want to run the microcode loader on xen at all. Or under KVM, or any other hypervisor, really. -- Henrique Holschuh

Re: [PATCH v2] platform/x86: thinkpad_acpi: Initialize local in_tablet_mode and type

0 and type to "". > > Signed-off-by: Darren Hart > Cc: Lyude > Cc: Henrique de Moraes Holschuh > Cc: Andy Shevchenko Acked-by: Henrique de Moraes Holschuh > --- > Since v1: Initialize type also. > > drivers/platform/x86/thinkpad_acpi.c | 4 ++-- >

Re: [PATCH v2] x86/mce: Include the PPIN in machine check records when it is available

On Wed, 23 Nov 2016, Tony Luck wrote: > IMHO people who really care should find the BIOS option and disable it > there. That can also be said about *enabling* it, I think (see below). > Having Linux take responsibility seems a little weird. If we do go Not really. The currently proposed patch

Re: [PATCH v2] x86/mce: Include the PPIN in machine check records when it is available

On Wed, 23 Nov 2016, Borislav Petkov wrote: > On Wed, Nov 23, 2016 at 11:29:51AM -0200, Henrique de Moraes Holschuh wrote: > > 1. Assuming we can do it, always lock it when it is found to be unlocked > >at kernel boot. > > Because...? Privacy, and the fact that /dev/

Re: [PATCH v2] x86/mce: Include the PPIN in machine check records when it is available

On Wed, 23 Nov 2016, Borislav Petkov wrote: > + /* if PPIN is disabled, but not locked, try to enable: */ > + if (!(val & 3ul)) { > + wrmsrl_safe(MSR_PPIN_CTL, val | 2ul); > + rdmsrl_safe(MSR_PPIN_CTL, &val); > + } Actual

Re: [PATCH] x86/boot: Fail the boot if !M486 and CPUID is missing

On Sun, 20 Nov 2016, Borislav Petkov wrote: > We will have set (or not) the X86_FEATURE_CPUID bit at > early_identify_cpu() time. Looking at the code, we do call sync_core() > pretty early. :-\ Hmm, watch out for the early microcode update driver for Intel processors should something get changed i

Re: [PATCH 2/3] thinkpad_acpi: Don't repeat ourselves in hotkey_init_tablet_mode()

On Mon, 07 Nov 2016, Lyude wrote: > There's no need to have multiple copies of the logic we use for checking > whether or not we're in tablet mode, so just use > hotkey_get_tablet_mode() when checking the initial state in > hotkey_init_tablet_mode(). ... > @@ -3130,13 +3130,16 @@ hotkey_init_tabl

Re: [PATCH v4 3/3] thinkpad_acpi: Add support for X1 Yoga (2016) Tablet Mode

On Mon, 07 Nov 2016, Lyude wrote: > For whatever reason, the X1 Yoga doesn't support the normal method of > querying for tablet mode. Instead of providing the MHKG method under the > hotkey handle, we're instead given the CMMD method under the EC handle. > Values on this handle are either 0x1, lapt

Re: [PATCH v3 1/3] thinkpad_acpi: Move tablet detection into separate function

init_tablet_mode(void) > +{ Function definiton all in one line, please. Provided that you fix that minor nit, Acked-by: Henrique de Moraes Holschuh -- Henrique Holschuh

Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

On Sat, 05 Nov 2016, Pavel Machek wrote: > On Sat 2016-11-05 15:46:12, Henrique de Moraes Holschuh wrote: > > On Sat, 05 Nov 2016, Pavel Machek wrote: > > > Hmm, thanks for the pointer. But it seems like I'll have to build my > > > own, as /proc/acpi/ibm does not

Re: [PATCH v2 1/3] thinkpad_acpi: Move tablet detection into separate function

On Sat, 05 Nov 2016, Darren Hart wrote: > On Mon, Oct 31, 2016 at 07:56:40PM -0400, Lyude wrote: > > Suggested by Daniel Martin > > > > Lenovo's having a bit of fun randomly changing what hotkey events and > > acpi handles they use for reporting tablet mode, so unfortunately this > > means we're

Re: [PATCH v2] thinkpad_acpi: Add support for X1 Yoga (2016) Tablet Mode

On Sat, 05 Nov 2016, Darren Hart wrote: > On Thu, Oct 27, 2016 at 03:46:44PM -0400, Lyude wrote: > > For whatever reason, the X1 Yoga doesn't support the normal method of > > querying for tablet mode. Instead of providing the MHKG method under the > > hotkey handle, we're instead given the CMMD met

Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

On Fri, 04 Nov 2016, Viresh Kumar wrote: > On 04-11-16, 10:26, Pavel Machek wrote: > > How would I know if it is thermal capping? There's nothing in dmesg. > > I am not sure what code is responsible for doing that in case of x86, maybe > Rafael and Rui can explain it that better. > > But surely i

Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

On Sat, 05 Nov 2016, Pavel Machek wrote: > [ 825.759661] thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something > is extremely hot! > [ 825.761935] thinkpad_acpi: temperatures (Celsius): 101 49 N/A 78 33 N/A 33 > N/A 47 50 N/A N/A N/A N/A N/A N/A Oh boy, that must be the second time in a

Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

On Sat, 05 Nov 2016, Pavel Machek wrote: > Hmm, thanks for the pointer. But it seems like I'll have to build my > own, as /proc/acpi/ibm does not follow the usual infrastructure... /proc/acpi/ibm has been deprecated for years. 99% of the functionality is available through more modern, standard in

Re: [PATCH] thinkpad_acpi: Add support for X1 Yoga (2016) Tablet Mode

On Thu, 27 Oct 2016, Lyude Paul wrote: > as well, can someone confirm this patch made it to the ibm-acpi-devel > list? When I originally sent this I realized I wasn't subscribed to the > list, so I'm guessing I might need to resend. I received it. I just didn't have the time to go over it in deta

Re: ATA failure regression

On Thu, 29 Sep 2016, t...@kernel.org wrote: > On Wed, Sep 28, 2016 at 05:45:08AM +, Shah, Nehal-bakulchandra wrote: > > Can someone please help me to debug this issue? > > The only thing I can do from libata side is disbling msi on the > affected platform, but the problem doesn't seem confined

Re: iTCO_wdt watchdog on Asus P10S-WS motherboard FREEZES MOTHERBOARD COMPLETELY

On Wed, 21 Sep 2016, David Madore wrote: > On Tue, Sep 20, 2016 at 03:50:09PM +0300, Mika Westerberg wrote: > > Does the machine have WDAT ACPI table (see /sys/firmware/acpi/tables/*)? > > If it does, you can try the new WDAT watchdog driver instead [1]. It > > still uses the same hardware, though

Re: TRIM/UNMAP/DISCARD via ATA Passthrough

On Mon, 12 Sep 2016, Jason A. Donenfeld wrote: > I was wondering if it'd be possible to have the uas driver -- or > perhaps somewhere else in the stack -- fall back to using > ATA-passthrough-TRIM for UNMAP, so that discard can work properly. > AFAIK, the Windows drivers do exactly this. > > If th

Re: [PATCH] prctl,x86 Add PR_[GET|SET]_CPUID for controlling the CPUID instruction.

On Mon, 12 Sep 2016, Andi Kleen wrote: > The cpuid char driver does this, other code may too. Such as anything that calls sync_core(). That includes processor hotplug paths, and who knows what else... > You probably would need to protect these CPUIDs with an exception > handler that temporarily

Re: [PATCH v2 0/5] bug: Provide toggle for BUG on data corruption

On Tue, 16 Aug 2016, Kees Cook wrote: > This adds a CONFIG to trigger BUG()s when the kernel encounters > unexpected data structure integrity as currently detected with > CONFIG_DEBUG_LIST. > > Specifically list operations have been a target for widening flaws to gain > "write anywhere" primitives

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

On Tue, 09 Aug 2016, Jason Cooper wrote: > Perhaps a /dev/hwrng[0-9] per rng? That would lend itself nicely to a > sysfs interface for per device quality, rate, and enabled attributes. > e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled} IMHO, this is mightly annoying to use from ins

Re: x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?

On Wed, 03 Aug 2016, Michael S. Tsirkin wrote: > Are any of these used in kernel though? These specific errata were not the point of my post, rather, it was the fact that errata related to *FENCE and LOCKed instructions exists. I didn't verify whether something attempts to use non-temporal loads

Re: x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?

On Wed, 03 Aug 2016, Michael S. Tsirkin wrote: > > And I'm still discussing this with the hardware people. It seems we > > can do this for *most* things, but not all; the question is where > > exactly we need to do something different. Let's hope the "hardware guys" get back to you soon :(

Re: [PATCH 0857/1285] Replace numeric parameter like 0444 with macro

(cc list trimmed) On Tue, 02 Aug 2016, Baole Ni wrote: > I find that the developers often just specified the numeric value > when calling a macro which is defined with a parameter for access permission. > As we know, these numeric value for access permission have had the > corresponding macro, >

Re: IOMMU+DMAR causing NMIs-s (was: 4.7-rc6: NMI in intel_idle on HP Proliant G6)

On Wed, 13 Jul 2016, Joerg Roedel wrote: > On Wed, Jul 13, 2016 at 11:31:02AM +0300, Meelis Roos wrote: > > > > Bisecting kernel configs shows that it's DMAR+IOMMU. When it is > > > > activated, there is high probability of NMI-s in random places. > > > > > > Hmm, strange. But nothing could reall

Re: Odd performance results

On Wed, 13 Jul 2016, Ingo Molnar wrote: > > The ordering Paul has, namely 0,1 for core0,smt{0,1} is not something > > I've ever seen on an Intel part. AMD otoh does enumerate their CMT stuff > > like what Paul has. > > That's more the natural 'direct' mapping from CPU internal topology to CPU > i

Re: [PATCH] x86: Report Intel platform_id in /proc/cpuinfo

On Tue, Jun 21, 2016, at 13:05, Andi Kleen wrote: > Andi Kleen writes: > > Ping! Any comments on this patch? Well, FWIW, it looks good enough to me. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond whe

Re: Why are the MB/s of avx and raid6: twice as high for a docked ThinkPad than for an undocked ?

On Wed, 15 Jun 2016, Toralf Förster wrote: > This diff is reliable depending whether the T440s is docked (right) or not > (left) : > > Linux t44 4.5.7-hardened-r2 #1 SMP Wed Jun 15 23:39:10 CEST 2016 x86_64 > Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz GenuineIntel GNU/Linux > > 215c215 >

  1   2   3   4   5   6   7   >