I'd like to know
- did you try the XFree86 3.3 server ? (if not, why???)
- does it still lockup without Option "no_pci_disconnect" ?
- any problems left when adding Option "no_pci_disconnect" ?
- did you only try 8bpp so far ? (this works fine for Nikita,
so please test 16/32bpp too!
- does anyone (with or without S3 card) has such a "Fore ATM" card ?
any known problems with this card ?
any idea what might be the reason or what to try next ?
please note that Nikita already rewrote BUSmemcpy.c (see below)
to use sparse access, but this didn't help either...
thanks for any idea, hint, pointer, ...
-----Forwarded message from Nikita Schmidt <cetus@snowball.ucd.ie>-----
Harald,
I wish to say that I've finally found a configuration that does not
cause S3 server to lock up the system. The configuration is simple:
-bpp 8. :-(
Last time I tried 8 bpp when I was fighting startup lockups in 3.2. It
did not help, so I never tried it anymore until yesterday.
Now I can say that it *may* be a real hardware problem. First, the
argument that "Digital UNIX doesn't lock up" no longer works: Digital
UNIX operates only in 8 bpp mode. Second, my investigations have shown
that the problem arises when (and only when) I have Fore ATM card
installed. (It actually doesn't matter what slot S3 is in.) But in
order to claim it as a hardware problem I have to install WinNT (grr...
both harddrives are using disklabel at the moment...) and see if it hangs
in 16 bpp mode.
Although it's rather strange problem - what on earth difference from the
PCI bus point of view can there be between 8 and 16 bpp? Twice as fast
video scan? Unlikely - it works in 1280x1024x8, but hangs in
800x600x16... Maybe I should try various strange options like
slow_dram_refresh, but there is a whole lot of them. Maybe the
difference in the way S3 accesses video memory in 8 and 16 bpp matters?
Anyway, thanks very-very much for solving the problem in general. 3.3
server with Option "no_pci_disconnect" is as stable as patched 3.2 - and
still locks up instantly without this option. Even on my supposedly buggy
hardware both work pretty well in 8 bpp, and both may suddenly hang the
system in 16 bpp mode. And I tend to consider my lockups completely
unrelated to that common AS255/S3 problem.
Just in case that you may have some ideas about this weirdness, here's
the list of things I've tried in hope to make it work (with no luck):
Option "number_nine" - yes, my card is #9, but this option
makes no visible difference;
Chipset "s3_generic";
Option "nolinear";
MemBase <various values, including those from /proc/pci>;
rewriting BUSmemcpy.c and lnx-video.c to use sparse space
instead of dense space and eliminate other-than-longword
accesses and bursts on the PCI.
Forcing Option "nomemaccess" (using proper hack in the code) helps to
get rid of lockups, but as far as I understand Trios can't read in this
mode, so the screen eventually gets messy. Well, that's no surprise, as
we know that the reason for these lockups is certainly the framebuffer
access (either through the LFB space or VGA window).
Lastly, some comments on your message.
On May 31, Harald Koenig wrote:
>
> yes I still remember and try to get hardware where I can reproduce and finally
> fix this myself.
I'm afraid I should send you my ATM card for this... :-)
>
> clearing CR67_7 disables "PCI bus disconnect" which might othewise occur if
> AD[1:0] != 00b (unaligned acces) or if the address during the burst goes outside
> the address ranges supported [from the S3 databook].
>
> CR3A_7 must not be set if CR67_7 is zero. when zero, it *EN*ables "PCI read burst cycles".
>
Maybe if PCI burst cycles are disabled in S3, but still happen on the bus
(originating from the CPU support chipset), either S3 or APECS just goes
berserk? That could be an explanation, as Alphas (at least those with
APECS chipset) almost always generate burst cycles on the PCI when
accessing it through the dense space. In this case it's not the
disconnect feature which is at fault. After all, there were no
unaligned accesses, nor accesses near the end of the supported address
space, when those lockups were happening.
Hold on... What does Digital UNIX think about it? Umm, you meant
CR66_7, not CR67_7, didn't you? At least your patch says it 66...
All right, here we go:
CR3A is 0x15 - whoa, burst cycles are enabled, as expected;
CR66 is 0x89, CR67 is 0x08 - if the register in question is CR66, then
DU has PCI disconnect enabled as well.
> I never understood why disabling read burst cycles needs the PCI disconnec feature
> and vice versa; maybe another S3 documentation bug ?!
>
I don't see any other reasonable explanation either. Probably they
could save a couple of transistors on this.
All right, sorry for taking your time, and thanks again for your help.
256 colours is better than nothing, although way worse than even 65536.
Best wishes
Nikita
-----End of forwarded message-----
Harald
--
All SCSI disks will from now on ___ _____
be required to send an email notice 0--,| /OOOOOOO\
24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^