Open Source Technology Center
>-Original Message-
>From: David Brownell [mailto:[EMAIL PROTECTED]
>Sent: Saturday, February 09, 2008 6:03 PM
>To: Jiri Slaby
>Cc: David Brownell; [EMAIL PROTECTED]; Alan Stern; Linux Kernel
Mailing List; Raj, Ashok; Li,
>Shaohua; Kesh
Hello Gurus...
Is there a method to schedule user mode code from kernel agent?
basically think that when some work is to be scheduled in user mode, the app
registers with the kernel mode agent with a function/parm to run, then when
the callback is appropriate the kerenl agent triggers this callb
Hello.
I have a need to have some drivers pre-loaded before the scsi adapter driver
is loaded.
I followed the usage and i got some errors which iam attaching below in this
mail.
If someone can give me a way to get this to work that would be awesome!!!
please reply back to me..
1. Is the size
Missed the command line in earlier mail
ashokr
-Original Message-
From: Raj, Ashok [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 08, 2001 1:08 PM
To: Linux-Kernel (E-mail)
Subject: mkinitrd errors...
Hello.
I have a need to have some drivers pre-loaded before the scsi adapter
Hello asm gurus..
I need a simple (??) change to atomic_inc() functionality. so that i can
increment and return the
value of the variable.
current implementation in linux/include/asm/atomic.h does not do this job.
any help would be greatly appreciated.
ashokr
from atomic.h
also if there is
Hello
Is there a method to stack signals? i.e when multiple signals are delivered
to the process, instead of being 1 shot, that signals get delivered as many
times?
and from kernel mode, can we pass arguments in the signal handler? for eg:
if i have SIGUSR1 for each
signal delivered by the kern
Hi Boris
On Fri, Sep 04, 2015 at 01:50:29PM +0200, Borislav Petkov wrote:
> > Intel Secure Guard eXtentions will be disabled when these controls are
> > cleared
> > from a security perspective. This patch enables SGX to work across
> > suspend/resume.
>
> What does that mean? What does SGX have
On Thu, Jan 11, 2018 at 05:41:34PM -0800, Andy Lutomirski wrote:
> On Thu, Jan 11, 2018 at 5:32 PM, Ashok Raj wrote:
> > - Remove including microcode.h, and use native macros from asm/msr.h
> > - added license header for spec_ctrl.c
> >
> > Signed-off-by: Ashok Raj
[snip]
> > +static inline u64
On Thu, Jan 11, 2018 at 06:20:13PM -0800, Andy Lutomirski wrote:
> On Thu, Jan 11, 2018 at 5:52 PM, Raj, Ashok wrote:
> >>
> >> What's wrong with native_read_msr()?
> >
> > Yes, i think i should have added to msr.h. The names didn't read as a
> &g
On Thu, Jan 11, 2018 at 05:58:11PM -0800, Dave Hansen wrote:
> On 01/11/2018 05:32 PM, Ashok Raj wrote:
> > +static void save_guest_spec_ctrl(struct vcpu_vmx *vmx)
> > +{
> > + if (boot_cpu_has(X86_FEATURE_SPEC_CTRL)) {
> > + vmx->spec_ctrl = spec_ctrl_get();
> > + spec_ctrl_r
On Tue, Jan 30, 2018 at 06:36:20PM -0500, Paolo Bonzini wrote:
> On 30/01/2018 04:00, David Woodhouse wrote:
> > I believe Ashok sent you a change which made us do IBPB on *every*
> > vmexit; I don't think we need that. It's currently done in vcpu_load()
> > which means we'll definitely have done i
Hi Karim
On Wed, Jan 31, 2018 at 08:37:46PM +0100, KarimAllah Ahmed wrote:
> [ Based on a patch from Ashok Raj ]
>
> Add direct access to MSR_IA32_SPEC_CTRL for guests. This is needed for
> guests that will only mitigate Spectre V2 through IBRS+IBPB and will not
> be using a retpoline+IBPB based
Hi Karim
Thanks for cracking at it through all the iterations.
On Wed, Jan 31, 2018 at 08:37:44PM +0100, KarimAllah Ahmed wrote:
> From: Ashok Raj
>
> The Indirect Branch Predictor Barrier (IBPB) is an indirect branch
> control mechanism. It keeps earlier branches from influencing
> later ones.
On Tue, Jan 30, 2018 at 01:10:27AM +0100, KarimAllah Ahmed wrote:
> Future intel processors will use MSR_IA32_ARCH_CAPABILITIES MSR to indicate
> RDCL_NO (bit 0) and IBRS_ALL (bit 1). This is a read-only MSR. By default
> the contents will come directly from the hardware, but user-space can still
>
Thanks Tom
On Mon, 2018-03-05 at 16:12 -0600, Tom Lendacky wrote:
> Borislav Petkov (3):
> > x86/microcode: Get rid of struct apply_microcode_ctx
> > x86/microcode/intel: Look into the patch cache first
> > x86/microcode: Request microcode on the BSP
> >
> > arch/x86/kernel/cpu/microcode/c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi Boris
If you got a blank email, sorry about that. Its been a while since i used
mutt and my setup was goofed up probably. Or i might have read your
signature a bit too literally :-)
> > +
> > + if (mca_cfg.lmce_disabled)
> > + return false;
> > +
> > + rdmsrl(MSR_IA32_MCG_CAP, c
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
> > is outright dangerous.
>
> Even if we update that microcode during CP
On Mon, May 28, 2018 at 10:49:23PM +0200, Borislav Petkov wrote:
> On Fri, May 25, 2018 at 02:41:55PM -0700, Tony Luck wrote:
> > @@ -1287,12 +1292,17 @@ void do_machine_check(struct pt_regs *regs, long
> > error_code)
> > no_way_out = worst >= MCE_PANIC_SEVERITY;
> > } els
On Thu, Feb 28, 2019 at 01:15:49PM -0800, Jacob Pan wrote:
> On Thu, 28 Feb 2019 15:09:50 +0100
> Joerg Roedel wrote:
>
> > Hi Jacob,
> >
> > On Wed, Feb 27, 2019 at 01:41:29PM -0800, Jacob Pan wrote:
> > > On Tue, 26 Feb 2019 12:17:43 +0100
> > > Joerg Roedel wrote:
> >
> > > Just trying to
On Tue, Feb 02, 2021 at 12:40:55PM +0800, Lu Baolu wrote:
> From: Yian Chen
>
> Starting from Intel Platform VT-d v3.2, BIOS may provide new remapping
> structure SATC for SOC integrated devices, according to section 8.8 of
> Intel VT-d architecture specification v3.2. The SATC structure reports
On Tue, Feb 02, 2021 at 12:40:56PM +0800, Lu Baolu wrote:
> From: Yian Chen
>
> Software should parse every SATC table and all devices in the tables
> reported by the BIOS and keep the information in kernel list for further
> SATC policy deployment.
>
The last part seems bit vague? Are you tryin
On Mon, Jun 01, 2020 at 04:25:19PM -0500, Bjorn Helgaas wrote:
> On Thu, May 28, 2020 at 01:57:42PM -0700, Ashok Raj wrote:
> > All Intel platforms guarantee that all root complex implementations
> > must send transactions up to IOMMU for address translations. Hence for
> > RCiEP devices that are V
On Mon, Aug 03, 2020 at 08:12:18AM -0700, Andy Lutomirski wrote:
> On Mon, Aug 3, 2020 at 8:03 AM Dave Hansen wrote:
> >
> > On 7/31/20 4:34 PM, Andy Lutomirski wrote:
> > >> Thomas suggested to provide a reason for the #GP caused by executing
> > >> ENQCMD
> > >> without a valid PASID value prog
On Thu, Aug 20, 2020 at 11:21:24AM -0700, Evan Green wrote:
> > >
> > > I'm slightly unclear about whether interrupts are disabled at the core
> > > by this point or not. I followed native_cpu_disable() up to
> > > __cpu_disable(), up to take_cpu_down(). This is passed into a call to
> > > stop_mac
On Sat, Mar 20, 2021 at 03:55:46PM +0100, Borislav Petkov wrote:
[snip]
> > microcode : 0x30
> > microcode : 0xde
> > microcode : 0x30
> > microcode : 0xde
>
> Yeah, I'm looking at that check_online_cpus() thing and wondering why we
> even need that:
>
> 0. So you have CPUs 1 and 3 offline.
> 1.
On Wed, Mar 17, 2021 at 08:09:52PM +0100, Lukas Wunner wrote:
> On Wed, Mar 17, 2021 at 10:45:21AM -0700, Dan Williams wrote:
> > Ah, ok, we're missing a flush of the hotplug event handler after the
> > link is up to make sure the hotplug handler does not see the Link Up.
> > I'm not immediately se
On Thu, Nov 19, 2020 at 08:51:20AM +0100, Lukas Wunner wrote:
> Hi Ashok,
>
> my sincere apologies for the delay.
No worries..
>
> On Fri, Sep 25, 2020 at 04:01:38PM -0700, Ashok Raj wrote:
> > When Mechanical Retention Lock (MRL) is present, Linux doesn't process
> > those change events.
> >
On Thu, Nov 19, 2020 at 04:27:41PM -0600, Bjorn Helgaas wrote:
> Hi Ashok,
>
> When you update this patch, can you run "git log --oneline
> drivers/pci/hotplug/pciehp*" and make yours match? It is a severe
> character defect of mine, but seeing subject lines that are obviously
:-)
> different t
Hi Lukas
On Sun, Nov 22, 2020 at 10:08:52AM +0100, Lukas Wunner wrote:
> On Sat, Nov 21, 2020 at 05:42:03PM -0800, Ashok Raj wrote:
> > --- a/drivers/pci/hotplug/pciehp_ctrl.c
> > +++ b/drivers/pci/hotplug/pciehp_ctrl.c
> > void pciehp_handle_presence_or_link_change(struct controller *ctrl, u32
Hi Lukas and Bjorn
On Sun, Nov 22, 2020 at 10:08:52AM +0100, Lukas Wunner wrote:
> > @@ -275,6 +302,13 @@ void pciehp_handle_presence_or_link_change(struct
> > controller *ctrl, u32 events)
> > if (link_active)
> > ctrl_info(ctrl, "Slot(%s): Link Up\n",
> >
Hi Joerg
On Mon, Mar 08, 2021 at 09:58:26AM +0800, Lu Baolu wrote:
> Hi Joerg,
>
> On 3/4/21 8:26 PM, Joerg Roedel wrote:
> >On Thu, Feb 25, 2021 at 02:26:51PM +0800, Lu Baolu wrote:
> >>When the first level page table is used for IOVA translation, it only
> >>supports Read-Only and Read-Write pe
On Sat, Nov 21, 2020 at 12:10:50PM +0100, Lukas Wunner wrote:
>
> > > > + /*
> > > > +* If ATTN is present and MRL is triggered
> > > > +* ignore the Presence Change Event.
> > > > +*/
> > > > + if (ATTN_BUTTN(ctrl) && (events & PCI_EXP_SLTSTA_MRLSC))
> > > > +
On Thu, Jul 16, 2015 at 06:16:50PM -0700, Andy Lutomirski wrote:
> > From: Ashok Raj
> >
> > kexec could boot a kernel that could be legacy with no knowledge of
> > LMCE. Hence we should make sure we clear LMCE optin before kexec reboot.
> >
>
> What happens if an offline-but-not-unplugged CPU ge
Hi Boris
On Fri, Dec 04, 2015 at 03:34:04PM +0100, Borislav Petkov wrote:
> > @@ -1008,6 +1009,14 @@ void do_machine_check(struct pt_regs *regs, long
> > error_code)
> > + if (cpu_is_offline(cpu) && (m.mcgstatus & MCG_STATUS_RIPV))
> > + goto out;
>
> This CPU - it being offline and
On Fri, Dec 04, 2015 at 02:34:52PM -0800, Andy Lutomirski wrote:
> On Fri, Dec 4, 2015 at 9:53 AM, Luck, Tony wrote:
> > ist_enter() is black magic to me. Andy? Would you be worried about executing
> > ist_{enter,exit}() on a cpu that was once online, but is currently marked
> > offline
> > by Li
On Mon, Dec 07, 2015 at 11:34:27PM +0100, Borislav Petkov wrote:
>
> Box logs below.
Do you have the dmidecode strings to find which platform this is?
>
> BIOS is doing funny cores enumeration:
>
> node #0, CPUs 0-7
> node #1, CPUs 8-15
> node #2, CPUs 16-23
> node #3, CPUs 24-31
>
> and then
On Tue, Dec 08, 2015 at 12:25:24AM +0100, Borislav Petkov wrote:
>
> Did you miss my statement in my previous mail where I said that the MCE
> is being raised only on the cores of node 0?
>
That's right.. but i think if MCE is only given to node0, then the system
would panic eveytime with or wi
Hi Eduardo,
Thanks for the feedback. All the suggestions make sense..
On Mon, Dec 14, 2015 at 02:23:56PM -0200, Eduardo Habkost wrote:
> > +static void feature_control_init(X86CPU *cpu)
> > +{
> > + CPUX86State *cenv = &cpu->env;
> > +
> > + cenv->msr_ia32_feature_control = ((1<<20) | (1<<0))
On Mon, Dec 14, 2015 at 05:37:38PM +0100, Borislav Petkov wrote:
>
> ... and obviously LMCE is vendor-specific so it cannot be enabled on
> !Intel guests with a define like that. mce_init() in qemu should check
> vendor too.
>
> The same mistake was done with SER_P but that's much harder to chang
On Mon, Dec 14, 2015 at 11:37:16PM +0100, Borislav Petkov wrote:
> On Mon, Dec 14, 2015 at 02:11:46PM -0500, Raj, Ashok wrote:
> > This is mostly harmless.. since the MCG_CAP space is shared and has no
> > conflict between vendors. Also just the CAP being set has no effect.
>
&
Hi Boris
On Fri, Sep 11, 2015 at 10:46:36AM +0200, Borislav Petkov wrote:
>
> One more buffer for MCEs? Why?
>
> We did add the mce_gen_pool thing exactly for logging stuff in atomic
> context. From looking at the code, we probably could get rid of that
> "struct mce_log mcelog" thing too and
Hi Zduan
do you know which distribution it is? This isn't a kernel bug.
if you look at dmesg you should see how many CPUs were booted. But the sysfs
files are created and the usermode script is bringing every cpu online.
Tony mentioned this to me couple weeks ago when i was fixing another bug
in
On Fri, Feb 08, 2019 at 11:49:55PM -0500, Sinan Kaya wrote:
> On 2/8/2019 8:02 PM, sathyanarayanan kuppuswamy wrote:
> >>This means that you should probably have some kind of version check
> >>here.
> >
> >There is no version field in ATS v1.0 spec. Also, If I follow the history
> >log in PCI spec,
Hi Thomas,
On Fri, Sep 06, 2019 at 02:51:17PM +0200, Thomas Gleixner wrote:
> Raj,
>
> On Thu, 5 Sep 2019, Raj, Ashok wrote:
> > On Thu, Sep 05, 2019 at 11:22:31PM +0200, Thomas Gleixner wrote:
> > > That's all nice, but what it the general use case for t
On Fri, Sep 06, 2019 at 11:16:00PM +0200, Thomas Gleixner wrote:
>
> So if we want to do late microcode loading in a sane way then there are
> only a few options and none of them exist today:
>
> 1) Micro-code contains a description of CPUID bits which are going to be
> exposed after the loa
Hi Boris,
sorry i added the wrong message id in the commit log.
https://lore.kernel.org/r/20190824085300.gb16...@zn.tnic/
On Wed, Aug 28, 2019 at 10:33:22PM -0700, Ashok Raj wrote:
> During microcode development, its often required to test different versions
> of microcode. Intel microcode load
On Thu, Aug 29, 2019 at 08:09:42AM +0200, Borislav Petkov wrote:
> On Wed, Aug 28, 2019 at 10:33:22PM -0700, Ashok Raj wrote:
> > During microcode development, its often required to test different versions
> > of microcode. Intel microcode loader enforces loading only if the revision
> > is
> > gr
On Tue, Aug 27, 2019 at 02:25:01PM +0200, Borislav Petkov wrote:
> On Mon, Aug 26, 2019 at 01:23:39PM -0700, Raj, Ashok wrote:
> > > Cloud customers have expressed discontent as services disappear for a
> > > prolonged time. The restriction is that only one core goes through t
On Wed, Aug 28, 2019 at 09:13:31PM +0200, Borislav Petkov wrote:
> On Tue, Aug 27, 2019 at 05:56:30PM -0700, Raj, Ashok wrote:
> > > "Cloud customers have expressed discontent as services disappear for
> > > a prolonged time. The restriction is that only one core (or
Hi Boris
Minor nit: Small commit log fixup below.
On Sat, Aug 24, 2019 at 10:53:00AM +0200, Borislav Petkov wrote:
> From: Ashok Raj
> Date: Thu, 22 Aug 2019 23:43:47 +0300
>
> Microcode update was changed to be serialized due to restrictions after
> Spectre days. Updating serially on a large
On Mon, Aug 26, 2019 at 08:53:05AM -0400, Boris Ostrovsky wrote:
> On 8/24/19 4:53 AM, Borislav Petkov wrote:
> >
> > +wait_for_siblings:
> > + if (__wait_for_cpus(&late_cpus_out, NSEC_PER_SEC))
> > + panic("Timeout during microcode update!\n");
> > +
> > /*
> > -* Increase th
On Thu, Sep 05, 2019 at 12:12:29AM +0200, Boris Petkov wrote:
> On September 5, 2019 12:06:54 AM GMT+02:00, Boris Ostrovsky
> wrote:
> >Why do we need to taint kernel here? We are not making any changes.
>
> Because this is not a normal operation we want users to do. This is only for
> testing
Hi Boris
On Thu, Sep 05, 2019 at 09:20:29AM +0200, Borislav Petkov wrote:
> On Wed, Sep 04, 2019 at 05:21:32PM -0700, Raj, Ashok wrote:
> > But echo 2 > reload would allow reading a microcode file from
> > /lib/firmware/intel-ucode/ even if the revision hasn't changed
On Thu, Sep 05, 2019 at 09:49:50PM +0200, Borislav Petkov wrote:
> On Thu, Sep 05, 2019 at 12:40:44PM -0700, Raj, Ashok wrote:
> > The original description said to load a new microcode file, the content
> > could have changed, but revision in the header hasn't increased.
>
Hi Thomas,
On Thu, Sep 05, 2019 at 11:22:31PM +0200, Thomas Gleixner wrote:
> Raj,
>
> On Thu, 5 Sep 2019, Raj, Ashok wrote:
> > On Thu, Sep 05, 2019 at 09:20:29AM +0200, Borislav Petkov wrote:
> > > On Wed, Sep 04, 2019 at 05:21:32PM -0700, Raj, Ashok wrote:
> >
On Fri, Sep 13, 2019 at 07:50:50PM +, Jason Gunthorpe wrote:
> On Thu, Sep 12, 2019 at 06:32:01PM -0700, Megha Dey wrote:
>
> > This series is a basic patchset to get the ball rolling and receive some
> > inital comments. As per my discussion with Marc Zyngier and Thomas Gleixner
> > at the Li
On Mon, Sep 16, 2019 at 12:36:11PM +0200, Thomas Gleixner wrote:
> > On Fri, 6 Sep 2019, Raj, Ashok wrote:
> > > On Fri, Sep 06, 2019 at 11:16:00PM +0200, Thomas Gleixner wrote:
> > > > Now #1 is actually a sensible and feasible solution which can be pulled
> >
Hi Thomas,
On Tue, Sep 17, 2019 at 08:37:10AM +0200, Thomas Gleixner wrote:
> > microode updates should be of 3 types.
> >
> > - Only loadable from BIOS (Only via FIT tables)
> > - Suitable for early load (things that take cpuid bits for e.g.)
> > - Suitable for late-load. (Where no cpuid bits sh
On Thu, Oct 03, 2019 at 01:57:47PM -0500, Bjorn Helgaas wrote:
> On Thu, Oct 03, 2019 at 10:21:24AM -0700, Kuppuswamy Sathyanarayanan wrote:
> > Hi Bjorn,
> >
> > On 8/28/19 3:14 PM, sathyanarayanan.kuppusw...@linux.intel.com wrote:
> > > From: Kuppuswamy Sathyanarayanan
> > >
> > >
> > > As pe
Hi Thomas
Just started looking into it to get some idea about what could be
going on. I had some questions, that would be helpful to clarify.
On Tue, Mar 24, 2020 at 08:03:44PM +0100, Thomas Gleixner wrote:
> Evan Green writes:
> > On Mon, Mar 23, 2020 at 5:24 PM Thomas Gleixner wrote:
> >> And
On Tue, Oct 22, 2019 at 04:53:16PM -0700, Jacob Pan wrote:
> Make use of generic IOASID code to manage PASID allocation,
> free, and lookup. Replace Intel specific code.
>
> Signed-off-by: Jacob Pan
> ---
> drivers/iommu/intel-iommu.c | 12 ++--
> drivers/iommu/intel-pasid.c | 36 ---
On Thu, Feb 07, 2019 at 08:08:06PM +, David Woodhouse wrote:
> On Thu, 2019-02-07 at 10:44 -0800, sathyanarayanan.kuppusw...@linux.intel.com
> wrote:
> > From: Kuppuswamy Sathyanarayanan
> >
> >
> > Intel IOMMU Page Request Services (PRS) only works with devices which
> > supports/uses PASI
On Thu, Feb 07, 2019 at 09:15:24PM +, David Woodhouse wrote:
> On Thu, 2019-02-07 at 13:09 -0800, Raj, Ashok wrote:
> > You are right.. they are completely orthogonal. We just don't have
> > a way to handle the page-requests for request without PASID's.
> >
&
On Wed, Feb 13, 2019 at 12:26:33AM -0800, Tian, Kevin wrote:
> >
> > diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> > index 1457f931218e..af2e4a011787 100644
> > --- a/drivers/iommu/intel-iommu.c
> > +++ b/drivers/iommu/intel-iommu.c
> > @@ -1399,7 +1399,8 @@ static void
On Thu, Sep 20, 2018 at 03:56:41PM -0700, Eads, Gage wrote:
Thanks Gage.
> Hi Alex,
> >
> > Known devices with this issue: 8086:270c
> >
> > Signed-off-by: Alex Williamson
>
> Tested-by: Gage Eads
Reviewed-by: Ashok Raj
Thanks.. also can you remove the ret below, and send the output
of /proc/cpuinfo before and after?
On Thu, Apr 19, 2018 at 02:18:41PM +0200, Borislav Petkov wrote:
> } else {
> + pr_info("%s: CPU%d returning 0x%x\n", __func__, cpu, err);
> return ret;
^^
On Fri, Apr 20, 2018 at 12:34:28PM +0200, Borislav Petkov wrote:
> save_mc_for_early() was a no-op on !CONFIG_HOTPLUG_CPU but the
> generic_load_microcode() path saves the microcode patches it has found
> into our cache of patches which is used for late loading too. Regardless
> of whether we do CP
On Fri, Apr 20, 2018 at 12:37:08PM +0200, Borislav Petkov wrote:
> Vitezslav reported a case where the
>
> "Timeout during microcode update!"
>
> panic would hit. After a deeper look, it turned out that his .config had
> CONFIG_HOTPLUG_CPU disabled which practically made save_mc_for_early() a
>
On Wed, Apr 18, 2018 at 02:22:12PM +0200, Borislav Petkov wrote:
> On Wed, Apr 18, 2018 at 02:08:40PM +0200, Vitezslav Samel wrote:
> > I switched to firmware-in-kernel early loading and that works OK.
firmware-in-kernel means you compile your microcode image in linux?
Can you tell me which distr
On Thu, Apr 19, 2018 at 07:35:31AM +0200, Vitezslav Samel wrote:
> > - Can you remove your builtin microcode,
> > - rename the /lib/firmware/intel-ucode so we don't find it during late
> > loading.
> > - let the system boot completely
> > - then rename the intel-ucode back for this test.
> > - w
Hi Boris
thanks for forwarding.
> > CPUID Vendor Intel Family 6 Model 142
This is Kabylake Mobile
> > Hardware event. This is not a software error.
> > MCE 1
> > CPU 0 BANK 7
> > MISC 7880018086 ADDR fef1ce40
> > TIME 1483543069 Wed Jan 4 16:17:49 2017
> > MCG status:
> > MCi status:
> > Error
Hi Boris
On Thu, Jan 05, 2017 at 09:31:47PM +0100, Borislav Petkov wrote:
> On Thu, Jan 05, 2017 at 09:10:34PM +0100, Alexander Alemayhu wrote:
> > Not sure if it is related, but I am also seeing those messages on my
> > MacBookPro11,3:
>
> Yours look to me like thermal throttling MCEs. And TBH
Hi Boris
On Thu, Jan 05, 2017 at 09:31:47PM +0100, Borislav Petkov wrote:
> On Thu, Jan 05, 2017 at 09:10:34PM +0100, Alexander Alemayhu wrote:
> > Not sure if it is related, but I am also seeing those messages on my
> > MacBookPro11,3:
>
> Yours look to me like thermal throttling MCEs. And TBH w
On Fri, Jan 06, 2017 at 12:56:11AM +0100, Borislav Petkov wrote:
> Oh, and it's not like the user can do anything - there's a thermald
> which is supposed to deal with all that. Which is not really
> trouble-free too, TBH. What happens if that thing dies? Fried CPU?
>
> So I say we should rip out
Hi Boris
On Fri, Jan 06, 2017 at 12:16:17PM +0100, Borislav Petkov wrote:
> On Thu, Jan 05, 2017 at 05:26:17PM -0800, Raj, Ashok wrote:
> > Agree, since we have both a log and another agent to deal with it, it makes
> > no good reason to continue... Will pass this along, and have
Hi Boris
This looks good to me!
On Fri, Jan 06, 2017 at 05:54:23PM +0100, Borislav Petkov wrote:
> On Fri, Jan 06, 2017 at 07:58:31AM -0800, Raj, Ashok wrote:
> > Looks like we don't need a return value from therm_throt_process(),
> > we can fix that as void as well.
>
Hi Bjorn
Sorry to bug you, didn't hear from you after i added the lock for consistency
to address the feedback.
Let me know if there is anymore changes you like to see.
Cheers,
Ashok
On Fri, Dec 09, 2016 at 01:06:04PM -0800, Ashok Raj wrote:
> Changes from v1:
> Address comments from Bjor
Hi Paul
On Mon, Jan 09, 2017 at 12:53:33PM +0100, Paul Menzel wrote:
>
>
> On 01/05/17 02:12, Raj, Ashok wrote:
>
> >>>CPUID Vendor Intel Family 6 Model 142
> >This is Kabylake Mobile
> >
> >>>Hardware event. This is not a software error.
> &
Hi Bjorn
On Thu, Dec 22, 2016 at 02:28:03PM -0600, Bjorn Helgaas wrote:
> On Thu, Dec 22, 2016 at 05:27:14PM +0100, Joerg Roedel wrote:
> > Hi Bjorn,
> >
> > On Mon, Dec 19, 2016 at 03:20:44PM -0600, Bjorn Helgaas wrote:
> > > I have some questions about dmar_init_reserved_ranges(). On systems
>
3:32:38PM -0800, Raj, Ashok wrote:
> Let me check and keep you posted if we have such platforms to make sure if
> we need this considerations for _TRA.
Cheers,
Ashok
Hi Bjorn,
On Tue, Dec 27, 2016 at 05:44:17PM -0600, Bjorn Helgaas wrote:
>
> dmar_init_reserved_ranges()
> {
> ...
> for_each_pci_dev(pdev) {
> for (i = 0; i < PCI_NUM_RESOURCES; i++) {
> r = &pdev->resource[i];
> reserve_iova(r)
>
> But I assume it's possible t
Hi David/Joerg
Haven't heard about it from David yet, but can we queue this for 4.10?
If you have any questions/concerns please let us know.
Cheers,
Ashok
On Wed, Dec 14, 2016 at 02:36:40PM +0200, Mika Kuoppala wrote:
> >
> > cc: Mika Kuoppala
> > cc: Ashok Raj
> > Signed-off-by: Jacob Pan
Hi Bjorn
Thanks. I have resent the last patch again with consistent lock usage as you
had requested.
I did attempt to make things a bit more easier to understand in one my
earlier experiments, but that resulted in very substantial changes.
Certainly something we should look in future to make the
On Mon, Mar 06, 2017 at 06:24:17PM -0600, Bjorn Helgaas wrote:
> On Fri, Feb 03, 2017 at 10:51:04AM -0600, Bjorn Helgaas wrote:
>
> Hi Ashok,
>
> Just a ping to make sure we're not deadlocked. I'm waiting for you,
> so I hope you're not also waiting for me :) I'm not trying to rush you;
> I jus
Hi Yinghai
On Thu, Feb 23, 2017 at 10:54:35PM -0800, Yinghai Lu wrote:
> +++ linux-2.6/drivers/pci/hotplug/pciehp_ctrl.c
> @@ -71,9 +71,6 @@ static void set_slot_off(struct controll
>*/
> msleep(1000);
> }
> -
> - pciehp_green_led_off(pslot);
> - pciehp_
Thanks Bjorn,
With the fixes below, managed add remove via sysfs seems to work on my
SKX system.
I'm not familiar with runtime PM aspects, just started looking into it
after this one. There seems some interactions with ASPM and how we handle
devices that support ARI for e.g.
For hotplug, we h
ost or all of those values to stay same between poweron
and after the next sysfs managed poweron. Would be worth taking a look and see
if we have any escapes.
Cheers,
Ashok
On Thu, Feb 09, 2017 at 10:23:28AM -0800, Raj, Ashok wrote:
> Thanks Bjorn,
>
> With the fixes below, managed add r
Hi Keith
did you have a chance to look at this?
Cheers,
Ashok
On Fri, Dec 09, 2016 at 01:06:04PM -0800, Ashok Raj wrote:
> Changes from v1:
> Address comments from Bjorn:
> Added p_slot->lock mutex around changes to p_slot->state
> Updated commit message to call
Hi Bjorn
On Thu, Feb 02, 2017 at 08:59:01PM -0600, Bjorn Helgaas wrote:
> Hi Ashok,
>
> Sorry it took me so long to review this. I never felt like I really
> understood it, and it took me a long time to try to figure out a more
> useful response.
No worries. Agree its a litte tricky, and took m
On Fri, Sep 25, 2015 at 10:29:01AM +0200, Borislav Petkov wrote:
> > >
> >
> > The last patch of that series had 2 changes.
> >
> > 1. Allow offline cpu's to participate in the rendezvous. Since in the odd
> > chance the offline cpus have any errors collected we can still report them.
> > (we ch
Hi Boris
On Thu, Sep 24, 2015 at 09:22:24PM +0200, Borislav Petkov wrote:
>
> Ah, we return. But we shouldn't return - we should overwrite. I believe
> we've talked about the policy of overwriting old errors with new ones.
>
Another reason i had a separate buffer in my earlier patch was to avoi
Hi Boris
I should have expanded on it..
On Thu, Sep 24, 2015 at 11:07:33PM +0200, Borislav Petkov wrote:
>
> How are you ever going to call into those from an offlined CPU?!
>
> And that's easy:
>
> if (!cpu_online(cpu))
> return;
>
The last patch of that series had 2 ch
Hi Greg,
On Thu, Jun 18, 2020 at 06:02:12PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jun 18, 2020 at 08:03:49AM -0700, Rajat Jain wrote:
> > Hello,
> >
> > On Thu, Jun 18, 2020 at 2:14 AM Andy Shevchenko
> > wrote:
> > >
> > > On Thu, Jun 18, 2020 at 11:36 AM Greg Kroah-Hartman
> > > wrote:
Hi Jason
On Wed, Sep 30, 2020 at 03:51:03PM -0300, Jason Gunthorpe wrote:
> On Wed, Sep 30, 2020 at 08:47:00PM +0200, Thomas Gleixner wrote:
>
> > > + pci_read_config_dword(pdev, SIOVCAP(dvsec), &val32);
> > > + if ((val32 & 0x1) && idxd->hw.gen_cap.max_ims_mult) {
> > > + idxd->ims_size
Hi Thomas,
On Wed, Sep 30, 2020 at 11:57:22PM +0200, Thomas Gleixner wrote:
> On Wed, Sep 30 2020 at 14:49, Ashok Raj wrote:
> >> It is the weirdest thing, IMHO. Intel defined a dvsec cap in their
> >> SIOV cookbook, but as far as I can see it serves no purpose at
> >> all.
> >>
> >> Last time I
Hi Ethan
On Sat, Oct 03, 2020 at 03:55:09AM -0400, Ethan Zhao wrote:
> Hi,folks,
>
> This simple patch set fixed some serious security issues found when DPC
> error injection and NVMe SSD hotplug brute force test were doing -- race
> condition between DPC handler and pciehp, AER interrupt handler
Hi Thomas,
On Wed, Aug 26, 2020 at 02:40:45AM +0200, Thomas Gleixner wrote:
> Ashok,
>
> On Thu, Aug 20 2020 at 17:42, Ashok Raj wrote:
> > When offlining CPUs, fixup_irqs() migrates all interrupts away from the
> > outgoing CPU to an online CPU. It's always possible the device sent an
> > interr
Hi Jason
On Thu, Oct 08, 2020 at 08:32:10PM -0300, Jason Gunthorpe wrote:
> On Fri, Oct 09, 2020 at 01:17:38AM +0200, Thomas Gleixner wrote:
> > Dave,
> >
> > On Thu, Oct 08 2020 at 09:51, Dave Jiang wrote:
> > > On 10/8/2020 12:39 AM, Thomas Gleixner wrote:
> > >> On Wed, Oct 07 2020 at 14:54, D
On Fri, Oct 09, 2020 at 03:52:51AM +0100, Hedi Berriche wrote:
> Commit 6d2c89441571 ("PCI/ERR: Update error status after reset_link()")
> changed pcie_do_recovery() so that status is updated with the return
> value from reset_link(); this was to fix the problem where we would
> wrongly report reco
1 - 100 of 202 matches
Mail list logo
