> 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.
so at least half a success ? ok, let's look for the 2nd half too...
btw, what about 32bpp? does it lockup too?
or does only 16bpp still show this problem?
> 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.)
this is a networking card (async. transfer mode, or similar), "Fore" the company ?
which chipsets etc ? please send the output of "cat /proc/pci" and
"scanpci -v" with and without this card after reboot (plus server output
("-probeonly" is ok for lockup setup)).
does this card have an own PCI bridge by any chance ?
there are problems with a 4-port-ethernet card for a x86-based system
right now (also rock stable without this card). just an idea...
is it sufficient to crash if the card is installed without using it
or even configuring it ?
> 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?
- faster access to frame buffer (for same pixel/second rate) from CPU
- other pixel alignments (16bit access vs. 8bit accesses...)
> 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.
or other AS255/S3 owners only use 8bpp ? there have been a number of
reports for Trio64 card; don't think they're using 16bpp with only 80Mhz
and poor performace...
for 16bpp, does it lockup immedieately at startup or only after some
time/operations ? again, it's most important to know *where* it locks up
to get ideas what to try next
> 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):
>
> 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.
even that didn't help ? but does it crash in memcpy routines for your
lasting 16bpp problem, or probably somewhere else ?
> 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
screen readback isn't possible with x64 chips in this mode.
frame buffer writes chould be done, though (so maybe we should add
"no_memwrite_ access" and only call s3ImageWriteNoMem() but not s3ImageReadNoMem() ?
but OTOH this is slow and won't fix the real problem (but it's a pointer
that direct frame buffer access is still the problem).
btw, which "proper hack" is needed (if any other than allowing this option) ?
> we know that the reason for these lockups is certainly the framebuffer
> access (either through the LFB space or VGA window).
I'd like that you have a PCI analyser which shows the last bus cycles
to get an idea why it's crashig (I'm dreaming of such a device for a long time now;)
> I'm afraid I should send you my ATM card for this... :-)
please give more details about this card (vendor, model etc.).
my idea is asking around if anyone has such a card in my region
(e.g. Werner Almesberger in Zuerich, Switzerland).
do you have different ATM cards for testing, or just this single one ?
could it be that this special card or just this model is broken?
or it's driver ?
> > 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".
>
> 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:
of course you're right, CR67 as a typo!
> 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.
so I guess CR66_7 doesn't matter for XF86_S3 for your lockups too ?
> > 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
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 ^^^^^ ^^^^^