|
Mario Charest
01/12/2009 4:51 PM
post19912
|
This is happening on a 8 cores system with 6.4.0 ( our first system with more then 4 cores and with 6.4.0 ).
The software is build on 6.3.2 and runs fine on a 6.3.2 machine, although only 8 cores.
According to the source it means channels vectors were not freed properly, that doesn't sound to good .
|
|
|
|
|
|
Colin Burgess(deleted)
|
Re: kerext_process line 351
|
|
Colin Burgess(deleted)
01/12/2009 5:10 PM
post19915
|
Re: kerext_process line 351
That sounds like you've been bitten by PR62479
"If you exec() something with a relative path, the proc_loader code now does a
pathmgr_node2fullpath() to get an absolute path for the aux vector AT_EXEFILE
entry. If qnet is running, that will cause a netmgr_nd2str() call which winds
up in __netmgr_send(). That function will open a connection to qnet to get the
node path, but leaves it open for future sends. Once we get to the point of
swapping the process data between the newly exec'd process and the parent, that
open connection will cause a crash() in kerext_process since that code is not
expecting the child to have any side channels aside from one to procnto."
The fixes are here...
http://community.qnx.com/integration/viewcvs/viewcvs.cgi?root=coreos_pub&rev=205108&system=exsy1001&view=rev
and
http://community.qnx.com/integration/viewcvs/viewcvs.cgi?root=coreos_pub&rev=206031&system=exsy1001&view=rev
Mario Charest wrote:
> This is happening on a 8 cores system with 6.4
.0 ( our first system with more then 4 cores and with 6.4.0 ).
>
> The software is build on 6.3.2 and runs fine on a 6.3.2 machine, although only 8 cores.
>
> According to the source it means channels vectors were not freed properly, that doesn't sound to good .
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post19912
>
--
cburgess@qnx.com
|
|
|
|
|
|
Mario Charest
|
RE: kerext_process line 351
|
|
Mario Charest
01/12/2009 5:19 PM
post19917
|
RE: kerext_process line 351
Ok,
I have no idea what do to from here, rebuild libc?
Guess I need to contact sales to obtain an official build with these patch, lol!
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: January-12-09 5:11 PM
> To: ostech-core_os
> Subject: Re: kerext_process line 351
>
> That sounds like you've been bitten by PR62479
>
> "If you exec() something with a relative path, the proc_loader code now
> does a
> pathmgr_node2fullpath() to get an absolute path for the aux vector
> AT_EXEFILE
> entry. If qnet is running, that will cause a netmgr_nd2str() call which
> winds
> up in __netmgr_send(). That function will open a connection to qnet to
> get the
> node path, but leaves it open for future sends. Once we get to the
> point of
> swapping the process data between the newly exec'd process and the
> parent, that
> open connection will cause a crash() in kerext_process since that code
> is not
> expecting the child to have any side channels aside from one to
> procnto."
>
> The fixes are here...
>
> http://community.qnx.com/integration/viewcvs/viewcvs.cgi?root=coreos_pu
> b&rev=205108&system=exsy1001&view=rev
> and
> http://community.qnx.com/integration/viewcvs/viewcvs.cgi?root=coreos_pu
> b&rev=206031&system=exsy1001&view=rev
>
> Mario Charest wrote:
> > This is happening on a 8 cores system with 6.4.0 ( our first system
> with more then 4 cores and with 6.4.0 ).
> >
> > The software is build on 6.3.2 and runs fine on a 6.3.2 machine,
> although only 8 cores.
> >
> > According to the source it means channels vectors were not freed
> properly, that doesn't sound to good .
> >
> > _______________________________________________
> > OSTech
> > http://community.qnx.com/sf/go/post19912
> >
>
> --
> cburgess@qnx.com
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post19915
>
|
|
|
|
|
|
Colin Burgess(deleted)
|
RE: kerext_process line 351
|
|
Colin Burgess(deleted)
01/12/2009 9:50 PM
post19927
|
RE: kerext_process line 351
I think the bug only affected spawns with a relative path - you could fully resolve it first.
Or plan b would be to get a patch produced.
Can you try the latest trunk kernel to verify that it solves your problem?
Colin
________________________________
From: Mario Charest [mailto:community-noreply@qnx.com]
Sent: Mon 1/12/2009 5:19 PM
To: ostech-core_os
Subject: RE: kerext_process line 351
Ok,
I have no idea what do to from here, rebuild libc?
Guess I need to contact sales to obtain an official build with these patch, lol!
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: January-12-09 5:11 PM
> To: ostech-core_os
> Subject: Re: kerext_process line 351
>
> That sounds like you've been bitten by PR62479
>
> "If you exec() something with a relative path, the proc_loader code now
> does a
> pathmgr_node2fullpath() to get an absolute path for the aux vector
> AT_EXEFILE
> entry. If qnet is running, that will cause a netmgr_nd2str() call which
> winds
> up in __netmgr_send(). That function will open a connection to qnet to
> get the
> node path, but leaves it open for future sends. Once we get to the
> point of
> swapping the process data between the newly exec'd process and the
> parent, that
> open connection will cause a crash() in kerext_process since that code
> is not
> expecting the child to have any side channels aside from one to
> procnto."
>
> The fixes are here...
>
> http://community.qnx.com/integration/viewcvs/viewcvs.cgi?root=coreos_pu
> b&rev=205108&system=exsy1001&view=rev
> and
> http://community.qnx.com/integration/viewcvs/viewcvs.cgi?root=coreos_pu
> b&rev=206031&system=exsy1001&view=rev
>
> Mario Charest wrote:
> > This is happening on a 8 cores system with 6.4.0 ( our first system
> with more then 4 cores and with 6.4.0 ).
> >
> > The software is build on 6.3.2 and runs fine on a 6.3.2 machine,
> although only 8 cores.
> >
> > According to the source it means channels vectors were not freed
> properly, that doesn't sound to good .
> >
> > _______________________________________________
> > OSTech
> > http://community.qnx.com/sf/go/post19912
> >
>
> --
> cburgess@qnx.com
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post19915
>
_______________________________________________
OSTech
http://community.qnx.com/sf/go/post19917
|
|
|
|
|
|
Mario Charest
|
RE: kerext_process line 351
|
|
Mario Charest
01/13/2009 9:57 AM
post19958
|
RE: kerext_process line 351
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: January-12-09 9:50 PM
> To: ostech-core_os
> Subject: RE: kerext_process line 351
>
> I think the bug only affected spawns with a relative path - you could
> fully resolve it first.
I assume that if a script does pterm <program>, pterm is spawning with a relative path?
>
> Or plan b would be to get a patch produced.
>
> Can you try the latest trunk kernel to verify that it solves your
> problem?
>
No binaries available, have to build it myself? Would be nice if a "daily build" of binaries would be available.
> Colin
>
> ________________________________
>
> From: Mario Charest [mailto:community-noreply@qnx.com]
> Sent: Mon 1/12/2009 5:19 PM
> To: ostech-core_os
> Subject: RE: kerext_process line 351
>
>
>
> Ok,
>
> I have no idea what do to from here, rebuild libc?
>
> Guess I need to contact sales to obtain an official build with these
> patch, lol!
>
>
> > -----Original Message-----
> > From: Colin Burgess [mailto:community-noreply@qnx.com]
> > Sent: January-12-09 5:11 PM
> > To: ostech-core_os
> > Subject: Re: kerext_process line 351
> >
> > That sounds like you've been bitten by PR62479
> >
> > "If you exec() something with a relative path, the proc_loader code
> > now does a
> > pathmgr_node2fullpath() to get an absolute path for the aux vector
> > AT_EXEFILE entry. If qnet is running, that will cause a
> > netmgr_nd2str() call which winds up in __netmgr_send(). That function
> > will open a connection to qnet to get the node path, but leaves it
> > open for future sends. Once we get to the point of swapping the
> > process data between the newly exec'd process and the parent, that
> > open connection will cause a crash() in kerext_process since that
> code
> > is not expecting the child to have any side channels aside from one
> to
> > procnto."
> >
> > The fixes are here...
> >
> >
> http://community.qnx.com/integration/viewcvs/viewcvs.cgi?root=coreos_p
> > u
> > b&rev=205108&system=exsy1001&view=rev
> > and
> >
> http://community.qnx.com/integration/viewcvs/viewcvs.cgi?root=coreos_p
> > u
> > b&rev=206031&system=exsy1001&view=rev
> >
> > Mario Charest wrote:
> > > This is happening on a 8 cores system with 6.4.0 ( our first system
> > with more then 4 cores and with 6.4.0 ).
> > >
> > > The software is build on 6.3.2 and runs fine on a 6.3.2 machine,
> > although only 8 cores.
> > >
> > > According to the source it means channels vectors were not freed
> > properly, that doesn't sound to good .
> > >
> > > _______________________________________________
> > > OSTech
> > > http://community.qnx.com/sf/go/post19912
> > >
> >
> > --
> > cburgess@qnx.com
> >
> > _______________________________________________
> > OSTech
> > http://community.qnx.com/sf/go/post19915
> >
>
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post19917
>
>
>
>
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post19927
|
|
|
|
|
|
Mario Charest
|
RE: kerext_process line 351
|
|
Mario Charest
01/15/2009 12:30 PM
post20140
|
RE: kerext_process line 351
I rebuild the last of trunk. Updated proc and libc.so.3 of my build tree but now I can`t spawn anything remotely.
I have two 6.4 machine, one is the development seat and the other one is the target. I do on -f /net/target sync and a
pidin on the target shows:
888842 1 (Loading ) 10r REPLY 118803@EA1659.comact.com
But from the target I can do a remote spawn no problem.
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: January-12-09 9:50 PM
> To: ostech-core_os
> Subject: RE: kerext_process line 351
>
> I think the bug only affected spawns with a relative path - you could
> fully resolve it first.
>
> Or plan b would be to get a patch produced.
>
> Can you try the latest trunk kernel to verify that it solves your
> problem?
>
> Colin
>
> ________________________________
>
> From: Mario Charest [mailto:community-noreply@qnx.com]
> Sent: Mon 1/12/2009 5:19 PM
> To: ostech-core_os
> Subject: RE: kerext_process line 351
>
>
>
> Ok,
>
> I have no idea what do to from here, rebuild libc?
>
> Guess I need to contact sales to obtain an official build with these
> patch, lol!
>
>
> > -----Original Message-----
> > From: Colin Burgess [mailto:community-noreply@qnx.com]
> > Sent: January-12-09 5:11 PM
> > To: ostech-core_os
> > Subject: Re: kerext_process line 351
> >
> > That sounds like you've been bitten by PR62479
> >
> > "If you exec() something with a relative path, the proc_loader code
> > now does a
> > pathmgr_node2fullpath() to get an absolute path for the aux vector
> > AT_EXEFILE entry. If qnet is running, that will cause a
> > netmgr_nd2str() call which winds up in __netmgr_send(). That function
> > will open a connection to qnet to get the node path, but leaves it
> > open for future sends. Once we get to the point of swapping the
> > process data between the newly exec'd process and the parent, that
> > open connection will cause a crash() in kerext_process since that
> code
> > is not expecting the child to have any side channels aside from one
> to
> > procnto."
> >
> > The fixes are here...
> >
> >
> http://community.qnx.com/integration/viewcvs/viewcvs.cgi?root=coreos_p
> > u
> > b&rev=205108&system=exsy1001&view=rev
> > and
> >
> http://community.qnx.com/integration/viewcvs/viewcvs.cgi?root=coreos_p
> > u
> > b&rev=206031&system=exsy1001&view=rev
> >
> > Mario Charest wrote:
> > > This is happening on a 8 cores system with 6.4.0 ( our first system
> > with more then 4 cores and with 6.4.0 ).
> > >
> > > The software is build on 6.3.2 and runs fine on a 6.3.2 machine,
> > although only 8 cores.
> > >
> > > According to the source it means channels vectors were not freed
> > properly, that doesn't sound to good .
> > >
> > > _______________________________________________
> > > OSTech
> > > http://community.qnx.com/sf/go/post19912
> > >
> >
> > --
> > cburgess@qnx.com
> >
> > _______________________________________________
> > OSTech
> > http://community.qnx.com/sf/go/post19915
> >
>
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post19917
>
>
>
>
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post19927
|
|
|
|
|
|
Colin Burgess(deleted)
|
Re: kerext_process line 351
|
|
Colin Burgess(deleted)
01/15/2009 12:42 PM
post20142
|
Re: kerext_process line 351
Which machine(s) did you update? Both?
Mario Charest wrote:
> I rebuild the last of trunk. Updated proc and libc.so.3 of my build tree but now I can`t spawn anything remotely.
>
> I have two 6.4 machine, one is the development seat and the other one is the target. I do on -f /net/target sync and
a pidin on the target shows:
>
> 888842 1 (Loading ) 10r REPLY 118803@EA1659.comact.com
>
> But from the target I can do a remote spawn no problem.
>
>> -----Original Message-----
>> From: Colin Burgess [mailto:community-noreply@qnx.com]
>> Sent: January-12-09 9:50 PM
>> To: ostech-core_os
>> Subject: RE: kerext_process line 351
>>
>> I think the bug only affected spawns with a relative path - you could
>> fully resolve it first.
>>
>> Or plan b would be to get a patch produced.
>>
>> Can you try the latest trunk kernel to verify that it solves your
>> problem?
>>
>> Colin
>>
>> ________________________________
>>
>> From: Mario Charest [mailto:community-noreply@qnx.com]
>> Sent: Mon 1/12/2009 5:19 PM
>> To: ostech-core_os
>> Subject: RE: kerext_process line 351
>>
>>
>>
>> Ok,
>>
>> I have no idea what do to from here, rebuild libc?
>>
>> Guess I need to contact sales to obtain an official build with these
>> patch, lol!
>>
>>
>>> -----Original Message-----
>>> From: Colin Burgess [mailto:community-noreply@qnx.com]
>>> Sent: January-12-09 5:11 PM
>>> To: ostech-core_os
>>> Subject: Re: kerext_process line 351
>>>
>>> That sounds like you've been bitten by PR62479
>>>
>>> "If you exec() something with a relative path, the proc_loader code
>>> now does a
>>> pathmgr_node2fullpath() to get an absolute path for the aux vector
>>> AT_EXEFILE entry. If qnet is running, that will cause a
>>> netmgr_nd2str() call which winds up in __netmgr_send(). That function
>>> will open a connection to qnet to get the node path, but leaves it
>>> open for future sends. Once we get to the point of swapping the
>>> process data between the newly exec'd process and the parent, that
>>> open connection will cause a crash() in kerext_process since that
>> code
>>> is not expecting the child to have any side channels aside from one
>> to
>>> procnto."
>>>
>>> The fixes are here...
>>>
>>>
>> http://community.qnx.com/integration/viewcvs/viewcvs.cgi?root=coreos_p
>>> u
>>> b&rev=205108&system=exsy1001&view=rev
>>> and
>>>
>> http://community.qnx.com/integration/viewcvs/viewcvs.cgi?root=coreos_p
>>> u
>>> b&rev=206031&system=exsy1001&view=rev
>>>
>>> Mario Charest wrote:
>>>> This is happening on a 8 cores system with 6.4.0 ( our first system
>>> with more then 4 cores and with 6.4.0 ).
>>>> The software is build on 6.3.2 and runs fine on a 6.3.2 machine,
>>> although only 8 cores.
>>>> According to the source it means channels vectors were not freed
>>> properly, that doesn't sound to good .
>>>> _______________________________________________
>>>> OSTech
>>>> http://community.qnx.com/sf/go/post19912
>>>>
>>> --
>>> cburgess@qnx.com
>>>
>>> _______________________________________________
>>> OSTech
>>> http://community.qnx.com/sf/go/post19915
>>>
>>
>> _______________________________________________
>> OSTech
>>...
|
|
|
|
|
|
Mario Charest
|
RE: kerext_process line 351
|
|
Mario Charest
01/15/2009 1:00 PM
post20148
|
RE: kerext_process line 351
The target. I'll create a second target and spawn from there onto the first. ( I don't want to touch the dev machine)
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: January-15-09 12:43 PM
> To: ostech-core_os
> Subject: Re: kerext_process line 351
>
> Which machine(s) did you update? Both?
>
> Mario Charest wrote:
> > I rebuild the last of trunk. Updated proc and libc.so.3 of my build
> tree but now I can`t spawn anything remotely.
> >
> > I have two 6.4 machine, one is the development seat and the other one
> is the target. I do on -f /net/target sync and a pidin on the target
> shows:
> >
> > 888842 1 (Loading ) 10r REPLY 118803@EA1659.comact.com
> >
> > But from the target I can do a remote spawn no problem.
> >
> >> -----Original Message-----
> >> From: Colin Burgess [mailto:community-noreply@qnx.com]
> >> Sent: January-12-09 9:50 PM
> >> To: ostech-core_os
> >> Subject: RE: kerext_process line 351
> >>
> >> I think the bug only affected spawns with a relative path - you
> could
> >> fully resolve it first.
> >>
> >> Or plan b would be to get a patch produced.
> >>
> >> Can you try the latest trunk kernel to verify that it solves your
> >> problem?
> >>
> >> Colin
> >>
> >> ________________________________
> >>
> >> From: Mario Charest [mailto:community-noreply@qnx.com]
> >> Sent: Mon 1/12/2009 5:19 PM
> >> To: ostech-core_os
> >> Subject: RE: kerext_process line 351
> >>
> >>
> >>
> >> Ok,
> >>
> >> I have no idea what do to from here, rebuild libc?
> >>
> >> Guess I need to contact sales to obtain an official build with these
> >> patch, lol!
> >>
> >>
> >>> -----Original Message-----
> >>> From: Colin Burgess [mailto:community-noreply@qnx.com]
> >>> Sent: January-12-09 5:11 PM
> >>> To: ostech-core_os
> >>> Subject: Re: kerext_process line 351
> >>>
> >>> That sounds like you've been bitten by PR62479
> >>>
> >>> "If you exec() something with a relative path, the proc_loader code
> >>> now does a
> >>> pathmgr_node2fullpath() to get an absolute path for the aux vector
> >>> AT_EXEFILE entry. If qnet is running, that will cause a
> >>> netmgr_nd2str() call which winds up in __netmgr_send(). That
> function
> >>> will open a connection to qnet to get the node path, but leaves it
> >>> open for future sends. Once we get to the point of swapping the
> >>> process data between the newly exec'd process and the parent, that
> >>> open connection will cause a crash() in kerext_process since that
> >> code
> >>> is not expecting the child to have any side channels aside from one
> >> to
> >>> procnto."
> >>>
> >>> The fixes are here...
> >>>
> >>>
> >>
> http://community.qnx.com/integration/viewcvs/viewcvs.cgi?root=coreos_p
> >>> u
> >>> b&rev=205108&system=exsy1001&view=rev
> >>> and
> >>>
> >>
> http://community.qnx.com/integration/viewcvs/viewcvs.cgi?root=coreos_p
> >>> u
> >>> b&rev=206031&system=exsy1001&view=rev
> >>>
> >>> Mario Charest wrote:
> >>>> This is happening on a 8 cores system with 6.4.0 ( our first
> system
> >>> with more then 4 cores and...
View Full Message
|
|
|
|
|
|
Mario Charest
|
RE: kerext_process line 351
|
|
Mario Charest
01/15/2009 1:19 PM
post20152
|
RE: kerext_process line 351
Seems to be working from two updates machines, does that mean 6.4.1 and 6.4.0 won't be compatible?
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: January-15-09 12:43 PM
> To: ostech-core_os
> Subject: Re: kerext_process line 351
>
> Which machine(s) did you update? Both?
>
> Mario Charest wrote:
> > I rebuild the last of trunk. Updated proc and libc.so.3 of my build
> tree but now I can`t spawn anything remotely.
> >
> > I have two 6.4 machine, one is the development seat and the other one
> is the target. I do on -f /net/target sync and a pidin on the target
> shows:
> >
> > 888842 1 (Loading ) 10r REPLY 118803@EA1659.comact.com
> >
> > But from the target I can do a remote spawn no problem.
> >
> >> -----Original Message-----
> >> From: Colin Burgess [mailto:community-noreply@qnx.com]
> >> Sent: January-12-09 9:50 PM
> >> To: ostech-core_os
> >> Subject: RE: kerext_process line 351
> >>
> >> I think the bug only affected spawns with a relative path - you
> could
> >> fully resolve it first.
> >>
> >> Or plan b would be to get a patch produced.
> >>
> >> Can you try the latest trunk kernel to verify that it solves your
> >> problem?
> >>
> >> Colin
> >>
> >> ________________________________
> >>
> >> From: Mario Charest [mailto:community-noreply@qnx.com]
> >> Sent: Mon 1/12/2009 5:19 PM
> >> To: ostech-core_os
> >> Subject: RE: kerext_process line 351
> >>
> >>
> >>
> >> Ok,
> >>
> >> I have no idea what do to from here, rebuild libc?
> >>
> >> Guess I need to contact sales to obtain an official build with these
> >> patch, lol!
> >>
> >>
> >>> -----Original Message-----
> >>> From: Colin Burgess [mailto:community-noreply@qnx.com]
> >>> Sent: January-12-09 5:11 PM
> >>> To: ostech-core_os
> >>> Subject: Re: kerext_process line 351
> >>>
> >>> That sounds like you've been bitten by PR62479
> >>>
> >>> "If you exec() something with a relative path, the proc_loader code
> >>> now does a
> >>> pathmgr_node2fullpath() to get an absolute path for the aux vector
> >>> AT_EXEFILE entry. If qnet is running, that will cause a
> >>> netmgr_nd2str() call which winds up in __netmgr_send(). That
> function
> >>> will open a connection to qnet to get the node path, but leaves it
> >>> open for future sends. Once we get to the point of swapping the
> >>> process data between the newly exec'd process and the parent, that
> >>> open connection will cause a crash() in kerext_process since that
> >> code
> >>> is not expecting the child to have any side channels aside from one
> >> to
> >>> procnto."
> >>>
> >>> The fixes are here...
> >>>
> >>>
> >>
> http://community.qnx.com/integration/viewcvs/viewcvs.cgi?root=coreos_p
> >>> u
> >>> b&rev=205108&system=exsy1001&view=rev
> >>> and
> >>>
> >>
> http://community.qnx.com/integration/viewcvs/viewcvs.cgi?root=coreos_p
> >>> u
> >>> b&rev=206031&system=exsy1001&view=rev
> >>>
> >>> Mario Charest wrote:
> >>>> This is happening on a 8 cores system with 6.4.0 ( our first
> system
> >>> with more then 4 cores and with 6.4.0 ).
>...
View Full Message
|
|
|
|
|
|
Colin Burgess(deleted)
|
Re: kerext_process line 351
|
|
Colin Burgess(deleted)
01/15/2009 1:24 PM
post20153
|
Re: kerext_process line 351
It wasn't intended. I'll raise a PR to track this one.
Colin
Mario Charest wrote:
> Seems to be working from two updates machines, does that mean 6.4.1 and 6.4.0 won't be compatible?
>
>> -----Original Message-----
>> From: Colin Burgess [mailto:community-noreply@qnx.com]
>> Sent: January-15-09 12:43 PM
>> To: ostech-core_os
>> Subject: Re: kerext_process line 351
>>
>> Which machine(s) did you update? Both?
>>
>> Mario Charest wrote:
>>> I rebuild the last of trunk. Updated proc and libc.so.3 of my build
>> tree but now I can`t spawn anything remotely.
>>> I have two 6.4 machine, one is the development seat and the other one
>> is the target. I do on -f /net/target sync and a pidin on the target
>> shows:
>>> 888842 1 (Loading ) 10r REPLY 118803@EA1659.comact.com
>>>
>>> But from the target I can do a remote spawn no problem.
>>>
>>>> -----Original Message-----
>>>> From: Colin Burgess [mailto:community-noreply@qnx.com]
>>>> Sent: January-12-09 9:50 PM
>>>> To: ostech-core_os
>>>> Subject: RE: kerext_process line 351
>>>>
>>>> I think the bug only affected spawns with a relative path - you
>> could
>>>> fully resolve it first.
>>>>
>>>> Or plan b would be to get a patch produced.
>>>>
>>>> Can you try the latest trunk kernel to verify that it solves your
>>>> problem?
>>>>
>>>> Colin
>>>>
>>>> ________________________________
>>>>
>>>> From: Mario Charest [mailto:community-noreply@qnx.com]
>>>> Sent: Mon 1/12/2009 5:19 PM
>>>> To: ostech-core_os
>>>> Subject: RE: kerext_process line 351
>>>>
>>>>
>>>>
>>>> Ok,
>>>>
>>>> I have no idea what do to from here, rebuild libc?
>>>>
>>>> Guess I need to contact sales to obtain an official build with these
>>>> patch, lol!
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Colin Burgess [mailto:community-noreply@qnx.com]
>>>>> Sent: January-12-09 5:11 PM
>>>>> To: ostech-core_os
>>>>> Subject: Re: kerext_process line 351
>>>>>
>>>>> That sounds like you've been bitten by PR62479
>>>>>
>>>>> "If you exec() something with a relative path, the proc_loader code
>>>>> now does a
>>>>> pathmgr_node2fullpath() to get an absolute path for the aux vector
>>>>> AT_EXEFILE entry. If qnet is running, that will cause a
>>>>> netmgr_nd2str() call which winds up in __netmgr_send(). That
>> function
>>>>> will open a connection to qnet to get the node path, but leaves it
>>>>> open for future sends. Once we get to the point of swapping the
>>>>> process data between the newly exec'd process and the parent, that
>>>>> open connection will cause a crash() in kerext_process since that
>>>> code
>>>>> is not expecting the child to have any side channels aside from one
>>>> to
>>>>> procnto."
>>>>>
>>>>> The fixes are here...
>>>>>
>>>>>
>> http://community.qnx.com/integration/viewcvs/viewcvs.cgi?root=coreos_p
>>>>> u
>>>>> b&rev=205108&system=exsy1001&view=rev
>>>>> and
>>>>>
>>...
View Full Message
|
|
|
|
|
|
Mario Charest
|
RE: kerext_process line 351
|
|
Mario Charest
01/15/2009 1:26 PM
post20154
|
RE: kerext_process line 351
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: January-15-09 1:24 PM
> To: ostech-core_os
> Subject: Re: kerext_process line 351
>
> It wasn't intended. I'll raise a PR to track this one.
Phew!!! Will probably open a tick with support because this halting deployement of our product which desperately need
support for more then 4G memory. Can you please post the PR number so I can make a reference to in.
>
> Colin
>
> Mario Charest wrote:
> > Seems to be working from two updates machines, does that mean 6.4.1
> and 6.4.0 won't be compatible?
|
|
|
|
|
|
Colin Burgess(deleted)
|
Re: kerext_process line 351
|
|
Colin Burgess(deleted)
01/15/2009 1:44 PM
post20158
|
Re: kerext_process line 351
I just tried a 640 vm image, then cloned it and built a new image with a trunk procnto-smp-instr and libc.so.3
on the trunk machine I did
on -f /net/colinsvmware640 uname -a
on the 640 machine I did
on -f /net/clone_640 uname -a
and they both worked. sync also worked.
Can you try my kernel/libc combo on your target?
Colin
Mario Charest wrote:
>
>> -----Original Message-----
>> From: Colin Burgess [mailto:community-noreply@qnx.com]
>> Sent: January-15-09 1:24 PM
>> To: ostech-core_os
>> Subject: Re: kerext_process line 351
>>
>> It wasn't intended. I'll raise a PR to track this one.
>
> Phew!!! Will probably open a tick with support because this halting deployement of our product which desperately need
support for more then 4G memory. Can you please post the PR number so I can make a reference to in.
>
>> Colin
>>
>> Mario Charest wrote:
>>> Seems to be working from two updates machines, does that mean 6.4.1
>> and 6.4.0 won't be compatible?
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post20154
>
--
cburgess@qnx.com
|
|
|
|
|
|
Mario Charest
|
RE: kerext_process line 351
|
|
Mario Charest
01/15/2009 2:24 PM
post20161
|
RE: kerext_process line 351
Wow, this is strange. I get the same behaviour with your kernel/libc, but doing more tests I've found the problem seems
to come from my development seat, which lives under VMWare, as do the targets.
It seems the problem is only doing a on -f from my 6.4.0 dev set onto a 6.4.0 target with the new stuff. Any other
combination ( 6.3.2 included ) works fine.
Unfortunately I don't have a second 6.4.0 dev seat to test with.
As far as I can remember my devseat is 6.4.0 (not a beta), uname -a says 2008/10/21.
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: January-15-09 1:45 PM
> To: ostech-core_os
> Subject: Re: kerext_process line 351
>
> I just tried a 640 vm image, then cloned it and built a new image with
> a trunk procnto-smp-instr and libc.so.3
>
> on the trunk machine I did
>
> on -f /net/colinsvmware640 uname -a
>
> on the 640 machine I did
>
> on -f /net/clone_640 uname -a
>
> and they both worked. sync also worked.
>
> Can you try my kernel/libc combo on your target?
>
> Colin
>
> Mario Charest wrote:
> >
> >> -----Original Message-----
> >> From: Colin Burgess [mailto:community-noreply@qnx.com]
> >> Sent: January-15-09 1:24 PM
> >> To: ostech-core_os
> >> Subject: Re: kerext_process line 351
> >>
> >> It wasn't intended. I'll raise a PR to track this one.
> >
> > Phew!!! Will probably open a tick with support because this halting
> deployement of our product which desperately need support for more then
> 4G memory. Can you please post the PR number so I can make a reference
> to in.
> >
> >> Colin
> >>
> >> Mario Charest wrote:
> >>> Seems to be working from two updates machines, does that mean 6.4.1
> >> and 6.4.0 won't be compatible?
> >
> > _______________________________________________
> > OSTech
> > http://community.qnx.com/sf/go/post20154
> >
>
> --
> cburgess@qnx.com
>
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post20158
|
|
|
|
|
|
Sean Boudreau(deleted)
|
Re: kerext_process line 351
|
|
Sean Boudreau(deleted)
01/15/2009 2:28 PM
post20162
|
Re: kerext_process line 351
On Thu, Jan 15, 2009 at 02:24:54PM -0500, Mario Charest wrote:
> Wow, this is strange. I get the same behaviour with your kernel/libc, but doing more tests I've found the problem
seems to come from my development seat, which lives under VMWare, as do the targets.
>
> It seems the problem is only doing a on -f from my 6.4.0 dev set onto a 6.4.0 target with the new stuff. Any other
combination ( 6.3.2 included ) works fine.
>
> Unfortunately I don't have a second 6.4.0 dev seat to test with.
>
> As far as I can remember my devseat is 6.4.0 (not a beta), uname -a says 2008/10/21.
>
The QNET is the same across attempts?
-seanb
|
|
|
|
|
|
Mario Charest
|
RE: kerext_process line 351
|
|
Mario Charest
01/15/2009 2:44 PM
post20165
|
RE: kerext_process line 351
> -----Original Message-----
> From: Sean Boudreau [mailto:community-noreply@qnx.com]
> Sent: January-15-09 2:29 PM
> To: ostech-core_os
> Subject: Re: kerext_process line 351
>
> On Thu, Jan 15, 2009 at 02:24:54PM -0500, Mario Charest wrote:
> > Wow, this is strange. I get the same behaviour with your kernel/libc,
> but doing more tests I've found the problem seems to come from my
> development seat, which lives under VMWare, as do the targets.
> >
> > It seems the problem is only doing a on -f from my 6.4.0 dev set onto
> a 6.4.0 target with the new stuff. Any other combination ( 6.3.2
> included ) works fine.
> >
> > Unfortunately I don't have a second 6.4.0 dev seat to test with.
> >
> > As far as I can remember my devseat is 6.4.0 (not a beta), uname -a
> says 2008/10/21.
> >
>
> The QNET is the same across attempts?
I don't know of any way to check for version of a running program. use -i io-pkt-v4 and lsm-qnet.so shows the same
output on target and dev machines.
>
> -seanb
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post20162
>
|
|
|
|
|
|
Mario Charest
|
RE: kerext_process line 351
|
|
Mario Charest
01/15/2009 3:24 PM
post20168
|
RE: kerext_process line 351
At least this solves the original problem. Kernel isn't crashing anymore.
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: January-15-09 1:45 PM
> To: ostech-core_os
> Subject: Re: kerext_process line 351
>
> I just tried a 640 vm image, then cloned it and built a new image with
> a trunk procnto-smp-instr and libc.so.3
>
> on the trunk machine I did
>
> on -f /net/colinsvmware640 uname -a
>
> on the 640 machine I did
>
> on -f /net/clone_640 uname -a
>
> and they both worked. sync also worked.
>
> Can you try my kernel/libc combo on your target?
>
> Colin
>
> Mario Charest wrote:
> >
> >> -----Original Message-----
> >> From: Colin Burgess [mailto:community-noreply@qnx.com]
> >> Sent: January-15-09 1:24 PM
> >> To: ostech-core_os
> >> Subject: Re: kerext_process line 351
> >>
> >> It wasn't intended. I'll raise a PR to track this one.
> >
> > Phew!!! Will probably open a tick with support because this halting
> deployement of our product which desperately need support for more then
> 4G memory. Can you please post the PR number so I can make a reference
> to in.
> >
> >> Colin
> >>
> >> Mario Charest wrote:
> >>> Seems to be working from two updates machines, does that mean 6.4.1
> >> and 6.4.0 won't be compatible?
> >
> > _______________________________________________
> > OSTech
> > http://community.qnx.com/sf/go/post20154
> >
>
> --
> cburgess@qnx.com
>
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post20158
|
|
|
|
|
|
Mario Charest
|
Re: kerext_process line 351
|
|
Mario Charest
01/29/2009 12:16 PM
post21011
|
Re: kerext_process line 351
Go so weird stuff going on. From 6.3.2 I do a pidin -n /net/controller which is running 6.4.0 plus the kernel and lib.
so.2. it's now showing all the processes. But if I do pidin -n /net/controller/ ( extra / ) then it seems to show every
process.
|
|
|
|
|
|
Colin Burgess(deleted)
|
Re: kerext_process line 351
|
|
Colin Burgess(deleted)
01/29/2009 12:56 PM
post21014
|
Re: kerext_process line 351
Uh - all processes vs ever process?
Mario Charest wrote:
> Go so weird stuff going on. From 6.3.2 I do a pidin -n /net/controller which is running 6.4.0 plus the kernel and lib
.so.2. it's now showing all the processes. But if I do pidin -n /net/controller/ ( extra / ) then it seems to show
every process.
>
>
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post21011
>
--
cburgess@qnx.com
|
|
|
|
|
|
Mario Charest
|
RE: kerext_process line 351
|
|
Mario Charest
01/29/2009 12:57 PM
post21015
|
RE: kerext_process line 351
"it's now showing all the processes" should read
it's *not* showing all the processes
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: January-29-09 12:57 PM
> To: ostech-core_os
> Subject: Re: kerext_process line 351
>
> Uh - all processes vs ever process?
>
> Mario Charest wrote:
> > Go so weird stuff going on. From 6.3.2 I do a pidin -n
> /net/controller which is running 6.4.0 plus the kernel and lib.so.2.
> it's now showing all the processes. But if I do pidin -n
> /net/controller/ ( extra / ) then it seems to show every process.
> >
> >
> >
> > _______________________________________________
> > OSTech
> > http://community.qnx.com/sf/go/post21011
> >
>
> --
> cburgess@qnx.com
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post21014
>
|
|
|
|
|
|
