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 = 00000000Aug 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/0x20Aug 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/0x70Aug 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:35Is 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:
smime.p7s
Description: S/MIME Cryptographic Signature
