Re: XFree86 4.1.0pre1v1.3 on Alpha
On Sat, Jun 30, 2001 at 12:36:14PM -0400, [EMAIL PROTECTED] wrote: As it turns out, one can add an option in the Device Section of the XF86Config file: Option NoInt10 Good to know. I looked for something like that, but it's not mentioned in the user-side documentation at all. I tried this and it does work on my system, but for the record is spelled NoINT10. Hmm; actually, I think it may do the comparison case-less, as I have had it work as NoInt10 and noint10... And unfortunately it's a tough nut to crack because it leaves the system in an unusable state. Unfortunately I think it's gonna take some serious code study by someone who's familiar with the minutia of the LX (or does it die on a Miata too?) I think it does crash on MIATA as well, but I'm not certain. And yes, it's tough. It may not even be the fault of the int10 code, either. Last one we had to go to this level with, was a problem we saw on *all* boxes with Radeon 32MB SDR PCI. It turned out to be a problem caused by running the BIOS more than once - it would work the first time (ie when the SRM console's BIOS emulator ran on the cold card), but then when int10 was run later under XFree86, it would make a mistake because the state of the card was already set up. I'd call that a problem in the BIOS code myself, but there's rather small chance of getting it fixed... ;-} Yes, I agree, since we have the nice option that makes things work once again. And now that it's been discussed here, maybe affected people will actually find the appropriate option via a web search. Well, an entry in release notes is always in order, or a FAQ if there's an appropriate one. I posted that workaround, as well as some others, to axp-list, and it seemed to help... ;-} --Jay++ - Jay A EstabrookAlpha Engineering - LINUX Project Compaq Computer Corp. - MRO1-2/K20 (508) 467-2080 200 Forest Street, Marlboro MA 01752 [EMAIL PROTECTED] - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.1.0pre1v1.3 on Alpha
On Sat, Jun 30, 2001 at 10:06:05AM -0400, Doug Larrick wrote: The attached patch makes a PCI Voodoo3 3000 PCI card work on my Alpha PC164LX. Without it, the system goes into a whole lot of bad during X initialization: 'sync' works afterwards, but 'halt' does not. The root of the problem is that the int10 subsystem is extremely broken for Alpha, at least for the type of Alpha that I have (LX). After int10 has done its work, calls to sleep(), usleep(), nanosleep(), etc. never return. My patch simply disables the use of int10 (and therefore also DDC) in the tdfx driver, like is done on PowerPC. This change probably precludes use of a 3dfx card as a second head on Alpha. The functionality obviously worked for someone, or it would not have been put in. But IMHO this way is safer for more users. I had a similar problem with a Voodoo Banshee card in an LX, though it was more serious - it crashed the machine back to SRM console. But that same card, and a Voodoo3 3000, work just fine in the newer (EV6) boxes, without the need for disabling int10 processing. The same type of int10-related problem has cropped up with other drivers on other cards when run on an LX; I seem to remember it was the GLINT driver, but it could have been the R128 one. As it turns out, one can add an option in the Device Section of the XF86Config file: Option NoInt10 to prevent int10 from getting run on a 3DFx card. Unfortunately, this does not work for some other drivers, so is not a general solution to int10-related problems. It would be much better if we could determine what it is about running int10 on some cards' BIOS code on an LX that causes problems. It's been on my TODO list for a while, and Egbert Eich, one of the XFree86 fellows responsible for int10 and who has a number of Alphas, would also like to see a solution. But to this point, the time hasn't been available to attack it. I have some int10-related patches against 4.1.0 that remove most if not all of the unaligned accesses that occur during the running of int10, but I don't believe they solve this problem with Voodoo cards. So, bottom line WRT the patches, is that they provide the best safety against uninformed folks using 3DFx cards on LX-style machines, but I don't recommend those patches be passed along to XFree86. They are overkill, don't apply to all Alpha machines, and will have side-effects when attempting to do multi-head with 3DFx cards, as Doug noted. --Jay++ - Jay A EstabrookAlpha Engineering - LINUX Project Compaq Computer Corp. - MRO1-2/K20 (508) 467-2080 200 Forest Street, Marlboro MA 01752 [EMAIL PROTECTED] -
Re: XFree86 4.1.0pre1v1.3 on Alpha
On Sat, Jun 30, 2001 at 12:36:14PM -0400, [EMAIL PROTECTED] wrote: As it turns out, one can add an option in the Device Section of the XF86Config file: Option NoInt10 Good to know. I looked for something like that, but it's not mentioned in the user-side documentation at all. I tried this and it does work on my system, but for the record is spelled NoINT10. Hmm; actually, I think it may do the comparison case-less, as I have had it work as NoInt10 and noint10... And unfortunately it's a tough nut to crack because it leaves the system in an unusable state. Unfortunately I think it's gonna take some serious code study by someone who's familiar with the minutia of the LX (or does it die on a Miata too?) I think it does crash on MIATA as well, but I'm not certain. And yes, it's tough. It may not even be the fault of the int10 code, either. Last one we had to go to this level with, was a problem we saw on *all* boxes with Radeon 32MB SDR PCI. It turned out to be a problem caused by running the BIOS more than once - it would work the first time (ie when the SRM console's BIOS emulator ran on the cold card), but then when int10 was run later under XFree86, it would make a mistake because the state of the card was already set up. I'd call that a problem in the BIOS code myself, but there's rather small chance of getting it fixed... ;-} Yes, I agree, since we have the nice option that makes things work once again. And now that it's been discussed here, maybe affected people will actually find the appropriate option via a web search. Well, an entry in release notes is always in order, or a FAQ if there's an appropriate one. I posted that workaround, as well as some others, to axp-list, and it seemed to help... ;-} --Jay++ - Jay A EstabrookAlpha Engineering - LINUX Project Compaq Computer Corp. - MRO1-2/K20 (508) 467-2080 200 Forest Street, Marlboro MA 01752 [EMAIL PROTECTED] -
Re: X problem
On Fri, Sep 29, 2000 at 01:06:23PM +0200, Ralf HECKHAUSEN wrote: I installed Debian 2.2 on an AlphaStation 255/233 and everythings works fine, but I cannot get X run. XF86Setup without using the XF86Config file switches to graphics mode but the screen is scambled. It looks as if 8 subsequent bytes in the video memory are filled with the same contents. SuperProbe returns S3 Trio64 with 2MB video memory. If I use the S3 server with this video card selected, the machine hangs. At one time, there was a problem (X 3.3.x hanging the machine) encountered most frequently on the AS2xx machines equipped with a Trio64 card. The problem was worked around by inserting (IIRC): Option "no_pci_disconnect" into the "Device" section of the XF86Config file. Good luck, hope this helps... --Jay++ - Jay A EstabrookAlpha Engineering - LINUX Project Compaq Computer Corp. - MRO1-2/K20 (508) 467-2080 200 Forest Street, Marlboro MA 01752 [EMAIL PROTECTED] - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X problem
On Fri, Sep 29, 2000 at 01:06:23PM +0200, Ralf HECKHAUSEN wrote: I installed Debian 2.2 on an AlphaStation 255/233 and everythings works fine, but I cannot get X run. XF86Setup without using the XF86Config file switches to graphics mode but the screen is scambled. It looks as if 8 subsequent bytes in the video memory are filled with the same contents. SuperProbe returns S3 Trio64 with 2MB video memory. If I use the S3 server with this video card selected, the machine hangs. At one time, there was a problem (X 3.3.x hanging the machine) encountered most frequently on the AS2xx machines equipped with a Trio64 card. The problem was worked around by inserting (IIRC): Option no_pci_disconnect into the Device section of the XF86Config file. Good luck, hope this helps... --Jay++ - Jay A EstabrookAlpha Engineering - LINUX Project Compaq Computer Corp. - MRO1-2/K20 (508) 467-2080 200 Forest Street, Marlboro MA 01752 [EMAIL PROTECTED] -
