Linode Forum
Linode Community Forums
 FAQFAQ    SearchSearch    MembersMembers      Register Register 
 LoginLogin [ Anonymous ] 
Post new topic  Reply to topic
Author Message
 Post subject:
PostPosted: Mon Feb 16, 2009 3:36 pm 
Offline
Senior Member

Joined: Fri Dec 07, 2007 1:37 am
Posts: 385
Location: NC, USA
drake127 wrote:
I managed to crash 2.6.28.3-x86_64-linode5 during recursive chown Gentoo portage on loopback device formatted to reiserfs twice in row. Since it is production machine, I'd like not to test it again without better ways to describe the issue.

I did something like this:
Code:
mv /usr/portage /usr/portage.tmp
losetup /dev/loop0 /usr/portage.img
mkreiserfs /dev/loop0
mount /dev/loop0 /usr/portage
cp -a /usr/portage.tmp/* /usr/portage
# Everything worked fine so far
chown -R portage:portage /usr/portage
And whole linode crashed. There was kernel panic report on console screen but unfortunatelly was not complete and I did not discovered it in logs.

Can somebody try similar procedure or tell me what I am doing wrong or tell me how to provide more information?

I tried this on my linode with the same kernel and could not recreate your problems. I didn't do it directly on /usr, but made a separate lv for testing. I tried reiser on reiser, reiser on ext3, and ext3 on ext3, and in all cases I could copy /usr/portage/* and chown -R the mounted loopback without errors.
Code:
lvcreate -L1G -ntest vg
mkreiserfs /dev/vg/test
mount /dev/vg/test /mnt/tmp
dd if=/dev/zero of=/mnt/tmp/portage.img bs=1K count=500K
losetup /dev/loop0 /mnt/tmp/portage.img
mkreiserfs /dev/loop0
mkdir /mnt/tmp/portage
mount /dev/loop0 /mnt/tmp/portage
cp -a /usr/portage/* /mnt/tmp/portage
chown -R portage:portage /mnt/tmp/portage
I'm not sure what is different, but it seems stable for me.


Top
   
 Post subject:
PostPosted: Fri Feb 20, 2009 8:41 am 
Offline
Senior Member

Joined: Sat Nov 15, 2008 4:24 pm
Posts: 55
Location: Czech Republic
I was not able to reproduce this bug either. It crashed three times in a row but after that it worked like a charm.

So I let it be and experimented with custom kernel (pv_ops) and hit this bug again during its compilation. So I suspect it throws this panic based on intensive disk I/O and some yet unrevealed condition.


Top
   
 Post subject:
PostPosted: Fri Feb 20, 2009 4:31 pm 
Offline
Senior Member

Joined: Sat Jun 05, 2004 12:49 am
Posts: 333
Saw this:
Code:
php[839]: segfault at 7f502fb03ac0 ip 00007f502fb03ac0 sp 00007fff3ff60838 error 14 in libtasn1.so.3
.0.16[7f5032ca2000+10000]                                                                           
php[2172]: segfault at 7f55984fdac0 ip 00007f55984fdac0 sp 00007fffa8959cf8 error 14 in libtasn1.so.
3.0.16[7f559b69c000+10000]                                                                         
php[2833]: segfault at 7fa6f6d29ac0 ip 00007fa6f6d29ac0 sp 00007fff071876a8 error 14 in libtasn1.so.
3.0.16[7fa6f9ec8000+10000]                                                                         
php[12205]: segfault at 7f21f71ccac0 ip 00007f21f71ccac0 sp 00007fff0762a008 error 14 in libtasn1.so
.3.0.16[7f21fa36b000+10000]


which was then followed by:

Code:
general protection fault: 0000 [#1] SMP                                                             
last sysfs file:                                                                                   
CPU 0                                                                                               
Modules linked in:                                                                                 
Pid: 13223, comm: htop Not tainted 2.6.28.3-x86_64-linode5 #1                                       
RIP: e030:[<ffffffff8024e5ee>]  [<ffffffff8024e5ee>] pid_task+0xe/0x30                             
RSP: e02b:ffff880014dfdc48  EFLAGS: 00010286                                                       
RAX: c381ffffde87e83c RBX: ffff880011c93468 RCX: 0000000000000000                                   
RDX: 0000000000000000 RSI: 0000000000000000 RDI: c381ffffde87e83c                                   
RBP: ffff880011e09318 R08: 0000000000000000 R09: ffff880015756140                                   
:                                                                                                   
R13: ffff880014dfdd18 R14: ffff880014dfdd28 R15: 00000000ffffff9c                                   
FS:  00007f87ead906e0(0000) GS:ffffffff809a1000(0000) knlGS:0000000000000000                       
CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033                                                   
CR2: 00007f87ead99000 CR3: 00000000156c9000 CR4: 0000000000000660                                   
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000                                   
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400                                   
Process htop (pid: 13223, threadinfo ffff880014dfc000, task ffff880015a0d950)                       
Stack:
 ffffffff8024e615 ffffffff802eeb34 ffff880011c93468 ffff88000e07c00d                               
 ffff880014dfde68 ffffffff802aa124 ffff880014dfde08 ffff88001568be80                               
 ffff880014dfdc98 ffff8800162dfa88 ffff88000e07c006 ffff880014dfdd18                               
Call Trace:                                                                                         
 [<ffffffff8024e615>] ? get_pid_task+0x5/0x10                                                       
 [<ffffffff802eeb34>] ? pid_revalidate+0x24/0x120                                                   
 [<ffffffff802aa124>] ? do_lookup+0x64/0x250                                                       
 [<ffffffff802ac73f>] ? __link_path_walk+0x74f/0xdd0                                               
 [<ffffffff806e3e04>] ? _spin_unlock_irqrestore+0x14/0x20                                           
 [<ffffffff802ace14>] ? path_walk+0x54/0xb0                                                         
 [<ffffffff806e3e04>] ? _spin_unlock_irqrestore+0x14/0x20                                           
 [<ffffffff802acfb2>] ? do_path_lookup+0x82/0x1d0                                                   
 [<ffffffff802ade68>] ? path_lookup_open+0x68/0xd0                                                 
 [<ffffffff8020c356>] ? xen_mc_flush+0xc6/0x190
 [<ffffffff802ae152>] ? do_filp_open+0xc2/0x910                                                     
 [<ffffffff80295bec>] ? free_pages_and_swap_cache+0x8c/0xb0                                         
 [<ffffffff8029dbdc>] ? kmem_cache_free+0x5c/0xa0                                                   
 [<ffffffff8028d7ba>] ? remove_vma+0x4a/0x60                                                       
 [<ffffffff802b7319>] ? alloc_fd+0x109/0x130                                                       
 [<ffffffff8029fc0c>] ? do_sys_open+0x5c/0xf0                                                       
 [<ffffffff8021130a>] ? system_call_fastpath+0x16/0x1b                                             
Code: 49 8b 80 d8 01 00 00 48 89 50 08 48 c7 87 e0 01 00 00 00 02 20 00 c3 66 0f 1f 44 00 00 48 85 f
f 75 03 31 c0 c3 89 f2 48 8d 04 d7 <48> 8b 48 08 48 85 c9 74 ee 48 8d 04 52 48 8d 04 c5 d8 01 00 00
RIP  [<ffffffff8024e5ee>] pid_task+0xe/0x30                                                         
 RSP <ffff880014dfdc48>                                                                             
---[ end trace ef3c7ac0c009758b ]---


which then followed a metric ton of:

Code:
php-cgi[13218] general protection ip:674970 sp:7fffedaf59b0 error:0 in php5-cgi[400000+506000]      
php-cgi[13219] general protection ip:674970 sp:7fffedaf59b0 error:0 in php5-cgi[400000+506000]     
php-cgi[13220] general protection ip:674970 sp:7fffedaf59b0 error:0 in php5-cgi[400000+506000]     
php-cgi[13221] general protection ip:674970 sp:7fffedaf59b0 error:0 in php5-cgi[400000+506000]     
php-cgi[13222] general protection ip:674970 sp:7fffedaf59b0 error:0 in php5-cgi[400000+506000]


Top
   
 Post subject:
PostPosted: Fri Feb 20, 2009 4:47 pm 
Offline
Senior Member

Joined: Sat Jun 05, 2004 12:49 am
Posts: 333
also ooped when I rebooted the machine, wasn't able to capture it from LISH before it rebooted and lost it in the scroll.


Top
   
 Post subject:
PostPosted: Mon Feb 23, 2009 2:53 am 
Offline
Junior Member

Joined: Sat Jan 05, 2008 2:40 am
Posts: 43
2.6.28.3 has been running great here (although several subsequent .28 patches seem to have closed some scaryish bugs, so a version bump wouldn't be bad). Even got some ext4 goodness up and running. +1 from me


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
RSS

Powered by phpBB® Forum Software © phpBB Group