From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 1 Feb 2008 08:14:53 +0000 To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] Serious Problem Running Plan 9 on Virtual PC From: "Eris Discordia" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: Content-Transfer-Encoding: Quoted-Printable Message-ID: In-Reply-To: User-Agent: Opera Mail/9.23 (Win32) Topicbox-Message-UUID: 3ec2fa6e-ead3-11e9-9d60-3106f5b1d025 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=3Ddata 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/o= r = 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/