Hello list,
Attached is a rediff of the virtual ohci host controller developed by Gianni
Tedesco. The primary changes are a fix in the handling of the HcFmInterval
register so that the host controller driver toggles the Frame Interval Toggle
bit instead of the host controller. This was cau
Not exactly...
As many Apple fans can tell you, apple just love to stick their own
ROM in there machines (I think it's called open firmware these days).
Since your own PC doesn't have this ROM (and I imagine they'll add
couple of tricks more to the package) - you won't be able even to
install OS X
I am sorry, it was a personal mail to stefano.
Unfortunately I have chosen the wrong "reply".
There is nothing secret in it, and the mail reveals (in Italian) what's
going on in the FreeosZoo management.
We want to provide a Bit-Torrent version of the images to have more
effective download ser
Stefano:
Nella prima pagina: Software e' un "uncountable" in Inglese e quindi
suppondo che softwares sia errato (al massimo metti software packages o
lascia al singolare).
Vorrei dare anche servizio a Bit-Torrent. Nella macchina che ospita
lo zoo i pacchetti per il supporto di Torrent dovrebbero
On Thu, Jun 09, 2005 at 12:31:18AM +0200, Jan Marten Simons wrote:
> > Not quite, but TFTP by protocol design limits filesize to 2^16-1 blocks
> > of 512 bytes or 32 MB minus 512 bytes (33553920 bytes).
>
> Well, if this is the case FTP should realy be added as an alternative
> protocol.
>
> And
Stefano;
Also, I see that you are doing the Windows daily cvs builds again!
That's good to see... Thanks Stefano. Thanks Ronald.
As for the forum...
Obviously there are still some issues (for example, language issues), but I
think most people will still prefer the qemu forum at
http://m2.d
Hello everybody. I just want to inform you that I've set up a forum for
the FreeOsZoo!
Check at http://www.freeoszoo.org for more news.
Stefano
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
> Not quite, but TFTP by protocol design limits filesize to 2^16-1 blocks
> of 512 bytes or 32 MB minus 512 bytes (33553920 bytes).
Well, if this is the case FTP should realy be added as an alternative
protocol.
And the more I think about vvFAT, the more I think it's too complex to get
this worki
> I am using kqemu and qemu built from May 2 snapshot if that
> matters. This was a stock 5.4-RELEASE complied locallly
> with
>
> makeoptionsDEBUG=-g
>
> added the kernel config file. The host was also running 5.4
> but that should not matter.
Ugh... Should've done a diff with GENER
Hmm... I've used qemu a bit to debug the kernel. Even used
it to debug a loadable module. Here is what I did:
# qemu -s img
# cd
# gdb kernel.debug
(gdb) target remote localhost:1234
...
(gdb) l kldload
739 /*
740 * MPSAFE
741 */
742 int
743 kldload(struct thread *td, stru
On Mon, Jun 06, 2005 at 04:54:25PM -0700, John R. Hogerhuis wrote:
> I can think of some reasons for a non-native file service that is
> instead built into QEMU:
>
>
> -- John.
>
I agree with you there, especially for non-networked OS support. A qemu-specific
guest program will take in a file
Pierre has asked me to maintain the OS X package.
I will glady take this task.
To keep things simple for enduser, I plan to make packages for the cocoa
flavour of qemu. If You think there should also a sdl package, please
inform me.
Layout of the Package:
Container: QEMU-0.7.x.dmg (compresse
On Tue, Jun 07, 2005 at 01:38:14AM +0200, Jan Marten Simons wrote:
> > Like I said, modifying TFTP for R/W would be a good option. It's already
> there,
> > the "miminalists" can't complain about having it removed (e.g. it may
> one day
> > be used to support "virtual" netboots), and one can use ft
On Tue, Jun 07, 2005 at 11:45:40PM +0200, Henrik Nordstrom wrote:
> On Mon, 6 Jun 2005, Jim C. Brown wrote:
>
> >Hmm...what if you don't have root/administrator access? It could still
> >work if
> >you are determined enough, but thats not the sort of thing you want to
> >force
> >onto a beginner
Hello,
We have tried to use qemu for debugging of kernel-level code the same way we
used
bochs in past.
The qemu whether with or without kqemu is quite fast for our needs. The gdb
connects
to guest just fine, however breakpoints break things and qemu stops working.
Our guest OS is FreeBSD 5.3
On Wed, 8 Jun 2005, Christian MICHON wrote:
this is the location of my mistake: I did "get w" instead of "get /q/w"
now it works in "get" mode only.
Good.
Is there anywhere a patch to get rw
access to tftp
As already said the TFTP server is currently read-only, however
implementing write
I made some progress based on your suggestions :)
> I don't have any to test on, but the code is extremely simple and not OS
> dependeng in any manner except the small detail that UNIX style paths must
> be used.
>
> Where is the file on the host?
c:\q\w
>
> What tftp argument did you gave to
Hi,
On Wed, 8 Jun 2005, Henrik Nordstrom wrote:
> On Tue, 7 Jun 2005, John R. Hogerhuis wrote:
>
> Updates in the other direction is harder however, unless vvfat is changed
> to emulate a floppy with floppy change notification and the guest has
> support for changing floppy "at random".
The supp
On Wed, 8 Jun 2005, Christian MICHON wrote:
I used 3 ways, either valid with msys or dos shell.
all fail :(
I can ping 10.0.2.2 perfectly, I even tried as administrator inside a dos
prompt.
Good.
the file I'm trying to get inside the guest is barely 58 bytes long
Anyone ever got tftp to wor
On Tue, 7 Jun 2005, John R. Hogerhuis wrote:
For the kind of thing I'm referring to is not usually very time
critical. The resolution is on the order of 15 to 30 minutes to an
hour... some stores get polled for data, the accounting system imports
the data and generates some reports which feed in
20 matches
Mail list logo
