CapnBax Posted October 24, 2009 Share Posted October 24, 2009 I've been running 18 data drives sense 4.5-beta7 has been out. They are on Asus K8N-lr motherboard with 2 SUPERMICRO AOC-SAT2-MV8 in pci-x slots, and a pcie 4x card. I have been using this board more than a year and added the second supermicro recently. When I try to assign the 19th drive unraid never assigns the drive it just sits there grayed out. The cache drive and the 19th drive are in Rosewill esata external enclosures. Both are using the SUPERMICRO cards, the cache drive works fine. The 19th drive is a WDC_WD7500AAKS-00RBA0, I have 3 other drives like this in the aray working fine. Here is the preclear report and here is the syslog right after I assign it. Thanks for the help Bax Quote Link to comment
tdoris Posted October 24, 2009 Share Posted October 24, 2009 I'm using NFS for a couple of months now (since I build my unraid) and while NFS in unraid does have some quirks, it doesn't display the problems you mention. I'm using the latest stable (4.4.2). 4.4.2 works fairly well, but isn't perfect. The 4.5.7 series haven't been working too well for me. I think my NFS issue is actually related to a CPU utilization problem I'm encountering. The other main use for my unRAID box is as storage for SageTV recordings. Anytime I use the livetv function and have a scheduled recording at the same time I experience severe stuttering with 4.5.7. 4.4.2 works fine. My recording share is set to use my cache drive (an 80 GB Intel SSD at the moment). I'm attaching syslogs and output from top showing the much heavier CPU utilization. Quote Link to comment
CapnBax Posted October 25, 2009 Share Posted October 25, 2009 Ok, I tried another drive for the 19th drive and got the same results. The second drive was a ST3500641AS. Here is the syslog. Thanks Bax Quote Link to comment
NAS Posted October 25, 2009 Share Posted October 25, 2009 Just for note I am still seeing drop outs from mapped drives. Randomly with no syslog entries windows filesharing will lose access to the server, then a minute later it will be back. I can find no real pattern to cause this other than if more than a couple of entwork activities are happening at the same time seems to cause it to happen more. Even then this may work most the time. Lack of logs stops me examining more Quote Link to comment
Joe L. Posted October 25, 2009 Share Posted October 25, 2009 Just for note I am still seeing drop outs from mapped drives. Randomly with no syslog entries windows filesharing will lose access to the server, then a minute later it will be back. I can find no real pattern to cause this other than if more than a couple of entwork activities are happening at the same time seems to cause it to happen more. Even then this may work most the time. Lack of logs stops me examining more Which machine on your LAN is acting as the "Master Browser" Joe L. Quote Link to comment
NAS Posted October 25, 2009 Share Posted October 25, 2009 All i know is if i downgrade to beta 6 i dont see outages and if I upgrade to beta 7 I see them daily. Dont know how to debug this more since syslog tells me nothing Quote Link to comment
Joe L. Posted October 25, 2009 Share Posted October 25, 2009 Good to know, since 4.5b7 has a newer version of SAMBA per the release notes. - Upgrade samba to 3.3.7 Quote Link to comment
cwr Posted October 25, 2009 Share Posted October 25, 2009 i build my own server using the same board as the limetech servers (c2see) and see complete network outages using beta6 about once per month. it looks like the network driver dies and comes back (eth0: Link up in dmesg). sounds like what's happening in beta7 for NAS Quote Link to comment
Joe L. Posted October 26, 2009 Share Posted October 26, 2009 i build my own server using the same board as the limetech servers (c2see) and see complete network outages using beta6 about once per month. it looks like the network driver dies and comes back (eth0: Link up in dmesg). sounds like what's happening in beta7 for NAS He said he does not see anything in the syslog. You might have a different issue. Your sounds more like a network driver, or (also possibly) a LAN cabling problem. It is hard to compare, as we might use different network chipsets, and consequently, different drivers. Quote Link to comment
purko Posted October 26, 2009 Share Posted October 26, 2009 ...the ide_core module [...] has a parameter to force the 40 wire cable type to be ignored [...] Can we enable the ide_core boot options in the next build? I don't know what you are asking for here; if you can provide what .config option you want, I can include it. But isn't it working correctly? That is, you are not using an 80-pin cable and linux is correctly not using it... does the drive not work at all? The disk in question is a 2.5" laptop EIDE disk. It does not have the choice of 40-pin or 80-pin cables. Its cable is 44-pin. So here is what happens: When I boot this machine with a different slackware build, and add the boot option... ide_core.ignore_cable=0 Oct 25 22:38:54 (none) kernel: ide: ignoring cable detection for ide0 Oct 25 22:38:54 (none) kernel: ide0: BM-DMA at 0xfc08-0xfc0f Oct 25 22:38:54 (none) kernel: hda: WDC WD3200BEVE-00A0HT0, ATA DISK drive Oct 25 22:38:54 (none) kernel: hda: UDMA/100 mode selected But when I boot this machine with unRaid, and try to use ide_core.ignore_cable=0, it fails: Oct 25 16:58:03 Tower kernel: Kernel command line: ide_core.ignore_cable=0 initrd=bzroot BOOT_IMAGE=bzimage Oct 25 16:58:03 Tower kernel: Unknown boot option `ide_core.ignore_cable=0': ignoring Oct 25 16:58:03 Tower kernel: hda: host side 80-wire cable detection failed, limiting max speed to UDMA33 Oct 25 16:58:03 Tower kernel: hda: UDMA/33 mode selected Looks like ide_core is not compiled in the unRaid kernel. It is only compiled as a module. When I look at the Lime config I see: # # Protocols # CONFIG_IDE=m I am guessing that changing that to "CONFIG_IDE=y" will enable ide_core at kernel boot time, and will solve the problem. Yours, Purko Quote Link to comment
limetech Posted October 26, 2009 Author Share Posted October 26, 2009 I've been running 18 data drives sense 4.5-beta7 has been out. They are on Asus K8N-lr motherboard with 2 SUPERMICRO AOC-SAT2-MV8 in pci-x slots, and a pcie 4x card. I have been using this board more than a year and added the second supermicro recently. When I try to assign the 19th drive unraid never assigns the drive it just sits there grayed out. The cache drive and the 19th drive are in Rosewill esata external enclosures. Both are using the SUPERMICRO cards, the cache drive works fine. The 19th drive is a WDC_WD7500AAKS-00RBA0, I have 3 other drives like this in the aray working fine. Here is the preclear report and here is the syslog right after I assign it. Thanks for the help Bax I'd like to see the full system log please. Quote Link to comment
limetech Posted October 26, 2009 Author Share Posted October 26, 2009 I can find no real pattern to cause this other than if more than a couple of entwork activities are happening at the same time seems to cause it to happen more. Even then this may work most the time. Do you mean network activity to the same server? Quote Link to comment
Joe L. Posted October 26, 2009 Share Posted October 26, 2009 I've been running 18 data drives sense 4.5-beta7 has been out. They are on Asus K8N-lr motherboard with 2 SUPERMICRO AOC-SAT2-MV8 in pci-x slots, and a pcie 4x card. I have been using this board more than a year and added the second supermicro recently. When I try to assign the 19th drive unraid never assigns the drive it just sits there grayed out. The cache drive and the 19th drive are in Rosewill esata external enclosures. Both are using the SUPERMICRO cards, the cache drive works fine. The 19th drive is a WDC_WD7500AAKS-00RBA0, I have 3 other drives like this in the aray working fine. Here is the preclear report and here is the syslog right after I assign it. Thanks for the help Bax I'd like to see the full system log please. A similar one is here Tom: http://lime-technology.com/forum/index.php?topic=4540.0 Quote Link to comment
limetech Posted October 26, 2009 Author Share Posted October 26, 2009 I am guessing that changing that to "CONFIG_IDE=y" will enable ide_core at kernel boot time, and will solve the problem. The ide_core was changed to a module (vs. built-in to kernel) quite a while ago. This was done to save a little memory for all-SATA systems. I have restored it as a "built-in" for the upcoming -beta8 release. I might add though - it seems what you are trying to do is force an IDE drive to use an Ultra DMA mode on a non-Ultra-DMA-capable cable. This is probably not a good idea & may result in DMA errors. Quote Link to comment
CapnBax Posted October 26, 2009 Share Posted October 26, 2009 OK, The syslog is too big for one post, so here is the first half. Quote Link to comment
CapnBax Posted October 26, 2009 Share Posted October 26, 2009 And here is the second half. Quote Link to comment
purko Posted October 26, 2009 Share Posted October 26, 2009 I am guessing that changing that to "CONFIG_IDE=y" will enable ide_core at kernel boot time, and will solve the problem. The ide_core was changed to a module (vs. built-in to kernel) quite a while ago. This was done to save a little memory for all-SATA systems. I have restored it as a "built-in" for the upcoming -beta8 release. Thank you! I might add though - it seems what you are trying to do is force an IDE drive to use an Ultra DMA mode on a non-Ultra-DMA-capable cable. Yes, I am trying to force it because laptop disks only have one type of cable, the 44-pin. In laptops they don't even use a cable, they plug directly to the mobo. But on setups where you have to use a cable, the short 44-pin one is the only thing in existance. This is probably not a good idea & may result in DMA errors. I will keep my eyes open for a long period of testing. Thanks again. Purko Quote Link to comment
agw Posted October 26, 2009 Share Posted October 26, 2009 My first hiccup with 4.5 beta 7 . . . Over the weekend, I was installing Windows 7 on my wife's netbook. First thing I did was image the netbook recovery partition to the unRaid server. It was about 2.5GB I believe. No problems. Then I installed Windows 7, updated drivers, etc. After getting the new OS partition in a nice clean state, I tried to image this partition to the unRaid server. It was about a 10gb file. After it got to just about the end of the backup, the imaging software errored out with a "Network Device No Longer Available" message (it was being done wirelessly - something that I had done many times before with even larger images). I closed the imaging software and tried to get to the unRaid server and found the following: 1. I could telnet in and get past the login / password stage. Anything beyond that and the server simply did not respond. I could not get syslog from a telnet session. 2. I could get to the server main page via http://tower.'>http://tower. 3. Occasionally, I could get to unMenu by http://tower:8080'>http://tower:8080 - but I could only get to the main screen. It would not respond to any of the sub-screens (mymain, syslog, etc). And it was random whether or not I could even get to the main unMenu page. 4. The only way to get to the syslog was via the web interface and http://tower/log/syslog.'>http://tower/log/syslog. 5. Yes the server had been awake and asleep a couple of times that day, whether or not that is relevant I am not sure. 6. I was able to stop the server from the http://tower main page and get it to properly shutdown from there as well. 7. Upon powering back on, it initiated a parity check. I let the parity check run (it was in the evening) and let the server sleep by itself afterwards. This morning I woke it back up and it was happy with no parity check errors and no additional errors in the smart history page of unMenu. Syslog files were too large to attach, so I stuck them in my dropbox. Links are here: http://dl.getdropbox.com/u/283470/unraid%20syslog%2010-25-09b.rtf - 10-25-09 is the log from the crash http://dl.getdropbox.com/u/283470/syslog-2009-10-26.txt - 10-26-09 is the subsequent log after reboot, parity check and one sleep / wake cycle. I can't make a lot of sense of these syslog files, but I will make a general statement that the log files seem a lot busier than I remember them being. Next I will revert to the cozy comfort of 4.4.2 and try to send the same image wirelessly and see what happens. I'll post syslog when I get a chance. agw Quote Link to comment
purko Posted October 27, 2009 Share Posted October 27, 2009 ... the server simply did not respond. I could not get syslog from a telnet session. Honestly, dragging 10GB over wireless -- that's asking for trouble!!! But that was not your problem. I used to experience the same type of lockups that you are describing: Upon strarting some large copy, the server would get unresponsive, a whole bunch of processes on the server would get stuck in a 'device wait state', and the copy would time-out with some message like 'network path no longer available'. Interestingly, if I left the server alone, 15 minutes later I would find the "aborted" file to be completely copied to the server, and then the server would become responsive again. I did a couple of tweaks to my server <as described in this thread> and I haven't seen this behavior since. (Knock on wood!) This may, or may not help your case, but it's worth a try. And get yourself some CAT-6 cables for stuff like this. Purko Quote Link to comment
limetech Posted October 27, 2009 Author Share Posted October 27, 2009 My first hiccup with 4.5 beta 7 . . . Looking at the system log it seems like you are using suspend/resume, correct? If so can you retry without using suspend/resume - that is completely untested. Quote Link to comment
limetech Posted October 27, 2009 Author Share Posted October 27, 2009 And here is the second half. Thank you, I know what the problem is. Quote Link to comment
Guzzi Posted October 27, 2009 Share Posted October 27, 2009 And here is the second half. Thank you, I know what the problem is. ok, so is it a general problem or specific to that box? Asking 'cause I have prepared/precleared drive 19, but now hesitating to add it after reading about the probs - with last bug (16+drives) it broke my array and config files ... So some additional info would be appreciated... May we also get an update on AD-integration plans, that is part of this betas? I couldn't get it properly up and running, so I reverted to userlevel security, manually creating all accounts I needed. If you need further testing, let me know, 'cause this can easily be done on my testsystem (that is unfortunately not equipped with 20 drives for the above data-19-drive-test...) Quote Link to comment
subwars Posted October 27, 2009 Share Posted October 27, 2009 hey, first i'd like to say i'm glad your back tom and your developing again. i installed a new 1.5tb sammy a couple weeks ago, and moved the 1tb from parity down into drive 1 slot, and i've just realised that it's not spinning down. i had noticed previously that it was always spun up when checking the status page, but just assumed something must of accessed it and cause it to spin up. but it is definatly not spinning down at all. now it always spun down noprob when it was the parity drive, but now it's not? so not sure if it's the new setup, or this new beta7. i have no idea, anyone got any ideas? edit:. i also just just manualy spinning it down, and the status page took about a min to refresh, and it sounded as if all the drives spun up and back down, but disk1 is still going, it didn't spin down.. Quote Link to comment
Joe L. Posted October 27, 2009 Share Posted October 27, 2009 hey, first i'd like to say i'm glad your back tom and your developing again. i installed a new 1.5tb sammy a couple weeks ago, and moved the 1tb from parity down into drive 1 slot, and i've just realised that it's not spinning down. i had noticed previously that it was always spun up when checking the status page, but just assumed something must of accessed it and cause it to spin up. but it is definatly not spinning down at all. now it always spun down noprob when it was the parity drive, but now it's not? so not sure if it's the new setup, or this new beta7. i have no idea, anyone got any ideas? edit:. i also just just manualy spinning it down, and the status page took about a min to refresh, and it sounded as if all the drives spun up and back down, but disk1 is still going, it didn't spin down.. Disk1 appears to be /dev/sdg. The command "hdparm -y /dev/sdg" is used to spin it down. As you can see from the lines I filtered from your syslog, unRAID has been sending it the command to spin down along with spin down commands to all the other disks in your array. If disk1 is not spinning down, then it might be some option set in the drive itself ( a jumper? or a "do not sleep" mode). Perhaps you can try a power cycle. (Stop array, power down, power back up restarting the array) Some drives will only change their mode after a power cycle has been performed. Oct 17 04:14:06 Tower kernel: sd 8:0:0:0: [sdg] 1953525168 512-byte hardware sectors: (1.00 TB/931 GiB) Oct 17 04:14:06 Tower kernel: sd 8:0:0:0: [sdg] Write Protect is off Oct 17 04:14:06 Tower kernel: sd 8:0:0:0: [sdg] Mode Sense: 00 3a 00 00 Oct 17 04:14:06 Tower kernel: sd 8:0:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Oct 17 04:14:06 Tower kernel: sdg: sdi1 Oct 17 04:14:06 Tower kernel: sdg1 Oct 17 04:14:06 Tower kernel: sd 8:0:0:0: [sdg] Attached SCSI disk Oct 17 04:14:06 Tower emhttp: pci-0000:00:1f.2-scsi-1:0:0:0 (sdg) ata-SAMSUNG_HD103UI_S1LMJDWS403503 Oct 17 04:14:06 Tower kernel: md: import disk1: [8,96] (sdg) SAMSUNG HD103UI S1LMJDWS403503 offset: 63 size: 976762552 Oct 17 04:14:08 Tower kernel: md: import disk1: [8,96] (sdg) SAMSUNG HD103UI S1LMJDWS403503 offset: 63 size: 976762552 Oct 17 04:14:09 Tower emhttp: shcmd (: /usr/local/sbin/set_ncq sdg 1 | logger Oct 17 04:14:09 Tower kernel: md: import disk1: [8,96] (sdg) SAMSUNG HD103UI S1LMJDWS403503 offset: 63 size: 976762552 Oct 18 17:12:28 Tower emhttp: shcmd (77): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 18 17:12:28 Tower emhttp: shcmd (77): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 18 17:14:12 Tower emhttp: shcmd (89): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 18 19:34:52 Tower emhttp: shcmd (101): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 19 09:49:38 Tower emhttp: shcmd (114): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 19 10:19:56 Tower emhttp: shcmd (122): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 19 11:40:58 Tower emhttp: shcmd (126): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 19 22:23:32 Tower emhttp: shcmd (142): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 19 23:34:46 Tower emhttp: shcmd (150): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 01:01:43 Tower emhttp: shcmd (178): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 01:31:56 Tower emhttp: shcmd (180): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 02:02:19 Tower emhttp: shcmd (181): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 02:32:42 Tower emhttp: shcmd (182): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 03:03:06 Tower emhttp: shcmd (183): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 03:33:29 Tower emhttp: shcmd (184): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 04:03:52 Tower emhttp: shcmd (185): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 04:34:04 Tower emhttp: shcmd (186): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 05:04:27 Tower emhttp: shcmd (187): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 05:34:39 Tower emhttp: shcmd (188): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 09:27:45 Tower emhttp: shcmd (191): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 09:58:17 Tower emhttp: shcmd (197): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 10:28:40 Tower emhttp: shcmd (202): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 10:59:09 Tower emhttp: shcmd (206): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 11:29:32 Tower emhttp: shcmd (209): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 11:59:55 Tower emhttp: shcmd (211): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 12:30:25 Tower emhttp: shcmd (213): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 13:00:39 Tower emhttp: shcmd (217): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 13:31:02 Tower emhttp: shcmd (220): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 14:01:27 Tower emhttp: shcmd (222): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 14:31:40 Tower emhttp: shcmd (224): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 15:01:52 Tower emhttp: shcmd (225): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 16:09:08 Tower emhttp: shcmd (233): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 16:39:23 Tower emhttp: shcmd (234): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 17:09:35 Tower emhttp: shcmd (235): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 17:52:56 Tower emhttp: shcmd (237): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 18:23:17 Tower emhttp: shcmd (242): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 18:53:43 Tower emhttp: shcmd (245): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 19:24:07 Tower emhttp: shcmd (248): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 20:10:10 Tower emhttp: shcmd (252): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 21 21:30:34 Tower emhttp: shcmd (260): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 22 14:30:11 Tower emhttp: shcmd (282): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 22 15:00:37 Tower emhttp: shcmd (286): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 22 15:30:49 Tower emhttp: shcmd (288): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 22 19:12:08 Tower emhttp: shcmd (298): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 22 19:42:22 Tower emhttp: shcmd (302): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 22 20:12:47 Tower emhttp: shcmd (305): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 22 20:43:13 Tower emhttp: shcmd (306): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 22 21:13:37 Tower emhttp: shcmd (309): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 22 21:43:49 Tower emhttp: shcmd (311): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 22 22:14:07 Tower emhttp: shcmd (313): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 22 22:46:50 Tower emhttp: shcmd (319): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 22 23:17:08 Tower emhttp: shcmd (322): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 23 09:22:31 Tower emhttp: shcmd (334): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 23 09:52:47 Tower emhttp: shcmd (341): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 23 10:23:17 Tower emhttp: shcmd (343): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 23 10:53:42 Tower emhttp: shcmd (346): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 23 15:43:32 Tower emhttp: shcmd (353): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 23 16:14:00 Tower emhttp: shcmd (360): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 23 16:44:30 Tower emhttp: shcmd (361): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 23 17:14:43 Tower emhttp: shcmd (363): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 23 17:45:07 Tower emhttp: shcmd (365): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 23 18:15:30 Tower emhttp: shcmd (367): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 23 18:45:42 Tower emhttp: shcmd (368): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 23 19:16:05 Tower emhttp: shcmd (369): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 23 19:46:28 Tower emhttp: shcmd (370): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 24 07:43:19 Tower emhttp: shcmd (378): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 24 08:13:46 Tower emhttp: shcmd (382): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 24 08:44:09 Tower emhttp: shcmd (384): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 24 09:14:23 Tower emhttp: shcmd (385): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 24 17:42:50 Tower emhttp: shcmd (394): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 24 18:13:07 Tower emhttp: shcmd (401): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 24 18:52:45 Tower emhttp: shcmd (404): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 24 19:23:10 Tower emhttp: shcmd (407): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 24 19:53:23 Tower emhttp: shcmd (409): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 24 20:23:50 Tower emhttp: shcmd (410): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 25 10:01:35 Tower emhttp: shcmd (418): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 25 16:26:42 Tower emhttp: shcmd (433): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 25 18:21:23 Tower emhttp: shcmd (443): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 25 23:36:34 Tower emhttp: shcmd (456): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 26 00:07:00 Tower emhttp: shcmd (460): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 26 00:37:23 Tower emhttp: shcmd (461): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 26 01:07:46 Tower emhttp: shcmd (462): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 26 15:00:58 Tower emhttp: shcmd (471): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 26 15:31:26 Tower emhttp: shcmd (478): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 26 16:01:38 Tower emhttp: shcmd (480): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 26 16:32:01 Tower emhttp: shcmd (482): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 26 17:22:28 Tower emhttp: shcmd (486): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 26 18:16:52 Tower emhttp: shcmd (492): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 26 18:57:49 Tower emhttp: shcmd (497): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 27 00:07:19 Tower emhttp: shcmd (514): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 27 08:43:01 Tower emhttp: shcmd (524): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 27 09:25:54 Tower emhttp: shcmd (529): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 27 09:56:19 Tower emhttp: shcmd (532): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 27 10:26:43 Tower emhttp: shcmd (533): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 27 10:57:06 Tower emhttp: shcmd (534): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 27 11:27:18 Tower emhttp: shcmd (535): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 27 11:57:38 Tower emhttp: shcmd (536): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 27 12:28:01 Tower emhttp: shcmd (538): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 27 12:58:13 Tower emhttp: shcmd (539): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 27 13:28:37 Tower emhttp: shcmd (541): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 27 17:00:30 Tower emhttp: shcmd (552): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 27 19:22:01 Tower emhttp: shcmd (556): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 27 19:52:26 Tower emhttp: shcmd (560): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 27 20:22:57 Tower emhttp: shcmd (561): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 27 20:53:11 Tower emhttp: shcmd (564): /usr/sbin/hdparm -y /dev/sdg >/dev/null Oct 27 21:23:35 Tower emhttp: shcmd (566): /usr/sbin/hdparm -y /dev/sdg >/dev/null Quote Link to comment
CapnBax Posted October 28, 2009 Share Posted October 28, 2009 And here is the second half. Thank you, I know what the problem is. OK, Ya think you could let me know what it is? Thanks, Bax Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.