From owner-freebsd-scsi Mon Mar 15 8:49: 9 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F2E6150AF for ; Mon, 15 Mar 1999 08:46:23 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id JAA19568; Mon, 15 Mar 1999 09:45:57 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903151645.JAA19568@panzer.plutotech.com> Subject: Re: cam_periph_mapmem: attempt to map 66560 bytes, which is greater than DFLTPHYS(65536) In-Reply-To: <36ECEF06.80D63F63@apdata.com.au> from Ian West at "Mar 15, 1999 9:59:10 pm" To: ian@apdata.com.au (Ian West) Date: Mon, 15 Mar 1999 09:45:57 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ian West wrote... > I have the following error when trying to write a cd using the latest > version of cdrecord (1.8a17). The latest version of cdrecord is 1.8a19. Joerg fixed this bug in that release: ============================ - Fixed a bug with non page aligned buffers if the FIFO was present. This caused problems with FreeBSD/current/CAM due to the fact that the max. number of DMA pages was exceeded. ============================ Thanks to Bjoern Fischer for figuring it out. > I worked around it by (probably wrongly, > but it works) doubling the sizes of DFLTPHYS, and MAXPHYS in > src/i386/param.h. The system is running fine, and it allowed me to write > my cd. Well, you can do that, but that's not the "right" thing to do, really. And it probably would have broken again if you recompiled cdrecord using the new value for DFLTPHYS. > cam_periph_mapmem: attempt to map 66560 bytes, which is greater than > DFLTPHYS(65536) > > Looking into this for a 'proper' answer, the section of code in > cam_periph (line 552) which seems to relate is below... > > if ((lengths[i] + > (((vm_offset_t)(*data_ptrs[i])) & PAGE_MASK)) > DFLTPHYS){ > printf("cam_periph_mapmem: attempt to map %u bytes, " > "which is greater than DFLTPHYS(%d)\n", > lengths[i] + > (((vm_offset_t)(*data_ptrs[i])) & PAGE_MASK), > DFLTPHYS); > return(E2BIG); > > seems to be where the error is ocuring. As I understand it, this allows > for the possibility of having the users buffer offset from the start of > a page. If the user is allowed to request up to DFLTPHYS bytes of > transfer, should the comparison not be for MAXPHYS ? > Am I missing the point completely ? I think so. The comparison needs to be against DFLTPHYS, because there are some controllers (e.g. the Adaptec 1542) that cannot handle transfer sizes greater than 64k. When userland buffers are mapped into the kernel, they will be truncated to start on a page boundary if they do not already start on a page boundary. If you've got a buffer that is 64k long that does not start on a page boundary, it will end up taking up more than 64k. Eventually we plan on adding fields to the path inquiry (XPT_PATH_INQ) CCB that will specify the maximum transfer size allowed by the controller and the maximum allowed by the system. (or something along those lines) Then userland programs will be able to inquire what the maximum transfer size is for a given device. If we can get some sort of buffer chaining system in place, the limiting factor will be the controller. This will also be helpful for people who want to read/write tapes with large block sizes. You can do it now by changing DFLTPHYS/MAXPHYS, but it would be easier if it just worked by default. > Is this simply a code error in > cdrecord ? Yes. cdrecord wasn't page-aligning all of its transfers, and was using the full DFLTPHYS transfer size. So some buffers, once they were truncated to a page boundary, exceeded DFLTPHYS. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message