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: Sean Atkinson <sean@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] RTL8139 support
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 09 Mar 2004 20:47:18 +0000
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 09 Mar 2004 20:48:41 +0000
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Tue, 09 Mar 2004 13:36:52 +0100." <1078835811.7031.76.camel@xxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> > 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?

Accesses to the skb->data on the receive path must be wrapped with
map_domain_mem()/unmap_domain_mem(). 

eg. 
 char *vdata = map_domain_mem(__pa(skb->data));
 <use vdata as you would normally use skb->data>
 unmap_domain_mem(vdata);

I've taken a brief look at the driver and you may get away with just
replacing wth_copy_and_sum() in include/xeno/etherdevice.h with the
following:

static inline void eth_copy_and_sum(struct sk_buff *dest, 
       unsigned char *src, int len, int base)
{
    char *vdata = map_domain_mem(__pa(dest->data));
    memcpy(vdata, src, len);
    unmap_domain_mem(vdata);
}

(You may need to #include <asm/domain_page.h>).

 -- Keir


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel