Official GIGABYTE Forum

Solution: GA-P35-DS3 Rev 1.0 BIOS F14 SATA AHCI Native Mode hangs at HDD detecti

kondra

  • 12
  • 0
-----------------------------------------------------------------------------------------------------------------
Solution: GA-P35-DS3 Rev 1.0 BIOS F14 SATA AHCI Native Mode hangs at HDD detection
-----------------------------------------------------------------------------------------------------------------
The following is the solution for many hangs inside the AHCI controller device enumeration at BIOS startup.
In addition other errors that appear to be strange are also related to a combination of firmware and Windows
Setup CD bugs. If you follow the listed steps I am not responsible for any damage that may occur! Keep in
mind that I am a bloody noob, which still tries to understand how these computers work, but getting better
in it every day.


-----------------------------------------------------------------------------------------------------------------
Scenario 1
-----------------------------------------------------------------------------------------------------------------
Error
-------
- BIOS is set to AHCI native SATA Mode
  BIOS > Integrated Peripherals >
  SATA AHCI Mode = AHCI
  SATA Port0-1 Native Mode = Enabled
- HDD is connected
- at the AHCI device scan we see the following text on the screen:
  Serial ATA AHCI BIOS, Version iSrc 1.20E
  Copyright (c) 2003-2008 Intel Corporation
  ** This version supports only Hard Disk and CDROM drives **
  Please wait. This will take few seconds.
  Controller Bus#00, Device#1F, Function#02: 04 Ports, 02 Devices
- the cursor is blinking infinite and no device can be enumerated

Solution
----------
- turn off computer
- disconnect HDD
- turn on computer and go to BIOS
- set BIOS to Legacy IDE Mode
  BIOS > Integrated Peripherals >
  SATA AHCI Mode = Disabled
  SATA Port0-1 Native Mode = Disabled
- save BIOS changes and turn off computer
- connect the HDD which caused the problem and a 2nd HDD for launching XP
- in XP use a hex editor, I like to use "010 Editor" and open the PhysicalDrive of the HDD causing the hang
- in the MBR, which is the very first sector, set the 3 bytes starting at offset 0x1C3 to FE FF FF and save
  the changes to the PhysicalDrive
- now the controller can be set back to AHCI native mode in BIOS and the hang disappears

Simulate the problem
----------------------
- use a HDD with a MBR and an active 1st primary partition, this is normally a HDD for booting an OS
- use a hex editor and set the 3 bytes starting at offset 0x1C3 to 01 08 00
- set BIOS to AHCI native SATA Mode
  BIOS > Integrated Peripherals >
  SATA AHCI Mode = AHCI
  SATA Port0-1 Native Mode = Enabled
- after the next reboot the AHCI device enumeration will hang infinite


-----------------------------------------------------------------------------------------------------------------
Scenario 2
-----------------------------------------------------------------------------------------------------------------
Error
-------
- BIOS is set to AHCI native SATA Mode
  BIOS > Integrated Peripherals >
  SATA AHCI Mode = AHCI
  SATA Port0-1 Native Mode = Enabled
- HDD is connected
- the primary partition start offset is 2048 sectors, which is equal to 1.048.576 bytes (1 * 1024 * 1024),
  this is an alignment value normally used for SSDs to improve read / write speed
- Windows 2003 Server x86 with integrated SP2 is used to install the HDD
- you press F6 to choose an AHCI driver floppy disk during setup
- we use the already present partition and do only a quick NTFS format or we choose "Leave the current file
  system intact (no changes)" if available
- the OS installs and on the 1st reboot directly after the AHCI Controller device scan you read one of the
  following error messages:
  - A disk read error occurred
  - Unable to load operating system
  - Error loading operating system

Solution
----------
- turn computer off
- connect the HDD which caused the problem and a 2nd HDD for launching XP
- turn computer on
- set BIOS to IDE Legacy Mode for XP to start
- in XP use a hex editor and open the PhysicalDrive of the HDD that you installed Windows Server 2003 on
- in the MBR set the 3 bytes starting at offset 0x1C3 to FE FF FF and save the changes to the PhysicalDrive
- turn computer off
- disconnect XP HDD
- turn on computer
- switch BIOS to native AHCI Mode
- now Windows 2003 Server / Windows XP Setup will boot and continue
- you will now have a properly aligned partition starting at sector 2048

Simulate the problem
----------------------
- set BIOS to legacy IDE Mode for XP to start
- use a completely blank HDD, you can also blank a HDD in XP with "010 Editor"
- use diskpar on XP on this blank HDD
- type "diskpar -i 0" and "diskpar -i 1" and look which drive number matches the blank HDD, no partitions
  should be shown
- let assume your blank HDD has drive number 1
- type "diskpar -s 1"
- set start offset to 2048 sectors, which is equal to 1.048.576 bytes (1 * 1024 * 1024)
- set partition size to e.g. 25000 MB (25 GB = 25000 * 1024 * 1024 = 26.214.400.000 bytes)
- start XP Disk Manager diskmgmt.msc and format the new partition, also set it to active
- turn off computer
- disconnect XP HDD
- turn on computer
- set BIOS to native AHCI Mode
- run Windows 2003 Server / Windows XP Setup CD
- press F6 to choose an AHCI driver floppy disk during setup
- we install into the already present partition and choose "Leave the current file system intact (no changes)"
- the OS installs and on the 1st reboot directly after the AHCI Controller device scan you read one of the
  following error messages:
  - A disk read error occurred
  - Unable to load operating system
  - Error loading operating system

kondra

  • 12
  • 0
-----------------------------------------------------------------------------------------------------------------
How Windows XP SP3 fixes the CHS problem so the AHCI Controller never hangs and no error messages are displayed
-----------------------------------------------------------------------------------------------------------------
For partitions bigger than 8.4 GB XP SP3 does the following:
- XP SP3 x86 sets the CHS last sector in partition correctly to FE FF FF if the partition is bigger than 8.4 GB
- we can create a partition with diskpar with a start offset of 2048 sectors and a size of 25000 MB
- start XP setup from CD and load the AHCI driver with F6
- then quick format the existing 25 GB partition during XP CD setup and use the diskpar created partition for OS
  install
- on the 1st reboot we see no problem, everything works as expected
- even the NTFS backup volume boot record is found in the last sector of the partition, because XP uses
  LBA addressing

For partitions smaller than 8.4 GB XP does the following which I will explain in 2 examples:
Example 1
- 5000 MB partition = 5000 * 1024 * 1024 = 5.242.880.000 bytes / 512 = 10.240.000 LBAs (0x9C4000 LBAs)
- last sector in partition is 10.242.047
- diskpar writes 0x89 0x8C 0x7D at partition creation for last CHS in partition, C:637 H:137 S:12
- if we use a geometry of 255 heads and 63 sectors the CHS values C:637 H:137 S:12 result in 10.242.047 as the last sector (correct!)
- after Windows XP setup the following is in the MBR:
  - last sector in partition if calculated correctly should be 0x9C4000 LBAs + 0x800 start offset - 1 = 0x9C47FF (10.242.047)
  - CHS start sector is 0x20 0x09 0x01 -> H:32 S:9 C:1 -> this is the correct 2048 if we use a geometry of heads 138 and sectors 12
  - CHS last sector in partition is 0x89 0xCC 0xFF -> H:137 S:12 C:1023 -> this is wrong for the geometry of heads 138 and sectors 12,
    last sector is 1.695.743 (0x19DFFF) which results in a partition size of 0x19DFFF + 1 - 0x800 = 0x19D800 * 512 = 867.172.352 bytes (wrong!)
Example 2
- 3000 MB partition = 3000 * 1024 * 1024 = 3.145.728.000 bytes / 512 = 6.144.000 LBAs (0x5DC000)
- last sector in partition is 6.146.047
- enter the following in PTCalc
  - LBA Sector = 6146047
  - Disk Geometry Head = 255, Sectors = 63
  - press LBA to CHS
  - we get C:382 H:146 S:20
- diskpar writes 0x92 0x54 0x7E at partition creation for last CHS in partition
- if we use a geometry of 255 heads and 63 sectors the CHS values C:382 H:146 S:20 result in 6.146.047 as the last sector (correct!)
- Windows XP setup sets it's disk geometry to heads = 0x92 + 1 (146d + 1) and sectors = 0x14 (20d)
- enter the following in PTCalc to calculate the CHS start sector
  - Disk Geometry Head = 147, Sectors = 20
  - LBA Sector = 2048
  - press LBA to CHS
  - we get C:0 H:102 S:9
- CHS start sector is then 0x66 0x09 0x00 -> C:0 H:102 S:9 -> this is the correct 2048 if we use a geometry of heads 147 and sectors 20
- CHS last sector is set as 0x92 0xD4 0xFF, the values for heads and sectors are taken from diskpar values, the cylinder is set to 1023
- this last sector results in 3.010.559 (0x2DEFFF) which results in a partition size of 0x2DEFFF + 1 - 0x800 = 0x2DE800 * 512 = 1.540.358.144 bytes (wrong!)

We see that the CHS last sector value is set wrong by XP SP3 setup. But it is set wrong, because MS knows that the disk geometry relies
on these CHS last sector values. If these are not fixed it is not possible to find the NTFS volume boot record at the correct sector.
Keep in mind that XP releases older than SP3 are still affected by the above mentioned bugs.


-----------------------------------------------------------------------------------------------------------------
Best practice to get XP older than SP3 and Windows Server 2003 Setup CD running with correct alignment
-----------------------------------------------------------------------------------------------------------------
- set BIOS to IDE Legacy Mode for XP to start
- use a completely blanked target HDD, you can also blank a HDD in XP with "010 Editor"
- connect the target HDD as a 2nd HDD in a running XP system
- use diskpar on XP on this blank HDD
- type "diskpar -i 0" and "diskpar -i 1" and look which drive number matches the blank HDD, no partitions
  should be shown
- let assume your blank HDD has drive number 1
- type "diskpar -s 1"
- set start offset to 2048 sectors, which is equal to 1.048.576 bytes (1 * 1024 * 1024)
- set partition size to e.g. 25000 MB (25 GB = 25000 * 1024 * 1024 = 26.214.400.000 bytes)
- optional:
  - start XP Disk Manager diskmgmt.msc and format the new partition, also set it to active
  - check with a hex editor that the NTFS volume boot record starting at offset 0x100000 has the following
    three values set correctly:
    WORD at offset 0x18 Sectors per Track = 3F 00
    WORD at offset 0x1A Number of Heads (Sides) = FF 00
    DWORD at offset 0x1C Number of "Hidden Sectors" (Cyl=0 Head=0) = 00 08 00 00
    The complete 8 bytes starting at absolute physical disk offset 0x100018 should then look like this:
    3F 00 FF 00 00 08 00 00
  - normally these values are set, but it is better to double check it
- turn off computer
- disconnect XP HDD
- turn on computer
- set BIOS to native AHCI Mode
- run Windows 2003 Server / Windows XP Setup CD
- press F6 to choose an AHCI driver floppy disk during setup
- we install into the already present partition and choose "Leave the current file system intact (no changes)",
  if we haven't formatted the disk in XP already we can do a quick format now
- the OS installs and on the 1st reboot directly after the AHCI Controller device scan you read one of the
  following error messages:
  - A disk read error occurred
  - Unable to load operating system
  - Error loading operating system
- turn computer off
- connect the target HDD as a 2nd HDD in a running XP system
- turn computer on
- set BIOS to IDE Legacy Mode for XP to start
- in XP use a hex editor and open the PhysicalDrive of the target HDD
- in the MBR set the 3 bytes starting at offset 0x1C3 to FE FF FF and save the changes to the PhysicalDrive
- turn computer off
- disconnect XP HDD
- turn on computer
- switch BIOS to native AHCI Mode
- now Windows 2003 Server / Windows XP Setup will boot and continue
- you will now have a properly aligned partition starting at sector 2048
- the NTFS backup volume boot record is also at the correct position in the last sector of the partition

kondra

  • 12
  • 0
-----------------------------------------------------------------------------------------------------------------
Technical Description
-----------------------------------------------------------------------------------------------------------------
At MBR offset 0x1C3 we find the CHS address of the last absolute sector in the partition. For partitions which
begin or end beyond the 1024th cylinder, the three CHS bytes should always be filled with: FE FF FF. For smaller
partitions these values should have the correct calculated bytes and NOT FE FF FF. But the Gigabyte GA-P35-DS3
Intel ICH9 AHCI Controller has always problems with the real values, at least if we also change the partitions
start offset to align it for an SSD for example and do not use the standard partition start offset of 63 sectors.
In addition the Windows Server 2003 setup has also a bug for computing the CHS address of the last absolute
sector in the partition. This seems to be calculated from the number of sectors in partition at MBR offset
0x1CA. But the setup does not use a drive geometry of 255 heads / 63 sectors. Instead Microsoft uses 240 heads /
63 sectors as geometry. Therefore if you use diskpar to create a partition the CHS and LBA values are based
on 255 heads and 63 sectors. This way the partitions LBA size and the CHS values do not match for Windows
2003 setup and it corrects the CHS value at offset 0x1C3 to fit the 240 heads / 63 sectors geometry. This
bug is also confirmed by MS and they have a patch for it at the following URLs:
http://support.microsoft.com/kb/931761/en-us
http://support.microsoft.com/kb/931760/en-us

I tried these two fixes and recognized that the CHS is now based on 255 heads and 63 sectors. But there is
still one problem left. If we cross the 1024 cylinder boundary the CHS is NOT changed to FE FF FF. Instead
the cylinder is set correctly to 1023, but the head and sectors are still calulated based on the partitions
size in sectors, which simply is wrong in my opinion. So if the setup CD would do it right we would only run
into the problem for partitions that are smaller than 8,4 GB, because the max addressable CHS value is
8.422.686.720 bytes. For bigger partitions there should be no problem. We see that XP SP3 does it right so
there is indeed still some bug left.

But not Microsoft alone can be blamed for the problems. After using the patch from MS knowledgebase, the
CHS is correct for partition sizes smaller than 8.4 GB. So I tested the complete 2003 installation on a
3 GB partition and recognized that the same problem shows again. We only see the message "Error loading
operating system" after the 1st restart of 2003 setup. I double checked the CHS values and they are
completely correct and based on 255 heads and 63 sectors drive geometry. If we correct these CHS values
again to FE FF FF, which is wrong according to the specs, the AHCI Controller will boot the HDD. The Problem
is that the Windows XP / 2003 Server MBR calls the BIOS function int13h ah=08h GET CURRENT DRIVE PARAMETERS
to get the disks geometry. But in AHCI mode this function call returns CHS head and sector values based on
offset 0x1C3 of the MBR. So the CHS last sector in partition values are taken to return the disk geometry
on executing the MBR and this results in a wrong offset for the NTFS volume boot record, which causes errors
like "Error loading operating system". As it seems the AHCI Controller uses the CHS value for the last sector
in the partition for calculating the disk geometry and returning this geometry for int13h ah=08h function call.
During tests I even saw that the disk geometries returned in AHCI and IDE Mode for the same HDD are different.

Another strange thing is that the AHCI Controller device detection can hang caused by these 3 CHS bytes
in the MBR. To be honest I used some uncommon values in the Simulation of Error Scenario 1, but if you
partition the disk several times and the drive geometry gets changed by diskpar, diskpart and
Windows Setup CD, it is possible that you end with a controller hang, because the CHS values get even
more corrupted from time to time. Not to mention if you try to edit the partition's LBA size manually in
the MBR without changing the CHS last sector in partition. I found out that the CHS values can cause a
AHCI Controller hang caused by an integer overflow at a division inside the firmware. Read on for the
firmware analysis of AHCI.bin of F14 BIOS.


-----------------------------------------------------------------------------------------------------------------
Firmware Analysis of AHCI.bin
-----------------------------------------------------------------------------------------------------------------
To analyze the firmware and find the bug I did the following steps:
- downloaded newest Gigabyte GA-P35-DS3 BIOS labeled P35DS3.F14
- download cbrom182
- attention the original BIOS file gets changed by the following actions, so you should have a copy of it
- to display all combined ROMs inside the BIOS file type:
  cbrom182 P35DS3.F14 /d
- we see the following list, what we are interested in is the entry number 8:
Code: [Select]
  No. Item-Name         Original-Size   Compressed-Size Original-File-Name
  ================================================================================
    0. System BIOS       20000h(128.00K)  151ABh(84.42K)  p35ds3.BIN
    1. XGROUP CODE       0EBC0h(58.94K)   0A4F1h(41.24K)  awardext.rom
    2. ACPI table        04D12h(19.27K)   01909h(6.26K)   ACPITBL.BIN
    3. EPA LOGO          0168Ch(5.64K)    0030Dh(0.76K)   AwardBmp.bmp
    4. GROUP ROM[18]     02E70h(11.61K)   02003h(8.00K)   ggroup.bin
    5. GROUP ROM[20]     00E20h(3.53K)    00B33h(2.80K)   ffgroup.bin
    6. YGROUP ROM        0C100h(48.25K)   06708h(25.76K)  awardeyt.rom
    7. GROUP ROM[ 0]     08360h(32.84K)   02D9Eh(11.40K)  _EN_CODE.BIN
    8. PCI ROM[A]        04000h(16.00K)   02B46h(10.82K)  AHCI.BIN
    9. PCI ROM[B]        07A00h(30.50K)   04479h(17.12K)  JMB59.BIN
   10. MINIT             0CBC0h(50.94K)   0CBF4h(50.99K)  MEMINIT.BIN
   11. PCI ROM[C]        0C800h(50.00K)   079FDh(30.50K)  rtegrom.lom
   12. LOGO BitMap       4B30Ch(300.76K)  05CE3h(23.22K)  ds3.bmp
   13. LOGO1 ROM         00B64h(2.85K)    00520h(1.28K)   dbios.bmp
   14. GV3                022ADh(8.67K)   00BD6h(2.96K)   PPMINIT.ROM
   15. OEM0 CODE         028ABh(10.17K)   01E1Bh(7.53K)   SBF.BIN
   16. OEM2 CODE         01000h(4.00K)    00092h(0.14K)   AFSC_HDR.ROM
- extract AHCI.BIN which is number 8 in the list above with the following cmds
  cbrom182 P35DS3.F14 /PCI extract
  cbrom182 V1.82 [04/11/07] (C)Phoenix Technologies 2001-2007
  PCI ROM - - - A : AHCI.BIN
  PCI ROM - - - B : JMB59.BIN
  PCI ROM - - - C : rtegrom.lom
  Enter a choice:a
  Enter an extract file Name :(AHCI.BIN) [PCI-A] ROM is extracted to AHCI.BIN
- now we should have AHCI.BIN and the file FILE_BUF.BIN
- FILE_BUF.BIN can be deleted, it is only the compressed AHCI.BIN
- disassemble AHCI.BIN in IDA as 16 bit code
- go to address seg000:3670
- we see the following code, as example I used the adapter hang causing values 01 08 00:
Code: [Select]
 seg000:3670                 push    es
  seg000:3671                 les     bx, cs:dword_3B95 ; cs:dword_3B95 points to the buffer for the Master Boot Record
  seg000:3676                 mov     cx, 1           ; ch = low eight bits of cylinder number = 0
  seg000:3676                                         ; cl = sector number 1-63 (bits 0-5) = 1, high two bits of cylinder (bits 6-7, hard disk only)
  seg000:3679                 mov     dh, 0           ; dh = head number = 0
  seg000:367B                 mov     dl, gs:[bp+0]   ; dh = drive number (bit 7 set for hard disk)
  seg000:367F                 mov     ax, 201h        ; int13 read 1 sector at offset 0, Master Boot Record
  seg000:3682                 call    int13_sub_18BC
  seg000:3685                 jb      short loc_36DE  ; cf set on error, jump on error
  seg000:3687                 cmp     word ptr es:[bx+1FEh], 0AA55h ; es:bx data buffer, check MBR end signature 0x55AA
  seg000:368E                 jnz     short loc_36DE  ; jump if no signature was found
  seg000:3690                 add     bx, 1BEh        ; go to 1st partition table start offset 1BEh in MBR
  seg000:3694                 mov     cx, 4           ; do this for all 4 partition tables
  seg000:3697
  seg000:3697 loc_3697:                               ; CODE XREF: seg000:36ADj
  seg000:3697                 mov     ax, es:[bx+5]   ; CHS address of last partition in sector, head = 1, sector = 8
  seg000:369B                 inc     al              ; increment head count, head = 2 after this
  seg000:369D                 and     ah, 3Fh         ; get only bits 0 to 5 for the sector, 6 and 7 are the upper cylinder bits
  seg000:36A0                 push    ax              ; save value 0802h, head = 2, sector = 8
  seg000:36A1                 mul     ah              ; ax = al * ah = heads * sectors = 10h
  seg000:36A3                 mov     bp, ax          ; save result 10h in bp
  seg000:36A5                 or      ax, ax          ; check if ax == 0, this means we have sectors or heads equal to zero in the MBR
  seg000:36A7                 pop     ax              ; restore ax from stack, after this ax = 0802h, head = 2, sector = 8
  seg000:36A8                 jnz     short loc_36B1  ; we jump here, because ax != 0
  seg000:36AA                 add     bx, 10h         ; go to next partition table entry
  seg000:36AD                 loop    loc_3697
  seg000:36AF                 jmp     short loc_36DE
  seg000:36B1 ; ---------------------------------------------------------------------------
  seg000:36B1
  seg000:36B1 loc_36B1:                               ; CODE XREF: seg000:36A8j
  seg000:36B1                 push    ax              ; save value 0802h, head = 2, sector = 8
  seg000:36B2                 mov     cx, gs:[si]     ; gs:[si] = cylinders from geometry of disk, 1024 cylinders
  seg000:36B5                 mov     ah, gs:[si+3]   ; gs:[si+3] = sectors from geometry of disk, 63 sectors
  seg000:36B9                 mov     al, gs:[si+2]   ; gs:[si+2] = heads from geometry of disk, 255 heads
  seg000:36BD                 mul     ah              ; ax = al * ah = 255 heads * 63 sectors = 16065 (3EC1h)
  seg000:36BF                 mul     cx              ; dx:ax = ax * cx = 3EC1h * 400h (16065 * 1024) = FB0400h (16450560)
  seg000:36C1                 div     bp              ; dx:ax / bp = FB0400h / 10h, ax = quotient, dx = remainder, integer overflow in ax
- if we enter the code inside masm with the values heads = 1 and sectors = 8 we see that at address seg000:36C1 an integer
  overflow in ax happens which results in an exception inside the firmware
« Last Edit: March 27, 2012, 07:46:19 pm by kondra »

kondra

  • 12
  • 0
-----------------------------------------------------------------------------------------------------------------
MASM Windows Command Line Application to simulate the AHCI Firmware bug
-----------------------------------------------------------------------------------------------------------------
Code: [Select]
.486
.model flat,stdcall
option casemap:none

include \masm32\include\kernel32.inc
includelib \masm32\lib\kernel32.lib

.code

start:
; Attention: The following code line was edited by me for a better understanding of the code to 8 heads and 1 sector.
; In the original firmware code this is read from the MBR at es:bx buffer.
mov ax, 0801h ; CHS address of last partition in sector, head = 1, sector = 8
inc al ; increment head count, head = 2 after this
and ah, 3Fh ; get only bits 0 to 5 for the sector, 6 and 7 are the upper cylinder bits
push ax ; save value 0802h, head = 2, sector = 8
mul ah ; ax = al * ah = heads * sectors = 10h
mov bp, ax ; save result 10h in bp
or ax, ax ; check if ax == 0, this means we have sectors or heads equal to zero in the MBR
pop ax ; restore ax from stack, after this ax = 0802h, head = 2, sector = 8
jnz loc_36B1 ; we jump here, because ax != 0
nop ; the following three code lines have been left out, they check the next partition entry
;add bx, 10h ; go to next partition table entry
;loop loc_3697
;jmp short loc_36DE

loc_36B1:
push ax ; save value 0802h, head = 2, sector = 8
mov cx, 400h ; 1024 cylinders
mov ah, 3Fh ; 63 sectors
mov al, 0FFh ; 255 heads
mul ah ; ax = al * ah = 255 heads * 63 sectors = 16065 (3EC1h)
mul cx ; dx:ax = ax * cx = 3EC1h * 400h (16065 * 1024) = FB0400h (16450560)
div bp ; dx:ax / bp = FB0400h / 10h, ax = quotient, dx = remainder, integer overflow in ax
mov bx, ax
pop cx

invoke ExitProcess,0 ; exit process, only present in my demonstration code

end start

This integer overflow can only be fixed in the future if the AHCI Controller firmware code checks if the product of
heads * sectors is bigger than 251. All product results that are 251 and less will cause the integer overflow. Intel
could use the same behaviour as for MBR values of 00 00 00, where they simply use 255 heads and 63 sectors as disk
geometry.


-----------------------------------------------------------------------------------------------------------------
Document References
-----------------------------------------------------------------------------------------------------------------
Bug Reports:
http://support.microsoft.com/kb/931761/en-us
http://support.microsoft.com/kb/931760/en-us
http://social.technet.microsoft.com/Forums/en/w7itproinstall/thread/0185fced-0564-412f-8e10-bec37d020c81
http://sstahlman.blogspot.de/2010/12/in-which-it-is-revealed-how-ahci-bug.html
http://forum.enteo.com/showthread.php?t=5290

Information:
http://support.microsoft.com/kb/929491
http://www.msexchange.org/tutorials/disk-geometry.html
http://en.wikipedia.org/wiki/Logical_block_addressing
http://en.wikipedia.org/wiki/Master_boot_record
http://thestarman.pcministry.com/asm/mbr/index.html
http://thestarman.pcministry.com/asm/mbr/NTFSBR.htm
http://thestarman.pcministry.com/asm/mbr/PartTables.htm
http://thestarman.pcministry.com/asm/mbr/PartTables3.htm
http://thestarman.pcministry.com/asm/mbr/Win2kmbr.htm
http://thestarman.pcministry.com/asm/mbr/W7MBR.htm
http://thestarman.pcministry.com/asm/mbr/BootToolsRefs.htm

I do not know how long these bugs will be present for the AHCI controller, but I think Intel and Gigabyte
will never get a fix out. Maybe even more motherboards are affected than I can imagine. So it is always
best to check the MBR on such error reports and correct the CHS values to FE FF FF. These seem to always
work for state of the art computers. I hope this article can help someone which has the same problems
as me. Now we can run Windows XP and 2003 on properly aligned partitions on every SSD without the help
of Windows 7.

Forewarned is forearmed!
Greets kondra!
« Last Edit: March 27, 2012, 07:44:24 pm by kondra »

zwrose

Hi,

I ran into your scenario 1 problem upon building a clean install of Win7x64. Nothing had been particularly wrong with my system, i just decided it was time for a clean wipe. I got through the first part of the install fine, but when it restarted to move forward with the install I hit the hang at the HDD detection.  :(

I implemented the first half of your fix and now things seem to be running ok - my install finished fine. I don't have a second HDD though to use to run XP and get into the physicaldrive and edit hex. basically im left with 2 questions:

1) Is there a way for me to fix and go back to AHCI and Native mode without a second HDD running XP?
2) What would I be losing by keeping AHCI disabled and staying on legacy?

Thanks in advance to any and all who can help!

kondra

  • 12
  • 0
1) Another way I sometimes use is by creating a Windows 7 PE CD. With this you can boot in legacy IDE mode and hex edit your HDD. You should place a hex editor on a USB stick and you should know how to launch programs by the command prompt, because the PE disc will only show a cmd prompt after boot.

2) I think you will not be losing much, but this is only my own opinion. I did enable AHCI, because I installed a new SSD in my system and wanted to get as much performance as possible. I think with a normal platter HDD it simply doesn't matter at all.

Btw: The best solution would be if a new Gigabyte BIOS would address this issue. I still wonder why no one of the developers seems to be interested in fixing this issue. At least I have not been contacted by anyone so far.
« Last Edit: June 20, 2012, 12:13:46 pm by kondra »

Dark Mantis

  • *
  • 18405
  • 413
  • 10typesofpeopleoneswhoknow binaryandoneswhodont
    • Dark Mantis
Btw: The best solution would be if a new Gigabyte BIOS would address this issue. I still wonder why no one of the developers seems to be interested in fixing this issue. At least I have not been contacted by anyone so far.

That is probably purely because you have only posted the information as you see it here on the forum. Although employees do frequent the forum obviously they can't read every post that is new and so yours may well have been missed. I would suggest contacting GGTS and let them know directly.

Just enter your email address and click on the language of choice.

GGTS   http://ggts.gigabyte.com/

http://www.gigabyte.com/support-downloads/support-downloads.aspx

Please expect several days for a reply.
Gigabyte X58A-UD7
i7 920
Dominators 1600 x6 12GB
6970 2GB
HX850
256GB SSD, Sam 1TB, WDB320GB
Blu-Ray
HAF 932

Gigabyte Z68X-UD5-B3
i7 3770K
Vengeance 1600 16GB
6950 2GB
HCP1200W
Revo Drive x2, 1.5TB WDB RAID0
16x DLRW
StrikeX S7
Full water cooling
3 x 27" Iiy

kondra

  • 12
  • 0
Thanks for the tip Dark Mantis!
I followed your advice and contacted GGTS with a link to this thread and a short explanation of the problem.

RobD

  • 108
  • 1
Keep in mind that I am a bloody noob, which still tries to understand how these computers work, but getting better
in it every day.


Duuude!! Your into reversing bios's back to 16 bit assembly to fix problems and hex editing hdd's....and you call yourself a 'noob'!!! Get outa' here!!!
Outstanding work and very detailed analyses. Well done!!!   8)
My only reversing has been on nissan ecu's  :P

kondra

  • 12
  • 0
I only try to fix the manufacturer problems which drive me mad. Trust me I spend some long time into the reversing process. Let's hope my analysis is correct, because I haven't patched the BIOS and reflashed it for verification.

RobD

  • 108
  • 1
Your reply has lead me to do some more research on dual bios boards.
It appears that e.g. the Asus Rampage can copy one bios to the other from within bios. I don't see this same feature on the Gigabyte boards, at least not with the Assassin.
This would be a handy feature for testing a modded bios, if there was an error you could recover by booting the other bios and overwriting the error bios.

I also note that the Asus board is quite ok to have each bios a different version. I suspect that this would be the case with any dual bios board?
Though one would need to be sure to clear cmos first before switching to a bios of different version, lest ye suffer unintended consequences  :)

kondra

  • 12
  • 0
I am not sure for Gigabyte motherboards, but normally a BIOS is checksummed. In addition I think it is not a big problem for a dev to test the code location against this potential bug. So I will wait and see, before messing up my main working machine.  8)

Hey,
Thank for your kindness. Thanks for the solution. I hope you will be keep in touch in future also.

kondra

  • 12
  • 0
The following was answered from GGTS http://ggts.gigabyte.com/:
---------------------------------------------------
Dear Mr. Kondra,

Thank you for emailing GIGABYTE.
We are delighted with your interest in our products.
We have forwarded this "for info" to our bios team.

Kind regards
GIGABYTE-Team
---------------------------------------------------

So the actual status is "for info". We will see in the future BIOS releases if this get fixed.

gechu

  • 2
  • 0
Thanks for sharing your findrings Kondra!

I´m on rev 2.1 on the same motherboard, but I think both motherboards share the same ICH9 controller. So I hope your findings is equally relevant for me.

Please keep this thread up to date with the conversation you have with the Gigabyte BIOS team.

 

anything