Date: Mon, 4 Jan 1999 00:26:40 -0700 (MST) From: "Kenneth D. Merry" <ken@plutotech.com> To: parag@cgt.com (Parag Patel) Cc: freebsd-current@FreeBSD.ORG Subject: Re: 3.0-CURRENT CAM vs scanner problems Message-ID: <199901040726.AAA56886@panzer.plutotech.com> In-Reply-To: <199901040055.QAA21093@pinhead.parag.codegen.com> from Parag Patel at "Jan 3, 99 04:55:12 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Parag Patel wrote... > > I am getting errors like these from the CAM subsystem when I try to scan > a rather small image using GIMP and the SANE 1.0 port and my UMAX: > > cam_periph_mapmem: attempt to map 130851 bytes, which is greater than DFLTPHYS(65536) > cam_periph_mapmem: attempt to map 130820 bytes, which is greater than DFLTPHYS(65536) > cam_periph_mapmem: attempt to map 131016 bytes, which is greater than DFLTPHYS(65536) > cam_periph_mapmem: attempt to map 129444 bytes, which is greater than DFLTPHYS(65536) > cam_periph_mapmem: attempt to map 131029 bytes, which is greater than DFLTPHYS(65536) > > The scan does not succeed in either lineart, gray, or color modes, > although the preview does. > > The comment in cam/cam_periph.c implies that the DFLTPHYS should be > MAXPHYS but perhaps the comment is wrong? Or perhaps SANE should be > using DFLTPHYS instead of MAXPHYS? > > For now, I added a patch to the sane-1.0 sanei/sanei_scsi.c file to use > DFLTPHYS instead of MAXPHYS, and it is scanning nicely. Still, I don't > know if it's a SANE bug or a CAM bug and so don't who to report it to. This is a SANE bug, sort of. quick background info: ======== The crashes that folks have been seeing with cdda2wav were caused by cdda2wav doing non-page-aligned reads that were within a page of 128K in size. Because the VM system deals with things on page boundaries, this ended up causing more than 128K to get mapped in, which exceeded the size of the system buffers (they're MAXPHYS size, and MAXPHYS == 128K). So, I first put in the proper check to make sure that transfers near 128K were page aligned. This "fixed" the cdda2wav crashes, by causing the program not to work by default. (because its transfers were too big) Justin then suggested that I change the check to be against DFLTPHYS (64K), since some controllers can't handle transfer sizes larger than that. Bruce then pointed out that controllers have always had to be able to handle DFLTPHYS/PAGE_SIZE - 1 page transfers, to handle the non-aligned case. I need to check that with Justin, though. That obviously assumes, however, that MAXPHYS > DFLTPHYS, and not MAXPHYS >= DFLTPHYS. So, it's possible I may take out the alignment check, and you may be able to transfer slightly more than 64K in the non-aligned case. Eventually, we'll have a field in probably the path inquiry CCB that indicates the maximum transfer size the controller can handle. Then applications can use that to set their maximum transfer size, rather than a fixed value. ======== For now, SANE should be changed to use the following transfer size calculation. This will work in all cases, and it will work even after we make future changes: DFLTPHYS - PAGE_SIZE (i.e., 60K for i386, and 56K for alpha) The cdrecord port has been changed to use that value, and Joerg Schilling will be putting that into his cdrecord/libscg source tree, so cdda2wav and cdrecord will be using that value in the future as well. I imagine that this is more than you wanted to hear, but at least it sort of explains the problem. :) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901040726.AAA56886>