strange problem with reiser4 with ccreg40 on amd64 2.6.35.2 vanilla kernel + tuxonice + reiser4 on a mdadm imsm raid-0 partition

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]

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

Hi,

First off: I am using reiser4 since YEARS now without the slightest
problem and I *LOVE* it! Except for deletes of large files on my SSD
drive it is VERY FAST and stable!

But now I think I might have found a bug:

If I compile javahelp on the reiser4 partition (mounted without any
special options), I get:

# du -h ./javahelp2-2.0.02_svn46/javahelp_nbproject/dist/lib/jsearch.jar
120K	./javahelp2-2.0.02_svn46/javahelp_nbproject/dist/lib/jsearch.jar
# ls -la ./javahelp2-2.0.02_svn46/javahelp_nbproject/dist/lib/jsearch.jar
-rw-r--r-- 1 portage portage      0 Aug 25 16:35
./javahelp2-2.0.02_svn46/javahelp_nbproject/dist/lib/jsearch.jar

I am not sure what the 0 usually refers to, but I think it should not be
0, right?
Because if I do the same thing on a ramdisk or on an ext4 partition:

# du -h ./javahelp2-2.0.02_svn46/javahelp_nbproject/dist/lib/jsearch.jar
128K	./javahelp2-2.0.02_svn46/javahelp_nbproject/dist/lib/jsearch.jar
# ls -la ./javahelp2-2.0.02_svn46/javahelp_nbproject/dist/lib
-rw-r--r-- 1 portage portage 121831 Aug 25 16:54
./javahelp2-2.0.02_svn46/javahelp_nbproject/dist/lib/jsearch.jar

How can I further investigate?
And/Or
What other informations would you need to further track down the problem?

Thanks for any advise!

Best,

Knuth


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

Re: strange problem with reiser4 with ccreg40 on amd64 2.6.35.2 vanilla kernel + tuxonice + reiser4 on a mdadm imsm raid-0 partition

[Edward Shishkin]

K. Posern wrote:
> Hi,
>   

Hello.

> First off: I am using reiser4 since YEARS now without the slightest
> problem and I *LOVE* it! Except for deletes of large files on my SSD
> drive it is VERY FAST and stable!
>
> But now I think I might have found a bug:
>
> If I compile javahelp on the reiser4 partition (mounted without any
> special options), I get:
>
> # du -h ./javahelp2-2.0.02_svn46/javahelp_nbproject/dist/lib/jsearch.jar
> 120K	./javahelp2-2.0.02_svn46/javahelp_nbproject/dist/lib/jsearch.jar
> # ls -la ./javahelp2-2.0.02_svn46/javahelp_nbproject/dist/lib/jsearch.jar
> -rw-r--r-- 1 portage portage      0 Aug 25 16:35
>   

Is it reproducible?
Any suspicious kernel messages being?
Also could you please fsck the partition (I wonder if there are any 
orphan things)

It might be because of this verrry ancient bug, which has been caught, 
but not yet fixed:
http://marc.info/?l=reiserfs-devel&m=127533196521722&w=2

Thanks for report,
Edward.

> ./javahelp2-2.0.02_svn46/javahelp_nbproject/dist/lib/jsearch.jar
>
> I am not sure what the 0 usually refers to, but I think it should not be
> 0, right?
> Because if I do the same thing on a ramdisk or on an ext4 partition:
>
> # du -h ./javahelp2-2.0.02_svn46/javahelp_nbproject/dist/lib/jsearch.jar
> 128K	./javahelp2-2.0.02_svn46/javahelp_nbproject/dist/lib/jsearch.jar
> # ls -la ./javahelp2-2.0.02_svn46/javahelp_nbproject/dist/lib
> -rw-r--r-- 1 portage portage 121831 Aug 25 16:54
> ./javahelp2-2.0.02_svn46/javahelp_nbproject/dist/lib/jsearch.jar
>
> How can I further investigate?
> And/Or
> What other informations would you need to further track down the problem?
>
> Thanks for any advise!
>
> Best,
>
> Knuth
>
>   

Re: 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]

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

Dear Mr. Shishkin,

"Good" news: It seems reproducible (even though the symptoms are 
different now ;)...

Please also note the question about my old notebook where I might have 
seen a similar kernel oops just this morning.

I can keep the machine in its exact current state for another 5-6 hours.
Then I need to reboot. The partition I can leave untouched for longer.
Please let me know if you need something from the machine in its current 
state and when I can (eventually) free the reiser4 partition.

Up-front 4 (major) things I recently changed:
	- This problem report is about gentoo on a new notebook
	- The partition is not a simple /dev/sda partition, but part of a 
RAID-0 intel "FakeRAID" that I access under linux with mdadm imsm.
	- The new installation uses 2.6.35.2 vanilla + tuxonice patch + reiser4 
patch
	  (see end of my mail about what I used on my 32-bit machine)
	- The new installation is amd64 gentoo (my old notebook runs 32-bit 686 
gentoo)

So here is what I did this morning:

(a) I formated the partition (I used yesterday, then formated to ext4 
yesterday) with reiser4 again:
	mkfs.reiser4 -o create=ccreg40 -L "/vola (reiser4)" /dev/md126p7

(b) I rsynced the content in the state of yesterday evening back with 
rsync -a

(c) I rebooted sanely

(d) It is mounted with:
/dev/md126p7    /mnt/vola       reiser4 
nodev,nosuid,noatime,exec,tmgr.atom_max_size=16000,tmgr.atom_max_age=36000,dont_load_bitmap 
0 0     # tmgr.atom_max_size=9000000

(e) I noticed that up until now I did not yet have my syslogd metalog 
(automatically) started --> I fixed this and started it

(f) I ran the gentoo command to reinstall (recompile) javahelp (like 
yesterday):
	emerge -qvt javahelp

(g) This time (unlike yesterday) it spit out kernel messages to the 
console (and into syslog, not into dmesg). The last line on the screen:
	[  220.742824] note: java[3141] exited with preempt_count 1
Here is the full syslog:
	http://tormen.pastebin.com/nNCFtNnp
Here is the dmesg (I guess not needed, but still):
	http://tormen.pastebin.com/DxXzpU1H
Here is my uname -a:
	Linux seven 2.6.35.3-nogo-pixel #9 SMP PREEMPT Mon Aug 23 19:42:14 EDT 
2010 x86_64 Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz GenuineIntel GNU/Linux
Here is the gentoo portage emerge logfile of the above emerge command:
	http://tormen.pastebin.com/ZXFxuQVU

(h) The console where I issued the emerge and saw the kernel oops got 
stuck, no CTRL+C works, even though other tty's are still working.
A "sync" I issued on another console got stuck too (ctrl-c does not work).

(i) I tried to access the directory (where gentoo unpacked and compiles) 
with zsh autocomplete. Here is how far I came before the console got 
stuck (on TAB) (CTRL-c does not work):
	cd /vola/tmp.portage/portage/dev-java/javahelp-2.0.02_p46
(in there is usually the "work" directory which contains the source code)
(/vola is a symlink pointing to /mnt/vola/sd)

As I mentioned:
The machine is still like this ... if I should try something...

//////////////////////////////////////////////////////////////////////

FINALLY...
I don't know if this is related or not, but I just looked in my 32-bit 
gentoo syslog and found this (containing the same reiser-4 line then my 
64-bit machine kernel oops from this morning):

Aug 26 10:34:08 [kernel] [565941.926011] BUG: unable to handle kernel 
NULL pointer dereference at 00000030
Aug 26 10:34:08 [kernel] [565941.926020] IP: [<c07d84c0>] 
_raw_spin_lock+0x10/0x20
Aug 26 10:34:08 [kernel] [565941.926050] *pde = 00000000
Aug 26 10:34:08 [kernel] [565941.926083] Modules linked in: vboxnetflt 
vboxdrv ehci_hcd uhci_hcd usbcore e1000e toshiba_acpi [last unloaded: 
iwlagn]
Aug 26 10:34:08 [kernel] [565941.926115]
Aug 26 10:34:08 [kernel] [565941.926137] Pid: 22234, comm: evince Not 
tainted 2.6.34.2-nogo-pixel #3 Portable PC/PORTEGE R500
Aug 26 10:34:08 [kernel] [565941.926142] EIP: 0060:[<c07d84c0>] EFLAGS: 
00010202 CPU: 0
Aug 26 10:34:08 [kernel] [565941.926147] EIP is at _raw_spin_lock+0x10/0x20
Aug 26 10:34:08 [kernel] [565941.926168] EAX: 00000030 EBX: 00000000 
ECX: 00000000 EDX: 00000100
Aug 26 10:34:08 [kernel] [565941.926172] ESI: c1bf71c0 EDI: c3b834f4 
EBP: f61cfdd4 ESP: f61cfd44
Aug 26 10:34:08 [kernel] [565941.926176]  DS: 007b ES: 007b FS: 00d8 GS: 
00e0 SS: 0068
Aug 26 10:34:08 [kernel] [565941.926203]  c033413a 00000000 00000246 
00000002 00000000 00000000 00000010 00000000
Aug 26 10:34:08 [kernel] [565941.926212] <0> 00000000 c1bf71c0 00000000 
f61cfdd4 c03360c3 00000000 00000000 f61cfdd4
Aug 26 10:34:08 [kernel] [565941.926240] <0> 00000001 c3b834f4 00000000 
c1bf71c0 f61cfe2c fffffff4 c0336268 000200da
Aug 26 10:34:08 [kernel] [565941.926275]  [<c033413a>] ? 
checkin_logical_cluster+0x1a/0x290
Aug 26 10:34:08 [kernel] [565941.926301]  [<c03360c3>] ? 
capture_page_cluster+0x53/0xf0
Aug 26 10:34:08 [kernel] [565941.926307]  [<c0336268>] ? 
write_end_cryptcompress+0x108/0x2b0
Aug 26 10:34:08 [kernel] [565941.926331]  [<c027f447>] ? 
__alloc_pages_nodemask+0xd7/0x580
Aug 26 10:34:08 [kernel] [565941.926338]  [<c033296e>] ? 
reiser4_write_end_careful+0xbe/0x190
Aug 26 10:34:08 [kernel] [565941.926363]  [<c0278767>] ? 
pagecache_write_end+0x57/0x70
Aug 26 10:34:08 [kernel] [565941.926369]  [<c02c3489>] ? 
__mark_inode_dirty+0x59/0x160
Aug 26 10:34:08 [kernel] [565941.926392]  [<c02c5e6a>] ? 
pipe_to_file+0x11a/0x140
Aug 26 10:34:08 [kernel] [565941.926397]  [<c02c3489>] ? 
__mark_inode_dirty+0x59/0x160
Aug 26 10:34:08 [kernel] [565941.926402]  [<c02c3489>] ? 
__mark_inode_dirty+0x59/0x160
Aug 26 10:34:08 [kernel] [565941.926430]  [<c02c5d50>] ? 
pipe_to_file+0x0/0x140
Aug 26 10:34:08 [kernel] [565941.926436]  [<c02c5c9b>] ? 
generic_file_splice_write+0xcb/0x180
Aug 26 10:34:08 [kernel] [565941.926460]  [<c02c5860>] ? 
spd_release_page+0x0/0x10
Aug 26 10:34:08 [kernel] [565941.926465]  [<c02c5bd0>] ? 
generic_file_splice_write+0x0/0x180
Aug 26 10:34:08 [kernel] [565941.926488]  [<c02c5179>] ? 
do_splice_from+0x69/0x90
Aug 26 10:34:08 [kernel] [565941.926494]  [<c02c55b6>] ? 
sys_splice+0x2a6/0x520
Aug 26 10:34:08 [kernel] [565941.926500]  [<c02ae080>] ? sys_pipe2+0x40/0x70
Aug 26 10:34:08 [kernel] [565941.926524]  [<c0202d17>] ? 
sysenter_do_call+0x12/0x26
Aug 26 10:34:08 [kernel] [565941.926530]  [<c07d0000>] ? 
cpu_init+0x2ef/0x341
Aug 26 10:34:08 [kernel] [565941.926689] ---[ end trace 8a3e6ebc317bfbfe 
]---
Aug 26 10:34:08 [kernel] [565941.926713] note: evince[22234] exited with 
preempt_count 1
Aug 26 10:34:14 [acpid] ACPI Battery Event: 100%

As mentioned I am using reiser4 since YEARS without *any* problems.
What I changed on my 32-bit machine:
	Beginning of August I updated from v2.6.31.3 to v2.6.33.5 and then to 
v2.6.34.2 (I was using 2.6.31.3 since december 2009 without problems).
The uname:
	Linux pixel 2.6.34.2-nogo-pixel #3 SMP PREEMPT Tue Aug 3 18:46:20 EDT 
2010 i686 Intel(R) Core(TM)2 CPU U7600 @ 1.20GHz GenuineIntel GNU/Linux

Don't know if this could be related?! (and if it this kernel oops seems 
to indicate an reiser4 implication at all ?!)	

Please let me know if you need anything.

Thanks,

Knuth

On 26/08/10 07:03, Edward Shishkin wrote:
> K. Posern wrote:
>> If I compile javahelp on the reiser4 partition (mounted without any
>> special options), I get:
>>
>> # du -h ./javahelp2-2.0.02_svn46/javahelp_nbproject/dist/lib/jsearch.jar
>> 120K ./javahelp2-2.0.02_svn46/javahelp_nbproject/dist/lib/jsearch.jar
>> # ls -la ./javahelp2-2.0.02_svn46/javahelp_nbproject/dist/lib/jsearch.jar
>> -rw-r--r-- 1 portage portage 0 Aug 25 16:35
>
> Is it reproducible?
> Any suspicious kernel messages being?
> Also could you please fsck the partition (I wonder if there are any
> orphan things)
>
> It might be because of this verrry ancient bug, which has been caught,
> but not yet fixed:
> http://marc.info/?l=reiserfs-devel&m=127533196521722&w=2
>
> Thanks for report,
> Edward.


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

Re: 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]

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

Hi,

I forgot to mention:
Right before sending the below mail:
I did do a fsck.reier4 --fix. It found some stuff, fixed it, told me
everything is fine now with the FS, thenn I tried again: same problem!

(I also double checked the FS permissions.)

dmesg did NOT show anything,
the build log did NOT show anything (turned on all debug available)
(and the emerge went actually through fine, just the file was 0 bytes ;)
-->
That's why it took me so long to figure out that it's actually my FS ;)

I have a emerge.log with the JAVA_PKG_DEBUG=1:
	http://tormen.pastebin.com/AEkDdQ1n
emerge --info:
	http://tormen.pastebin.com/EfZe3afK

About the reproducibility:
It was reproducible yesterday all day and night :)
...
Unfortunately I was tired and fed-up and wanted to move on --> I rsynced
the content, reformatted the partition with ext4... I will nevertheless
try to restore the the original setup ... again this evening. Sorry
about that. I should have waited at least for a response from you... :(

Best,

Knuth

On 26/08/10 04:07, Jonáš Vidra wrote:
> On Thu, 26 Aug 2010 03:00:47 +0200 K. Posern <quickhelp@gmail.com> wrote:
> 
>> Hi,
> 
> Hello!
> 
> 
>> How can I further investigate?
>> And/Or
>> What other informations would you need to further track down the problem?
> 
> Try running fsck.reiser4, that might help. Knowing your plugin profile
> would be good as well.
> 
> Is the bug reproducible? I can't reproduce it here, could you send me your
> emerge --info and build logs?
> 
> 
>>
>> Thanks for any advise!
>>
>> Best,
>>
>> Knuth
>>
> 
> 



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

Re: strange problem with reiser4 with ccreg40 on amd64 2.6.35.2 vanilla kernel + tuxonice + reiser4 on a mdadm imsm raid-0 partition

[Jonáš Vidra]

Dne Thu, 26 Aug 2010 14:51:09 +0200 K. Posern <quickhelp@gmail.com>  
napsal(a):

> I have a emerge.log with the JAVA_PKG_DEBUG=1:
> 	http://tormen.pastebin.com/AEkDdQ1n
> emerge --info:
> 	http://tormen.pastebin.com/EfZe3afK

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?

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.


-- 
Jonáš Vidra, vidra.jonas@seznam.cz
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 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]

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

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 --]

Re: strange problem with reiser4 with ccreg40 on amd64 2.6.35.2 vanilla kernel + tuxonice + reiser4 on a mdadm imsm raid-0 partition

[Jordan Patterson]

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
>
>
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 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]

[-- 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 --]

Re: strange problem with reiser4 with ccreg40 on amd64 2.6.35.2 vanilla kernel + tuxonice + reiser4 on a mdadm imsm raid-0 partition

[Nicolas Barbier]

2010/8/27 K. Posern <quickhelp@gmail.com>:

> 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.

It could trigger compiler bugs and trigger unintended behavior due to
unsafe (but possibly intentional) constructs in the compiled source
code. I don't know of any case where it could fail the build, although
such cases may exist.

For an example of how compiler optimizations can break the generated
code (which is probably totally unrelated to your specific problem),
see:

<URL:http://en.wikipedia.org/wiki/Aliasing_(computing)#Conflicts_with_optimization>

Nicolas
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html