Date: Sun, 12 Feb 2006 21:11:11 +0900 (JST) From: chi@bd.mbn.or.jp (Chiharu Shibata) To: sos@deepcore.dk Cc: freebsd-hackers@FreeBSD.ORG, re@FreeBSD.ORG, nork@FreeBSD.ORG, core@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: kern/60163 Message-ID: <20060212121111.5A54E819F@m-kg282p.ocn.ne.jp> In-Reply-To: <43EF0194.3020605@deepcore.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
This is Chiharu Shibata. At Sun, 12 Feb 2006 10:36:20 JST, you wrote... >Norikatsu Shigemura wrote: >> I heard from Chiharu Shibata <chi@bc.mbn.or.jp> about kern/60163. >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/60163 >> (He knew that this pr was closed, recently) >> >> I cannot believe sos's close reason. >> >> ********************************************************** >> The most significant problem is "Cannot mount CD-EXTRA >> multisession cd.". No related /dev/acdXtY. >> ********************************************************** >> >> If there are no reason expect sos' close reason, the patch >> should be committed. How about this? > >Uhm, why the fuzz about this now, this PR was closed on >Mon Sep 6 11:40:13 GMT 2004 according to logs. GNATS system does not mail to me, because I'm a follower of this PR, not a originator. >However on the patch involved: setting the blocksize for the /dev/acd0 >device depending on blocksize of any track is just as wrong as setting >it to the size of the first track, it just fails in different ways. >So the right way to do this on multitrack media, is to mount any track >as /dev/acdNtY which will set the blocksize correctly for that track. >Thats why the PR was closed as stated in the PR logs... > >So, if we should rehash this again I'll need more details on what it is >that fails exactly doing what, CD layouts etc etc... This is a sample DISC's rayout. ==== Starting track = 1, ending track = 13, TOC size = 114 bytes track start duration block length type ------------------------------------------------- 1 0:02.00 4:09.25 0 18550 audio 2 4:09.25 4:28.22 18550 19972 audio 3 8:35.47 4:00.48 38522 17898 audio 4 12:34.20 5:56.37 56420 26587 audio 5 18:28.57 4:59.45 83007 22320 audio 6 23:26.27 5:13.15 105327 23340 audio 7 28:37.42 0:21.58 128667 1483 audio 8 28:57.25 3:51.72 130150 17247 audio 9 32:47.22 5:02.10 147397 22510 audio 10 37:47.32 4:23.30 169907 19605 audio 11 42:08.62 4:41.70 189512 20995 audio 12 46:48.57 3:28.27 210507 15477 audio 13 50:15.09 4:36.37 225984 20587 data 170 54:49.46 - 246571 - - ==== To mount this DISC, your opinion is... (1) at first, try "cdcontrol -f /dev/acd0c info" to make sure where track is data area. (2) type "mount_cd9660 -o rdonly /dev/acd0t13 /cdrom". Is this right? 1st Problem: I cannot mount this DISC though the procedure is completed. "mount_cd9660: /dev/acd0t13: Invalid argument" Did you succeed? In this case, the "disklabel.d_secsize" is still "2352", even if /dev/acdNtY is used. Does the hidden problem like this remain? 2nd Problem: It varies by the DISCs where the starting track of data area. Therefore, there is no way to write the entry of CD Extra DISC in /etc/fstab, and so on. Of course, my(and originator) patch can mount any CD Extra DISCs by "/dev/acd0c". 3rd Problem: The originator says "atapicam is OK". SCSI and ATAPICAM use "/dev/cdYc", but ATA should use "/dev/acdYtN" to mount same CD Extra DISC. Don't you think this to be a strange specification? -- Chiharu Shibata chi@bd.mbn.or.jp <http://www32.ocn.ne.jp/~chi/>;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060212121111.5A54E819F>