Re: [Qemu-devel] Using Microsoft-provided Windows images
Hello. Yes but if I understood well, you can't boot on the SCSI device because of BIOS limitations right? So the problem remains ... :) Maybe if you install GRUB and tell him to boot on SCSI.. :) --- François. Le mercredi 01 août 2007 à 10:55 -0500, [EMAIL PROTECTED] a écrit : > on x86, qemu by default does not emulate a scsi device. > > if you look at my last set of postings, you will see a patch set for adding > scsi controllers on demand. > > its got some code formatting issues, so i understand why it hasnt been merged > as of yet. i intend to publish a new version in the next couple of days. > > Julia Longtin <[EMAIL PROTECTED]> > > On Wed, Aug 01, 2007 at 04:33:31PM +0200, GUERRAZ Francois wrote: > > Hello. > > > > Micro$oft's 64bits OSes are known to be problematic w/ kvm. > > > > I guess that the main problem w/ Qemu is that Microsoft Virtual Server > > can emulate a SCSI controller and Qemu cannot... I havent checked but I > > bet they installed their VM's with just SCSI drivers... > > Try to install IDE drivers from VM Ware and then to boot from QEMU. > > Also, try to disable ACPI (update the "computer" driver to "Standard PC" > > if available) > > > > Regards, > > > > François. > > > > Le mercredi 01 août 2007 à 23:35 +0930, Dan Shearer a écrit : > > > I have been playing around with the demonstration Windows images > > > downloadable from Microsoft just to see how hard it would be to use the > > > OSs they provide. The images are designed for Microsoft Virtual Server, > > > but can be successfully converted to qcow2 and vhdx using qemu-img. QEMU > > > won't boot the images (not a difficult problem, I think) but VMware can. > > > I'll try other free virtualisation systems at some point. > > > > > > See http://shearer.org/Microsoft_Demo_VMs for my notes so far. > > > > > > > > > > > >
[Qemu-devel] vnc improvement/bugfix patches from xen
After some issues with qemu vnc I happened upon the patches xen carries in xen-unstable.hg/tools/ioemu/patches/. After getting them to apply cleanly they have vastly improved my experience with vnc. I've taken these, omitted any that are xen specific or add extra features to qemu, and made some patches that apply cleanly to the latest qemu and kvm-33 sources. http://magoazul.com/proj/qemu/from_xen-unstable.hg_7c5c3aa858cc/ They seem to resolve the following issues for me: - having the vncviewer 4.1.2 die with: Rect too big: 4260x16389 at 4259,4323 exceeds 720x400 Aborted - having some odd stuck bits on the display when using the mouse via gdm or vim -> fixed by vnc-backoff-screen-scan/vnc-cleanup/vnc-fixes - occasionally having the vnc server go into an infinite loop thus screwing up the entire vm (verified with gdb) -> fixed by vnc-protocol-fixes - keypad not working -> fixed by vnc-keypad-handling [vnc-altgr-keysym/vnc-fix-text-display-shift-key not sure, included em anyway] Obviously I had *zero* hand in creating these patches and the original authors deserve the credit, I'm merely providing them for anyone experiencing the same issues. What I have done though is abused the patched qemu and kvm installs pretty thoroughly with vnc over the past week without issue. Also, in the course of this I read the recent 'Merging QEMU-DM upstream' slides from XenSummit by Anthony Liguori who I've seen on this list. Wondering if this is ongoing and I just duplicated some work that's already done? :) -- Matthew Kent <[EMAIL PROTECTED]> http://magoazul.com
[Qemu-devel] QEMU - windows Vista
Hi guys, I have had success using qemu + LinuxBIOS + ADLO to boot win2k and winXP but with windows vista I have no idea what the problems are. I have tried to use qemu with its normal bochs bios to boot VISTA installation DVD. I get the initial loading screen followed by a black screen ans that's it. Could you guys show me any thread or tell me if anybody has detected the problem with windows Vista? Thanks a lot, -- Augusto Pedroza
Re: [Qemu-devel] [PATCH] make /usr/bin/qemu the native arch
> Management tools for QEMU will have come to rely on existing semantics > of /usr/bin/qemu being i386. How about just deprecating it? For example, we could make /usr/bin/qemu be a script with: #!/bin/bash echo "warning: $0 is deprecated, use qemu-system-i386 instead" exec qemu-system-i386 $@ > Changing this for merely cosmetic reasons [...] It's not just cosmetic. I recall you sent me some benchmarks (too bad they didn't make it to the list, and I somehow lost that mail), but they were done on i386 (which remains unaffected). On x86_64, results are different (specially if you have setup kqemu which only works with qemu-system-x86_64). -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list.
Re: [Qemu-devel] IBM makes AIX 6 beta available for download for everyone
The correct place for these questions would be the OpenBIOS list (blatantly cross-posted). On 7/30/07, Andreas Färber <[EMAIL PROTECTED]> wrote: > > Am 19.07.2007 um 09:23 schrieb Natalia Portillo: > > > El jue, 19-07-2007 a las 00:46 +0200, Andreas Färber escribió: > >> Am 18.07.2007 um 18:26 schrieb Blue Swirl: > >> > > It looks like open hack'ware is pretty much stalled, so its hard > > telling > > what progress will be made futurewise. > > Might it be possible to replace it with OpenBIOS? > >>> > >>> Sure, and as both are GPL useful, code can be shared. But some PPC > >>> developers are needed. It may still be easier to fix the OHW bugs > >>> than > >>> start over anew. > >> > >> Not sure I understand... I thought Open Firmware was based on > >> platform independent Forth code? > >> I'm running on ppc64 and could try to compile something under Linux > >> in case that's the problem. > > Yes, OF is basically a Forth-interpreter. > > Of course this Forth-interpreter is in C and compile to machine > > code :p > > Yes, that is obvious. Not so obvious was what ppc *developers* were > needed for. > I got the other answer afterwards saying that HFS etc. support needed > to be added. > > > > Try to compile OpenBIOS under Linux/PPC (using 32bit compiler, not > > ppc64) and comment us. > > I tried SVN HEAD of both fcode-utils and openbios-devel. > > OpenBIOS supposedly has support for ppc and cross-ppc archs but that > is not true. It currently only has support for cross-ppc (for the old > PearPC emulator it seems). I copied these files as ppc_config.xml and > ppc_rules.xml respectively to get the ppc target, in ppc_rules.xml > changed the tool names to use the standard gcc etc. and was able to > compile okay. Products based on this unmodified configuration were > among others an openbios-pearpc.elf file - I thus changed ppc_rom.bin > in some ppc files to this filename. Launching qemu-system-sparc -boot > d -cdrom /dev/cdrom with a Debian Etch DVD inserted resulted in an > opcode error. My guess thus is that this OpenBIOS file is not suited > for qemu in that configuration? > > Some observations that might be of interest: > - OpenBIOS has support for some (not all) PowerPC processors > according to some Readme > - it specifically mentions ppc/AIX and has some apparent IBM > contributions despite the missing ppc target > - the cross-ppc config mentions HFS and HFSP which I guess refer to > HFS and HFS+ filesystems respectively (HFS was set to false, HFSP to > true) > > Maybe someone can shed some more light on what exactly needs to be > changed config-wise or is missing in OpenBIOS or qemu in order to > boot AIX 6 or any Linux. > > Andreas > >
Re: [Qemu-devel] PATCH 7/8: command line args for x509 cert paths
On Tue, Jul 31, 2007 at 08:54:09PM -0500, Anthony Liguori wrote: > Daniel P. Berrange wrote: > >This final code patch adds 4 new command line arguments to QEMU to allow > >the > >certificate files to be specified. The '-x509cacert', '-x509cert' and > >'-x509key' > >parameters are mandatory if the 'x509' or 'x509verify' flags are used when > >setting up the VNC server. If the certificates are not provided, all client > >authentication attempts will be rejected. > > > > It concerns me a little to add 4 new command line options. Perhaps just > supply a directory and hard code the names of each file? Then it could > even be specified as -vnc > [proto]:[,tls[,x509[:/path/to/x509/certs]]] with a > reasonable default provided. Including it as part of the main vnc arg would be nice as it'd let the admin set/change it from the monitor too. Merely specifying a directory would be fine with me - its trivial to symlink files if the admin wants to store them in some other way. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Re: [Qemu-devel] PATCH 4/8: VeNCrypt basic TLS support
On Tue, Jul 31, 2007 at 08:50:29PM -0500, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >@@ -362,6 +365,7 @@ echo " --enable-alsaenable
> > echo " --enable-alsaenable ALSA audio driver"
> > echo " --enable-fmodenable FMOD audio driver"
> > echo " --enable-dsound enable DirectSound audio driver"
> >+echo " --enable-vnc-tls enable TLS encryption for VNC server"
> > echo " --enable-system enable all system emulation targets"
> > echo " --disable-system disable all system emulation targets"
> > echo " --enable-linux-user enable all linux usermode emulation
> > targets"
> >@@ -589,6 +593,16 @@ fi # -z $sdl
> > fi # -z $sdl
> >
> > ##
> >+# VNC TLS detection
> >+if test "$vnc_tls" = "yes" ; then
> >+ `pkg-config gnutls` || vnc_tls="no"
> >+fi
> >+if test "$vnc_tls" = "yes" ; then
> >+ vnc_tls_cflags=`pkg-config --cflags gnutls`
> >+ vnc_tls_libs=`pkg-config --libs gnutls`
> >+fi
> >+
> >+##
> > # alsa sound support libraries
>
> Since it's possible to probe for gnutls support, why not just enable it
> by default and disable it if it's not available?
Sure I can make that change - I wasn't sure what people's preference for
this was so I took conservative approach of not enabling it unless it
is explicitly asked for. Happy to change it to enable by default if the
pkg-config probing succeeds, and allow a configure arg to explicitly
disable it.
> >diff -r a1fa771c6cf9 vl.c
> >--- a/vl.c Tue Jul 31 14:50:01 2007 -0400
> >+++ b/vl.c Tue Jul 31 14:50:03 2007 -0400
> >@@ -6458,7 +6458,7 @@ void main_loop_wait(int timeout)
> > if (FD_ISSET(ioh->fd, &rfds)) {
> > ioh->fd_read(ioh->opaque);
> > }
> >-if (FD_ISSET(ioh->fd, &wfds)) {
> >+if (!ioh->deleted && ioh->fd_write && FD_ISSET(ioh->fd,
> >&wfds)) {
> > ioh->fd_write(ioh->opaque);
> > }
> > }
> >
>
> I thought this was fixed already. At any rate, it should be a separate
> patch.
Sorry, this chunk wasn't supposed to be included - I'll submit it as a
separate patch.
> >+#if CONFIG_VNC_TLS
> >+ssize_t vnc_tls_push(gnutls_transport_ptr_t transport,
> >+ const void *data,
> >+ size_t len) {
> >+struct VncState *vs = (struct VncState *)transport;
> >+int ret, lastErrno;
> >
>
> s/lastErrno/last_errno/g
Ok.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Re: [Qemu-devel] PATCH 3/8: VNC password authentication
On Tue, Jul 31, 2007 at 08:46:49PM -0500, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >This patch introduces support for VNC protocols upto 3.8 and with
> >it, support for password based authentication. VNC's password based
> >authentication is not entirely secure, but it is a standard and the
> >RFB spec requires that all clients support it. The password can be
> >provided by using the monitor 'change vnc :1' and it will prompt for
> >a password to be entered. Passwords have upto 8 letters of context.
> >Pressing 'enter' without entering any characters disables password
> >auth in the server. NB, we need a custom copy of d3des here because
> >VNC uses a 'special' modification of the algorithm. This d3des code
> >is public domain & in all other VNC servers & clients.
> >
>
> I think it may be better to have a command to explicitly set the vnc
> password. Issuing "change vnc :1" just to change the password is a
> little awkward IMHO.
Ok I'll add a separate command for that - any preference for naming.
I thought about 'change vncpassword', but the 'change' command requires
2 args and we'd only have 1 here. Or if we think there may be other
devices/drivers which will have passwords in the future we could have
'change password vnc' as the command.
> >-
> >-vnc_write_u32(vs, 1); /* None */
> >-vnc_flush(vs);
> >-
> >-vnc_read_when(vs, protocol_client_init, 1);
> >+VNC_DEBUG("Client request protocol version %d.%d\n", vs->major,
> >vs->minor);
> >+if (vs->major != 3 ||
> >+(vs->minor != 3 &&
> >+ vs->minor != 7 &&
> >+ vs->minor != 8)) {
> >+VNC_DEBUG("Unsupported client version\n");
> >+vnc_write_u32(vs, VNC_AUTH_INVALID);
> >+vnc_flush(vs);
> >+vnc_client_error(vs);
> >+return 0;
> >+}
> >
>
> A very popular VNC client uses 3.5 as the protocol version. I believe
> the specification requires that 3.5 be treated at 3.3 because of that.
Good point. I'll add support for that.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Re: [Qemu-devel] Patch: let qemu work with latest bochsbios
Bernhard Kauer wrote: The boot_device is not communicated to the bochsbios through the CMOS. The following patch allows to boot via network on the newest bochsbios. Bernhard Kauer Index: vl.c === RCS file: /sources/qemu/qemu/vl.c,v retrieving revision 1.323 diff -u -r1.323 vl.c --- vl.c29 Jul 2007 17:57:25 - 1.323 +++ vl.c1 Aug 2007 15:36:31 - @@ -7828,7 +7828,7 @@ fprintf(stderr, "No valid PXE rom found for network device\n"); exit(1); } - boot_device = 'c'; /* to prevent confusion by the BIOS */ + //boot_device = 'c'; /* to prevent confusion by the BIOS */ } Please don't comment out code. Just delete it. Regards, Anthony Liguori #endif Index: hw/pc.c === RCS file: /sources/qemu/qemu/hw/pc.c,v retrieving revision 1.81 diff -u -r1.81 pc.c --- hw/pc.c 6 Jun 2007 16:26:13 - 1.81 +++ hw/pc.c 1 Aug 2007 15:36:31 - @@ -197,6 +197,9 @@ case 'd': rtc_set_memory(s, 0x3d, 0x03); /* CD-ROM boot */ break; +case 'n': +rtc_set_memory(s, 0x3d, 0x04); /* Network boot */ +break; } /* floppy type */
Re: [Qemu-devel] Using Microsoft-provided Windows images
on x86, qemu by default does not emulate a scsi device. if you look at my last set of postings, you will see a patch set for adding scsi controllers on demand. its got some code formatting issues, so i understand why it hasnt been merged as of yet. i intend to publish a new version in the next couple of days. Julia Longtin <[EMAIL PROTECTED]> On Wed, Aug 01, 2007 at 04:33:31PM +0200, GUERRAZ Francois wrote: > Hello. > > Micro$oft's 64bits OSes are known to be problematic w/ kvm. > > I guess that the main problem w/ Qemu is that Microsoft Virtual Server > can emulate a SCSI controller and Qemu cannot... I havent checked but I > bet they installed their VM's with just SCSI drivers... > Try to install IDE drivers from VM Ware and then to boot from QEMU. > Also, try to disable ACPI (update the "computer" driver to "Standard PC" > if available) > > Regards, > > François. > > Le mercredi 01 août 2007 à 23:35 +0930, Dan Shearer a écrit : > > I have been playing around with the demonstration Windows images > > downloadable from Microsoft just to see how hard it would be to use the > > OSs they provide. The images are designed for Microsoft Virtual Server, > > but can be successfully converted to qcow2 and vhdx using qemu-img. QEMU > > won't boot the images (not a difficult problem, I think) but VMware can. > > I'll try other free virtualisation systems at some point. > > > > See http://shearer.org/Microsoft_Demo_VMs for my notes so far. > > > > >
[Qemu-devel] Patch: let qemu work with latest bochsbios
The boot_device is not communicated to the bochsbios through the CMOS. The following patch allows to boot via network on the newest bochsbios. Bernhard Kauer Index: vl.c === RCS file: /sources/qemu/qemu/vl.c,v retrieving revision 1.323 diff -u -r1.323 vl.c --- vl.c 29 Jul 2007 17:57:25 - 1.323 +++ vl.c 1 Aug 2007 15:36:31 - @@ -7828,7 +7828,7 @@ fprintf(stderr, "No valid PXE rom found for network device\n"); exit(1); } - boot_device = 'c'; /* to prevent confusion by the BIOS */ + //boot_device = 'c'; /* to prevent confusion by the BIOS */ } #endif Index: hw/pc.c === RCS file: /sources/qemu/qemu/hw/pc.c,v retrieving revision 1.81 diff -u -r1.81 pc.c --- hw/pc.c 6 Jun 2007 16:26:13 - 1.81 +++ hw/pc.c 1 Aug 2007 15:36:31 - @@ -197,6 +197,9 @@ case 'd': rtc_set_memory(s, 0x3d, 0x03); /* CD-ROM boot */ break; +case 'n': +rtc_set_memory(s, 0x3d, 0x04); /* Network boot */ +break; } /* floppy type */
[Qemu-devel] Patch: let qemu work with latest bochsbios
The boot_device is not communicated to the bochsbios through the CMOS. The following patch allows to boot via network on the newest bochsbios. Bernhard Kauer
Re: [Qemu-devel] Using Microsoft-provided Windows images
Hello. Micro$oft's 64bits OSes are known to be problematic w/ kvm. I guess that the main problem w/ Qemu is that Microsoft Virtual Server can emulate a SCSI controller and Qemu cannot... I havent checked but I bet they installed their VM's with just SCSI drivers... Try to install IDE drivers from VM Ware and then to boot from QEMU. Also, try to disable ACPI (update the "computer" driver to "Standard PC" if available) Regards, François. Le mercredi 01 août 2007 à 23:35 +0930, Dan Shearer a écrit : > I have been playing around with the demonstration Windows images > downloadable from Microsoft just to see how hard it would be to use the > OSs they provide. The images are designed for Microsoft Virtual Server, > but can be successfully converted to qcow2 and vhdx using qemu-img. QEMU > won't boot the images (not a difficult problem, I think) but VMware can. > I'll try other free virtualisation systems at some point. > > See http://shearer.org/Microsoft_Demo_VMs for my notes so far. >
Re: [Qemu-devel] replacing dyngen (was: S/390 host fixed)
On Wednesday 01 August 2007, Dan Shearer wrote: > On Wed, Aug 01, 2007 at 03:23:45PM +0100, Paul Brook wrote: > > Some parts of this code effectively are a "special language" for > > describing a CPU, that happen to be implemented using the C > > preprocessor :-) > > Right, in the same way that QEMU devices written in C are in a device > language? :-) Not really. The cpu backends are mainly defining parameters for the generic code. Most of it doesn't look much like C. The implementation of the code generator itself is in C, but that's shared between all targets. Paul
Re: [Qemu-devel] replacing dyngen (was: S/390 host fixed)
On Wed, Aug 01, 2007 at 03:23:45PM +0100, Paul Brook wrote: > Some parts of this code effectively are a "special language" for > describing a CPU, that happen to be implemented using the C > preprocessor :-) Right, in the same way that QEMU devices written in C are in a device language? :-) -- Dan Shearer [EMAIL PROTECTED]
Re: [Qemu-devel] replacing dyngen (was: S/390 host fixed)
On Wednesday 01 August 2007, Dan Shearer wrote: > On Wed, Aug 01, 2007 at 02:02:13AM +0100, Paul Brook wrote: > > I suspect making dyngen handle jump tables is not going to happen. > > Which brings up the question of dyngen. Very clever and a very good way > of bootstrapping QEMU in the early days, but too brittle going forwards > now the rest of QEMU works so well. > > You had an alternative approach to dyngen, pointed at here: > http://lists.gnu.org/archive/html/qemu-devel/2006-10/msg00227.html > > Any thoughts about the future of hand-coded backends in QEMU? I wasn't > convinced at first (and, given resources, it isn't nearly as good as a > special-purpose language for describing CPUs at this level) but I now > think your work is a very good solution for bootstrapping QEMU to the > next level of users. There's also a goolge SoC project to use llvm for code generation. http://code.google.com/p/llvm-qemu/ This works, however it's also significantly slower than current qemu (no more than half the speed). It may be possible to improve this, but llvm is a fairly heavyweight framework so I'm not convinced it is ever going to be competitive for generalexecution speed. One interesting thing that did come out of that project is that it's fairly trivial (a few hours work) to turn the existing code into a simple interpreter. Obviously this incurs a large performance hit, but also makes qemu trivially portable to other hosts. My hand coded generator is currently ~20% slower that dyngen. I still think this (or something similar) is the way forward, however I haven't made time to do any work on it recently. Some parts of this code effectively are a "special language" for describing a CPU, that happen to be implemented using the C preprocessor :-) Paul
[Qemu-devel] Using Microsoft-provided Windows images
I have been playing around with the demonstration Windows images downloadable from Microsoft just to see how hard it would be to use the OSs they provide. The images are designed for Microsoft Virtual Server, but can be successfully converted to qcow2 and vhdx using qemu-img. QEMU won't boot the images (not a difficult problem, I think) but VMware can. I'll try other free virtualisation systems at some point. See http://shearer.org/Microsoft_Demo_VMs for my notes so far. -- Dan Shearer [EMAIL PROTECTED]
Re: [Qemu-devel] [PATCH] S/390 host fixed
On Wed, Aug 01, 2007 at 02:02:13AM +0100, Paul Brook wrote: > I suspect making dyngen handle jump tables is not going to happen. Which brings up the question of dyngen. Very clever and a very good way of bootstrapping QEMU in the early days, but too brittle going forwards now the rest of QEMU works so well. You had an alternative approach to dyngen, pointed at here: http://lists.gnu.org/archive/html/qemu-devel/2006-10/msg00227.html Any thoughts about the future of hand-coded backends in QEMU? I wasn't convinced at first (and, given resources, it isn't nearly as good as a special-purpose language for describing CPUs at this level) but I now think your work is a very good solution for bootstrapping QEMU to the next level of users. -- Dan Shearer [EMAIL PROTECTED]
Re: [Qemu-devel] [PATCH] S/390 host fixed
On Wednesday 01 August 2007 01:59, Thiemo Seufer wrote: > > -AIOLIBS="-lrt" > > +AIOLIBS="-lrt -lpthread" > > Why is this needed? Linux toolchains should add -lpthread implicitly. Our SLES9 toolchain seems not to. It's a near-cosmetic change. > > +#ifdef __s390__ > > +retaddr = (void*)((unsigned long)retaddr & 0x7fffUL); > > +#endif > > All of those look weird. Is this a null-extension vs. sign-extension > issue? S/390 has a 31 (thirty-one) bit address space; the MSB of the PSW is not part of the address and must be masked out. This is simply part of the architecture, there's no way around it. > > +#ifdef __s390__ > > +func = NULL; /* does not work on S/390 for unknown > > reasons */ +#else > > func = gen_jcc_sub[s->cc_op - CC_OP_SUBB][jcc_op]; > > +#endif > > Hum. It wold be good to know what happens here. Indeed. :) > > +#ifdef __s390__ > > +if(!T1) > > +T0 = (int32_t)env->fcr0; > > +else if(T1 == 25) [...] > > I guess this breaks when you _breathe_ at the compiler. Probably, but that is true for a significant part of the QEMU codebase... CU Uli -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
[Qemu-devel] qemu/hw rtl8139.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/08/01 13:10:29 Modified files: hw : rtl8139.c Log message: Fix rtl8139 checksum calculation, by Tim Deegan. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/rtl8139.c?cvsroot=qemu&r1=1.10&r2=1.11
