[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] RTL8139 support
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 Attachment:
8139too.patch
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |