[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b647ffbd0904230155t61578496pf75fb79e54def3a3@mail.gmail.com>
Date: Thu, 23 Apr 2009 10:55:29 +0200
From: Dmitry Adamushko <dmitry.adamushko@...il.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Rusty Russell <rusty@...tcorp.com.au>,
Andreas Herrmann <andreas.herrmann3@....com>,
Peter Oruba <peter.oruba@....com>,
Arjan van de Ven <arjan@...radead.org>,
Hugh Dickins <hugh@...itas.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86 microcode: work_on_cpu and cleanup of the
synchronization logic
2009/4/23 Ingo Molnar <mingo@...e.hu>:
>
> * Dmitry Adamushko <dmitry.adamushko@...il.com> wrote:
>
>> Version 3
>>
>> diff with v.2
>>
>> - use smp_call_function_single() instead of work_on_cpu() as suggested by Ingo;
>> - add 'enum ucode_state' as return value of request_microcode_{fw,user}
>> - minor cleanups
>
> This version looks really nice structurally. What type of testing
> have you done on the patch, on what CPU type?
Quite limited testing. It looks like there is no newer ucode availble
for my dual-core Intel Core2 Duo (Thinkpad R60) so what I did is as
follows:
- change update_match_revision() in microcode_intel.c in a way that
allows loading of a ucode with a revision == the current revision
(rev. 0x57 in my case). From the POV of the microcode module it
nevertheless looks like an update;
- update via /dev/microcode (CONFIG_MICROCODE_OLD_INTERFACE) with a .dat file;
- suspend -> resume (reload of ucode via cpu-callbacks)
These tests worked for me.
Obviously, it'd be nice if more people could give it a try (e.g.
update with a firmware image and also on AMD - although the changes in
microcode_amd.c are quite straightforward).
p.s. argh... just noticed that the following line is redundant in
microcode_core.c (forgot to remove it)
+enum { UCODE_UPDATE_ERR, UCODE_UPDATE_OK, UCODE_UPDATE_NAVAIL };
>
> Thanks,
>
> Ingo
>
--
Best regards,
Dmitry Adamushko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists