lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <33998356.WVR1zQ2T7Q@debian64>
Date:	Sun, 24 Apr 2016 17:21:26 +0200
From:	Christian Lamparter <chunkeey@...glemail.com>
To:	Julian Margetson <runaway@...dw.ms>
Cc:	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Tejun Heo <tj@...nel.org>, linux-ide@...r.kernel.org,
	Rob Herring <robh+dt@...nel.org>,
	linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	Måns Rullgård <mans@...sr.com>
Subject: Re: [PATCH v1 00/23] ata: sata_dwc_460ex: make it working again

On Sunday, April 24, 2016 09:05:43 AM Julian Margetson wrote:
> On 4/23/2016 3:41 PM, Christian Lamparter wrote:
> > There's a known errata for the 460EX, with the CPU lockup upon
> > high AHB traffic:
> > <http://lists.denx.de/pipermail/u-boot/2008-June/036078.html>
> >
> > "This patch implements a fix provided by AMCC so that the lockup upon
> > simultanious traffic on AHB USB OTG, USB 2.0 and SATA doesn't occur
> > anymore:..."
> >
> > This should be fixed by u-boot. However, there's no telling if
> > there's more to this workaround in the dma engine. You could try
> > to do the testing without anything connected to the USB ports
> > and disable/remove all usb hcds modules. As for fixing this:
> > I did a quick search but couldn't find any public information.
> > There's always support@....com (contact them!), or maybe someone
> > from the Amiga community knows more?
> >
> >
> 
> Tested with kernel with all USB disabled. No sata error messages 
> during the partition copy but the copying is quite slow.
Ok. The CONFIG_DMADEVICES_DEBUG and CONFIG_DMADEVICES_VDEBUG option
have quite a large overhead, if this fixed the issue for now you
could try to disable them and look if the issue comes back or not.
(also, you can drop the mdelay patch if it's still applied). If
the issue doesn't come back, you could add your "Tested-by" tag
too.

Another thing, the sata dwc driver doesn't yet support NCQ. Do you
know if the driver for the Amiga OS does?

> so this does appear to be the problem.
So, how to fix this? I know, there's an AHB DMA Arbiter. But I can't
get any documentation for it from AMCC/APM. Maybe denx.de or someone
from the Amiga community knows how to deal with it. In theory, we 
could try if limiting the burst length, pending dma request count or
add code to retry failed dma transfers and reinit the usb-cores would
help.

Regards,
Christian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ