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

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

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

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

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

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. > > >

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. > > >

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: 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

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

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

-off-by: Alexander Kappner <a...@godking.net> I assume you tested this on real hardware? If so: Acked-by: Henrique de Moraes Holschuh <h...@hmh.eng.br> > --- > drivers/platform/x86/thinkpad_acpi.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/driv

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

-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/drivers/

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

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

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 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

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

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 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: > 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 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

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

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

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

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

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

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 subsystem still pr

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 subsystem still pr

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,

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,

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

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

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

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

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. That's k

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. That's k

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

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

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

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

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

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

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

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. > > > >

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: [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: 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

rning, and I am fine with the current name for the events (they are 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 <h...@hmh.eng.br> > --- > drivers/platform/x86/thinkpad_acpi.c | 10 ++ >

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

they are 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: 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 > >

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

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

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

work 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 <bb...@redhat.com> > Cc: Peter FP1 Zhang <zhang...@lenovo.com> > Cc: Lyude Paul <ly.

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

work 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 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,

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

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] 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

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

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, 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

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

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

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

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

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

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 <ibm-a...@hmh.eng.br> &

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 > Cc:

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

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

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 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

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

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 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), ... > +

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), ... > +

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

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

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: [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

  1   2   3   4   5   6   7   8   9   10   >