[openbeosstorage] Re: R5 Pro CD vs. partition/intel

> Here's what I've come up with while trying to get the updated session 
> module working with the R5 CD:
> 
> + Using the disk_scanner version pre-dating Ingo's recent (meaning 
> since the holidays) changes, everything works fine. All three 
> sessions are enumerated properly.
> + Using the current version, the intel partition module finds a valid 
> partition signature in the second session (the one with the bfs image 
> named "BeOS 5 Pro Edition"), and thus thinks it has a valid intel 
> style partition set, though it in fact does not. As the disk_scanner 
> is trying to enumerate all the available partitions, some 
> particularly large (and incorrect) offset or size is, I'm guessing, 
> causing a crash.
> + Using the old version of the disk_scanner, but changing line 119 of 
> disk_scanner.c to read (as it does in the new version)
> 
> =09=09=09if (read_pos(fd, offset, *block, size) !=3D (ssize_t)size) {
> 
> instead of
> 
> =09=09=09if (read_pos(fd, 0, *block, size) !=3D (ssize_t)size) {
> 
> gives the same behaviour as the newer version (since the partition 
> module is now passed the actual first block of each session, instead 
> of always getting the very first block on the disc, which is all 
> zeros (the first session is an iso9660 image)), but without the 
> crash. Since there's no crash, a number of incorrect partitions are 
> listed as existing in the second session.
>
> Thus I believe the crash, at least, is a bug in the new cache code; 
> the old code handles the garbage values gracefully.

Actually the cache code does some range checking against the partition 
boundaries. Nevertheless, it shouldn't crash on unusal partition 
dimensions though.

> The partition 
> behaviour is, unless I'm missing something, just a coincedence; the 
> bfs image happens to have a valid intel partition signature sitting 
> in the right location. 

That's very strange.

> If it were just some random, obscure CD, I might be tempted to say 
> "screw it", but being the R5 Pro CD, we really ought to get the thing 
> working properly. Since I believe the updated cdrom module is 
> actually working correctly, I've gone ahead and checked it in so 
> everyone can play with it. :-)

Unfortunately, it doesn't seem to work for me. I just updated to the 
latest CVS and the session module doesn't like the TOC or whatever. 
BTW, I'm have a version distributed by Gobe. Don't know if it is the 
same one distributed in the USA. Debug output is attached.

> So, if Ingo can't come up with a way to invalidate the second session 
> of the R5 CD as an intel style partition set while still properly 
> recognizing real partition sets :-), I guess we may need to handle 
> partitions differently for CDs.

At least the DriveSetup intel partition add-on manages to deny the 
sessions, so it is obviously possible. Currently I only test for the 
signature in identify(). I could parse at least the primary partition 
map, if not the whole partition structure.
BTW, I really tend to switch to C++ in that module. I believe, that 
would make it a lot more elegant and less error prone -- I think, I 
found another error concerning extended partitions on sessions with 
offset > 0.

> Has anyone ever heard of burning a CD 
> session with multiple partitions, anyway?

Yes (don't know, if their is an easy solution for home users though). 
Some BeNewsletter (or BMessage?) discusses the matter of CDs with 
multiple sessions vs. multiple partitions. And obviously the DriveSetup 
add-ons support it.

I don't have a CD burner at hand right now, but if you have, you can 
try to create a multi-partition image using the virtualdrive driver and 
burn it on CD. (The driver is a quite unflexible right now, but before 
we start testing our API, I will add driver_settings support.)

> Theoretically it could be 
> done, I guess, but you can do everything partitions can do (and more) 
> with sessions. Following that argument, we could then just have a 
> cdrom partition module (or special case, a la 
> disk_scanner_get_nth_session_info() in disk_scanner.c, but I don't 
> think I like that route; see next paragraph) that returns one 
> partition encompassing the whole session if the device is a CD. 
> Thoughts?

I don't like that idea either. In particular, because multiple 
partitions per session are possible.

> And while I'm thinking of it, that special case to handle CDs in  
> disk_scanner_get_nth_session_info() kind of bugs me. Oughtn't we have 
> a non-cdrom session module to handle the virtual session case, and 
> then allow developers to have a higher priority custom module in the 
> odd case that they want to support a special kind of session for 
> their device? As it currently stands, only CD devices ever get a 
> chance to publish sessions to the system.

That's true. If the session add-ons are robust enough, we can drop the 
check for CD devices and return a virtual session, in case no session 
add-on recognizes the format -- similarly as done on the partition 
module level. We don't need to introduce a dummy session add-on to do 
this -- otherwise we would indeed need priorities (not that I have 
arguments against priorities, but we don't need to introduce something 
we won't quite likely ever use).

> I've included below debug info from the above-mentioned cases when 
> run on the R5 Pro CD, in the order listed above.

Save the fact, that the partition add-on shouldn't recognize the second 
session in the first place I don't see anything suspicious.

CU, Ingo


Output for my BeOS CD:

device: `/dev/disk/ide/atapi/1/master/0/raw'
session/cdrom: std_ops(0x1)
session/cdrom: get_nth_info(3, 0, 642181120, 2048, 0xfd001784)
session/cdrom: read_table_of_contents: (3, 0xfd000798, 2048)
session/cdrom: table of contents dump:
--------------------------------------------------
header:
  length = 68
  first  = 1
  last   = 1

entry count = 6

entry #0:
  session  = 1
  adr      = 1
  control  = 0
  tno      = 0
  point    = 160 (0xa0)
  minutes  = 0
  frames   = 0
  seconds  = 0
  zero     = 0
  pminutes = 1
  pseconds = 0
  pframes  = 0
  lba      = 4350

entry #1:
  session  = 1
  adr      = 1
  control  = 4
  tno      = 0
  point    = 161 (0xa1)
  minutes  = 0
  frames   = 0
  seconds  = 0
  zero     = 0
  pminutes = 3
  pseconds = 0
  pframes  = 0
  lba      = 13350

entry #2:
  session  = 1
  adr      = 1
  control  = 4
  tno      = 0
  point    = 162 (0xa2)
  minutes  = 0
  frames   = 0
  seconds  = 0
  zero     = 0
  pminutes = 69
  pseconds = 42
  pframes  = 65
  lba      = 313565

entry #3:
  session  = 1
  adr      = 1
  control  = 4
  tno      = 0
  point    = 1 (0x01)
  minutes  = 0
  frames   = 0
  seconds  = 0
  zero     = 0
  pminutes = 0
  pseconds = 2
  pframes  = 0
  lba      = 0

entry #4:
  session  = 1
  adr      = 1
  control  = 4
  tno      = 0
  point    = 2 (0x02)
  minutes  = 0
  frames   = 0
  seconds  = 0
  zero     = 0
  pminutes = 9
  pseconds = 44
  pframes  = 47
  lba      = 43697

entry #5:
  session  = 1
  adr      = 1
  control  = 4
  tno      = 0
  point    = 3 (0x03)
  minutes  = 0
  frames   = 0
  seconds  = 0
  zero     = 0
  pminutes = 42
  pseconds = 49
  pframes  = 58
  lba      = 192583
--------------------------------------------------
session/cdrom: Point 0xA1 found in state 6
session/cdrom: error reading table of contents, ended up in state 6
session/cdrom: get_nth error 0x80006003
session/cdrom: std_ops(0x2)

Other related posts: