Re: Problems with mach64 on NetBSD/sparc64
On Thu, 6 Oct 2005, Martin Husemann wrote: On Thu, Oct 06, 2005 at 01:39:10PM -0600, Marc Aurele La France wrote: No. My preference is definitely to keep the OS out of the way, as much as possible Ok, but in this case that is not realy possible. You need a OS driver that understands your mmap() call anyway to get the IOMMU mappings correct consistent. We do not allow generic mmap'ing of PCI memory ranges, because that would mean we had to try very hard to keep all OS drivers out of the way or somehow synchronize the userland mapping with them. On i386 with plain pass-through PCI access thinks are certainly different. You're assuming the X server would indiscriminately trample all over such mappings. That's not the case on SPARC any more than it is on x86. I also don't see why this is not really possible with NetBSD, when it works very well through Linux and SunOS (... and I _do_ mean through). The idea here is to support PCI, not PCI/x86, PCI/SPARC, ad nauseam. This means creating a generic model of PCI and filtering out host differences before presenting that model to our video drivers. The less lobotomies of PCI the underlying OS implements, the better. The only restriction on PCI this architecture actually implements is its default handling of master aborts. And even that assertion is debatable. _All_ other restrictions are necessarily OS inventions. No matter how you look at it, some NetBSD kernel work will be required for multihead to work on both uni-domain (Sabre Hummingbird) and multi-domain (Psycho, Schizo Tomatillo) systems. The first thing to look at is PCI I/O. I see from the logs posted on this thread that the kernel clobbers OBP's assignment of PCI I/O BARs. This clobbering needs to be removed. There also needs to be an ability to map in one chunk the entirety of a host bridge's PCI I/O range. Doing this mapping per device isn't practical because PCI limits assignments to 256 bytes (which is less than the host page size) and per-device mappings don't allow for unregistered assignments such as those for VGA, 8514/A, etc. It doesn't really matter whether PCI memory mappings are done per-device, per-domain, or through some more liberal /dev/mem clone. The caveat here is that should you require that such mappings be done per-device, you had better ensure even PCI ROM pointers are assigned, valid and mappable. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problems with mach64 on NetBSD/sparc64
On Thu, 6 Oct 2005, Michael wrote: The only work-around is to remove the XL. It won't work anyway, at least not under NetBSD/sparc64 as things currently stand. There's no way for the ati driver to simply ignore adaptors it cannot mmap? How can it, when the port FatalError's mmap() failures? Ouch. Hmm, many ports seem to do that. On the other hand drivers seem to check wether xf86MapVidMem() returns NULL ( well, the ati driver does ) so - is there a good reason to FatalError() in whatever_MapVidMem() ? If not I'd just let it return NULL on sparc64 and see what happens. FatalError'ing mmap() failures here normally indicate a problem with the server's OS interface, rather than one with the server itself. Think of these as reminders to developers that more work needs to be done. So, yes, you should see what happens when mmap() failures return NULL. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problems with mach64 on NetBSD/sparc64
On Tue, 4 Oct 2005, Michael wrote: Second - the driver seems to either ignore the BusID parameter. Log excerpt: (--) PCI: (1:2:0) ATI Technologies Inc 3D Rage Pro 215GP rev 92, Mem @ 0xe10 0/24, 0xe200/12, I/O @ 0xff00/8, BIOS @ 0xe102/17 (--) PCI: (2:1:0) ATI Technologies Inc Rage XL rev 39, Mem @0x1100/24, 0x12 00/12, I/O @ 0xff00/8, BIOS @ 0x1202/17 That's the onboard Rage Pro and a Sun PGX64 in a Sun Ultra 5 The Device section in XF86Config: Section Device ### Available Driver options are:- ### Values: i: integer, f: float, bool: True/False, ### string: String, freq: f Hz/kHz/MHz ### [arg]: arg optional #Option accel # [bool] #Option crt_display # [bool] #Option composite_sync# [bool] #Option hw_cursor # [bool] #Option mmio_cache# [bool] #Option test_mmio_cache # [bool] #Option panel_display # [bool] #Option probe_clocks # [bool] #Option reference_clock # freq #Option shadow_fb # [bool] #Option sw_cursor # [bool] Identifier Card0 Driver ati VendorName ATI BoardName 3D Rage Pro 215GP ChipSet ati ChipId 0x4750 ChipRev 0x5c BusID PCI:1:2:0 EndSection but XFree fails with this: (II) ATI: Candidate Device section Card0. (II) ATI: Unshared PCI/AGP Mach64 in slot 1:2:0 detected. Fatal server error: xf86MapVidMem: could not mmap screen [s=2000,a=1200] (Invalid argument) So it tries to map PCI resources belonging to the Rage XL while the Device section clearly says it should use the onboard Rage Pro. Even if it's only probing it shouldn't fail here since the device it's supposed to use is definitely usable - with the Rage XL removed it works as expected. I'd need to see a log of this. The log and config are attached. ATIProbe() tries to mmap() every adapter of interest in the system so that it can probe them. This happens before the driver even looks at XF86Config information (which might not exist). But that's not the real issue here. The problem is that wscons on NetBSD/sparc64 does not consider secondary adapters as part of the console. This means that multi-head cannot work as this port is currently coded. I would venture to guess that a different file descriptor is needed for every adapter in the system. Another possibility is to convert the NetBSD/sparc64 to use the common layer's domain scheme, essentially translating every mmap() request into one of /dev/mem. Either way, there's work to be done in this port's os-support layer. The only work-around is to remove the XL. It won't work anyway, at least not under NetBSD/sparc64 as things currently stand. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problems with mach64 on NetBSD/sparc64
Hello, ATIProbe() tries to mmap() every adapter of interest in the system so that it can probe them. This happens before the driver even looks at XF86Config information (which might not exist). But that's not the real issue here. The problem is that wscons on NetBSD/sparc64 does not consider secondary adapters as part of the console. This means that multi-head cannot work as this port is currently coded. I know. The NetBSD-specific code needs to open more than one device, right now it tries to mmap() everything through a single file descriptor which isn't going to work. There's a workaround ( /dev/xf86 ) somewhere but that's more or less i386-specific and rather ugly. Either way, there's work to be done in this port's os-support layer. Definitely. The only work-around is to remove the XL. It won't work anyway, at least not under NetBSD/sparc64 as things currently stand. There's no way for the ati driver to simply ignore adaptors it cannot mmap? have fun Michael pgpUQdkFQYojP.pgp Description: PGP signature
Re: Problems with mach64 on NetBSD/sparc64
On Thu, Oct 06, 2005 at 09:51:38AM -0600, Marc Aurele La France wrote: I would venture to guess that a different file descriptor is needed for every adapter in the system. Yeah, I would prefer to use /dev/fb* for the PCI devices too (this is what is used for SBUS and UPA devices already) - and avoid all the PCI bus scanning that way too. Martin ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problems with mach64 on NetBSD/sparc64
On Thu, 6 Oct 2005, Michael wrote: The only work-around is to remove the XL. It won't work anyway, at least not under NetBSD/sparc64 as things currently stand. There's no way for the ati driver to simply ignore adaptors it cannot mmap? How can it, when the port FatalError's mmap() failures? Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problems with mach64 on NetBSD/sparc64
On Thu, 6 Oct 2005, Martin Husemann wrote: On Thu, Oct 06, 2005 at 09:51:38AM -0600, Marc Aurele La France wrote: I would venture to guess that a different file descriptor is needed for every adapter in the system. Yeah, I would prefer to use /dev/fb* for the PCI devices too (this is what is used for SBUS and UPA devices already) - and avoid all the PCI bus scanning that way too. No. My preference is definitely to keep the OS out of the way, as much as possible, because it's more portable to do so (from our perspective). This OS-as-God idea is out-to-lunch, IMNSHO. Look at Linux as an example of why. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problems with mach64 on NetBSD/sparc64
Hello, The only work-around is to remove the XL. It won't work anyway, at least not under NetBSD/sparc64 as things currently stand. There's no way for the ati driver to simply ignore adaptors it cannot mmap? How can it, when the port FatalError's mmap() failures? Ouch. Hmm, many ports seem to do that. On the other hand drivers seem to check wether xf86MapVidMem() returns NULL ( well, the ati driver does ) so - is there a good reason to FatalError() in whatever_MapVidMem() ? If not I'd just let it return NULL on sparc64 and see what happens. have fun Michael pgpJ6qUfEpvff.pgp Description: PGP signature
Re: Problems with mach64 on NetBSD/sparc64
On Thu, Oct 06, 2005 at 01:39:10PM -0600, Marc Aurele La France wrote: No. My preference is definitely to keep the OS out of the way, as much as possible Ok, but in this case that is not realy possible. You need a OS driver that understands your mmap() call anyway to get the IOMMU mappings correct consistent. We do not allow generic mmap'ing of PCI memory ranges, because that would mean we had to try very hard to keep all OS drivers out of the way or somehow synchronize the userland mapping with them. On i386 with plain pass-through PCI access thinks are certainly different. Martin ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problems with mach64 on NetBSD/sparc64
On Wed, 28 Sep 2005, Michael wrote: we ran into two problems with the ati driver. First - it seems to screw up when switching resolution on Sun PGX64 cards ( these use a Rage XL with 8MB VRAM). The result is a monitor reporting frequencies out of range, even when forced to use something very conservative that works with the same monitor and a different graphics controller. It works just fine with a Rage Pro. If the XL has no ix86 BIOS, the ReferenceClock option (documented in README.ati) likely needs to be specified. Accurately detecting this value is not possible. Second - the driver seems to either ignore the BusID parameter. Log excerpt: (--) PCI: (1:2:0) ATI Technologies Inc 3D Rage Pro 215GP rev 92, Mem @ 0xe10 0/24, 0xe200/12, I/O @ 0xff00/8, BIOS @ 0xe102/17 (--) PCI: (2:1:0) ATI Technologies Inc Rage XL rev 39, Mem @0x1100/24, 0x12 00/12, I/O @ 0xff00/8, BIOS @ 0x1202/17 That's the onboard Rage Pro and a Sun PGX64 in a Sun Ultra 5 The Device section in XF86Config: Section Device ### Available Driver options are:- ### Values: i: integer, f: float, bool: True/False, ### string: String, freq: f Hz/kHz/MHz ### [arg]: arg optional #Option accel # [bool] #Option crt_display # [bool] #Option composite_sync# [bool] #Option hw_cursor # [bool] #Option mmio_cache# [bool] #Option test_mmio_cache # [bool] #Option panel_display # [bool] #Option probe_clocks # [bool] #Option reference_clock # freq #Option shadow_fb # [bool] #Option sw_cursor # [bool] Identifier Card0 Driver ati VendorName ATI BoardName 3D Rage Pro 215GP ChipSet ati ChipId 0x4750 ChipRev 0x5c BusID PCI:1:2:0 EndSection but XFree fails with this: (II) ATI: Candidate Device section Card0. (II) ATI: Unshared PCI/AGP Mach64 in slot 1:2:0 detected. Fatal server error: xf86MapVidMem: could not mmap screen [s=2000,a=1200] (Invalid argument) So it tries to map PCI resources belonging to the Rage XL while the Device section clearly says it should use the onboard Rage Pro. Even if it's only probing it shouldn't fail here since the device it's supposed to use is definitely usable - with the Rage XL removed it works as expected. The Xserver in question is: XFree86 Version 4.5.0 Release Date: 16 March 2005 X Protocol Version 11, Revision 0 Build Operating System:NetBSD/sparc64 3.99.8 - The NetBSD Foundation, Inc. Current Operating System: NetBSD censored 3.99.9 NetBSD 3.99.9 (INISHOWEN) #594: Fri Sep 23 06:57:25 EDT 2005 [EMAIL PROTECTED]:/data/src/sys/arch/sparc64/compile/INISHOWEN sparc64 I'd need to see a log of this. any ideas? Anything we should import from XFree -current? I think doing so for this problem is a little premature. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problems with mach64 on NetBSD/sparc64
Hello, If the XL has no ix86 BIOS, the ReferenceClock option (documented in README.ati) likely needs to be specified. Accurately detecting this value is not possible. Ok, I'll try that. Second - the driver seems to either ignore the BusID parameter. Log excerpt: (--) PCI: (1:2:0) ATI Technologies Inc 3D Rage Pro 215GP rev 92, Mem @ 0xe10 0/24, 0xe200/12, I/O @ 0xff00/8, BIOS @ 0xe102/17 (--) PCI: (2:1:0) ATI Technologies Inc Rage XL rev 39, Mem @0x1100/24, 0x12 00/12, I/O @ 0xff00/8, BIOS @ 0x1202/17 That's the onboard Rage Pro and a Sun PGX64 in a Sun Ultra 5 The Device section in XF86Config: Section Device ### Available Driver options are:- ### Values: i: integer, f: float, bool: True/False, ### string: String, freq: f Hz/kHz/MHz ### [arg]: arg optional #Option accel # [bool] #Option crt_display # [bool] #Option composite_sync# [bool] #Option hw_cursor # [bool] #Option mmio_cache# [bool] #Option test_mmio_cache # [bool] #Option panel_display # [bool] #Option probe_clocks # [bool] #Option reference_clock # freq #Option shadow_fb # [bool] #Option sw_cursor # [bool] Identifier Card0 Driver ati VendorName ATI BoardName 3D Rage Pro 215GP ChipSet ati ChipId 0x4750 ChipRev 0x5c BusID PCI:1:2:0 EndSection but XFree fails with this: (II) ATI: Candidate Device section Card0. (II) ATI: Unshared PCI/AGP Mach64 in slot 1:2:0 detected. Fatal server error: xf86MapVidMem: could not mmap screen [s=2000,a=1200] (Invalid argument) So it tries to map PCI resources belonging to the Rage XL while the Device section clearly says it should use the onboard Rage Pro. Even if it's only probing it shouldn't fail here since the device it's supposed to use is definitely usable - with the Rage XL removed it works as expected. The Xserver in question is: XFree86 Version 4.5.0 Release Date: 16 March 2005 X Protocol Version 11, Revision 0 Build Operating System:NetBSD/sparc64 3.99.8 - The NetBSD Foundation, Inc. Current Operating System: NetBSD censored 3.99.9 NetBSD 3.99.9 (INISHOWEN) #594: Fri Sep 23 06:57:25 EDT 2005 [EMAIL PROTECTED]:/data/src/sys/arch/sparc64/compile/INISHOWEN sparc64 I'd need to see a log of this. The log and config are attached. any ideas? Anything we should import from XFree -current? I think doing so for this problem is a little premature. I was just asking in case this is a known problem. have fun Michael XFree86.0.log Description: Binary data XF86Config Description: Binary data pgp1mPKo58Vyd.pgp Description: PGP signature
Problems with mach64 on NetBSD/sparc64
Hello, we ran into two problems with the ati driver. First - it seems to screw up when switching resolution on Sun PGX64 cards ( these use a Rage XL with 8MB VRAM). The result is a monitor reporting frequencies out of range, even when forced to use something very conservative that works with the same monitor and a different graphics controller. It works just fine with a Rage Pro. Second - the driver seems to either ignore the BusID parameter. Log excerpt: (--) PCI: (1:2:0) ATI Technologies Inc 3D Rage Pro 215GP rev 92, Mem @ 0xe10 0/24, 0xe200/12, I/O @ 0xff00/8, BIOS @ 0xe102/17 (--) PCI: (2:1:0) ATI Technologies Inc Rage XL rev 39, Mem @0x1100/24, 0x12 00/12, I/O @ 0xff00/8, BIOS @ 0x1202/17 That's the onboard Rage Pro and a Sun PGX64 in a Sun Ultra 5 The Device section in XF86Config: Section Device ### Available Driver options are:- ### Values: i: integer, f: float, bool: True/False, ### string: String, freq: f Hz/kHz/MHz ### [arg]: arg optional #Option accel # [bool] #Option crt_display # [bool] #Option composite_sync# [bool] #Option hw_cursor # [bool] #Option mmio_cache# [bool] #Option test_mmio_cache # [bool] #Option panel_display # [bool] #Option probe_clocks # [bool] #Option reference_clock # freq #Option shadow_fb # [bool] #Option sw_cursor # [bool] Identifier Card0 Driver ati VendorName ATI BoardName 3D Rage Pro 215GP ChipSet ati ChipId 0x4750 ChipRev 0x5c BusID PCI:1:2:0 EndSection but XFree fails with this: (II) ATI: Candidate Device section Card0. (II) ATI: Unshared PCI/AGP Mach64 in slot 1:2:0 detected. Fatal server error: xf86MapVidMem: could not mmap screen [s=2000,a=1200] (Invalid argument) So it tries to map PCI resources belonging to the Rage XL while the Device section clearly says it should use the onboard Rage Pro. Even if it's only probing it shouldn't fail here since the device it's supposed to use is definitely usable - with the Rage XL removed it works as expected. The Xserver in question is: XFree86 Version 4.5.0 Release Date: 16 March 2005 X Protocol Version 11, Revision 0 Build Operating System:NetBSD/sparc64 3.99.8 - The NetBSD Foundation, Inc. Current Operating System: NetBSD censored 3.99.9 NetBSD 3.99.9 (INISHOWEN) #594: Fri Sep 23 06:57:25 EDT 2005 [EMAIL PROTECTED]:/data/src/sys/arch/sparc64/compile/INISHOWEN sparc64 any ideas? Anything we should import from XFree -current? have fun Michael PS: the Rage XL isn't mine, I'm merely forwarding problem reports I've been unable to resolve. pgpPP9yxkONif.pgp Description: PGP signature
