From 8cee055ec4fac00e59f19620ab06e2b30dccee3c Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 11 Jul 2012 22:39:59 +0200 Subject: IRC. --- microkernel/mach/gnumach/memory_management.mdwn | 35 ++++++++++++++++++------- 1 file changed, 26 insertions(+), 9 deletions(-) (limited to 'microkernel/mach/gnumach') diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn index ca2f42c4..c630af05 100644 --- a/microkernel/mach/gnumach/memory_management.mdwn +++ b/microkernel/mach/gnumach/memory_management.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,9 +8,12 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!tag open_issue_documentation]] +[[!tag open_issue_documentation open_issue_gnumach]] -IRC, freenode, #hurd, 2011-02-15 +[[!toc]] + + +# IRC, freenode, #hurd, 2011-02-15 etenil: originally, mach had its own virtual space (the kernel space) @@ -37,14 +40,15 @@ IRC, freenode, #hurd, 2011-02-15 lage - pages without resetting the mmu often thanks to global pages, but that didn't exist at the time) -IRC, freenode, #hurd, 2011-02-15 + +# IRC, freenode, #hurd, 2011-02-15 however, the kernel won't work in 64 bit mode without some changes to physical memory management and mmu management (but maybe that's what you meant by physical memory) -IRC, freenode, #hurd, 2011-02-16 +## IRC, freenode, #hurd, 2011-02-16 antrik: youpi added it for xen, yes antrik: but you're right, since mach uses a direct mapped kernel @@ -52,9 +56,7 @@ IRC, freenode, #hurd, 2011-02-16 which isn't required if the kernel space is really virtual ---- - -IRC, freenode, #hurd, 2011-06-09 +# IRC, freenode, #hurd, 2011-06-09 btw, how can gnumach use 1 GiB of RAM ? did you lower the user/kernel boundary address ? @@ -82,7 +84,7 @@ IRC, freenode, #hurd, 2011-06-09 RAM to fill the kernel space with struct page entries -IRC, freenode, #hurd, 2011-11-12 +# IRC, freenode, #hurd, 2011-11-12 well, the Hurd doesn't "artificially" limits itself to 1.5GiB memory @@ -102,3 +104,18 @@ IRC, freenode, #hurd, 2011-11-12 kernel space is what determines how much physical memory you can address unless using the linux-said-awful "bigmem" support + + +# IRC, freenode, #hurd, 2012-07-05 + + hm i got an address space exhaustion while building eglibc :/ + we really need the 3/1 split back with a 64-bits kernel + 3/1? + 3 GiB userspace, 1 GiB kernel + ah + the debian gnumach package is patched to use a 2/2 split + and 2 GiB is really small for some needs + on the bright side, the machine didn't crash + there is issue with watch ./slabinfo which turned in a infinite + loop, but it didn't affect the stability of the system + actually with a 64-bits kernel, we could use a 4/x split -- cgit v1.2.3 From d72694b33a81919368365da2c35d5b4a264648e0 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 12 Jul 2012 13:54:25 +0200 Subject: hurd/running/qemu/writeback_caching: New. --- contributing.mdwn | 6 +- hurd/running/debian/qemu_image.mdwn | 4 +- hurd/running/gnu/create_an_image.mdwn | 4 +- hurd/running/qemu.mdwn | 14 +++-- hurd/running/qemu/babhurd_image.mdwn | 3 +- hurd/running/qemu/discussion.mdwn | 96 +----------------------------- hurd/running/qemu/microsoft_windows.mdwn | 13 ++-- hurd/running/qemu/writeback_caching.mdwn | 90 ++++++++++++++++++++++++++++ microkernel/mach/gnumach/ports/xen.mdwn | 4 +- open_issues/gnumach_page_cache_policy.mdwn | 3 + open_issues/qemu_writeback.mdwn | 18 ------ unsorted/MakeImage.mdwn | 2 +- 12 files changed, 122 insertions(+), 135 deletions(-) create mode 100644 hurd/running/qemu/writeback_caching.mdwn delete mode 100644 open_issues/qemu_writeback.mdwn (limited to 'microkernel/mach/gnumach') diff --git a/contributing.mdwn b/contributing.mdwn index 97ae450b..2f786e9f 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008, 2009, 2010, 2011 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2006, 2007, 2008, 2009, 2010, 2011, 2012 Free +Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -146,7 +146,7 @@ I'll have to think about it some more. * Install qemu-kvm via your distros packages. * Download the [qemu image](http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz): `wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz` * Unpack it: `tar xf debian-hurd.img.tar.gz` -* Run it: `qemu-kvm debian-hurd.img -m 512 -no-kvm-irqchip` # …irq… is a currently necessary fix due to some changes in Linux. Optionally use `--curses` to keep your keyboard layout. If need be modprobe kvm_amd, kvm intel and kvm to get kvm support (which is much, much faster). See also: [kvm FAQ](http://www.linux-kvm.org/page/FAQ). +* Run it: `qemu-kvm -m 512 -no-kvm-irqchip -drive cache=writeback,index=0,media=disk,file=debian-hurd.img` # …irq… is a currently necessary fix due to some changes in Linux. Optionally use `--curses` to keep your keyboard layout. If need be modprobe kvm_amd, kvm intel and kvm to get kvm support (which is much, much faster). See also: [kvm FAQ](http://www.linux-kvm.org/page/FAQ). * login as root * `apt-get update` * `apt-get install -y git mercurial emacs vim` diff --git a/hurd/running/debian/qemu_image.mdwn b/hurd/running/debian/qemu_image.mdwn index 19b371c1..de1027b7 100644 --- a/hurd/running/debian/qemu_image.mdwn +++ b/hurd/running/debian/qemu_image.mdwn @@ -15,7 +15,9 @@ Usage: $ wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz $ tar -xz < debian-hurd.img.tar.gz - $ qemu -m 512 -net nic,model=rtl8139 -net user -hda debian-hurd-*.img + $ qemu -m 512 -net nic,model=rtl8139 -net user -drive cache=writeback,index=0,media=disk,file=$(echo debian-hurd-*.img) + +See the discussion about [[hurd/running/qemu/writeback_caching]]. Just in case you were wondering: the *root* password is *root*. diff --git a/hurd/running/gnu/create_an_image.mdwn b/hurd/running/gnu/create_an_image.mdwn index 8784a826..98af99eb 100644 --- a/hurd/running/gnu/create_an_image.mdwn +++ b/hurd/running/gnu/create_an_image.mdwn @@ -18,7 +18,7 @@ Creating a bootable qemu image from a root filesystem and bootloader 2. Use a live CD (better to have a lighter OS like system rescue CD to make the process faster) and the image created to boot. - qemu -m 512 -cdrom /dev/cdrom -hda -boot d + qemu -m 512 -cdrom /dev/cdrom -drive cache=writeback,index=0,media=disk,file= -boot d 3. Once system is booted use a partition editing tool (like fdisk, cfdisk, parted, gparted, qtparted ...) to partition the image. @@ -65,7 +65,7 @@ Creating a bootable qemu image from a root filesystem and bootloader 11. Run qemu to boot into your brand new system - qemu -m 512 -hda -fda grub.img -boot a + qemu -m 512 -drive cache=writeback,index=0,media=disk,file= -fda grub.img -boot a Happy Hacking !! diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index b64c576f..512ea602 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -12,6 +12,8 @@ License|/fdl]]."]]"""]] This page discusses things for [[Unix]] systems, there is a separate page for [[Microsoft_Windows]] systems. +See the discussion about [[hurd/running/qemu/writeback_caching]]. + # Readily Available Images You can use the following images to give the GNU/Hurd a try. @@ -29,7 +31,7 @@ volunteers and may not have been tested extensively. * [Disk image](http://draketo.de/dateien/hurd/bab-hurd-qemu-2008-10-29.img.tar.bz2) with a short intro on translators. Just start it with `qemu -m 512 - disk_image.img`. + -drive cache=writeback,index=0,media=disk,file=disk_image.img`. It should work without any of the configuration below. If you want to know what you can do with it, please have a look at [[its_wikipage|hurd/running/qemu/babhurd_image]]. And when you use it, please [tell me your experience with it](http://draketo.de/contact)! - [[community/weblogs/ArneBab]] @@ -125,7 +127,7 @@ First off you will need to create a disk image using `qemu-img`. I have set mine Next you will want to start up QEMU and begin the installation process. - $ qemu -m 512 -hda hd0.img -cdrom mini.iso -net nic,model=rtl8139 -net user + $ qemu -m 512 -drive cache=writeback,index=0,media=disk,file=hd0.img -cdrom mini.iso -net nic,model=rtl8139 -net user Now at his point do the regular install using `hd0` as your harddrive. Partition it and install the base system. @@ -175,7 +177,7 @@ Also see another text about how to [[gnu/create_an_image]] for the Starting qemu/qemu-kvm: - $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -hda hd0.img -vga vmware + $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -drive cache=writeback,index=0,media=disk,file=hd0.img -vga vmware vmsvga_value_write: guest runs Linux. Note: See below on port forwarding in the networking section. @@ -273,7 +275,7 @@ This is the recommended way to work with a Command Line Interface (CLI) since al a) with ssh (assuming you have installed openssh-server) - $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -hda hd0.img & + $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -drive cache=writeback,index=0,media=disk,file=hd0.img & Logging in to the running Hurd: @@ -290,7 +292,7 @@ Copying files: b) with telnet (assuming you have installed a telnet server, like telnetd) - $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5556-:23 -hda hurd-install.qemu & + $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5556-:23 -drive cache=writeback,index=0,media=disk,file=hurd-install.qemu & Logging in to the running Hurd: @@ -331,7 +333,7 @@ Now it is time to start-up your QEMU Hurd system and get networking going in the **Important:** Remember you may need to use the `-M isapc` or `-isa` flag if using an older version of the gnumach package. - $ qemu -m 512 -hda hd0.img -cdrom debian-K9-hurd-i386-CD1.iso -fda floppy.img -boot a -net nic -net tap + $ qemu -m 512 -drive cache=writeback,index=0,media=disk,file=hd0.img -cdrom debian-K9-hurd-i386-CD1.iso -fda floppy.img -boot a -net nic -net tap Once you have logged in as `root` run the `pfinet` translator with values that apply to your network. Think of your QEMU client as another computer in your network. diff --git a/hurd/running/qemu/babhurd_image.mdwn b/hurd/running/qemu/babhurd_image.mdwn index 855e8f51..6a3bb30e 100644 --- a/hurd/running/qemu/babhurd_image.mdwn +++ b/hurd/running/qemu/babhurd_image.mdwn @@ -6,7 +6,8 @@ What this little Hurd image can do This is the README file accompanying a [disk\_image](http://draketo.de/dateien/hurd/bab-hurd-qemu-2008-10-29.img.tar.bz2) for [[running the GNU/Hurd via qemu|hurd/running/qemu]]. To run the disk image, -just use `qemu -m 512 disk_image.img`. +just use `qemu -m 512 -drive +cache=writeback,index=0,media=disk,file=disk_image.img`. You can find the custom *.bashrc* used to tell the user about it as well as this text itself in the Mercurial repository [hurd_intro](http://bitbucket.org/ArneBab/hurd_intro). diff --git a/hurd/running/qemu/discussion.mdwn b/hurd/running/qemu/discussion.mdwn index 1ce14b01..facb8a31 100644 --- a/hurd/running/qemu/discussion.mdwn +++ b/hurd/running/qemu/discussion.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011 Free -Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 +Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -50,95 +50,3 @@ The problem is actually that the linux block cache doesn't make any consistency between /dev/hda and /dev/hda6, so if you give /dev/hda to qemu, qemu writings won't be consistent with mounting /dev/hda6 in linux. You can give /dev/hda6 directly to qemu and it will be fine. - - -# Host-side Writeback Caching - -IRC, freenode, #hurd, 2011-06-07 - - hm, i guess i should have used cache=writeback with kvm before - starting the debian installer :/ - ah yes, much better - this shows how poor the state of our I/O drivers and subsystem is - :/ - indeed... still no clustered pageout :-( - and no I/O scheduler either - although an I/O scheduler has limited value without clustered - pageouts - since one of its goals is to pack related I/O requests together eh - i wonder if the wiki mentions using cache=writeback to speed up - qemu performances - it would help those unable to use kvm a lot - and even those running kvm too - kvm -m $RAM \ -monitor stdio \ -drive - cache=writeback,index=0,media=disk,file=hd0.img \ - etc.. - the idea is that qemu doesn't open its disk file synchronously - changes are queued in the host page cache before being flushed to - the disk image - but if you brutally close your qemu instance, you're likely to - loose file system consistency - ext2fs will think it has committed its metadata to the disk, but - the disk image won't be updated synchronously - on my machine (which is quite fast), my kvm has installed debian - like 10 times faster than without the option - braunr: I don't think killing qemu should hurt in this - case... probably only matters when the host machine dies - antrik: ah yes, right - it really makes everything faster, even downloading, since I/O - requests aren't interleaved between networking RPCs - regarding I/O sheduler... this discussion came up before, but I - don't remember the outcome -- doesn't the glued Linux driver actually - come with one? - i don't remember either - braunr: err... I don't think interleaving has anything to do with - it... I guess it's simply the fact that downloading writes the result to - disk, which suffers from lacking clustered pageout like everything else - (my internet connection is too slow though to notice :-) ) - well, if there is no I/O during downloading, downloading is faster - :) - -IRC, freenode, #hurd, 2011-06-08 - - youpi: does xen provide disk caching options ? - through a blktap, probably - ok - -([[microkernel/mach/gnumach/ports/Xen]], *Host-side Writeback Caching*.) - - we should find the pages mentioning qemu on the wiki and add the - options to enable disk image caching - it really makes the hurd run a lot faster - as a workaround for emulators until I/O is reworked, ofc - -IRC, freenode, #hurd, 2011-06-09 - - braunr recommends to use writeback caching with kvm. Is this - really recommended with the frequent crashes I experience? - provided that you terminate your kvm normaly (i.e. quitting it, not - killing it), there should be no difference - I think the host's stability is what matters - the data presumably sits in linux's cache even if qemu dies - violently - But the freezes I see force me to kill kvm :-( - maybe kvm doesn't even do caching indeed, I don't know - gnu_srs: you can quit even when frozen - use the console - (the kvm console) - gnu_srs, "Writeback caching will report data writes as completed - as soon as the data is present in the host page cache. This is safe as - long as you trust your host. If your host crashes or loses power, then - the guest may experience data corruption." (from the qemu manpage) - -IRC, freenode, #hurd, 2011-06-11 - - braunr: If you are online. For me setting the parameters -drive - cache=writeback,index=0,media=disk,file=hd0.img does not show any speed - improvement at all compared to the default. - gnu_srs: what's your complete qemu command line ? - kvm -m 1024 -net nic,model=rtl8139 -net - user,hostfwd=tcp::5556-:22 -drive - cache=writeback,index=0,media=disk,file=hd0.img -cdrom netinst.iso - what qemu version ? - qemu-kvm 0.14.1+dfsg-1: Sorry, I cannot be online until - tomorrow again. diff --git a/hurd/running/qemu/microsoft_windows.mdwn b/hurd/running/qemu/microsoft_windows.mdwn index 832b4bef..e2c8636c 100644 --- a/hurd/running/qemu/microsoft_windows.mdwn +++ b/hurd/running/qemu/microsoft_windows.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2012 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] Welcome, This document is for getting you started in a few minutes. @@ -46,7 +47,5 @@ Welcome, This document is for getting you started in a few minutes. ## QEmu Image Hangs on Boot The Debian GNU/Hurd K16 QEmu image hangs during the boot process. You may have better luck by converting the image to qcow format - ..\qemu-0.9.0-x86\qemu-img.exe convert debian-hurd-k16-qemu.img -O - qcow debian-hurd-k16-qemu.qcow - ..\qemu-0.9.0-x86\qemu.exe -L ..\qemu-0.9.0-x86 -m 512 -hda - debian-hurd-k16-qemu.qcow -localtime -M pc + ..\qemu-0.9.0-x86\qemu-img.exe convert debian-hurd-k16-qemu.img -O qcow debian-hurd-k16-qemu.qcow + ..\qemu-0.9.0-x86\qemu.exe -L ..\qemu-0.9.0-x86 -m 512 -drive cache=writeback,index=0,media=disk,file=debian-hurd-k16-qemu.qcow -localtime -M pc diff --git a/hurd/running/qemu/writeback_caching.mdwn b/hurd/running/qemu/writeback_caching.mdwn new file mode 100644 index 00000000..c9c53e3e --- /dev/null +++ b/hurd/running/qemu/writeback_caching.mdwn @@ -0,0 +1,90 @@ +[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 +Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Host-side Writeback Caching"]] + +[[!tag open_issue_documentation]] + +IRC, freenode, #hurd, 2011-06-07 + + hm, i guess i should have used cache=writeback with kvm before + starting the debian installer :/ + ah yes, much better + this shows how poor the state of our I/O drivers and subsystem is + :/ + indeed... still no clustered pageout :-( + and no I/O scheduler either + although an I/O scheduler has limited value without clustered + pageouts + since one of its goals is to pack related I/O requests together eh + i wonder if the wiki mentions using cache=writeback to speed up + qemu performances + it would help those unable to use kvm a lot + and even those running kvm too + kvm -m $RAM \ -monitor stdio \ -drive + cache=writeback,index=0,media=disk,file=hd0.img \ + etc.. + the idea is that qemu doesn't open its disk file synchronously + changes are queued in the host page cache before being flushed to + the disk image + but if you brutally close your qemu instance, you're likely to + loose file system consistency + ext2fs will think it has committed its metadata to the disk, but + the disk image won't be updated synchronously + on my machine (which is quite fast), my kvm has installed debian + like 10 times faster than without the option + braunr: I don't think killing qemu should hurt in this + case... probably only matters when the host machine dies + antrik: ah yes, right + it really makes everything faster, even downloading, since I/O + requests aren't interleaved between networking RPCs + regarding I/O sheduler... this discussion came up before, but I + don't remember the outcome -- doesn't the glued Linux driver actually + come with one? + i don't remember either + braunr: err... I don't think interleaving has anything to do with + it... I guess it's simply the fact that downloading writes the result to + disk, which suffers from lacking clustered pageout like everything else + (my internet connection is too slow though to notice :-) ) + well, if there is no I/O during downloading, downloading is faster + :) + +IRC, freenode, #hurd, 2011-06-08 + + youpi: does xen provide disk caching options ? + through a blktap, probably + ok + +([[microkernel/mach/gnumach/ports/Xen]], *Host-side Writeback Caching*.) + + we should find the pages mentioning qemu on the wiki and add the + options to enable disk image caching + it really makes the hurd run a lot faster + as a workaround for emulators until I/O is reworked, ofc + +IRC, freenode, #hurd, 2011-06-09 + + braunr recommends to use writeback caching with kvm. Is this + really recommended with the frequent crashes I experience? + provided that you terminate your kvm normaly (i.e. quitting it, not + killing it), there should be no difference + I think the host's stability is what matters + the data presumably sits in linux's cache even if qemu dies + violently + But the freezes I see force me to kill kvm :-( + maybe kvm doesn't even do caching indeed, I don't know + gnu_srs: you can quit even when frozen + use the console + (the kvm console) + gnu_srs, "Writeback caching will report data writes as completed + as soon as the data is present in the host page cache. This is safe as + long as you trust your host. If your host crashes or loses power, then + the guest may experience data corruption." (from the qemu manpage) diff --git a/microkernel/mach/gnumach/ports/xen.mdwn b/microkernel/mach/gnumach/ports/xen.mdwn index 5fe73c06..c6023786 100644 --- a/microkernel/mach/gnumach/ports/xen.mdwn +++ b/microkernel/mach/gnumach/ports/xen.mdwn @@ -117,8 +117,8 @@ settrans -fgap /dev/hd0s1 /hurd/storeio -T typed part:1:device:hd0 # Host-side Writeback Caching -Optimization possible as it is with [[QEMU|hurd/running/qemu/discussion]], -*Host-side Writeback Caching*? +Optimization possible as it is with +[[QEMU|hurd/running/qemu/writeback_caching]]? IRC, freenode, #hurd, 2011-06-08 diff --git a/open_issues/gnumach_page_cache_policy.mdwn b/open_issues/gnumach_page_cache_policy.mdwn index 6f51d713..03cb3725 100644 --- a/open_issues/gnumach_page_cache_policy.mdwn +++ b/open_issues/gnumach_page_cache_policy.mdwn @@ -590,6 +590,9 @@ License|/fdl]]."]]"""]] the amount of vm_object and ipc_port is gracefully adjusted that'd help us with not having to tell people to use the complex -drive option :) + +([[hurd/running/qemu/writeback_caching]].) + so you can easily run a hurd with 128 MiB with decent performance and no leak in ext2fs yes diff --git a/open_issues/qemu_writeback.mdwn b/open_issues/qemu_writeback.mdwn deleted file mode 100644 index ab881705..00000000 --- a/open_issues/qemu_writeback.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_documentation]] - - -# IRC, freenode, #hurdfr, 2012-07-01 - - remplace "-hda file.img" par "-drive - cache=writeback,index=0,media=disk,file=file.img" - tu sentiras tout de suite la différence diff --git a/unsorted/MakeImage.mdwn b/unsorted/MakeImage.mdwn index b3485771..ff64ce46 100644 --- a/unsorted/MakeImage.mdwn +++ b/unsorted/MakeImage.mdwn @@ -53,7 +53,7 @@ I use this for testing OSKit... ## Booting Qemu - qemu -m 512 -user-net -isa -boot d -cdrom grub.iso -hda gnu.img + qemu -m 512 -user-net -isa -boot d -cdrom grub.iso -drive cache=writeback,index=0,media=disk,file=gnu.img The switch `-isa` is for current gnumach.gz on hda. -- cgit v1.2.3