Mailing List Archive

HPA - more information
ok - I've done some more reading of HPA and know a little more about how it
works. As usual, Wikipedia is pretty good:
http://en.wikipedia.org/wiki/Host_protected_area

The OS is perfectly capable of detecting when HPA is in use - indeed the
dmesg log will indicate if HPA is enabled for any particular drive. Also
[sudo hdparm -N /dev/sdX] will give details.

The problem with Gigabyte motherboards is that on startup, they apparently
look at the first disk initialised (not necessily the disk on the first
port) to see if a copy of the BIOS is saved on the end of the disk. If
not, then the BIOS will enable HPA, steal the last few megabytes of the
disk, and overwrite it with a copy of the BIOS. This is obviously bad and
could very easily corrupt any existing the filesystem on that disk.

Apparently newer Gigabyte motherboards have this feature disabled by
default. As mentioned in my last post, looks like some older motherboards
had a bug where instead of reserving a few megabytes off the end of the
disk, it actually reserved a full 1TB. There is no way to disable this
feature on older Gigabyte motherboards. There are a large number of posts
and articles on the internet talking about corrupted filesystems and RAID
arrays caused by this bug. General consensus seems to be to avoid older
Gigabyte motherboards completely.

I'm now wondering if the kernal version had nothing to do with the issue.
Maybe the system drive on my Myth box was just a bit slow starting up and
meant that the BIOS decided to use my 3TB drive for the BIOS backup? I did
reboot several times while trying to fix the issue, but still...

Also, assuming that my motherboard did in fact write a BIOS copy to the end
of the disk - why didn't xfs_repair find any issues once I got my partition
back?
Re: HPA - more information [ In reply to ]
On Fri, 14 Mar 2014 10:04:28 +1300, you wrote:

>ok - I've done some more reading of HPA and know a little more about how it
>works. As usual, Wikipedia is pretty good:
> http://en.wikipedia.org/wiki/Host_protected_area
>
>The OS is perfectly capable of detecting when HPA is in use - indeed the
>dmesg log will indicate if HPA is enabled for any particular drive. Also
>[sudo hdparm -N /dev/sdX] will give details.
>
>The problem with Gigabyte motherboards is that on startup, they apparently
>look at the first disk initialised (not necessily the disk on the first
>port) to see if a copy of the BIOS is saved on the end of the disk. If
>not, then the BIOS will enable HPA, steal the last few megabytes of the
>disk, and overwrite it with a copy of the BIOS. This is obviously bad and
>could very easily corrupt any existing the filesystem on that disk.
>
>Apparently newer Gigabyte motherboards have this feature disabled by
>default. As mentioned in my last post, looks like some older motherboards
>had a bug where instead of reserving a few megabytes off the end of the
>disk, it actually reserved a full 1TB. There is no way to disable this
>feature on older Gigabyte motherboards. There are a large number of posts
>and articles on the internet talking about corrupted filesystems and RAID
>arrays caused by this bug. General consensus seems to be to avoid older
>Gigabyte motherboards completely.
>
>I'm now wondering if the kernal version had nothing to do with the issue.
>Maybe the system drive on my Myth box was just a bit slow starting up and
>meant that the BIOS decided to use my 3TB drive for the BIOS backup? I did
>reboot several times while trying to fix the issue, but still...
>
>Also, assuming that my motherboard did in fact write a BIOS copy to the end
>of the disk - why didn't xfs_repair find any issues once I got my partition
>back?

The data areas for the xfs filesystem are a relatively small portion
of the data on an xfs partition, and that is all that xfs_repair will
be checking. So if the BIOS write did not hit any of the xfs data
areas, then xfs_repair will not see any problem. But the BIOS data
may still have overwritten part of a file somewhere, especially if the
partition was full (as MythTV recording partitions tend to be after a
while).

BTW You must have actually been using the command "apt-get
dist-upgrade" to get a new kernel - "apt-get upgrade" will not install
anything new, just upgrade things that are already installed.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: HPA - more information [ In reply to ]
On Fri, Mar 14, 2014 at 2:39 PM, Stephen Worthington
<stephen_agent@jsw.gen.nz> wrote:
> On Fri, 14 Mar 2014 10:04:28 +1300, you wrote:
>
>>ok - I've done some more reading of HPA and know a little more about how it
>>works. As usual, Wikipedia is pretty good:
>> http://en.wikipedia.org/wiki/Host_protected_area
>>
>>The OS is perfectly capable of detecting when HPA is in use - indeed the
>>dmesg log will indicate if HPA is enabled for any particular drive. Also
>>[sudo hdparm -N /dev/sdX] will give details.
>>
>>The problem with Gigabyte motherboards is that on startup, they apparently
>>look at the first disk initialised (not necessily the disk on the first
>>port) to see if a copy of the BIOS is saved on the end of the disk. If
>>not, then the BIOS will enable HPA, steal the last few megabytes of the
>>disk, and overwrite it with a copy of the BIOS. This is obviously bad and
>>could very easily corrupt any existing the filesystem on that disk.
>>
>>Apparently newer Gigabyte motherboards have this feature disabled by
>>default. As mentioned in my last post, looks like some older motherboards
>>had a bug where instead of reserving a few megabytes off the end of the
>>disk, it actually reserved a full 1TB. There is no way to disable this
>>feature on older Gigabyte motherboards. There are a large number of posts
>>and articles on the internet talking about corrupted filesystems and RAID
>>arrays caused by this bug. General consensus seems to be to avoid older
>>Gigabyte motherboards completely.
>>
>>I'm now wondering if the kernal version had nothing to do with the issue.
>>Maybe the system drive on my Myth box was just a bit slow starting up and
>>meant that the BIOS decided to use my 3TB drive for the BIOS backup? I did
>>reboot several times while trying to fix the issue, but still...
>>
>>Also, assuming that my motherboard did in fact write a BIOS copy to the end
>>of the disk - why didn't xfs_repair find any issues once I got my partition
>>back?
>
> The data areas for the xfs filesystem are a relatively small portion
> of the data on an xfs partition, and that is all that xfs_repair will
> be checking. So if the BIOS write did not hit any of the xfs data
> areas, then xfs_repair will not see any problem. But the BIOS data
> may still have overwritten part of a file somewhere, especially if the
> partition was full (as MythTV recording partitions tend to be after a
> while).
>
> BTW You must have actually been using the command "apt-get
> dist-upgrade" to get a new kernel - "apt-get upgrade" will not install
> anything new, just upgrade things that are already installed.

Yes it WILL upgrade a kernel, but not to a new major version.

And please posters, it is kernel, not kernal.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/