2006

Yes Junichi, you are correct, the behaviour of /proc/1/{cwd,root} changed in 2.6.18. The relevant commit is 778c1144771f0064b6f51bee865cceb0d996f2f9.

The behaviour is now really weird. readlink returns /, but in reality it points to somewhere else. Also it breaks the chroot detection.

I just take a look into the opcodes list of binutils for s390 and found the following entries:

b9b1 cu24 RRF_M0RR "convert utf-16 to utf-32" z9-109 zarch
b2a6 cu21 RRF_M0RR "convert utf-16 to utf-8" z9-109 zarch
b2a6 cuutf RRF_M0RR "convert unicode to utf-8" z9-109 zarch
b9b3 cu42 RRF_M0RR "convert utf-32 to utf-16" z9-109 zarch
b9b2 cu41 RRF_M0RR "convert utf-32 to utf-8" z9-109 zarch
b2a7 cu12 RRF_M0RR "convert utf-8 to utf-16" z9-109 zarch
b2a7 cutfu RRF_M0RR "convert utf-8 to unicode" z9-109 zarch
b9b0 cu14 RRF_M0RR "convert utf-8 to utf-32" z9-109 zarch

Since z9-109, it have own opcodes to convert between the different types of unicode.

It is done. The new Xen infrastructure is finished, although it is not yet completely in unstable.

The main difference to the old one, the hypervisor and utils packages includes the complete version and an abi spec, just like our linux kernels. Also it is now possible to install more than one version of the utils at the same time. The userspace tries to find the correct tools for the running hypervisor.

The following packages are provided now:

• xen-hypervisor-3.0.2-1-$flavour
• xen-utils-3.0.2-1
• xen-ioemu-3.0

and from the kernel

• xen-linux-system-$kernelversion

The only missing thing is a selection of the correct hypervisor in update-grub.

I did some performance tests with the T2000. The CPU is too slow to beat any current one from IBM (Power), AMD or Intel.

My first test was building kernels. With -j32, a complete build needs about 9 minutes. For comparison, a 4-way UltraSparc 2 with 450MHz needs 30 minutes. So each core compares to an UltraSparc 2 with 700MHz.

This numbers are not that phenomenal, so I added another test with ccache, to realy use the io system. With empty cache, it needs 10 minutes, with filled cache it needs 2.5 minutes.

As application server, it is not that usable; they are cpu bound. Especially zope, which is known to not scale well on more cpus because of the python global interpreter lock, is not able to use this. A comparision with an Opteron 242 with 1.6GHz shows a factor of 5 in the computing power on virtual cpu.

Some people already know it, I got a new machine to play with.

It is a Sparc running Debian etch:

# uname -a
Linux zee 2.6.17-2-vserver-sparc64 #1 SMP Sat Aug 26 12:28:58 UTC 2006 sparc64 GNU/Linux

The kernel is not yet available in Debian, it is handbuilt. But I hope that this will change soon.

It is a small machine with some CPUs:

# grep ncpus /proc/cpuinfo
ncpus probed    : 32
ncpus active    : 32

It only have a little bit of RAM:

# grep MemTotal /proc/meminfo
MemTotal:     33257432 kB

And really too less disk space:

SCSI device sda: 143374738 512-byte hdwr sectors (73408 MB)
SCSI device sdb: 143374738 512-byte hdwr sectors (73408 MB)

Yes, it is a T2000 from Sun with 8 real CPU cores:

cpu             : UltraSparc T1 (Niagara)
fpu             : UltraSparc T1 integrated FPU
prom            : OBP 4.19.0 2005/10/27 17:24
type            : sun4v

Each of the 8 cores can run 4 threads at the same time, Sun calls this CoolThreads, and Linux sees this as virtual CPUs.

Yes, the xen images from linux 2.6.16-18 in unstable does not work with the currect xen 3.0 in unstable and testing. The interface for the priviledged domain changed in an incompatible way. I'm working on that problem and 2.6.17-7 will contain a complete new infrastructure.

ibmvscsi is the name of the virtual scsi for ibm pSeries and iSeries machines. The client part is in the kernel since long time. The server part is not.

There are several versions of the server part floating around, one was submitted to linux upstream and rejected, the others was directly pushed into the SLES kernel. SLES 10.1 have one in there 2.6.16 kernel.

Now I wanted to update the kernel of my vioserver to something newer than 2.6.13, I wanted 2.6.17. The ibmvscsis is easily ported -- some of the constants was renamed -- and installed. As I wanted to test it in my kernel test environment, I only booted a minimal set, the vioserver themself, which provides scsi and network for the other partitions, the control partition, which is used for easy control, my own development partition and my kernel test environment. After a short time, the software on the kernel test partitions begins to segfault and dpkg crys about broken tar archives. After that also my own development partition shows the same behaviour.

The result:

• / of the control partition is partialy broken, can be repaired.
• / of my development guest is completely broken.
• /srv of my development guest is partialy broken.
• /home is okay puh.
• / of the kernel test partitions are unknown.

This is the story of a simple kernel upgrade, which is not finished after 6 hours and a part of a company which wants support for there hardware but don't want work with Linux upstream. The communication with the Cell and zSeries developers works fine, with the pSeries not.

I commited a XEN patch to linux-2.6, so we will have XEN in 2.6.17. The patch is based on the Fedora sources.

The images will be available tomorrow via the Kernel snapshots and needs an updated xen-hypervisor-3.0-* package (>= 3.0.2+hg9697-2) with changes I commited today.

I think the current situation is rather clear. Our current kernel contains firmware blobs for some hardware. They are relicts from the time where the firmware loading infrastructure did not exists. It may be possible to move them outside, but such patches was rejected to keep compatibility.

Some people clearly stats, that they think, this violates paragraph 2 of the DFSG. I must say, I'm not sure. This paragraph say: The program must include source code. Now source is not defined and opaque data have no defined form of source. The data is opaque as it is not possible to say, what it includes. (Some people wanted to differentiate between executable code and configuration settings, but there is no way to see what it is.)

If we remove them from the kernel image, we make many users unhappy. Many of the widely used hardware like TG3 and some storage adapters will just stop working after a kernel upgrade. There is also no clean upgrade path. Even the installer infrastructure is missing and I don't think they will be finished for the release of etch. Therefor is think, such a removal will even violation paragraph 4 of our Social Contract which say: Our priorities are our users.