headers
Thomas Jackowski | 5 Feb 2011 11:17
Picon
Favicon

AMD SB850 Raid - Should an output like this happen?

Hello,

I have a RAID10 setup on my AMD SB850 Raid chipset. Well I noticed from
the very beginning issues with dmraid and its outputs.

zusteller ~ # dmraid -r
/dev/sdd: pdc, "pdc_cficbgcda-1", stripe, ok, 1953124992 sectors, data <at>  0
/dev/sdc: pdc, "pdc_cficbgcda-1", stripe, ok, 1953124992 sectors, data <at>  0
/dev/sdb: pdc, "pdc_cficbgcda-0", stripe, ok, 1953124992 sectors, data <at>  0
/dev/sda: pdc, "pdc_cficbgcda-0", stripe, ok, 1953124992 sectors, data <at>  0
zusteller ~ # dmraid -s -s pdc_cficbgcda
*** Active Superset
name   : pdc_cficbgcda
size   : 3906249984
stride : 128
type   : raid10
status : ok
subsets: 2
devs   : 4
spares : 0
--> Active Subset
name   : pdc_cficbgcda-0
size   : 3906249984
stride : 128
type   : stripe
status : ok
subsets: 0
devs   : 2
spares : 0
--> Active Subset
(Continue reading)

Permalink | Reply | 1 comment |
headers
Anthony B | 6 Feb 2011 05:19
Picon
Favicon

(unknown)


I have a problem i think/hope related to a hpa (host protected area) my original post is here http://kubuntuforums.net/forums/index.php?topic=3115533.0

Anyway, it boils down to an old board of mine set a hpa to store a bios backup, not my choice, i liked it off but it
was a default on setting so it would get enabled every time i reset cmos. That board died. I bought a new board
and a new disk and forgot about hpa. I created a raid array with said old disk and new disk. Installed an m$ os
on raid array. All worked well.

Needed to mount array under Linux, hit problem. That old disk wasn't detected as part of the array and on
reboot wasn't detected as part of an array by the boards own raid manager but power cycling fixed it. I
checked logs, etc and found nothing.

Now i dumped the last 3000 sectors of the offending disk and saw references to a bios manufacturer, the name
and the chipset of old board. The cogs in my brain turned slightly and i thought 'hpa'. Got a low level disk
utility and sure enough there was a hpa on the disk, right at the end. I just disabled it. Bad idea, the array
is no longer detected by the on-board manager.

I booted back to Linux and my brain ticked once more, on other Linux systems i saw the boot console instead of
it being all hidden away and i remember a few years ago i saw a message for another disk saying something
about unlocking hpa. I grepped logs for hpa and found:

ata1.00: HPA unlocked: 976771055 -> 976773168, native 976773168

Nice, everything has fallen into place now. I know why my disk would only be detected as part of the array
after power cycling and why dmraid wouldn't detect it but, my array is broken and i want ALL my bytes back.
All i have to do is re-enable hpa at the right place to get the raid working again and tell the kernel at boot
not to mess with hpa. But like i say MY BYTES AND I WANT THEM BACK.

My point is, could dmraid be aware of hpa's and adjust itself accordingly? If nothing else, just scream a
great big error message about disabling hpa detection at kernel boot time but never remove the hpa
(Continue reading)

Permalink | Reply | 2 comments |
headers
Phillip Susi | 8 Feb 2011 21:09
Picon

Re: HPA and dmraid

You should always set a subject when sending email.

On 2/5/2011 11:19 PM, Anthony B wrote:

> ata1.00: HPA unlocked: 976771055 -> 976773168, native 976773168

Unfortunately when the libata transition happened, Ubuntu decided to
unlock the HPA by default, because there was a bug in the old ide driver
that did the same.  Some work has been under way lately to correct this
issue upstream by having the kernel only unlock the HPA automatically if
it is required to access a defined partition.

> Nice, everything has fallen into place now. I know why my disk would
> only be detected as part of the array after power cycling and why
> dmraid wouldn't detect it but, my array is broken and i want ALL my
> bytes back. All i have to do is re-enable hpa at the right place to
> get the raid working again and tell the kernel at boot not to mess
> with hpa. But like i say MY BYTES AND I WANT THEM BACK.

Yep, that's what you need to do.
Permalink | Reply | 1 comment |
headers
Anthony Blakemore | 9 Feb 2011 01:47
Picon
Favicon

Re: HPA and dmraid


  On 08/02/2011 20:09, Phillip Susi wrote:
> You should always set a subject when sending email.
Yes sorry, i had to use a friends box with ff4 thats not playing nice 
with m$ live mail. I had to paste my message and hit send before the 
page refreshed again.
> On 2/5/2011 11:19 PM, Anthony B wrote:
>
>> ata1.00: HPA unlocked: 976771055 ->  976773168, native 976773168
> Unfortunately when the libata transition happened, Ubuntu decided to
> unlock the HPA by default, because there was a bug in the old ide driver
> that did the same.  Some work has been under way lately to correct this
> issue upstream by having the kernel only unlock the HPA automatically if
> it is required to access a defined partition.
>
That would have saved me a lot of trouble. I was about to dd /dev/zero 
to both disks and start over again but knowing what i do now, that still 
would not have worked.
>> Nice, everything has fallen into place now. I know why my disk would
>> only be detected as part of the array after power cycling and why
>> dmraid wouldn't detect it but, my array is broken and i want ALL my
>> bytes back. All i have to do is re-enable hpa at the right place to
>> get the raid working again and tell the kernel at boot not to mess
>> with hpa. But like i say MY BYTES AND I WANT THEM BACK.
> Yep, that's what you need to do.
>
Once i'd figured out the nvidia raid metadata was written to the second 
to last sector, i re-enabled hpa to the position in the log, set kernel 
command "libata.ignore_hpa=0", dd'd the last two sectors to a file, then 
dd'd it back on with hpa unset. Now both os'es are happy and so am i.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Giacomo Montagner | 9 Feb 2011 22:03
Picon

Re: AMD SB850 Raid - Should an output like this happen?

On Sat, 05 Feb 2011 11:17:51 +0100
Thomas Jackowski <thomas+lists.redhat.ataraid <at> jackowski.de> wrote:

> ERROR: pdc: wrong # of devices in RAID set "pdc_cficbgcda-1" [1/2] on
> /dev/sdd
> ERROR: pdc: wrong # of devices in RAID set "pdc_cficbgcda-1" [1/2] on
> /dev/sdc
> ERROR: pdc: wrong # of devices in RAID set "pdc_cficbgcda-0" [1/2] on
> /dev/sdb
> ERROR: pdc: wrong # of devices in RAID set "pdc_cficbgcda-0" [1/2] on
> /dev/sda

Hi, 
I'm quite scared by those error messages; it happens to me, too: 

# dmraid -r
ERROR: ddf1: seeking device "/dev/dm-8" to 18446744073709421056
ERROR: hpt37x: seeking device "/dev/dm-8" to 4608
ERROR: hpt45x: seeking device "/dev/dm-8" to 18446744073709547008
ERROR: pdc: seeking device "/dev/dm-8" to 137438913024
ERROR: pdc: seeking device "/dev/dm-8" to 137438920192
ERROR: pdc: seeking device "/dev/dm-8" to 137438927360
ERROR: pdc: seeking device "/dev/dm-8" to 137438934528
ERROR: sil: seeking device "/dev/dm-8" to 18446744073709289984
/dev/sdd: pdc, "pdc_ddbffbcej", mirror, ok, 1953124992 sectors, data <at>  0
/dev/sdc: pdc, "pdc_dcidibfa", stripe, ok, 976562432 sectors, data <at>  0
/dev/sdb: pdc, "pdc_ddbffbcej", mirror, ok, 1953124992 sectors, data <at>  0
/dev/sda: pdc, "pdc_dcidibfa", stripe, ok, 976562432 sectors, data <at>  0

ERROR: ddf1: seeking device "/dev/dm-8" to 18446744073709421056
(Continue reading)

Permalink | Reply | 0 comments |

Gmane