Port-xen archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: upgrading from netbsd 4/xen 3.1 on i386 to HEAD on amd64



On Tue, Mar 11, 2008 at 10:35:15AM -0500, Chris Brookes wrote:
> > Basically yes. Just exchange your 32bit kernels with 32bit PAE kernels and
> > that's it. No changes in the userland are needed.
> 
> 
> And it works, mostly. The ride hasn't been smooth though. Apart from
> sysinst refusing to work with me on a partition greater than 1TB,
> which I worked around, I still have a few lingering issues only a
> couple of which are probably relevant to this list but I'll mention
> the others in the hopes of some direction...
> 
> 1) Using 
> http://ftp.netbsd.org/pub/NetBSD-daily/HEAD/200803080000Z/i386/binary/kernel/netbsd-INSTALL_XEN3PAE_DOMU.gz
> I got a core when I run nslookup or dig.
> 
> link# nslookup
> [1]   Bad system call (core dumped) nslookup
> link# Mar 11 09:59:57 link /netbsd: pid 1363 (nslookup), uid 0: exited on 
> signal
> 
> An example is at http://txrx.org/nslookup.core

Ha yes, the SA syscall issues. Threaded programs won't work with a current
kernel and an older userland. To workaround this you can upgrade libc and
libpthread only, but it may be easier to upgrade the whole system to current.

> 
> 2) On the Dom-0 using a kernel compiled from source at
> http://ftp.netbsd.org/pub/NetBSD-daily/HEAD/200803080000Z/source/sets/syssrc.tgz
> I couldn't get the re0 nic to work properly with my vlan setup.
> 
> re0 at pci2 dev 15 function 0: RealTek 8169SC/8110SC Single-chip
> Gigabit Ethernet (rev. 0x10)
> re0: interrupting at ioapic0 pin 23, event channel 13
> re0: Ethernet address 00:1a:4d:ff:e4:72
> re0: using 256 tx descriptors
> rgephy0 at re0 phy 7: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 2
> 
> When the interface was brought up with a regular IP it worked without
> issue. When I brought up re0 without an IP and instead configured a
> vlan interface with the other end connected to a 801.1q trunk port on
> my switch, things started to go awry. I could source traffic from the
> dom-0 and get as far as installing packages over the network seemingly
> without problems, but strangely inbound traffic wasn't working
> properly. An inbound telnet on port 22 to the dom0 would produce the
> SSH banner, but any subsequent traffic would vanish. Looking at a
> trace in wireshark it showed a sucessful tcp connection setup
> (obviously since I saw the banner) but after the banner there'd be a
> couple of retransmissions and then nothing. I plugged in an old  3c905
> and using the ex driver everything's fine, so I'm relatively confident
> it's a re drive issue. Which would be the best list to report to with
> this, or should I file a PR, or both?

Looks like an issue with hardware vlan support on re(4).
You can post to tech-net@ first, and eventually send-pr.

> 
> 3) I have a parition in the dom0 (/dev/ld1a) that is exported to a
> domu with 'phy:/dev/ld1a,wd2d,w' and is then exported to another
> (linux) domu with 'phy:/dev/ld1a,sda3,r'. Prior to the upgrade, I had
> this working for a couple of months with (I think) xentools3.1.2. With
> my new setup (xentols3.1.3 ) this simply doesn't work.  The first
> dom-u mounts with no problem and then the second one prints time out
> message from XENBUS. I haven't tried the xentools 3.1.2 to see if that
> is the problem, I just mention the versions because (aside from the
> dom-0 architecture change!) that's the only thing that's different...

Any more message in /var/log/xenbackendd, or /var/log/xen/xend.log ?

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--


Home | Main Index | Thread Index | Old Index