Subject: Re: build aborts in regress/lib/libpthread/sem
To: None <cpg@aladdin.de, marcus@mc.pp.se>
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
List: port-dreamcast
Date: 02/13/2003 19:14:04
In article <yf9el6es2bh.fsf@mc.pp.se>
marcus@mc.pp.se wrote:

> 
> Christian Groessler <cpg@aladdin.de> writes:
> 
> > This might be a more general problem of the g2 bus space routines:
> > The G2_LOCK macro seems to disable exceptions. But what happens if the
> > page addressed by *addr is not available, and the exception is needed?
> 
> Yes, the function should make sure the source data is paged in before
> calling G2_LOCK.  If there is any race condition possible where the
> pages could be swapped out again before G2_LOCK is reached, the pages
> should be locked into memory.  I haven't looked into the details of
> the virtual memory system in NetBSD, but I assume there are such
> facilities available, to be used with DMA devices for example.

Nether I'm a VM guru, but in this case the buffer address passed from
MI mb86964.c is kernel mbufs' one, so it would never be paged out.
If the driver accesses memory of any user process, it should make
sure the buffer is locked by itself, and bus_space(9) wouldn't
care it at all.

Anyway, I just refered g2bus_bus_mem_*_region_1() to
implement g2bus_sparse_bus_mem_*_multi_1()..
If the fix is really needed all other functions
should also fixed but I'm afraid it causes big
performance penalty.

BTW, I have some questions about current G2_LOCK/UNLOCK implementation:

- In G2_LOCK, it uses _cpu_exception_suspend(), but shouldn't we
  use _cpu_intr_suspend() instead?

- In G2_UNLOCK, it implicitly pass zero to _cpu_exception_resume(),
  but shouldn't we restore returned value from the previous
  _cpu_exception_suspend() in G2_LOCK?

---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp