Re: [Qemu-devel] BeOS R5 boot failure
El 23/03/2010, a las 10:07, François Revol escribió: I've been trying for some time to get an old BeOS R5 image to boot, but it seems it doesn't like QEMU's IDE controller: Trying /dev/disk/ide/ata/0/master/0/raw IDE PCI -- find_devices: intel 82371SB (PIIX3) chipset IDE PCI -- find_devices: controller supports DMA IDE ATA -- configure_device: selected dma mode bad, disable dma for this device IDE ATA -- get_bios_driveinfo: ata/0/0 match bios drive 0x80 found boot device: /dev/disk/ide/ata/0/master/0/raw IDE PCI -- find_devices: intel 82371SB (PIIX3) chipset IDE PCI -- find_devices: controller supports DMA IDE ATA -- configure_device: selected dma mode bad, disable dma for this device IDE ATA -- get_bios_driveinfo: ata/0/0 match bios drive 0x80 IDE PCI -- find_devices: intel 82371SB (PIIX3) chipset IDE PCI -- find_devices: controller supports DMA IDE ATA -- configure_device: selected dma mode bad, disable dma for this device IDE ATA -- get_bios_driveinfo: ata/0/0 match bios drive 0x80 warning: fs blocks fa000 larger than device blocks 0 bad super block KERNEL PANIC: was unable to mount /dev/disk/ide/ata/0/master/0/0_0 type bfs on /boot Anyone has a clue ? It's a known bug but nobody knows or has time to apply a solution. Bochs had the same bug and corrected it about November 2009, maybe checking their commit will make light to correct QEMU. It seems VirtualBox has the same issue. Older versions (ZETA) seem to work fine, but they have a totally different IDE subsystem. VirtualPC had the same fail also. Zeta however is not an older version but a newer one. Considering Zeta is a non-authorized hack, who knows what have they changed. The bug is present on BeOS R3, R4, R4.5 and R5. The warning suggest the block device is seen as having a size of 0, though oddly it seems to be able to read from it since it gets the size of the BFS in the superblock... I've rebuilt with DEBUG_IDE and put a log here: http://revolf.free.fr/beos/qemu-beosr5-bad-ide-20100323.log Note disabling DMA in the boot menu (space bar, Select safe mode options) doesn't help either... Use F1 at boot to get serial output. The image is available here: http://bebits.com/app/2680 (BeOS R5 Personal Edition for Linux) François.
Re: [Qemu-devel] BeOS R5 boot failure
It's a known bug but nobody knows or has time to apply a solution. Bochs had the same bug and corrected it about November 2009, maybe checking their commit will make light to correct QEMU. Ok, I might have a look at it, thanks. It seems VirtualBox has the same issue. Older versions (ZETA) seem to work fine, but they have a totally different IDE subsystem. VirtualPC had the same fail also. Zeta however is not an older version but a newer one. Yes I messed up, I meant newer of course. Considering Zeta is a non-authorized hack, who knows what have they changed. I do, I worked at yellowTAB for a while. :p ZETA switched to a customized version of the IDE Replacement stack from Thomas Kurschel at some point: http://bebits.com/app/2625 This whole FUD about ZETA not being legal has nothing to do in here. Besides, if PalmSource/Palm/ACCESS loose documents in their cupboards it's not my fault. François.
Re: [Qemu-devel] BeOS R5 boot failure
http://bochs.cvs.sourceforge.net/bochs/bochs/CHANGES?view=markupcontent-type=text/vnd.viewcvs-markuprevision=REL_2_4_2_FINAL 2.2.5 December 2005 BeOS boot failure fix in the PCI IDE code 2.3.5 September 2007 [1500216] Bochs fails to boot BeOs CD I had a look at it, but it seems it's only about DMA... and the code in hw/ide/ seems to already or the status reg with BM_STATUS_INT (4) in many places... Seems to be something else maybe. François.
Re: [Qemu-devel] BeOS R5 boot failure
http://bochs.cvs.sourceforge.net/bochs/bochs/CHANGES?view=markupcontent-type=text/vnd.viewcvs-markuprevision=REL_2_4_2_FINAL 2.2.5 December 2005 BeOS boot failure fix in the PCI IDE code 2.3.5 September 2007 [1500216] Bochs fails to boot BeOs CD Hmm actually, I begin to think it just doesn't like booting from a partition image directly. The fact the bootloader lists the volume misleads into thinking it can boot... Using the image as cdrom with a floppy image works fine. Also, the log says ...ata/0/master/0/0_0 and 0_0 is supposed to be the first partition, which of course doesn't exist (and thus has a size of 0...), the whole block device should have been .../raw instead. I suppose I've been way too used to Haiku being able to boot this way. Those images were meant to be used in a FAT or ext2 partition, not straight away as disk images, unlike in Haiku. I suppose it was just too obvious :^) François.
