Business inquiry.
Hello, I was wondering if you were interested in our products. We supply new OEM printer cartridges at wholesale prices. I am sure we can save you money on your printer supplies. Should you have any questions please feel free to contact me. I have included a brief product price list. Sincerely, John Smirley Sales Manager 888-662-2256 [EMAIL PROTECTED] www.gtlaser.com HP Laser Toner Description Price per unit 1 HP C3906A US$51.50 2 HP C4092A US$51.75 3 HP C3903A US$62.75 4 HP 92274A US$70.75 5 HP 92298A US$73.95 6 HP C4096A US$76.25 7 HP 4127X US$96.50 8 HP 4129X US$126.75 9 HP C3900A US$109.00 10 HP 3909A US$135.50 10A HP C4182X US$139.50 11 HP 7115A US$54.50 12 HP 8061X US$96.75 13 HP Q series 2612 US$54.75 14 HP Q series 2613 US$59.95 15 HP Q series 2610 US$93.75 HP Inkjet Cartridge Description Price per unit 1 HP C6625A (Color) US$23.79 2 HP 51645A (Black) US$22.70 3 HP 51649A (Color) US$23.50 4 HP C1823D (Color) US$25.45 5 HP C6614D (Black) US$21.65 6 HP C6615D (Black) US$21.60 7 HP C6578D (Color) US$25.30 8 HP 51626A (Black) US$22.90 9 HP 51629A (Black) US$22.90 14 HP 6657A (Color) US$25.65 ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Added Pseudocolor Visuals for XFree86?
Title: Added Pseudocolor Visuals for XFree86? At Boeing we have a number of graphics applications that have been developed in-house, originally for various SGI platforms. These applications are used for engineering visualization They work well on the native hardware and even display well across the network using third party applications under Windows like Hummingbird's ExCeed 3D. However, under Linux, the fail to work properly, either natively or via remote display with the original SGI hardware acting as server, due to omissions in the available Pseudocolor Visuals. Examination of the output of xdpyinfo in the SGI machines shows that the SGI X drivers support Pseudocolor visuals at both 8 bit planes and 12 bit planes. Similar output under Linux shows support for Pseudocolor Visuals at only 8 bit planes. These applications were built to take advantage of the 12 bit plane Pseudocolor Visual under the SGI X drivers. To allow use of these graphics applications within a Linux environment, we're contemplating a port of the applications to Directcolor Visuals. But prior to initiating such an activity, I've been asked to ask whether new developments or releases of the XFree86 X drivers might be in the pipeline for future release that might offer a wider variety of Pseudocolor Visuals. Hence this note. Is there any support for 12 bit plane Pseudocolor Visuals within at least one video card and the XFree86 drivers? Will there be support for such features in the future? If so, is there an anticipated release date? Thank you. John Bussoletti John Bussoletti Enabling Technology and Research Boeing Commercial Airplane Group Email: john.e.[EMAIL PROTECTED] Phone: (425) 234-1278
RE: Added Pseudocolor Visuals for XFree86?
Title: Message Tim, Thanks for the info, but I'm left a bit puzzled. Under Windows with the ExCeed 3D X windows server, using the same hardware that we've got under Linux, we're at least able to use the Windows screen to display the 12 bit Pseudocolor Visual screen correctly. WIth Linux and the XFree86 drivers, we can only do so using an 8 bit plane Pseudocolor visual which results in mis-mapped colors when the color scale is exceeded. So ExCeed 3D must be doing something that the XFree86 drivers don't do. Do you have any idea what it might be? One possiblility is to pursue a contract with Hummingbird... John Bussoletti -Original Message-From: Tim Roberts [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 4:24 PMTo: [EMAIL PROTECTED]Subject: Re: Added Pseudocolor Visuals for XFree86?Bussoletti, John E wrote: At Boeing we have a number of graphics applications that have been developed in-house, originally for various SGI platforms. These applications are used for engineering visualization They work well on the native hardware and even display well across the network using third party applications under Windows like Hummingbird's ExCeed 3D. However, under Linux, the fail to work properly, either natively or via remote display with the original SGI hardware acting as server, due to omissions in the available Pseudocolor Visuals. Examination of the output of xdpyinfo in the SGI machines shows that the SGI X drivers support Pseudocolor visuals at both 8 bit planes and 12 bit planes. Similar output under Linux shows support for Pseudocolor Visuals at only 8 bit planes. These applications were built to take advantage of the 12 bit plane Pseudocolor Visual under the SGI X drivers. To allow use of these graphics applications within a Linux environment, we're contemplating a port of the applications to Directcolor Visuals. But prior to initiating such an activity, I've been asked to ask whether new developments or releases of the XFree86 X drivers might be in the pipeline for future release that might offer a wider variety of Pseudocolor Visuals. Hence this note. Is there any support for 12 bit plane Pseudocolor Visuals within at least one video card and the XFree86 drivers? Will there be support for such features in the future? If so, is there an anticipated release date?The problem is not XFree86, the problem is technology. I'm not aware of ANY commodity graphics chips that support a 12-bit palettized video display mode. That's mostly because Windows doesn't handle it, and if Windows doesn't handle it, there is no business case for developing it in hardware.Assuming there was such a chip, there are no architectural barriers to supporting it in XFree86..-- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc.
RE: Added Pseudocolor Visuals for XFree86?
Ian, What I mean is the application is running on the SGI platform and displaying on a screen across the network. Running on identical hardware, under Window/ExCeed's X server, the application works correctly. Running under Linux/XFree86 X server, it only displays at 8 bit planes and when the color map overflows, the display is not colored correctly. So somehow Windows/ExCeed seems to be doing a bit more in emulating capabilities that aren't being provided by the Xfree 86 driver. John Bussoletti -Original Message- From: Ian Romanick [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 4:37 PM To: [EMAIL PROTECTED] Cc: Wollen, Douglas B; Jorstad, Ralph G Subject: Re: Added Pseudocolor Visuals for XFree86? Bussoletti, John E wrote: At Boeing we have a number of graphics applications that have been developed in-house, originally for various SGI platforms. These applications are used for engineering visualization They work well on the native hardware and even display well across the network using third party applications under Windows like Hummingbird's ExCeed 3D. However, under Linux, the fail to work properly, either natively or via remote display with the original SGI hardware acting as server, due to omissions in the available Pseudocolor Visuals. The X terminology is a little different than most people expect, so I want to ask for some clarification. By SGI hardware acting as server do you mean the application is running on the SGI and displaying on the Linux system, or the application is running on the Linux system and displaying on the SGI? In X terminology, the server (i.e., X-server) is where ever the stuff is being displayed. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: radeon driver breaking LCD brightness control?
Andrew C Aitchison wrote: Can you try XFree86 4.4, to see whether this has been fixed since 4.3 ? Fortunately, I found a usable Debian package of XFree86 4.4 (http://ftp.fifi.org/debian-local/stable/unofficial/), which probably saved me several days of work. Yes, the problem seems to have been fixed since 4.3. I think it may be worth tracking this down, because I don't know if 4.4 will make it to the Debian Sarge release. How extensive are the radeon changes between 4.3 and 4.4? -John -- http:// ift ile.org/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
radeon driver breaking LCD brightness control?
Hello, I'm the author of the toshiba_acpi Linux driver, which allows control of LCD brightness on some Toshiba laptops. After upgrading from XFree86 4.2.1 to 4.3.0.1 on my laptop (Toshiba Libretto L5 with Radeon M6), a bizarre problem has started: if I switch to the console and back to X, my driver is no longer able to adjust the LCD brightness until the next machine reboot. The driver operates by using the ACPI extensions for display adapters defined in the appendix of the ACPI spec. I'm not sure how, but I suspect that the radeon driver may be causing the problem. I'm wondering if anyone has heard of a problem like this, or if some relevant bug fix has been made to the radeon driver since XFree86 4.3. -John Belmonte -- http:// ift ile.org/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: radeon driver breaking LCD brightness control?
Alex Deucher wrote: It probably is the radeon driver. Unfortunately, xfree86 and it's drivers have no knowledge of acpi at the moment. probably some acpi related regs do not get properly saved by the server. Can you suggest how I might get to the bottom of this? I didn't have the problem in 4.2.1 but, as there are so many changes to the driver between 4.2.1 and 4.3.0, I don't know where to look. I'm not familiar with the radeon code or XFree86 display driver framework at all. -John -- http:// ift ile.org/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
ibm526 ramdac support for s3 968
Hi,
I have two old Diamond Stealth 64 VRAM cards that use the IBM 526 RAMDAC.
This patch makes XFree86 work on it again. The relevant pieces of the log
file look like this:
(II) s3(0): VESA VBE OEM: Diamond Stealth 64 Video VRAM
(--) s3(0): Attached RAMDAC is IBM 526
(--) s3(0): MCLK 74.286 MHz
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
diff -ur org/xc/programs/Xserver/hw/xfree86/drivers/s3/s3_driver.c
xc/programs/Xserver/hw/xfree86/drivers/s3/s3_driver.c
--- org/xc/programs/Xserver/hw/xfree86/drivers/s3/s3_driver.c Thu Sep 25 13:05:02
2003
+++ xc/programs/Xserver/hw/xfree86/drivers/s3/s3_driver.c Sat Jan 24 16:50:37
2004
@@ -171,6 +171,8 @@
RamDacSupportedInfoRec S3IBMRamdacs[] = {
{ IBM524_RAMDAC },
{ IBM524A_RAMDAC },
+ { IBM526_RAMDAC },
+ { IBM526DB_RAMDAC },
{ -1 }
};
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: What is DCC?
On Sat, 2004-02-28 at 19:14 -0500, D. Hugh Redelmeier wrote: A google search seems to find a lot of references to DCC in places where I'd have thought DDC was correct. One is in the heading of section 4.8.1 in http://fun.bestdsl.net/~jlhimpel/XFree86/ReleaseNotes-Ovr-of-XFr.html#id2981945 === That's a typo on my part. Sorry. I'll have that fixed in a moment. PS: The new url s/b http://www.XFree86.Org/~jwhimpel/html/ReleaseNotes. html John === Is this a mistake, or is there something like DDC that is called DCC? Hugh Redelmeier [EMAIL PROTECTED] voice: +1 416 482-8253 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
typo in 4.4.0 pre-Release Notes, font style comment
I found the link to the DocBook pre-release note for 4.4 on XFree86.org http://www.xfree86.org/~jwhimpel/html/ReleaseNotes-Smm-of-Upd.html says: On Darwin, IOKit mode now used shadowfb for must faster drawing. I think that should be now uses shadowfb for much faster drawing. Since I'm here, I don't think system names like Darwin and GNU/KNetBSD should appear in Courier, which is how my Mac Mozilla 1.6b displays tt class=systemitemDarwin/tt I would use tt for things you're likely to see in computer output like filenames and resources, use kbd for options you type, and use something else (cite?) for system names. Congratulations on the nearly-ready release. These are my opinions, not my employer's. -- =S Page Thank you for catching my typo. It will be fixed in my next upload. As for the font suggestion. I am currently using the systemitem class='osname' tag for Operating System Name markup. I am trying to stick as close as possible to the standard XSL stylesheets for DocBook 4.3 for rendering to HTML. Currently I view my task as completing the markup and publishing in at least a readable format, then on a subsequent pass begin to work on any XFree86 changes to either the markup or stylesheets. So for now, the Operating System names will appear as shown. Later, I am open for suggestions such as yours. Again, thanks for taking the time to provide this valuable feedback. John PS: Pardon my breaking the thread, but my new bleeding-edge mailer, has Mark as important Mark as Junk in its menu. I guess, I misses by a few pixels and the original message is gone into the ether. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DocBook pre-Release Notes
On Thu, 2004-02-12 at 19:30 -0500, georgina o. economou wrote: Yep I see that the double comma is gone but now there's a space between the name and comma. So a typical line in the credits section looks like: General Integration of Submissions: Egbert Eich , David H. Dawes , Ivan Pascal , Alan Hourihane , Matthieu Herrb Was that the intent? No, but that was the effect. I just re-published without the space preceding the comma. If you want the semi-colons that are in the subsections removed, I can easily do that too. I just reproduced the original. But I agree that it does look a bit odd. John ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DocBook pre-Release Notes
On Wed, 2004-02-11 at 17:33 -0500, georgina o. economou wrote: Hi, I was going thru the Release Notes for 4.4 and I noticed that there are double commas in section 5,1 thru 5.4 where all the submitters names are. I also think the colon on the TOC after section 5 looks wild. Perhaps I am unfamiliar with the formatting of LinuxDoc but to me a colon should mean that the list directly follows, not that it points to a section. And btw, I like the little finger for a NOTE. Other than that John, I like it. Georgina, 1) The double comma is an oops on my part. I will publish a fix in about an hour. 2) The semi-colon in the TOC is just following mimicing from the official CVS version. titleNew Features, Enhancements and Updates:/title. 3) The graphics are standard DocBook graphics. I have seen some others for tip/note/warning/caution/next/previous/home/up that are much prettier than the standard issue DocBook ones, but the license prohibits their usage (GPL or GFDL). If you know a good graphics artist/designer, you can do some good stuff. For an example, you might look at https://www.redhat.com/docs/manuals/linux/RHL-9-Manual/install-guide/ch- intro.html. Again there are licensing restrictions with these, but they show what can be done. John ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: PCI Express
On Tue, 2004-02-03 at 17:37, Marc Aurele La France wrote: PCI-Xpress is programmatically identical to PCI, so I don't forsee any problems in that regard. Yes, its identical to PCI in terms of the interface presented to the OS so configuration probably won't be an issue, but there is code in hw/xfree86/os-support/bus that attempts to walk the bus topology with explicit knowledge of current PCI bridges. I don't believe this code will execute correctly, but I assume it can be easily defeated, yes? But thats probably less of an issue than the fact PCIE systems demand new PCIE cards and that means driver support. If we are fortunate the new PCIE cards might be pragmatically compatible with with current cards and XFree86 will only need to recognize the new cards, but I really doubt that will be the case. ATI, nvidia, 3DLabs have all announced support for PCIE and pledged it will bring dramatic performance increases. Some of that will be due to the faster bus, but I've got to believe these new cards will feature architectural changes as well demanding new driver support. Bottom line, I've been asked if XFree86 will be able to support PCIE systems due to arrive in a few months or if these systems are going to be dead in the water for open source for anything other than a server. So I'm digging for what people know or believe the issues are. John ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
PCI Express
In a few months PCI Express (PCIE) will hit the streets. My understanding is that some system vendors are building system boards without any AGP slots. As far as I know that means only an old style PCI graphics card will work (PCIE is fully compatible with PCI), or a new PCIE card. Does anybody know to what extent PCIE will be supported by XFree86 and in what timeframe? I found a preliminary release note for the Radeon driver in 4.4 that in a PCIE system it will fall back to PCI and should work. But I'm guessing that DRI and other components that use AGP will be crippled in this environment, right? I'm also aware the XFree86 server likes to roam around and touch things like PCI bridges, I'm wondering how this code will play in a PCIE system. Have any of the XFree86 developers been seeded with PCIE systems and graphics cards and are working on this? What is the extent of changes anticipated to support PCIE only systems? And if so what's the timeframe? -- John Dennis [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Conversion of README's to DocBook Format
Greetings, I have been laboring in the background for about 18 months converting the README files from linuxdoc format to DocBook format. I believe I have nearly completed that effort. My efforts are currently stored in a separate cvs instance at XFree86.Org. During that time, some bit-rot of the documentation has occurred, but it should be a very small task to bring the DocBook versions to currency. It is time to begin submitting the infrastructure necessary to support the conversion (tools, DTD, stylesheets, etc) to XFree86 for inclusion into the main cvs instance. Since this involves over 1800 files, submitting them via Bugzilla or mailing lists as individual files is quite impractical (I have a gift for seeing the obvious) :-] I would like group the files into logical components and submit them as tar files. David Dawes and I have exchanged emails on the doc list and have come to an agreement as to placement of the logical groups in cvs. To whom or to where should I submit the tar files? After the infrastructure is completely in place, I will begin submitting the converted README files. Since there will be some stylistic changes in the output, I plan to start by submitting the converted XFree86 4.4 Release Notes, the New Design document, and the README.ati document. I chose these because they represent different styles of documents and will present good examples for discussion of any requested changes to style. Questions and comments are encouraged. John ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
(no subject)
___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Is it possible to move application displays between hosts?
Hello, occassionally we have users login to RedHat Linux machines who have started applications that they would like to keep running in the background while someone else uses the machine. So, say I start a program we have here for one of our microscopes and it is in the midst of processing data. However, someone else needs to be on this machine to capture data. Can I tell the machine to display the graphical interface for this program on another machine once the program has started? I know it is possible to change the DISPLAY variable and xhost + on the other machine. But if the program is already running, is it possible to do the equivalent? If this isn't possible currently, it would be a really great thing to have in the future. Thanks in advance, John ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
DRI proprietary modules
For DRI to work correctly there are several independent pieces that all have to be in sync. * XFree86 server which loads drm modules (via xfree86 driver module) * The drm kernel module * The agpgart kernel module Does anybody know for the proprietary drivers (supplied by ATI and Nvidia) which pieces they replace and which pieces they expect to be there? The reason I'm asking is to understand the consequences of changing an API. I'm curious to the answer in general, but in this specific instance the api I'm worried about is between the agpgart kernel module and drm kernel module. If the agpgart kernel module modifies it's API will that break things for someone who installs a proprietary 3D driver? Do the proprietary drivers limit themselves to mesa driver and retain the existing kernel services assuming the IOCTL's are the same? Or do they replace the kernel drm drivers as well? If so do they manage AGP themselves, or do they use the systems agpgart driver? Do they replace the systems agpgart driver? -- John Dennis [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] Deadlock with radeon DRI
The locking problem is solved, my original analysis was incorrect. The
problem was that DRM_CAS was not correctly implemented on IA64. Thus
this was an IA64 issue only, this is consistent with others who showed
up in a google search describing the problem, all were on IA64.
I have filed an XFree86 bug report on this. I could not find a DRI
specific bug reporting mechanism other than the dri-devel list.
The IA64 implementation of CAS was this:
#define DRM_CAS(lock,old,new,__ret) \
do { \
unsigned int __result, __old = (old); \
__asm__ __volatile__( \
mf\n\
mov ar.ccv=%2\n \
;;\n\
cmpxchg4.acq %0=%1,%3,ar.ccv\
: =r (__result), =m (__drm_dummy_lock(lock)) \
: r (__old), r (new) \
: memory); \
__ret = (__result) != (__old);\
} while (0)
The problem was with the data types given to the cmpxchg4
instruction. All of the lock types in DRM are int's and on IA64 thats
4 bytes wide. The digit suffix cmpxchg4 signifies this instruction
operates on a 4 byte quantity. One might expect then since this
instruction operates on 4 byte values and in DRM the locks are 4 bytes
everything is fine, but it isn't.
The cmpxchg4 instruction operates this way:
cmpxchg4 r1=[r3],r2,ar.ccv
4 bytes are read at the address pointed to by r3, that 32 bit value is
then zero extended to 64 bits. The 64 bit value is then compared to
the 64 bit value stored in appliation register CCV. If the two 64 bit
values are equal then the least significant 4 bytes in r2 are written
back to the address pointed to by r3. The original value pointed to by
r3 is stored in r1. The entire operation is atomic.
The mistake in the DRM_CAS implemenation is that the comparison is 64
bits wide, thus the value stored in ar.ccv (%2 in the asm) must be 64
bits wide and for us that means zero extending the 32 bit old
parameter to 64 bits.
Because of the way GCC asm blocks work to tie C variables and data
types to asm values the promotion of old from unsigned int to
unsigned long was not happening. Thus when old was stored into
ar.ccv its most significant 32 bits contained garbage. (Actually
because of the way GCC generates constants it turns out the upper 32
bits was 0x, this was from the OR of DRM_LOCK_HELD which is
defined as 0x8000, but the compiler generates a 64 bit OR
operation using the immediate value 0x8000, which is legal
because the upper 32 bits are undefined on int (32 bit) operations).
The bottom line is that the test would fail when it shouldn't because
the high 32 bits in ar.ccv were not zero.
One might think that because old was assigned to __old in a local
block which was unsigned int the compiler would know enough when using
this value in the asm to have zero extended it. But that's not true,
in asm blocks its critical to define the asm value correctly so the
compiler can translate between the C code variable and what the asm
code is referring to.
The line:
: r (__old), r (new)
says %2 is mapped by r (__old), in other words put __old in a
general 64 bit register. We've told the compiler to put 64 bits of
__old into a register, but __old is a 32 bit value with its high
order 32 bits undefined. We need to tell the compiler to widen the
type when assigning it to a general register, thus the asm template
type definition needs to be modified with a cast to unsigned long.
: r ((unsigned long)__old), r (new)
Only with this will the compiler know to widen the 32 bit __old value
to 64 bits inside the asm code.
Thanks to Jakub Jelinek who helped me understand the nuances of GCC
asm templates and type conversions.
As a minor side note, definitions of bit flags should be tagged as
unsigned. Thus things like:
#define DRM_LOCK_HELD 0x8000
#define DRM_LOCK_CONT 0x4000
should really be:
#define DRM_LOCK_HELD 0x8000U
#define DRM_LOCK_CONT 0x4000U
John
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
How to kick off a accelerate draw operation in source code
Hi all, I am writing a customerized graphic card driver in xfree86, and I refered to NV dirver, I can find that NVSetupForSolidLine and NVSubsequentSolidHorVertLine .. functions to manipulate the HW register, I wonder that it is just filling some data in the registers, I want to know when and which instruction kick off the draw operation. Please give me some clue. _ MSN Hotmail http://www.hotmail.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Deadlock with radeon DRI
[Note: this is cross posted between dri-devel and [EMAIL PROTECTED] ] I'm trying to debug a hung X server problem with DRI using the radeon driver. Sources are XFree86 4.3.0. This happens to be on ia64, but at the moment I don't see anything architecture specific about the problem. The symptom of the problem is the following message from the drm radeon kernel driver: [drm:radeon_lock_take] *ERROR* x holds heavyweight lock where x is a context id. I've tracked the sequence of events down to the following: DRIFinishScreenInit is called during the radeon driver initialization, inside DRIFinishScreenInit is the following code snippet: /* Now that we have created the X server's context, we can grab the * hardware lock for the X server. */ DRILock(pScreen, 0); pDRIPriv-grabbedDRILock = TRUE; Slightly later on RADEONAdjustFrame is called and it does the following: #ifdef XF86DRI if (info-CPStarted) DRILock(pScrn-pScreen, 0); #endif Its this DRILock which is causing the *ERROR* x holds heavyweight lock message. The reason is both DRIFinishScreenInit and RADEONAdjustFrame are executing in the server and using the servers DRI lock. DRIFinishScreenInit never unlocks, it sets the grabbedDRILock flag, big deal, no one ever references this flag. When RADEONAdjustFrame calls DRILock its already locked because DRIFinishScreenInit locked and never unlocked. The dri kernel driver on the second lock call then suspends the X server process (DRM(lock_take) returns zero to DRM(lock) because the context holding the lock and context requesting the lock are the same, this then causes DRM(lock) to put the X server on the lock wait queue). Putting the X server on the wait queue waiting for the lock to be released then deadlocks the X server because its the process holding the lock on its context. Questions: The whole crux of the problem seems to me the taking and holding of the lock in DRIFinishScreenInit. Why is this being done? I can't see a reason for it. Why does it set a flag indicating its holding the lock if nobody examines that flag? Is suspending a process that already holds a lock during a lock request really the right behavior? Granted, a process thats trying to lock twice without an intervening unlock is broken, but do we really want to deadlock that process? Any other insights to this issue? FWIW, I googled for this error and came up with several folks who starting around last spring started seeing the same problem, but none of the mail threads had a follow up solution. Thanks, John ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XmuPrintEvent anyone?
I was thinking a very useful function in line with everything else Xmu provides would be an XmuPrintEvent(XEvent *ev, FILE *stream); which would print information about the event to stream in the same format as xev. I was able to liberate the code for the core protocols from xev and the code to print XKB events from xkbevd.c, but this seems like a generally useful thing.. does this already exist? would patches implementing it be accepted? or has Xmu been given up on. John -- --- John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED] --- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: setjmp needs fixing again, here's the issues
On Wed, 2003-09-10 at 20:11, David Dawes wrote: John wrapper. So as long as we've already lost module John independence by virtue of linking the system function why John not go all the way and use the system definition of the John system function's argument? It seems like David We haven't lost module independence by doing that. Perhaps I'm misunderstanding module independence, can you confirm or deny some of the assumptions I've been working with: 1) System specific functions are wrapped in an xf86* wrapper so that: a) system differences are isolated at a single point which provides a common interface to the rest of the server b) all system specific functions are wrapped and live in the executable XFree86. The XFree86 executable is linked against the system libraries and hence the XFree86 executable is not system independent. 2) module independence derives from the following: a) modules only link against (e.g. import) from the XFree86 executable that loaded it. In other words all system specific elements are contained in the executable, not a loaded module. b) The executable and modules share the same linking, relocation, exception, and call conventions. This makes a module mostly system independent, but not 100%, e.g. its possible, but not common, for different OS's on the same architecture to have a different ABI, but less common today as the industry is converging on standardized ABI's. Is the above basically correct? If so then by directly linking a reference to the system's setjmp call in a module haven't we violated the notion that only the main executable has dependencies on the system libraries? The module is now making a call whose parameters and behavior is specific to the system. Actually, more correctly, its specific to the how the main executable was linked (which is system specific), see below for why this is true. David All that matters is that the jmp_buf type be defined on David each architecture in such a way that it meets the David requirements of all the supported OSs on that architecture. David Newer architectures are more likely to have a David platform-independent ABI anyway than was necessarily true David in the past. If the platform's setjmp.h can define the David type with the correct alignment, then so can we. It David doesn't matter if the methods for doing this are David compiler-specific. If the 128-bit alignment is an IA64 ABI David requirement, then I'd expect that all complilers for IA64 David will have a method for defining jmp_buf with the correct David alignment. If I following your reasoning then you would be happy with this definition in xf86_libc.h /* setjmp/longjmp */ #if defined(__ia64__) typedef int xf86jmp_buf[1024]; __attribute__ ((aligned (16))); /* guarantees 128-bit alignment! */ #else typedef int xf86jmp_buf[1024]; #endif But if one is going to special case the definition of jmp_buf based on architecture why not use the system definition and typedef xf86jmp_buf to be jmp_buf? I suspect the answer will be that the system libraries could change requiring a different size buffer. I'd buy that if it weren't for the fact we are directly linking the library specfic version of setjmp into the module. Why a module referencing setjmp is tied to a specific system library: - As far as I can tell we've tied the module to a specific system library. Here is why I believe this. I'm going to simplify the discussion by assming there is only one xf86set_jmp symbol and ignore the type 0 and type 1 variants that select setjmp or sigsetjmp. 1) a module makes a reference to xf86set_jmp. 2) the xfree86 loader when it loads that module searches for that symbol in its hash table of symbols, that table was populated in part by the table in xf86sym.c which in a loadable build contains this definition in the main executable: #include setjmp.h SYMFUNCALIAS(xf86setjmp,setjmp) 3) the above definition means when the symbol name xf86setjmp is looked up by the loader it will get the address of setjmp that was linked into the main executable. This is the function address that the xfree86 loader will insert into module during its relocation phase. 4) How does the address of setjmp get into the main executable? It depends on whether the main executable was statically or dynamically linked, but in either case the system will assure it comes from a specific version of the library defined at the time the main executable was linked. 5) Therefore when a module that referenced setjmp is called its calling the system version of setjmp in the exact library when the main executable was linked. I don't see how the above satisfies the conception of module independence and by extension the avoidence of using
Re: setjmp needs fixing again, here's the issues
On Thu, 2003-09-11 at 14:35, David Dawes wrote:
What's the difference between this in the core executable:
xf86A(pointer data)
{
return A(data);
}
SYMFUNC(xf86A)
and this:
SYMFUNCALIAS(xf86A, A)
The difference is that xf86A may massage data in some system specific
manner specific to the libraries the main executable is linked against.
Examples might include parameters to mmap where the base address and
size have to be adjusted for page boundaries and the mapping flags
passed. Or anything passed into an ioctl. I don't think the current set
of wrapped functions includes anything of this nature, but I thought it
was the principle behind it.
Module independence comes from providing a more uniform ABI to the
modules than you might get by linking directly with the functions provided
by the system libraries.
Isn't that what I'm saying above? Xfree86 imposes its own interface
leaving the wrappers to translate when the underlying system differs.
Perhaps just as importantly since the wrappers are in the main
executable, which is the ONLY place loadable object dependencies are
enforced, its the only place you can be guaranteed that you'll be linked
to the version of shared object you're expecting!
If I following your reasoning then you would be happy with this
definition in xf86_libc.h
Yes.
O.K. I'll make this patch and put it in the bugzilla. I'm not completely
happy with it because its not really addressing the root problem. Setjmp
may blow up on some other system in the future because we're ignoring
the system defined requirements. For example in the non-ia64 case
xf86jmp_buf will only be aligned on int boundaries, what if a system
needs long alignment, or some other requirement?
I'll grant that what we're going with setjmp is a little hairy, but I
haven't seen anything so far that says the basic approach doesn't work
or impacts the portability of modules.
Yes, you are right setjmp is a true exception because it can't be
wrapped and thus isolate system specifics outside the module. And you're
also right its a bit hairy, it took me a while to fully understand
exactly what was going on.
As for impacting portability of modules, why isn't the following true?
libc version 1.0 requires 8 byte alignment, server XFree86 A is linked
against this library.
libc version 1.1 requires 16 byte alignment, server XFree86 B is linked
against this library.
The module in theory can be loaded into either XFree86 server A or B.
If the module was built against the libc 1.0 requirement it will fail
when loaded into XFree86 B. This is because unlike the system loader
which enforces the right version of the library to be loaded when
XFree86 is loaded by the system, the module loader does not deal with
version dependencies. In part because the version dependencies in theory
have been isolated in the main executable image via wrappers and
enforced by the system loader. The current setjmp implementation
violates all these assumptions which is why I conclude this negatively
impacts module portability. It is also true that if setjmp were in a
wrapper the module could be loaded into XFree86 server A or B without
issue, but thats not the case, it will crash the server if loaded in
XFree86 server B.
Granted, if we are lucky this may never bite us, there is a reasonable
chance it won't, but on the other hand to assert we haven't lost module
independence and portability is not being honest about the new situation
with modules that import xf86set_jmp.
I'm not saying I have an answer to the problem we've created for
ourselves, but I am saying we need to be honest about the impact, that
any module that imports xf86set_jmp is no longer portable, is tied the
libraries the main XFree86 is linked against, and as such we might as
well use the system definitions of jmp_buf because its the robust
solution and is no more, no less portable than inventing a jmp_buf
abstraction that inherently is not robust. So if you're not getting
portability and independence with the abstraction why sacrifice
robustness?
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
setjmp needs fixing again, here's the issues
I have found the problem with XFree86's implementation of setjmp on ia64. It occurs because we are ignoring the type definition of setjmp's argument. int setjmp(jmp_buf env); In xf86_lib.h we redefine jmp_buf thusly: /* setjmp/longjmp */ typedef int xf86jmp_buf[1024]; #undef jmp_buf #define jmp_buf xf86jmp_buf Based on the discussions that occurred last Feb and March I believe this was done to preserve a loadable modules system independence. The notion being that each system may have a different jmp_buf size, we can't know aprori what that is, so make it bigger than we think is necessary and it should be big enough no matter on what system the module is loaded on. However ignoring the system defined type for jmp_buf we've ignored the system specific alignment requirement of jmp_buf. On ia64 it must be 16 byte aligned because setjmp when it saves the execution context on ia64 uses machine instructions that writes the contents of the 16 byte floating point registers, the destination address must be 16 byte aligned or a SIGBUS fault is signaled. On ia64 you can see in /usr/include/bits/setjmp.h the following jmp_buf definition: /* the __jmp_buf element type should be __float80 per ABI... */ typedef long __jmp_buf[_JBLEN] __attribute__ ((aligned (16))); /* guarantees 128-bit alignment! */ I did an experiment where I defeated the use of xf86jmp_buf and instead used the systems definition of jmp_buf and the SIGBUS problem went away. Earlier I had noted that a static server did not exhibit the problem, thats because the xf86jmp_buf is only used in a loadable build. How do we fix this? --- 1) It may be hard to know the alignment requirements for all OS's and architectures (thats part of the reason we have system header files). We could guess 16 byte is sufficient. But even if we got the alignment requirement right how do we specify the alignment requirement to the compiler in a portable way such that it will build on a variety of systems and compilers? My understanding is that compiler alignment directives are not portable (e.g. not part of ANSI C). Are we comfortable picking one or two common alignment directives and conditionally compiling with the right one? 2) We cannot force alignment without the use of compiler directives for any alignment greater than the maximum size of a basic type by creating artifical structs. This is because in C structs are aligned to the size of the maximum basic type, which on ia64 is 8 (long, double, etc), half the alignment requirement. Plus such a scheme would put us back into guessing type sizes, alignment requrements, etc. It would not be robust. 3) We could use the systems's definition of jmp_buf. That means it will always be correct on the system it was compiled on, but that module may be loaded on another system with potentially different jmp_buf definitions and cause problems. I realize we have a goal of system independence for loadable modules, but do we really expect modules built on one system to be loaded on a significantly different system? They are after all binary modules. I also realize that setjmp is currently the only thing in our loadable modules which is not wrapped by a core server function so it would kind of be a shame to let this one item polute module independence but we have no choice, the loader now links the system implementation of setjmp and not a wrapper. So as long as we've already lost module independence by virtue of linking the system function why not go all the way and use the system definition of the system function's argument? It seems like we would not have lost anything and would have picked up robustness we've given up by trying to use a system neutral definition of the jmp_buf argument. Given the argument in 3 above I'd recommend taking out xf86jmp_buf and putting back in #include stdjmp.h. It seems the simplist, most robust, and in practical terms sacrifices little. Comments? I'm going to file a bugzilla on this, its very definitely broken on ia64 and causes the server to crash. I will put the text of this in the bugzilla. John ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
setjmp wrappers
Remember last Feburary and March there was a big discussion about xf86setjmp? Part of that discussion involved a SIGSEGV or SIGBUS in the freetype2 code when a font was not found. Well, I'm seeing the same thing (on ia64). At the time it was pointed out that one can never wrap setjmp because setjmp has bad behavior if its called from within a function that returns, which is exactly what a wrapper is. The setjmp code was reworked a couple of months ago (in part to account for libc differences). The current implementation has these code fragments: ftstdlib.h: --- #define DONT_DEFINE_WRAPPERS #define DEFINE_SETJMP_WRAPPERS #include xf86_ansic.h #undef DONT_DEFINE_WRAPPERS xf86_libc.h: #if defined(XFree86LOADER) \ (!defined(DONT_DEFINE_WRAPPERS) || defined(DEFINE_SETJMP_WRAPPERS)) #undef setjmp #define setjmp(a) xf86setjmp_macro(a) #undef longjmp #define longjmp(a,b)xf86longjmp(a,b) #undef jmp_buf #define jmp_buf xf86jmp_buf #endif As far as I can tell when one builds the freetype module for the loadable server you're not going to get any wrappers except for setjmp and this is bad because you can't wrap setjmp. As a trial I built both a static and a loadable server. The static server ran fine, but the loadable server dies with a SIGBUS in the freetype code when a setjmp/longjmp is executed. Pretty much what I expected. I'm wondering if I'm missing something, but its a fact you can't wrap setjmp right? And why would you turn off all wrappers except setjmp? Is this really right? I reread the original discussion and part of had to do with how to implement setjmp in modules that are supposed to be system neutral (i.e. must use wrappers) when one has this exception of a clib function that can't be wrapped. What ever came of that? -- John Dennis [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
On Thu, 2003-08-28 at 12:46, Marc Aurele La France wrote: Secondly, EFI is already doing the wrong thing by marking PCI ROMs as non-cacheable. This doesn't inspire confidence... I believe there is a difference between ROM's being logically cacheable and the way the ZX1 actually wires that memory into the memory system. The ZX1 connection to PCI devices are always non-cached. It's a simplified assumption correct in most all cases with little penalty for the rare case of cacheable memory sitting out in MMIO space. Therefore EFI is not doing the wrong thing by marking ROM as non-cacheable, the ZX1 is going to treat any PCI address as non-cached by design. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
On Thu, 2003-08-28 at 16:40, Marc Aurele La France wrote: ... which basically means that framebuffers cannot benifit from CPU caching. I don't beleive this to be the case. Further to this, it appears you don't realise that the frambuffers we're talking about here, _are_ in PCI space. Yes, I realize framebuffers are in PCI space. All I can do is make the following observations: 1) I was told by HP: The ZX1 chipset doesn't support cacheable access to any MMIO space, regardless of whether that space happens to contain RAM, ROM, device CSRs, etc. This statement seems clear to me, do you have a different interpretation? 2) Write combining is a typical memory attribute to apply to a framebuffer, on the IA64 the write combining memory attribute is also non-cacheable. 3) Would you really want caching on framebuffer memory in the presence of a graphics co-processor that can alter the memory independently of the cache? 4) It does not seem outlandish when considering the universe of PCI devices to believe the memory regions on these devices either have side-effects or can be modified by the device, either case would demand non-caching. It would be very hard, as it has been pointed out, for the firmware to know what memory regions on a device could be cached safely. Thus a decision to treat any PCI memory region as non-cached sounds like a plausible design decision. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
On Wed, 2003-08-27 at 06:15, Egbert Eich wrote: Appearantly there are still issues with VGA framebuffer and emulated PIO register writes when saving and restoring fonts. These problems only affect certain cards (so far I've only heared of Nvidia cards). Mark Vojkovich is sure that these are related to caching problems, too. Have you made any progress investigating this issue? I have looked at this, here is what I know (or think I know :-) * The vga font save/restore seems unrelated to caching. - The vga framebuffer (where the fonts live) has always been mapped non-cached. The EFI on HP ZX1 would also have set this region up as non-cached. We have verified by inspecting the TLB it is non-cached. The kernel patch for non-caching (should not have mattered given the above) does not affect the font/save restore, nor did I expect it to. Everything seems right. * The vga font save/restore seems related to timing, specifically too many back to back bus transactions to the VGA framebuffer. - Adding more delays into SlowBCopy makes the problem go away. - The symptom of the problem is the bridge appears to be in a master abort error state. This would occur if the vga did not respond fast enough. * So far we've only seen this problem with nvidia (but see next item). - This suggests the problem is specific to the nvidia vga implementation and the speed at which it responds. * SlowBCopy seems only to be used for VGA font/save restore. - The whole idea of SlowBCopy bothers me from a technical perspective. - SlowBCopy has been around a while, thus this is not the first time folks have run into this problem. - No one seem to know anymore when or why its needed, but it seems to have first appeared on DEC ALPHA systems and seem unnecessary on standard PC class machines. It is an interesting correlation that both ALPHA and IA64 had fast bus transaction design goals. Mark, is there a hardware engineer at nvidia that would be familar with the VGA timing? Is it possible your VGA is running near or beyond the limits of the PCI timing requirements? My understanding is the ZX1 is a very aggressive chipset tuned for high performance, so its possible on a standard PC you may not have seen the timing problems, even if you were close to the limits. John ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
I just wanted to follow up with this for those who are maintaining the memory mapping code in the CVS tree, this is linux ia64 specific and possibly HP ZX1 specific. As of today this is best information I have and wanted to share it. Originally the MAP_NONCACHED passed to mmap caused non-cached access. That was deprecated in favor of the O_SYNC flag passed to the open of /dev/mem. As of linux kernels 2.5.xx or those which have been patched, these flags are both deprecated and ignored. At some point os-support/linux/lnx_video.c should clean up the use of these flags. There are a few other places in the tree these flags are used as well. However, for the time being the use of these flags should remain as people may be running on kernels without the automatic detection of the caching attribute. The critical issue is that caching attribute the kernel sets in the TLB must match the EFI (firmware) setup. It has been a fortunate consequence that when XFree86 passed the non-caching flags it was for memory regions that EFI had configured to be non-caching and no problem was observed, the non-caching flag caused the kernel to set the TLB correctly. For kernels that ignore the flag it will still set the TLB correctly via an automatic mechanism. EFI will have created non-cached mappings with the HP ZX1 chipset for ALL PCI memory regions since the ZX1 only supports non-cached on IO. Anytime in the XServer when MMIO was specified as a mapping flag the ia64 code would have requested non-cached, this is done for all register mappings and the VGA framebuffer (because write combining was avoided on banked memory). If the FAMEBUFFER flag is passed then write combining is selected instead of non-cached, but the framebuffer should have also been set up by the firmware as non-cached. I would expect this to have caused an inconsistency between the TLB entry and the ZX1 chipset possibly leading to MCA's but this has not been observed, so I can't explain that one. The only other example I have heard of where XFree86 was requesting a cached or non-cached mapping which was not consistent with EFI is the mapping of ROM BIOS when using the ROM base address register in the PCI config. EFI treats that memory as non-cached because its PCI and the non-cached flag was not passed in xf86ReadBIOS. ROM BIOS cached reads to the standard video rom address 0xC were fine because its a shadow image in RAM which is cached. So far I can only find source code that passes 0xC to xf86ReadBIOS, but that does not mean there isn't code lurking somewhere that uses the PCI ROM BAR. The MAP_WRITECOMBINED flag passed to mmap is now also deprecated in Linux as of 2.4.19 for two reasons, its lack of support on most ia64 platforms and because of memory attribute aliasing problems that originally caused the MAP_NONCACHED and O_SYNC flags to be removed. The flag can still be specified, but will be ignorned. Note that all ia64 GARTs are now run in choerent mode, so there is no need for write combining. John ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
On Tue, 2003-08-26 at 10:22, Marc Aurele La France wrote: Frankly, I don't see how this EFI MDT can be accurate given that, in general, whether or not a particular PCI memory assignment will tolerate caching and/or write-combining is highly device-specific. That would be a horrific PCI device database for EFI to maintain. My understanding (albeit limited) from correspondence with HP is that it is the chipset that determines this. On current HP ia64 they use the ZX1 chipset which only does non-cached access on PCI. Thus if firmware knows there is a ZX1 chipset it knows how the memory region will be handled. Apparently EFI also seems to know about GARTs. Intel boxes used a different chipset but share EFI and the kernel code so it should be behave the same. I'm leery of misinterpreting some of the correspondence so is the actual text from some of it, if you draw different conclusions let me know. John What had been confusing at this end is the notion that ROM by John definition can never be incoherent, therefore cached John vs. non-cached should be irrelevant. HP Ah, I see that point. The problem in this case is that the HP chipset may support different types of access to different HP regions. (That's part of what the EFI MDT tells you.) The ZX1 HP chipset doesn't support cacheable access to any MMIO space, HP regardless of whether that space happens to contain RAM, ROM, HP device CSRs, etc. John The problem if I understand correctly is that the access was not John consistent with the EFI table defining what the memory attribute John needed to be. Bottom line, its EFI that determines cachability, John not a prori knowledge of the memory characteristics being John mapped. HP Right. And the underlying chipset determines what goes in the EFI HP table. - John This made me think about the MAP_WRITECOMBINED flag passed to John mmap. The current scheme has EFI responsible for determining the John cached vs. non-cached memory attribute, the user should not be John specifying such a memory attribute. Write combining or write John coalescing is one variant of a non-cached memory attribute on John ia64 that is used for frame buffers. My understanding is that John EFI will be ignorant of this memory attribute and the John MAP_WRITECOMBINED remains a valid flag to pass. I also assume John that passing this flag replaces an ma value of 4 (uncached) with John 6 (uncached write coalescing) and that such a replacement, John outside the scope of the EFI MDT is valid because both share the John uncached attribute. Correct? HP The EFI MDT does have a bit for WC, but I don't know of any ia64 HP platform that sets it. I removed support for MAP_WRITECOMBINED in HP the 2.4.19 patch because we don't have a good way of using it HP safely. (Even if there were an ia64 platform that claimed to HP support it, we'd have to be very careful to avoid the attribute HP aliasing problem. The fact that kernel identity mappings don't HP have page tables and are inserted in 64Mb (or maybe 16Mb) chunks HP means that we'd have to somehow ensure that a 64Mb chunk that HP contained a WC mapping could never also be mapped WB.) HP From the user side, MAP_WRITECOMBINED can still be specified; we HP just ignore it in the kernel. This used to be used for AGP, but HP all ia64 GARTs are now run in coherent mode, so there's no need HP for WC. HP It is possible for multiple attributes to be supported, so it's HP conceivable that we could look at user requests for special HP mappings. For example, the i2000 supports both UC and WB mappings HP of main memory. But at the moment, I don't think there's an HP actual need for such a feature, and the fact that we don't have HP kernel page tables would complicate adding it. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
On Tue, 2003-08-26 at 13:40, Egbert Eich wrote: Marc Aurele La France writes: On Tue, 26 Aug 2003, Egbert Eich wrote: Frankly, I don't see how this EFI MDT can be accurate given that, in general, whether or not a particular PCI memory assignment will tolerate caching and/or write-combining is highly device-specific. That would be a horrific PCI device database for EFI to maintain. How that is done is in fact an interesting question. Maybe someone with good contacts to HP could inquire on this. I will confess my understanding is weak when it comes to low level bus interactions, but I'm learning more eveytime I have to tackle these issues ;-) Correct me if I'm wrong, but I thought things like caching and write-combining are not properties of the PCI device, rather they are properties of the memory system upstream of the PCI device, e.g. bridges, memory controllers, and the MMU in the CPU. The PCI configuration does provide various pieces of information which help determine how the device can be accessed, e.g. pre-fetch, latency, cache line size etc. All of this is available to firmware. Wouldn't all this be sufficient for firmware to make the right decisions? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
I have spent quite a bit of time investigating this issue and I think we now understand the underlying issue. The various places in XFree86 that mmap memory seem to very careful to specify the proper mapping attributes, e.g. when mapping registers with ordering requirements and side-effects (e.g. MMIO) the mapping is forced to be non-cached and ordered. But ROM (e.g. device bios) can be read cached, it has no side-effects. Thus when xf86ReadBIOS maps the ROM BIOS it does not force a non-cached mapping. In theory this is correct. However on IA64 the concept of caching is overloaded, not only does it refer to memory coherence but more importantly selects between two vastly different memory spaces, RAM and IO. A cached access is directed to RAM and a non-cached access is directed to IO (e.g. a pci device). It was observed that ROM reads using the standard VGA ROM base of 0xC were successful, but ROM reads using a base address computed from the PCI TAG (e.g. using the ROM BAR) failed unless the caching attribute was asserted. Note that at boot time the VGA bios is copied from the card to RAM at 0xC (e.g. the shadow copy) as is required by the PCI spec. In XFree86 it uses the symbol V_BIOS for this address. This implies the following: 1) Reading the bios at 0xC must be cached so that it is directed to RAM. 2) Reading a bios on the card must be non-cached so that it becomes an IO access. This means if there is a common routine (e.g. xf86ReadBIOS) it must distinguish between whether the base address is a shadow copy or not. This also explains why cached reads of 0xC were successful and why cached reads off the card failed (and in most cases should have machine checked). If our analysis is correct it means we can't just force a non-cached mapping unless we know if we are pointing to a shadow or the physical IO address of the bios. This problem only seems to show up when there is a second graphics card in the system. This also makes sense to me. The primary card has its VGA shadowed at 0xC in RAM. But if a driver or int10 code want to read the bios on the non-primary card it can't use the VGA ROM base because that belongs to the primary, it must get it from the PCI config and read it from the card. I went looking for the place in the XFree86 code that reads rom bios using the tag, as this seems to be a key element, but I didn't find it yet. Can someone point me at it? On the assumption this analysis is correct should we ifdef xf86ReadBIOS for __ia64__ and test for anything in the range of 0xC to 0xC+size and modify the mapping based on that test? Are there any places in the server which read BIOS that is not done via the utility xf86ReadBIOS? John ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
On Mon, 2003-08-25 at 14:51, David Dawes wrote: However on IA64 the concept of caching is overloaded, not only does it refer to memory coherence but more importantly selects between two vastly different memory spaces, RAM and IO. A cached access is directed to RAM and a non-cached access is directed to IO (e.g. a pci device). Does this mean that the video memory aperture on a PCI device is classified as RAM, or is there something else that ensures that cached accesses get directed to the PCI device in this case? Is the difference that this is a writeable region while the ROM is read-only? I just received information from HP (thank you Bjorn Helgaas) that the memory attribute does not direct access between RAM and IO, I was in error. But what is critical is that the EFI MDT (Memory Descriptor Table?) which is set up at boot time is the arbiter of which memory attributes are used for various memory regions. User space mappings that try to force cached vs. non-cached accesses are inappropriate, its not their decision, rather it must be consistent with the EFI table which is set up at boot time. There is a kernel patch that ignores the user request for cached vs. uncached mappings and instead (indirectly) consults the EFI MDT such that the memory attribute field in the TLB is consistent with how that memory is referenced in the system, as determined by the firmware (EFI). Beta RH kernel's were missing this patch that had been present in earlier kernels. Bjorn tells me that with the patch applied no changes need to be made to X for proper operation and that the patch is in the upstream kernel sources. FYI, the patch follows for those interested, note that O_SYNC is no longer used as a trigger for non-cached access. --- drivers/char/mem.c 2003-08-21 15:55:17.0 -0600 +++ /home/helgaas/linux/testing/drivers/char/mem.c 2003-08-13 10:54:25.0 -0600 @@ -180,6 +177,11 @@ test_bit(X86_FEATURE_CYRIX_ARR, boot_cpu_data.x86_capability) || test_bit(X86_FEATURE_CENTAUR_MCR, boot_cpu_data.x86_capability) ) addr = __pa(high_memory); +#elif defined(__ia64__) + struct page *page; + + page = virt_to_page(__va(addr)); + return !VALID_PAGE(page) || PageReserved(page); #else return addr = __pa(high_memory); #endif @@ -194,7 +196,11 @@ * through a file pointer that was marked O_SYNC will be * done non-cached. */ +#ifdef __ia64__ + if (noncached_address(offset)) +#else if (noncached_address(offset) || (file-f_flags O_SYNC)) +#endif vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot); /* Don't try to swap out physical pages.. */ -- John Dennis [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
*** xf86BiosREAD, IA64, Multi-card Init ***
We are working through an issue on IA64 (Itanium2) and would
like to consult the developer community on our approach.
On a 4.3.0-based XFree86, we are having difficulties properly
initializing multiple graphics cards with Int10. Most
specifically, mapping and reading the video BIOS through this
mechanism returns incorrect results for any additional cards
beyond the primary device.
The IA64 kernel we are running is 2.4.21-based. In the file:
xc/programs/Xserver/hw/xfree86/os-support/shared/bios_mmap.c
the function below opens /dev/mem and memory maps the BIOS:
int
xf86ReadBIOS(unsigned long Base, unsigned long Offset,
unsigned char *Buf, int Len)
{
if ((fd = open(DEV_MEM, O_RDONLY)) 0)
ptr = (unsigned char *)mmap((caddr_t)0, mlen, PROT_READ,
MAP_SHARED, fd, (off_t)Base);
}
___
Problem
The behavior in our case is that the BIOS memory on the
non-primary devices (secondary cards) is returned cacheable,
resulting in unusable results to proceed with the initialization
from BIOS.
_
Solution Proposal
The current solution proposal is to, on IA64 architectures only,
explicitly trigger a non-cacheable request of kernel memory
through the additional flag to open(..., O_RDONLY | O_SYNC).
In the 2.4 kernel module (drivers/char/mem.c), this flag will
explicitly mark the memory as non-cacheable when the mmap()
call is later made. (We have investigated the MAP_NONCACHED
flag to mmap(), but this is not supported under all kernels,
architectures, and distributions.)
When this request is implemented on a 2.4 kernel, the memory
map returned is uncacheable and suitable for direct BIOS reads
with the expected results. This should also be benign for
requests where the memory is already marked uncacheable.
Cacheable BIOS reads under IA64 can lead to memory attribute
aliasing which can trigger machine-checks on some of our current
hardware. This is also why this issue is of interest.
Future kernels will be more robust in enforcing cacheability
maps, but this is not always guaranteed on all current
production kernels that are shipping now for IA64. By
making this change now, we believe there will be broader
supportability of multi-card solutions for Itanium-based
systems using XFree86.
(If other architectures also require this support consideration,
the proposed fix could be broadened, too. Insights welcome.)
Comments and questions are welcome. The proposed patch in
its entirety is attached below.
Thank you and best regards,
John Fujii
HP WGBU Linux Graphics
--- xc/programs/Xserver/hw/xfree86/os-support/shared/bios_mmap.c.orig 2001-05-23
08:46:05.0 -0600
+++ xc/programs/Xserver/hw/xfree86/os-support/shared/bios_mmap.c2003-08-18
16:29:09.0 -0600
@@ -47,7 +47,12 @@
int psize;
int mlen;
+#ifdef __ia64__
+ /* force noncacheable; see drivers/char/mem.c */
+ if ((fd = open(DEV_MEM, O_RDONLY | O_SYNC)) 0)
+#else /* !__ia64__ */
if ((fd = open(DEV_MEM, O_RDONLY)) 0)
+#endif /* __ia64__ */
{
xf86Msg(X_WARNING, xf86ReadBIOS: Failed to open %s (%s)\n,
DEV_MEM, strerror(errno));
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
cvsup problems
I had been using cvsup successfully to sync with the XFree86 CVS tree,
but after returning from vacation it has started to fail with what
appears to be an internal error in the client.
***
*** runtime error:
***Segmentation violation - possible attempt to dereference NIL0
***
use option @M3stackdump to get a stack trace
Aborted
I will include the stackdump below and my config file, I didn't see
anything in the stackdump that meant anything to me. I did update my
cvsup client to the latest and I checked the cvsup web site looking for
possible causes/solutions. The only thing I found was if you DNS could
not reverse map your ip address you could get a similar failure, but my
DNS server can do the reverse mapping fine. So I'm a bit perplexed,
anybody have a suggestion as to what may be the problem. Like I said,
this has all been working fine previously. The only thing I can think of
is that my host machine did have some libraries updated but cvsup is
statically linked so I don't think that could explain the sudden
failure.
$ cvsup @M3stackdump cvsup.xfree86
***
*** runtime error:
***Segmentation violation - possible attempt to dereference NIL0
***
- STACK DUMP ---
PC SP
0x80c9c18 0xbfffe130 Crash + 0x58 in
/usr/local/src/m3/pm3-1.1.15/libs/m3core/src/runtime/common/RTProcess.m3
0x80c8d6f 0xbfffe144 EndError + 0x3f in
/usr/local/src/m3/pm3-1.1.15/libs/m3core/src/runtime/common/RTMisc.m3
0x80c8b74 0xbfffe168 FatalErrorI + 0x34 in
/usr/local/src/m3/pm3-1.1.15/libs/m3core/src/runtime/common/RTMisc.m3
0x80cd46a 0xbfffe17c SegV + 0x2a in
/usr/local/src/m3/pm3-1.1.15/libs/m3core/src/runtime/LINUXLIBC6/RTSignal.m3
0x80eafb8 0xbfffe4f0
0x8106e0c 0xbfffe538
0x810694b 0xbfffe5fc
0x8106f36 0xbfffe628
0x8101ef9 0xbfffe634
0x810694b 0xbfffe6f8
0x8101772 0xbfffe758
0x8101dff 0xbfffe774
0x811b2d7 0xbfffe78c
0x8102c9d 0xbfffe7e4
0x810285c 0xbfffe83c
0x80a7e8e 0xbfffea0c CanGet + 0x16e in
/usr/local/src/m3/pm3-1.1.15/libs/libm3/src/uid/POSIX/MachineIDPosix.m3
0x80a7238 0xbfffea28 Init + 0x58 in
/usr/local/src/m3/pm3-1.1.15/libs/libm3/src/uid/Common/TimeStamp.m3
0x80a73b1 0xbfffea94 New + 0x81 in
/usr/local/src/m3/pm3-1.1.15/libs/libm3/src/uid/Common/TimeStamp.m3
0x80a69a1 0xbfffead0 RandomSeed + 0x41 in
/usr/local/src/m3/pm3-1.1.15/libs/libm3/src/random/Common/Random.m3
0x80a6876 0xbfffeae4 Init + 0x46 in
/usr/local/src/m3/pm3-1.1.15/libs/libm3/src/random/Common/Random.m3
0x8066467 0xbfffeb1c New + 0x87 in
/usr/local/src/cvsup/cvsup-snap-16.1d/client/src/BackoffTimer.m3
0x806895b 0xb0bc
0x80c869f 0xb0d4 RunMainBodies + 0x6f in
/usr/local/src/m3/pm3-1.1.15/libs/m3core/src/runtime/common/RTLinker.m3
-- EXCEPTION HANDLER STACK -
0xbfffe85c RAISES {}
0xbfffea20 RAISES {}
0xbfffea60 LOCK mutex = 0x81842ec
0xbfffea6c RAISES {}
0xbfffeac8 RAISES {}
0xbfffec34 TRY-FINALLY proc = 0x8068d73 frame = 0xb0bc
0xbfffecfc TRY-EXCEPT {Main.Error}
0xbfffee68 TRY-EXCEPT {Thread.Alerted}
Aborted
Here is my cvsup config file:
*default release=cvs host=anoncvs.xfree86.org
base=/home/boston/jdennis/.cvsup
*default prefix=/home/boston/jdennis/src/xfree86 delete use-rel-suffix
*default compress
*default tag=.
xc-all
doctools-all
contrib-all
xtest-all
utils-all
--
John Dennis [EMAIL PROTECTED]
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
SlowBCopy, IA64, PCI bus corruption
as to how much no-op is needed in the loop on a given system? 4) Is my general analysis correct? If not can you help explain where I'm missing the mark and what the actual issues are? John -- John Dennis [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
fspanel || learning XLib and Xinerama
I've just discovered fspanel. I love it because it it so so simple. I use XFree86 on MacOSX so my OS is already provided for me and I don't need all the extra features of gnome or kde just to get their panel. Here's my issue: fspanel doesn't have the vaguest idea about Xinerama, and I have multiple displays. This makes it impossible to make it show up on the correct one correctly. ;-) First, if anyone has a patch/hack/whatever that will make it work, pls tell me!? or even a similarly lightweight panel. I've looked at fbpanel and hpanel, they aren't what I'm looking for, and I'm not entirely sure they support Xinerama either. Second, failing my first request: Could someone point me in the right direction to learn Xlib and Xinerama myself? I know some C (I understand the language, but have very little experience) and I'd like to be able to fix this myself. :-) Help is appreciated, JP It's all fun and games 'til someone writes to a NULL pointer! ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
You will love it
Title: ad As Seen On TV: CNN, ABC News And More ... Doctors Create VPRX Penis Enlargement Pills Gain Up To 3+ Full Inches In Length Increase Your Penis Width (Girth) By 20% Stop Premature Ejaculation! Produce Larger, Rock Hard Erections 100% Safe To Take, With No Side Effects Fast Priority Fed-Ex Shipping WorldWide Doctor Approved And Recommended No Exercises! No Pumps! No Surgery! 100% Money Back Guarantee FREE Bottle Of VP-RX Worth Over $50 FREE "Male Help E-Book" Worth Over $50 >CLICK HERE TO READ MORE No Thank you, I want Out
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
Hi Michel (and the rest of the cc club), I upgraded my dri-trunk packages today (xlibmesga-gl1 and xserver-xfree86) from your repository and my dual head config now works! I am an extremely happy bunny. Have you an unfullfilled Amazon wishlist item or something I can bless you with? I have version 2003.07.25-2 of the two packages I mentioned. I also have the drm-trunk-module-src module but have not compiled or inserted the module, so just the xserver stuff fixed this. My current config (Radeon M9 with LCD+Iiyama Vision Master Pro 451) can be found at: http://www.johnleach.co.uk/documents/powerpc/XF86Config-4.dualhead John. On Sat, 2003-07-26 at 12:08, Michel Dänzer wrote: On Tue, 2003-07-15 at 16:29, Benjamin Herrenschmidt wrote: latest CVS build (by myself) as of yesterday (4.3.99...) When did you try exactly ? I've seen more fixes for TMDS getting in the CVS recently. I'm not sure what's up here, definitely not something the doc explains. I suspect it's the path of pixel data from the framebuffer to the TMDS transmitter that has an endian problem, I fail to see why SURFACE_CNTL thing would fail, or maybe it's a problem related to surface translation getting in our way ? I suspected that as well. If current CVS still doesn't work (works perfectly here with an external CRT on an M9 in a TiBook IV), please try this patch and post the RADEONInitCommonRegisters output. Or maybe it's something like http://bugs.xfree86.org/show_bug.cgi?id=521 ? -- GPG KEY: B89C D450 5B2C 74D8 58FB A360 9B06 B5C2 26F0 3047 HTTP: http://www.johnleach.co.uk signature.asc Description: This is a digitally signed message part
Re: spoofing X-events input?
you can do this via several methods. XSendEvent is the simplest, but is problematic since you would have to choose the window to send the events to and clients can ignore the events. the proper way to do this is with the XTEST extension which was introduced just for this purpose. 'xautomation' is a tool which gives you a command line interface to this extension and is very handy and can be used to do things like simulate paste for apps which don't support pasting nativly. John On Tue, Jul 22, 2003 at 11:34:50PM +0200, Roland Pabel wrote: Hi, I'd like to know if anyone ever thought of a way to spoof mouse/keyboards events, so you could send special events like clicked() to any application running... My idea is to have something like this: A pipe ~/.X_fifo is created on X startup and you can paste strings like mouse move 100,100, mouse pressed left or keyboard pressed 'P' and these actions would then be carried out as if someone moved/pressed the mouse or keyboard accordingly...(the applications shouldn't notice a difference) If no one knows of an implementation, could you tell me with which of the X11/extensions/ header files to start with? thanks Roland Pabel -- ICQ UIN 49339118 Linux Counter #88774 GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel -- --- John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED] --- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
Hi Michel, My attempts at using the binary have failed. X reports: (II) LoadModule: radeon (II) Loading /usr/X11R6/lib/modules-dri-trunk/drivers/radeon_drv.o (II) Module radeon: vendor=The XFree86 Project compiled for 4.3.99.5, module version = 4.0.1 Module class: XFree86 Video Driver ABI class: XFree86 Video Driver, version 0.7 (EE) module ABI minor version (7) is newer than the server's version (6) (II) UnloadModule: radeon (II) Unloading /usr/X11R6/lib/modules-dri-trunk/drivers/radeon_drv.o (EE) Failed to load module radeon (module requirement mismatch, 0) I've tried and failed to build a new dri-trunk package incorporating the patch (most likely a newbie deb package building/xfree86 compiling problem). My package versions are: xserver-xfree86 4.2.1-6 the XFree86 X server xserver-xfree86-dri-trunk 2003.05.04-1 The XFree86 X server [DRI trunk] If this is due to your binary being compiled against a different version of X than my own, what can I do? Should I try it with a 4.3 server? (and if so, are some official debs available?) Could you compile it against a lower version for me? Or shall I just give up on this whilst somebody else with more xfree86 smarts tests it? :( Thanks, John. On Wed, 2003-06-04 at 00:19, Michel Dänzer wrote: On Tue, 2003-06-03 at 15:22, Benjamin Herrenschmidt wrote: On Fri, 2003-05-30 at 11:52, Simon Urbanek wrote: Hi all, I have several problems with the ATI Radeon drivers in XFree on my Mac G4 Windtunnel (dual 1.4GHz). Summary: 1) CRT + TMDS dual head configuration doesn't work 2) In all configurations colors are completely wrong 3) closing X blanks all monitors I have tested following versions of XFree86: Debian sid officail 4.2.1 Michel Daenzer's 4.2.1 DRI build Debian inoffical 4.3.0 latest CVS build (by myself) as of yesterday (4.3.99...) Ok, CVS is the really interesting one. Michel, did you ever commit the fix of SURFACE_CNTL ? That should fix the colors at least on the main aperture It's in, but only handles aperture 0. Can someone try http://penguinppc.org/~daenzer/XFree86/radeon-ap1.diff or http://penguinppc.org/~daenzer/XFree86/radeon_drv.o ? -- GPG KEY: B89C D450 5B2C 74D8 58FB A360 9B06 B5C2 26F0 3047 HTTP: http://www.johnleach.co.uk signature.asc Description: This is a digitally signed message part
Re: Cyberpro 20x0 driver?
At at previous job I was responsible for XFree86 Cyberpro drivers. Tvia (www.tvia.com) had supplied us with source code for their XFree86 4.x Cyberpro driver that worked reasonably well. I did have to make a few fixes and we did add some enhancements. The point of this is that Tvia does develop and maintain XFree86 drivers for their Cyberpro series. Why these are not available at least as binary downloads from their web site eludes me. Tvia does try to earn extra income from selling their SDK's. As of a year ago when I working on this the SDK's did not include the XFree86 driver sources, we had to obtain that separately. I suspect the reason Tvia has not open sourced their driver is a function of their wanting to derive income from the sale of their SDK's. My personal opion of their SDK's and their doc was it was not worth the price they were asking. However, having said that, I did find it essential to have the SDK's in order to work on the driver because the SDK's provided example code to perform certain functions which at the time were not part of the driver. I think Tvia suffers the same type of myopia that many small vendors suffer from. They would generate more income via increased hardware sales by opening up their source pool then the amount of income they generate by selling their marginal SDK's to a handful of partners. Maybe it would be worthwhile for someone to press them on this issue. John ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
