August 30, 201114 yr I am currently running a parity check due to an improper shutdown. Everything seemed to be going ok. I was coping some large files to the server and this is what showed up in the syslog and the client hanged on the copying. What does this mean? Aug 29 22:23:32 Hitch kernel: ------------[ cut here ]------------ Aug 29 22:23:32 Hitch kernel: kernel BUG at drivers/md/unraid.c:436! Aug 29 22:23:32 Hitch kernel: invalid opcode: 0000 [#1] SMP Aug 29 22:23:32 Hitch kernel: last sysfs file: /sys/devices/pci0000:00/0000:00:11.0/host6/target6:0:0/6:0:0:0/block/sdf/stat Aug 29 22:23:32 Hitch kernel: Modules linked in: md_mod xor atiixp ahci r8169 mvsas libsas scst scsi_transport_sas Aug 29 22:23:32 Hitch kernel: Aug 29 22:23:32 Hitch kernel: Pid: 3095, comm: flush-9:2 Not tainted (2.6.32.9-unRAID # A760G M2+ Aug 29 22:23:32 Hitch kernel: EIP: 0060:[<f851bc2c>] EFLAGS: 00010286 CPU: 1 Aug 29 22:23:32 Hitch kernel: EIP is at unraid_make_request+0x1e1/0x342 [md_mod] Aug 29 22:23:32 Hitch kernel: EAX: c2929d30 EBX: 00000002 ECX: 00000005 EDX: c2929d30 Aug 29 22:23:32 Hitch kernel: ESI: 00000001 EDI: c2929c20 EBP: c21e1bdc ESP: c21e1b98 Aug 29 22:23:32 Hitch kernel: DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Aug 29 22:23:32 Hitch kernel: Process flush-9:2 (pid: 3095, ti=c21e0000 task=c2252260 task.ti=c21e0000) Aug 29 22:23:32 Hitch kernel: Stack: Aug 29 22:23:32 Hitch kernel: c3c76d80 00000002 f74a5ba0 00000001 86fe7100 00000000 86fe7108 00000000 Aug 29 22:23:32 Hitch kernel: <0> c2929d30 f74a5ba0 c41884e0 c2929d48 c21e1bfc c1126fb4 f6de52e0 00000008 Aug 29 22:23:32 Hitch kernel: <0> c430a000 c21e1bfc f8518ef7 c3c76d80 00000002 00000000 f6de52e0 00000008 Aug 29 22:23:32 Hitch kernel: Call Trace: Aug 29 22:23:32 Hitch kernel: [<c1126fb4>] ? __make_request+0x235/0x341 Aug 29 22:23:32 Hitch kernel: [<f8518ef7>] ? md_make_request+0x83/0x8b [md_mod] Aug 29 22:23:32 Hitch kernel: [<c1125b0f>] ? generic_make_request+0x1d6/0x211 Aug 29 22:23:32 Hitch kernel: [<c104a784>] ? mempool_alloc+0x3d/0xd3 Aug 29 22:23:32 Hitch kernel: [<c1126d10>] ? submit_bio+0x96/0x9b Aug 29 22:23:32 Hitch kernel: [<c1089412>] ? bio_alloc_bioset+0x37/0x96 Aug 29 22:23:32 Hitch kernel: [<c1085ee1>] ? submit_bh+0xde/0xfd Aug 29 22:23:32 Hitch kernel: [<c10af011>] ? reiserfs_writepage+0xa42/0xb85 Aug 29 22:23:32 Hitch kernel: [<f84788a5>] ? rtl8169_poll+0xf6/0x11a [r8169] Aug 29 22:23:32 Hitch kernel: [<c12312aa>] ? net_rx_action+0x57/0x102 Aug 29 22:23:32 Hitch kernel: [<c1133b65>] ? radix_tree_gang_lookup_tag_slot+0x7b/0x9a Aug 29 22:23:32 Hitch kernel: [<c104d843>] ? __writepage+0xb/0x23 Aug 29 22:23:32 Hitch kernel: [<c104daeb>] ? write_cache_pages+0x1b4/0x2ac Aug 29 22:23:32 Hitch kernel: [<c104d838>] ? __writepage+0x0/0x23 Aug 29 22:23:32 Hitch kernel: [<c104dc00>] ? generic_writepages+0x1d/0x27 Aug 29 22:23:32 Hitch kernel: [<c104dc2f>] ? do_writepages+0x25/0x28 Aug 29 22:23:32 Hitch kernel: [<c1081c82>] ? writeback_single_inode+0xae/0x1eb Aug 29 22:23:32 Hitch kernel: [<c108233d>] ? writeback_inodes_wb+0x2ca/0x343 Aug 29 22:23:32 Hitch kernel: [<c10824a6>] ? wb_writeback+0xf0/0x14d Aug 29 22:23:32 Hitch kernel: [<c108257b>] ? wb_clear_pending+0x65/0x6a Aug 29 22:23:32 Hitch kernel: [<c10825e2>] ? wb_do_writeback+0x62/0x11b Aug 29 22:23:32 Hitch kernel: [<c10826c3>] ? bdi_writeback_task+0x28/0x85 Aug 29 22:23:32 Hitch kernel: [<c1056226>] ? bdi_start_fn+0x0/0xa1 Aug 29 22:23:32 Hitch kernel: [<c105627b>] ? bdi_start_fn+0x55/0xa1 Aug 29 22:23:32 Hitch kernel: [<c1056226>] ? bdi_start_fn+0x0/0xa1 Aug 29 22:23:32 Hitch kernel: [<c1033869>] ? kthread+0x61/0x68 Aug 29 22:23:32 Hitch kernel: [<c1033808>] ? kthread+0x0/0x68 Aug 29 22:23:32 Hitch kernel: [<c100339f>] ? kernel_thread_helper+0x7/0x1a Aug 29 22:23:32 Hitch kernel: Code: ca 7c ea 83 7d dc 00 75 04 0f 0b eb fe 8d 47 28 e8 88 49 d8 c8 8b 45 dc 83 78 0c 00 74 04 0f 0b eb fe 8b 55 dc 83 7a 10 00 74 04 <0f> 0b eb fe 83 7d c8 00 74 06 83 7d c8 02 75 0e 8b 5d bc 8b 4d Aug 29 22:23:32 Hitch kernel: EIP: [<f851bc2c>] unraid_make_request+0x1e1/0x342 [md_mod] SS:ESP 0068:c21e1b98 Aug 29 22:23:32 Hitch kernel: ---[ end trace c0c51844f16b2369 ]---
August 30, 201114 yr I am currently running a parity check due to an improper shutdown. Everything seemed to be going ok. I was coping some large files to the server and this is what showed up in the syslog and the client hanged on the copying. What does this mean? Aug 29 22:23:32 Hitch kernel: ------------[ cut here ]------------ Aug 29 22:23:32 Hitch kernel: kernel BUG at drivers/md/unraid.c:436! Aug 29 22:23:32 Hitch kernel: invalid opcode: 0000 [#1] SMP Aug 29 22:23:32 Hitch kernel: last sysfs file: /sys/devices/pci0000:00/0000:00:11.0/host6/target6:0:0/6:0:0:0/block/sdf/stat Aug 29 22:23:32 Hitch kernel: Modules linked in: md_mod xor atiixp ahci r8169 mvsas libsas scst scsi_transport_sas Aug 29 22:23:32 Hitch kernel: Aug 29 22:23:32 Hitch kernel: Pid: 3095, comm: flush-9:2 Not tainted (2.6.32.9-unRAID # A760G M2+ Aug 29 22:23:32 Hitch kernel: EIP: 0060:[<f851bc2c>] EFLAGS: 00010286 CPU: 1 Aug 29 22:23:32 Hitch kernel: EIP is at unraid_make_request+0x1e1/0x342 [md_mod] Aug 29 22:23:32 Hitch kernel: EAX: c2929d30 EBX: 00000002 ECX: 00000005 EDX: c2929d30 Aug 29 22:23:32 Hitch kernel: ESI: 00000001 EDI: c2929c20 EBP: c21e1bdc ESP: c21e1b98 Aug 29 22:23:32 Hitch kernel: DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Aug 29 22:23:32 Hitch kernel: Process flush-9:2 (pid: 3095, ti=c21e0000 task=c2252260 task.ti=c21e0000) Aug 29 22:23:32 Hitch kernel: Stack: Aug 29 22:23:32 Hitch kernel: c3c76d80 00000002 f74a5ba0 00000001 86fe7100 00000000 86fe7108 00000000 Aug 29 22:23:32 Hitch kernel: <0> c2929d30 f74a5ba0 c41884e0 c2929d48 c21e1bfc c1126fb4 f6de52e0 00000008 Aug 29 22:23:32 Hitch kernel: <0> c430a000 c21e1bfc f8518ef7 c3c76d80 00000002 00000000 f6de52e0 00000008 Aug 29 22:23:32 Hitch kernel: Call Trace: Aug 29 22:23:32 Hitch kernel: [<c1126fb4>] ? __make_request+0x235/0x341 Aug 29 22:23:32 Hitch kernel: [<f8518ef7>] ? md_make_request+0x83/0x8b [md_mod] Aug 29 22:23:32 Hitch kernel: [<c1125b0f>] ? generic_make_request+0x1d6/0x211 Aug 29 22:23:32 Hitch kernel: [<c104a784>] ? mempool_alloc+0x3d/0xd3 Aug 29 22:23:32 Hitch kernel: [<c1126d10>] ? submit_bio+0x96/0x9b Aug 29 22:23:32 Hitch kernel: [<c1089412>] ? bio_alloc_bioset+0x37/0x96 Aug 29 22:23:32 Hitch kernel: [<c1085ee1>] ? submit_bh+0xde/0xfd Aug 29 22:23:32 Hitch kernel: [<c10af011>] ? reiserfs_writepage+0xa42/0xb85 Aug 29 22:23:32 Hitch kernel: [<f84788a5>] ? rtl8169_poll+0xf6/0x11a [r8169] Aug 29 22:23:32 Hitch kernel: [<c12312aa>] ? net_rx_action+0x57/0x102 Aug 29 22:23:32 Hitch kernel: [<c1133b65>] ? radix_tree_gang_lookup_tag_slot+0x7b/0x9a Aug 29 22:23:32 Hitch kernel: [<c104d843>] ? __writepage+0xb/0x23 Aug 29 22:23:32 Hitch kernel: [<c104daeb>] ? write_cache_pages+0x1b4/0x2ac Aug 29 22:23:32 Hitch kernel: [<c104d838>] ? __writepage+0x0/0x23 Aug 29 22:23:32 Hitch kernel: [<c104dc00>] ? generic_writepages+0x1d/0x27 Aug 29 22:23:32 Hitch kernel: [<c104dc2f>] ? do_writepages+0x25/0x28 Aug 29 22:23:32 Hitch kernel: [<c1081c82>] ? writeback_single_inode+0xae/0x1eb Aug 29 22:23:32 Hitch kernel: [<c108233d>] ? writeback_inodes_wb+0x2ca/0x343 Aug 29 22:23:32 Hitch kernel: [<c10824a6>] ? wb_writeback+0xf0/0x14d Aug 29 22:23:32 Hitch kernel: [<c108257b>] ? wb_clear_pending+0x65/0x6a Aug 29 22:23:32 Hitch kernel: [<c10825e2>] ? wb_do_writeback+0x62/0x11b Aug 29 22:23:32 Hitch kernel: [<c10826c3>] ? bdi_writeback_task+0x28/0x85 Aug 29 22:23:32 Hitch kernel: [<c1056226>] ? bdi_start_fn+0x0/0xa1 Aug 29 22:23:32 Hitch kernel: [<c105627b>] ? bdi_start_fn+0x55/0xa1 Aug 29 22:23:32 Hitch kernel: [<c1056226>] ? bdi_start_fn+0x0/0xa1 Aug 29 22:23:32 Hitch kernel: [<c1033869>] ? kthread+0x61/0x68 Aug 29 22:23:32 Hitch kernel: [<c1033808>] ? kthread+0x0/0x68 Aug 29 22:23:32 Hitch kernel: [<c100339f>] ? kernel_thread_helper+0x7/0x1a Aug 29 22:23:32 Hitch kernel: Code: ca 7c ea 83 7d dc 00 75 04 0f 0b eb fe 8d 47 28 e8 88 49 d8 c8 8b 45 dc 83 78 0c 00 74 04 0f 0b eb fe 8b 55 dc 83 7a 10 00 74 04 <0f> 0b eb fe 83 7d c8 00 74 06 83 7d c8 02 75 0e 8b 5d bc 8b 4d Aug 29 22:23:32 Hitch kernel: EIP: [<f851bc2c>] unraid_make_request+0x1e1/0x342 [md_mod] SS:ESP 0068:c21e1b98 Aug 29 22:23:32 Hitch kernel: ---[ end trace c0c51844f16b2369 ]--- It indicates there is a bug in unRAID that shows itself in servers with multi-core CPUs. We have absolutely no idea which version of unRAID unfortunately, since you did not attach a syslog to your post, nor even mention which version of unRAID you are running or the hardware you are running it on. Joe L.
August 30, 201114 yr Does this happen to be an AMD CPU and do you use nfs shares? Kernel bug reported and a possible patch http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=invalid+opcode%3A+0000+%5B%231%5D+SMP&qscrl=1 https://lkml.org/lkml/2010/3/15/192 https://patchwork.kernel.org/patch/85984/
August 30, 201114 yr Author Sorry... Case: Coolermaster Centurion 590 Drive Cages: Supermicro 5 in 3 hot swappable drive bays x2 P.S.: CORSAIR CMPSU-450VX Motherboard: Biostar A760G M2+ CPU: AMD Athlon X2 BE-2400 2.3 GHz Memory: 4GB: qty 2 - A-DATA 2GB (2 x 1GB) 240-Pin DDR2 SDRAM DDR2 800 (PC2 6400) Dual Channel Kit Desktop Memory Model AD2U800B1G5-DRH HDD Controller: Supermicro AOC-SASLP-MV8 (installed with 1 drive) HDD (all WD,): Parity: 2TB EARS Disk 1: 2TB EARS Disk 2: 2TB EARS Disk 3: 2TB EARS Disk 4: 2TB EARS (all EARS – 4k aligned) Flash: SanDisk Cruzer 2GB unRAID plus: 4.7 Samba shares only Full syslog is attached. I have had my fair share of problems with this build since I started. When running normally, it seems to work fine. But when I run a parity check it ends up running out of memory and kills some of my processes. I could never use the server during a parity check, cause it would kill samba almost imediately. I actally thought this was normal until I saw others using there server while a parity check was going on. I went from 2 to 4 gigs and that didn't help. So this time, I stopped crashplan and cache_dir from running at boot and I wasn't getting any out of memory errors. So I tried to use the server as normal, copying things to it. When I was doing this earlier yesterday, it appeared that the server froze after copying for awhile (I was doing this via RDP). I lost the web interface, unraid interface and couldn't even telenet into it. When I got home I hard rebooted causing anoter parity check. This time I would do a little bit at a time during the parity check, while keeping an eye on my syslog entries. Then I got a connecting error on my client while copying some files, that is the kernel panic I posted earlier. Although smb seemed to work ok, I couldn't copy anything else from that client to the server. Tried to copy from another client and that worked ok for a few minutes then I received another disconnect. This time, no other entries in the syslog. At some point unmenu stopped working even though I didn't see an entry for this. Maybe the syslog stoped getting written too. At this point it was about 45% done with the parity check. I thought I would just leave it and go to bed. Woke up this morning with it at 57% and all drives a sleep and it telling me it would take like 475678 minutes or something like that. I tried to stop the array since the web interface was still working. That locked the web interface up. Tried to issue a reboot command from telenet and that did nothing forcing me to hard boot it again. Currently it's at 45%+ parity check moving along just fine. I won't touch it this time (unless instructed to do so). I have run a memory test a few months ago with no problems. Sorry for the long post. Edit - hardware list posted syslog-2011-08-29a.zip
August 30, 201114 yr Author Any suggestions based on what I posted above? The parity check completed fine, however, I didn't touch the server why it was running. I have attached the complete syslog for any reference or comparison. Thanks. syslog-2011-08-30.zip
August 31, 201114 yr Any suggestions based on what I posted above? The parity check completed fine, however, I didn't touch the server why it was running. I have attached the complete syslog for any reference or comparison. Thanks. yes, send an e-mail to [email protected] point him to the kernel oops post you made. It indicates an issue with SMP processing. Joe L.
August 31, 201114 yr Author Thanks Joe. The server just locked up on me again and this time is wasn't doing a parity check, it was just copying files. Since it is locked, I can't get a syslog. I have another AMD processor, should I switch it out. It is still an x2 cpu though. Or maybe try to disable one of the cores in the bios? This build had been runing for about 6+ months and I haven't experienced anything like this before. I'm a little concerned that I can't even copy files to the server without locking it up. Any suggestions would be appreciated. I will email Tom for the time being. Edit - Hold up for now - I have bad memory.
August 31, 201114 yr I am currently running a parity check due to an improper shutdown. Everything seemed to be going ok. I was coping some large files to the server and this is what showed up in the syslog and the client hanged on the copying. What does this mean? Aug 29 22:23:32 Hitch kernel: ------------[ cut here ]------------ Aug 29 22:23:32 Hitch kernel: kernel BUG at drivers/md/unraid.c:436! Aug 29 22:23:32 Hitch kernel: invalid opcode: 0000 [#1] SMP Aug 29 22:23:32 Hitch kernel: last sysfs file: /sys/devices/pci0000:00/0000:00:11.0/host6/target6:0:0/6:0:0:0/block/sdf/stat Aug 29 22:23:32 Hitch kernel: Modules linked in: md_mod xor atiixp ahci r8169 mvsas libsas scst scsi_transport_sas Aug 29 22:23:32 Hitch kernel: Aug 29 22:23:32 Hitch kernel: Pid: 3095, comm: flush-9:2 Not tainted (2.6.32.9-unRAID # A760G M2+ Aug 29 22:23:32 Hitch kernel: EIP: 0060:[<f851bc2c>] EFLAGS: 00010286 CPU: 1 Aug 29 22:23:32 Hitch kernel: EIP is at unraid_make_request+0x1e1/0x342 [md_mod] Aug 29 22:23:32 Hitch kernel: EAX: c2929d30 EBX: 00000002 ECX: 00000005 EDX: c2929d30 Aug 29 22:23:32 Hitch kernel: ESI: 00000001 EDI: c2929c20 EBP: c21e1bdc ESP: c21e1b98 Aug 29 22:23:32 Hitch kernel: DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Aug 29 22:23:32 Hitch kernel: Process flush-9:2 (pid: 3095, ti=c21e0000 task=c2252260 task.ti=c21e0000) Aug 29 22:23:32 Hitch kernel: Stack: Aug 29 22:23:32 Hitch kernel: c3c76d80 00000002 f74a5ba0 00000001 86fe7100 00000000 86fe7108 00000000 Aug 29 22:23:32 Hitch kernel: <0> c2929d30 f74a5ba0 c41884e0 c2929d48 c21e1bfc c1126fb4 f6de52e0 00000008 Aug 29 22:23:32 Hitch kernel: <0> c430a000 c21e1bfc f8518ef7 c3c76d80 00000002 00000000 f6de52e0 00000008 Aug 29 22:23:32 Hitch kernel: Call Trace: Aug 29 22:23:32 Hitch kernel: [<c1126fb4>] ? __make_request+0x235/0x341 Aug 29 22:23:32 Hitch kernel: [<f8518ef7>] ? md_make_request+0x83/0x8b [md_mod] Aug 29 22:23:32 Hitch kernel: [<c1125b0f>] ? generic_make_request+0x1d6/0x211 Aug 29 22:23:32 Hitch kernel: [<c104a784>] ? mempool_alloc+0x3d/0xd3 Aug 29 22:23:32 Hitch kernel: [<c1126d10>] ? submit_bio+0x96/0x9b Aug 29 22:23:32 Hitch kernel: [<c1089412>] ? bio_alloc_bioset+0x37/0x96 Aug 29 22:23:32 Hitch kernel: [<c1085ee1>] ? submit_bh+0xde/0xfd Aug 29 22:23:32 Hitch kernel: [<c10af011>] ? reiserfs_writepage+0xa42/0xb85 Aug 29 22:23:32 Hitch kernel: [<f84788a5>] ? rtl8169_poll+0xf6/0x11a [r8169] Aug 29 22:23:32 Hitch kernel: [<c12312aa>] ? net_rx_action+0x57/0x102 Aug 29 22:23:32 Hitch kernel: [<c1133b65>] ? radix_tree_gang_lookup_tag_slot+0x7b/0x9a Aug 29 22:23:32 Hitch kernel: [<c104d843>] ? __writepage+0xb/0x23 Aug 29 22:23:32 Hitch kernel: [<c104daeb>] ? write_cache_pages+0x1b4/0x2ac Aug 29 22:23:32 Hitch kernel: [<c104d838>] ? __writepage+0x0/0x23 Aug 29 22:23:32 Hitch kernel: [<c104dc00>] ? generic_writepages+0x1d/0x27 Aug 29 22:23:32 Hitch kernel: [<c104dc2f>] ? do_writepages+0x25/0x28 Aug 29 22:23:32 Hitch kernel: [<c1081c82>] ? writeback_single_inode+0xae/0x1eb Aug 29 22:23:32 Hitch kernel: [<c108233d>] ? writeback_inodes_wb+0x2ca/0x343 Aug 29 22:23:32 Hitch kernel: [<c10824a6>] ? wb_writeback+0xf0/0x14d Aug 29 22:23:32 Hitch kernel: [<c108257b>] ? wb_clear_pending+0x65/0x6a Aug 29 22:23:32 Hitch kernel: [<c10825e2>] ? wb_do_writeback+0x62/0x11b Aug 29 22:23:32 Hitch kernel: [<c10826c3>] ? bdi_writeback_task+0x28/0x85 Aug 29 22:23:32 Hitch kernel: [<c1056226>] ? bdi_start_fn+0x0/0xa1 Aug 29 22:23:32 Hitch kernel: [<c105627b>] ? bdi_start_fn+0x55/0xa1 Aug 29 22:23:32 Hitch kernel: [<c1056226>] ? bdi_start_fn+0x0/0xa1 Aug 29 22:23:32 Hitch kernel: [<c1033869>] ? kthread+0x61/0x68 Aug 29 22:23:32 Hitch kernel: [<c1033808>] ? kthread+0x0/0x68 Aug 29 22:23:32 Hitch kernel: [<c100339f>] ? kernel_thread_helper+0x7/0x1a Aug 29 22:23:32 Hitch kernel: Code: ca 7c ea 83 7d dc 00 75 04 0f 0b eb fe 8d 47 28 e8 88 49 d8 c8 8b 45 dc 83 78 0c 00 74 04 0f 0b eb fe 8b 55 dc 83 7a 10 00 74 04 <0f> 0b eb fe 83 7d c8 00 74 06 83 7d c8 02 75 0e 8b 5d bc 8b 4d Aug 29 22:23:32 Hitch kernel: EIP: [<f851bc2c>] unraid_make_request+0x1e1/0x342 [md_mod] SS:ESP 0068:c21e1b98 Aug 29 22:23:32 Hitch kernel: ---[ end trace c0c51844f16b2369 ]--- This has nothing to do with "multiple cores". From the system log, you are running 4.7-beta1. Please update to either 4.7 (final) or latest 5.0-beta.
September 1, 201114 yr Author I'm going to label this one solved for now, since my bad memory was most likely the cause for my recent problems and lockups. Thanks all for your help.
Archived
This topic is now archived and is closed to further replies.