{"id":39443,"date":"2014-05-09T09:36:55","date_gmt":"2014-05-09T09:36:55","guid":{"rendered":"http:\/\/blog.open-e.com\/?p=39443"},"modified":"2025-04-04T06:53:01","modified_gmt":"2025-04-04T06:53:01","slug":"update-your-linux-driver-for-areca-arc-1883-sas-raid-adapter","status":"publish","type":"post","link":"https:\/\/www.open-e.com\/blog\/update-your-linux-driver-for-areca-arc-1883-sas-raid-adapter\/","title":{"rendered":"Update your Linux driver for  Areca ARC-1883 SAS RAID Adapter"},"content":{"rendered":"<p>\t\t\t\tRecently, when performing planned test scenarios with different hardware parts, our QA team identified an issue with kernel panic during read operations on the Areca ARC-1883 SAS RAID Adapter. We notified Areca and thanks to their fast reaction we were able to quickly resolve the problem. Here\u2019s an overview.<\/p>\n<p><strong>The problem<\/strong><\/p>\n<p>During sequential read operations kernel panic occurred on Linux. As it turned out, the newer the kernel version the faster the system would hang.<\/p>\n<p>Call trace from dying system:<\/p>\n<div style=\"border: #999999 1px solid; float: center; padding: 5px; margin: 2px; font-size: 11px; width: auto; overflow-x: scroll; text-align: left; margin-left: 15px;\"><code>BUG: unable to handle kernel paging request at ffff8800ffffffc8<br \/>\nIP: [&lt;ffffffffa01be89d&gt;] arcmsr_drain_donequeue+0xd\/0x70 [arcmsr]<br \/>\nPGD 1a86063 PUD 0<br \/>\nOops: 0000 [#1] SMP<br \/>\nlast sysfs file: \/sys\/devices\/pci0000:00\/0000:00:1d.0\/usb2\/2-1\/2-1.4\/speed<br \/>\nCPU 12<br \/>\nModules linked in: arcmsr(U) autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tab]<br \/>\nPid: 3576, comm: dd Not tainted 2.6.32-431.11.2.el6.x86_64 #1 Supermicro X9DRH-7TF\/7F\/iTF\/iF\/X9DRH-7TF\/7F\/iTF\/iF<br \/>\nRIP: 0010:[&lt;ffffffffa01be89d&gt;] \u00a0[&lt;ffffffffa01be89d&gt;] arcmsr_drain_donequeue+0xd\/0x70 [arcmsr]<br \/>\nRSP: 0018:ffff88089c483e38 \u00a0EFLAGS: 00010082<br \/>\nRAX: ffffc90016ea00c8 RBX: ffff8810731885e0 RCX: ffffc90016ea0020<br \/>\nRDX: 0000000000000001 RSI: ffff8800ffffffb0 RDI: ffff8810731885e0<br \/>\nRBP: ffff88089c483e48 R08: 0000000000000000 R09: 0000000000000000<br \/>\nR10: 0000000000000000 R11: 0000000000000000 R12: ffffc90016ea0030<br \/>\nR13: 0000000000000008 R14: 0000000000000010 R15: 0000000000000001<br \/>\nFS: \u00a000007f7f733e5700(0000) GS:ffff88089c480000(0000) knlGS:0000000000000000<br \/>\nCS: \u00a00010 DS: 0000 ES: 0000 CR0: 000000008005003b<br \/>\nCR2: ffff8800ffffffc8 CR3: 0000000f2b97c000 CR4: 00000000001407e0<br \/>\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br \/>\nDR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400<br \/>\nProcess dd (pid: 3576, threadinfo ffff8809c7172000, task ffff8810712b8ae0)<\/code><code>Stack:<br \/>\nffff88089c483e48 ffffffff81095628 ffff88089c483eb8 ffffffffa01beeff<br \/>\n&lt;d&gt; 0000000000000005 ffff88089c483e90 ffff88107318acd8 ffffc90016ea0020<br \/>\n&lt;d&gt; ffffc90016ea00c8 ffffc90016ea0030 0000000000000100 ffff88107026dc40<\/code><code>Call Trace:<br \/>\n&lt;IRQ&gt;<br \/>\n[&lt;ffffffff81095628&gt;] ? schedule_work+0x18\/0x20<br \/>\n[&lt;ffffffffa01beeff&gt;] arcmsr_interrupt+0x5ff\/0x6a0 [arcmsr]<br \/>\n[&lt;ffffffffa01befb1&gt;] arcmsr_do_interrupt+0x11\/0x20 [arcmsr]<br \/>\n[&lt;ffffffff810e6eb0&gt;] handle_IRQ_event+0x60\/0x170<br \/>\n[&lt;ffffffff8107a93f&gt;] ? __do_softirq+0x11f\/0x1e0<br \/>\n[&lt;ffffffff810e980e&gt;] handle_edge_irq+0xde\/0x180<br \/>\n[&lt;ffffffff8100c30c&gt;] ? call_softirq+0x1c\/0x30<br \/>\n[&lt;ffffffff8100faf9&gt;] handle_irq+0x49\/0xa0<br \/>\n[&lt;ffffffff815315fc&gt;] do_IRQ+0x6c\/0xf0<br \/>\n[&lt;ffffffff8100b9d3&gt;] ret_from_intr+0x0\/0x11<br \/>\n&lt;EOI&gt;<br \/>\n[&lt;ffffffff81136bc9&gt;] ? activate_page+0x189\/0x1a0<br \/>\n[&lt;ffffffff81136bb9&gt;] ? activate_page+0x179\/0x1a0<br \/>\n[&lt;ffffffff81136c21&gt;] mark_page_accessed+0x41\/0x50<br \/>\n[&lt;ffffffff811213c3&gt;] generic_file_aio_read+0x2c3\/0x700<br \/>\n[&lt;ffffffff811c4841&gt;] blkdev_aio_read+0x51\/0x80<br \/>\n[&lt;ffffffff81188e7c&gt;] ? do_sync_read+0xec\/0x140<br \/>\n[&lt;ffffffff81188e8a&gt;] do_sync_read+0xfa\/0x140<br \/>\n[&lt;ffffffff8109b290&gt;] ? autoremove_wake_function+0x0\/0x40<br \/>\n[&lt;ffffffff812334d6&gt;] ? selinux_file_permission+0x26\/0x150<br \/>\n[&lt;ffffffff812335ab&gt;] ? selinux_file_permission+0xfb\/0x150<br \/>\n[&lt;ffffffff81226496&gt;] ? security_file_permission+0x16\/0x20<br \/>\n[&lt;ffffffff81189775&gt;] vfs_read+0xb5\/0x1a0<br \/>\n[&lt;ffffffff811975bd&gt;] ? path_put+0x1d\/0x40<br \/>\n[&lt;ffffffff811898b1&gt;] sys_read+0x51\/0x90<br \/>\n[&lt;ffffffff810e1e4e&gt;] ? __audit_syscall_exit+0x25e\/0x290<br \/>\n[&lt;ffffffff8100b072&gt;] system_call_fastpath+0x16\/0x1b<\/code><code>Code: ff ff c6 02 00 48 8d 7a 01 40 b6 5f e9 5f ff ff ff 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 48 83 ec 10 0f 1f 44 00 00 &lt;4c&gt; 8b 46 18 49 39 f<br \/>\nRIP \u00a0[&lt;ffffffffa01be89d&gt;] arcmsr_drain_donequeue+0xd\/0x70 [arcmsr]<br \/>\nRSP &lt;ffff88089c483e38&gt;<br \/>\nCR2: ffff8800ffffffc8<\/code><\/div>\n<p>&nbsp;<\/p>\n<p>Preliminary tests showed that the same scenario performed with an older kernel works longer but finally provides the same results \u2013 kernel panic.<\/p>\n<p><strong>What was the solution?<\/strong><\/p>\n<p>Our development team researched the driver and immediately informed Areca about the part of the code where this issue occurred. The issue was caused by getting the wrong Command Control Block pointer value in \u00a0the arcmsr_hbaC_postqueue_isr function.<\/p>\n<p>In the arcmsr_hbaC_postqueue_isr function of the old driver:<\/p>\n<div style=\"border: #999999 1px solid; float: center; padding: 5px; margin: 2px; font-size: 11px; width: 450px; text-align: left; margin-left: 15px;\"><code>flag_ccb = readl(&amp;phbcmu-&gt;outbound_queueport_low);<\/code>ccb_cdb_phy = (flag_ccb &amp; 0xFFFFFFF0);\/*frame must be 32 bytes aligned*\/arcmsr_cdb = (struct ARCMSR_CDB *)(acb-&gt;vir2phy_offset + ccb_cdb_phy);ccb = container_of(arcmsr_cdb, struct CommandControlBlock, arcmsr_cdb); \u00a0\u00a0<strong>&lt;- ccb points to the wrong address<\/strong><\/div>\n<p>&nbsp;<\/p>\n<p>Upon Areca\u2019s request, our kernel developers also tested this scenario on different Linux systems (including Ubuntu and CentOS) and provided further information about the test results.<\/p>\n<p><strong>Devices affected<\/strong><\/p>\n<p>We tested other Areca Adapters, however, this behavior only occurred on the Areca ARC-1883 SAS RAID Adapter.<\/p>\n<p><strong>Operation System affected<\/strong><\/p>\n<p>All Linux-based systems that use the Areca driver in versions lower than 1.30.0X.18-140417 are affected.<\/p>\n<p><strong>What to do if you want to use <a href=\"https:\/\/www.open-e.com\/products\/data-storage-software-v7\/\" target=\"_blank\" rel=\"noopener\">Open-E DSS V7<\/a> with the Areca ARC-1883 SAS RAID Adapter?<\/strong><\/p>\n<p>Please contact our support team which already has a fix for this issue. Additionally, Areca prepared a driver which fixes the issue. [<a href=\"https:\/\/www.areca.com.tw\/support\/s_linux\/linux.htm\">https:\/\/www.areca.com.tw\/support\/s_linux\/linux.htm<\/a>]<\/p>\n<p>All in all, we have to say that we were impressed with Areca\u2019s technical support. They reacted very fast from the moment our QA team first reported the problem. Then, upon Areca\u2019s request &#8211; our team further investigated the issue. Once the problem was identified, our technology partner Areca quickly prepared a driver fixing the issue. Great job guys!\t\t<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Recently, when performing planned test scenarios with different hardware parts, our QA team identified an issue with kernel panic during read operations on the Areca ARC-1883 SAS RAID Adapter. We&nbsp;&#8230;<\/p>\n","protected":false},"author":11,"featured_media":45463,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[29,18],"tags":[64,68,226,361,362,374,466,523,579],"class_list":["post-39443","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-data-protection","category-hardware","tag-arc-1883","tag-areca","tag-drivers","tag-kernel","tag-kernel-panic","tag-linux","tag-open-e-dss-v7","tag-raid","tag-sas-raid-adapter"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/posts\/39443","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/users\/11"}],"replies":[{"embeddable":true,"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/comments?post=39443"}],"version-history":[{"count":1,"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/posts\/39443\/revisions"}],"predecessor-version":[{"id":55237,"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/posts\/39443\/revisions\/55237"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/media\/45463"}],"wp:attachment":[{"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/media?parent=39443"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/categories?post=39443"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/tags?post=39443"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}