Re: [Xpert]xfree86 libint10 in non-x86 environments
On Sat, 23 Nov 2002, Egbert Eich wrote: However, the ATI rage drivers do not deal well with the lack of libint10 and seems to set really bogus video timings as a result (there are other bugs I've fixed where the rage driver will crash if libint10 is not present). In fact in the rage driver only part of the code checks for the existence of libint10 and other parts of the code blithely assumes it's existence. This is a bug. Not at all. That's quite intentional. Therefore we have a situation where on two boxes that are architecturally identical (or at least really really close) and depending on the installed video card libint10 has to be present or absent or really bad things happen. The solution proposed by Marc will solve this problem. I am in contact with HP to get docs for their ZX1-based systems so that I can add support for them (as I've already done for 460GX-based Itanium1's). Until that happens (I'm hoping in time for 4.3), XFree86 won't officially support such systems. As to int10, the intention is to extend it to deal with other ROM types, such as EFI, OF, etc. That means writting an emulator for each type. That won't happen tomorrow, but... 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. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xfree86 libint10 in non-x86 environments
John I'm trying to fix some bugs with XFree86 drivers in an Itanium John (ia64) environment. ... Egbert I don't think you need to do too much for ia64. It works Egbert on all ia64 systems I have tested so far. Unfortunately I have an example where it does not, see below. Egbert However Itaniums usually do have x86 BIOS cards. Not on the 2nd generation ia64 boxes from HP. First generation supported x86 BIOS, but HP decided to eliminate x86 BIOS emulation for the 2nd generation, in part as I understand from a paper Porting Drivers to HP ZX1 by Grant Grundler of HP, to force adoption of EFI (Extensible Firmware Interface). John ... is there some alternate mechanism for configuration in John these environments that XFree86 supports or intends to John support (e.g. EFI?). Egbert Possibly. If you can give us some information on EFI. I'm probably the wrong person to fill you in on EFI, I've only been just learning about it as I try to track down this problem. FWIW, in the paper by Grundler he states all the IO card vendors that supply HP have committed to providing such a driver (EFI) and I know they are delivering or have delivered. Egbert There are very few architectures where we build a stub Egbert libint10. These are mostly architectures that have an Egbert OpenFirmware approach. We expect libint10 to work on all Egbert other architectures. see below Egbert Maybe you can give us some insight into what problems you Egbert are running into with libint10 on ia64? O.K. here is the issue. I'm trying to make XFree86 with ATI drivers run on both Intel and HP ia64 boxes with hopefully a common xfree86 binary package shared between them. The Intel boxes support x86 BIOS, the HP's do not. HP's proposed solution was to remove libint10.a from the modules directory so that the ATI driver init code would not find the library and load it, and initialize it. This is because xf86InitInt10 touches some address that is not valid and causes a machine check (or at least that is my current understanding, I'm still trying to nail down exactly where the fault is occurring). The lack of libint10 does not seem to cause problems for the ATI radeon drivers which is what HP ships. However, the ATI rage drivers do not deal well with the lack of libint10 and seems to set really bogus video timings as a result (there are other bugs I've fixed where the rage driver will crash if libint10 is not present). In fact in the rage driver only part of the code checks for the existence of libint10 and other parts of the code blithely assumes it's existence. On the Intel ia64 boxes libint10 does work and is necessary for the ATI rage driver to come up correctly. Therefore we have a situation where on two boxes that are architecturally identical (or at least really really close) and depending on the installed video card libint10 has to be present or absent or really bad things happen. I'm not a fan of the idea of not installing libint10 on ia64 to solve this problem, its a hack solution and is not general and it makes coming up with a common binary package for ia64 problematic and what happens if someone switches the video card? It seems to me that all video drivers need to be able to initialize correctly without libint10 since its an architecturally specific utility. While its true that many non-x86 vendors provide BIOS emulation support to provide a legacy friendly environment there is no requirement for them to do so and drivers should be prepared for some other configuration option, (but what would that be?) I'm still trying to tack down why the ATI radeon seems to initialize correctly without libint10 but the rage does not. I'm beginning to believe libint10 should not be installed on ia64 (unless we can come up with a way to make it work in the absence of a x86 BIOS). John ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xfree86 libint10 in non-x86 environments
John Dennis writes: John Dennis writes: John I'm trying to fix some bugs with XFree86 drivers in an Itanium John (ia64) environment. ... Egbert I don't think you need to do too much for ia64. It works Egbert on all ia64 systems I have tested so far. Unfortunately I have an example where it does not, see below. Egbert However Itaniums usually do have x86 BIOS cards. Not on the 2nd generation ia64 boxes from HP. First generation supported x86 BIOS, but HP decided to eliminate x86 BIOS emulation for the 2nd generation, in part as I understand from a paper Porting Drivers to HP ZX1 by Grant Grundler of HP, to force adoption of EFI (Extensible Firmware Interface). Interesting. Every once a while somebody comes up with something new. At least I have a HP box which has a x86 BIOS. Possibly because it is from the '1st generation' of machines. John ... is there some alternate mechanism for configuration in John these environments that XFree86 supports or intends to John support (e.g. EFI?). Egbert Possibly. If you can give us some information on EFI. I'm probably the wrong person to fill you in on EFI, I've only been just learning about it as I try to track down this problem. FWIW, in the paper by Grundler he states all the IO card vendors that supply HP have committed to providing such a driver (EFI) and I know they are delivering or have delivered. Egbert There are very few architectures where we build a stub Egbert libint10. These are mostly architectures that have an Egbert OpenFirmware approach. We expect libint10 to work on all Egbert other architectures. see below Egbert Maybe you can give us some insight into what problems you Egbert are running into with libint10 on ia64? O.K. here is the issue. I'm trying to make XFree86 with ATI drivers run on both Intel and HP ia64 boxes with hopefully a common xfree86 binary package shared between them. The Intel boxes support x86 BIOS, the HP's do not. HP's proposed solution was to remove libint10.a from the modules directory so that the ATI driver init code would not find the library and load it, and initialize it. This is because xf86InitInt10 touches some address that is not valid and causes a machine check (or at least that is my current understanding, I'm still trying to nail down exactly where the fault is occurring). I've run into exactly the same issue on my box. You don't have to eliminate the entire libint10. The problem are Lock/UnlockLegacyVGA(). I've submitted a solution for this problem to CVS. You need to put an #ifndef __ia64__ ... #endif around the line which accesses address 0x46e8 (and possibly 0x102 - I don't remember). This will not get you off the hook completely as the ATi drivers probes for some Mach variants will make the box machine check, too. I've talked to Marc Aurele about this. He proposed to add information about host bridges to the Xserver where we can keep information on which address ranges on the PCI bus can be probed savely. So far I think he is still waiting for the necessary information by HP. My quick-n-dirty work around was to '#ifdef __ia64__'-out all probing for 'legacy' HW in the ATi driver. This however will not be in the CVS. Yes, I've seen some of HP's hacks for XFree86. All I've seem was not usable for XFree86. The lack of libint10 does not seem to cause problems for the ATI radeon drivers which is what HP ships. The ATi driver reads information from the BIOS. On some versions of the linux kernel the BIOS image that was created when the system was initialized by the firmware was busted. This required some reposting to get a clean BIOS image. I believe this kernel problem has been fixed now. However, the ATI rage drivers do not deal well with the lack of libint10 and seems to set really bogus video timings as a result (there are other bugs I've fixed where the rage driver will crash if libint10 is not present). In fact in the rage driver only part of the code checks for the existence of libint10 and other parts of the code blithely assumes it's existence. This is a bug. On the Intel ia64 boxes libint10 does work and is necessary for the ATI rage driver to come up correctly. I've got it to work on my HP box, too. Therefore we have a situation where on two boxes that are architecturally identical (or at least really really close) and depending on the installed video card libint10 has to be present or absent or really bad things happen. The solution proposed by Marc will solve this problem. I'm not a fan of the idea of not installing libint10 on ia64 to solve this problem, its a hack solution and is not general and it makes coming up with a common binary package for ia64 problematic and what happens if someone switches the video card? Right. Well, libint10 should work for all
[Xpert]xfree86 libint10 in non-x86 environments
I'm trying to fix some bugs with XFree86 drivers in an Itanium (ia64) environment. Many of the drivers seem to have a strong dependency on libint10 for configuration, especially for getting monitor configuration information via DDC/VBE which depends on int10. I'll admit libint10 is one area of the XFree86 server I'm less familar with, although I have spent some time reading the source, but I've still got some questions. 1) It there an expectation that libint10 should work in a non-x86 environment? As far as I can tell at this point libint10 is completely dependent on an x86 BIOS being implemented, is that true? 2) If one removes libint10 it seems like some of the drivers are incapable of automatically configuring the monitor and getting their initial clock timings correct (yes, this can be hardcoded in the config file but thats not a very supportable solution). If libint10 is not expected to work without an x86 BIOS present then is there some alternate mechanism for configuration in these environments that XFree86 supports or intends to support (e.g. EFI?). 3) In the XFree86 source tree I see only a handful of scattered checks for int10 support. Some drivers seem to rely on the module libint10.a not being present in lib/modules. But this seems like a weak test since a working libint10 varies even within architectures. Is this just a new problem area I'm stumbling on or is there some cohesive way to deal with this I'm missing? 4) Can someone point me to documentation on video BIOS that might help me understand some of what is going on in libint10? So far all I've found is the int 10 interface for user code, but not what is going on under the covers. www.vesa.org seemed the obvious place to look but I didn't find anything in the public area. Thanks, John ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xfree86 libint10 in non-x86 environments
John Dennis writes: I'm trying to fix some bugs with XFree86 drivers in an Itanium (ia64) environment. Many of the drivers seem to have a strong dependency on libint10 for configuration, especially for getting monitor configuration information via DDC/VBE which depends on int10. I don't think you need to do too much for ia64. It works on all ia64 systems I have tested so far. I'll admit libint10 is one area of the XFree86 server I'm less familar with, although I have spent some time reading the source, but I've still got some questions. 1) It there an expectation that libint10 should work in a non-x86 environment? As far as I can tell at this point libint10 is completely dependent on an x86 BIOS being implemented, is that true? Yes, and yes. However Itaniums usually do have x86 BIOS cards. 2) If one removes libint10 it seems like some of the drivers are incapable of automatically configuring the monitor and getting their initial clock timings correct (yes, this can be hardcoded in the config file but thats not a very supportable solution). If libint10 is not expected to work without an x86 BIOS present then is there some alternate mechanism for configuration in these environments that XFree86 supports or intends to support (e.g. EFI?). Possibly. If you can give us some information on EFI. 3) In the XFree86 source tree I see only a handful of scattered checks for int10 support. Some drivers seem to rely on the module libint10.a not being present in lib/modules. But this seems like a weak test since a working libint10 varies even within architectures. Is this just a new problem area I'm stumbling on or is there some cohesive way to deal with this I'm missing? There are very few architectures where we build a stub libint10. These are mostly architectures that have an OpenFirmware approach. We expect libint10 to work on all other architectures. 4) Can someone point me to documentation on video BIOS that might help me understand some of what is going on in libint10? So far all I've found is the int 10 interface for user code, but not what is going on under the covers. www.vesa.org seemed the obvious place to look but I didn't find anything in the public area. I don't know of a single documentation. We collected our knowledge from the PCI BIOS specs, VESA BIOS specs, dosemu and experience. Maybe you can give us some insight into what problems you are running into with libint10 on ia64? Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
