Hi,

 

A couple days ago, I've upgraded my hardware from P4 setup to C2D 9550 + Supermicro C2SEA. The parity check gotten better from 36hrs down to 20hrs. I still have the SAT2-MV8 on the PCI slot. I did a couple sanity check from reading and copying a 6GB file. They all went fine.

 

Last night, I started to copy a 30GB file over to my server and it started with 15/Mbs but it slowly comes down to 7/Mbs with 7GB left to go. I went to sleep and let it copy. This morning(8hrs later), it's still copying with 650Mb left at 1/Mbs. I went to http://tower and it's showing both the destination disk and parity disk running. Strangely when I refresh the page, it's showing the read # from the destination disk is increasing with a couple bytes but the write is not doing anything.

 

I was tailing the syslog file before I went to sleep and the log doesn't have anything to show other than the drives went spin down mode. One more thing, while I was doing the copying, I was running the preclear script on my new 2tb drive but I thought it has anything to do with it.

 

Does anyone know what's going on? Do you think it's a bad motherboard Nic?

 

thanks in advance,

~joy

 

Updated: attached syslog

syslog20200421.txt

Hi,

 

A couple days ago, I've upgraded my hardware from P4 setup to C2D 9550 + Supermicro C2SEA. The parity check gotten better from 36hrs down to 20hrs. I still have the SAT2-MV8 on the PCI slot. I did a couple sanity check from reading and copying a 6GB file. They all went fine.

 

Last night, I started to copy a 30GB file over to my server and it started with 15/Mbs but it slowly comes down to 7/Mbs with 7GB left to go. I went to sleep and let it copy. This morning(8hrs later), it's still copying with 650Mb left at 1/Mbs. I went to http://tower and it's showing both the destination disk and parity disk running. Strangely when I refresh the page, it's showing the read # from the destination disk is increasing with a couple bytes but the write is not doing anything.

 

I was tailing the syslog file before I went to sleep and the log doesn't have anything to show other than the drives went spin down mode. One more thing, while I was doing the copying, I was running the preclear script on my new 2tb drive but I thought it has anything to do with it.

 

Does anyone know what's going on? Do you think it's a bad motherboard Nic?

 

thanks in advance,

~joy

 

 

Something sounds wrong... Other than that, we can't tell since you did not post a syslog for analysis.

I was in a hurry to drop off the kids to school so I didn't get a chance to post this from home. I will upload my log once I get home. It wouldn't be surprise me if it's still copying 1MB left at .001/kbs when I get home.

 

thanks,

~joy

The copy is done but not sure when it finished. Attached is the syslog which also has the Hitachi preclear output.

 

I am planning to use a different computer to copy data over to the server just to make sure it's not my desktop that's acting up.

syslog20200421.txt

I think my Unraid is getting worst by the minute. I copied DayAfterTomorrow (30GB) to my disk8 and it went fine then I copy it to my disk9. Windows complains that it can't access disk9 so I cancelled the copy. When I check the disk9, DayAfterTomorrow is there with 6MB size. I try to delete it from Windows and my explorer crashed. I opened putty and try to do rm -rf DayAfterTomorrow but it hanged. I opened another putty do kill the rm PID but no luck. When I keep on refreshing the http://tower page, I can see the Reads # keep going up. I even try to do Spin Down but disk9 just won't quite.  I just don't get it. Hopefully someone out there knows what's going on. Attached is my log.

 

thanks,

~joy

syslog20100422.txt

Possible another Gigabyte motherboard horror story -from your log:

 

Apr 20 22:19:19 Tower kernel: ata10.00: HPA detected: current 3907029168, native 18446744073321613488

Apr 20 22:19:19 Tower kernel: ata10.00: ATA-8: WDC WD20EADS-00R6B0, 01.00A01, max UDMA/133

Apr 20 22:19:19 Tower kernel: ata10.00: 3907029168 sectors, multi 16: LBA48 NCQ (depth 0/32)

Apr 20 22:19:19 Tower kernel: ata10.01: HPA detected: current 3907029168, native 18446744073321613488

Apr 20 22:19:19 Tower kernel: ata10.01: ATA-8: Hitachi HDS722020ALA330, JKAOA28A, max UDMA/133

 

That's strange. I am using Supermicro C2SEA that's the little brother of C2SEA which has 2 more PCI slots. I thought the HPA issue only affects the harddrive size. When I view the size from the http://tower page. All my 2TB and 1TB drives have 552 at the end.

I did diff against JimmyJoe's C2SEA Level2 Testing log. http://lime-technology.com/forum/index.php?topic=3817.0 There's no HPA in there. Maybe I should do a clear CMOS on the MB. I did use this board for my desktop before so there may be some bios changes that I don't remember about.

 

thanks,

~joy

Where some of the drives maybe using in a different system before?

Where some of the drives maybe using in a different system before?

 

Yes, My original Unraid setup was Pentium 4 on Abit IC7-G motherboard with the SAT2-MV8 card. I just upgraded to C2D 9550 on Supermicro C2SEA last weekend.

 

thanks,

~joy

The HPA shown up 3 times. Does that mean 3 drives are affected? My Parity 2TB and Disk1 both have WD20EADS-00R6B0. Does this mean both disks are affected or one is repeating itself? Also, I don't get why the Hitachi has the HPA too. I just brought it and doing pre-clear. It's not even part of my Unraid.

 

ata9.00: HPA detected: current 3907029168, native 18446744073321613488

 ata9.00: ATA-8: WDC WD20EADS-00R6B0, 01.00A01, max UDMA/133

 

ata10.00: HPA detected: current 3907029168, native 18446744073321613488

 ata10.00: ATA-8: WDC WD20EADS-00R6B0, 01.00A01, max UDMA/133

 

 ata10.01: HPA detected: current 3907029168, native 18446744073321613488

 ata10.01: ATA-8: Hitachi HDS722020ALA330, JKAOA28A, max UDMA/133

 

Digging around the HPA threads. Are these commands correct if I want to remove the HPA?

 

disk0: hdparm -N p18446744073321613488 /dev/sdf

disk1: hdparm -N p18446744073321613488 /dev/sdh

hdparm -N p18446744073321613488 /dev/sdi

 

 

Also, one other thing that I don't get is why are the 2TB drives getting the infamous HPA and not the 7 1TB drives.

 

thanks,

~joy

 

 

 

 

The HPA shown up 3 times. Does that mean 3 drives are affected? My Parity 2TB and Disk1 both have WD20EADS-00R6B0. Does this mean both disks are affected or one is repeating itself? Also, I don't get why the Hitachi has the HPA too. I just brought it and doing pre-clear. It's not even part of my Unraid.

 

ata9.00: HPA detected: current 3907029168, native 18446744073321613488

 ata9.00: ATA-8: WDC WD20EADS-00R6B0, 01.00A01, max UDMA/133

 

ata10.00: HPA detected: current 3907029168, native 18446744073321613488

 ata10.00: ATA-8: WDC WD20EADS-00R6B0, 01.00A01, max UDMA/133

 

 ata10.01: HPA detected: current 3907029168, native 18446744073321613488

 ata10.01: ATA-8: Hitachi HDS722020ALA330, JKAOA28A, max UDMA/133

 

Digging around the HPA threads. Are these commands correct if I want to remove the HPA?

 

disk0: hdparm -N p18446744073321613488 /dev/sdf

disk1: hdparm -N p18446744073321613488 /dev/sdh

hdparm -N p18446744073321613488 /dev/sdi

 

 

Also, one other thing that I don't get is why are the 2TB drives getting the infamous HPA and not the 7 1TB drives.

 

thanks,

~joy

 

 

 

 

No, I don't think the drive is accurately reporting the native size, therefore, the commands you described are probably not going to work.

 

Joe L.

There may not be an HPA at all...

 

According to this post, the kernel module that interperts the size of large drives has a bug... resulting in the super-huge number you see for the "native size"

 

A post by RobJ indicated:

 

Re: Gigabyte EP-35-DS3R HPA or Not?

« Reply #6 on: November 08, 2009, 11:48:05 PM »

Reply with quoteQuote

By the way, the original poster is using v4.3.3, and that version and even several since then have a bug in the Linux kernel module that deals with those sector counts.  For these large drives, you may see a faulty HPA error in your syslog, looking similar to the following:

Code:

 

HPA detected: current 2930277168, native 18446744072344861488

 

The 'current' is the correct sector count, the 'native' is always an enormous number completely out of range, a bad interpretation of the bytes encoding the number.  Recent versions have fixed this.  You can still determine if this is a Gigabyte HPA by examining the last 3 digits of the 'current', if 168 then full size, if 055 then a true HPA.

 

This little 'rule' does not necessarily apply to older drives.

Since your drives are reporting current sizes ending with "168" they are indeed full size.

 

Joe L.

There may not be an HPA at all...

 

According to this post, the kernel module that interperts the size of large drives has a bug... resulting in the super-huge number you see for the "native size"

 

A post by RobJ indicated:

 

Re: Gigabyte EP-35-DS3R HPA or Not?

« Reply #6 on: November 08, 2009, 11:48:05 PM »

Reply with quoteQuote

By the way, the original poster is using v4.3.3, and that version and even several since then have a bug in the Linux kernel module that deals with those sector counts.  For these large drives, you may see a faulty HPA error in your syslog, looking similar to the following:

Code:

 

HPA detected: current 2930277168, native 18446744072344861488

 

The 'current' is the correct sector count, the 'native' is always an enormous number completely out of range, a bad interpretation of the bytes encoding the number.  Recent versions have fixed this.  You can still determine if this is a Gigabyte HPA by examining the last 3 digits of the 'current', if 168 then full size, if 055 then a true HPA.

 

This little 'rule' does not necessarily apply to older drives.

Since your drives are reporting current sizes ending with "168" they are indeed full size.

 

Joe L.

 

Thank you, Joe. This makes sense because I see all my drives end with 552 from http://tower page. I also dig up my old syslog from my P4 setup. The HPA was there. So I guess this bug is not just on v4.3.3 but also on v4.4.2. JimmyJoe's C2SEA Level2 Testing log didn't show any HPA because he is using 1TB and 500GB drives.

 

I've put my old P4 ethernet network card back to C2SEA board and let's see if that fix the weird problems that I am having. Later, I will probably upgrade to 4.5.3 after I am done with the new Hitachi drive.

 

thanks,

~joy

Just to follow up. I've upgraded to 4.5.3 and I don't see the HPA from my log. I must say, the write speed improvement from 15MB/sec to 25MB/sec is a nice jump.

 

thanks,

~joy