PATCH: uniata: freezes on transfers between Via 6421 card and Western Digital drives[upstream]

Created an attachment (id=6714)
Debug log of ReactOS starting up with a Via 6421 controller and WD HD.

ReactOS freezes when reading/writing files between Via 6421 raid cards and Western Digital drives.

After some testing with a number of Via 6421 raid cards and different brands/models of hard drives I am confident that I am encountering the same issue described here: http://ubuntuforums.org/archive/index.php/t-1665984.html except under ReactOS with UniATA.

Also described with more technical specifics here:
http://patchwork.ozlabs.org/patch/54101/

This issue appears to occur with both 6420 and 6421 chips and only with recent Western Digital hard drives (Recent Hitachi hard drives, for example, work fine.)

The Linux fix is as follows when configuring the device (see http://git.freesmartphone.org/?p=linux-2.6.git;a=blob;f=drivers/ata/sata_via.c ) :

/*

• vt6420/1 has problems talking to some drives. The following
• is the fix from Joseph Chan <JosephChan@via.com.tw>.
  *
• When host issues HOLD, device may send up to 20DW of data
• before acknowledging it with HOLDA and the host should be
• able to buffer them in FIFO. Unfortunately, some WD drives
• send upto 40DW before acknowledging HOLD and, in the
• default configuration, this ends up overflowing vt6421's
• FIFO, making the controller abort the transaction with
• R_ERR.
  *
• Rx52[2] is the internal 128DW FIFO Flow control watermark
• adjusting mechanism enable bit and the default value 0
• means host will issue HOLD to device when the left FIFO
• size goes below 32DW. Setting it to 1 makes the watermark
• 64DW.
  *
• https://bugzilla.kernel.org/show_bug.cgi?id=15173
• http://article.gmane.org/gmane.linux.ide/46352
• http://thread.gmane.org/gmane.linux.kernel/1062139
  */
  if (board_id == vt6420 || board_id == vt6421) { pci_read_config_byte(pdev, 0x52, &tmp8); tmp8 |= 1 << 2; pci_write_config_byte(pdev, 0x52, tmp8); }

It looks like something similar could be applied to UniATA to hopefully correct the issue.

Since I know somebody will ask, I am attaching the first part of a UniATA debug log. This should give you an idea of the configuration, however I was not able to replicate the crash with the debug UniATA presumably because it slows everything down so much.

Additionally, it is not possible to enter the kernel debugger when this freeze occurs.