I just got off the phone with one of their executive customer service guys and he says they are working on a fix right now and should have a firmware update out some time this week, assuming all the testing goes well. When I get it I'll update and let you guys know if it works.<br>
<br><div class="gmail_quote">On Thu, Nov 6, 2008 at 2:43 AM, Dan Graham <span dir="ltr"><<a href="mailto:grahadan@gmail.com">grahadan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Chris,<br>
<br>
Thank you for the heads up. I was going to add another RAID 5 array<br>
with these drives ... shudderz ... I held off because of reliabilty<br>
issues with the 1T Seagates (I already have one of two over heating).<br>
I have had really good luck with the 750 Gig. Hitachis.<br>
<br>
All the best, Dan<br>
<div><div></div><div class="Wj3C7c"><br>
On Wed, Nov 5, 2008 at 5:45 PM, Chris q <<a href="mailto:quilley@gmail.com">quilley@gmail.com</a>> wrote:<br>
><br>
><br>
> ---------- Forwarded message ----------<br>
> From: Chris <<a href="mailto:chris@quilley.net">chris@quilley.net</a>><br>
> Date: Wed, Nov 5, 2008 at 5:45 PM<br>
> Subject: Re: [clug-talk] Fwd: Fwd: asus P5Q -Carefule of seagate 1.5 TB<br>
> drives, they are a bit broken<br>
> To: CLUG General <<a href="mailto:clug-talk@clug.ca">clug-talk@clug.ca</a>><br>
><br>
><br>
> <a href="http://forums.seagate.com/stx/board/message?board.id=ata_drives&thread.id=2390&view=by_date_ascending&page=6" target="_blank">http://forums.seagate.com/stx/board/message?board.id=ata_drives&thread.id=2390&view=by_date_ascending&page=6</a><br>
> Problem tentatively solved. Any of you thinking about buying the seagate 1.5<br>
> TB drives, wait until they fix this problem.<br>
><br>
><br>
> On Wed, Nov 5, 2008 at 4:15 PM, Chris <<a href="mailto:chris@quilley.net">chris@quilley.net</a>> wrote:<br>
>><br>
>> ok, here's the part that I don't get perhaps you can explain what's going<br>
>> on. it looks like a bunch of cups stuff is happening then my raid array sata<br>
>> links reset,although that might be a coincidence. Is there any reason why<br>
>> the link is resetting? doesn't make sense to me.<br>
>><br>
>> Nov 5 12:49:12 serverv2 -- MARK --<br>
>> Nov 5 13:09:12 serverv2 -- MARK --<br>
>> Nov 5 13:29:12 serverv2 -- MARK --<br>
>> Nov 5 13:49:12 serverv2 -- MARK --<br>
>> Nov 5 14:09:12 serverv2 -- MARK --<br>
>> Nov 5 14:29:12 serverv2 -- MARK --<br>
>> Nov 5 14:49:12 serverv2 -- MARK --<br>
>> Nov 5 15:09:12 serverv2 -- MARK --<br>
>> Nov 5 15:29:12 serverv2 -- MARK --<br>
>> Nov 5 15:49:12 serverv2 -- MARK --<br>
>> Nov 5 15:50:55 serverv2 python: hp-systray(init)[6671]: warning: No hp:<br>
>> or hpfax: devices found in any installed CUPS queue. Exiting.<br>
>> Nov 5 15:52:07 serverv2 kernel: [12192.326735] type=1503<br>
>> audit(1225925527.559:4): operation="inode_permission" requested_mask="r::"<br>
>> denied_mask="r::" fsuid=7 name="/proc/6778/net/" pid=6778<br>
>> profile="/usr/sbin/cupsd"<br>
>> Nov 5 15:52:08 serverv2 kernel: [12193.222565] type=1503<br>
>> audit(1225925528.454:5): operation="inode_permission" requested_mask="r::"<br>
>> denied_mask="r::" fsuid=7 name="/proc/6782/net/" pid=6782<br>
>> profile="/usr/sbin/cupsd"<br>
>> Nov 5 15:52:08 serverv2 kernel: [12193.222606] type=1503<br>
>> audit(1225925528.454:6): operation="socket_create" family="ax25"<br>
>> sock_type="dgram" protocol=0 pid=6782 profile="/usr/sbin/cupsd"<br>
>> Nov 5 15:52:08 serverv2 kernel: [12193.222614] type=1503<br>
>> audit(1225925528.454:7): operation="socket_create" family="netrom"<br>
>> sock_type="seqpacket" protocol=0 pid=6782 profile="/usr/sbin/cupsd"<br>
>> Nov 5 15:52:08 serverv2 kernel: [12193.222621] type=1503<br>
>> audit(1225925528.454:8): operation="socket_create" family="rose"<br>
>> sock_type="dgram" protocol=0 pid=6782 profile="/usr/sbin/cupsd"<br>
>> Nov 5 15:52:08 serverv2 kernel: [12193.222628] type=1503<br>
>> audit(1225925528.454:9): operation="socket_create" family="ipx"<br>
>> sock_type="dgram" protocol=0 pid=6782 profile="/usr/sbin/cupsd"<br>
>> Nov 5 15:52:08 serverv2 kernel: [12193.222634] type=1503<br>
>> audit(1225925528.454:10): operation="socket_create" family="appletalk"<br>
>> sock_type="dgram" protocol=0 pid=6782 profile="/usr/sbin/cupsd"<br>
>> Nov 5 15:52:08 serverv2 kernel: [12193.222641] type=1503<br>
>> audit(1225925528.454:11): operation="socket_create" family="econet"<br>
>> sock_type="dgram" protocol=0 pid=6782 profile="/usr/sbin/cupsd"<br>
>> Nov 5 15:52:08 serverv2 kernel: [12193.222648] type=1503<br>
>> audit(1225925528.454:12): operation="socket_create" family="ash"<br>
>> sock_type="dgram" protocol=0 pid=6782 profile="/usr/sbin/cupsd"<br>
>> Nov 5 15:52:08 serverv2 kernel: [12193.222654] type=1503<br>
>> audit(1225925528.454:13): operation="socket_create" family="x25"<br>
>> sock_type="seqpacket" protocol=0 pid=6782 profile="/usr/sbin/cupsd"<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.184075] ata3: hard resetting link<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.184077] ata4: hard resetting link<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.668023] ata4: SATA link up 3.0<br>
>> Gbps (SStatus 123 SControl 300)<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.668709] ata3: SATA link up 3.0<br>
>> Gbps (SStatus 123 SControl 300)<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.670396] ata4.00: configured for<br>
>> UDMA/133<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.670419] ata4: EH complete<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.670494] sd 3:0:0:0: [sdd]<br>
>> 2930277168 512-byte hardware sectors (1500302 MB)<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.670517] sd 3:0:0:0: [sdd] Write<br>
>> Protect is off<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.670556] sd 3:0:0:0: [sdd] Write<br>
>> cache: enabled, read cache: enabled, doesn't support DPO or FUA<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.670941] ata3.00: configured for<br>
>> UDMA/133<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.670952] ata3: EH complete<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.670992] sd 2:0:0:0: [sdc]<br>
>> 2930277168 512-byte hardware sectors (1500302 MB)<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.671012] sd 2:0:0:0: [sdc] Write<br>
>> Protect is off<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.671050] sd 2:0:0:0: [sdc] Write<br>
>> cache: enabled, read cache: enabled, doesn't support DPO or FUA<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.682437] md: super_written gets<br>
>> error=-5, uptodate=0<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.704202] md: super_written gets<br>
>> error=-5, uptodate=0<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.757591] RAID5 conf printout:<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.757598] --- rd:6 wd:4<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.757601] disk 0, o:1, dev:sda1<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.757604] disk 1, o:1, dev:sdb1<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.757606] disk 2, o:0, dev:sdc1<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.757608] disk 3, o:0, dev:sdd1<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.757610] disk 4, o:1, dev:sde1<br>
>> Nov 5 16:05:21 serverv2 kernel: [12986.757612] disk 5, o:1, dev:sdf1<br>
>> Nov 5 16:05:22 serverv2 kernel: [12986.769512] RAID5 conf printout:<br>
>> Nov 5 16:05:22 serverv2 kernel: [12986.769520] --- rd:6 wd:4<br>
>> Nov 5 16:05:22 serverv2 kernel: [12986.769523] disk 0, o:1, dev:sda1<br>
>> Nov 5 16:05:22 serverv2 kernel: [12986.769525] disk 1, o:1, dev:sdb1<br>
>> Nov 5 16:05:22 serverv2 kernel: [12986.769527] disk 2, o:0, dev:sdc1<br>
>> Nov 5 16:05:22 serverv2 kernel: [12986.769529] disk 4, o:1, dev:sde1<br>
>> Nov 5 16:05:22 serverv2 kernel: [12986.769531] disk 5, o:1, dev:sdf1<br>
>> Nov 5 16:05:22 serverv2 kernel: [12986.769549] RAID5 conf printout:<br>
>> Nov 5 16:05:22 serverv2 kernel: [12986.769551] --- rd:6 wd:4<br>
>> Nov 5 16:05:22 serverv2 kernel: [12986.769552] disk 0, o:1, dev:sda1<br>
>> Nov 5 16:05:22 serverv2 kernel: [12986.769554] disk 1, o:1, dev:sdb1<br>
>> Nov 5 16:05:22 serverv2 kernel: [12986.769556] disk 2, o:0, dev:sdc1<br>
>> Nov 5 16:05:22 serverv2 kernel: [12986.769558] disk 4, o:1, dev:sde1<br>
>> Nov 5 16:05:22 serverv2 kernel: [12986.769560] disk 5, o:1, dev:sdf1<br>
>> Nov 5 16:05:22 serverv2 kernel: [12986.789508] RAID5 conf printout:<br>
>> Nov 5 16:05:22 serverv2 kernel: [12986.789513] --- rd:6 wd:4<br>
>> Nov 5 16:05:22 serverv2 kernel: [12986.789516] disk 0, o:1, dev:sda1<br>
>> Nov 5 16:05:22 serverv2 kernel: [12986.789518] disk 1, o:1, dev:sdb1<br>
>> Nov 5 16:05:22 serverv2 kernel: [12986.789520] disk 4, o:1, dev:sde1<br>
>> Nov 5 16:05:22 serverv2 kernel: [12986.789522] disk 5, o:1, dev:sdf1<br>
>><br>
>><br>
>><br>
>> On Tue, Nov 4, 2008 at 4:57 PM, Mark Carlson <<a href="mailto:carlsonmark@gmail.com">carlsonmark@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> I'm sure someone can help you if you simply state why you think your<br>
>>> RAID array is failing. What makes you think the array is failing?<br>
>>> Can you not access the file system on it? Do you get an error message<br>
>>> that says that the array is bad?<br>
>>><br>
>>> As far as I know, you may not even have created a file system on the<br>
>>> array, let alone mounted it. This is why you need to provide the<br>
>>> steps you took to create the array. I cannot stress this enough.<br>
>>> Tell us what you did and we can help you. "I created a software raid<br>
>>> array" does not cut it. It's not like we need screen shots or<br>
>>> anything. If you did it using a GUI, tell us what GUI you used and<br>
>>> what buttons you pressed and anything you typed in. If you used the<br>
>>> command line, tell us what you typed in. That's it, that's all...<br>
>>> it's a pretty standard thing to do when you need help with a problem,<br>
>>> even non-computer problems.<br>
>>><br>
>>> What you've done so far is analogous to going to the doctor and<br>
>>> saying: "I'm sick, give me pills that make me feel better."<br>
>>><br>
>>> -Mark C.<br>
>>><br>
>>> On 11/4/08, Chris q <<a href="mailto:quilley@gmail.com">quilley@gmail.com</a>> wrote:<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > The stuff down at the bottom about the ata fail seemed important. I'm<br>
>>> > hoping<br>
>>> > someone can tell me why the raid array is failing.<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > On Tue, Nov 4, 2008 at 2:11 PM, Mark Carlson <<a href="mailto:carlsonmark@gmail.com">carlsonmark@gmail.com</a>><br>
>>> > wrote:<br>
>>> ><br>
>>> > ><br>
>>> > ><br>
>>> > > On 11/2/08, Chris q <<a href="mailto:quilley@gmail.com">quilley@gmail.com</a>> wrote:<br>
>>> > > > Well, I attached an IDE cdrom and it immediately happened again..<br>
>>> > > > here's the /var/log/messages output, I'm hoping you guys can help<br>
>>> > > > me<br>
>>> > figure<br>
>>> > > > this out.<br>
>>> > ><br>
>>> > > Posting the entire contents of /var/log/messages is helpful<br>
>>> > > sometimes... but not right now. What in /var/log/messages do you<br>
>>> > > think relates to your problems, and why do you think it has something<br>
>>> > > to do with your cdrom drive?<br>
>>> > ><br>
>>> > > I would like to help you solve your problem, but you are missing some<br>
>>> > > key things here.<br>
>>> > ><br>
>>> > > 1. CLEARLY state your problem. Include any error messages related to<br>
>>> > > the problem, no more and no less. I still don't understand what your<br>
>>> > > problem and you seem to be withholding information.<br>
>>> > > 2. How are you setting up the software raid? Describe your steps.<br>
>>> > > This is often the root cause of Linux problems, misconfiguration,<br>
>>> > > rather than hardware or software errors.<br>
>>> > > 3. Have you tried setting up a RAID 0 array instead of RAID 5? Use<br>
>>> > > two drives instead of all 6. Maybe one of your drives is bad.<br>
>>> > ><br>
>>> > ><br>
>>> > > -Mark C.<br>
>>><br>
>>> _______________________________________________<br>
>>> clug-talk mailing list<br>
>>> <a href="mailto:clug-talk@clug.ca">clug-talk@clug.ca</a><br>
>>> <a href="http://clug.ca/mailman/listinfo/clug-talk_clug.ca" target="_blank">http://clug.ca/mailman/listinfo/clug-talk_clug.ca</a><br>
>>> Mailing List Guidelines (<a href="http://clug.ca/ml_guidelines.php" target="_blank">http://clug.ca/ml_guidelines.php</a>)<br>
>>> **Please remove these lines when replying<br>
>><br>
><br>
><br>
><br>
> _______________________________________________<br>
> clug-talk mailing list<br>
> <a href="mailto:clug-talk@clug.ca">clug-talk@clug.ca</a><br>
> <a href="http://clug.ca/mailman/listinfo/clug-talk_clug.ca" target="_blank">http://clug.ca/mailman/listinfo/clug-talk_clug.ca</a><br>
> Mailing List Guidelines (<a href="http://clug.ca/ml_guidelines.php" target="_blank">http://clug.ca/ml_guidelines.php</a>)<br>
> **Please remove these lines when replying<br>
><br>
<br>
_______________________________________________<br>
clug-talk mailing list<br>
<a href="mailto:clug-talk@clug.ca">clug-talk@clug.ca</a><br>
<a href="http://clug.ca/mailman/listinfo/clug-talk_clug.ca" target="_blank">http://clug.ca/mailman/listinfo/clug-talk_clug.ca</a><br>
Mailing List Guidelines (<a href="http://clug.ca/ml_guidelines.php" target="_blank">http://clug.ca/ml_guidelines.php</a>)<br>
**Please remove these lines when replying<br>
</div></div></blockquote></div><br>