ports/63775: cam_periph_mapmem: attempt to map failed in cdda2wav
Eyal Soha
esoha at comcast.net
Thu Mar 4 22:10:19 UTC 2004
>Number: 63775
>Category: ports
>Synopsis: cam_periph_mapmem: attempt to map failed in cdda2wav
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Mar 04 14:10:18 PST 2004
>Closed-Date:
>Last-Modified:
>Originator: Eyal Soha
>Release: FreeBSD 5.1-RELEASE-p13 i386
>Organization:
>Environment:
System: FreeBSD x1-6-00-50-2c-02-55-54.attbi.com 5.1-RELEASE-p13 FreeBSD 5.1-RELEASE-p13 #0: Wed Mar 3 16:49:41 PST 2004 esoha at x1-6-00-50-2c-02-55-54.attbi.com:/usr/src/sys/i386/compile/EYAL i386
>Description:
I was trying to use xcdroast and it kept failing during the reading of data from the CD. Using "xcdroast -d 1" I saw the xcdroast runs the command cdda2wav like this:
x1-6-00-50-2c-02-55-54:~/cdda2wav#cdda2wav -D "1,0,0" -g -O wav -S 40 -v all -P
0 -n 75 -paranoia -paraopts=retries=20 -B "track-01.wav" "track-02.wav" "track-0
3.wav" "track-04.wav" "track-05.wav" "track-06.wav" "track-07.wav" "track-08.wav
" "track-09.wav" "track-10.wav" "track-11.wav" "track-12.wav" "track-13.wav" "tr
ack-14.wav"
Type: ROM, Vendor 'LITE-ON ' Model 'LTR-24102B ' Revision '5S07' MMC+CDDA
266240 bytes buffer memory requested, 4 buffers, 27 sectors
#Cdda2wav version 2.00.3_freebsd_5.1-release-p13_i386_i386, real time sched., so
undcard, libparanoia support
Tracks:14 46:28.32
CDINDEX discid: W2_EXuJmN5nw13xvsoU.aExv_Xg-
CDDB discid: 0xb50ae20e
CD-Text: not detected
CD-Extra: not detected
Album title: '' from ''
T01: 0 3:08.65 audio linear copydenied stereo title '' from ''
T02: 14165 2:55.55 audio linear copydenied stereo title '' from ''
T03: 27345 2:34.05 audio linear copydenied stereo title '' from ''
T04: 38900 2:50.65 audio linear copydenied stereo title '' from ''
T05: 51715 3:30.37 audio linear copydenied stereo title '' from ''
T06: 67502 3:11.38 audio linear copydenied stereo title '' from ''
T07: 81865 2:55.17 audio linear copydenied stereo title '' from ''
T08: 95007 3:19.20 audio linear copydenied stereo title '' from ''
T09: 109952 3:56.65 audio linear copydenied stereo title '' from ''
T10: 127717 3:03.40 audio linear copydenied stereo title '' from ''
T11: 141482 3:57.08 audio linear copydenied stereo title '' from ''
T12: 159265 3:51.25 audio linear copydenied stereo title '' from ''
T13: 176615 2:33.25 audio linear copydenied stereo title '' from ''
T14: 188115 4:38.17 audio linear copydenied stereo title '' from ''
Leadout: 208982
No media catalog number present.
scanning for ISRCs: 14 ...
index scan: 14...samplefile size will be 491525708 bytes.
recording 2786.4266 seconds stereo with 16 bits @ 44100.0 Hz ->'track-01'...
using lib paranoia for reading.
child pid is 51260
percent_done:
0%cdda2wav: Argument list too long. Cannot send SCSI cmd via ioctl
W Child exited with 2
I have an ATA CD drive and I'm using atapicam to emulate having a SCSI CD drive, because xcdroast doesn't support ATAPI CD drives.
I've never hacked around with this stuff, but here's my best guess as to what's going wrong:
cdda2wav is generating a ccb to send to the CAM XPT module. ATAPICAM needs to map the userland data into kernel land for the transfer. To make sure that it fits within a page boundary, there is a check made in sys/cam/cam_periph.c:
if ((lengths[i] +
(((vm_offset_t)(*data_ptrs[i])) & PAGE_MASK)) > DFLTPHYS){
printf("cam_periph_mapmem: attempt to map %lu bytes, "
"which is greater than DFLTPHYS(%d)\n",
(long)(lengths[i] +
(((vm_offset_t)(*data_ptrs[i])) & PAGE_MASK)),
DFLTPHYS);
cdda2wav isn't aligning the data_ptr properly each time, so the check fails sometimes.
>How-To-Repeat:
Need a system with an ATA CD drive, using cdda2wav and atapicam. Run this command as root:
cdda2wav -V -D "1,0,0" -g -O wav -S 40 -v toc,summary,sectors,titles -P 0 -n 75 -paranoia -paraopts=retries=20 -B "track-01.wav" "track-02.wav" "track-03.wav" "track-04.wav" "track-05.wav" "track-06.wav" "track-07.wav" "track-08.wav" "track-09.wav" "track-10.wav" "track-11.wav" "track-12.wav" "track-13.wav" "track-14.wav"
In my tests, the first ccb always has an aligned pointer, but the second one isn't.
>Fix:
Have cdda2wav send properly aligned addresses, or shink the transfer size down so that the data fits within a page. I'm not sure how difficult this will be.
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-ports-bugs
mailing list