The PCI writes correspond to 

PCI write to set a bit
Short delay (for loop counter)
PCI write to clr a bit

And this needs to be atomic so that the thread does not get scheduled out in the middle, hence it has been protected by 
the Interrupt locks

-----Original Message-----
From: Lichun Zhu [mailto:community-noreply@qnx.com] 
Sent: Wednesday, November 04, 2009 7:50 AM
To: ostech-core_os
Subject: Re: RE: SIGSEGV in InterruptUnlock / __inline_InterruptEnable 

If there is no specific reason, I don't see a point to use InterruptLock/Unlock. You better not to use kernel call 
within your IntterptLock/Unlock. Pci write will call pci server that involves kernel calls.




_______________________________________________

OSTech
http://community.qnx.com/sf/go/post41276

Hi,


The actual code is as follows:

InterruptLock(&_intr_lock);
    mapped_pci_mem_write(signal);
    pci_conf_write(0,0,0,PCI_INTA_REG,1)
    for(i=0; i < DELAY_INTERVAL; i++) {};
    pci_conf_write(0,0,0,PCI_INTA_REG,0)
InterruptUnlock(&_intr_lock);


The mapped_pci_mem_write writes into mapped pci device memory. I am not seeing anything that may cause sleep.
If the thread tries to sleep after a lock, would a crash occur while scheduling out the thread or issues like currently 
observed during InterrupUnlock

Can any other info be collected (such as thread privileges etc.) to better understand the issue?

Regards
Chaitanya


-----Original Message-----
From: Rajat Jain [mailto:community-noreply@qnx.com] 
Sent: Wednesday, November 04, 2009 11:58 AM
To: ostech-core_os
Subject: RE: SIGSEGV in InterruptUnlock / __inline_InterruptEnable 


Hi,

> InterruptLock(&_intr_lock);
> 
> /* couple of pci config writes */
> 
> InterruptUnlock(&_intr_lock);

Could you give the complete code please (/* couple of pci config writes
*/)? Are you sure you are not doing anything that may cause sleep /
reschedule as it is illegal to do that after you do InterruptLock().

Thanks,

Rajat

----Original Message----
From: Chaitanya Huilgol [mailto:community-noreply@qnx.com]
Sent: Wednesday, November 04, 2009 11:54 AM
To: ostech-core_os
Subject: RE: SIGSEGV in InterruptUnlock / __inline_InterruptEnable

> I have checked the return value of ThreadCtl, Also the issue
> does not occur immediately. Privileged I/O accesses do go
> through without causing SIGSEGV before this issue is hit
> 
> Regards
> Chaitanya H
> 
> -----Original Message-----
> From: Steve Reid [mailto:community-noreply@qnx.com]
> Sent: Tuesday, November 03, 2009 8:08 PM
> To: ostech-core_os
> Subject: RE: SIGSEGV in InterruptUnlock / __inline_InterruptEnable
> 
> Did you check the return code from ThreadCtl() to make sure
> that it was
> successful?
> 
> 
> Steve Reid (stever@qnx.com)
> Technical Editor
> QNX Software Systems
> 
> 
>> -----Original Message-----
>> From: Chaitanya Huilgol [mailto:community-noreply@qnx.com]
>> Sent: Tuesday, November 03, 2009 5:12 AM
>> To: ostech-core_os
>> Subject: SIGSEGV in InterruptUnlock / __inline_InterruptEnable
>> 
>> Hi,
>> 
>>  I am getting SIGSEGV during InterruptUnlock /
>> __inline_InterruptEnable
>> 
>> The piece of code that causes this fault is as follows:
>> ----------------------------------------------------------------
>> 
>> InterruptLock(&_intr_lock);
>> 
>> /* couple of pci config writes */
>> 
>> InterruptUnlock(&_intr_lock);
>> 
>> ----------------------------------------------------------------
>> 
>> I/O privileges have been obtained for this thread with:
>> 
>> ThreadCtl(_NTO_TCTL_IO, 0);
>> 
>> Can a Threads I/O privileges be lost at runtime? If so, what
>> can cause it?
>> Are there any other reasons for a SIGSEGV to be generated
>> during Interrupt Enable/Disable?
>> 
>> The code is running on a BCM1250 (MIPS) based H/W running ONX 6.3
>> 
>> Regards
>> Chaitanya
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 
>> OSTech
>> http://community.qnx.com/sf/go/post41202
>> 
>> 
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post41220
> 
> 
> 
> 
> _______________________________________________
> 
> OSTech
>...