Yuan Yijun (bbbush) wrote,
Yuan Yijun
bbbush

头一次用桌面搜索工具,被害了

用的是 Google Desktop for Linux
开始觉得蛮酷的,ctrl-ctrl 比自带的桌面工具栏考虑得要方便。其他地方也很完善,包括安装程序,运行等等,毕竟是在 windows 版做了那么久之后。

装上之后发现最好关掉 BOINC/Seti@HOME 然后慢慢等着它做完索引。

到今天,重启了好几次了,它已经做了 76k 文件的索引,然而刚启动时还是会提示 0.1% 完成,剩余约 5.8 小时闲置时间,和初次运行时一样。

索引的内容好像是按类型有不同的优先级。媒体文件的优先级很低,很少排到处理,从更新项目的时间可以看到,也许是因为处理起来比较耗资源。Gmail 的优先级满高的,大概是因为网络资源不易得,我的邮件已经处理了 17k 了,然而还没有处理完。普通的文件优先级很高,这是使用中的感受。

就说这使用中。昨天晚上用 vim 写程序,一小段 python 程序大约是 50 行,要设置参数,参数写死在文件里了,于是存一次运行一次。结果,出现了好多次找不到文件的情况,都存了好几秒了,文件才可以运行。

[yuan@mstar workspace]$ python pvpa.py 
python: can't open file 'pvpa.py': [Errno 2] No such file or directory


最后,在某次存盘时,系统重启了。这也是头一次呢!正常运行的系统,通风良好,怎么会过热的。说是过热,又像是内核ACPI的问题,因为在某次运行时,有段内核消息(都打到 gnome-terminal 里面了),说什么未知的电源管理模式 - - 也许内核已经糊涂了吧。


Jul  1 00:46:38 mstar kernel: 
Jul  1 00:46:39 mstar kernel: =======================================================
Jul  1 00:46:40 mstar kernel: [ INFO: possible circular locking dependency detected ]
Jul  1 00:46:40 mstar kernel: 2.6.21-1.3240.fc8 #1
Jul  1 00:46:41 mstar kernel: -------------------------------------------------------
Jul  1 00:46:41 mstar kernel: gdl_fs_crawler/3078 is trying to acquire lock:
Jul  1 00:46:42 mstar kernel:  (&mm->mmap_sem){----}, at: [] do_page_fault+0x177/0x504
Jul  1 00:46:42 mstar kernel: 
Jul  1 00:46:43 mstar kernel: but task is already holding lock:
Jul  1 00:46:45 mstar kernel:  (&dev->ev_mutex){--..}, at: [] mutex_lock+0x21/0x24
Jul  1 00:46:48 mstar kernel: 
Jul  1 00:46:50 mstar kernel: which lock already depends on the new lock.
Jul  1 00:46:52 mstar kernel: 
Jul  1 00:46:54 mstar kernel: 
Jul  1 00:46:54 mstar kernel: the existing dependency chain (in reverse order) is:
Jul  1 00:46:55 mstar kernel: 
Jul  1 00:46:57 mstar kernel: -> #3 (&dev->ev_mutex){--..}:
Jul  1 00:46:58 mstar kernel:        [] __lock_acquire+0x9ea/0xb75
Jul  1 00:46:58 mstar kernel:        [] lock_acquire+0x56/0x6f
Jul  1 00:46:59 mstar kernel:        [] __mutex_lock_slowpath+0xf7/0x26e
Jul  1 00:46:59 mstar kernel:        [] mutex_lock+0x21/0x24
Jul  1 00:47:00 mstar kernel:        [] inotify_dev_queue_event+0x1f/0x113
Jul  1 00:47:01 mstar kernel:        [] inotify_remove_watch_locked+0x3b/0x42
Jul  1 00:47:02 mstar kernel:        [] inotify_rm_wd+0x75/0x93
Jul  1 00:47:04 mstar kernel:        [] sys_inotify_rm_watch+0x40/0x58
Jul  1 00:47:06 mstar kernel:        [] syscall_call+0x7/0xb
Jul  1 00:47:10 mstar kernel:        [] 0xffffffff
Jul  1 00:47:15 mstar kernel: 
Jul  1 00:47:17 mstar kernel: -> #2 (&ih->mutex){--..}:
Jul  1 00:47:17 mstar kernel:        [] __lock_acquire+0x9ea/0xb75
Jul  1 00:47:17 mstar kernel:        [] lock_acquire+0x56/0x6f
Jul  1 00:47:17 mstar kernel:        [] __mutex_lock_slowpath+0xf7/0x26e
Jul  1 00:47:17 mstar kernel:        [] mutex_lock+0x21/0x24
Jul  1 00:47:17 mstar kernel:        [] inotify_find_update_watch+0x42/0x83
Jul  1 00:47:17 mstar kernel:        [] sys_inotify_add_watch+0xb0/0x151
Jul  1 00:47:17 mstar kernel:        [] syscall_call+0x7/0xb
Jul  1 00:47:17 mstar kernel:        [] 0xffffffff
Jul  1 00:47:17 mstar kernel: 
Jul  1 00:47:17 mstar kernel: -> #1 (&inode->inotify_mutex){--..}:
Jul  1 00:47:18 mstar kernel:        [] __lock_acquire+0x9ea/0xb75
Jul  1 00:47:18 mstar kernel:        [] lock_acquire+0x56/0x6f
Jul  1 00:47:18 mstar kernel:        [] __mutex_lock_slowpath+0xf7/0x26e
Jul  1 00:47:18 mstar kernel:        [] mutex_lock+0x21/0x24
Jul  1 00:47:18 mstar kernel:        [] inotify_inode_queue_event+0x36/0xbc
Jul  1 00:47:18 mstar kernel:        [] inotify_dentry_parent_queue_event+0x6b/0x83
Jul  1 00:47:18 mstar kernel:        [] __fput+0x76/0x173
Jul  1 00:47:18 mstar kernel:        [] fput+0x17/0x19
Jul  1 00:47:18 mstar kernel:        [] remove_vma+0x3c/0x4e
Jul  1 00:47:18 mstar kernel:        [] do_munmap+0x19b/0x1b4
Jul  1 00:47:18 mstar kernel:        [] sys_munmap+0x30/0x3f
Jul  1 00:47:18 mstar kernel:        [] syscall_call+0x7/0xb
Jul  1 00:47:18 mstar kernel:        [] 0xffffffff
Jul  1 00:47:18 mstar kernel: 
Jul  1 00:47:18 mstar kernel: -> #0 (&mm->mmap_sem){----}:
Jul  1 00:47:18 mstar kernel:        [] __lock_acquire+0x8ce/0xb75
Jul  1 00:47:18 mstar kernel:        [] lock_acquire+0x56/0x6f
Jul  1 00:47:18 mstar kernel:        [] down_read+0x3f/0x51
Jul  1 00:47:18 mstar kernel:        [] do_page_fault+0x177/0x504
Jul  1 00:47:18 mstar kernel:        [] error_code+0x72/0x78
Jul  1 00:47:18 mstar kernel:        [] copy_to_user+0x42/0x4d
Jul  1 00:47:18 mstar kernel:        [] inotify_read+0xfb/0x169
Jul  1 00:47:18 mstar kernel:        [] vfs_read+0xad/0x167
Jul  1 00:47:18 mstar kernel:        [] sys_read+0x3d/0x61
Jul  1 00:47:18 mstar kernel:        [] syscall_call+0x7/0xb
Jul  1 00:47:18 mstar kernel:        [] 0xffffffff
Jul  1 00:47:18 mstar kernel: 
Jul  1 00:47:18 mstar kernel: other info that might help us debug this:
Jul  1 00:47:18 mstar kernel: 
Jul  1 00:47:18 mstar kernel: 1 lock held by gdl_fs_crawler/3078:
Jul  1 00:47:18 mstar kernel:  #0:  (&dev->ev_mutex){--..}, at: [] mutex_lock+0x21/0x24
Jul  1 00:47:18 mstar kernel: 
Jul  1 00:47:18 mstar kernel: stack backtrace:
Jul  1 00:47:18 mstar kernel:  [] show_trace_log_lvl+0x1a/0x2f
Jul  1 00:47:18 mstar kernel:  [] show_trace+0x12/0x14
Jul  1 00:47:18 mstar kernel:  [] dump_stack+0x16/0x18
Jul  1 00:47:18 mstar kernel:  [] print_circular_bug_tail+0x5f/0x68
Jul  1 00:47:18 mstar kernel:  [] __lock_acquire+0x8ce/0xb75
Jul  1 00:47:18 mstar kernel:  [] lock_acquire+0x56/0x6f
Jul  1 00:47:18 mstar kernel:  [] down_read+0x3f/0x51
Jul  1 00:47:18 mstar kernel:  [] do_page_fault+0x177/0x504
Jul  1 00:47:18 mstar kernel:  [] error_code+0x72/0x78
Jul  1 00:47:18 mstar kernel:  [] copy_to_user+0x42/0x4d
Jul  1 00:47:18 mstar kernel:  [] inotify_read+0xfb/0x169
Jul  1 00:47:18 mstar kernel:  [] vfs_read+0xad/0x167
Jul  1 00:47:18 mstar kernel:  [] sys_read+0x3d/0x61
Jul  1 00:47:18 mstar kernel:  [] syscall_call+0x7/0xb
Jul  1 00:47:18 mstar kernel:  =======================
Jul  1 01:04:06 mstar kernel: Uhhuh. NMI received for unknown reason 11 on CPU 0.
Jul  1 01:04:06 mstar kernel: Do you have a strange power saving mode enabled?
Jul  1 01:04:06 mstar kernel: Dazed and confused, but trying to continue



我倒希望这是个别现象。听说 Inotify 处理 VIM 时的确要很小心的,可是没想到会让我碰上。又,我写程序也太烂了,那么几行的程序也要调那么久(今天也没想出来为什么二分法收敛又快又稳定 :( )
Tags: fedora, 小东西
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 1 comment