linux-kernel - Re: IDE Floppy support for IOMEGA Zip Drive broken in 3.16 -> 3.17 transition

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: <559630A9.5020804@gmail.com>
Date:	Fri, 03 Jul 2015 08:50:17 +0200
From:	Sergio Callegari <sergio.callegari@...il.com>
To:	Ondrej Zary <linux@...nbow-software.org>
CC:	linux-kernel@...r.kernel.org
Subject: Re: IDE Floppy support for IOMEGA Zip Drive broken in 3.16 -> 3.17
 transition

On 02/07/2015 18:11, Ondrej Zary wrote:
> You're probably using libata and not the old IDE layer.
>
> Just tested this one:
>
>   Model=IOMEGA  ZIP 100       ATAPI, FwRev=03.H, SerialNo=
>   Config={ SpinMotCtl Removeable nonMagnetic }
>   RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
>   BuffType=unknown, BuffSize=unknown, MaxMultSect=0
>   (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
>   IORDY=on/off, tPIO={min:500,w/IORDY:180}, tDMA={min:150,rec:150}
>   PIO modes:  pio0 pio1 pio2 pio3
>   DMA modes:  mdma0 *mdma1
>   AdvancedPM=no
>
>   * signifies the current active mode
>
> in 4.0.0-next-20150415 and it seems to work fine. Mounted, unmounted, read
> complete disk using dd without any problems.
>
Also mine 'seems' to work fine.  I can boot the machine, mount, unmount, read 
the disk without problems *for some time*.

The issue is that, if I boot *with no disk in the drive* after about 2-3 hours I 
use the machine the iowait jumps high, the kernel starts to complain about hung 
processes, any command related to the zip drive starts hanging, the machine 
cannot be shut down cleanly, any kernel install process starts to hang at the 
ramdisk generation or grub install.
If I detach the drive or downgrade to 3.16, all is fine.

Clearly, the items above make 'uninformed' bisecting quite hard, particularly 
because it is unclear to me at this point if the machine load has any influence 
on triggering the issue.

Now, it is obvious that one can live without a zip drive today, but if this is 
the case, it would be better to blacklist it from the kernel altogether, because 
something has surely got wrong in the 3.16->3.17 transition and there is a 
serious regression with regard to this now rarely used piece of hardware. Also I 
wonder if there is around some other "ide-floppy" device that may be affected.

Regards,

Sergio

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/