We run QNX 4.25 Patch D.
If I try mounting an MO right after booting there are no problems.
If i try mounting after quite a while it still works sometimes.
But often “mount /dev/mo0 /mo” returns “not enought memory”.
But there are still 20 MB of Ram available, so I was wondering how much
RAM does QNX need for mounting an MO …?
Or is it some bug where a workaround has been developed already?
MfG
Micro (aka Sebastian)
Sebastian wrote:
We run QNX 4.25 Patch D.
If I try mounting an MO right after booting there are no problems.
If i try mounting after quite a while it still works sometimes.
But often “mount /dev/mo0 /mo” returns “not enought memory”.
Not sure if this manifests itself in that manner, but are you running
out of de-blcoking buffers. Do you also have a CD-ROM drive on that
system? By default Fsys.* drivers only have enough buffer for one
non-512-byte-sector device (so access to the CD may prevent later access
to the MO). But this displays a message - “Can’t get free buffers for
deblocking” - do you see that? You might want to try increasing the
buffers anyway via the “Fsys.eide fsys -B16” option. Otherwise, if Fsys
has run out of heap memory there will be a message to that effect in the
traceinfo (code 4/36, “internal heap exhaustion …”).
hm, no its not.
its “not enough memory” - i thought with “-B 16” it may ran a bit better.
But today i encountered that problem again.
Has there to be no space in between B and 16?
John Garvey wrote:
Sebastian wrote:
We run QNX 4.25 Patch D.
If I try mounting an MO right after booting there are no problems.
If i try mounting after quite a while it still works sometimes.
But often “mount /dev/mo0 /mo” returns “not enought memory”.Not sure if this manifests itself in that manner, but are you running
out of de-blcoking buffers. Do you also have a CD-ROM drive on that
system? By default Fsys.* drivers only have enough buffer for one
non-512-byte-sector device (so access to the CD may prevent later access
to the MO). But this displays a message - “Can’t get free buffers for
deblocking” - do you see that? You might want to try increasing the
buffers anyway via the “Fsys.eide fsys -B16” option. Otherwise, if Fsys
has run out of heap memory there will be a message to that effect in the
traceinfo (code 4/36, “internal heap exhaustion …”).
So, i also came up with a traceinfo now
I think i can reproduce it now, but in a bit other way then it generally
happens.
Generally u can do still everything, but mounting MO.
Now i took the Computer to full activity and opened a lot of TTY´s and
Programms. When i cannot open any “pterm” anymore, i start the Helpbrowser.
After that MO-mounting stops (so much for reproducing, generally just one
application is running and it occures anyway …)
Also here the additional traceinfo:
QUOTE prog=traceinfo
// General mounting
Jun 28 19:48:38 5 00005109 Scsi sense (unit=1 scsi=2 err=70h sense=5h
asc=20h as
cq=0h)
// edditing with vi
Jun 28 19:51:34 2 00003024 00013F1B 00052EEB 646F6E69 65
Jun 28 19:51:34 2 00003024 00013F1B 00052EEB 646F6E69 65
Jun 28 19:51:34 2 00003024 00013F1B 00052EEB 656D616E
Jun 28 19:51:34 2 00003024 00013F1B 00052EEB 656D616E
Jun 28 19:51:34 2 00003024 00013F1B 00052EEB 656D616E
Jun 28 19:51:34 2 00003024 00013F1B 00052EEB 656D616E
Jun 28 19:51:34 2 00003024 00013F1B 00052EEB 646F6E69 65
Jun 28 19:51:34 2 00003024 00013F1B 00052EEB 656D616E
Jun 28 19:51:39 2 00003024 00013F1B 00052EEB 646F6E69 65
Jun 28 19:51:39 2 00003024 00013F1B 00052EEB 656D616E
// mounting again, but this time with failure ( mount: mount() of /dev/mo0
failed: Not enough memory )
Jun 28 19:51:49 5 00005109 Scsi sense (unit=1 scsi=2 err=70h sense=5h
asc=20h as
cq=0h)
Jun 28 19:53:07 2 00003024 00013F1B 00052EEB 74696E75
/QUOTE
micro wrote:
So, i also came up with a traceinfo now
Jun 28 19:51:34 2 00003024 00013F1B 00052EEB 646F6E69 65
Jun 28 19:51:34 2 00003024 00013F1B 00052EEB 646F6E69 65
Jun 28 19:51:34 2 00003024 00013F1B 00052EEB 656D616E
Jun 28 19:51:34 2 00003024 00013F1B 00052EEB 656D616E
Jun 28 19:51:34 2 00003024 00013F1B 00052EEB 656D616E
Jun 28 19:51:34 2 00003024 00013F1B 00052EEB 656D616E
Jun 28 19:51:34 2 00003024 00013F1B 00052EEB 646F6E69 65
Jun 28 19:51:34 2 00003024 00013F1B 00052EEB 656D616E
Jun 28 19:51:39 2 00003024 00013F1B 00052EEB 646F6E69 65
Jun 28 19:51:39 2 00003024 00013F1B 00052EEB 656D616E
Jun 28 19:53:07 2 00003024 00013F1B 00052EEB 74696E75
Yes, those are all messages from Fsys about running out of heap/memory.
You’ll need to increase the ‘Fsys -H’ parameter to allocate more.
Refer to historical threads in this newsgroups for more discussion on this
(in fact I think it was you who had a “Too many open files” thread
going, this is the same issue, so use a bigger value).
p.s. You could add the following to your “/etc/config/traceinfo” file,
to the “#major 0x00003 /* Fsys */” section, to get textual display:
" 36 internal heap exhaustion (nbytes=%ld/%ld) (object=%s)"
In fact you thought right 
It was me asking about this, but i also asked where to get information on
the “-H” Option of Fsys, since it is nowhere documented.
I do not know what size of number to write there behind (e.g. 2, 2048,
even more?), also not what is the default value.
But tell me how the internal Heap can be exhausted, we close all our
programs etc., there should be no situation where the Heap could be
exhausted, otherwise the memory management leaks some holes, where
reserved memory is not free´ed again.
For now i would be happy if somebody tells me the dimensions of the size
to write behind the “-H” and even more happy if somebody knows a reason
for the exhaustion of our heap, even when i close all programs it does not
free the heap anymore.
Thanks a lot
John (if u don`t mind me calling you that way) 
Sebastian wrote:
It was me asking about this, but i also asked where to get information on
the “-H” Option of Fsys, since it is nowhere documented.
I have answered this many times in the newsgroups over the last 5 years.
But here’s another summary, hopefully it will answer your questions …
… if you have Fsys 4.24Y it is fairly simple, previous versions
involve more calculation (but the traceinfo gives you some hints).
Thx a very lot John, that helped.
ill c/p this to osnews too, since the problem is discussed there too.