| |
| |
| |
|
Page: 1 2 3 4
Comments:
<0> hi whurley
<1> hi
<2> moin hint whurley iamlost
<0> whurley: if you want to discuss, it is possible now (although not for a long time)
<1> hint: no worries, I'll send you an email and we can chat that way :)
<0> ok
<3> moin nox-
<4> i have qemu installed on HOST freebsd 6.1, and im trying to install a guest freebsd 6.1 from the boot-only.iso. I only have ssh access, and no xserver. How do i redirect the output to the tty im on?
<4> current command line is : qemu -cdrom ../ender/6.1-RELEASE-i386-bootonly.iso -boot d dns.harddrive -nographic -serial stdio -monitor stdio
<4> i get the (qemu) prompt, but no output
<5> Configure your guest to use a serial console.
<5> Or use the vnc server.
<4> will the vns server work before the guest OS is even booted up correctly? aka from the bios?
<5> yes.
<4> hmm, il try that, thank you pbrook
<4> I do not understand the display option. -vnc display. should that be /dev/tty something, or an IP?
<5> It should be the vnc display number. Same as with any other VNC server.
<4> holy ****
<4> thats pretty slick
<4> windows -> tightvnc client -> freebsd host -> qemu on freebsd boot.iso
<0> pbrook: I commited a somewhat simplified clock handling where the host syscall is used when the devices ask the time. I hope the performance will still be good
<6> hint: you could just test for presence of _POSIX_MONOTONIC_CLOCK definition
<0> malc_: I will tyr
<0> try
<6> that's what docs tell.. your solution is more bulletproof (IF you add check that errno is EINVAL)
<0> malc_: finally I decided to try to use a syscall to get the clock (pbrook was also suggesting it). The current clock logic is close to what we will get with the virtual cycle counter
<0> malc_: maybe a configure check for librt will be needed
<6> hint: libcall, nobody tells you how rt timers are implemented :)
<6> it would also be cool that the old behavior could be used with a switch.. just for convenience sake
<0> malc_: on my system _POSIX_MONOTONIC_CLOCK is defined to 0 and MONOTONIC_CLOCK is not available
<0> malc_: If the performance is too bad with the new clock system I will add the dynamic TSC freq estimation
<5> We'll want teh dynamic estimation code for the virtual TSC anyway.
<5> I think there's value if having a mode that uses an adaptive virtual TSC.
<6> hint: it's 0 = not available :)
<5> #if, not #ifdef.
<0> pbrook: the question is should I leave the current code for the 0.8.2 release
<6> anyone here succeeded in installing debian with ppc or sparc emulation?
<0> malc_: I think Jocelyn Mayer succeeded on ppc
<0> malc_: another problem related to the timers is the cpu_interrupt() threading issue
<5> I think ppc works if you can persuade it to boot. IIRC you need a special kenrel that works around firmware bugs.
<5> And I remember someone on the list saying they got parc to install.
<5> s/parc/sparc/
<6> i got through half of the install process but then it started throwing errors
<0> with 2.4.x kernel it works. For 2.6 kernels there may be small openfirmware issues (should be easy to solve for an openhackware hacker)
<6> hint: i just need an image for either sparc or ppc with X and ability to run it in QEMU..
<5> malc_: You can use debootstrap to install debian.
<5> If the installer is broken (whcih is often seems to be).
<6> pbrook: debootstrap?
<5> yes
<6> i don't see how having a package for PPC can help me
<0> it would be good to publish somewhere debian images with all tools so that they can be tried in QEMU and used for QEMU testing
<5> You use debootstrap --foreign to create a root fs, then boot that, using -kernel if neccy.
<5> hint: In my experience OHW is slightly broken for 2.4 kernels, and very broken for 2.6 kenels :-)
<0> pbrook: I only tried it on old Linux distributions
<0> pbrook: since OHW does not include the Forth interpreter, one must look at the Forth strings every OS sends to it
<5> IIRC it botched the initrd setup for 2.4 PREP kernels, nothing else even got that far.
<0> pbrook: (and PearPC does the same !)
<0> for PREP kernels the problem may be different
<0> as they usually don't rely on the OpenFirmware tree
<5> Boo. sparc network is still broken.
<0> the lance device is broken ?
<5> Something is broken. Dunno if it's the hw or the bios.
<0> BTW I find very impressive that BlueSwirl managed to get OpenBIOS to work so well for sparc
<5> Yeah.
<5> It makes me wonder if we shouldn't do the same thing for ppc.
<0> jwessel said he wanted to try
<5> It does seem a much better long-term solution than OHW.
<0> yes
<0> OHW should be used to get the tree (Mac OS X is _very_ touchy about the device tree, I spent days fixing the bugs)
<2> osx progress? ;)
<0> no, but getting to the point it show the graphical interface was already very difficult
<2> ah
<0> now it should be much easier to make it work correctly
<2> why?
<0> anyone is against threads in QEMU ? They will be difficult to avoid to achieve better performance and to ease win32 porting
<5> Depends how much you care about older systems. linuxthreads is fairly ****y.
<7> howdy, bbl after reading the FAQs
<6> hint: threads for what?
<0> Provided it works on my RedHat 9 it is OK :-)
<6> pbrook: debootstrap fetched stuff, and then died trying to chroot or something
<5> malc_: Like I said, you need to specify --foreign.
<0> malc_: A thread might be used to handle the select() of the main loop
<0> malc_: and another thread to handle the disk I/Os
<6> pbrook: it does not have such an option
<5> malc_: You need a newer debootstrap then.
<0> malc_: so it implies there must be a thread safe way to interrupt the virtual CPU, at least on win32
<6> hint: yeah yeah, i spent countless hours on this this winter
<6> hint: though aio and or completion ports on win32 is better idea methinks
<0> malc_: I have a solution to get cpu_interrupt() thread safe but it requires the virtual cycle counter
<0> malc_: and on Linux ? Should we use aio too ?
<2> aio requires a custom kernel on freebsd iirc
<6> hint: i would vote yes.. then again i only wrote a small test thingie to get a glimpse of it
<6> hint: http://www.boblycat.org/~malc/aioex.tgz
<6> pbrook: any idea where to find this "newer" debootstrap
<0> not relying on threads also means using SIGIO for socket I/Os (the current select() code does polling in fact)
<5> malc_: packages.debian.org
<0> malc_: thank you for the code. It seems to work on my Linux distrib
<6> integrates nicely with signals which what attracted me
<0> problem: the block devices would be difficult to modify to use aio
<6> why whould it be any harder than with plain threads?
<0> with plain threads I can just use the existing code (a patch was published some time ago)
<6> qemu_concurrent_io?
<0> I don't remember its name
<5> What's different about aio?
<6> aio pros: a. lighter/cleaner(ugly parts in kernel or libc) b. does not reuire synchronization primitives
<6> aio cons: not available on windows (unlike pthreads-win32)
<2> more aio cons: requires a custom kernel on freebsd
<2> iirc
<5> malc_: I'm fairly sure windows has some sort of asynchronous IO functionality. I don't remember the details though, and don't have a clue how aio works.
<6> pbrook: look at the example i posted to hint, and sure windows has aio (completion ports, overalapped io)
<6> i was suggesting that the same implementation wouldnt work on both platforms
<6> nox-: my linux kernel does not have aio either, glibc provides an emulation.. i guess it's the same for freebsd
<6> at least man pages do not tell anything about custom kernels
<6> pbrook: okay debootstrap succeeded, what should i do now?
<2> oh, you can kldload aio it seems
<5> Surely the only thing the implementation effects is the main look and maybe a bit of the glue code.
<6> i wouldn't be so sure..
<5> I'd expect the block layer interface to be fairly similar for both.
<6> the whole problem with windows and threads so far was the lack of ability to send a signal to the main thread
<5> aio doesn't help that does it?
<6> it does
<5> How?
<6> you tell it to fire a signal on completion
<6> instead of invokinga threaded callback
<5> What sort of signal?
<6> i dont understand the question
<5> I didn't think windows did signals at all.
<6> pbrook: have you looked at the code? it does just that in 86 lines
<6> i think we are mixing terms here
<5> IIRC you have two options with windows async IO. The completion routines either get run in a different thread or they are run syncronously at sync points (eg. WaitForEvent).
<0> yes, on windows using threads is not avoidable
<5> And we obviously can interrupt the main thread because we do it for timer interrupts.
<6> that works only on uniprocessors for obvious reasons
<0> on windows I think the main thread is not interrupted. IMHO the timer alarm is ran in another thread
<6> hint: right
<5> malc_: I'm fairly sure we fixed the win32 SMP bugs a whle ago.
<6> pbrook: nope
<0> and so cpu_interrupt() is called in another thread which gives instabilities
<0> even on Linux cpu_interrupt is broken, but the occurences of brokenness are "rare enough"
<5> Really?
<6> Jari Kimppa wrote a workaround launcher that sets the affinities so that the timer thread always runs on the same core with the main thread
<6> hence thing "work"
<6> Komppa
<6> pbrook: uh.. once again, debootstrap completed, any hints of what i should do now?
<5> Err, well, if it completed, you're done.
<0> for example, doing: "env->interrupt_request |= mask;" is not safe
<5> Wedget the FS onto an image and boot away.
<6> pbrook: mkimage; mkext2fs; cpio; boot?
<5> If you want.
<2> gnite
<0> bye
Return to
#qemu
or
Go to some related
logs:
flaucinaucihilipilification
#gentoo
gnomemachine linux
authorized_submit_users
#php
No module named Tkinter gentoo
sed escape forward slashes
adelfino google
compiz-settings gentoo
gentoo jokes
|
|