Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Xen: Devel

RTL8139 support

 

 

Xen devel RSS feed   Index | Next | Previous | View Threaded


sean at netproject

Mar 8, 2004, 7:24 AM

Post #1 of 20 (193 views)
Permalink
RTL8139 support

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 [at] netproject>
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 [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


sean at netproject

Mar 8, 2004, 7:24 AM

Post #2 of 20 (190 views)
Permalink
RTL8139 support [In reply to]

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 [at] netproject>
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 [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


Ian.Pratt at cl

Mar 8, 2004, 7:49 AM

Post #3 of 20 (189 views)
Permalink
Re: RTL8139 support [In reply to]

> 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 [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


Ian.Pratt at cl

Mar 8, 2004, 7:49 AM

Post #4 of 20 (191 views)
Permalink
Re: RTL8139 support [In reply to]

> 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 [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


Mark.Williamson at cl

Mar 8, 2004, 8:01 AM

Post #5 of 20 (190 views)
Permalink
Re: RTL8139 support [In reply to]

> 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 [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


Mark.Williamson at cl

Mar 8, 2004, 8:01 AM

Post #6 of 20 (191 views)
Permalink
Re: RTL8139 support [In reply to]

> 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 [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


rattan at cps

Mar 8, 2004, 10:23 AM

Post #7 of 20 (190 views)
Permalink
Re: RTL8139 support [In reply to]

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 [at] lists
> 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 [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


rattan at cps

Mar 8, 2004, 10:23 AM

Post #8 of 20 (190 views)
Permalink
Re: RTL8139 support [In reply to]

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 [at] lists
> 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 [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


Ian.Pratt at cl

Mar 8, 2004, 10:36 AM

Post #9 of 20 (190 views)
Permalink
Re: RTL8139 support [In reply to]

>
> 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 [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


Ian.Pratt at cl

Mar 8, 2004, 10:36 AM

Post #10 of 20 (190 views)
Permalink
Re: RTL8139 support [In reply to]

>
> 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 [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


sean at netproject

Mar 9, 2004, 5:36 AM

Post #11 of 20 (190 views)
Permalink
Re: RTL8139 support [In reply to]

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 [at] netproject>
Netproject
Attachments: xen_dmesg.log (7.02 KB)
  8139too.patch (0.93 KB)


sean at netproject

Mar 9, 2004, 5:36 AM

Post #12 of 20 (190 views)
Permalink
Re: RTL8139 support [In reply to]

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 [at] netproject>
Netproject
Attachments: xen_dmesg.log (7.02 KB)
  8139too.patch (0.93 KB)


Keir.Fraser at cl

Mar 9, 2004, 1:47 PM

Post #13 of 20 (190 views)
Permalink
Re: RTL8139 support [In reply to]

> > 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 [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


Keir.Fraser at cl

Mar 9, 2004, 1:47 PM

Post #14 of 20 (190 views)
Permalink
Re: RTL8139 support [In reply to]

> > 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 [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


Ian.Pratt at cl

Mar 9, 2004, 2:50 PM

Post #15 of 20 (190 views)
Permalink
Re: RTL8139 support [In reply to]

> 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 [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


Ian.Pratt at cl

Mar 9, 2004, 2:50 PM

Post #16 of 20 (189 views)
Permalink
Re: RTL8139 support [In reply to]

> 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 [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


sean at netproject

Mar 11, 2004, 2:27 AM

Post #17 of 20 (190 views)
Permalink
Re: RTL8139 support [In reply to]

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 [at] netproject>
Netproject
Attachments: xeno-8139too.patch (1.60 KB)


sean at netproject

Mar 11, 2004, 2:27 AM

Post #18 of 20 (190 views)
Permalink
Re: RTL8139 support [In reply to]

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 [at] netproject>
Netproject
Attachments: xeno-8139too.patch (1.60 KB)


Keir.Fraser at cl

Mar 11, 2004, 3:06 AM

Post #19 of 20 (189 views)
Permalink
Re: RTL8139 support [In reply to]

> 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 [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


Keir.Fraser at cl

Mar 11, 2004, 3:06 AM

Post #20 of 20 (190 views)
Permalink
Re: RTL8139 support [In reply to]

> 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 [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel

Xen devel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.