Dave,
This patchset will only write root tables in old kernel, if it is
corrupted, faults will also happen in old kernel, and hardware would
mark it. So things will not go worse..
Thanks
Zhenhua
On 05/06/2015 09:51 AM, Dave Young wrote:
On 05/05/15 at 05:31pm, Joerg Roedel wrote:
On Tue, Ma
On 05/05/15 at 05:31pm, Joerg Roedel wrote:
> On Tue, May 05, 2015 at 02:14:23PM +0800, Dave Young wrote:
> > The failure is nothing different, but as I said in another reply the
> > difference is we could use corrupted data to possiblly cause more failure.
>
> I still fail to see how things can g
On 05/05/15 at 05:23pm, Joerg Roedel wrote:
> On Tue, May 05, 2015 at 02:09:31PM +0800, Dave Young wrote:
> > I agree that we can do nothing with the old corrupted data, but I worry
> > about the future corruption after using the old corrupted data. I wonder
> > if we can mark all the oldmem as rea
On Sun, May 3, 2015 at 2:18 AM, Oded Gabbay wrote:
>
>
> On 05/03/2015 01:14 AM, Joerg Roedel wrote:
>>
>> Hi Oded,
>>
>> On Sat, May 02, 2015 at 07:59:39PM +0300, Oded Gabbay wrote:
>>>
>>> However, Joerg is not answering my emails for some reason
>>> (vacation/sick?)
>>
>>
>> Sorry, I was travel
Hi Joerg,
On 05/05/15 15:41, Joerg Roedel wrote:
Do you see a real deadlock or only the lockdep warning? In the code it
looks like virtfn_add() takes the sriov->lock of the physical device
while pci_enable_ats() (when called from there) takes the sriov->lock of
the virtual function. In this case
Joerg,
I see a deadlock in pci_enable_ats() called from attach_device() in
drivers/iommu/amd_iommu.c. It appears to be a recursive attempt to take
pci_sriov::lock.
The problem occurs when a network driver (sfc.ko, here an internal
testing version) enables SR-IOV on its device by calling
pci_enab
Hi Joerg,
> -Original Message-
> From: jroe...@suse.de [mailto:jroe...@suse.de]
> Sent: Tuesday, May 05, 2015 7:13 PM
> To: Sethi Varun-B16395
> Cc: j...@8bytes.org; iommu@lists.linux-foundation.org; Bucur Madalin-
> Cristian-B32716
> Subject: Re: [iommu:ppc/pamu 1/1] drivers/iommu/fsl_pam
> On 05 May 2015 at 18:03 Joerg Roedel wrote:
>
>
> On Wed, Apr 29, 2015 at 09:05:17PM +0200, Fabian Frederick wrote:
> > msm_iommu_lock is only used in msm_iommu.c
> >
> > Signed-off-by: Fabian Frederick
> > ---
> > drivers/iommu/msm_iommu.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 delet
On Tue, May 05, 2015 at 05:18:02PM +0100, Joerg Roedel wrote:
> On Tue, Apr 28, 2015 at 03:41:21PM +0800, Yong Wu wrote:
> > This patch is for ARM Short Descriptor Format.It has 2-levels
> > pagetable and the allocator supports 4K/64K/1M/16M.
> >
> > Signed-off-by: Yong Wu
> > ---
> > drivers/io
On Tue, Apr 28, 2015 at 03:41:21PM +0800, Yong Wu wrote:
> This patch is for ARM Short Descriptor Format.It has 2-levels
> pagetable and the allocator supports 4K/64K/1M/16M.
>
> Signed-off-by: Yong Wu
> ---
> drivers/iommu/Kconfig| 7 +
> drivers/iommu/Makefile |
On Wed, Apr 29, 2015 at 09:05:17PM +0200, Fabian Frederick wrote:
> msm_iommu_lock is only used in msm_iommu.c
>
> Signed-off-by: Fabian Frederick
> ---
> drivers/iommu/msm_iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
This driver is marked BROKEN, I think its more important t
On Thu, Apr 16, 2015 at 11:32:47PM -0500, Robert Callicotte wrote:
> Fixed checkpatch warnings for missing blank line after declaration of
> struct.
>
> Signed-off-by: Robert Callicotte
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundat
On Tue, May 05, 2015 at 03:47:48PM +0100, Gregor Dick wrote:
> Hi Joerg,
>
> On 05/05/15 15:41, Joerg Roedel wrote:
> >Do you see a real deadlock or only the lockdep warning? In the code it
> >looks like virtfn_add() takes the sriov->lock of the physical device
> >while pci_enable_ats() (when call
On Tue, May 05, 2015 at 02:14:23PM +0800, Dave Young wrote:
> The failure is nothing different, but as I said in another reply the
> difference is we could use corrupted data to possiblly cause more failure.
I still fail to see how things can get more worse than they already are
by reusing the old
On Tue, May 05, 2015 at 02:09:31PM +0800, Dave Young wrote:
> I agree that we can do nothing with the old corrupted data, but I worry
> about the future corruption after using the old corrupted data. I wonder
> if we can mark all the oldmem as readonly so that we can lower the risk.
> Is it resonab
Hi,
On Tue, May 05, 2015 at 03:30:41PM +0800, AceLan Kao wrote:
> There is no easy way to check whether this BIOS bug is present, so we
> have to list them explicitly.
> I think we can do just like what platform drivers(ex. asus_quirks[1])
> do, check the system vendor and product name to identify
Hi Marek,
On Mon, May 04, 2015 at 10:15:55AM +0200, Marek Szyprowski wrote:
> iommu: exynos: don't read version register on every tlb operation
Please use 'iommu/exynos:' as prefix for the iommu patches and start
the remaining subject with a capital letter, like this:
iommu/exynos: Don
On Mon, May 04, 2015 at 10:16:10AM +0200, Marek Szyprowski wrote:
> struct exynos_iommu_domain {
> - struct list_head clients; /* list of sysmmu_drvdata.node */
> + struct list_head clients; /* list of sysmmu_drvdata.domain_node */
> sysmmu_pte_t *pgtable; /* lv1 page table, 16KB */
On Mon, May 04, 2015 at 10:16:05AM +0200, Marek Szyprowski wrote:
> The driver doesn't need to do anything important in device add/remove
> callbacks, because initialization will be done from device-tree specific
> callbacks added later. IOMMU groups created by current code were never
> used.
Hmm,
On Mon, May 04, 2015 at 10:16:04AM +0200, Marek Szyprowski wrote:
> After refactoring functions to use pointer to struct sysmmu_drvdata
> directly, some functions became useless and thus never used, so remove
> them completely.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/iommu/exynos-iom
On Mon, May 04, 2015 at 10:16:03AM +0200, Marek Szyprowski wrote:
> @@ -719,14 +712,12 @@ static void exynos_iommu_domain_free(struct
> iommu_domain *domain)
>
> spin_lock_irqsave(&priv->lock, flags);
>
> - list_for_each_entry(owner, &priv->clients, client) {
> - while (!
Hi Gregor,
On Tue, May 05, 2015 at 10:24:13AM +0100, Gregor Dick wrote:
> The problem occurs when a network driver (sfc.ko, here an internal
> testing version) enables SR-IOV on its device by calling
> pci_enable_sriov(). There are two PFs for this physical device. This
> call in turn results in a
On Tue, May 05, 2015 at 01:22:24PM +, Varun Sethi wrote:
> > Which means the driver was only buildable on e500mc and now you are
> > telling me that this is broken. What am I missing?
> >
> PPC_E500MC dependency is fine, but with the COMPIL_TEST flag ("or"
> condition) the PAMU driver code w
Hi Joerg,
> -Original Message-
> From: jroe...@suse.de [mailto:jroe...@suse.de]
> Sent: Tuesday, May 05, 2015 6:47 PM
> To: Sethi Varun-B16395
> Cc: j...@8bytes.org; iommu@lists.linux-foundation.org; Bucur Madalin-
> Cristian-B32716
> Subject: Re: [iommu:ppc/pamu 1/1] drivers/iommu/fsl_pam
On Fri, Apr 10, 2015 at 11:58:24PM +0200, Arnd Bergmann wrote:
> The rockchip iommu driver references its of_device_id table
> from the init function, which fails to build when the table
> is undefined:
>
> iommu/rockchip-iommu.c: In function 'rk_iommu_init':
> iommu/rockchip-iommu.c:1029:35: erro
Hi Varun,
On Wed, Apr 08, 2015 at 01:24:16PM +, Varun Sethi wrote:
> Following issue was observed while building (compile test) for a
> non-powerpc (e500mc) based platform. The pamu driver includes a file
> which is available in the architecture include directory. Should we
> move the header f
Hi Joerg,
There is no easy way to check whether this BIOS bug is present, so we
have to list them explicitly.
I think we can do just like what platform drivers(ex. asus_quirks[1])
do, check the system vendor and product name to identify those
machines, and give them a working ioapic value.
1. dri
27 matches
Mail list logo
