Hi, I''m having problems using my RTL8139 network card with Xen. Output from lspci reports "Realtek Semiconducter Co., Ltd. RTL-8139/8319C/8139C+ (rev 10)". Although /xeno-1.2/xen/drivers/net/SUPPORTED_CARDS lists rtl8139 as ported, I can''t find any reference in the source files. Unsurprisingly both the demo CD and locally built versions for the stable release don''t appear to support my network card. The bit keeper binary appears to just hang when I try and clone the unstable source, so I''ve unpacked the nightly tarball instead. The ChangeLog states that 8139too.c was added at 2004-03-02 11:33:20, and this appears to be built. Booting the unstable version, I noticed Xen reports support for RTL-8139 as eth0, and even the partner ability which I guess indicates it''s a real physical device? I only saw this output before Xen stalled when I used the xenolinuz.gz from 1.2 with "noreboot" - I don''t know how else to capture such logs. However using the correct xenolinux.gz to boot properly I still get the same problems as ever. Trying "ifname=eth0" didn''t help either. In all cases dhclient only broadcasts DISCOVER requests and gets no responses. The output from "ifconfig eth0" lists a MAC of all zeroes and TX data only, with zero RX counters. What''s the status of the 8139 driver? Should this be working, or am I missing something? Thanks, Sean. -- Sean Atkinson <sean@netproject.com> Netproject ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> I''m having problems using my RTL8139 network card with Xen. Output from > lspci reports "Realtek Semiconducter Co., Ltd. RTL-8139/8319C/8139C+ > (rev 10)". > > Although /xeno-1.2/xen/drivers/net/SUPPORTED_CARDS lists rtl8139 as > ported, I can''t find any reference in the source files. Unsurprisingly > both the demo CD and locally built versions for the stable release don''t > appear to support my network card.I''m afraid the SUPPORTED_CARDS list is incorrect -- the driver isn''t actually in 1.2, though it is in the unstable tree. The driver was an external contribution, and we haven''t had any hardware to test it ourselves.> 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.> The ChangeLog states that 8139too.c was added at 2004-03-02 > 11:33:20, and this appears to be built. Booting the unstable > version, I noticed Xen reports support for RTL-8139 as eth0, > and even the partner ability which I guess indicates it''s a > real physical device?That suggests that at least the probe code is working.> I only saw this output before Xen stalled when I used the > xenolinuz.gz from 1.2 with "noreboot" - I don''t know how else > to capture such logs. However using the correct xenolinux.gz > to boot properly I still get the same problems as ever.You can always capture Xen''s output over a serial line, or use "xen_read_console" from domain0 after boot. 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.> Trying "ifname=eth0" didn''t help either.That''s the default, so shouldnm''t make any difference.> In all cases dhclient only broadcasts DISCOVER requests and gets no > responses. The output from "ifconfig eth0" lists a MAC of all zeroes > and TX data only, with zero RX counters.MAC of all zeros doesn''t sound at all good... I suspect you''re card isn''t being grocked quite right. Ian ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> You can always capture Xen''s output over a serial line, or use > "xen_read_console" from domain0 after boot.Actually, it''s xen_dmesg.py to get Xen''s boot output from dom0. This is in the tools/misc/ directory under the 1.2 and unstable trees. Mark ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Is RTL8139 NIC supported? -ishwar On Mon, 8 Mar 2004, Mark Williamson wrote:> > You can always capture Xen''s output over a serial line, or use > > "xen_read_console" from domain0 after boot. > > Actually, it''s xen_dmesg.py to get Xen''s boot output from dom0. This is in > the tools/misc/ directory under the 1.2 and unstable trees. > > Mark > > > > ------------------------------------------------------- > 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xen-devel >------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > Is RTL8139 NIC supported?xeno-unstable.bk contains a driver that has not received wide testing (we don''t have any hardware). We''d be grateful for feedback as to whether it works (or a patch to fix it ;-) Best, Ian ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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@netproject.com> Netproject
> > 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> 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.xen_read_console if for capturing console output for other domains. It''s very recently been replaced by the ''xend'' in xeno-unstable.bk -- the new bi-directional console daemon. For reading out messages from Xen itself use xen_dmesg.py (as per Mark''s email).> 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?If xenolinux boots OK, xen_dmesg.py should do the trick.> 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?So, sounds like the problem is the TX path. What happens if you enable the NMI watchdog in Xen? It might be helpful in finding out what''s hanging. Otherwise, perhaps scatter the TX path with printk''s and see where it hangs. Sorry not to be much more help, but without the h/w its hard to be useful.... Ian ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Hi,> 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>).Success! Your suggestions worked first time, and my RTL8139 NIC now appears to be working fine. I tested the performance between my regular Linux kernel on Fedora and Xen 1.3. An NFS (using default UDP) copy of a large file was almost 5% slower on Xen than Linux, and a scp (TCP) took just over 13% longer. Presumably these are reasonable results given the driver''s having to make extra copies in Xen? The only unusual result was that Xen''s time to flood ping 1000 packets over 100 Mbps Ethernet was 10306ms, less than Fedora''s 19503ms for the same test. For comparison an nVidia nForce in another machine achieved only 861ms, which makes both results for the RTL8139 look slow. Many thanks for your time and help in fixing this so promptly. Cheers, Sean. -- Sean Atkinson <sean@netproject.com> Netproject
> Success! Your suggestions worked first time, and my RTL8139 NIC now > appears to be working fine.Great! I cleaned up and applied your patch to the unstable tree.> I tested the performance between my regular Linux kernel on Fedora and > Xen 1.3. An NFS (using default UDP) copy of a large file was almost 5% > slower on Xen than Linux, and a scp (TCP) took just over 13% longer. > Presumably these are reasonable results given the driver''s having to > make extra copies in Xen?There are no extra copies happening: in both setups, every packet that is transferred is copied by the main CPU to or from an on-card buffer. The extra slowdown on Xen is due to using IO_REGS (ie. inb/outb) rather than memory-mapped IO (readb/writeb). If you want to get that performance back you''ll need to get the driver working without setting USE_IO_REGS. It *ought* to work --- ioremap() exists in Xen and is used by other drivers.> The only unusual result was that Xen''s time to flood ping 1000 packets > over 100 Mbps Ethernet was 10306ms, less than Fedora''s 19503ms for the > same test. For comparison an nVidia nForce in another machine achieved > only 861ms, which makes both results for the RTL8139 look slow.Well yes, the RTL8139 is a slow card! :-) The nVidia NIC can DMA to/from host memory, so you''re avoiding tying up the host CPU executing PIO cycles to perform the transfer itself. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel