[9fans] lguest port broken due to some change in last 6 months; any ideas?
There were a number of changes in the kernel last 6 months, I just recently did a pull and the lguest port is screwed. I spent part of today fixing things and catching up, and am now stuck in the first taskswitch. Symptoms are odd. It dies in the first call to gotolabel. But here is the output from some prints: mmuswitch done return to 0xc01508de port/proc.c goto label c0470008 (pc c01013b3, sp c0059778) That pc is init0; the SP is good, previously allocated in newproc(). Next line after this is from lguest program. Lguest says this: lguest: Bad address 0xc0012c01 (gpte 01008200) The gpte is the pte that the lguest kernel code found for that address. eh? c0012c01? It makes not a lot of sense, that's not word aligned, as it should be for accesses to cpu0pdb. And ... it dies in gotolabel here: TEXT gotolabel(SB), $1 MOVLlabel+0(FP), AX MOVL0(AX), SP /* restore sp */ MOVL4(AX), AX /* put return pc on the stack */ MOVLAX, 0(SP) MOVL$1, AX /* return 1 */ DIE DIE DIE RET as determined by me putting calls to lguest crash, line by line. Yep, it dies on an immediate move to AX. I'm thinking I'm overwriting code somehow. Anybody has ideas on how to debug this, let me know. I've had lots of weird problems on these lguest ports but this one takes the cake. oh yeah I have fixed the port with the new bits in memory.c, l.s, etc. for handling 8 MB of initial mappings. ron
Re: [9fans] I/O load crashes Qemu
On Sat, Jun 14, 2008 at 1:58 AM, Bruce Ellis <[EMAIL PROTECTED]> wrote: > I don't know how the praise of "excellent" was bestowed on QEMU. It > may work well on a x86 emulating an x86 but try something else. It > ends in tears. > just like opening up an x86 machine and trying to stick a mips processor inside. at the end of the day you get qemu-mips. iru
Re: [9fans] I/O load crashes Qemu
I don't know how the praise of "excellent" was bestowed on QEMU. It may work well on a x86 emulating an x86 but try something else. It ends in tears. brucee
Re: [9fans] I/O load crashes Qemu
On Fri, 13 Jun 2008 20:39:48 EDT erik quanstrom <[EMAIL PROTECTED]> wrote: > > On a T42 running FreeBSD, a stock FreeBSD-4.11/qemu gets > > 18MB/s & plan9/qemu gets 3MB/s. Both tested by writing 100MB > > from /dev/zero to a file. Neither needs any special drivers. > > > > I think part of the performance problem is qemu emulates an > > early Intel ATA controller chip (PIIX3) and perhaps plan9 > > does not do certain optimizations. It would not be too hard > > to emulate a more modern controller. > > try turning dma on. it is very unlikely that plan 9 is missing some > important ata optimization. Already tried. echo 'dma on' > /dev/sdC0/ctl doesn't make any difference in performance. > > IMHO a virtualizable processor is the necessary first step as > > it clears one's mind about what not to do in an efficient > > virtualizable IO architecture! > > unless you are contemplating a processor with i/o instructions, > what does the processor have to do with i/o architecture? Just that if you have no incentive to virtualize IO, you are unlikely to think about making it efficient. > i find there's a certain simplicty in dealing directly > with hardware, provided one has documentation. Provided it is complete and the h/w well designed and interface regular. Unfortunately not all that common. > but just wait, there will come a day when people complain > about the nasty registers in vm and how it would be good to > abstract that stuff out. Ha! First we have to get there.
Re: [9fans] I/O load crashes Qemu
> On a T42 running FreeBSD, a stock FreeBSD-4.11/qemu gets > 18MB/s & plan9/qemu gets 3MB/s. Both tested by writing 100MB > from /dev/zero to a file. Neither needs any special drivers. > > I think part of the performance problem is qemu emulates an > early Intel ATA controller chip (PIIX3) and perhaps plan9 > does not do certain optimizations. It would not be too hard > to emulate a more modern controller. try turning dma on. it is very unlikely that plan 9 is missing some important ata optimization. > IMHO a virtualizable processor is the necessary first step as > it clears one's mind about what not to do in an efficient > virtualizable IO architecture! unless you are contemplating a processor with i/o instructions, what does the processor have to do with i/o architecture? > Emulating grotty device > registers with horrible side-effects is just too painful and > one would be forced to abstract that out. Probably too late > for that! i find there's a certain simplicty in dealing directly with hardware, provided one has documentation. but just wait, there will come a day when people complain about the nasty registers in vm and how it would be good to abstract that stuff out. i think that may have been yesterday. - erik
Re: [9fans] I/O load crashes Qemu
On Fri, 13 Jun 2008 19:52:22 EDT erik quanstrom <[EMAIL PROTECTED]> wrote: > > You don't need this sort of code in a virtualizable processor. > > See for example > > http://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualization_requiremen > ts > > i'm not convinced that the illusion that the virtualized environment > is in every way equivalent to the bare iron is always useful or worth > the effort. why should a virtualized operating system need to worry > about what nic the machine has? Well the URL was more to get the point across. Whether your virtual OS uses simplified virtual devices or emulated real devices, you shouldn't have to emulate each instruction in software! I won't argue with "worth the effort" but it can be useful (e.g. running dusty decks, debugging etc). My argument is more that real device intefaces should be designed to make virtualization efficient. > for example vmware doesn't provide this sort of virtualized environment. > it provides the same virtual network card interface regardless of > what hardware the machine has. It is doable but it took them years to get there and provide good efficiency. May be even more years that VM/370?!
Re: [9fans] command line tool for storing / reading files on venti
> BTW: still leaves the problem that lot's of vacfs servers are > started not terminated after use :( no, it doesn't. on plan 9, when the shell script exits, nothing will have vacfs mounted anymore, so vacfs will get an eof on the 9p connection and exit. that's why i put an rfork n in the script. > Well, this doesnt seem to run this way on p9p :( true. i thought you were using plan 9, sorry. if you are using linux and have fuse installed, you can still run something like the script, as long as you are willing to run just one at a time. vacfs -m /vac file.vac cp -R /vac/* . unmount /vac would work, assuming you create a /vac that you have write permission to. you can only run one at a time since there is only one /vac. russ
Re: [9fans] command line tool for storing / reading files on venti
* Russ Cox <[EMAIL PROTECTED]> wrote:
> > The venti/read and venti/write commands just support single blocks.
> > Vac seems fine as archive tool, but it only can store - I need some
> > "unvac" command. (mounting each single archive via vacfs is a bit
> > too complicated for my project).
>
> I'm hesitant to bother replying, as we learned earlier that
> your idea of complicated does not match established norms.
>
> That said, here is an (untested) unvac command:
>
> #!/bin/rc
> if(! ~ $#* 2){
> echo 'usage: unvac file.vac directory'
> exit 1
> }
> rfork n
> vacfs $1 || exit
> mkdir -p $2 || exit
> dircp /n/vac $2
Well, this doesnt seem to run this way on p9p :(
BTW: still leaves the problem that lot's of vacfs servers are
started not terminated after use :(
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666
--
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--
Re: [9fans] I/O load crashes Qemu
> Any good recommended lecture to learn about good virtualization? i think this is an interesting approach. note that some code runs faster under the vx32 than natively, though the title seems to hint that there are varying definitions of virtualization. http://swtch.com/~rsc/papers/vx32-usenix2008.pdf > I imagine that the biggest issue is to avoid a racing condition > between the two(or 'n') running kernels. two different kernels can't race as they share no resources. in the hypervisor, races can be taken care of with the same techniques that work on any other multithreaded program. so, if performance is not an issue, a single threaded hypervisor could schedule any number of guests. then there are no locking problems at all. > Then... Would it be very hard to build an fs that allows to share real > hardware with another kernel running alongside plan 9? I imagine that > the so called hypervisors are kind of a "(exo-)scheduler" this is already possible. any number of plan 9 cpu servers may share a single fileserver. no virtualization needed. > You don't need this sort of code in a virtualizable processor. > See for example > http://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualization_requirements i'm not convinced that the illusion that the virtualized environment is in every way equivalent to the bare iron is always useful or worth the effort. why should a virtualized operating system need to worry about what nic the machine has? for example vmware doesn't provide this sort of virtualized environment. it provides the same virtual network card interface regardless of what hardware the machine has. - erik
Re: [9fans] I/O load crashes Qemu
On Sat, Jun 14, 2008 at 1:42 AM, Lorenzo Fernando Bivens de la Fuente > FPGA's are getting cheaper. A friend of mine got a nice Spartan III > for less than us$50 > > Clock speeds are still behind the usual ASIC (lack of sleep might > alter my grammar habilities), but I think they are ok for things like > a java vm, or a nes emulator... Ever heard of 'Dis on a Chip'? http://groups.google.com/group/dis-on-a-chip uriel
Re: [9fans] I/O load crashes Qemu
FPGA's are getting cheaper. A friend of mine got a nice Spartan III
for less than us$50
Clock speeds are still behind the usual ASIC (lack of sleep might
alter my grammar habilities), but I think they are ok for things like
a java vm, or a nes emulator...
Years ago I made a picoJava based processor and it was really fun...
All we need is to put that into a PCI thing and enjoy (And it would
even be better if you can program the thing dynamically from your pc
as needed)
I also believe I've seen some SUN workstations that do have a "pci"
processor to emulate an x86 machine...
Blah... I really need to sleeep.
I hate PHP.
On 6/13/08, Pietro Gagliardi <[EMAIL PROTECTED]> wrote:
> On Jun 13, 2008, at 7:01 PM, Bakul Shah wrote:
>
>
> > IMHO a virtualizable processor is the necessary first step as
> >
>
>
> And don't forget the cost of a virtualizer v. the cost of actual hardware.
> Verilog is free, but the device to make it is not. Start simple:
>
> void
> main(int, char *[])
> {
> while(readbyte()){
> parseinst();
> doinst();
> }
> exits(nerrs ? "error" : 0);
> }
>
>
>
>
Re: [9fans] I/O load crashes Qemu
On Fri, 13 Jun 2008 19:26:42 EDT Pietro Gagliardi <[EMAIL PROTECTED]> wrote:
> On Jun 13, 2008, at 7:01 PM, Bakul Shah wrote:
>
> > IMHO a virtualizable processor is the necessary first step as
>
>
> And don't forget the cost of a virtualizer v. the cost of actual
> hardware. Verilog is free, but the device to make it is not. Start
> simple:
>
> void
> main(int, char *[])
> {
> while(readbyte()){
> parseinst();
> doinst();
> }
> exits(nerrs ? "error" : 0);
> }
?
You don't need this sort of code in a virtualizable processor.
See for example
http://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualization_requirements
Re: [9fans] I/O load crashes Qemu
On Jun 13, 2008, at 7:01 PM, Bakul Shah wrote:
IMHO a virtualizable processor is the necessary first step as
And don't forget the cost of a virtualizer v. the cost of actual
hardware. Verilog is free, but the device to make it is not. Start
simple:
void
main(int, char *[])
{
while(readbyte()){
parseinst();
doinst();
}
exits(nerrs ? "error" : 0);
}
Re: [9fans] I/O load crashes Qemu
On Fri, 13 Jun 2008 21:33:15 BST Charles Forsyth <[EMAIL PROTECTED]> wrote: > >perhaps qemu-ide specific drivers need to be done. > > Many hosted OSs need custom made drivers to > > be used with a virtualizer. On a T42 running FreeBSD, a stock FreeBSD-4.11/qemu gets 18MB/s & plan9/qemu gets 3MB/s. Both tested by writing 100MB from /dev/zero to a file. Neither needs any special drivers. I think part of the performance problem is qemu emulates an early Intel ATA controller chip (PIIX3) and perhaps plan9 does not do certain optimizations. It would not be too hard to emulate a more modern controller. > i must say that my experience with VM/370 was otherwise, > for the standard devices. there were extensions you could access > if you liked, but the basic emulation was solid. the only restriction i reme > mber > was that you couldn't any longer dynamically modify channel programs > (by having a channel program read some blocks into memory that would > later be executed in the same channel program), but other systems > imposed a similar restriction on that hardware. > > the peculiar thing about the modern virtualisers/hypervisors etc is that > they require specialised drivers but are no easier (often harder) to drive th > an > actual hardware! it's all gone wrong! I don't think you can escape writing device emulation code for the virtualization layer (when the guest os diddles a device register, someone has to implement its semantics). If the emulated device is not the same as some real device, the guest os has to have a special drivers for it. IMHO a virtualizable processor is the necessary first step as it clears one's mind about what not to do in an efficient virtualizable IO architecture! Emulating grotty device registers with horrible side-effects is just too painful and one would be forced to abstract that out. Probably too late for that!
Re: [9fans] I/O load crashes Qemu
Any good recommended lecture to learn about good virtualization? I imagine that the biggest issue is to avoid a racing condition between the two(or 'n') running kernels. Then... Would it be very hard to build an fs that allows to share real hardware with another kernel running alongside plan 9? I imagine that the so called hypervisors are kind of a "(exo-)scheduler" A not very educated guess... On 6/13/08, erik quanstrom <[EMAIL PROTECTED]> wrote: > > the peculiar thing about the modern virtualisers/hypervisors etc is that > > they require specialised drivers but are no easier (often harder) to drive > than > > actual hardware! it's all gone wrong! > > > but the blinding performance is ... check that. > > > - erik > > >
Re: [9fans] command line tool for storing / reading files on venti
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Since you mention using vac for storage, I assume you're using venti > directly, not via fossil, in which case the '9fs dump' suggestion will > do nothing for you. ACK. > I don't believe there is anything in Plan 9 that does what you want > (certainly the BUGS section in venti(1) implies not), but you might > look at vcat in p9p. It's not quite there - it seems to demand that > you're working with only a single file, rather than directory trees > (possibly containing only a single file) as vac creates - but does the > redirection and may be close to what you want. Yes, that sounds good, but fails with: ./vcat: diskopenventi: not a single file Well, if I now just find the opposite - uploading a file - I'll be happy :) cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [9fans] command line tool for storing / reading files on venti
> The venti/read and venti/write commands just support single blocks.
> Vac seems fine as archive tool, but it only can store - I need some
> "unvac" command. (mounting each single archive via vacfs is a bit
> too complicated for my project).
I'm hesitant to bother replying, as we learned earlier that
your idea of complicated does not match established norms.
That said, here is an (untested) unvac command:
#!/bin/rc
if(! ~ $#* 2){
echo 'usage: unvac file.vac directory'
exit 1
}
rfork n
vacfs $1 || exit
mkdir -p $2 || exit
dircp /n/vac $2
Russ
Re: [9fans] Plan 9 Terminal Target
Talking of cheap machines ... Does anyone know anything about the Elonex One? http://elonexone.co.uk/ It's ~USD200. I'm getting a couple anyway for other reasons, but if they could be used to do something 9ish as well, that would be a bonus. I'll start looking at running 9 on it ASAP of course, but any shoulders to stand on would be useful. DaveL Another good cause! I'm cycling 50 miles from London to Brighton to support the British Heart Foundation. http://www.justgiving.com/davelukes-brighton-bikride
Re: [9fans] command line tool for storing / reading files on venti
I don't think so. 9fs dump gives you everything afaik. On Jun 13, 2008, at 4:29 PM, Enrico Weigelt wrote: * Pietro Gagliardi <[EMAIL PROTECTED]> wrote: 9fs dump command /n/dump//mmdd/absolutepathtofile but this still requires me to mount each single vac archive before reading, and I need to create a new one for each upload, right ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [9fans] I/O load crashes Qemu
> the peculiar thing about the modern virtualisers/hypervisors etc is that > they require specialised drivers but are no easier (often harder) to drive > than > actual hardware! it's all gone wrong! but the blinding performance is ... check that. - erik
Re: [9fans] command line tool for storing / reading files on venti
* Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > 9fs dump > command /n/dump//mmdd/absolutepathtofile but this still requires me to mount each single vac archive before reading, and I need to create a new one for each upload, right ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [9fans] I/O load crashes Qemu
>perhaps qemu-ide specific drivers need to be done. > Many hosted OSs need custom made drivers to > be used with a virtualizer. i must say that my experience with VM/370 was otherwise, for the standard devices. there were extensions you could access if you liked, but the basic emulation was solid. the only restriction i remember was that you couldn't any longer dynamically modify channel programs (by having a channel program read some blocks into memory that would later be executed in the same channel program), but other systems imposed a similar restriction on that hardware. the peculiar thing about the modern virtualisers/hypervisors etc is that they require specialised drivers but are no easier (often harder) to drive than actual hardware! it's all gone wrong!
Re: [9fans] I/O load crashes Qemu
> the peculiar thing about the modern virtualisers/hypervisors etc is that sorry. i meant to write "one peculiar thing ...", because there are others.
Re: [9fans] command line tool for storing / reading files on venti
Since you mention using vac for storage, I assume you're using venti directly, not via fossil, in which case the '9fs dump' suggestion will do nothing for you. I don't believe there is anything in Plan 9 that does what you want (certainly the BUGS section in venti(1) implies not), but you might look at vcat in p9p. It's not quite there - it seems to demand that you're working with only a single file, rather than directory trees (possibly containing only a single file) as vac creates - but does the redirection and may be close to what you want. Anthony
Re: [9fans] I/O load crashes Qemu
In fact it is definetly not a plan9 issue... If qemu fails hosting plan 9, it affects plan 9 but there is little to be done unless we communicate with the qemu dev team. Plan 9 is not the only os having problems with DMA access through qemu. I am myself a moron... All I know is that the issue exists, I don't know why... (But it would be very appreciated if an explanation is given) One thing I've thought several times is that perhaps qemu-ide specific drivers need to be done. Many hosted OSs need custom made drivers to be used with a virtualizer. I am sure a lot has been discused about this on the list. I'll try to do a quick scan about it later. On 6/13/08, Bakul Shah <[EMAIL PROTECTED]> wrote: > > Everything, in my experience, crashes QEMU. Nice try. > > > Just the opinion of me and my dog (who barks loudly when I shout > > f**king QEMU - piece of f**king sh*t!). > > > I have used qemu/freebsd for the past 4 years or so. On the > whole it has worked quite well. I often use plan9, Windows > 2000 and freebsd under qemu for hours on end. Juergen Lock > has done an excellent job on making sure qemu+kqemu continue > to work on freebsd but he has needed feedback from > qemu/freebsd users. > > If you plan on continuing with qemu it might be worth asking > on the qemu-devel mailing list or #qemu on freenode as I > don't think any qemu dveloper follows 9fans. But they will > need details like the host OS and version, qemu version, > command line used, exact symptoms, steps to repeat the > problem etc. > >
Re: [9fans] command line tool for storing / reading files on venti
9fs dump command /n/dump//mmdd/absolutepathtofile -> year mmdd -> month and date On Jun 13, 2008, at 3:50 PM, Enrico Weigelt wrote: Hi folks, is there any command line tool for reading and writing files on venti ? The venti/read and venti/write commands just support single blocks. Vac seems fine as archive tool, but it only can store - I need some "unvac" command. (mounting each single archive via vacfs is a bit too complicated for my project). cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
[9fans] command line tool for storing / reading files on venti
Hi folks, is there any command line tool for reading and writing files on venti ? The venti/read and venti/write commands just support single blocks. Vac seems fine as archive tool, but it only can store - I need some "unvac" command. (mounting each single archive via vacfs is a bit too complicated for my project). cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [9fans] I/O load crashes Qemu
> Everything, in my experience, crashes QEMU. Nice try. > Just the opinion of me and my dog (who barks loudly when I shout > f**king QEMU - piece of f**king sh*t!). I have used qemu/freebsd for the past 4 years or so. On the whole it has worked quite well. I often use plan9, Windows 2000 and freebsd under qemu for hours on end. Juergen Lock has done an excellent job on making sure qemu+kqemu continue to work on freebsd but he has needed feedback from qemu/freebsd users. If you plan on continuing with qemu it might be worth asking on the qemu-devel mailing list or #qemu on freenode as I don't think any qemu dveloper follows 9fans. But they will need details like the host OS and version, qemu version, command line used, exact symptoms, steps to repeat the problem etc.
Re: [9fans] Plan 9 Terminal Target
Looks like the same Geode motherboard as as this one http://www.sumotech.com/english/hardware/st166_overview.php This one comes with foundry linux based thin client s/w on internal CF. I got one to try about 18 months ago. Quite a nice little box, but won't replace my NCD X-Term till I get NAS audio working on it... Havn't tried it for Plan9 compatability yet. Regards, DigbyT On Fri, Jun 13, 2008 at 10:12:57AM -0400, Michaelian Ennis wrote: > At 280 USD this seemed like a nice Plan 9 terminal or native inferno target. > > http://www.linutop.com/ > > Ian -- Digby R. S. Tarvin digbyt(at)digbyt.com http://www.digbyt.com
Re: [9fans] Plan 9 Terminal Target
On Fri Jun 13 10:14:33 EDT 2008, [EMAIL PROTECTED] wrote: > At 280 USD this seemed like a nice Plan 9 terminal or native inferno target. > > http://www.linutop.com/ > > Ian > i think that's 280 euros — over $400. the "infos" or "miscs" didn't include the ethernet chipset or the vga chipset. it's quite strange how english words tour europe and come back under a new heading. moin moin - erik
[9fans] Plan 9 Terminal Target
At 280 USD this seemed like a nice Plan 9 terminal or native inferno target. http://www.linutop.com/ Ian
Re: [9fans] Running plan 9 on a Toshiba laptop
> well, the only thing I could find using Widows Vista was: > Intel(R) 82801HEM/HBM SATA AHCI Controller > and > FUJITSU MHY2250BH are you using a very recent cd? if you can copy down any lines that look like these that pop up during the boot process and send them to me offline? #S/sdE: ahci sb600 port 0xe0022800: sss 0 ncs 31 coal 1 mports 3 led 1 clo 1 ems 0 #S/sdE: sb600: sata-II with 4 ports it would also be helpful if you could send me the output of a tool like lspci. i don't know if there's a windows equivalent. i'm most interested in the vid and did of the ahci controller. - erik
Re: [9fans] I/O load crashes Qemu
I am experiencing crashes here too. QEMU 0.9.1 with and without kqemu, using qcow2, on Linux 2.6.24. I have built QEMU from source so I can backtrace it next time it happens. Perhaps Plan 9 under lguest is the way to go. Stefan
Re: [9fans] Running plan 9 on a Toshiba laptop
well, the only thing I could find using Widows Vista was: Intel(R) 82801HEM/HBM SATA AHCI Controller and FUJITSU MHY2250BH 2008/6/11 Lorenzo Fernando Bivens de la Fuente <[EMAIL PROTECTED]>: > By disk controller I mean the chipset that handles your disk. > I believe (I've had problems myself) that many SATA controllers are > still buggy/not supported on plan 9. > > Toshiba Satellite 2800? I don't think you have the same laptop. That > 2800 was a "single core" computer. 2800s are a whole series of laptops > 2800-500 would be a > celeron based one, etc... (I am asuming that is the laptop you are > talking about because it is the only toshiba listed on the "previously > on plan 9" section) > > Get the output from lspci on lunix or some other utility on windows or > whatever your usual poison is. > > Suerte. > > On Wed, Jun 11, 2008 at 11:12 AM, hugo rivera <[EMAIL PROTECTED]> wrote: >> There are no error messages at all, it just freezes in the DMA >> question, before I answer anything. >> My laptop is listed in the wiki as: "worked in previous releases and >> may work in the current one". >> I have a SATA disk, is that what you mean by disk controller? >> >> Gracias por tu ayuda >> >> Hugo >> >> 2008/6/10 Lorenzo Fernando Bivens de la Fuente <[EMAIL PROTECTED]>: >>> Hola! >>> >>> Any error message? >>> What is your disk controller? >>> Have you read the wiki? Is it supported? >>> >>> Does it freeze whether you choose to use DMA or not? >>> >>> éxito! >>> >>> >>> >>> On Tue, Jun 10, 2008 at 3:51 PM, hugo rivera <[EMAIL PROTECTED]> wrote: Hi: I downloaded the plan 9 iso image a couple of days ago. I just burned it and booted in a Toshiba with an intel Core2 Duo, with a sata hard drive. When I just run plan 9, without installing it, everything runs ok, but when I choose the install option, it starts loading and the freezes in the "use dma" question. Any clues? Saludos Hugo >>> >> >
Re: [9fans] I/O load crashes Qemu
On Thu, Jun 12, 2008 at 9:54 PM, Venkatesh Srinivas <[EMAIL PROTECTED]> wrote: > Hi, > > I currently use Plan 9 in qemu 0.9.1; whenever I try to do anything I/O > demanding such as unpacking a ~100MB tarball, qemu locks up and refuses > further connections (via vnc, or gdb for example). I am using fossil > alone. This behavior occurs whether kqemu is enabled or not, though it > happens a lot faster w/o kqemu. > > Has anyone else noticed anything like this? Any thoughts about running > Plan 9 in qemu? Yes, I had this problem several times while doing replica/pull yesterday. Qemu uses up all cpu load, and does not respond. Sometimes it comes back on from the lock up, while other times I lose my patience and kill it. I went back to 0.9.0. Lets see if I have the same problem. fhs
Re: [9fans] I/O load crashes Qemu
I have problems with Qemu too. Qemu hangs booting, hangs after booting, hangs ramdomly, ... with or without venti. I am using now a "new" PC for Plan9 > Everything, in my experience, crashes QEMU. Nice try. > > Just the opinion of me and my dog (who barks loudly when I shout > f**king QEMU - piece of f**king sh*t!). > > Hey, this is off topic but ... anyone had fun with a Asus EeePC? The > excess stock are being sold in Oz and I got a 4G for US$300. Tho Amzon > were down to 4. Let me know off-list. > > Regards, > > The Dude With The Little Dog. > > -- Rodolfo García AKA kix http://www.kix.es/ EA4ERH (@IN80ER)
Re: [9fans] I/O load crashes Qemu
Everything, in my experience, crashes QEMU. Nice try. Just the opinion of me and my dog (who barks loudly when I shout f**king QEMU - piece of f**king sh*t!). Hey, this is off topic but ... anyone had fun with a Asus EeePC? The excess stock are being sold in Oz and I got a 4G for US$300. Tho Amzon were down to 4. Let me know off-list. Regards, The Dude With The Little Dog.
Re: [9fans] I/O load crashes Qemu
On Fri, Jun 13, 2008 at 12:00 PM, Venkatesh Srinivas <[EMAIL PROTECTED]> wrote: > I've tried with both qcow2 and raw; raw takes longer to get to a crash, > but still reliably crashes. Strangely, connecting to qemu with gdb > before Plan 9 starts reduces the crash rate a lot, but it might just be > because the world is noticeably slower... Does it actually crash or just hang? Maybe you just need to wait for the I/O to drop before it will accept connections again? -sqweek
