From owner-freebsd-arch@freebsd.org Mon Dec 4 00:56:06 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 963CEE6EB4A for ; Mon, 4 Dec 2017 00:56:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6DC047143C for ; Mon, 4 Dec 2017 00:56:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 69EA3E6EB49; Mon, 4 Dec 2017 00:56:06 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 697C0E6EB48 for ; Mon, 4 Dec 2017 00:56:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 29D2D7143A for ; Mon, 4 Dec 2017 00:56:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22e.google.com with SMTP id b5so8909918itc.3 for ; Sun, 03 Dec 2017 16:56:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bzxkAkeWuZK3UozVmQ9XSlPzr3lMTBvL5Z1pr0pY4go=; b=vU+6IdvxpuSJfZSg5SSNUaMNWynAaExDXhuLqiyg5hVwIemH0hXOxBILaSJy0iHSGU Ea+ZtfARu+cXxgs941HQnNs4mD+PXqx1605mq+L73NZE2zSmtcq/Eef8q07vvpMAZBOb Gw+Di9mktjKRgfHNG8wo1IsxH7knfWB+3y4DqlVyeryP83drMxRSHuHKaTRh7rz+eCTC RAevaKOV9dMmMLXssBS+FJNoi6pDLT2Ug1/SidjFAKFae699xDqThRb7cFXunbBsrCBW s72QLjXxnUsNRuoweOH0t6O1wBIN1sQZNgohayF2N+bwPJ791D1WUm4dfjefvbdx9H9s jrdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bzxkAkeWuZK3UozVmQ9XSlPzr3lMTBvL5Z1pr0pY4go=; b=nEv7H+heMRgCLPXQiCjc6yIJHLkqbZ2UvT10+6PG64xRAzVh147/RNVe8IfPeQUed+ xP/EkiE2iuZUHWXiENNIp1sRJOJvSt6CeD/AGzz3O8CUqARnTHw73m5f1VxaF2q0RWHV by0+RlFdKX32CxGQjPtBWj0P3gxWp7nKzfCxevJPe8fwhqBlI6rTX2W3lU2aPpYNFiH7 IxMU6ueP3jCmw8eW2rxe/jEhFRGTRBa7EJPjLNTIjE9WlnrjVHw6ktYPYplt2MunoYEi ufDmnDwdclAalywQdAcjEgPD22/A+xJ0K1hRiTzNAwYV61LPZ+qmOOurvHGzH1dU3/js hOUA== X-Gm-Message-State: AKGB3mLLpFEjcJn/2o+lq+v52P5Am/7FsrTuBDiksUHVEQG+qa5Hfj+x USMaFfj2qA4mWd389VuDo4fS+WspT807JGZP9AXfjw== X-Google-Smtp-Source: AGs4zMYgoO1RFnA5bgXDr/eL00dH+P5tg7xrqfnxT3WzojTDdJgTHC/+tTsiQ9ifhJqxr0U0XFJROh6mRuNls2Gjq8g= X-Received: by 10.36.147.193 with SMTP id y184mr2432819itd.64.1512348965423; Sun, 03 Dec 2017 16:56:05 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Sun, 3 Dec 2017 16:56:04 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <201712040035.vB40ZFjx037674@slippy.cwsent.com> References: <201712040035.vB40ZFjx037674@slippy.cwsent.com> From: Warner Losh Date: Sun, 3 Dec 2017 17:56:04 -0700 X-Google-Sender-Auth: 3waXX83Mhnw2QRWYU4vvlv9pxUI Message-ID: Subject: Re: Deprecating / Removing floppy drive support To: Cy Schubert Cc: Adrian Chadd , Hans Petter Selasky , "freebsd-arch@freebsd.org" , "Rodney W. Grimes" , Eitan Adler Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 00:56:06 -0000 On Sun, Dec 3, 2017 at 5:35 PM, Cy Schubert wrote: > In message tVsHXqgqaNihuQ@mail.gmail.c > om> > , Warner Losh writes: > > --001a11418b8c855b04055f789009 > > Content-Type: text/plain; charset="UTF-8" > > > > On Sun, Dec 3, 2017 at 4:48 PM, Adrian Chadd wrote: > > > > > [snip snip] > > > > > > If someone wants to support it, and it doesn't make things in other > > > places harder ... why not do it! > > > > > > It at least keeps our APIs honest.. > > > > > > > If it actually works on real hardware, something we have conflicting > > reports on at the moment... > > > > And we seem to be short of the 'someone' that would be able to take up > the > > banner of wanting to support it, having the skill to support it and > > demonstrating the time is there by fixing bugs... > > Bruce was partially right. It does work on i386. My test on an i386 MP > kernel worked. > > Just a guess, as I haven't really looked at it, I'm willing to bet the > controller expects to use addresses below 4 GB. The Floppy controller doesn't grok anything about addresses. The ISA DMA chip (8237A) doesn't grok anything about 16MB. The floppy is hard wired to channel 2 of the DMA controller and can only do 8-bit transfers. And it's slow (maybe 400kB/s). It's so limited that it spawned creation of VLB and then PCI. One cause of problems is that fdc passes the raw address of the BIO that generated the I/O down to isa_dma. Once there, there's a range check to make sure that it's a cool address, and if not it bounces it into dma_bouncebuf[] which is contig malloc'd early in an attempt to get that elusive below 16MB memory (it panics it if can't get it). There was talk about tweaks to the isa_dma interface to allow drivers to specify the memory to use and using a hard-coded 64k array in the floppy driver to ensure it is below 16MB (with linker script hacks, if necessary). That talk never went anywhere, though. Also, if contigmalloc is broken such that it no longer really honors the constraints in the arguments, the isa_dma code has no checks for that either location or aligment (both of which would be fatal to proper floppy operation). This would explain why it works for bde and not for me or others I've chatted with about the deal. Adding sanity checks here would be a good first start, I think, to making things less insane. An even better start would be to just pre-allocate DMA channel 2 with 64k, aligned 64k in isa_dma and hack the code to use this. The other channels... No One will ever use them anymore... Just a thought... Memory is no longer so dear that this would be an issue. Warner