On Mon, 17 Feb 2014, Petr Tesarik wrote:
> Well, if the user passes both nr_cpus and maxcpus parameters to the
> kernel, I think it's fair to issue two warnings. But if everyone agrees
> that only the maxcpus warning should be printed in that case, I can
> send a version 2 of my patch.
Please reme
t
> CC: ibm-acpi-de...@lists.sourceforge.net
> CC: platform-driver-...@vger.kernel.org
> CC: linux-kernel@vger.kernel.org
Acked-by: Henrique de Moraes Holschuh
--
"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
On Wed, Feb 12, 2014, at 13:32, Takashi Iwai wrote:
> The mute LED states have to be restored after resume.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70351
> Cc: [v3.13+]
> Signed-off-by: Takashi Iwai
Acked-by: Henrique de Moraes Holschuh
--
"One disk t
On Fri, 31 Jan 2014, Igor Podlesny wrote:
>Probably every Linux newcomer's going to have concerns regarding
> low free memory and hear an explanation from Linux old fellows that's
> actually there's plenty of -- it's just cached, but when it's needed
> for applications it's gonna be used -- on
On Sat, 25 Jan 2014, Andi Kleen wrote:
> On Sat, Jan 25, 2014 at 02:35:58PM -0200, Henrique de Moraes Holschuh wrote:
> > On Fri, 24 Jan 2014, Andi Kleen wrote:
> > > For testing purposes it can be useful to downgrade microcode.
> > > Normally the driver only allows upgr
On Sat, 25 Jan 2014, Ingo Molnar wrote:
> * Dave Jones wrote:
> > I have a system with 4 cores (configured with CONFIG_NR_CPUS=4) that shows
> > during boot..
> >
> > [0.00] smpboot: 8 Processors exceeds NR_CPUS limit of 4
> >
> > it looks like this is because..
> >
> > [0.00]
On Fri, 24 Jan 2014, Andi Kleen wrote:
> For testing purposes it can be useful to downgrade microcode.
> Normally the driver only allows upgrading.
The code is not prepared to work correctly when downgrading is allowed, in
the presence of shadowed microcode. When a firmware request results in mor
On Sat, 25 Jan 2014, Rafael J. Wysocki wrote:
> On Saturday, January 25, 2014 02:53:24 PM Rafael J. Wysocki wrote:
> > On Saturday, January 25, 2014 11:03:09 AM Jörg Otte wrote:
> > > Kernel 3.13.0-06058-g2d08cd0 displays following errors on the console:
> > >
> > > ACPI: \_PR_.CPU4: failed to get
On Thu, 16 Jan 2014, Aravind Gopalakrishnan wrote:
> We might want to still have a software fix for this just in case
> someone uses older BIOSes..
There is no "just in case" when it comes to someone using outdated firmware.
It is a *given*, except for hardware that is only used in HPC and multipl
I just got this assigned to amd64-microcode in Debian, but it is something
that needs to be worked around by the EFI/BIOS and/or the kernel.
Since we all know just how well it pans out to depend on BIOS/EFI updates
for *anything*, I'm raising the issue here. IMHO looks like it would be
worthwhile
On Tue, 31 Dec 2013, Julian Andres Klode wrote:
> We might be able to work around this by simple setting stop = start
> if a new write causes the stop threshold to be below the start
> threshold. But this also seems ugly.
It is the safest way, but the correct pseudo-code would be, assuiming
unsign
On Mon, 30 Dec 2013, Henrique de Moraes Holschuh wrote:
> On Mon, 30 Dec 2013, Julian Andres Klode wrote:
> > On Mon, Nov 11, 2013 at 02:56:30PM +0100, Julian Andres Klode wrote:
> > > Add support for battery charge thresholds in new Sandy Bridge and Ivy
> > > Bridge
&g
On Mon, 30 Dec 2013, Julian Andres Klode wrote:
> On Mon, Nov 11, 2013 at 02:56:30PM +0100, Julian Andres Klode wrote:
> > Add support for battery charge thresholds in new Sandy Bridge and Ivy Bridge
> > ThinkPads. Based on the unofficial documentation in tpacpi-bat.
> >
> > The threshold files su
On Mon, 30 Dec 2013, Johannes Berg wrote:
> On Mon, 2013-12-30 at 20:58 +0100, Julia Lawall wrote:
> > > Is there any way we could catch (sparse, or some other script?) that
> > > struct reorganising won't break the condition needed ("within a
> > > structure that contains at least two more bytes")
On Mon, 30 Dec 2013, Julian Andres Klode wrote:
> I think that a more generic approach is a good idea, but
> I don't think creating a new power supply device would be the right
...
> We could extend the existing battery devices and then get paths like
> /sys/class/power_supply/BAT0/start_ch
On Sat, 28 Dec 2013, Julian Andres Klode wrote:
> On Mon, Nov 11, 2013 at 02:56:29PM +0100, Julian Andres Klode wrote:
> > This patch series adds support for specifying charging thresholds,
> > forcing a battery to discharge, and inhibiting charging, on ThinkPad
> > Laptops using Sandy Bridge or ne
On Mon, 16 Dec 2013, Peter Hurley wrote:
> >Is this a 3.13-final thing, or can it wait for 3.14-rc1?
>
> Definitely not 3.13 at this point -- it should go to -next.
Please earmark it for stable, if possible. This fixes a rather annoying long
time bug, after all...
--
"One disk to rule them al
On Wed, 18 Dec 2013, Lv Zheng wrote:
> CONFIG_ACPI dependent code should include instead of
> directly including . This patch cleans up such wrong
> inclusions for Thinkpad ACPI users.
...
> drivers/platform/x86/thinkpad_acpi.c |1 -
> include/linux/thinkpad_acpi.h|2 ++
> soun
On Sun, 15 Dec 2013, Andrew Morton wrote:
> On Sun, 24 Nov 2013 01:53:11 -0200 Henrique de Moraes Holschuh
> wrote:
> > On Sun, 24 Nov 2013, Matthew Garrett wrote:
> > > On Sat, Nov 23, 2013 at 10:40:15PM -0200, Henrique de Moraes Holschuh
> > > wrote:
> &
On Fri, 13 Dec 2013, Henrique de Moraes Holschuh wrote:
> 2. This change has unintended side-effects that ought to be at least
> documented:
>
> In "allow downgrade" mode, should you send a microcode pack with several
> microcodes to the kernel, and more than one o
On Fri, 06 Dec 2013, Andi Kleen wrote:
> For testing purposes it can be useful to downgrade microcode.
> Normally the driver only allows upgrading.
...
> int
> update_match_revision(struct microcode_header_intel *mc_header, int rev)
> {
> + if (allow_downgrade)
> + return 1;
>
On Sat, 30 Nov 2013, venkata koppula wrote:
> Yeah, I understand that we need to utilize the resources as much as we
> can. At the same time user should not
> feel that system is slow and user should never wait for the copying
> operation should complete to launch another
> application meanwhile.
On Sun, 24 Nov 2013, Matthew Garrett wrote:
> On Sat, Nov 23, 2013 at 10:40:15PM -0200, Henrique de Moraes Holschuh wrote:
> > On Fri, 22 Nov 2013, Matthew Garrett wrote:
> > > We have userspace that relies on uevents of type
> > > BACKLIGHT_UPDATE_HOTKEY. I don't
On Fri, 22 Nov 2013, Matthew Garrett wrote:
> On Fri, Nov 22, 2013 at 09:36:01AM -0200, Henrique de Moraes Holschuh wrote:
> > On Thu, 21 Nov 2013, Matthew Garrett wrote:
> > > The uevent support was initially added to handle systems where pressing
> > > a hotkey genera
On Thu, 21 Nov 2013, Matthew Garrett wrote:
> On Thu, Nov 21, 2013 at 09:43:32AM -0200, Henrique de Moraes Holschuh wrote:
> > With this patchset applied, as far as I can tell anything that used to be
> > uevent-driven by the backlight class will break: when a process changes th
On Tue, 12 Nov 2013, Jingoo Han wrote:
> On Tuesday, November 12, 2013 8:57 AM, Kyungmin Park wrote:
> > From: Kyungmin Park
> >
> > The most mobile phones have Ambient Light Sensors and it changes brightness
> > according lux.
> > It means it changes backlight brightness frequently by just writ
On Thu, 07 Nov 2013, Kees Cook wrote:
> On Thu, Nov 7, 2013 at 4:55 AM, Henrique de Moraes Holschuh
> wrote:
> > On Tue, 05 Nov 2013, Andy Lutomirski wrote:
> >> Maybe the thing to do is to put a warning in the config text for
> >> CONFIG_OABI_COMPAT that des
On Thu, 07 Nov 2013, Ingo Molnar wrote:
> How about:
>
> http://www.intel.com/content/www/us/en/search.html?keyword=linux+microcode+data+file
>
> ? That, by the looks of it, appears to be a reasonably stable URL.
But it is also mostly useless. No version information in the results, and
the ne
On Tue, 05 Nov 2013, Andy Lutomirski wrote:
> Maybe the thing to do is to put a warning in the config text for
> CONFIG_OABI_COMPAT that describes the problems (malicious userspace
> can confuse syscall auditors, strace, etc.), change the "if in doubt"
> part to N, and disable seccomp filters if CO
Is there a reason to not enforce strictlimit by default?
--
"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
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To unsubscribe from thi
On Mon, 28 Oct 2013, Stephan Mueller wrote:
> If it is accepted that the CPU Jitter RNG delivers entropy, the latter
> update may now allow us to get rid of storing the seed file during
> shutdown and restoring it during the next boot sequence.
That's a 4096-bit safety net (uncredited entropy) w
On Mon, 28 Oct 2013, Borislav Petkov wrote:
> So Prarit, please split this patch into changes which *directly* address
> the issue and other cleanups ontop. This will simplify review immensely
> as having one single bulky patch is not easy on the eyes.
>
> Then, make sure to audit the lowlevel dri
On Fri, 18 Oct 2013, Felipe Pena wrote:
> In the thermal_init function when checking for thinkpad_id.ec_model,
> the 'ta2' variable is being OR'd when acpi_ec_read call succeeds,
> on fail it is setting 0 to 'ta1' variable instead.
>
> Signed-off-by: Felipe Pena
NAK.
ta1 == 0 implies malfunctio
On Thu, 24 Oct 2013, Takashi Iwai wrote:
> SNDRV_CARDS can be specified via Kconfig since 3.11 kernel, so this
> can be over 32bit integer range, which leads to a build error.
>
> Cc: [v3.11+]
> Signed-off-by: Takashi Iwai
Acked-by: Henrique de Moraes Holschuh
--
"O
On Wed, 23 Oct 2013, Prarit Bhargava wrote:
> After all this I completely forgot the problem I'm trying to solve here. The
> issue is that with HOTPLUG & request_microcode_nowait(), if the microcode
> image
> is not found (that is the file is not found on disk), then EACH cpu waits 1
> minute and
On Wed, 23 Oct 2013, Joe Perches wrote:
> Emitting an OOM message isn't necessary after input_allocate_device
> as there's a generic OOM and a dump_stack already done.
>
> Signed-off-by: Joe Perches
For the thinkpad-acpi bits:
Acked-by: Henrique de Moraes Holschuh
--
On Thu, 03 Oct 2013, Stephan von Krawczynski wrote:
> Does the above output mean that the cores are numbered right across the two
> physical cpus? Does this mean one has to pin processes to 0,2,4,... to stay in
> "short distance" to node 0 RAM?
...
> If so, it would be a lot better to have them n
On Thu, 26 Sep 2013, Sherry Hurwitz wrote:
> We have failed to reproduce a hang while loading microcode.
I got an offer from a Debian user to test it over the weekend, let's hope
he will have more luck(?) at hitting the issue. If he does, it should give
us sysrq+t dumps of the hung system.
> We
On Fri, 27 Sep 2013, Yves-Alexis Perez wrote:
> On ven., 2013-09-27 at 12:20 -0300, Henrique de Moraes Holschuh wrote:
> > Some testing on a *60 (T60,X60...) would also be best, I cannot test
> > this on
> > my T43.
> >
> > Anyway, the code itself looks fine,
t notification
> on backlight hotkey press as a result of evaluation of _BCL.
>
> Signed-off-by: Aaron Lu
> Tested-by: Igor Gnatenko
Some testing on a *60 (T60,X60...) would also be best, I cannot test this on
my T43.
Anyway, the code itself looks fine, so:
Acked-by: Henrique de Mora
On Thu, 26 Sep 2013, Aaron Lu wrote:
> I checked the git log for the commit to use tpacpi_acpi_handle_locate to
> locate video controller's ACPI handle, it's:
>
> commit 122f26726b5e16174bf8a707df14be1d93c49d62
> Author: Henrique de Moraes Holschuh
> Date: Mon Aug
On Tue, 24 Sep 2013, Aaron Lu wrote:
> locate handle for ACPI video by HID, the problem is, ACPI video node
> doesn't really have HID defined(i.e. no _HID control method is defined
ACPI video is supposed to attach a virtual HID node (ACPI_VIDEO_HID) to ACPI
video devices so as to keep the non-triv
On Tue, 24 Sep 2013, Sherry Hurwitz wrote:
> You can direct AMD microcode issues to me now.
> We are setting up some systems in the lab and trying to duplicate
> the problem now.
Thank you!
If you're going to be taking care of AMD microcode update issues, maybe it
would be a good idea to add your
On Mon, 23 Sep 2013, Pavel Machek wrote:
> > I have rather old thinkpad x60 here. Long time ago, I noticed that on
> > high continuous ethernet load, it shuts itself down in regular
> > way. I traced it down to overheat, followed by ACPI signaling system
> > to go down.
>
> just to wrap the story
On Sun, 22 Sep 2013, Igor Gnatenko wrote:
> Hi all! How about fix this problem ?
> I have ThinkPad X230 and have micmute button, which works correctly and
> LED on this button, which doesn't work.
> I looked older threads[0] about this, but nothing changed since 2011..
The problem is not on the th
On Thu, 19 Sep 2013, Borislav Petkov wrote:
> On Thu, Sep 19, 2013 at 03:15:54PM -0300, Henrique de Moraes Holschuh wrote:
> > I can request help on debian-user or debian-devel to get someone with
> > an AMD box to help with bissection, but it is usually best if we don't
>
On Thu, 19 Sep 2013, Borislav Petkov wrote:
> On Thu, Sep 19, 2013 at 11:58:34AM -0300, Henrique de Moraes Holschuh wrote:
> > I take care of the amd64 microcode update support for Debian, and I'm
> > receiving user reports of lockup issues with the AMD microcode driver in
Jacob, Andreas,
I take care of the amd64 microcode update support for Debian, and I'm
receiving user reports of lockup issues with the AMD microcode driver in
several kernels. This is about the runtime update interface,
/sys/devices/system/cpu/*/microcode/reload and
/sys/devices/system/cpu/microc
On Thu, 12 Sep 2013, Neil Horman wrote:
> On Thu, Sep 12, 2013 at 03:46:30PM -0300, Henrique de Moraes Holschuh wrote:
> > On Thu, 12 Sep 2013, Neil Horman wrote:
> > > Both of these execptions should be rare, and are something the
> > > administrator
> > > w
On Thu, 12 Sep 2013, Neil Horman wrote:
> Both of these execptions should be rare, and are something the administrator
> will want to know about, so as not to confuse the real error with the mystery
> -ENOENT you would get if you fell back to the user mode helepr and it wansn't
> configured on in t
On Tue, 10 Sep 2013, Matthew Garrett wrote:
> That's why modern systems require signed firmware updates.
Linux doesn't. Is someone working on adding signature support to the
runtime firmware loader?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the
Hi Jason!
On Thu, 22 Aug 2013, Jason A. Donenfeld wrote:
> The micmute LED is currently unused. This patch allows it to be hooked
> up to various LED triggers.
>
> Signed-off-by: Jason A. Donenfeld
> ---
> drivers/platform/x86/thinkpad_acpi.c | 6 --
> 1 file changed, 4 insertions(+), 2 de
On Thu, 22 Aug 2013, Jason A. Donenfeld wrote:
> Thinkpads with a micmute LED do not have a capslock LED. The micmute LED
> is currently not used by any piece of Linux kernel land or user land. It
> seems reasonable to hook it up to caps lock, at least by default, so
> users can have some degree of
et rid of this old stuff...
>
> CC: rui.zh...@intel.com
> CC: l...@kernel.org
> CC: Rafael J. Wysocki
> CC: Matthew Garrett
> CC: Henrique de Moraes Holschuh
For the thinkpad-acpi hunks:
Acked-by: Henrique de Moraes Holschuh
> Signed-off-by: Thomas Renninger
> --
s param
> is useless and should vanish as well.
>
> CC: Henrique de Moraes Holschuh
> Signed-off-by: Thomas Renninger
Acked-by: Henrique de Moraes Holschuh
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In th
On Sun, 30 Jun 2013, Pavel Machek wrote:
> > > > You know, either the "long" or the "offline" SMART test routines do
> > > > exactly
> > > > that on any spinning rust device with a firmware that is not utterly
> > > > broken.
> > > >
> > > > The HDD's firmware will rewrite, and even reallocate a
On Sat, 29 Jun 2013, Mark Lord wrote:
> On 13-06-29 02:47 PM, Henrique de Moraes Holschuh wrote:
> > You know, either the "long" or the "offline" SMART test routines do exactly
> > that on any spinning rust device with a firmware that is not utterly broken.
>
You know, either the "long" or the "offline" SMART test routines do exactly
that on any spinning rust device with a firmware that is not utterly broken.
The HDD's firmware will rewrite, and even reallocate any "weak" sectors
found by the surface scan.
--
"One disk to rule them all, One disk to
On Sun, 23 Jun 2013, H. Peter Anvin wrote:
> On 06/23/2013 02:56 PM, Henrique de Moraes Holschuh wrote:
> >
> > And as far as I could find from Intel's not-that-complete public
> > "specification updates", we are applying the errata workaround to a few more
&
On Sun, 23 Jun 2013, H. Peter Anvin wrote:
> On 06/23/2013 12:29 PM, Henrique de Moraes Holschuh wrote:
> > On Sun, 23 Jun 2013, H. Peter Anvin wrote:
> >> Why do you care about performance when PAT is disabled?
> >
> > It will regress already slow boxes. We blackl
On Sun, 23 Jun 2013, H. Peter Anvin wrote:
> Why do you care about performance when PAT is disabled?
It will regress already slow boxes. We blacklist a LOT of P4s, PMs, etc and
nobody ever took the pain to track down which ones of those actually have
PAT+MTRR aliasing bugs.
These boxes have boar
On Fri, 07 Jun 2013, Adam Lee wrote:
> Some new Lenovo or ThinkPad laptops don't have EC controllable LEDs.
> This patch adds their quirks.
>
> Signed-off-by: Adam Lee
NAK.
Let's see if we can do this in a better way that is a bit more future-proof.
--
"One disk to rule them all, One disk t
On Fri, 07 Jun 2013, Adam Lee wrote:
> Some new Lenovo or ThinkPad laptops don't have EC controllable LEDs,
> their LED quirks are 0. This patch set led_supported=TPACPI_LED_NONE
> when quirk equals 0.
>
> Signed-off-by: Adam Lee
Acked-by: Henrique de Moraes Holschuh
>
On Mon, 17 Jun 2013, Henrique de Moraes Holschuh wrote:
> On Fri, 07 Jun 2013, Adam Lee wrote:
> > Not all 0-15 LEDs are available for all models, sometimes it's even not
> > safe. This patch return -NODEV while operating uninitialized LEDs.
> >
> > Signed-off-by
On Sat, 08 Jun 2013, Adam Lee wrote:
> Not all 0-15 LEDs are available for all models, sometimes it's even not
> safe. This patch return -NODEV while operating uninitialized LEDs.
>
> Signed-off-by: Adam Lee
Acked-by: Henrique de Moraes Holschuh
> ---
> drivers/platf
On Fri, 07 Jun 2013, Adam Lee wrote:
> Not all 0-15 LEDs are available for all models, sometimes it's even not
> safe. This patch return -NODEV while operating uninitialized LEDs.
>
> Signed-off-by: Adam Lee
Acked-by: Henrique de Moraes Holschuh
> ---
> drivers/platf
Can you get me the ACPI interface documentation? It should be simple to get
it, but I haven't emailed the Lenovo BIOS engineers for some time.
Basically, create a new LED method in thinkpad-acpi, lock it down to vendor
lenovo, detect the new interfaces, and only check the two-argument LED one i
On Fri, 31 May 2013, Andreas Herrmann wrote:
> On Fri, May 31, 2013 at 01:26:49AM -0300, Henrique de Moraes Holschuh wrote:
> > On Thu, 30 May 2013, Jacob Shin wrote:
> > > mkdir initrd
> > > cd initrd
> > > -mkdir kernel
> > > -mkdir kernel/x8
On Thu, 30 May 2013, Jacob Shin wrote:
> mkdir initrd
> cd initrd
> -mkdir kernel
> -mkdir kernel/x86
> -mkdir kernel/x86/microcode
> -cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin
> -find .|cpio -oc >../ucode.cpio
> +mkdir -p kernel/x86/microcode
> +cp ../microcode.bin kernel/x86/mic
On Thu, 07 Mar 2013, Toshi Kani wrote:
> dock.0 on your Lenovo likely shows as "battery_bay", which I think you
> cannot undock regardless of this patch. Can you try to undock the one
You're supposed to be able to undock any thinkpad battery just fine, and it
used to work on older firmware such a
with hotkey_kthread(). When kthread_stop() returns the
> > thread is already dead, it called do_exit()->complete_vfork_done().
> >
> > Reported-by: Artem Savkov
> > Reported-by: Maciej Rutecki
> > Signed-off-by: Oleg Nesterov
> >
>
> Reviewed-by: Mandee
On Sat, 09 Mar 2013, Borislav Petkov wrote:
> On Sat, Mar 09, 2013 at 09:06:46AM +0100, Yves-Alexis Perez wrote:
> > Also see https://bugzilla.kernel.org/show_bug.cgi?id=51231 and
> > https://patchwork.kernel.org/patch/2124861/
>
> Great, another fit-the-hardware-to-the-software idiocy because tho
On Mon, 04 Mar 2013, Borislav Petkov wrote:
> I get this in dmesg with 3.9-rc1:
>
> [ 12.951434] thinkpad_acpi: unhandled HKEY event 0x6050
> [ 12.951438] thinkpad_acpi: please report the conditions when this event
> happened to ibm-acpi-de...@lists.sourceforge.net
> [ 13.516752] thinkpad_a
On Wed, 06 Mar 2013, Oleg Nesterov wrote:
> On 03/05, Henrique de Moraes Holschuh wrote:
> > On Tue, 05 Mar 2013, Mandeep Singh Baines wrote:
> > > This mutex seems wrong. Its held the entire time the kthread is
> > > running. I think its used to synchronize on
On Tue, 05 Mar 2013, Mandeep Singh Baines wrote:
> This mutex seems wrong. Its held the entire time the kthread is
> running. I think its used to synchronize on the exit of the kthread. A
> completion would more appropriate in that case.
>From the top of the driver source:
/* Acquired while the p
On Sun, 30 Dec 2012, Richard Hartmann wrote:
> On Sun, Dec 30, 2012 at 3:00 AM, Henrique de Moraes Holschuh > wrote:
>
> > Acked-by: Henrique de Moraes Holschuh
> >
>
> Thanks for the two ACKs.
>
> Just to make sure: From how I read the (outdated) Copyright
-baudet.net
> T420s - 20120608080824.gs25...@hexapodia.org
> W520 - 20121008181050.gf2...@ericlaptop.home.christensenplace.us
>
> Signed-off-by: Richard Hartmann
Acked-by: Henrique de Moraes Holschuh
> ---
> drivers/platform/x86/thinkpad_acpi.c | 11 ---
> 1 file
On Thu, 27 Dec 2012, Richard Hartmann wrote:
> On Thu, Dec 27, 2012 at 11:38 AM, Henrique de Moraes Holschuh <
> h...@hmh.eng.br> wrote:
>
> > /* fallthrough */
> >
> [...]
>
> > and letting it proceed to the TP_HKEY_EV_KEY_NUMLOCK block.
> >
&g
On Wed, 26 Dec 2012, Richard Hartmann wrote:
> + case TP_HKEY_EV_AC_CHANGED:
> + pr_info("AC status has changed\n");
> + /* X120e, x121e, X220, X220i, X220t, X230, T420, T420s, W520:
> + * AC status changed; can be triggered by plugging or
> + *
nly compile
> tested.
>
> Signed-off-by: Tejun Heo
> Cc: Henrique de Moraes Holschuh
> Cc: ibm-acpi-de...@lists.sourceforge.net
> Cc: platform-driver-...@vger.kernel.org
Acked-by: Henrique de Moraes Holschuh
> ---
> Please let me know how this patch should be routed. I
Jacob,
Since you seem to be dealing with AMD microcode, do you know anything about
the amd64.org demise? Where do we get the microcode update data, now?
--
"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
On Sat, 17 Nov 2012, Borislav Petkov wrote:
> On Thu, Nov 15, 2012 at 06:35:17PM -0500, Boris Ostrovsky wrote:
> > One possibility is that BIOS already incorporated all patches (which
> > typically is the case) and so the driver doesn't have to do anything.
>
> /proc/cpuinfo contains ucode version
On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
> On 11/15/2012 03:45 PM, Henrique de Moraes Holschuh wrote:
> >On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
> >>Add valid patch size for family 16h processors
> >>
> >>Signed-off-by: Boris Ostrovsky
> >
> &
On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
> Add valid patch size for family 16h processors
>
> Signed-off-by: Boris Ostrovsky
Is this something that needs to go to -stable ?
> #define F1XH_MPB_MAX_SIZE 2048
> #define F14H_MPB_MAX_SIZE 1824
> #define F15H_MPB_MAX_SIZE 4096
> +#define F16H_M
On Wed, 14 Nov 2012, Jesse Barnes wrote:
> + unsigned long bad_ranges[] = {
> + 0x2005,
> + 0x2011,
> + 0x2013,
> + 0x20138000,
> + 0x40004000,
Yikes. Can this be fixed thro
On Fri, 05 Oct 2012, da...@lang.hm wrote:
> >On Thu, Oct 4, 2012 at 9:50 PM, Kurt H Maier wrote:
> >>On Wed, Oct 03, 2012 at 07:27:01PM +, Al Viro wrote:
> >>>Al, that -><- close to volunteering for maintaining that FPOS
> >>>kernel-side...
> >>
> >>This would be fantastic.
> >
> >And that wo
On Sat, 29 Sep 2012, H. Peter Anvin wrote:
> >Intel doesn't make it easy to get all processor specification updates at
> >once so that I could hunt down every processor which acknowledges the
> >existence of that errata before replying, so I will assume for the moment
> >that the comment is mostly
On Sat, 29 Sep 2012, H. Peter Anvin wrote:
> PAT support are lacking only in the Pentium Pro and Pentium II. Sorry, if
> you're using crap that old, you don't get to screw up the kernel for
> everyone else.
PAT is blacklisted for x86_model < 15 on Intel, which covers a lot
more boxes than p-pro a
On Fri, 28 Sep 2012, H. Peter Anvin wrote:
> On 09/28/2012 10:37 AM, Peter Hurley wrote:
> > An interesting side note: more recent revisions of this BIOS (rev. A11)
> > report one less variable MTRR (so, IA32_MTRRCAP is writable?)
> >
> >>> However, the right way to fix that is to use the PAT inte
On Mon, 03 Sep 2012, Michael Wang wrote:
> On 09/01/2012 07:02 AM, Henrique de Moraes Holschuh wrote:
> > Just got one of these:
> >
> > kernel: INFO: rcu_bh detected stall on CPU 2 (t=0 jiffies)
> > kernel: Pid: 0, comm: swapper/2 Not tainted 3.2.28+ #2
> &g
Just got one of these:
kernel: INFO: rcu_bh detected stall on CPU 2 (t=0 jiffies)
kernel: Pid: 0, comm: swapper/2 Not tainted 3.2.28+ #2
kernel: Call Trace:
kernel: [] __rcu_pending+0x159/0x400
kernel: [] rcu_check_callbacks+0x9b/0x120
kernel: [] update_process_times+0x43/0x80
kernel: [] tick_sc
On Sat, 25 Aug 2012, wbrana wrote:
> On 8/25/12, Pekka Enberg wrote:
> > So despite my humble suggestion, you've filled up my inbox with
> > pointless rambling. Would it be at all possible you just got the f*ck
> > off LKML? I know it's difficult to hear this but nobody gives a shit
> > about your
On Sun, 19 Aug 2012, Yu, Fenghua wrote:
> > From: Henrique de Moraes Holschuh [mailto:h...@hmh.eng.br]
> > On Sat, 18 Aug 2012, Fenghua Yu wrote:
> > > + char ucode_name[] =
> > "kernel/x86/microcode/GenuineIntel/microcode.hex";
> >
> > Why n
On Sat, 18 Aug 2012, Yu, Fenghua wrote:
> > From: Henrique de Moraes Holschuh [mailto:h...@hmh.eng.br] On Sat, 18 Aug
> > 2012, Fenghua Yu wrote:
> > > Given a file's name, find its starting point in a cpio formated area.
> > This will
> > > be used to fin
On Sat, 18 Aug 2012, Fenghua Yu wrote:
> + char ucode_name[] = "kernel/x86/microcode/GenuineIntel/microcode.hex";
Why name it ".hex" when you're loading binary data? I suggest ".bin". It
is confusing to have .hex there, since you're not dealing with the Intel HEX
format, nor anything text-li
On Sat, 18 Aug 2012, Fenghua Yu wrote:
> Given a file's name, find its starting point in a cpio formated area. This
> will
> be used to find microcode in combined initrd image. But this function is
> generic and could be used in other places.
Shouldn't this (very useful) feature get its own docum
On Fri, 17 Aug 2012, Pekka Enberg wrote:
> [ 3129.616297] thinkpad_acpi: unhandled HKEY event 0x6040
> [ 3129.616298] thinkpad_acpi: please report the conditions when this
> event happened to ibm-acpi-de...@lists.sourceforge.net
> [ 3129.616949] thinkpad_acpi: undocked from hotplug port replicator
On Wed, 15 Aug 2012, Greg Kroah-Hartman wrote:
> On Tue, Aug 14, 2012 at 09:26:54PM -0300, Henrique de Moraes Holschuh wrote:
> > I believe the patch bellow, which was required on 3.2, will also be
> > necessary.
>
> Will it be necessary to apply this before this patch goe
I believe the patch bellow, which was required on 3.2, will also be
necessary.
From: Kevin Winchester
Subject: [PATCH] x86: Simplify code by removing a !SMP #ifdefs from 'struct
cpuinfo_x86'
commit 141168c36cdee3ff23d9c7700b0edc47cb65479f and
commit 3f806e50981825fa56a7f1938f24c0680816be45 upst
On Tue, 14 Aug 2012, Ulrich Windl wrote:
> After several reboots due to memory errors after excellent power-saving of
> Linux on a HP DL380G7 with Intel Xeon 5650 processors (all in on memory
> bank), I found out the errate "BD104" and "BD123". The former should be
> fixed in a microcode revision "
301 - 400 of 652 matches
Mail list logo
