WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] RTL8139 support

To: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] RTL8139 support
From: Sean Atkinson <sean@xxxxxxxxxxxxxx>
Date: Tue, 09 Mar 2004 13:36:52 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 09 Mar 2004 12:39:18 +0000
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: <E1B0M3w-0007m7-00@xxxxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Organization: Netproject
References: <E1B0M3w-0007m7-00@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
Hi,

> > The bit keeper binary appears to just hang when I try and clone the
> > unstable source, so I've unpacked the nightly tarball instead.
> 
> That's very odd. I wander if bkbits.net was in a maintenance
> window -- it's usually very reliable.

Things seem to be back in order now - cloning worked fine for me this
morning.

> You can always capture Xen's output over a serial line, or use
> "xen_read_console" from domain0 after boot.

I've now updated my xeno.spec file to package the unstable 1.3 source,
and it appears xen_dmesg.py has replaced xen_read_console. 

Unfortunately I don't have a serial cable for capturing Xen's output
from my desktop and my laptop doesn't even have a serial port - are
there any clever alternatives please?  Trying console=vga didn't help,
and even remote logging over the network would be of limited use in
debugging a NIC driver :o).  Maybe I'll have to go buy a null modem
cable somewhere...

> Capturing this would be very helpful, particularly if debuging in
> the RTL8139 driver was enabled. Comparing it against the same
> driver running under Linux would likely highlight the problem.

Following your advice, I've made some progress now.  I noticed that
booting Fedora, dmesg listed a sensible MAC and IRQ, and had identified
my chip set as "RTL-8139C" (lspci -n reports 10ec:8139 for the device). 
However Xen reported "unknown chip version, assuming RTL-8139" and
"TxConfig = 0x0".  It appears all the RTL_R[8,16,32] macros in 8139too.c
were returning zero, so I've defined USE_IO_OPS so they call in[b,w,l]
like 3c59x.c instead of read[b,w,l].  The patch is attached, as well as
the resulting log output.  The good news is that this identifies the
chip set properly and reports the correct MAC.  I can even configure the
device with ifconfig and send packets onto the network.

Naturally there's some bad news too - receiving packets hangs the
machine instantly.  Although pinging an unused address is OK, the return
packet from a live address stalls Xen.  Similar problems were
experienced with a DHCP offer response and even trying to send UDP
packets with nc.

Does anybody have any experience of this working since being added to
Xen, or have any thoughts on how I might proceed debugging it?

Thanks,

Sean.

-- 
Sean Atkinson <sean@xxxxxxxxxxxxxx>
Netproject

Attachment: xen_dmesg.log
Description: Text document

Attachment: 8139too.patch
Description: Text document