From what I've seen the Partition Map is the same on disk and CD.  It is 
stored in entrries that are 512 bytes in length.  There can be alternate 
entries in the Partition Map that are used for accessing the CD in 2K 
blocks, but those entries still appear to be 512 bytes in length 
themselves.  From this I assume the Partition Map is always processed as 
if it were composed of entries each containing 512 bytes, but an entry 
may describe a Partition that should be processed as 2K sized blocks.

I've got some utilities that I used to dump various Partition Maps from 
different devices; SCSI disks, IDE disks, and CDs.  If anyone would like 
them or the dumps I've gotten from my devices I'd be happy to provide 
them.

Hope this helps,
-bob

On 10/20/01 1:19 PM, Chuck Silvers (chuq@chuq.com) wrote:

>no one answered my question, so I don't know what the right fix is yet.
>
>-Chuck
>
>
>On Sat, Oct 20, 2001 at 11:05:46AM -0400, Jim Mercer wrote:
>> On Wed, Oct 03, 2001 at 11:28:14PM -0700, Chuck Silvers wrote:
>> > well the problem is pretty obvious.  mac68k/disksubr.c has:
>> 
>> did we ever see a solution to this?
>> 
>> > 
>> > #define NUM_PARTS 32
>> > 
>> > char *
>> > readdisklabel(dev, strat, lp, osdep)
>> > ...
>> > {
>> > 	...
>> > 	bp = geteblk((int)lp->d_secsize * (NUM_PARTS + 1));
>> > 	...
>> > }
>> > 
>> > 
>> > for a cdrom, lp->d_secsize is going to be 2k, so readdisklabel()
>> > will try to allocate a buffer of size 2k * 33 = 66k, which is larger
>> > than MAXBSIZE (which is 64k).
>> > 
>> > I'm guessing that readdisklabel() is really assuming that lp->d_secsize
>> > is 512, in which case this would work out fine.  if the mac partition map
>> > records are stored consectively on disk (rather than 1 entry per sector
>> > as the code currently assumes) then we should be able to replace all of
>> > the occuraces of "lp->d_secsize" with "512", and then round the argument
>> > of geteblk() up to a multiple of lp->d_secsize.
>> > 
>> > could someone that has a cd with a mac partition table on it
>> > check to see whether the partition map records are packed or
>> > 1 entry per sector?
>> > 
>> > -Chuck
>> > 
>> > 
>> > On Wed, Oct 03, 2001 at 12:45:51PM -0400, Jim Mercer wrote:
>> > > On Tue, Oct 02, 2001 at 09:20:58PM -0700, Chuck Silvers wrote:
>> > > > what is the stack trace when it panics like this?
>> > > > (type "t" in ddb)
>> > > 
>> > > sorry, i don't have a serial console, so this is by hand, if you need 
the
>> > > specific numbers, i can get them by crashing it again.
>> > > 
>> > > panic: allocbuf: buffer larger than MAXBSIZE requested
>> > > Stopped in pid 186 (cdparanoia) at _spu_Debugger+0x6:  unlk  a6
>> > > db> t
>> > > _cpu_Debugger(
>> > > _panic(
>> > > _allocbuf(
>> > > _geteblk(
>> > > _readdisk(
>> > > _cdgetdisklabel(
>> > > _cdopen(
>> > > _spec_open(
>> > > _VOP_OPEN(
>> > > _vn_open(
>> > > _sys_open(
>> > > _syscall(
>> > > _trap(
>> > > 
>> > > 
>> > > > 
>> > > > -Chuck
>> > > > 
>> > > > 
>> > > > On Tue, Oct 02, 2001 at 03:15:15PM -0400, Jim Mercer wrote:
>> > > > > 
>> > > > > i've tried this with the current-20010915 SBC kernel and i have the
>> > > > > current-20010915 userland.
>> > > > > 
>> > > > > i built and installed cdparanoia.
>> > > > > 
>> > > > > when i run it to query the drive, i get a panic/break to debugger:
>> > > > > 
>> > > > > panic: allocbuf: buffer larger than MAXBSIZE requested
>> > > > > stopped in pid 16209 (cdparanoia) at _cpu_Debugger+0x6: unlk  a6
>> > > > > 
>> > > > > note: this same thing happened using binary package versions of 
other
>> > > > > cdrom/audio tools on 1.5.0, 1.5.1 and 1.5.2.
>> > > > > 
>> > > > > hardware is:
>> > > > > 
>> > > > > Mac LC575, 36M, upgraded to full 68040
>> > > > > 
>> > > > > CD is Neil Young.  8^)
>> > > > > 
>> > > > > -- 
>> > > > > [ Jim Mercer        jim@reptiles.org         +1 416 410-5633 ]
>> > > > > [ Now with more and longer words for your reading enjoyment. ]
>> > > 
>> > > -- 
>> > > [ Jim Mercer        jim@reptiles.org         +1 416 410-5633 ]
>> > > [ Now with more and longer words for your reading enjoyment. ]
>> 
>> -- 
>> [ Jim Mercer        jim@reptiles.org         +1 416 410-5633 ]
>> [ Now with more and longer words for your reading enjoyment. ]
>