[Linux-ia64] Re: IA-64 XFree86 (was: XFree 4.0.1 module loading)

[Linux-ia64] Re: IA-64 XFree86 (was: XFree 4.0.1 module loading)

[Keith Packard]

> First, I ask David Dawes or Keith Packard to set up an XFree86-internal
> mailing list, say ia64@xfree86.org.  At this point, I don't think this
> list should be public.  Its initial membership would be

Let me know and I'll create a list.  I'll make Marc be the administrator so
that addition requests can be handled correctly.  I'm a bit concerned about
IA64 IP though -- XFree86 has no NDA with Intel regarding IA64 as far as I
know.

If no proprietary information will be discussed, I'd be happier with a 
public list, they're easier to administer.

keithp@keithp.com	 XFree86 Core Team		SuSE, Inc.

[Linux-ia64] Re: IA-64 XFree86 (was: XFree 4.0.1 module loading)

[Marc Aurele La France]

On Mon, 21 Aug 2000, Keith Packard wrote:

> > First, I ask David Dawes or Keith Packard to set up an XFree86-internal
> > mailing list, say ia64@xfree86.org.  At this point, I don't think this
> > list should be public.  Its initial membership would be

> Let me know and I'll create a list.  I'll make Marc be the administrator so
> that addition requests can be handled correctly.  I'm a bit concerned about
> IA64 IP though -- XFree86 has no NDA with Intel regarding IA64 as far as I
> know.

> If no proprietary information will be discussed, I'd be happier with a 
> public list, they're easier to administer.

I'm suggesting it be non-public to keep the S/N ratio up.

Marc.

+----------------------------------+-----------------------------------+
|  Marc Aurele La France           |  work:   1-780-492-9310           |
|  Computing and Network Services  |  fax:    1-780-492-1729           |
|  352 General Services Building   |  email:  tsi@ualberta.ca          |
|  University of Alberta           +-----------------------------------+
|  Edmonton, Alberta               |                                   |
|  T6G 2H1                         |     Standard disclaimers apply    |
|  CANADA                          |                                   |
+----------------------------------+-----------------------------------+
XFree86 Core Team member.  ATI driver and X server internals.

Re: [Linux-ia64] Re: IA-64 XFree86 (was: XFree 4.0.1 module loading)

[Jes Sorensen]

>>>>> "Marc" = Marc Aurele La France <tsi@gpu.srv.ualberta.ca> writes:

Marc> On Mon, 21 Aug 2000, Keith Packard wrote:
>> If no proprietary information will be discussed, I'd be happier
>> with a public list, they're easier to administer.

Marc> I'm suggesting it be non-public to keep the S/N ratio up.

Please don't it makes it a royal pain in the butt for people who post
from random email addresses and it isn't that likely that there will
be a pile of noise makers on a list like this.

Jes

[Linux-ia64] Re: IA-64 XFree86 (was: XFree 4.0.1 module loading)

[Mark Vojkovich]

On Mon, 21 Aug 2000, Marc Aurele La France wrote:

> ATI is funding me to go to their labs near Toronto from 2000.09.13 to
> 2000.09.22 and work on IA-64 support.  This despite that they are aware
> Michael Madore has both the ATI and R128 drivers working reasonably well.
> I see this as a measure of how important they feel IA-64 support this.  I
> agree with them.  And so, my goal with this "outing" will be to bring
> XFree86's IA-64 server up to as close to an "out-of-the-box" condition as
> I can, using what we currently provide on IA-32 as a benchmark.
> 
> So that I don't end up duplicating effort and/or working in the dark, I'd
> like us to coordinate our efforts.

   I don't have anything on my worklist for IA-64.  The biggest
problems I have with IA-64 are things that I cannot address. 
Mainly:

1) Firmware issues that prevent the X-server from working reliably
   with SMP (even lspci locks up in the SAL code).

2) No mechanism for the X-server to write combine memory and no
   discussions on adding this to Linux as far as I can tell.
   There needs to be a new flag to open() or mmap().  There
   aren't any MTRRs.

3) The bios not assigning interrupts to cards that need them.
   My A3 machine will not boot with an NVIDIA card in it for
   this reason.

  Other than those, and the fact that we don't have loader
support, the server is pretty much offering what we offer under
IA-32 currently.


					Mark.

Re: [Linux-ia64] Re: IA-64 XFree86 (was: XFree 4.0.1 module loading)

[Marc Aurele La France]

On 21 Aug 2000, Jes Sorensen wrote:

> >> If no proprietary information will be discussed, I'd be happier
> >> with a public list, they're easier to administer.

> Marc> I'm suggesting it be non-public to keep the S/N ratio up.

> Please don't it makes it a royal pain in the butt for people who post
> from random email addresses and it isn't that likely that there will
> be a pile of noise makers on a list like this.

I disagree.  This is to be a working group, and, given the timelines
involved, not one bogged down by answering FAQ's or dealing with 
dichotomous net presences.

Marc.

+----------------------------------+-----------------------------------+
|  Marc Aurele La France           |  work:   1-780-492-9310           |
|  Computing and Network Services  |  fax:    1-780-492-1729           |
|  352 General Services Building   |  email:  tsi@ualberta.ca          |
|  University of Alberta           +-----------------------------------+
|  Edmonton, Alberta               |                                   |
|  T6G 2H1                         |     Standard disclaimers apply    |
|  CANADA                          |                                   |
+----------------------------------+-----------------------------------+
XFree86 Core Team member.  ATI driver and X server internals.

[Linux-ia64] Re: IA-64 XFree86 (was: XFree 4.0.1 module loading)

[Bill Nottingham]

Mark Vojkovich (mvojkovich@valinux.com) said: 
> 1) Firmware issues that prevent the X-server from working reliably
>    with SMP (even lspci locks up in the SAL code).

There is a kernel patch for this; there's a buffer overflow
in the PCI code. (Unless you are running into something else,
which is possible...)

> 3) The bios not assigning interrupts to cards that need them.
>    My A3 machine will not boot with an NVIDIA card in it for
>    this reason.

Is it sitting behind a PCI card with a bridge on it?

Bill

[Linux-ia64] Re: IA-64 XFree86 (was: XFree 4.0.1 module loading)

[Mark Vojkovich]

On Mon, 21 Aug 2000, Bill Nottingham wrote:

> Mark Vojkovich (mvojkovich@valinux.com) said: 
> > 1) Firmware issues that prevent the X-server from working reliably
> >    with SMP (even lspci locks up in the SAL code).
> 
> There is a kernel patch for this; there's a buffer overflow
> in the PCI code. (Unless you are running into something else,
> which is possible...)

   Does lspci work reliably on your SMP Big Sur?

> 
> > 3) The bios not assigning interrupts to cards that need them.
> >    My A3 machine will not boot with an NVIDIA card in it for
> >    this reason.
> 
> Is it sitting behind a PCI card with a bridge on it?
> 

  No.  I've not gotten any NVIDIA card to work in my A3 or
A0 machines.  The machine will not even get to the EFI prompt.
NVIDIA tells me this is because the bios is not giving the
card an interrupt, and they need one.


				Mark.

Re: [Linux-ia64] Re: IA-64 XFree86 (was: XFree 4.0.1 module loading)

[David Mosberger]

>>>>> On Mon, 21 Aug 2000 12:34:11 -0700 (PDT), Mark Vojkovich <mvojkovich@valinux.com> said:

  Mark> 1) Firmware issues that prevent the X-server from working
  Mark> reliably with SMP (even lspci locks up in the SAL code).

As Bill already pointed out, we have seen any problems since we fixed
/proc/bus/pci/devices not to overwrite kernel memory.  We have a
dual-CPU BigSur here which runs X fine and lspci doesn't crash the
machine.  The quick and dirty hack is to use 16KB page size.

  Mark> 2) No mechanism for the X-server to write combine memory and
  Mark> no discussions on adding this to Linux as far as I can tell.
  Mark> There needs to be a new flag to open() or mmap().  There
  Mark> aren't any MTRRs.

I submitted a patch for the tdfx DRM module to map non-AGP stuff as
write-combined (actually, I'm not 100% sure this is the right thing to
do here; a DRM expert may want to double check this; it does seem to
work fine on my machine).  See the latest Linux kernel patch.

Linus already agreed that it would be OK to add additional mmap()
flags to indicate the memory attribute (normal vs. write-combine
vs. uncached).  Walt says a patch to do this was developed as part of
the XFree86 4.0 work at VA and promised to send me a patch.  I don't
think I have received such a patch, but I'd be happy to merge it
in. ;-)

  Mark> 3) The bios not assigning interrupts to cards that need them.
  Mark> My A3 machine will not boot with an NVIDIA card in it for this
  Mark> reason.

Can't help with this.

	--david

Re: [Linux-ia64] Re: IA-64 XFree86 (was: XFree 4.0.1 module loading)

[Mark Vojkovich]

On Mon, 21 Aug 2000, David Mosberger wrote:

> >>>>> On Mon, 21 Aug 2000 12:34:11 -0700 (PDT), Mark Vojkovich <mvojkovich@valinux.com> said:
> 
>   Mark> 1) Firmware issues that prevent the X-server from working
>   Mark> reliably with SMP (even lspci locks up in the SAL code).
> 
> As Bill already pointed out, we have seen any problems since we fixed
> /proc/bus/pci/devices not to overwrite kernel memory.  We have a
> dual-CPU BigSur here which runs X fine and lspci doesn't crash the
> machine.  The quick and dirty hack is to use 16KB page size.

   OK, that's good news.  I'll get somebody to update the kernel
on my dual-CPU BigSur and give it a try.

>   Mark> 2) No mechanism for the X-server to write combine memory and
>   Mark> no discussions on adding this to Linux as far as I can tell.
>   Mark> There needs to be a new flag to open() or mmap().  There
>   Mark> aren't any MTRRs.
> 
> Linus already agreed that it would be OK to add additional mmap()
> flags to indicate the memory attribute (normal vs. write-combine
> vs. uncached).  Walt says a patch to do this was developed as part of
> the XFree86 4.0 work at VA and promised to send me a patch.  I don't
> think I have received such a patch, but I'd be happy to merge it
> in. ;-)

   That Walt is a funny guy.  I'll make sure to give him a swift kick 
in the ass tomorrow.  God knows he deserves it. 


					MArk.

Re: [Linux-ia64] Re: IA-64 XFree86 (was: XFree 4.0.1 module loading)

[Johannes Erdfelt]

On Mon, Aug 21, 2000, Mark Vojkovich <mvojkovich@valinux.com> wrote:
> 
> On Mon, 21 Aug 2000, David Mosberger wrote:
> 
> > >>>>> On Mon, 21 Aug 2000 12:34:11 -0700 (PDT), Mark Vojkovich <mvojkovich@valinux.com> said:
> > 
> >   Mark> 1) Firmware issues that prevent the X-server from working
> >   Mark> reliably with SMP (even lspci locks up in the SAL code).
> > 
> > As Bill already pointed out, we have seen any problems since we fixed
> > /proc/bus/pci/devices not to overwrite kernel memory.  We have a
> > dual-CPU BigSur here which runs X fine and lspci doesn't crash the
> > machine.  The quick and dirty hack is to use 16KB page size.
> 
>    OK, that's good news.  I'll get somebody to update the kernel
> on my dual-CPU BigSur and give it a try.

Nope, this was not the problem. We have the same problem going directly
to the hardware as well, as XFree and scanpci (XFree tool) does. But, it
couldn't hurt to try the patch.

I'll try upgrading him to ver 59 of the workstations firmware to see if
it helps.

JE

Re: [Linux-ia64] Re: IA-64 XFree86 (was: XFree 4.0.1 module loading)

[Johannes Erdfelt]

On Tue, Aug 22, 2000, Johannes Erdfelt <jerdfelt@valinux.com> wrote:
> I'll try upgrading him to ver 59 of the workstations firmware to see if
> it helps.

Build 59 still has the same problem. I'm curious if this could be caused
by a hardware problem? The machine locked up while reading the image off
of the floppy in EFI as well as at the "hit any other key to continue"
prompt in the startup.nsh script.

The machine seems stable in Linux (compiling the kernel, etc) so I was
quite surprised to see those 2 lockups.

JE

Re: [Linux-ia64] Re: IA-64 XFree86 (was: XFree 4.0.1 module loading)

[David Mosberger]

A hardware problem is certainly a possibility.  We really haven't seen
any problems with PCI access once the kernel buffer overflow was
fixed.  It was working well even before upgrading to the latest fw.
Do you have another machine you could try?

	--david

>>>>> On Tue, 22 Aug 2000 15:07:10 -0700, Johannes Erdfelt <jerdfelt@valinux.com> said:

  Johannes> On Tue, Aug 22, 2000, Johannes Erdfelt
  Johannes> <jerdfelt@valinux.com> wrote:
  >> I'll try upgrading him to ver 59 of the workstations firmware to
  >> see if it helps.

  Johannes> Build 59 still has the same problem. I'm curious if this
  Johannes> could be caused by a hardware problem? The machine locked
  Johannes> up while reading the image off of the floppy in EFI as
  Johannes> well as at the "hit any other key to continue" prompt in
  Johannes> the startup.nsh script.

  Johannes> The machine seems stable in Linux (compiling the kernel,
  Johannes> etc) so I was quite surprised to see those 2 lockups.

Re: [Linux-ia64] Re: IA-64 XFree86 (was: XFree 4.0.1 module loading)

[Johannes Erdfelt]

[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]

On Mon, Aug 21, 2000, David Mosberger <davidm@hpl.hp.com> wrote:
>   Mark> 2) No mechanism for the X-server to write combine memory and
>   Mark> no discussions on adding this to Linux as far as I can tell.
>   Mark> There needs to be a new flag to open() or mmap().  There
>   Mark> aren't any MTRRs.
> 
> I submitted a patch for the tdfx DRM module to map non-AGP stuff as
> write-combined (actually, I'm not 100% sure this is the right thing to
> do here; a DRM expert may want to double check this; it does seem to
> work fine on my machine).  See the latest Linux kernel patch.
> 
> Linus already agreed that it would be OK to add additional mmap()
> flags to indicate the memory attribute (normal vs. write-combine
> vs. uncached).  Walt says a patch to do this was developed as part of
> the XFree86 4.0 work at VA and promised to send me a patch.  I don't
> think I have received such a patch, but I'd be happy to merge it
> in. ;-)

Now that we have a stable platform, we were able to test the patch and
confirm the patch wasn't causing the stability problems we were seeing.

This gets a 3 times speed improvement over non write combined memory in
the tests Mark performed.

The patch is against 2.4.0-test9-ia64-001004

JE


[-- Attachment #2: mmap-wrcomb-noncached.patch --]
[-- Type: text/plain, Size: 2608 bytes --]

diff -ur linux-2.4.0-test9.orig/drivers/char/mem.c linux-2.4.0-test9/drivers/char/mem.c
--- linux-2.4.0-test9.orig/drivers/char/mem.c	Mon Sep 25 15:26:56 2000
+++ linux-2.4.0-test9/drivers/char/mem.c	Thu Oct 26 15:31:18 2000
@@ -198,8 +198,12 @@
 	 * through a file pointer that was marked O_SYNC will be
 	 * done non-cached.
 	 */
-	if (noncached_address(offset) || (file->f_flags & O_SYNC))
+	if (noncached_address(offset) || (file->f_flags & O_SYNC) ||
+	    vma->vm_flags & VM_NONCACHED)
 		vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+
+	if (vma->vm_flags & VM_WRITECOMBINED)
+		vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
 
 	/*
 	 * Don't dump addresses that are not real memory to a core file.
diff -ur linux-2.4.0-test9.orig/include/asm-ia64/mman.h linux-2.4.0-test9/include/asm-ia64/mman.h
--- linux-2.4.0-test9.orig/include/asm-ia64/mman.h	Fri Apr 21 15:21:24 2000
+++ linux-2.4.0-test9/include/asm-ia64/mman.h	Thu Oct 26 15:04:01 2000
@@ -24,6 +24,9 @@
 #define MAP_LOCKED	0x2000		/* pages are locked */
 #define MAP_NORESERVE	0x4000		/* don't check for reservations */
 
+#define MAP_WRITECOMBINED 0x10000	/* Write combine the area */
+#define MAP_NONCACHED	0x20000		/* Don't cache the memory */
+
 #define MS_ASYNC	1		/* sync memory asynchronously */
 #define MS_INVALIDATE	2		/* invalidate the caches */
 #define MS_SYNC		4		/* synchronous memory sync */
diff -ur linux-2.4.0-test9.orig/include/linux/mm.h linux-2.4.0-test9/include/linux/mm.h
--- linux-2.4.0-test9.orig/include/linux/mm.h	Mon Oct  2 11:01:19 2000
+++ linux-2.4.0-test9/include/linux/mm.h	Thu Oct 26 15:30:56 2000
@@ -96,6 +96,9 @@
 #define VM_DONTCOPY	0x00020000      /* Do not copy this vma on fork */
 #define VM_DONTEXPAND	0x00040000	/* Cannot expand with mremap() */
 
+#define VM_WRITECOMBINED 0x00100000	/* Write combined */
+#define VM_NONCACHED	0x00200000	/* Noncached access */
+
 #define VM_STACK_FLAGS	0x00000177
 
 #define VM_READHINTMASK			(VM_SEQ_READ | VM_RAND_READ)
diff -ur linux-2.4.0-test9.orig/mm/mmap.c linux-2.4.0-test9/mm/mmap.c
--- linux-2.4.0-test9.orig/mm/mmap.c	Tue Aug 29 12:41:12 2000
+++ linux-2.4.0-test9/mm/mmap.c	Mon Oct 30 11:01:13 2000
@@ -151,6 +151,12 @@
 		_trans(prot, PROT_WRITE, VM_WRITE) |
 		_trans(prot, PROT_EXEC, VM_EXEC);
 	flag_bits =
+#ifdef MAP_WRITECOMBINED
+		_trans(flags, MAP_WRITECOMBINED, VM_WRITECOMBINED) |
+#endif
+#ifdef MAP_NONCACHED
+		_trans(flags, MAP_NONCACHED, VM_NONCACHED) |
+#endif
 		_trans(flags, MAP_GROWSDOWN, VM_GROWSDOWN) |
 		_trans(flags, MAP_DENYWRITE, VM_DENYWRITE) |
 		_trans(flags, MAP_EXECUTABLE, VM_EXECUTABLE);