x86_64-2.6.0-1 released

[Andi Kleen]

The first x86-64 patchkit for the 2.6.0 linux kernel has been released. I normally don't announce
patchkits to linux-kernel, but a lot of people don't seem to know about them. The patchkit
has fixes for many serious bugs (including data corruption iossues) on x86-64 that didn't make it 
in official 2.6.0. Please don't bother reporting any x86-64 problems to me if you didn't 
apply the patchkit first. 

Hopefully now that the trees are more open again most of this can migrate into the official
tree, depending on the policy enforced by Linus/Andrew.

This version just has a few minor fixes against the last patchkit release (x86_64-2.6.0test11-3)

ftp://ftp.x86-64.org/pub/linux/v2.6/x86_64-2.6.0-1.bz2
df65fee5a0388a036d324cb9b16bd778  x86_64-2.6.0-1.bz2

ChangeLog since x86_64-2.6.0test11-3:
- Mark some more non 64bit clean drivers !64BIT
- Remove dump_sg in pci-gart.c again
- Fix inefficiency in find_next_bit

Older Changelog is available in ftp://ftp.x86-64.org/pub/linux/v2.6/RELEASE-NOTES

Some known issues:
Taskfile IO can hang SuSE hwscan. Better disable it for now.
Taskfile IO can cause disk corruption too.
NMI watchdog runs too often (HZ instead once a second) (still true?)
[I think that's fixed now, but needs verifying]
Machine Check calls printk currently, but that can deadlock when the MCE
occurs inside any of the console locks.
sysfs support for arch/ may not be complete.
32bit SYSCALL seems to still have problems with some programs (disabled currently)
Some reports of persistent segfaults after stress tests
(also seen once here, need to be reproduced). Could be IOMMU overflow.
Mysterious timer bug in some cases. Shortly in or after bootup
the timer lists gets corrupted in some configuration. Seems to depend
on how long the bootup takes.
JFS seems to corrupt file systems quickly (generic 64bit bug)
	[maintainer cannot reproduce it]
WCHAN seems to be broken
Suspend often doesn't initialize video after wakeup
	Generic problem, needs a lot of effort to fix properly. The graphic
	card has to be POSTed properly, which is quite complicated.
MPT fusion driver breaks when iommu merging is disabled (run with iommu=merge)
	A workaround for this is enabled by default now. Underlying bug
	still unfixed. This bug seems to only occur on some specific machines,
	most MPT fusion users probably don't have to worry about it. Seems
	to be a driver bug.
Realtek 8169 driver does not support >4GB (patch exists, should be merged
by network driver maintainer) 
Nvidia and VIA boards are forced to IO-APIC off to work around ACPI bugs.
	This will be a major problem once SMP boards with these chipsets 
	are out.
Some boards don't set the wall clock correctly
G400 DRM crashes machine
VIA SATA doesn't work
Some people report disk corruptions with IOMMU. Not able to reproduce it.
	It seems to happen on some block device drivers who have a very deep
	queue. Mostly these devices don't need an IOMMU (3ware is a prominent 
	exception) because they support 64bit IO. Unfortunately many people
	still run with CONFIG_IOMMU_DEBUG which will force the IOMMU support
	for every device. Changing the IOMMU flush to flush on every mapping
	seems to fix it. Currently there are workarounds active that
	check for Qlogic and 3ware and do that.  Anybody still seeing this please 
	try with iommu=fullflush and report back.
	Underlying bug still undebugged.
Scheduler does not work well with NUMA (testcase multithreaded STREAM) 
	It does not distribute threads quickly enough to all CPUs,
	which leads to memory getting allocated on the wrong nodes.
Some motherboard/cpu combinations do not reboot automatically
IPSec netlink setup code is not 32bit emulation clean
iptables is not 32bit emulation clean
gettimeofday gets non monontonous when ntpd corrects drift
valgrind does not run even with linux32 --3gb. Figure out what is different.
	[An a.out emacs also doesn't run. Probable the same difference]


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/