pci_attach-pci_detach-6.2.0-6.2.1

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

Hello,

I am running my driver for BT848 cards (bttvx) under qnx 6.2.0 and it works
perfectly. But exactly the same code in a 6.2.1 box is blocking the machine
completly. The problem appears when I call the pci_detach_device() function
when closing the driver.
I don’t understand why this is happening. I am not totally sure, but the
block seems to be a consequence of a 100% use of the CPU.
Is there diferences in the pci server from 6.2.0 to 6.2.1??
Ah! both are PE editions…

Thank you in advance.

Carlos Beltran

2

You don’t say what platform you are running on! Is this x86 or some other
platform? Are you running 6.2.0 and 6.2.1 on exactly the same machine? Do
you disable the adapter before you call pci_detach_device()?

“Carlos Beltran” <cbeltran@dist.unige.it> wrote in message
news:bodtq4$5j3$1@inn.qnx.com…

Hello,

I am running my driver for BT848 cards (bttvx) under qnx 6.2.0 and it
works
perfectly. But exactly the same code in a 6.2.1 box is blocking the
machine
completly. The problem appears when I call the pci_detach_device()
function
when closing the driver.
I don’t understand why this is happening. I am not totally sure, but the
block seems to be a consequence of a 100% use of the CPU.
Is there diferences in the pci server from 6.2.0 to 6.2.1??
Ah! both are PE editions…

Thank you in advance.

Carlos Beltran

3

Hello,
Yes, you are right.

“Hugh Brown” <hsbrown@qnx.com> wrote in message
news:boe1uv$8cc$1@inn.qnx.com…

You don’t say what platform you are running on! Is this x86 or some other
platform?

x86

Are you running 6.2.0 and 6.2.1 on exactly the same machine? Do

Yes. Actually the machine is floppy booted. I have used exactly the same
buildfile to create the two floppys, the only diference is the qnx versions
in the machines I have used to create them, 6.2.0 in one case and 6.2.1 in
the other.
The problem appears too in another 6.2.1 system (x86) with full
installation. It is a dual processor and it blocks in 1 processor
configuration and in 2 processors configuration. In the 2 processors case,
one of the cpu remains 100% used and after two or three trials
(starting/closing the driver software) it blocks completly.
I have not been able to reproduce the problem in any of the 6.2.0 boxes we
have, we have 4 of them, with all kind of diferent configurations; 1
processors, two processor, harddisk booted, floppy booted, network booted, 1
network card, two network cards… the problem verifies only in the 6.2.1.

you disable the adapter before you call pci_detach_device()?

Uhmm, what do you mean with ‘disable the adapter’?
What I do is to stop the acquisition in the framegraber by writing in the
adequate register…
then stopping the dma tranfers(by again writing in a framegrabber register)
then detaching the assigned irq (InterruptDetach)
and then calling pci_detach_device()


I will work in the problem the next hours so I hope I can provide more data
later.
I know this is an strange problem; this is why I am writing in the
newsgroup, I am sorry I am not supplying enought data, but you will
undertand this is dificult to debug, my hope was that this was somekind of a
know bug in the pci stuff…

Thanks in advance.

Carlos Beltran

“Carlos Beltran” <> cbeltran@dist.unige.it> > wrote in message
news:bodtq4$5j3$> 1@inn.qnx.com> …
Hello,

I am running my driver for BT848 cards (bttvx) under qnx 6.2.0 and it
works
perfectly. But exactly the same code in a 6.2.1 box is blocking the
machine
completly. The problem appears when I call the pci_detach_device()
function
when closing the driver.
I don’t understand why this is happening. I am not totally sure, but the
block seems to be a consequence of a 100% use of the CPU.
Is there diferences in the pci server from 6.2.0 to 6.2.1??
Ah! both are PE editions…

Thank you in advance.

Carlos Beltran
\

4

Ok, ok,. so forgot about all the pci stuff. The problem seems to be related
with the interrupt handler…this is the code I use to create the
handler:
…
ThreadCtl( _NTO_TCTL_IO, 0 );

pthread_attr_init(&attr);

SIGEV_THREAD_INIT((&event), InterruptEvent,&attr, NULL);

btv->id =InterruptAttachEvent(info.Irq, &event, _NTO_INTR_FLAGS_PROCESS);

…

Each time an interrupt occurs an InterruptEvent thread is created; this
could explain the anormal behavior with the CPU 100% use due to some problem
with interrupts…
for some reason the behavior in 6.2.0 and 6.2.1 is diferent…
I am going to change the interrupt handler with a more clean implementation
with just one thread running…

Thx

Carlos Beltran

5

So, yes. The problem was there. For some reason, the interrupt detach were
not working correctly and I was not cleaning all the hardware in all the
details.But I don’t understand why the problem appeared only in 6.2.1.
BTW I found a clarifing note in the Rob’s book (pag 239):

“An ISR returning SIGEV_THREAD is one scenario that fill me with absolute
fear! I’d recommend avoiding this “feature” if at all possible”

:slight_smile:), Rob, I agree with you.

Carlos.

“Carlos Beltran” <cbeltran@dist.unige.it> wrote in message
news:bofvv8$j9u$1@inn.qnx.com…

Ok, ok,. so forgot about all the pci stuff. The problem seems to be
related
with the interrupt handler…this is the code I use to create the
handler:
…
ThreadCtl( _NTO_TCTL_IO, 0 );

pthread_attr_init(&attr);

SIGEV_THREAD_INIT((&event), InterruptEvent,&attr, NULL);

btv->id =InterruptAttachEvent(info.Irq, &event, _NTO_INTR_FLAGS_PROCESS);

…

Each time an interrupt occurs an InterruptEvent thread is created; this
could explain the anormal behavior with the CPU 100% use due to some
problem
with interrupts…
for some reason the behavior in 6.2.0 and 6.2.1 is diferent…
I am going to change the interrupt handler with a more clean
implementation
with just one thread running…

Thx

Carlos Beltran

6

Carlos Beltran <cbeltran@dist.unige.it> wrote:
CB > So, yes. The problem was there. For some reason, the interrupt detach were
CB > not working correctly and I was not cleaning all the hardware in all the
CB > details.But I don’t understand why the problem appeared only in 6.2.1.
CB > BTW I found a clarifing note in the Rob’s book (pag 239):

It’s on page 231 in earlier printings of the book.

CB > “An ISR returning SIGEV_THREAD is one scenario that fill me with absolute
CB > fear! I’d recommend avoiding this “feature” if at all possible”

CB > :slight_smile:), Rob, I agree with you.