Date: Mon, 15 Mar 1999 09:45:57 -0700 (MST) From: "Kenneth D. Merry" <ken@plutotech.com> To: ian@apdata.com.au (Ian West) Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: cam_periph_mapmem: attempt to map 66560 bytes, which is greater than DFLTPHYS(65536) Message-ID: <199903151645.JAA19568@panzer.plutotech.com> In-Reply-To: <36ECEF06.80D63F63@apdata.com.au> from Ian West at "Mar 15, 1999 9:59:10 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903151645.JAA19568>