Re: mounting device acd0t01

Well, AFAIK, *cd*t* (like acd0t01) are for multisession disks.

I have personally only ever seen this when dealing with audio CDs, with
a tXX for every audio track.

You shouldn't have to mount those at all.

Mounting it as a ISO CD9660 filesystem is impossible if it is an audio
CD, since the data in those tracks is PCM and not a filesystem. (obviously)

If it's a data CD however, then you should be able to mount it provided
the disc was made correctly.

Personally though, I've never seen a multisession data disc show up in
this fashion... perhaps someone else has.
(A quick read of the manpage for acd shows:  "/dev/acd*              
ATAPI CD-ROM device nodes" so I can't be sure.)

About the panic... if  it is in fact an audio CD, it would seem that
some sort of sanity checking is missing in the mounting.

 In previous versions of FreeBSD it simply returned an error saying it
was not a CD9660 filesystem.

When I get home tonight I'll try and mount an audio cd in the same
fashion and see if I get the same panic.

Best of Luck!

--
Regards,
Chris Gilbert
+45 33 73 29 31 (UTC +0100)

Jeremie Le Hen wrote:

>Hi,
>
>I was trying to understand what was residing on an unnamed CD-ROM,
>and it leads me to run the following command :
>%%%
>    mount_cd9660 /dev/acd0t01 /cdrom
>%%%
>
>I obtained such a device once I have used cdcontrol(8) to try playing
>the CD-ROM.  BTW, isn't it possible to make these devices appear
>immediately when the CD-ROM is inserted and remove them when the
>CD-ROM is removed ?  I don't know how this works internaly, but I'm
>pretty sure the CD-ROM drive triggers an interruption for this kind
>of actions.
>
>Apart from this, this generated the following panic.  Is is resolvable ?
>%%%
>    panic: wrong offset 32768 for sectorsize 2352
>    [...]
>    panic()
>    g_io_request() at g_io_request+0xbb
>    g_vfs_strategy() at g_vfs_strategy+0x71
>    breadn() at breadn+0x141
>    bread() at bread+0x4c
>    cd9660_mount() at cd9660_mount+0x568
>    vfs_domount() at vfs_domount+0x667
>    vfs_donmount() at vfs_donmount+0x107
>    kernel_mount() at kernel_mount+0x7e
>    cd9660_cmount() at cd9660_cmount+0x1cd
>    mount()  at mount+1e6
>    syscall()
>    Xint0x80_syscall()
>    --- syscall (1, FreeBSD ELF32, mount), eip = 0x36759097, esp = 0xbfbf123c, ebp = 0xbfbf1708 ---
>%%%
>
>I didn't do a dump, it is easily reproducible.
>My sources are dating from 2004.07.24, but I don't think this is very
>relevant for this bug.
>
>Regards,
>  
>