[PATCH 1/5] Fix spurious segmentation faults

Sebastien Jan s-jan at ti.com
Tue Jul 6 08:52:09 UTC 2010


On 07/03/2010 07:15 AM, Nicolas Pitre wrote:
> On Fri, 2 Jul 2010, Sebastien Jan wrote:
> 
>> This commit (f22c4b02) appears in the kernel-ubuntu tree (in the for-ubuntu-2.6.34 branch for example) (and comes from our kernel-omap4 tree, both on dev.omapzoom.org).
>> See this link: http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=commit;h=f22c4b0221b283f05a648d35f19facf80d8a0b23
>>
>>>> But there have been some updates to this patch series, which the current patch aims to cover, as it fixes some very ugly side effects.
>>>>
>>>
>>> Yeah, I think this patch will be helpful, but we need some testing. Do we have
>>> launchpad bug tracker of this bug? Ogra and Lee, are you guys aware of this bug?
>>> I am not playing with the Maverick rootfs.
>>>
>>>> Regarding patch author: I specified Rob as he did the investigations on the segfault we had, and find out the missing parts. We may have to credit Catalin instead/additionaly.
>>>
>>> Rob, thanks for fixing this. But we need know more information about the
>>> original patches and the status of this patch? Will this patch in mainline or in
>>> the OMAP4 upstream queue? That will be much easier for us to review.
>>
>> The 1st version of this patch series has been integrated into our omap4 tree (see above commit information).
>> Since then, new versions of this series are being discussed on the ARM ML [1]. From what I can read, it seems to be a proposal for the 2.6.36 merge window.
>>
>> Rob's patch contains a part of the new patch series, which fixes a memory related issue (which used to cause the segfaults when using git v1.7.0 for example).
>> Without this patch, I also used to see segfaults when using dpkg or gcc, making my maverick FS impossible to use for intensive build tasks.
>> With this patch, I was able to build the latest kernel image on my omap4 board.
> 
> How different is this patch from Catalin's latest?
> 
> Did you test with the latest from Catalin?  If not, then why not?
> 
> It would really be a good idea to test the latest patch instead of 
> trying to fix an older incarnation.  Even more so if the latest still 
> exhibits problems.  And in that case it would be really important to 
> disclose those segmentation fault problems on the ARM mailing list in 
> order to have the original fixed.

I fully agree. I have prepared an updated patch to upgrade to latest from Catalin's (v4).
I did not have segfaults with this new version either.

I will send it for review very soon.




More information about the kernel-team mailing list