reiserfs-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "K. Posern" <quickhelp@gmail.com>
To: Jordan Patterson <jordanp@gmail.com>
Cc: ReiserFS mailing list <reiserfs-devel@vger.kernel.org>
Subject: Re: strange problem with reiser4 with ccreg40 on amd64 2.6.35.2 vanilla kernel + tuxonice + reiser4 on a mdadm imsm raid-0 partition
Date: Thu, 26 Aug 2010 22:58:31 -0400	[thread overview]
Message-ID: <4C7729D7.3050004@gmail.com> (raw)
In-Reply-To: <AANLkTi=EjdZO26VKB7HBdS=Qup1DAorPmJOZEohmhCwq@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3798 bytes --]

Thanks for the report non-the-less :)

P.S.: ... I just hope you don't use btrfs (did you read the assessment 
of Edward Shishkin)?

On 26/08/10 19:58, Jordan Patterson wrote:
> Hi:
>
> I have a 64-bit Gentoo install, and I would get the same kernel bug
> when trying to emerge some java applications, such as ant-base.  This
> happened with the 2.6.35 and 2.6.34 kernels.
>
> I was using ccreg40 with lzo compression.
>
> My CFLAGS are "-march=core2 -O2 -pipe", which shouldn't have been a
> problem.  I'm not using reiser4 any more, so I can only confirm this
> bug.
>
> Jordan
>
> On Thu, Aug 26, 2010 at 5:45 PM, K. Posern<quickhelp@gmail.com>  wrote:
>> Hi,
>>
>> On 26/08/10 15:20, Jonáš Vidra wrote:
>>>
>>> Could you, please, recompile both the kernel and reiser4progs
>>> (and possibly their dependencies :D) with -O2 instead of -O3
>>> in CFLAGS? It tends to break things in strange and nasty ways,
>>> why do you have it enabled globally like this? Are you sure
>>> it's actually needed?
>>
>> I had read around and found comments that it can actually make things faster
>> and so I decided to give it a try.
>> You said "break things in strange and nasty ways":
>> Does this mean it can compile well and then just not WORK right (like for
>> example: mkfs.reiser4 doing the wrong things when formatting)??
>> I only heard that it can break the compilation, no? And for me everything
>> compiled fine.
>>
>> The difference between -O2 and -O3 are these 6 options:
>>>    -fgcse-after-reload                         [enabled]
>>>    -finline-functions                          [enabled]
>>>    -fipa-cp-clone                              [enabled]
>>>    -fpredictive-commoning                      [enabled]
>>>    -ftree-vectorize                            [enabled]
>>>    -funswitch-loops                            [enabled]
>>
>> Can you maybe comment on them?
>>
>> ... Because I could also use O2 and turn on some of them...
>> I was told: -ftree-vectorize and -funswitch-loops should be good and maybe
>> -fpredictive-commoning?!
>>
>>> Also, CCache is not used anymore, remove it from FEATURES.
>>> If you actually _use_ CCache (i.e. you've installed it
>>> manually), unmerge it immediately. It's broken by design.
>>>
>>> Other stuff in your FEATURES looks fishy as well, but it
>>> shouldn't affect builds. I hope you know what you're doing.
>>
>> Thanks! I used your comment to review my features again :)
>> ... and I disabled CCACHE.
>>
>> If you don't mind: Now I am interested in your feedback about the other
>> features:
>>
>> These should be 100% secure, right:
>>         buildsyspkg -- secure I guess ;) ... and I like it in case something
>> f's up big-scale in portage and I start emerging ;) ... happened once to a
>> friend of mine ... just try to use portage when python is broken ;)
>>         collision-protect -- useful I find
>>         parallel-fetch -- faster downloads who doen't want that
>>         metadata-transfer -- necessary for sqlite with portage (afaik)
>>         noauto -- convenient
>>         noinfo -- I just don't use "info"
>>
>> SECURITY - Drop-Priviledges
>> -->  should if things compile also be fine, right?
>>         userpriv usersandbox userfetch usersync
>>
>> SECURITY - MISC:
>> -->  These I like for some additional (security) checking:
>> (I guess about them and the File-Permissions I am the most interested in
>> your opinion)
>>         sandbox - seems also useful to me, no?
>>         strict - seems like a good thing from the description
>>
>> SECURITY - File-Permissions
>> <<<  they might be scetchy, right?... but should not do /harm/
>>         sfperms
>>         suidctl
>>
>> Thanks a lot!
>>
>> Knuth
>>
>>



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3644 bytes --]

  reply	other threads:[~2010-08-27  2:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-26  1:00 strange problem with reiser4 with ccreg40 on amd64 2.6.35.2 vanilla kernel + tuxonice + reiser4 on a mdadm imsm raid-0 partition K. Posern
2010-08-26 11:03 ` Edward Shishkin
2010-08-26 16:26   ` K. Posern
     [not found] ` <op.vh1ct9tghogzsi@g17b>
2010-08-26 12:51   ` K. Posern
2010-08-26 19:20     ` Jonáš Vidra
2010-08-26 23:45       ` K. Posern
2010-08-26 23:58         ` Jordan Patterson
2010-08-27  2:58           ` K. Posern [this message]
2010-08-27  7:30         ` Nicolas Barbier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C7729D7.3050004@gmail.com \
    --to=quickhelp@gmail.com \
    --cc=jordanp@gmail.com \
    --cc=reiserfs-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).