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: <alpine.LNX.2.00.1701271234010.32301@nippy.intranet>
Date:   Fri, 27 Jan 2017 12:41:50 +1100 (AEDT)
From:   Finn Thain <fthain@...egraphics.com.au>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
cc:     Michael Schmitz <schmitzmic@...il.com>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Tejun Heo <tj@...nel.org>,
        "linux-ide@...r.kernel.org" <linux-ide@...r.kernel.org>,
        Linux/m68k <linux-m68k@...ts.linux-m68k.org>,
        Linux Kernel Development <linux-kernel@...r.kernel.org>,
        Andreas Schwab <schwab@...ux-m68k.org>
Subject: Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support


On Thu, 26 Jan 2017, Geert Uytterhoeven wrote:

> Hi Finn,
> 
> On Thu, Jan 26, 2017 at 9:47 AM, Finn Thain <fthain@...egraphics.com.au> 
> wrote:
> > The difficulty will be arranging for disabled FDC & IDE interrupt 
> > sources during SCSI DMA, and disabled SCSI & IDE interrupt sources 
> > during FDC DMA. (Not all 5380 interrupts can be disabled; no idea 
> > about the IDE device or WD1772 FDC.)
> 
> IDE interrupts are disabled at the device level. Unfortunately some hard 
> drives (e.g. Western Digital Caviar) didn't honour the ATA disable IRQ 
> bit, so they caused an interrupt deadlock if you probed for them on 
> Amiga with the IDE interrupt enabled. The problem didn't show up on PC 
> because they had no shared interrupts, while on A4000 the IDE interrupt 
> is shared with Zorro Ethernet, which was still enabled.
> 
> That was fixed (in 1995 or 1996?) by disabling the IDE interrupt at the 
> IRQ controller level.
> 

As I undersand it, masking these interrupts at the IRQ controller level 
won't work because these interrupt sources are all logically-OR'd together 
to generate the input that is to be polled during DMA. (And accessing the 
individual device registers is impossible during DMA!)

Anyway, the end result is that both IDE and SCSI have the potential to 
(occasionally) mess up the DMA polling during and FDC or SCSI transfer. 

For SCSI, I believe that we can detect this when it happens (by checking 
the sector count registers in the DMA chip) and return the SCSI command 
with an error result, so that the mid-layer will retry it.

I don't know how it would be handled in the case of an FDC transfer but I 
presume that a similar mechanism is available in the block layer.

-- 

> Gr{oetje,eeting}s,
> 
>                         Geert
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ