MOL 0.9.64 on a 6500: report

[mol-general@lists.maconlinux.org]

On Tue, Jul 16, 2002 at 12:31:46PM -0400, Stefan Jeglinski wrote:
> 1. Default config files have scsi devices "on" (blkdev: sda -rw, 
> blkdev: sdb -rw), and I left those as is. The 6500 has a scsi cdrom 
> and zip drive. I am running 2.4.19-rc1 rsynced from mvista (BTW, I 
> can finally confirm complete stability on 603 with this kernel - I 
> was randomly crashing with all recent 2.4 kernels as per the bug 
> discussed on the dev mailing list). When launching mol in this 
> configuration, I get a break into mon, which requires a reboot 
> because I have no control thru the and keyboard). Here is the 
> relevant info:
> 
> vector: 400 at pc=00000000, lr=00000000, msr=20009032,
> sp=c05c5ea0 [c05c5df0], current=c05c4000, pid=7, comm=scsc_eh_1
> 
> I'm a little confused though... looking at my System.map, there is no 
> c05c address range... it ends at c02ac0b8 (?). 

The address is probably in a kernel module. Look in /proc/ksyms...

> though, if I comment out the 2 scsi references in the mol config 
> file, it boots -without- the debugger  break. I'm more concerned that 
> mol could cause the debugger break to begin with - is this possibly a 
> kernel issue rather than a mol issue?

I would guess this is the "AudioCD" bug. When MOL tries to read
data form an audio CD, the kernel panics (instead of returning
a sensible error). I used to be able to reproduce this by doing a simple 
"cat /dev/cdrom" as root. I haven't tried it lately though (and not
all CD players are/were affected).

This bug is one reason why /dev/cdrom is not specified in
/etc/molrc by default.

> 2. Regarding the drives again, I started with the default blkdev: hda 
> -rw setting, and all my Mac-side hfs partitions mounted rw; the 
> startup log showed a march through the partitions until it found a 
> suitable ROM at hda5. So I tried it again with blkdev: hda5 -rw first 
> and then on the next line blkdev: hda -rw. This time it booted right 
> away without marching, BUT: the boot drive was locked as if it really 
> wasn't rw, AND: the boot drive was mounted a second time rw. Maybe 
> this is how it should work?

Yes. I would suggest you use either

	/dev/hda5 -rw -boot
	/dev/hda9 -rw 
	/dev/hda13 -rw
or
	/dev/hda -rw -boot

If you mix, MOL will mount one the same volume twice (one read only, 
and one read/write).
	
> That's it for now, I'll hammer on this some more. I haven't 
> successfully gotten it to boot in any other than 640x480, despite my 
> belief that there are other legals modes set up. 

Change the resolution in MacOS... The resolution setting in
/etc/molrc.video has very little effect (basically, it only
affects the splash screeen).

> Have not tried full console screen yet. But I have to study
> the new config setup more. 

> Attached is the startup [and shutdown] log (what are all the 
> mouse_read_reg entries? also typo: should read "register" not 
> "regster"?).

Useless output :-). MOL emulates an ADB mouse (not really used
anymore; MacOS still detects it though) and a USB one. The warning
just states that someone tried to read from an unimplemented
ADB mouse registers. This is a completely legal thing to do, 
so the warning just reflects that the fact that MOL implements
a very basic type of mouse.

Cheers,

/Samuel