November 12, 201114 yr Please forgive the length of this post in advance, but I really want to be as specific as possible in hopes of getting some assistance. I’m having a problem that I’ve spent a great deal of time running down and have reached what seems like a bizarre conclusion. I’m hoping someone with more hardware expertise than me can interpret the error messages in the log below, and/or confirm or refute the conclusion I’ve tentatively reached. I am running unRAID 4.7. Here’s what I’m observing. When I attempt a preclear from any hard drive attached to my Supermicro AOC-SASLP-MV8 8-Port card, I get a series of errors that show up in the syslog. Here is the relevant portion (the entire syslog is also attached.) Nov 11 14:59:19 Tower kernel: WARNING: at drivers/ata/libata-core.c:5186 ata_qc_issue+0x10b/0x308() Nov 11 14:59:19 Tower kernel: Hardware name: GA-MA785G-UD3H Nov 11 14:59:19 Tower kernel: Modules linked in: ntfs md_mod xor atiixp ahci r8169 sata_sil24 mvsas libsas scst scsi_transport_sas Nov 11 14:59:19 Tower kernel: Pid: 2724, comm: smartctl Not tainted 2.6.32.9-unRAID #8 Nov 11 14:59:19 Tower kernel: Call Trace: Nov 11 14:59:19 Tower kernel: [<c102449e>] warn_slowpath_common+0x60/0x77 Nov 11 14:59:19 Tower kernel: [<c10244c2>] warn_slowpath_null+0xd/0x10 Nov 11 14:59:19 Tower kernel: [<c11b624d>] ata_qc_issue+0x10b/0x308 Nov 11 14:59:19 Tower kernel: [<c11ac0ba>] ? scsi_init_sgtable+0x5b/0x76 Nov 11 14:59:19 Tower kernel: [<c11ba260>] ata_scsi_translate+0xd1/0xff Nov 11 14:59:19 Tower kernel: [<c11a816c>] ? scsi_done+0x0/0xd Nov 11 14:59:19 Tower kernel: [<c11a816c>] ? scsi_done+0x0/0xd Nov 11 14:59:19 Tower kernel: [<c11baa40>] ata_sas_queuecmd+0x120/0x1d7 Nov 11 14:59:19 Tower kernel: [<c11bc6df>] ? ata_scsi_pass_thru+0x0/0x21d Nov 11 14:59:19 Tower kernel: [<f843069a>] sas_queuecommand+0x65/0x20d [libsas] Nov 11 14:59:19 Tower kernel: [<c11a816c>] ? scsi_done+0x0/0xd Nov 11 14:59:19 Tower kernel: [<c11a82c0>] scsi_dispatch_cmd+0x147/0x181 Nov 11 14:59:19 Tower kernel: [<c11ace4d>] scsi_request_fn+0x351/0x376 Nov 11 14:59:19 Tower kernel: [<c1126798>] __blk_run_queue+0x78/0x10c Nov 11 14:59:19 Tower kernel: [<c1124446>] elv_insert+0x67/0x153 Nov 11 14:59:19 Tower kernel: [<c11245b8>] __elv_add_request+0x86/0x8b Nov 11 14:59:19 Tower kernel: [<c1129343>] blk_execute_rq_nowait+0x4f/0x73 Nov 11 14:59:19 Tower kernel: [<c11293dc>] blk_execute_rq+0x75/0x91 Nov 11 14:59:19 Tower kernel: [<c11292cc>] ? blk_end_sync_rq+0x0/0x28 Nov 11 14:59:19 Tower kernel: [<c11295fa>] ? blk_recount_segments+0x16/0x24 Nov 11 14:59:19 Tower kernel: [<c11250c6>] ? blk_rq_bio_prep+0x47/0x78 Nov 11 14:59:19 Tower kernel: [<c1128edb>] ? blk_rq_append_bio+0x14/0x3b Nov 11 14:59:19 Tower kernel: [<c1129121>] ? blk_rq_map_user+0x12c/0x1be Nov 11 14:59:19 Tower kernel: [<c112c2bf>] sg_io+0x22d/0x30a Nov 11 14:59:19 Tower kernel: [<c112c5a8>] scsi_cmd_ioctl+0x20c/0x3bc Nov 11 14:59:19 Tower kernel: [<c104cbfe>] ? get_page_from_freelist+0x2e4/0x344 Nov 11 14:59:19 Tower kernel: [<c11b3257>] sd_ioctl+0x6a/0x8c Nov 11 14:59:19 Tower kernel: [<c112a420>] __blkdev_driver_ioctl+0x50/0x62 Nov 11 14:59:19 Tower kernel: [<c112ad1c>] blkdev_ioctl+0x8b0/0x8dc Nov 11 14:59:19 Tower kernel: [<c1131e2d>] ? kobject_get+0x12/0x17 Nov 11 14:59:19 Tower kernel: [<c112b0f8>] ? get_disk+0x4a/0x61 Nov 11 14:59:19 Tower kernel: [<c1131e2d>] ? kobject_get+0x12/0x17 Nov 11 14:59:19 Tower kernel: [<c1131e2d>] ? kobject_get+0x12/0x17 Nov 11 14:59:19 Tower kernel: [<c1192208>] ? get_device+0x11/0x18 Nov 11 14:59:19 Tower kernel: [<c11334a5>] ? radix_tree_lookup_slot+0xd/0xf Nov 11 14:59:19 Tower kernel: [<c104a179>] ? filemap_fault+0xb8/0x305 Nov 11 14:59:19 Tower kernel: [<c1048c43>] ? unlock_page+0x18/0x1b Nov 11 14:59:19 Tower kernel: [<c1057c63>] ? __do_fault+0x3a7/0x3da Nov 11 14:59:19 Tower kernel: [<c10757d4>] ? do_filp_open+0x3d8/0x6d1 Nov 11 14:59:19 Tower kernel: [<c105985f>] ? handle_mm_fault+0x42d/0x8f1 Nov 11 14:59:19 Tower kernel: [<c108b6c6>] block_ioctl+0x2a/0x32 Nov 11 14:59:19 Tower kernel: [<c108b69c>] ? block_ioctl+0x0/0x32 Nov 11 14:59:19 Tower kernel: [<c10769d5>] vfs_ioctl+0x22/0x67 Nov 11 14:59:19 Tower kernel: [<c1076f33>] do_vfs_ioctl+0x478/0x4ac Nov 11 14:59:19 Tower kernel: [<c106afbf>] ? fd_install+0x1e/0x43 Nov 11 14:59:19 Tower kernel: [<c1075b02>] ? set_close_on_exec+0x1e/0x38 Nov 11 14:59:19 Tower kernel: [<c1076030>] ? do_fcntl+0x139/0x390 Nov 11 14:59:19 Tower kernel: [<c1076f93>] sys_ioctl+0x2c/0x45 Nov 11 14:59:19 Tower kernel: [<c1002935>] syscall_call+0x7/0xb Nov 11 14:59:19 Tower kernel: ---[ end trace 7d928b44146141be ]--- Here are the components of my system: Motherboard: Gigabyte GA-MA785G-UD3H CPU: AMD Athlon II X2 240 Regor 2.8 GHz PSU: CORSAIR CMPSU-750HX RAM: A-DATA 2GB (2 x 1GB) 240-Pin DDR2 SDRAM DDR2 800 Cages (3): Athena Power BP-SATA3051B SATA Controller: Supermicro AOC-SASLP-MV8 8-Port SAS/SATA SATA Controller: SATA2 Serial ATA II PCI-Express RAID Controller (SIL3132) SAS Breakout Cable (2): LSI/3Ware CBL-SFF8087OCF-10M SFF-8087 to Discrete Forward Breakout This hardware had been running WHS for well over a year without problem when I had a disk fail on me. I had been checking out unRAID and decided it was time to move to a system with some redundancy rather than one that gave me a choice of nothing or total replication. I started noticing the problem when I had a preclear operation fail during the zeroing stage. This after a bunch of preclear operations that were successful (at least by result, since all seemed well and I didn’t think of checking the syslog) In one recent case the errors didn’t appear in the syslog until the second phase of the preclear operation. I allowed the preclear operation to continue. It completed successfully. But almost all the time these errors appear as soon as I enter the preclear command and before confirming that I want to proceed. It’s possible that preclear operations would still be successful if I ignored these errors but I don’t see the point in continuing and courting disaster down the road. After much investigation and trouble-shooting I’ve ruled out all of the following: - The hard drive: it happens regardless of which hard drive I use, and drives that fail when attached to the Supermicro card don’t have any problems when attached to motherboard SATA ports or SIL3132 ports. - The Athena cages: it happens regardless of which cage the drive is inserted into, and all three cages work when attached to motherboard SATA ports or the SIL3132 ports. - The disk tray: changing the disk tray doesn’t solve the problem, and the same tray that fails when connected to the Supermicro port works when connected to motherboard SATA ports or SIL3132 ports. - The breakout cables: unless it is both cables (seems unlikely) since it happens regardless of whether it’s connected to SAS1 or SAS2. - The Supermicro card: I purchased a new card and replaced the old one. It didn’t solve anything. -The PCIEX4 port: I removed the card and inserted into the PCIEX16 port. It didn’t make a difference. - The PSU: Don’t know if this is definitive, but the problem still happens even when I unload all the drives and attempt to preclear with just a single drive mounted. I had almost come to the conclusion that it must be the motherboard, though troubleshooting logic aside, that seemed very unlikely. The system is working in all other regards, and had been working for quite a while before switching to unRAID. In one last attempt to troubleshoot I removed one of the SATA connectors on the breakout cable from the Athena cage, put in an old SATA to eSATA bracket I had, and attached that SATA connector to the bracket. I then attached a Thermaltake dock I use on my PC to the eSATA port. Thus creating a connection between the Supermicro card and an external drive in the Thermaltake dock. I started a preclear operation and it reported no problems at the place where the errors typically occur, thus seemingly definitively clearing the Supermicro card of being defective. The implication, as far as I can see, is that somehow, the Supermicro card doesn’t like the Athena Power BP-SATA3051B cages. I’ve been running fine with these cages and this card on WHS (at least as far as I could tell under WHS). Thinking it might be a power issue, and not knowing whether or not adding a third power connector to the cage (only two are typically required) might make a difference, I added a third one to the cage. It didn’t make a difference. Before I go ahead and order a different cage to see if that solves the problem, has anyone encountered similar problems. I note some complaints on the forum with the Athena cages but nothing that sounds like the problem I’m having. Is my logic flawed? Is there something I should try before tearing everything apart and installing new backplanes? Should I just go ahead and ignore these error messages, since it would appear likely that allowing the preclear operation to proceed might yield success? Any suggestions or feedback would be much appreciated here. Thanks. syslog-2011-11-11.txt
Archived
This topic is now archived and is closed to further replies.