September 13, 200718 yr Tom, I continue to have the dreaded dma_timer_expiry error and subsequent total system freeze as I have often spoke with you about. This only takes place on disk spin up and only on drive "e" despite the fact that I have changed EVERYTHING possible. The last change was to get a replacement drive from Seagate (yeah Seagate) and that has been in the tower now for about 2 weeks. Still the error.... I have changed IDE cable, the tray even the Promise card and still get the same error when the drive spins down and I attempt to wake it either by a normal access of that one disk or attempting a share re-scan. Here is the error, looks like all the others I think, any thoughts.... JUsNov 29 13:24:17 Tower emhttp[1289]: shcmd (24): killall -w smbd nmbd Nov 29 13:24:19 Tower emhttp[1289]: Scanning user shares... Nov 29 13:24:19 Tower emhttp[1289]: shcmd (25): rm -r /mnt/user/* 2>/dev/null Nov 29 13:25:02 Tower kernel: [ 7659.931925] hde: dma_timer_expiry: dma status = = 0x61 Nov 29 13:25:12 Tower kernel: [ 7669.912274] hde: DMA timeout error Nov 29 13:25:12 Tower kernel: [ 7669.912286] hde: dma timeout error: status=0x50 { DriveReady SeekComplete } Nov 29 13:25:12 Tower kernel: [ 7669.912291] ide: failed opcode was: unknown Nov 29 13:25:12 Tower kernel: [ 7670.065170] hde: task_in_intr: status=0x51 { Dr iveReady SeekComplete Error } Nov 29 13:25:12 Tower kernel: [ 7670.065179] hde: task_in_intr: error=0x04 { Dri veStatusError } Nov 29 13:25:12 Tower kernel: [ 7670.065183] ide: failed opcode was: unknown Nov 29 13:25:13 Tower kernel: [ 7670.218964] hde: task_in_intr: status=0x51 { Dr iveReady SeekComplete Error } Nov 29 13:25:13 Tower kernel: [ 7670.218971] hde: task_in_intr: error=0x04 { Dri veStatusError } Nov 29 13:25:13 Tower kernel: [ 7670.218975] ide: failed opcode was: unknown Nov 29 13:25:13 Tower kernel: [ 7670.372786] hde: task_in_intr: status=0x51 { Dr iveReady SeekComplete Error } Nov 29 13:25:13 Tower kernel: [ 7670.372794] hde: task_in_intr: error=0x04 { Dri veStatusError } Nov 29 13:25:13 Tower kernel: [ 7670.372798] ide: failed opcode was: unknown Nov 29 13:25:13 Tower kernel: [ 7670.526595] hde: task_in_intr: status=0x51 { Dr iveReady SeekComplete Error } Nov 29 13:25:13 Tower kernel: [ 7670.526602] hde: task_in_intr: error=0x04 { Dri veStatusError } Nov 29 13:25:13 Tower kernel: [ 7670.526606] ide: failed opcode was: unknown Nov 29 13:25:13 Tower kernel: [ 7670.526612] hdf: DMA disabled Nov 29 13:25:13 Tower kernel: [ 7670.526638] pdc202xx_new: Primary channel reset . Nov 29 13:25:13 Tower kernel: [ 7670.570973] ide2: reset: success Nov 29 13:25:33 Tower kernel: [ 7690.561609] hde: dma_timer_expiry: dma status = = 0x21
September 13, 200718 yr I had a similar problem with an older Maxtor drive, and had to give up on it. Hard drives have a standby mode and a sleep mode. It would appear that the attempt to spin the drive down and put it into standby mode, actually puts it into sleep mode, which is off, completely, and cannot be awakened. For me, it required a complete power off, not just a power down, before the drive would come back up. If I disabled spin down in unRAID, the drive performed OK. I believe the dma_timer_expiry and other errors are because the drive is totally off, and not responding. This of course forces a parity rebuild, on the next boot of unRAID, even though nothing is actually changed or bad in the data. It appears to me, in the case of your and my drives, to be bad firmware. Until I gave up on the drive, I turned off Spin down globally. I've been working on a post about a method of individual control of spin down. For now, if you add the line 'hdparm -S0 /dev/hda' to the bottom of your go script, it will disable spin down of just the hda drive. Change hda to the appropriate drive symbol for your system. 'Sleep' mode is wrongly labeled in my opinion. I think they should change it to 'disabled' mode, although after my experiences, I would prefer 'dead' mode.
September 13, 200718 yr Author Thanks Rob, I don't think however that in my case, after all I have done that it's a bad drive. First ALL 12 of my drives are the same Seagate 500GB deives and I have only hade this issue on disk 4 (5th drive and 1st on Promise card). I have replaced the drive with a new one, replaced the IDE cable with a new one, replaced the Promise card with a new one, and swapped the cage with the 12th drive. There is nothing left in my mind from the hardware side. I'm sure if I disable spin down it will be a bandaid as the problem only takes place when the drive is asked to spin up. But I really don't want that drive running 24x7.
September 13, 200718 yr Perhaps attempt change power connections such that, for example, disk3 and disk4 swap connectors. If the power connector is the issue, you would then start having issues with disk3. Bill
September 13, 200718 yr Author I will try the power connectors, great idea. Beacuse Tom said 4.2 had a better spin up routine I upgrade but no dice. I selected "spin down" on the web admin screen, then selected spin up and here is what I got....... Nov 29 19:56:14 Tower emhttp[1650]: spinup_disk: /dev/hda Nov 29 19:56:14 Tower emhttp[1651]: spinup_disk: /dev/hdb Nov 29 19:56:14 Tower emhttp[1652]: spinup_disk: /dev/hdc Nov 29 19:56:14 Tower emhttp[1653]: spinup_disk: /dev/hdd Nov 29 19:56:14 Tower emhttp[1654]: spinup_disk: /dev/hde Nov 29 19:56:14 Tower emhttp[1655]: spinup_disk: /dev/hdf Nov 29 19:56:14 Tower emhttp[1656]: spinup_disk: /dev/hdg Nov 29 19:56:14 Tower emhttp[1658]: spinup_disk: /dev/hdi Nov 29 19:56:14 Tower emhttp[1659]: spinup_disk: /dev/hdj Nov 29 19:56:14 Tower emhttp[1660]: spinup_disk: /dev/hdk Nov 29 19:56:14 Tower emhttp[1657]: spinup_disk: /dev/hdh Nov 29 19:56:14 Tower emhttp[1661]: spinup_disk: /dev/hdl Nov 29 19:56:34 Tower kernel: [ 618.138320] hde: dma_timer_expiry: dma status = = 0x61 Nov 29 19:56:44 Tower kernel: [ 628.118667] hde: DMA timeout error Nov 29 19:56:44 Tower kernel: [ 628.118678] hde: dma timeout error: status=0x50 { DriveReady SeekComplete } Nov 29 19:56:44 Tower kernel: [ 628.118684] ide: failed opcode was: unknown Nov 29 19:56:53 Tower kernel: [ 636.505382] hde: task_in_intr: status=0x51 { Dr iveReady SeekComplete Error } Nov 29 19:56:53 Tower kernel: [ 636.505392] hde: task_in_intr: error=0x04 { Dri veStatusError } Nov 29 19:56:53 Tower kernel: [ 636.505396] ide: failed opcode was: unknown Nov 29 19:56:53 Tower kernel: [ 636.659175] hde: task_in_intr: status=0x51 { Dr iveReady SeekComplete Error } Nov 29 19:56:53 Tower kernel: [ 636.659183] hde: task_in_intr: error=0x04 { Dri veStatusError } Nov 29 19:56:53 Tower kernel: [ 636.659186] ide: failed opcode was: unknown Nov 29 19:56:53 Tower kernel: [ 636.812997] hde: task_in_intr: status=0x51 { Dr iveReady SeekComplete Error } Nov 29 19:56:53 Tower kernel: [ 636.813004] hde: task_in_intr: error=0x04 { Dri veStatusError } Nov 29 19:56:53 Tower kernel: [ 636.813008] ide: failed opcode was: unknown Nov 29 19:56:53 Tower kernel: [ 636.966818] hde: task_in_intr: status=0x51 { Dr iveReady SeekComplete Error } Nov 29 19:56:53 Tower kernel: [ 636.966826] hde: task_in_intr: error=0x04 { Dri veStatusError } Nov 29 19:56:53 Tower kernel: [ 636.966829] ide: failed opcode was: unknown Nov 29 19:56:53 Tower kernel: [ 636.966836] hdf: DMA disabled Nov 29 19:56:53 Tower kernel: [ 636.966863] pdc202xx_new: Primary channel reset . Nov 29 19:56:53 Tower kernel: [ 637.011154] ide2: reset: success At this point (as before) the tower is dead and the two yellow lights on that IDE chain are lit solid.
September 14, 200718 yr I believe you may have misinterpreted Tom's statement about improvement in the method for spinning up the drives. It's my understanding that he is just using standard calls to the Linux drivers and Linux tools like hdparm to control spindown and spinup, and that what he meant was that he had found a better, more reliable way of accessing the drives to force them to spin up. In your case, the drive is not communicating once it spins down, and no amount of commands or methods can work until the drive is rebooted, electrically reset. A DMA timeout means a command was sent, but there was no response in a reasonable amount of time, so the drive is effectively the same as if it was turned off. I probably wasn't clear enough that you CANNOT let the drive spin down. Now it may not be the drive's fault, since you isolated it down to a problem with the first connector on your Promise card. Perhaps the firmware on that Promise card is faulty? I would check for an update. You can also swap the data cable with another drive, and check whether the suspect drive spins down and up on the other connector. If it does, then you can assume the Promise card is at fault.
September 14, 200718 yr Richard, You might try the commands mentioned in this thread to turn off the seagate power saving mode on that drive and make it persistent across power cycles. The post I found is here: http://forums.storagereview.net/index.php?showtopic=19970 The commands seem you might want to try are: hdparm -Z /dev/hde hdparm -B 255 /dev/hde hdparm -k1 /dev/hde hdparm -K1 /dev/hde Joe L.
September 14, 200718 yr Author Thanks Joe, but when I run these commands I get an Input/Output error like this. root@Tower:~# hdparm -Z /dev/hde /dev/hde: disabling Seagate auto powersaving mode HDIO_DRIVE_CMD(seagatepwrsave) failed: Input/output error root@Tower:~# hdparm -B 255 /dev/hde /dev/hde: setting Advanced Power Management level to disabled HDIO_DRIVE_CMD failed: Input/output error And see this in the syslog... Nov 30 11:18:59 Tower kernel: [54958.779608] hde: drive_cmd: status=0x51 { Drive Ready SeekComplete Error } Nov 30 11:18:59 Tower kernel: [54958.779617] hde: drive_cmd: error=0x04 { DriveS tatusError } Nov 30 11:18:59 Tower kernel: [54958.779622] ide: failed opcode was: 0xfb Nov 30 11:19:32 Tower kernel: [54991.253946] hde: drive_cmd: status=0x51 { Drive Ready SeekComplete Error } Nov 30 11:19:32 Tower kernel: [54991.253956] hde: drive_cmd: error=0x04 { DriveS tatusError } Nov 30 11:19:32 Tower kernel: [54991.253960] ide: failed opcode was: 0xef
September 14, 200718 yr On the face of it, looks like a bad drive. But, tell me if this is true: 1. Everything works ok for normal read/write, just spin up/down fails. 2. If you swap this drive with another drive, the same disk slot fails (/dev/hde) - so problem does not follow drive, it stays with slot. 3. If you replace mobile rack, cable, and promise controller, problem persists.
September 14, 200718 yr On the face of it, looks like a bad drive. But, tell me if this is true: 1. Everything works ok for normal read/write, just spin up/down fails. 2. If you swap this drive with another drive, the same disk slot fails (/dev/hde) - so problem does not follow drive, it stays with slot. 3. If you replace mobile rack, cable, and promise controller, problem persists. It sounds as if the drive works until it spins down, then it stops working. According to this quote, it is a new drive and the controller, cable, tray, etc have also been changed: The last change was to get a replacement drive from Seagate (yeah Seagate) and that has been in the tower now for about 2 weeks. Still the error.... I have changed IDE cable, the tray, even the Promise card and still get the same error when the drive spins down and I attempt to wake it either by a normal access of that one disk or attempting a share re-scan. Richard will need to answer your #2 question. Could he have gotten a replacement drive with exactly the same problem? Or, is it some setting (in firmware) on the drive that causes it to go into a deep sleep and not awaken when requested?
September 14, 200718 yr Nothing I'm aware of in drive firmware would cause to behave this way. My previous post was just to make sure I was on the same exact page as he is regarding h/w, what's been changed, and what hasn't.
September 14, 200718 yr Author I have not yet attempted #2 exactly, I did replace the suspect drive hde with a brand new one that Seagate sent me as a replacement for what I thought (based on my tests) to be a bad drive. But even after then new drive was installed I got (and get) the same error. I will do a drive swap of disk#4 and disk#8 and see if the problem follows the drive or stays with hde, stay tuned.
September 14, 200718 yr Author OK I did the swap mentioned above and the problem did NOT follow the drive but stayed with hde. So with this swap there have been 3 cages in this slot, 3 drives, 2 promise cards and 2 IDE cables yet the problem is still there. I'm lost......
September 14, 200718 yr OK I did the swap mentioned above and the problem did NOT follow the drive but stayed with hde. So with this swap there have been 3 cages in this slot, 3 drives, 2 promise cards and 2 IDE cables yet the problem is still there. I'm lost...... Power connection at that slot or the motherboard. Bill
September 14, 200718 yr OK I did the swap mentioned above and the problem did NOT follow the drive but stayed with hde. So with this swap there have been 3 cages in this slot, 3 drives, 2 promise cards and 2 IDE cables yet the problem is still there. I'm lost...... Two more things to try: 1. The Intel D865GLCLK motherboard has 3 PCI slots. Let's number them 1, 2, 3, where 1 is closest to the CPU. You probably have the cards plugged into slots 1 and 2. Try moving them to slots 2 and 3. 2. From telnet console, please type this command: cat /proc/interrupts You should see output that looks like this: CPU0 0: 19870735 XT-PIC-XT timer 1: 2 XT-PIC-XT i8042 2: 0 XT-PIC-XT cascade 3: 0 XT-PIC-XT uhci_hcd:usb3 5: 170674 XT-PIC-XT uhci_hcd:usb4, eth0 7: 1856 XT-PIC-XT ide4, ide5 8: 1 XT-PIC-XT rtc 9: 888 XT-PIC-XT acpi, ehci_hcd:usb1 10: 4557 XT-PIC-XT ide2, ide3 11: 0 XT-PIC-XT uhci_hcd:usb2, uhci_hcd:usb5 12: 5 XT-PIC-XT i8042 14: 2146 XT-PIC-XT ide0 15: 679 XT-PIC-XT ide1 NMI: 0 ERR: 0 Please post what your output is.
September 15, 200718 yr Author Will move the promise cards later today and report back, here is the printout you requested. root@Tower:~# cat /proc/interrupts CPU0 0: 6584591 XT-PIC-XT timer 1: 2 XT-PIC-XT i8042 2: 0 XT-PIC-XT cascade 3: 7219 XT-PIC-XT ide4, ide5 5: 0 XT-PIC-XT uhci_hcd:usb3 6: 3 XT-PIC-XT floppy 8: 1 XT-PIC-XT rtc 9: 229 XT-PIC-XT acpi, ehci_hcd:usb1 10: 1795840 XT-PIC-XT uhci_hcd:usb4, libata, eth0 11: 36577 XT-PIC-XT uhci_hcd:usb2, uhci_hcd:usb5, ide2, ide3 12: 5 XT-PIC-XT i8042 14: 10228 XT-PIC-XT ide0 15: 3567 XT-PIC-XT ide1 NMI: 0 ERR: 15720
September 16, 200718 yr It has been a while since I had to deal with interrupt conflicts, but how about trying moving your USB key to a different USB port. If indeed the interrupt for the USB is conflicting with the drive, that would either fix the problem or make it show up in a different drive. Bill
September 24, 200718 yr Author Turns out that I'm not able to do the slot swap at all :'( My two Promise cards were in the 2 & 3 slots, what I found was that whatever card I put in slot 1 the four drives on that card would come up missing. I did a number of card swaps and crossing of cards but again whatever drives were served off slot 1 would come up missing. I now have both cards back in slots 2 & 3 but have them swapped from the original design where the card in slot 2 is serving the last four drives and the card in slot 3 is serving the middle set. Not sure what that may or may not tell me but I will report what I see.
September 24, 200718 yr My two Promise cards were in the 2 & 3 slots, what I found was that whatever card I put in slot 1 the four drives on that card would come up missing. That makes sense because the PCI assignment is different. What you have to do after changing PCI slots is go to the Device page of the System Management Utility and re-assign the devices to the correct slots. To make sure all each hard drive is assigned correctly, I suggest you first jot down the last few chars of each hard drive's serial number, and which disk (or parity) it's assigned to. Then power down, re-arrange PCI cards as desired, and when system boots back up, go to Devices page and re-assign the hard drives.
September 25, 200718 yr Author This is getting stranger all the time.... Thanks Tom I forgot about the assignment requirement. So I moved both cards up one slot (2-1 and 3-2) re-set all device assignments and so far so good. Now all four drives on the first Promise card (hde - hdh) will no longer auto spin down but ALL other drives do. I can click the "spin down" button and they then show as down but it's only when they spin down on their own that the spin up causes the dma error. In other words I can click the "spin down" button and then the "spin up" button all day long and never get the dma_timer error, but when they spin down auto the "spin up" button (or normal access to hde) will then cause the dma error. UPDATE - Drives hde - hdh have now been spun up for a day and a half, all other drives are down.....
October 1, 200718 yr Author UPDATE - Drives hde - hdh have now been spun up for a day and a half, all other drives are down..... Any help........
October 1, 200718 yr I'm not clear as to where the Promise cards ended up. Just to confirm, you have them in slots 2 & 3, and you are still getting these compatibility problems?
October 1, 200718 yr Author I'm not clear as to where the Promise cards ended up. Just to confirm, you have them in slots 2 & 3, and you are still getting these compatibility problems? Sorry that was a little confusing I guess. Right now the two cards are in slots 1&2 and it's the Promise card in slot 1 that will no longer spin down automatically. Since I have put it into this configuration I have NOT have the DMA error but that's because hde will not auto spin down. I can click the spin down button and it shows as down but I never get the DMA error unless the spin down on their own. This non-spin down condition is something I have never seen before.
Archived
This topic is now archived and is closed to further replies.