lkml.org 
[lkml]   [1999]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: New resources - pls, explain :-(

On Tue, 17 Aug 1999, Petr Vandrovec Ing. VTEI wrote:

> Hi,
> > The ideal situation is what the PCI spec says about transaction ordering.
> > Basically (from memory):
> > - - Strong ordering in each direction.
> > - - The design of the whole PCI system must ensure that no deadlock or
> > livelock may occur.
> What about this: CPU cannot finish write cycle to G200 because of G200
> command queue is full. G200 cannot empty slot in command queue because of

I donnot know of video boards in fact, but I beleived that it was possible
to check room in the fifo command queue of video boards.

> currently processed command requires access to PCI bus (to main memory) to
> finish. Does this count as deadlock or livelock (*)? Is it possible to

If the video board must read from memory to free some room in the command
queue, and the PCI write to the command queue of the board has been
posted, it may happen that you are just stuck. :-)

What should happen could be the following:

1) Since the video board cannot accept the data, it must terminate the
PCI write transaction with retry.

2) Then the arbiter will grant it the bus (provided that the video
board has asserted its REQ#)

3) The PCI read can complete at the originator (video board) only after
the completion of the posted PCI write (in reverse direction), so the
bridge will complete the read with retry (or as a delayed transaction).

This process will never progress. Livelock or deadlock does not make
differences in this regard.

> handle this situation (limited resources on both videocard, host CPU
> and bridge) correctly?

Or check that the command fifo has room enough for the next command prior
to queuing it, if it is possible.

Note that if it is not possible to ensure that there is room for a command
prior to queuing it and if the board may have to read from memory in order
to free space in the fifo command, then my opinion could be that this
hardware is badly designed.

But, dreaming a bit, ... another ugly solution could have been that the
video board terminates the PCI write with an abort condition and reports
this condition in some IO register. Then you just would have to check this
condition after having tried to brute-force any command in the command
fifo and retry the write if it failed. This seems too ugly to have any
chance to be possible or ever work if it was so, probably.

> > But the reality is quite different:
> > Some system-PCI bridges may:
> > - - Reorder write to memory.
> > - - Only flush on a read posted write transactions that go in the
> > direction of this read transaction (donnot flush PWs in the opposite
> > direction)
> > - - Only ensure that everything is flushed prior to the interrupt delivery.
> > - - Not snoop DMA accesses.
> > - - Etc...
> > There is no nightmare here, but just too much fun. ;-)

> It cost couple of hours to find, why in busmastering mode my driver
> painted (after matroxfb switches to graphics and redraws old vgacon screen)
> just 832 1/2 character with 6x11 font, 20 1/3 with 12x22 font and INF with
> 8x16 font before complete lock (no poweroff button on ATX) occurs (**).

If it only costed you a couple of hours to find the cause of such a
problem, then I can only say: BRAVO!

Gérard.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.025 / U:1.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site