> From: Nikolay Borisov
> [...]
> >> Actually now shouldn't the CONFIG_PARAVIRT_SPINLOCKS check be
> retained?
> >> Otherwise we'll have the virtspinlock enabled even if we are a guest
> >> but CONFIG_PARAVIRT_SPINLOCKS is disabled, no ?
> >>
> >
> > It seems to be the expected behavior? If CONFIG
> [...]
>
> I think 507b460f8144 appeared in v5.11, so not something we broke in v5.12.
> Applied to pci/error for v5.13, thanks!
Thanks Bjorn!
> If I understand correctly, we previously only got this right in one
> case:
>
>0 == PCI_SLOT(00.0)# correct
>1 == PCI_SLOT(00.1)# inc
Hi Bjorn,
Do you have any comments on this patch? If need any changes, please let me
know.
Thanks!
-Qiuxu
> -Original Message-
> From: Zhuo, Qiuxu
> Sent: Monday, February 22, 2021 9:17 AM
> To: Bjorn Helgaas
> Cc: Zhuo, Qiuxu ; Lorenzo Pieralisi
> ; Krzysztof W
> ...
> > [ Krzysztof: Update commit message. ]
> [...]
>
> Thank you! I appreciate that. However, we probably should drop this from the
> commit message. Perhaps either Bjorn or Lorenzo could do it when applying
> changes.
OK, will send out the v3 that drops "[ Krzysztof: Update commit messag
> ...
>
> I took your suggestion and came up with the following:
>
> Function rcec_assoc_rciep() incorrectly used "rciep->devfn" (a single
> byte encoding the device and function number) as the device number to
> check whether the corresponding bit was set in the RCiEPBitmap of the
> RCEC
>...
>
> We could probably add the following:
>
> Fixes: 507b460f8144 ("PCI/ERR: Add pcie_link_rcec() to associate RCiEPs")
>
OK. Will add this to the v2.
Thanks!
-Qiuxu
Hi Krzysztof,
Sorry, just back from Chinese New Year holiday.
> From: Krzysztof Wilczyński
> ...
> ...
> Would this only affect error injection or would this be also a generic problem
> with the driver itself causing issues regardless of whether it was an error
> injection or not for this partic
> From: Jonathan Cameron
> Sent: Monday, July 27, 2020 7:17 PM
> To: Kelley, Sean V
> Cc: bhelg...@google.com; r...@rjwysocki.net; ashok@kernel.org; Luck,
> Tony ;
> sathyanarayanan.kuppusw...@linux.intel.com; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Z
>
> BIOS has marked the 32K MCHBAR window as reserved, so when dnv_rd_reg()
> tries to ioremap() a 64KB region you get warnings like:
>
> resource sanity check: requesting [mem 0xfed1-0xfed1], which spans
> more than reserved [mem 0xfed1-0xfed17fff] caller
> dnv_rd_reg+0xc8/0x240 [pnd
> From: Borislav Petkov [mailto:b...@alien8.de]
>> ...
>> Dropping my SOB or adding a text "[Qiuxu: Get the macros in the Ice Lake
>> group sorted by
> > model number.]" at the end of the commit message - which one is
> > better/clear for you?
>
> I'll add that note when applying.
>
> Thx.
Tha
> From: Borislav Petkov [mailto:b...@alien8.de]
> ...
> > From: Kan Liang
> >
> > Add the CPUID model number of Icelake (ICL) desktop and server
> > processors to the Intel family list.
> >
> > Signed-off-by: Kan Liang
> > Signed-off-by: Qiuxu Zhuo
>
> You're sending this patch but it has Qiuxu
Hi Justin,
> [ 3401.987556] EDAC MC15: Giving out device to module skx_edac controller
> Skylake Socket#1 IMC#1
Just curious, has the system(two memory controllers per socket) got more
than 8 sockets?
Normally, the number "1" in the above string "Skylake Socekt#1 IMC#1"
should be 7 (tha
Hi Silva,
The actual intention of the code is NOT to fall through, though current
code can work correctly.
Thanks for this finding. If you don't mind, I'll submit a fix patch for it
with the tag 'Reported-by:' by you.
Thanks!
- Qiuxu
> From: linux-edac-ow...@vger.kernel.org [mailto:lin
> From: Borislav Petkov [mailto:b...@alien8.de]
>
> Xiaolong,
>
> can you please run Qiuxu's patch to verify it fixes your issue?
Hi Boris,
I manually verified the fix patch on the Broadwell-DE server on which the
bug was found by Xiaolong:
the sb_edac can be loaded successfully, and i
Hi Xiaolong,
Fixed this issue by 'EDAC, sb_edac: Avoid creating 'SOCK' EDAC memory
controller' (you were also CCed by 'Reported-by').
Thanks for this test case :-)
BR
qiuxu
-----Original Message-
From: Zhuo, Qiuxu
Sent: Monday, June 5, 2017 9:08 PM
Hi Xiaolong,
Thanks! I'll look at it, and feedback ASAP.
BR
qiuxu
-Original Message-
From: lkp-robot-requ...@eclists.intel.com
[mailto:lkp-robot-requ...@eclists.intel.com] On Behalf Of Ye, Xiaolong
Sent: Monday, June 5, 2017 2:23 PM
To: Zhuo, Qiuxu
Cc: Borislav Petkov ; linux
lav Petkov; Ingo Molnar; Brian Gerst;
linux-kernel@vger.kernel.org; Zhuo, Qiuxu; Thomas Gleixner; Denys Vlasenko;
Wang, Frank; linux-tip-comm...@vger.kernel.org
Subject: Re: [tip:x86/urgent] x86/entry: Restore traditional SYSENTER calling
convention
On Mon, Jan 4, 2016 at 10:48 AM, H. Pet
17 matches
Mail list logo
