IA-64 XFree86 (was: XFree 4.0.1 module loading)
Subsystems (4)
Quoted 3 lines
First, I ask David Dawes or Keith Packard to set up an XFree86-internal mailing list, say [email protected]. 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.
[email protected] XFree86 Core Team SuSE, Inc.
Quoted 11 lines · Keith Packard
Quoted 3 lines
First, I ask David Dawes or Keith Packard to set up an XFree86-internal mailing list, say [email protected]. 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: [email protected] | | University of Alberta +-----------------------------------+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply | | CANADA | | +----------------------------------+-----------------------------------+ XFree86 Core Team member. ATI driver and X server internals.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Marc" = Marc Aurele La France <[email protected]> writes:
Quoted 2 lines · Keith Packard
Quoted 2 lines
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
Quoted 10 lines · Marc Aurele La France
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.
Quoted 8 lines · Jes Sorensen
Quoted 2 lines
Quoted 2 lines
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: [email protected] | | University of Alberta +-----------------------------------+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply | | CANADA | | +----------------------------------+-----------------------------------+ XFree86 Core Team member. ATI driver and X server internals.
Quoted 2 lines · Mark Vojkovich
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...)
Quoted 3 lines
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
Quoted 7 lines · Bill Nottingham
Quoted 2 lines · Mark Vojkovich
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?
Quoted 7 lines
Quoted 4 lines
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.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Mark Vojkovich
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
Quoted 9 lines · David Mosberger
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Mark Vojkovich
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/devicesnot 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.
Quoted 11 lines
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()ormmap(). 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.
Quoted 8 lines · Mark Vojkovich
Quoted 5 lines · David Mosberger
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Mark Vojkovich
Mark> 1) Firmware issues that prevent the X-server from working Mark> reliably with SMP (even lspci locks up in the SAL code).
Quoted 7 lines
Quoted 4 lines
As Bill already pointed out, we have seen any problems since we fixed
/proc/bus/pci/devicesnot 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
Quoted 2 lines · Johannes Erdfelt
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
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
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Johannes Erdfelt
Johannes> On Tue, Aug 22, 2000, Johannes Erdfelt
Quoted 2 lines · Johannes> <[email protected]> wrote:
Quoted 2 lines
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.
Quoted 10 lines · David Mosberger
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()ormmap(). 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.
Quoted 6 lines
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
drivers/char/mem.c +5 -1
@@ -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.
include/asm-ia64/mman.h +3 -0
@@ -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 */
include/linux/mm.h +3 -0
@@ -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)
mm/mmap.c +6 -0
@@ -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 );