[9fans] Serious Problem Running Plan 9 on Virtual PC - Plan9

This is a discussion on [9fans] Serious Problem Running Plan 9 on Virtual PC - Plan9 ; Hi there, I've recently installed the Plan 9 system from the live/install disc image at http://www.tip9ug.jp/mirror/plan9.iso.bz2 . I have no particular use for it but am eager to learn about a new OS (barring Windows and UNIX/UNIX-likes). To avoid dual-booting ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: [9fans] Serious Problem Running Plan 9 on Virtual PC

  1. [9fans] Serious Problem Running Plan 9 on Virtual PC

    Hi there,

    I've recently installed the Plan 9 system from the live/install disc image
    at
    http://www.tip9ug.jp/mirror/plan9.iso.bz2. I have no particular use for it
    but
    am eager to learn about a new OS (barring Windows and UNIX/UNIX-likes).

    To avoid dual-booting and in the absence of a (retired) PC to run Plan 9
    on I
    decided to use Microsoft Virtual PC, which I've been using for a while to
    run
    FreeBSD 6.2-Release without any problems.

    Now, the live system boots and functions properly on VPC. The installation
    also
    proceeds without any errors and finishes OK. However, when I reboot the VM
    to
    get the installed system running it fails.

    I've read all I could find, but no one seems to have had the same problem
    on
    VPC. I also tried the method described here:

    http://groups.google.mn/group/comp.o...d55830f8cd4a95

    Which I do not understand, by the way. It seems to be checking the fossil
    filesystem for errors. In my case, the status report stopped at around 4%
    of
    the blocks and it would not go any further, even after 45 minutes. While
    the
    first 4% was checked in roughly 2 minutes.

    Thanks in advance.

    VM details:

    Microsoft Virtual PC 2007 v6.0.156.0 on Windows XP x64
    128 MB RAM allotted to the VM
    8 GB VHD (tried both fixed-size and sparse options)

    VHD layout: single active plan9 slice -> 9fat, nvram, fossil, swap
    Boot method: Plan 9 MBR

    Error details:

    MBR...PBS1...
    ..
    ..
    ..
    ELCR: 0800
    128M memory: 53M kernel data, 74M user, 299M swap
    root is from (tcp, local)[local!#S/sdC0/fossil]: (I accept the default)
    user[none]: glenda

    time...
    fossil(#S/sdC0/fossil)...version...time...

    init: starting /bin/rc
    (long, almost 5 minute, pause here)
    command 30
    data f07613b0 limit f07263b0 dlen 8192 status 0 error 0
    lba 231760 -> 231760, count 16 -> 16 (16)
    0x00 0x07 0x59 0x89 0x03 0xE0 0x58
    0x40: E307 0x42: C0000x48: 00
    0x4A: 0000
    fossil: diskWriteRaw failed: /dev/sdC0/fossil: score 0x00000006: date Thu
    Jan
    31 16:45:44 EST 2008
    part=data block 6: i/o error

    (the above fossil error repeats indefinitely with different score, block,
    etc
    numbers)

    (boot process goes no further than that)

  2. Re: [9fans] Serious Problem Running Plan 9 on Virtual PC

    > (long, almost 5 minute, pause here)
    > command 30
    > data f07613b0 limit f07263b0 dlen 8192 status 0 error 0
    > lba 231760 -> 231760, count 16 -> 16 (16)
    > [0] 0x00 0x07 0x59 0x89 0x03 0xE0 0x58

    data err lba lba lba lba obs Status
    > 0x40: E307 0x42: C0000x48: 00
    > 0x4A: 0000
    > fossil: diskWriteRaw failed: /dev/sdC0/fossil: score 0x00000006: date Thu
    > Jan
    > 31 16:45:44 EST 2008
    > part=data block 6: i/o error
    >


    quick reparse of the data you've given. ata command 0x30 (write
    sectors) timed out after 1 minute at lba 231760 which is safely under
    8GB. the status (register 7) is 0x58 which is
    0x08 Drq /* waiting on your data */
    0x10 Serv
    0x40 Drdy

    but the lba read back (assuming it's correct) is 231769. so some
    progress has been made -- indicating we're getting some interrupts,
    but somehow we've missed one and stalled out.

    the real problem is that data > limit by 236kb. i'm not sure how this
    could happen. something looks very wrong.

    - erik


  3. Re: [9fans] Serious Problem Running Plan 9 on Virtual PC

    On Fri, 01 Feb 2008 02:37:12 -0000, erik quanstrom
    wrote:

    >> (long, almost 5 minute, pause here)
    >> command 30
    >> data f07613b0 limit f07263b0 dlen 8192 status 0 error 0
    >> lba 231760 -> 231760, count 16 -> 16 (16)
    >> [0] 0x00 0x07 0x59 0x89 0x03 0xE0 0x58

    > data err lba lba lba lba obs Status
    >> 0x40: E307 0x42: C0000x48: 00
    >> 0x4A: 0000
    >> fossil: diskWriteRaw failed: /dev/sdC0/fossil: score 0x00000006: date
    >> Thu
    >> Jan
    >> 31 16:45:44 EST 2008
    >> part=data block 6: i/o error
    >>

    >
    > quick reparse of the data you've given. ata command 0x30 (write
    > sectors) timed out after 1 minute at lba 231760 which is safely under
    > 8GB. the status (register 7) is 0x58 which is
    > 0x08 Drq /* waiting on your data */
    > 0x10 Serv
    > 0x40 Drdy
    >
    > but the lba read back (assuming it's correct) is 231769. so some
    > progress has been made -- indicating we're getting some interrupts,
    > but somehow we've missed one and stalled out.
    >
    > the real problem is that data > limit by 236kb. i'm not sure how this
    > could happen. something looks very wrong.
    >
    > - erik
    >


    First of all, lots of thanks for taking the time to help.

    Then, I really understand very little, if any, of computer hardware and/or
    systems programming. Given that, I dare ask a naive question: Could the
    problem be because of running a "32-bit virtual machine" on a "64-bit OS?"

    The version of VPC I am using is supposed to be 64-bit. Microsoft's
    website says so. And the 32-bit version I had would not even install on
    Windows XP x64. In spite of these facts, Windows task manager adds a *32
    to the image name of the VPC process which effectively means it is a
    32-bit process running in compatibility mode. The emulated machines are
    surely 32-bit.

    On the other hand, my (32-bit) FreeBSD installation is running prefectly
    OK on this same platform.

    Right now, I think one way to test any ideas is for me to boot into the
    live system and somehow try to access the virtual hard disk. I would be
    grateful if someone would instruct me on any diagnostic procedures and/or
    various access methods from the live system. Things equivalent to the
    UNIX/Linux mount, mkfs, and fsck.

    --
    Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

  4. Re: [9fans] Serious Problem Running Plan 9 on Virtual PC

    > First of all, lots of thanks for taking the time to help.

    you're welcome.

    > Then, I really understand very little, if any, of computer hardware and/or
    > systems programming. Given that, I dare ask a naive question: Could the
    > problem be because of running a "32-bit virtual machine" on a "64-bit OS?"


    likely not. i think it is more likely a bug in the vm or a bug in plan 9.
    (that really narrows it down, doesn't it?)

    > Right now, I think one way to test any ideas is for me to boot into the
    > live system and somehow try to access the virtual hard disk. I would be
    > grateful if someone would instruct me on any diagnostic procedures and/or
    > various access methods from the live system. Things equivalent to the
    > UNIX/Linux mount, mkfs, and fsck.


    it's not clear that simple io to your virtual disk works. you could
    open a window in the installer and use
    ; cat /dev/sdctl
    to give you information on this disks in your system. this information
    is going to be interesting. then you can try (where XX is likely C0
    on your machine)
    dd -if /dev/sdXX/data -of /dev/null -bs 8k
    if that works, then you might want to try a write test
    dd -if /dev/sdXX/data -bs 512k |
    dd -of /dev/sdXX/data -bs 8k
    this may destroy your installed image.

    if any of these steps barf, you may want to fiddle with the dma
    settings on sdXX:
    dmaon

    - erik


  5. Re: [9fans] Serious Problem Running Plan 9 on Virtual PC

    On Fri, 01 Feb 2008 12:34:14 -0000, erik quanstrom
    wrote:

    > ; cat /dev/sdctl
    > to give you information on this disks in your system. this information
    > is going to be interesting. then you can try (where XX is likely C0
    > on your machine)
    > dd -if /dev/sdXX/data -of /dev/null -bs 8k
    > if that works, then you might want to try a write test
    > dd -if /dev/sdXX/data -bs 512k |
    > dd -of /dev/sdXX/data -bs 8k
    > this may destroy your installed image.
    >
    > if any of these steps barf, you may want to fiddle with the dma
    > settings on sdXX:
    > dmaon
    >
    > - erik
    >


    A "cat /dev/sdctl" gives:

    sdC ata port 1F0 ctl 3F4 irq 14
    sdD ata port 170 ctl 374 irq 15

    A "cat ctl" in /dev/sdC0 gives:

    inquiry Virtual HD
    config 045A capabilities 0F00 dma 00000004 dmactl 00000000 rwm 16 rwmctl0
    geometry 16777152 512 16644 16 63
    part data 0 16777152
    part plan9 63 16771860
    part 9fat 63 204863
    part nvram 204863 204864
    part fossil 204864 15723284
    part swap 15723284 16771860

    Doing "9fat:" and then "cat /n/9fat/plan9.ini" gives:

    bootfile=sdC0!9fat!9pcf
    bootargs=local!#S/sdC0/fossil
    bootdisk=local!#S/sdC0/fossil

    #*noahciload=1
    *debugload=1
    *nobiosload=1
    *nodumpstak=1
    *nomp=1
    dmamode=ask (but it asks me nothing, probably it never gets to that point)
    partition=new
    mouseport=ps2
    monitor=xga
    vgasize=640x480x8

    I tried changing dmamode from "ask" to "off." No use.

    Then, did this according to the newsgroup entry I linked to in my first
    post:

    fossil/fossil -c 'srv -p fscons'
    con /srv/fscons
    prompt: srv -AWP replica
    prompt: fsys main config /dev/sdC0/fossil
    prompt: fsys main open -AWP
    warning: connecting to venti: cs: can't translate address: '/srv/dns' file
    does not exist
    prompt: fsys main
    main: check fix

    The above ought to verify at least two things:

    1. The disk is indeed readable.
    2. The fossil partition is OK.

    Result is:

    checking epoch 1...
    check: visited 1/968226 blocks (0%)
    check: visited 9683/968226 (1%)
    [it freezes here and the green hdd indicator in VPC's status line shows no
    activity after around 20 minutes]

    I have noticed an eccentricity: when the live system boots, it boots from
    #S/dev/sdD0/data but the installed system boots from #S/dev/sdC0/fossil.I
    tried changing that to #S/dev/sdC0/data, but then the boot process
    complains that it cannot find /boot/kfs and stops.

    --
    Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

  6. Re: [9fans] Serious Problem Running Plan 9 on Virtual PC

    >
    > I have noticed an eccentricity: when the live system boots, it boots from
    > #S/dev/sdD0/data but the installed system boots from #S/dev/sdC0/fossil. I
    > tried changing that to #S/dev/sdC0/data, but then the boot process
    > complains that it cannot find /boot/kfs and stops.


    that's because you boot from a (virtual?) cdrom during the install process.
    typically this is sdD0. when you boot from the normal system, you boot
    from the virtual hard drive, sdC0. the super special el torito process
    makes a cdrom appear differently when its booted from than when
    it's just accessed normally.

    - erik


  7. Re: [9fans] Serious Problem Running Plan 9 on Virtual PC

    I have no knowledge to debug your problem. Anyway some tips:

    >From my own experience dealing with OS in virtual environments, be sure that the

    RAM memory for the virtual OS is not more than the half of the physical memory.

    If you have plenty of physical memory to spare, have you tried on
    giving more to the virtual OS?

    --
    Fidonet: 2:345/432.2

  8. Re: [9fans] Serious Problem Running Plan 9 on Virtual PC

    On Fri, 01 Feb 2008 15:43:36 -0000, erik quanstrom
    wrote:

    >>
    >> I have noticed an eccentricity: when the live system boots, it boots
    >> from
    >> #S/dev/sdD0/data but the installed system boots from
    >> #S/dev/sdC0/fossil. I
    >> tried changing that to #S/dev/sdC0/data, but then the boot process
    >> complains that it cannot find /boot/kfs and stops.

    >
    > that's because you boot from a (virtual?) cdrom during the install
    > process.
    > typically this is sdD0. when you boot from the normal system, you boot
    > from the virtual hard drive, sdC0. the super special el torito process
    > makes a cdrom appear differently when its booted from than when
    > it's just accessed normally.
    >
    > - erik
    >


    I see, thanks for the explanation. I suppose then, that #S/dev/sdC0/fossil
    is perfectly OK for booting from.

    With this situation at hand, and the bag of nasty little tricks empty, I
    think the better option is to either try another virtualization/emulation
    solution (I gave up on Bochs x86 emulator just a few minutes ago, it was
    too unstable and slow for my purpose) or get a used hard drive for that
    little old PC sitting in the corner of my room.

    --
    Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

  9. Re: [9fans] Serious Problem Running Plan 9 on Virtual PC

    On Fri, 01 Feb 2008 17:07:12 -0000, Juan M. Mendez
    wrote:

    > I have no knowledge to debug your problem. Anyway some tips:
    >
    >> From my own experience dealing with OS in virtual environments, be sure
    >> that the

    > RAM memory for the virtual OS is not more than the half of the physical
    > memory.
    >
    > If you have plenty of physical memory to spare, have you tried on
    > giving more to the virtual OS?
    >


    Both issues have been take care of. I have 1 GB of physical memory, of
    which 128 MB has been given to that particular VM; less than half the
    physical. I also tried increasing that to 384 MB, still no improvement.

    --
    Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

  10. Re: [9fans] Serious Problem Running Plan 9 on Virtual PC

    > With this situation at hand, and the bag of nasty little tricks empty, I
    > think the better option is to either try another virtualization/emulation
    > solution (I gave up on Bochs x86 emulator just a few minutes ago, it was
    > too unstable and slow for my purpose) or get a used hard drive for that
    > little old PC sitting in the corner of my room.


    if you run linux vblade (on sourceforge), you can use that as your disk.
    vblade is a software aoe target. not very fast, but requires only ethernet.

    the main trick would be configuring the drive.
    this can be done with the following commands:

    ; bind -a '#æ' /dev
    ; echo bind /net/ether0>/dev/aoe/ctl
    ; echo config switch on spec e type aoe//dev/aoe/2.0 >/dev/sdctl
    # creates /dev/sde0.

    - erik


+ Reply to Thread