pci_attach_device fail

bridged with qnx.rtos
Post Reply
Francois Joubert

pci_attach_device fail

Post by Francois Joubert » Mon May 21, 2007 11:50 am

In my startup script I would like to detect if a 3rd party vendor's card
is plugged into the system.
# pci -v | grep -q XR17C154
# if [ $? -eq 0]; then
# Load driver
# fi

This works well.

Now I want to start up my own board's driver but pci_attach_device fail,
error code 16, Resource busy.

It only fails if the script execute the command:
# pci -v | grep -q XR17C154

The following command does not cause this problem:
# pci -v

Setting the flag PCI_SHARE in pci_attach_device does not solve the problem.

Any ideas?

Francois

David Gibbs

Re: pci_attach_device fail

Post by David Gibbs » Fri Jun 01, 2007 7:58 pm

Francois Joubert <sommerfj@webmail.co.za> wrote:
In my startup script I would like to detect if a 3rd party vendor's card
is plugged into the system.
# pci -v | grep -q XR17C154
# if [ $? -eq 0]; then
# Load driver
# fi

This works well.

Now I want to start up my own board's driver but pci_attach_device fail,
error code 16, Resource busy.
That usually means someone else has (still has) a pci_attach() to the
device without the PCI_SHARE flag.
It only fails if the script execute the command:
# pci -v | grep -q XR17C154
Odd. Is the pci command still lingering or something?
The following command does not cause this problem:
# pci -v

Setting the flag PCI_SHARE in pci_attach_device does not solve the problem.
I wouldn't expect it to. If someone has attached without SHARE, then
they've demanded exclusive use -- you can't then SHARE it. The first
attacher has to SHARE for a later attacher to succeed.
Any ideas?
Figure out, somehow, who has done the attach. Does the pci hang
around? Do you take a branch in your script that runs something
that attaches?

-David
--
David Gibbs
QNX Training Services
dagibbs@qnx.com

Francois Joubert

Re: pci_attach_device fail

Post by Francois Joubert » Mon Jun 04, 2007 2:11 pm

My apologies, I should have reported back. I believe it to be a
corrupted build process/incompatible shared library on my side. After a
fresh rebuild of all the modules, I could not repeat the problem.

However, what I noted was, through testing, that "pci -v | grep -q
XR17C154" caused the problem whereas "pci -v" did not cause the problem.

I will report back if this problem crops up again.

Francois

David Gibbs wrote:
Francois Joubert <sommerfj@webmail.co.za> wrote:
In my startup script I would like to detect if a 3rd party vendor's card
is plugged into the system.
# pci -v | grep -q XR17C154
# if [ $? -eq 0]; then
# Load driver
# fi

This works well.

Now I want to start up my own board's driver but pci_attach_device fail,
error code 16, Resource busy.

That usually means someone else has (still has) a pci_attach() to the
device without the PCI_SHARE flag.

It only fails if the script execute the command:
# pci -v | grep -q XR17C154

Odd. Is the pci command still lingering or something?

The following command does not cause this problem:
# pci -v

Setting the flag PCI_SHARE in pci_attach_device does not solve the problem.

I wouldn't expect it to. If someone has attached without SHARE, then
they've demanded exclusive use -- you can't then SHARE it. The first
attacher has to SHARE for a later attacher to succeed.

Any ideas?

Figure out, somehow, who has done the attach. Does the pci hang
around? Do you take a branch in your script that runs something
that attaches?

-David

Post Reply

Return to “qnx.rtos”