On 5/5/2015 3:28 PM, Luck, Tony wrote:
Should you check whether the address is valid before blindly reading the
register?
m.bank = bank;
if (m.status & MCI_STATUS_ADDRV)
rdmsrl(MSR_IA32_MCx_ADDR(bank), m.addr);
mce_log(&m);
Yes, mis
Should you check whether the address is valid before blindly reading the
register?
> m.bank = bank;
if (m.status & MCI_STATUS_ADDRV)
rdmsrl(MSR_IA32_MCx_ADDR(bank), m.addr);
> mce_log(&m);
-Tony
On 5/4/2015 1:46 PM, Borislav Petkov wrote:
So you can use mce_read_aux(), yeah, you can move it to mce-internal.h
Re-using mce_read_aux() was not as trivial as I initially thought.
The MISC address value we read in amd_threshold_interrupt() could also
be the value
in MSR0xc408 or MSR0xc00
On Mon, May 04, 2015 at 02:06:43PM -0500, Aravind Gopalakrishnan wrote:
> Is it ok to grow another patch in a V2 for this instead of fixing
> it in this patch since it's a real bug? That should be helpful when
> someone wants to look up git logs of why this was done..
Yes, a prepatch please.
> Ye
On 5/4/2015 1:46 PM, Borislav Petkov wrote:
For deferred errors, the workaround is a little different as it
applies to only the given family/model right now. If the workaround
needs to be applied for future processors, we can extend the family
check for those right?
Or, you can do the check for
On Mon, May 04, 2015 at 12:08:16PM -0500, Aravind Gopalakrishnan wrote:
> Not sure if lvt_off_valid() can be reused for deferred error interrupt
> setup. It expects some some of info to be in struct threshold_block
> which is fine for threshold errors and the shifts for offset are
> different too.
On 5/4/2015 10:46 AM, Borislav Petkov wrote:
On Mon, May 04, 2015 at 10:29:50AM -0500, Aravind Gopalakrishnan wrote:
What's the family check for? for BIOSes which don't set the LVT offset
to 2, as they should?
If so, we probably should say
pr_err(FW_BUG "Your BIOS is not setting up LVT
On Mon, May 04, 2015 at 10:29:50AM -0500, Aravind Gopalakrishnan wrote:
> >What's the family check for? for BIOSes which don't set the LVT offset
> >to 2, as they should?
> >
> >If so, we probably should say
> >
> > pr_err(FW_BUG "Your BIOS is not setting up LVT offset 0x2 for deferred
> > err
On 5/3/2015 4:22 AM, Borislav Petkov wrote:
On Thu, Apr 30, 2015 at 09:49:23AM -0500, Aravind Gopalakrishnan wrote:
Changes introduced in the patch-
- Assign vector number 0xf4 for Deferred errors
- Declare deferred_interrupt, allocate gate and bind it
to DEFERRED_APIC_VECTOR.
- De
On Thu, Apr 30, 2015 at 09:49:23AM -0500, Aravind Gopalakrishnan wrote:
> Changes introduced in the patch-
> - Assign vector number 0xf4 for Deferred errors
> - Declare deferred_interrupt, allocate gate and bind it
> to DEFERRED_APIC_VECTOR.
> - Declare smp_deferred_interrupt to be used a
On 5/1/2015 4:36 AM, Borislav Petkov wrote:
On Thu, Apr 30, 2015 at 11:16:30PM -0500, Aravind Gopalakrishnan wrote:
I used the term as it is an interrupt due to the deferred error.
Would 'deferred_err_interrupt' be more apt? Maybe 'irq_deferred_error_count'
for the counter?
Yeah, I think it is
On Thu, Apr 30, 2015 at 11:16:30PM -0500, Aravind Gopalakrishnan wrote:
> I used the term as it is an interrupt due to the deferred error.
> Would 'deferred_err_interrupt' be more apt? Maybe 'irq_deferred_error_count'
> for the counter?
Yeah, I think it is important to stick to the "deferred erro
On 4/30/15 3:41 PM, Andy Lutomirski wrote:
On Thu, Apr 30, 2015 at 7:49 AM, Aravind Gopalakrishnan
wrote:
Changes introduced in the patch-
- Assign vector number 0xf4 for Deferred errors
- Declare deferred_interrupt, allocate gate and bind it
to DEFERRED_APIC_VECTOR.
- Declare sm
On Thu, Apr 30, 2015 at 7:49 AM, Aravind Gopalakrishnan
wrote:
> Changes introduced in the patch-
> - Assign vector number 0xf4 for Deferred errors
> - Declare deferred_interrupt, allocate gate and bind it
> to DEFERRED_APIC_VECTOR.
> - Declare smp_deferred_interrupt to be used as the
>
14 matches
Mail list logo
