From: David Laight
Date: Tue, 7 Feb 2017 09:55:47 +
> From: David Miller
>> Sent: 06 February 2017 19:15
>> From: David Laight
>> Date: Mon, 6 Feb 2017 17:23:54 +
>>
>> > Although the 'store buffer' on the sparc cpus I used to use would
>> > let reads overtake writes. So you did have to
From: David Miller
> Sent: 06 February 2017 19:15
> From: David Laight
> Date: Mon, 6 Feb 2017 17:23:54 +
>
> > Although the 'store buffer' on the sparc cpus I used to use would
> > let reads overtake writes. So you did have to read back the address
> > of the last write - not sure about mode
From: David Laight
Date: Mon, 6 Feb 2017 17:23:54 +
> Although the 'store buffer' on the sparc cpus I used to use would
> let reads overtake writes. So you did have to read back the address
> of the last write - not sure about modern sparc cpus.
Never would any sparc cpu do so when any of th
From: Alexander
> Sent: 06 February 2017 16:27
> To: David Laight
> On Mon, Feb 6, 2017 at 7:33 AM, David Laight wrote:
> > netdev probably isn't the right list for this, but I suspect people
> > reading it understand what happens.
> >
> > I'm fairly sure that an msix interrupt can get raised aft
On Mon, Feb 6, 2017 at 7:33 AM, David Laight wrote:
> netdev probably isn't the right list for this, but I suspect people
> reading it understand what happens.
>
> I'm fairly sure that an msix interrupt can get raised after
> the kernel thinks it has masked it.
>
> When an msix interrupt is disabl
netdev probably isn't the right list for this, but I suspect people
reading it understand what happens.
I'm fairly sure that an msix interrupt can get raised after
the kernel thinks it has masked it.
When an msix interrupt is disabled I think msi_set_mask_bit()
(in drivers/pci/msi.c) is called to
