On Tue, Feb 3, 2009 at 3:03 AM, Alan Coopersmith <Alan.Coopersmith at sun.com> wrote: > Alan Coopersmith wrote: >> Right now, the versions we know work and don't: >> - up through nv_105: may report too many devices >> - nv_106 - nv_107: should work on most systems, since we limit the >> bus ids scanned to bus_range, which due to bug 6782932/6798926 was >> a small range that on most machines includes the actual devices but >> not the addresses we previously hit that caused incorrect memory >> locations to be used in the probes >> - recent nightlies: the fix for 6798926 returned the bus_range size >> to the larger values, causing us to > > ...return to seeing too many devices again. >
Yes, I recall having seen loops which do not operate correctly. Another loop was disabled (don't recall the file name). The best I could get when I last tried a while ago was, that it would identify invalid devices as chosen gfx device to use, while not finding the actual gfx devices at all, or finding unsupported ones like Expert3Dlite (for which no Xorg driver will ever exist). For example it would report a NIC or some bridge as gfx device in Xorg.0.log, then it would hang or crash or simply exit. This was last fall (October or September). And in terms of the delays you are talking about: Yes, especially on Psycho (U30, U60). There it would take over a minute or two. My other question was: Is there a dumb loop implemented meanwhile, which would assign the platform-specific root-nexus to it, for the various SPARC platforms accordingly?? You only need to open /devices ro and look for a string which ends in :0 (or the like, I do not recall). Then you could be quite sure this is the pci nexus you want. Some SPARC boxes have 2 or more of them, though, depending on the number of PCI buses inside. Okay, as I understand it all this does not matter anymore, because it will be enough to have a /dev/fb driver. This relieves me. I am curious about how it works. I check asap. Then we can really get the legacy ddx modules going!!! Hopefully we will also find a way to get UPA working again. Which should still be working like it previously did, when I recall the bus scanning code inside the server itself: It has only been removed for PCI. For UPA it had still been inside (server 1.5). I hope this is still valid for 1.5.3 and 1.6.x . Then not much should prevent the new servers to drive Elite and Creator cards as well, as previously in server 1.3. And in this case the SPARC-Indiana folks can hardly really afford to leave it out. They will see: They user base will demand legacy gfx support, as soon as SPARC-Indiana will be out. And as soon as end-users learn about it, through marketing. But my experiments back then had been with an older version of libpciaccess. Long before you added the 1.5 branch or any custom patches for libpciaccess. I must try two things: The newer release of libpciaccess. Your patches against it. But right now I am busy enough on x86 with DRM/DRI. My SPARC boxes are not really in a usable state right now. But as I am curious about it, this will be undone asap. Thank you for the update. p.s. Did you notice that your current fox-gate (1.5.3) generated amd64 server doesn't find its own core modules, even though they do exist and not even when you instruct Xorg to report the module path (Xorg reports it correctly) and also not even if you redundantly specify the same path as Xorg option on the cmd line or in X11/bin/Xserver? My current "workaround" was, that I use the 32bit server, by having lofs mounted /usr/X11/bin/i386 over /usr/X11/bin/amd64. Because right now I am on DRM and don't want to waste hours on attempting to find out why the other problem hit me. Just to ensure that somebody checks this. -- %martin bochnig
