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
| ||
|
Date: Sat, 24 Jun 2017 12:50:20 +1000 (AEST) From: Finn Thain <fthain@...egraphics.com.au> To: Ondrej Zary <linux@...nbow-software.org> cc: "James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>, "Martin K. Petersen" <martin.petersen@...cle.com>, linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org, Michael Schmitz <schmitzmic@...il.com> Subject: Re: [PATCH 0/4] g_NCR5380: PDMA fixes and cleanup On Fri, 23 Jun 2017, Ondrej Zary wrote: > On Friday 23 June 2017 13:01:53 Finn Thain wrote: > > On Fri, 23 Jun 2017, I wrote: > > > Does this patch help? It should be applied on top of this series of 4. > > > > Sorry, I sent the wrong diff. Please try this patch instead. > > Thanks, much better now: both HDD and CD-ROM seem to work on DTC and non-DTC > chips. I get many of these messages with CD-ROM: > [ 912.397076] generic_NCR5380_pread: No end dma signal (4096/4096) > [ 913.141225] generic_NCR5380_pread: No end dma signal (4096/4096) > > Maybe just remove this error message as in my original patch? > The "data loop" algorithm in the datasheet syas that if End of DMA doesn't become asserted after a transfer, this is an error condition. Your log (above) shows 4096/4096 bytes so I think that End of DMA is tested too soon: the datasheet says that End of DMA takes 100 ns to become asserted even after all of the relevant signals reach their final state. I'll re-do the series to account for this. Thanks for testing. --
Powered by blists - more mailing lists