2002-07-16 20:00:15

by Andi Kleen

[permalink] [raw]
Subject: Second x86-64 kernel snapshot based on 2.4.19rc1 released


A new snapshot of the linux/x86-64 kernel has been released. Linux/x86-64
is a port of Linux to the x86-64 architecture. For more information on
x86-64 see http://www.x86-64.org.

This is the second snapshot based on 2.4.19rc1.

This release fixes some bugs in the IOMMU code. These can cause file system
corruption with IDE. If you're already using the 2.4.19rc1-1 snapshot
it is strongly recommended to upgrade to 2.4.19rc1-2.

Full tar ball:

ftp://ftp.x86-64.org/pub/linux/v2.4/linux-x86_64-2.4.19rc1-2.tar.bz2

Patch against official 2.4.19rc1 from kernel.org:

ftp://ftp.x86-64.org/pub/linux/v2.4/x86_64-2.4.19rc1-2.bz2

2.4.19rc1-2 snapshot:

- Fix radeon and vesafb framebuffer drivers.
- Various bugfixes for the IOMMU code:
* on/off/force switching logic is more intelligent
* never flush caches except at initialization
* don't access the IOMMU part of the GART via the CPU.
* fix scatter gather freeing problems
* various other cleanups and fixes.1
- More driver fixes.
- Fix strncpy_from_user problems which caused glibc and LTP failures
- Support VFAT ioctls in 32bit emulation
- Fix vsyscall linker bug
- Reenable AMD7469 IDE tuning
- Various other cleanups and fixes

2.4.19rc1-1 snapshot:

- Merge to 2.4.19rc1
- HPET timer support. When the box doesn't support HPET it'll fallback to accessing
the 8253 timer chip. The support is checked using the acpitable mini ACPI. When
there is no ACPI entry found it tries to enable HPET timers manually.
- PCI GART IOMMU support. Allows operation of 32bit PCI cards on boxes with more
than 4GB of memory.
This code is currently enabled for all drivers that use the pci-dma API even for
memory addresses smaller than 4GB. This is done to get better test coverage.
The code can be disabled with a configuration option.
To use this code it is recommended to use a big AGP aperture (256MB - 512MB)
It can be also disabled at bootup using iommu=off
- change_page_attr implemented to fix mappings with conflicting caching attributes in AGP
- AGP driver for AMD 8151
- Machine check handler for AMD Opteron
- New early console support to print messages
- Various driver fixes. Several not 64bit clean drivers disabled in the configuration
and others fixed.
- NMI watchdog works now.
- mtrr driver works now on SMP
- New optimized IP checksum/memset/memcpy functions
- Some bugs in IA32 emulation fixed.
- signal handler stack alignment bug fixed.
- Lots of bugfixes and cleanups.

Known Problems/Caveats:

- vsyscalls are currently disabled because they trigger too many linker bugs together
with HPET timers. The vsyscall pages just call normal syscalls.
- ISDN driver should not be enabled in the configuration because it partly
doesn't compile.
- The drivers/usb/se401.c USB driver triggers a compiler bug and should not be
enabled in the configuration.
- gdb sometimes corrupts the kernel stack frame and can cause an oops in error_restore.
- Still many drivers untested and may not work.
- LDT sharing between threads may not work.

-Andi Kleen, SuSE Labs


2002-07-16 20:15:55

by Chris Friesen

[permalink] [raw]
Subject: Re: Second x86-64 kernel snapshot based on 2.4.19rc1 released

Andi Kleen wrote:

> - vsyscalls are currently disabled because they trigger too many linker bugs together
> with HPET timers. The vsyscall pages just call normal syscalls.

I assume that the linker is going to get fixed before general x86-64 release so
these can be used together?

Chris


--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]

2002-07-16 20:23:49

by Andi Kleen

[permalink] [raw]
Subject: Re: Second x86-64 kernel snapshot based on 2.4.19rc1 released

On Tue, Jul 16, 2002 at 04:18:35PM -0400, Chris Friesen wrote:
> Andi Kleen wrote:
>
> > - vsyscalls are currently disabled because they trigger too many linker bugs together
> > with HPET timers. The vsyscall pages just call normal syscalls.
>
> I assume that the linker is going to get fixed before general x86-64 release so
> these can be used together?

Yes, the problem is being worked on.

-Andi

2002-07-19 07:10:49

by Andreas Jaeger

[permalink] [raw]
Subject: Re: Second x86-64 kernel snapshot based on 2.4.19rc1 released

Andi Kleen <[email protected]> writes:

> On Tue, Jul 16, 2002 at 04:18:35PM -0400, Chris Friesen wrote:
>> Andi Kleen wrote:
>>
>> > - vsyscalls are currently disabled because they trigger too many linker bugs together
>> > with HPET timers. The vsyscall pages just call normal syscalls.
>>
>> I assume that the linker is going to get fixed before general x86-64 release so
>> these can be used together?
>
> Yes, the problem is being worked on.

It looks currently like a kernel bug - the linker is fine. We're
currently working on a proper fix for this and I hope that Andi's next
kernel will work correctly.

Andreas
--
Andreas Jaeger
SuSE Labs [email protected]
private [email protected]
http://www.suse.de/~aj

2002-07-19 09:40:23

by Andi Kleen

[permalink] [raw]
Subject: Re: Second x86-64 kernel snapshot based on 2.4.19rc1 released

On Fri, Jul 19, 2002 at 09:13:47AM +0200, Andreas Jaeger wrote:
> Andi Kleen <[email protected]> writes:
>
> > On Tue, Jul 16, 2002 at 04:18:35PM -0400, Chris Friesen wrote:
> >> Andi Kleen wrote:
> >>
> >> > - vsyscalls are currently disabled because they trigger too many linker bugs together
> >> > with HPET timers. The vsyscall pages just call normal syscalls.
> >>
> >> I assume that the linker is going to get fixed before general x86-64 release so
> >> these can be used together?
> >
> > Yes, the problem is being worked on.
>
> It looks currently like a kernel bug - the linker is fine. We're
> currently working on a proper fix for this and I hope that Andi's next
> kernel will work correctly.

If you refer to the SIZEOF undefined symbol thing - that was a different
problem and indeed a kernel bug. But with full vsyscalls we run into
more relocation problems because the linker seems to have problems
with the secondary mapping used by vsyscalls with more complex code.
Of course it could be still a kernel bug, but I do not see where it
should come from.

In short the mapping trick used by the current vsyscall code is very
nasty. It requires quite some non obvious vmlinux.lds trickery that
seems to easily cause/trigger bugs in both binutils and kernel. I would
be better to find a more maintaineable solution for the secondary mappings.

-Andi