Mindready Firewire driver doesn't work under 6.2.1NC

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

I just upgraded from QNX 6.2.0 NC to QNX 6.2.1 NC, and now
the Mindready LLA won’t initialize at all. It prints:

./devfw-ohci

SedNet2 Low Level API (LLA) version 2.3.2 Fix D (Nov 26 2002)
mmap failed: Not enough memory.

This happens on the first call to the Mindready LLA.
The program was running fine on QNX 6.2.0 NC.

This probably relates to the change in QNX which removed
the “sysinfo” page from memory in 6.2.1 systems. See
the “core technology” section of the release notes on
the 6.2.1 installation CD.

John Nagle
Animats

2

In article <3EDA8309.3070905@downside.com>, nagle@downside.com says…

./devfw-ohci

SedNet2 Low Level API (LLA) version 2.3.2 Fix D (Nov 26 2002)
mmap failed: Not enough memory.

mmap once more :slight_smile:

ed1k

3

Hi Mr Nagle, Ed1k

Mindready has already solved this issue.
The issue was related to the use of mmap() function as stated by ed1k.
To solve this problem, we simply used mmap_device_memory() function instead.

Mr Nagle received the version 3.1.1 of our Sednet 1394 LLA which is released
for QNX 6.2.0
but was fully tested on version QNX 6.2.1 NC.

If anybody needs further assistance, please contact Mindready Support Team
at :
Support1394@Mindready.com




“ed1k” <ed1k@humber.bay> wrote in message
news:MPG.19445812a8c6286c9896cd@inn.qnx.com…

In article <> 3EDA8309.3070905@downside.com> >, > nagle@downside.com > says…

./devfw-ohci

SedNet2 Low Level API (LLA) version 2.3.2 Fix D (Nov 26 2002)
mmap failed: Not enough memory.

mmap once more > :slight_smile:

ed1k

4

In article <bbia2m$kvc$1@inn.qnx.com>, eric.paiement@mindready.com says…

Hi Eric,

What a lightning answer! Bravo! I never had a chance to use mindready’s products 8^(
Cheers,
ed1k.

Hi Mr Nagle, Ed1k

Mindready has already solved this issue.
The issue was related to the use of mmap() function as stated by ed1k.
To solve this problem, we simply used mmap_device_memory() function instead.

Mr Nagle received the version 3.1.1 of our Sednet 1394 LLA which is released
for QNX 6.2.0
but was fully tested on version QNX 6.2.1 NC.

If anybody needs further assistance, please contact Mindready Support Team
at :
Support1394@Mindready.com

5

The Mindready update worked. Had to recompile and update
some paths, but no code changes were required. Thanks.

Mindready has been really good about support.

John Nagle
Animats

ed1k wrote:

In article <bbia2m$kvc$> 1@inn.qnx.com> >, > eric.paiement@mindready.com > says…

Hi Eric,

What a lightning answer! Bravo! I never had a chance to use mindready’s products 8^(
Cheers,
ed1k.


Hi Mr Nagle, Ed1k

Mindready has already solved this issue.
The issue was related to the use of mmap() function as stated by ed1k.
To solve this problem, we simply used mmap_device_memory() function instead.

Mr Nagle received the version 3.1.1 of our Sednet 1394 LLA which is released
for QNX 6.2.0
but was fully tested on version QNX 6.2.1 NC.

If anybody needs further assistance, please contact Mindready Support Team
at :
Support1394@Mindready.com

6

We’ve recently been struggling with QNX crashes during
startup of the Mindready LLA package for IEEE-1394 controller
access. Everything was working nicely under QNX 6.2.0, but
after “upgrading” to QNX 6.2.1, our application stopped working
because of the change to the “mmap()” API in QNX.

Mindready quickly came out with a fix to their LLA, and
we rebuilt with their new library, and our application seemed to work
again. But once we started running it more, we discovered that
we were getting crashes of the entire system during the
Mindready “llaAttach” call, as the LLA starts up.

Mindready is working to fix this, and they’ve been able to
reproduce the problem, but it’s intermittent for them. Is
anyone else seeing problems with the memory-mapping API in
6.2.1?

John Nagle


John Nagle wrote:
The Mindready update worked. Had to recompile and update
some paths, but no code changes were required. Thanks.

Mindready has been really good about support.

John Nagle
Animats

ed1k wrote:

In article <bbia2m$kvc$> 1@inn.qnx.com> >, > eric.paiement@mindready.com
says…

Hi Eric,

What a lightning answer! Bravo! I never had a chance to use
mindready’s products 8^( Cheers,
ed1k.


Hi Mr Nagle, Ed1k

Mindready has already solved this issue.
The issue was related to the use of mmap() function as stated by ed1k.
To solve this problem, we simply used mmap_device_memory() function
instead.

Mr Nagle received the version 3.1.1 of our Sednet 1394 LLA which is
released
for QNX 6.2.0
but was fully tested on version QNX 6.2.1 NC.

If anybody needs further assistance, please contact Mindready Support
Team
at :
Support1394@Mindready.com
\

7

Mindready is working to fix this, and they’ve been able to
reproduce the problem, but it’s intermittent for them. Is
anyone else seeing problems with the memory-mapping API in
6.2.1?

On the three boxes I run QNX on I haven’t seen any full system deadlocks
from any drivers or when running programs (all of which use the mmap()
interface). Curious - during that attach function are they also setting
up an interrupt handler? Does your computer still pass the Numlock
test during this system-wide hangup?

chris

–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

8

“Chris McKillop” <cdm@qnx.com> wrote in message
news:be2q14$38l$1@nntp.qnx.com…

Mindready is working to fix this, and they’ve been able to
reproduce the problem, but it’s intermittent for them. Is
anyone else seeing problems with the memory-mapping API in
6.2.1?


On the three boxes I run QNX on I haven’t seen any full system deadlocks
from any drivers or when running programs (all of which use the mmap()
interface). Curious - during that attach function are they also setting
up an interrupt handler? Does your computer still pass the Numlock
test during this system-wide hangup?

I’ve seen a really odd case of ‘lockup’ lately with 6.2.0 even. A system
that’s essentially idle being left alone for a while eventually becomes
unresponsive. I can type, but no response to anything (keyboard driver works
in interrupt mode though). If spin is left to run on a high priority console
before the lockup, it keeps running… and does not show high CPU usage or
any processes hogging CPU. If I exit it and try to restart, it does not
(console hangs after ENTER just like others).

9

John Nagle wrote:

We’ve recently been struggling with QNX crashes during
startup of the Mindready LLA package for IEEE-1394 controller
access. Everything was working nicely under QNX 6.2.0, but
after “upgrading” to QNX 6.2.1, our application stopped working
because of the change to the “mmap()” API in QNX.

Mindready quickly came out with a fix to their LLA, and
we rebuilt with their new library, and our application seemed to work
again. But once we started running it more, we discovered that
we were getting crashes of the entire system during the
Mindready “llaAttach” call, as the LLA starts up.

Mindready is working to fix this, and they’ve been able to
reproduce the problem, but it’s intermittent for them. Is
anyone else seeing problems with the memory-mapping API in
6.2.1?

Yes … if you switch from mmap() to mmap_device_memory
the physical_address must be provided by an uint64_t variable
or must be casted with uint64_t.

If this is not the case → mmap_device_memory fails again =:-/

Armin