Re: I/O flexpages / new mapping DB issue with overlapping ports
Frank Mehnert <[email protected]>
| Newsgroups | gmane.comp.micro-kernel.l4.l4ka.general |
|---|---|
| Organization | InnoTek Systemberatung GmbH |
| Message-ID | <[email protected]> |
Espen, On Wednesday 07 June 2006 18:16, Espen Skoglund wrote: > [Frank Mehnert] > > > Hi, > > I have a problem using I/O flexpages with Pistachio. My application > > raises I/O pagefaults and the pager replies the corresponding I/O > > flexpage. But an assertion is triggered if an I/O fpage should be > > mapped while the application has already mapped parts of that I/O > > fpage, for example > > > > 1. I/O fault port=0xcfb size=1 => map I/O flexpage (ok) > > 2. I/O fault port=0xcf8 size=4 => map I/O flexpage > > > > At this point a kernel assertion is triggered: > > > > Assertion isize > newsize failed in > > file /home/fm3/src/pistachio/kernel/src/generic/vrt.cc, line 346 > > (fn=f01029b1) > > > > Any ideas? > > Actually. I just realized that there were a number of pending fixes > to the vrt stuff from a long time ago that I had forgot to committ. > Have committed it now (together with a lot of other stuff). Sorry for the delay. I just updated Pistachio from CVS including your latest fixes. Same problem. Enabled VRT_MAP and VRT_MAPCTRL: ROOT: I/O fault from 8.00 port=0cfb size=01 ip=00447abc ROOT: Sending ports 0cfb-0cfb to task #08 io<f0352040>::map (fp=0cfb0026 [00000cfb,0] base=00000cfb) to io<f0352060> (fp=00004020 [00000000,16]) ROOT: I/O fault from 8.00 port=0cf8 size=04 ip=00447ac4 ROOT: Sending ports 0cf8-0cfb to task #08 io<f0352040>::map (fp=0cf80826 [00000cf8,2] base=00000cf8) to io<f0352060> (fp=00004020 [00000000,16]) Assertion isize > newsize failed in file /home-sarge/fm3/src/afterburner/extern/pistachio/kernel/src/generic/vrt.cc, line 346 (fn=f0303151) Another thing I observed is that although my privileged root task received the whole I/O space (ports 0...0xffff), ports 0..0xff don't occur in the 'I' listing of the mapping database and accessing a port of that range raises a page fault. MR2 was 00004027 after the IPC to Sigma0 -- seems ok. Frank -- ## InnoTek Systemberatung GmbH, http://www.innotek.de ##
signature.asc
(application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEhwBq6z8pigLf3EcRAvC0AJwK07E+rzqjvSBtNi+RjD2qt2a9EQCggTsi A1MR5MOm9pILZlHYa3VjsQs= =/6q2 -----END PGP SIGNATURE-----