September 14, 200619 yr Author Tom, Will give it a go. Hopefully.... this is a powersupply issue. If disk4 passes with no problem alone in the system, I am going to hook up my other computers P/S and fire it up and see what I get. I am also going to check to see if I might have another bad rack unit!!!!!!! UGH!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
September 14, 200619 yr I suggest taking it a little slower just to decrease the overall potential frutration level. Right now you know for sure that with a full-up system, disk4 is flaky. Don't know if it's the disk, mobile rack, controller, cable, power supply, phase of the moon... So, isolate disk4. Remove all drives BUT disk4 and see if it still fails. If it DOES, then next step is to move it to another slot to see if it's the controller/cable. If it DOES NOT fail, next step is to just sloooowly add drives. I'd probably add disk5 first cuz it's on the same cable. You get the idea. If disk4 fails and you go to all the effort to tear apart your system to replace the p/s, and it ends up STILL failing, then you're liable to kick the dog - and we can't have that
September 14, 200619 yr Teamhood, I know exactly the frustration you are feeling. I went through it for the first 3 months I owned my UnRaid. I'm rooting for you to win this fight, but I always root for the under-dog
September 15, 200619 yr Author WELLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL, son of a bee with an itch /disk4 on PS1 with no other /disks on the PS... NO PROBLEM. I GUESS WE ARE LOOKING AT A POWER SUPPLY PROBLEM HERE!!!!!!!!!!!!!! UGH Time to take out the beefy 550 out of my HTPC I will report results
September 15, 200619 yr Author Teamhood, I know exactly the frustration you are feeling. I went through it for the first 3 months I owned my UnRaid. I'm rooting for you to win this fight, but I always root for the under-dog Thank you for the kind words. I hope to win this battle as well. I have invested, so if this power supply isn't the problem I FedExing this damn thing to Tom and have him school this POS Now I just need to break it down some more. I really can't believe this is a PS issue... SO WHAT POWER SUPPLY SHOULD I BUY THAT IS GOOD?!?!!?!?!?!? I might as well make it silent as well.. I really like the one in my HTPC, doesn't make a sound
September 15, 200619 yr WELLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL, son of a bee with an itch /disk4 on PS1 with no other /disks on the PS... NO PROBLEM. I GUESS WE ARE LOOKING AT A POWER SUPPLY PROBLEM HERE!!!!!!!!!!!!!! UGH Time to take out the beefy 550 out of my HTPC I will report results Again.. I wouldn't be so fast to do that. At least add disk5 (the same one that was disk5 before you isolated disk4). Now you have just disk4 and disk5, both on the same controller & cable. Test again. It's possible that disk5 is actually the bad one - perhaps doing something it shouldn't be when disk4 is active. For example, it could be glitching a data line - that's why is important to go slow in trying to isolate FOR SURE what the problem is.
September 15, 200619 yr Author firing the server back up with disk4 and disk5 on no problem copying 300 meg to disk4 or disk5
September 15, 200619 yr disk 5, it copied but was slow as hell. also i see that disk6 and disk7's LED's are pinged??! why the hell is that? disk4 exactly the same thing. why is it that disk4 or disk5 those LEDs don't light up at all, but disk6 and disk7 are lighting up while copying data over to disk4 or 5? These are currently on the bottom PS, I am going to put them on the first PS I think Tom mentioned once before that the lights on the drive trays flash when either of the drives on that cable are active, so you would expect to see two drive LEDs flashing. On the other hand, if the drive trays are lighting up when not on the same cable and not being read/written to, it might indicate a different possible cause of drive interaction you are not seeing when only one drive is installed.
September 15, 200619 yr Author Joe L. I think that it might have something to do with the power.. That is odd though that when copying to disk 4 and 5 (which is on one IDE cable) 6 and 7 were lighting up. So, I am hoping that this is all is power supply related. Tom, what do you think I should do next? Throw in my larger power supply and start testing from there? Thank you, Mike
September 15, 200619 yr When you access disk4 or disk5, both of their LED's should blink because they're on the same cable (limitation of IDE). Now put in disk6 and disk7 (along with disk4 and disk5). Now you have all four devices of the same Promise controller attached. Run your transfer tests. If, from what I think I read above, in this configuration you access disk4 and the LED's for disk6/disk7 blink, then that would be very strange - I've never seen that before - and my first guess would be bad Promise controller. I would physically swap the two Promise controllers and see if it still happens.
September 15, 200619 yr Author When you access disk4 or disk5, both of their LED's should blink because they're on the same cable (limitation of IDE). Now put in disk6 and disk7 (along with disk4 and disk5). Now you have all four devices of the same Promise controller attached. Run your transfer tests. If, from what I think I read above, in this configuration you access disk4 and the LED's for disk6/disk7 blink, then that would be very strange - I've never seen that before - and my first guess would be bad Promise controller. I would physically swap the two Promise controllers and see if it still happens. i i captain
September 16, 200619 yr Author Tom. Alright I put /disk4,5,6,7 all on PS1 and copied data. I ran into errors when I copied to disk6... which is interesting... here is the log Sep 15 17:13:37 Tower kernel: hdl: dma_timer_expiry: dma status == 0x60 Sep 15 17:13:37 Tower kernel: hdl: timeout waiting for DMA Sep 15 17:13:37 Tower kernel: PDC202XX: Secondary channel reset. Sep 15 17:13:37 Tower kernel: hdl: timeout waiting for DMA Sep 15 17:13:37 Tower kernel: hdl: (__ide_dma_test_irq) called while not waiting Sep 15 17:13:37 Tower kernel: hdl: status error: status=0x58 { DriveReady SeekCo mplete DataRequest } Sep 15 17:13:37 Tower kernel: Sep 15 17:13:37 Tower kernel: hdl: drive not ready for command Sep 15 17:13:37 Tower kernel: hdl: status timeout: status=0xd1 { Busy } Sep 15 17:13:37 Tower kernel: Sep 15 17:13:37 Tower kernel: PDC202XX: Secondary channel reset. Sep 15 17:13:37 Tower kernel: hdl: drive not ready for command Sep 15 17:13:37 Tower kernel: ide5: reset: success Sep 15 17:15:45 Tower smbd[924]: [2006/09/15 17:15:45, 0] lib/util_sock.c:read_s ocket_data(384) Sep 15 17:15:45 Tower smbd[924]: read_socket_data: recv failure for 4. Error = Connection reset by peer Isn't hdl really suppose to be disk7?? I don't know what the heck is going on because when I put /disk1,2,3,4 all on PS1 I don't have a problem at all. I am going to pull/disk6 out of the mobile rack and connect directly into the promise card and see what the hell happens right now
September 16, 200619 yr I think you're getting closer! '/dev/hdl' is disk7 in your config & by writing to disk6 you get errors reported by disk7 ?? Bad disk6, disk7, or controller card. I'd maybe put a different disk as disk7 and see what happens. Now.. this does remind me of something we saw once. We have a drive here which causes problems only when used as a Slave on a Promise controller (heh, sound familiar?). I think I have the dumb thing in my own home server - I just put it in a Master slot.
September 16, 200619 yr Author Tom, So check this... I removed /disk6 disk7 and disk9 from their mobile rack units. I then brought 1 HD online at a time and repeated my process of pushing 300 meg over to all the drive. I have NO PROBLEMS AT ALL with disk1 through disk 9 copying over files.... So I guess maybe I got a bunch of bad mobile racks... or my power supply can't handle the racks with the hard drives in them... so where should I go from here? I would like to bring parity back online, so should I start server, and do that dd command which has the super.dat file or whatever on it? and then rebuild parity?? Or what do you think??
September 16, 200619 yr Are you running 3.0-beta1 ? You only really need to create the 'super.dat' file if you are trying to preserve parity (so that you don't have to rebuild parity). This is only a precaution in case a drive decides to fail right when you're doing the parity-sync.
September 16, 200619 yr Author Tom, Well, I rebuilt parity with no problem last night. I know that the speeds were going rather quickly as well. So, this brings up the next question. Do you think that the problem is indeed with the rack units? If so, did I just receive 4 faulty units, or do you think that it might be an issue with the power supply? And I have a question about the second power supply. As you know, to be able to use the second power supply without plugging the one part into the MOBO you have to short two of the pins. I did this using a wire and putting electrical tape to make sure that wire didn't move. Do you think that this could be a problem? How do you short the second power supply? I was thinking about trying out a larger power supply and see if that would allow the rack units to work properly! Thank you for the help.... also no, I am not on 3.0beta yet.... I am thinking about messing around with that this weekend, but it seems my dogs really, really want to goto the dog park today and I have about 100 different things to do. Also, I plan on trying unRAID on that Asus P5GDC-V Deluxe MOBO and let you know how that goes. Thank you, Mike
September 16, 200619 yr Author Well, I don't think it is just the drive trays. I tried to copy data from /disk4 to /disk7 and I received errors. Sep 16 09:57:42 Tower kernel: hdl: dma_timer_expiry: dma status == 0x40 Sep 16 09:57:42 Tower kernel: hdl: timeout waiting for DMA Sep 16 09:57:42 Tower kernel: PDC202XX: Secondary channel reset. Sep 16 09:57:42 Tower kernel: hdl: timeout waiting for DMA Sep 16 09:57:42 Tower kernel: hdl: (__ide_dma_test_irq) called while not waiting Sep 16 09:57:42 Tower kernel: hdl: status error: status=0x58 { DriveReady SeekCo mplete DataRequest } Sep 16 09:57:42 Tower kernel: Sep 16 09:57:42 Tower kernel: hdl: drive not ready for command Sep 16 09:57:42 Tower kernel: hdk: status timeout: status=0xd1 { Busy } Sep 16 09:57:42 Tower kernel: Sep 16 09:57:42 Tower kernel: hdk: drive not ready for command Sep 16 09:57:42 Tower kernel: hdl: status timeout: status=0xd0 { Busy } Sep 16 09:57:42 Tower kernel: Sep 16 09:57:42 Tower kernel: PDC202XX: Secondary channel reset. Sep 16 09:57:42 Tower kernel: hdl: no DRQ after issuing WRITE Sep 16 09:57:42 Tower kernel: ide5: reset: success Sep 16 09:57:50 Tower smbd[953]: [2006/09/16 09:57:50, 0] smbd/oplock.c:oplock_b reak(830) Sep 16 09:57:50 Tower smbd[953]: oplock_break: end of file from client Sep 16 09:57:50 Tower smbd[953]: oplock_break failed for file Final Cut Studio Complete NOT UB/Apple Loops for Soundtrack Pro.toast (dev = 907, inode = 4, fil e_id = 2447). Sep 16 09:57:50 Tower smbd[953]: [2006/09/16 09:57:50, 0] smbd/oplock.c:oplock_b reak(923) Sep 16 09:57:50 Tower smbd[953]: oplock_break: client failure in break - shutt ing down this smbd. Sep 16 09:58:11 Tower smbd[1022]: [2006/09/16 09:58:11, 0] smbd/oplock.c:request _oplock_break(1055) Sep 16 09:58:11 Tower smbd[1022]: request_oplock_break: no response received t o oplock break request to pid 953 on port 32769 for dev = 907, inode = 4, file_i d = 2447 Also, while the array was just idle and I was @ the dog park these pesky errors came back: Sep 16 09:57:39 Tower smbd[1021]: [2006/09/16 09:57:39, 0] lib/util_sock.c:get_p eer_addr(1000) Sep 16 09:57:39 Tower smbd[1021]: getpeername failed. Error was Transport endp oint is not connected Sep 16 09:57:39 Tower smbd[1021]: [2006/09/16 09:57:39, 0] lib/util_sock.c:get_p eer_addr(1000) Sep 16 09:57:39 Tower smbd[1021]: getpeername failed. Error was Transport endp oint is not connected Sep 16 09:57:39 Tower smbd[1021]: [2006/09/16 09:57:39, 0] lib/util_sock.c:write _socket_data(430) Sep 16 09:57:39 Tower smbd[1021]: write_socket_data: write failure. Error = Co nnection reset by peer Sep 16 09:57:39 Tower smbd[1021]: [2006/09/16 09:57:39, 0] lib/util_sock.c:write _socket(455) Sep 16 09:57:39 Tower smbd[1021]: write_socket: Error writing 4 bytes to socke t 5: ERRNO = Connection reset by peer Sep 16 09:57:39 Tower smbd[1021]: [2006/09/16 09:57:39, 0] lib/util_sock.c:send_ smb(647) Sep 16 09:57:39 Tower smbd[1021]: Error writing 4 bytes to client. -1. (Connec tion reset by peer)
September 16, 200619 yr Tom, Well, I rebuilt parity with no problem last night. I know that the speeds were going rather quickly as well. So, this brings up the next question. Do you think that the problem is indeed with the rack units? If so, did I just receive 4 faulty units, or do you think that it might be an issue with the power supply? And I have a question about the second power supply. As you know, to be able to use the second power supply without plugging the one part into the MOBO you have to short two of the pins. I did this using a wire and putting electrical tape to make sure that wire didn't move. Do you think that this could be a problem? How do you short the second power supply? I was thinking about trying out a larger power supply and see if that would allow the rack units to work properly! Thank you for the help.... also no, I am not on 3.0beta yet.... I am thinking about messing around with that this weekend, but it seems my dogs really, really want to goto the dog park today and I have about 100 different things to do. Also, I plan on trying unRAID on that Asus P5GDC-V Deluxe MOBO and let you know how that goes. Thank you, Mike Regarding the 2nd power supply... as you know we use the Cooler Master Stacker case for out large tower product which supports dual power. It comes with a handly adaptor for connecting the two supplies together for the purpose of turning the 2nd one on/off when the first one is turned on/off. You can see it in the third picture on this review page. I don't know where you could buy that adaptor. Anyway what's good about the adaptor is this: release 3.0 now includes a "Power down" button on the Management Utility, which will shutdown the system and turn off the power supplies. So... if there's no power switch (as on the MD-1200), how do you turn the unit back on? Two ways: first, you can physically turn off the top power supply, wait for bottom one to now come on (!) and then turn the top one on again. Second way is to use Wake-On-Lan.
September 16, 200619 yr Well, I don't think it is just the drive trays. I tried to copy data from /disk4 to /disk7 and I received errors. Sep 16 09:57:42 Tower kernel: hdl: dma_timer_expiry: dma status == 0x40 Sep 16 09:57:42 Tower kernel: hdl: timeout waiting for DMA Sep 16 09:57:42 Tower kernel: PDC202XX: Secondary channel reset. Sep 16 09:57:42 Tower kernel: hdl: timeout waiting for DMA Sep 16 09:57:42 Tower kernel: hdl: (__ide_dma_test_irq) called while not waiting Sep 16 09:57:42 Tower kernel: hdl: status error: status=0x58 { DriveReady SeekCo mplete DataRequest } Sep 16 09:57:42 Tower kernel: Sep 16 09:57:42 Tower kernel: hdl: drive not ready for command Sep 16 09:57:42 Tower kernel: hdk: status timeout: status=0xd1 { Busy } Sep 16 09:57:42 Tower kernel: Sep 16 09:57:42 Tower kernel: hdk: drive not ready for command Sep 16 09:57:42 Tower kernel: hdl: status timeout: status=0xd0 { Busy } Sep 16 09:57:42 Tower kernel: Sep 16 09:57:42 Tower kernel: PDC202XX: Secondary channel reset. Sep 16 09:57:42 Tower kernel: hdl: no DRQ after issuing WRITE Sep 16 09:57:42 Tower kernel: ide5: reset: success Sep 16 09:57:50 Tower smbd[953]: [2006/09/16 09:57:50, 0] smbd/oplock.c:oplock_b reak(830) Sep 16 09:57:50 Tower smbd[953]: oplock_break: end of file from client Sep 16 09:57:50 Tower smbd[953]: oplock_break failed for file Final Cut Studio Complete NOT UB/Apple Loops for Soundtrack Pro.toast (dev = 907, inode = 4, fil e_id = 2447). Sep 16 09:57:50 Tower smbd[953]: [2006/09/16 09:57:50, 0] smbd/oplock.c:oplock_b reak(923) Sep 16 09:57:50 Tower smbd[953]: oplock_break: client failure in break - shutt ing down this smbd. Sep 16 09:58:11 Tower smbd[1022]: [2006/09/16 09:58:11, 0] smbd/oplock.c:request _oplock_break(1055) Sep 16 09:58:11 Tower smbd[1022]: request_oplock_break: no response received t o oplock break request to pid 953 on port 32769 for dev = 907, inode = 4, file_i d = 2447 Also, while the array was just idle and I was @ the dog park these pesky errors came back: Sep 16 09:57:39 Tower smbd[1021]: [2006/09/16 09:57:39, 0] lib/util_sock.c:get_p eer_addr(1000) Sep 16 09:57:39 Tower smbd[1021]: getpeername failed. Error was Transport endp oint is not connected Sep 16 09:57:39 Tower smbd[1021]: [2006/09/16 09:57:39, 0] lib/util_sock.c:get_p eer_addr(1000) Sep 16 09:57:39 Tower smbd[1021]: getpeername failed. Error was Transport endp oint is not connected Sep 16 09:57:39 Tower smbd[1021]: [2006/09/16 09:57:39, 0] lib/util_sock.c:write _socket_data(430) Sep 16 09:57:39 Tower smbd[1021]: write_socket_data: write failure. Error = Co nnection reset by peer Sep 16 09:57:39 Tower smbd[1021]: [2006/09/16 09:57:39, 0] lib/util_sock.c:write _socket(455) Sep 16 09:57:39 Tower smbd[1021]: write_socket: Error writing 4 bytes to socke t 5: ERRNO = Connection reset by peer Sep 16 09:57:39 Tower smbd[1021]: [2006/09/16 09:57:39, 0] lib/util_sock.c:send_ smb(647) Sep 16 09:57:39 Tower smbd[1021]: Error writing 4 bytes to client. -1. (Connec tion reset by peer) Yes, it appears all is not quite right yet. Could swap the 2 Promise cards - this will not force you to re-sync parity - but if errors move away from disks4-7 to disks8-11 then would point to the controller - otherwise probably power. If you don't mind re-syncing, swap disk4 and disk5, and swap disk6 and disk7 (this swaps whether they're Master or Slave). All those "getpeername", "writesocket", "writesocketdata" errors may be ignored - they're harmless and don't indicate any h/w problem.
September 17, 200619 yr Author Well, I just looked through all the stuff that came with my stacker case.. sure enough, there is that power adapter... so I just hooked that up and removed to ole piece of wire : I will play around with moving the drives and see what the hell happens.
September 17, 200619 yr Author So I swapped disk 4 and disk 5 and disk 6 and disk 7. Before I swapped I was able to copy with no problems to disk5 or disk6 and disk8, but I could not get copy to disk7 and disk9.... Still no go... still can't copy to the 'new' disk 6 (which is was /disk 7) and now I can't copy to the new disk 7 (was disk6 and I was able to copy to before I switched. all these hard drives from disk6 and on are on that second PS
September 17, 200619 yr Author I am rebuilding parity right now and things are moving along at the normal speed. Tom, why is that I don't have a problem rebuilding parity, but copying data between disks locks up the array??
September 17, 200619 yr I am rebuilding parity right now and things are moving along at the normal speed. Tom, why is that I don't have a problem rebuilding parity, but copying data between disks locks up the array?? It does seem to be pointing to the p/s. Parity sync would not stress the p/s that much because it's entirely sequential, no large seeks involved - seeking it what draws the most current.
September 17, 200619 yr Author Alright, threw in my 430watt SeaSonic powersupply that I have for my HTPC. (note this p/s has 6 ide power connectors so we also eliminated the possibility that the power problem was related to the y-adapters) I CANT't copy to /disk 6 or /disk9. I can copy to every other drive. Both of these drives a Seagates BTW. i will also add disk 9 is connected direcly to the promise card....
September 17, 200619 yr What model Seagate? I believe the drive I mentioned earlier about problems being a Slave on a Promise was a Seagate ST3300831A. Definately not all Seagates have this problem, though.
Archived
This topic is now archived and is closed to further replies.