[9fans] Virtual PC + Win64 = i/o errors

[9fans] Virtual PC + Win64 = i/o errors

[Benjamin Huntsman]

I recently switched to Windows XP x64 Edition on my two 64-Bit x86 systems.  Ever since, I've had trouble with Virtual PC, where I run a couple of Plan 9 VMs.  I was wondering if anyone has seen similar issues:

I copied over a virtual machine from a 32-bit host, where it was running happily.  I also get the same errors during the install process, just after it tries to format the fossil.  Below are the relevant messages from the boot process:

...
fossil(#S/sdC0/fossil)...version...time...
command 30
data f0caaaf8 limit f0cab8f8 dlen 8291 status 0 error 0
lba 605536 -> 605536, count 16 -> 16 (16)
 0x00 0x06 0x6A 0x3D 0x09 0xE0 0x58
0x40: E307 0x42: C0000x48: 00
0x4A: 0000
fossil: diskWriteRaw failed: /dev/sdC0/fossil: score 0x00005529: date Sun Apr 5
 06:37:19 PDT 2009
 part=data block 21801: i/o error
...

I get several subsequent messages that say basically the same thing, with different block numbers, but the machine never finishes booting.
Has anyone seen anything similar?  Is this a Plan 9 bug, Windows x64 bug, or Virtual PC x64 bug?

Many thanks in advance!

-Ben

Re: [9fans] Virtual PC + Win64 = i/o errors

[erik quanstrom]

> fossil(#S/sdC0/fossil)...version...time...
> command 30
> data f0caaaf8 limit f0cab8f8 dlen 8291 status 0 error 0
> lba 605536 -> 605536, count 16 -> 16 (16)
>  0x00 0x06 0x6A 0x3D 0x09 0xE0 0x58
> 0x40: E307 0x42: C0000x48: 00
> 0x4A: 0000
> fossil: diskWriteRaw failed: /dev/sdC0/fossil: score 0x00005529: date Sun Apr 5
>  06:37:19 PDT 2009
>  part=data block 21801: i/o error

did you type in this by hand?  i'm wondering about the
"dlen = 8291".  that should be 8192.

the device driver claims you owe him data
after doing 10 sectors.  but you would have given
him another sector, had you gotten an interrupt.

so the question is, why did you get the first 9 interrupts
and not get the 10th?

§9.1 #4 p. 64, ata 7 vol 2 says it should, but if you read
a little further it can deassert the interrupt if the
command register is written.

it's really hard to say anything useful without seeing
this problem up close.  a rather desperate guess might
be that this is a pio timing thing.  (note that this is
presented as an intel pci ide chipset.  there must be
a reason those registers are printed out for intel parts.)
if it is, then dma mode from the get-go could fix the
problem.

is this an ahci-capable chipset?  or is virtual pc presenting
something odd?

- erik

Re: [9fans] Virtual PC + Win64 = i/o errors

[Benjamin Huntsman]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

>> fossil(#S/sdC0/fossil)...version...time...
>> command 30
>> data f0caaaf8 limit f0cab8f8 dlen 8291 status 0 error 0
>> lba 605536 -> 605536, count 16 -> 16 (16)
>>  0x00 0x06 0x6A 0x3D 0x09 0xE0 0x58
>> 0x40: E307 0x42: C0000x48: 00
>> 0x4A: 0000
>> fossil: diskWriteRaw failed: /dev/sdC0/fossil: score 0x00005529: date Sun Apr 5
>>  06:37:19 PDT 2009
>>  part=data block 21801: i/o error
>
>did you type in this by hand?  i'm wondering about the
>"dlen = 8291".  that should be 8192.

Yes, I typed it in by hand from the Virtual PC screen.  
You're right, I transposed the numbers.  Sorry about that.

I don't know what else to say, I don't really understand the error or what
the codes mean.

I don't know if VPC is ahci-compatable.  The disks show up as regular IDE, not SATA,
though my host is SATA-based...  But still, VPC is supposed to hide such things from the guest.

According to the docs, Virtual PC presents an Intel 440BX chipset.

>dma mode from the get-go could fix the problem.

How exactly would I enable that on an already-installed VM?  Would a modified plan9.ini on a floppy
image do the trick?

Many thanks!

-Ben

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 3152 bytes --]

Re: [9fans] Virtual PC + Win64 = i/o errors

[erik quanstrom]

> How exactly would I enable that on an already-installed VM?
> Would a modified plan9.ini on a floppy
> image do the trick?

unfortunately, there's no *justusedma=1 plan9.ini option.  that
would be far to easy.

i think you will need to modify the kernel to make progress.
do you have a way of compiling kernels?  or at least sticking a new
kernel into 9fat?

- erik

Re: [9fans] Virtual PC + Win64 = i/o errors

[Benjamin Huntsman]

[-- Attachment #1: Type: text/plain, Size: 168 bytes --]

>do you have a way of compiling kernels?

Sure do!  The original copy of the same VM in question still runs fine on it's original host...

Thanks much!!

-Ben


[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2364 bytes --]

Re: [9fans] Virtual PC + Win64 = i/o errors

[erik quanstrom]

> fossil(#S/sdC0/fossil)...version...time...
> command 30
> data f0caaaf8 limit f0cab8f8 dlen 8291 status 0 error 0
> lba 605536 -> 605536, count 16 -> 16 (16)
>  0x00 0x06 0x6A 0x3D 0x09 0xE0 0x58
> 0x40: E307 0x42: C0000x48: 00
> 0x4A: 0000
> fossil: diskWriteRaw failed: /dev/sdC0/fossil: score 0x00005529: date Sun Apr 5
>  06:37:19 PDT 2009
>  part=data block 21801: i/o error

many thanks to bhuntsman for having the patience to put up
with my crappy code.

it turns out that this is due to some poor timing on the part of
virtual pc.  virtual pc asserts an interrupt while the virtual controller
is busy.  then virtual pc refuses to reassert the interrupt, though the
condition is not handled.  this problem only hapens in pio mode.

(it just occurs to me in writing this up that i had not considered that
this might be an edge vs. level irq problem.  and i'm ignorant enough
of virtual pc to not even know if that's a stupid idea or not.)

in any event, replacing the big tsleep with a loop of smaller tsleeps
and checking for missed irqs seems to help pio commands.  i also
added a kernel variable to plan9.ini, sdXXdma=on.  that might be
overkill, but i was worried about fossil/venti needing to do a lot of
disasterously slow i/o before cpurc/termrc gets a chance to run.
i'd like to hear if anyone finds that this is necessary.

one thing that is not yet done is a similar approach with packet io.
i'd like to test it with actual hardware rather than guessing.

what i've got so far is on sources in the contrib package quanstro/sd.

i'd like to hear if this works (or doesn't) for anybody else.

- erik