Description of problem: Low Harddisk transfer rate for VX800 platform. Version-Release number of selected component (if applicable): How reproducible: It takes 2 hours to install the RHEL 5.3 into VIA VX800 platform + VIA Nano 1.3GHz CPU + IDE Harddisk. And after RHEL 5.3 installed, the IDE is running in PIO mode only by hdparm command. Actual results: Expected results: Additional info: After rebuild the pata_via.c and insert this module into kernel, the IDE can run in UDMA mode. So we would like to request to go through pata_via module instead of defaul via82cxxx module.
Marizol: please be advised that this VIA chipset is in use in the Dell Data Center Solutions (DCS) "Fortuna" product line. We have not needed change requests for DCS products yet, this is the first. As you are aware, DCS is the group developing web-farm-scale servers, essentially custom-designed for each individual customer, and each customer buys thousands to tens of thousands of the same model. Supporting the IDE chip in here will be important to these customers. All DCS customers (so far except one :-) run some form of Linux, many of the Red Hat Enterprise Linux.
Bruce, will you be developing the patch against the RHEL 5.3 kernel, and attaching to this bug report, or do you need Red Hat to do the backport from mainline? If Red Hat does the work, that will take longer.
Hello All: Patched provided from VIA on 82cxxxx for supporting VX800. Signed off by Joseph Chan <JosephChan.tw> --- a/include/linux/pci_ids.h 2009-06-04 11:43:38.000000000 +0800 +++ b/include/linux/pci_ids.h 2009-06-08 18:43:22.000000000 +0800 @@ -1336,9 +1336,11 @@ #define PCI_DEVICE_ID_VIA_8251 0x3287 #define PCI_DEVICE_ID_VIA_8237A 0x3337 #define PCI_DEVICE_ID_VIA_8237S 0x3372 +#define PCI_DEVICE_ID_VIA_8261 0x3402 #define PCI_DEVICE_ID_VIA_8231 0x8231 #define PCI_DEVICE_ID_VIA_8231_4 0x8235 #define PCI_DEVICE_ID_VIA_8365_1 0x8305 +#define PCI_DEVICE_ID_VIA_5324 0x5324 #define PCI_DEVICE_ID_VIA_CX700 0x8324 #define PCI_DEVICE_ID_VIA_VX800 0x8353 #define PCI_DEVICE_ID_VIA_8371_1 0x8391 --- a/drivers/ide/pci/via82cxxx.c 2006-09-20 11:42:06.000000000 +0800 +++ b/drivers/ide/pci/via82cxxx.c 2009-06-08 18:42:28.000000000 +0800 @@ -78,7 +78,12 @@ u8 rev_max; u16 flags; } via_isa_bridges[] = { + { "vx800", PCI_DEVICE_ID_VIA_VX800, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, + { "cx700", PCI_DEVICE_ID_VIA_CX700, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, + { "vt8237s", PCI_DEVICE_ID_VIA_8237S, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, + { "vt8237a", PCI_DEVICE_ID_VIA_8237A, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, { "vt6410", PCI_DEVICE_ID_VIA_6410, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, + { "vt8261", PCI_DEVICE_ID_VIA_8261, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, { "vt8251", PCI_DEVICE_ID_VIA_8251, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, { "vt8237", PCI_DEVICE_ID_VIA_8237, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, { "vt8237a", PCI_DEVICE_ID_VIA_8237A, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, @@ -498,6 +503,7 @@ { PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C576_1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, { PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, { PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_6410, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 1}, + { PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_5324, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 1}, { 0, }, }; MODULE_DEVICE_TABLE(pci, via_pci_tbl); --- a/drivers/ata/pata_via.c 2009-06-04 11:43:09.000000000 +0800 +++ b/drivers/ata/pata_via.c 2009-06-08 18:46:01.000000000 +0800 @@ -100,6 +100,7 @@ } via_isa_bridges[] = { { "vx800", PCI_DEVICE_ID_VIA_VX800, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, { "vt8237s", PCI_DEVICE_ID_VIA_8237S, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, + { "vt8261", PCI_DEVICE_ID_VIA_8261, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, { "vt8251", PCI_DEVICE_ID_VIA_8251, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, { "cx700", PCI_DEVICE_ID_VIA_CX700, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST | VIA_SATA_PATA }, { "vt6410", PCI_DEVICE_ID_VIA_6410, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST | VIA_NO_ENABLES},
Bruce Can you confirm if the above patch is sufficient - and there are no other changes to kernel module options?
Hello Subhendu: For the storage DMA support in RHEL 5U3, yes, the patch listed as above can solve the issue. Thanks and Best Regards
To recap: comment #0 above says support for "vx800" should be shifted from via82cxxx to pata_via. The patch provided in comment #3 has been tested on a kernel rpm provided by SEG and found to work. Thank you so much for providing patch, but upon further review I have some comments and questions: 1. drivers/pci/pata_via.c does NOT currently get compiled in RHEL-5. It is my understanding that VIA tested the rpm provided in the Issue Tracker (304317) but pata_via.o was not there, so how did it pass? This was not a srpm so you could not have compiled it yourself. 2. The patch adds entries to via_isa_bridges[] in via82cxxx.c. I guess (naively) I would have thought it would have possibly remove devices from via82cxxx.x since the goal is to move the functionality from via82cxxx.c to pata_via.c ("rebuild the pata_via.c and insert this module into kernel"). Why are these entries ADDED to via_isa_bridges[]? 3. Assuming you need to add to via_isa_bridges[], I can see where the "vt800" entry is needed (see bug title) but why are we adding "vx8261", "cx700", and "vt8237a" entries? 4. If via82cxxx.c handles this device now, (albeit badly) why do we need to add pci ids (for 8261 and 5324)? Shouldn't they already be there? 5. I found all of this code upstream (good) but not just in one commit but actually a series of commits (not so good). Okay, let me guess how this really works: This patch does not migrate the functionality from via82cxxx.c to pata_via.c as the bugzilla requests. It adds the VIA_5324 device to via82cxxx.c and then the isa bridge for VIA_8261 which is configured for UDMA. This activation of the device in UDMA mode in via82cxxx.c is what is needed, not switching to pata_via.c. If my guess is correct, then the patch is reduced to adding two pci ids to pci_ids.h and the "vt8261" entry to via_isa_bridges[] and the 5324 entry to the via_pci_tbl[] in via82cxxx.c only. The rest is extraneous. Given the situation, my requirements for this patch are to have only the code that is required and nothing else. Please let me know how far off my guess is and what I need to do to provide you with a patch that fulfills your needs with minimal code.
I believe your analysis is completely correct. I have worked with the VX800 using both via82cxx and pata_via. As you will definitely know, for [almost?] all IDE/PATA drivers, there are two drivers in the kernel. One is the old /drivers/ide/ architecture, the other one is the new PATA-via-SATA architecture in /drivers/ata/pata_*. Both drivers will work, the difference mainly being whether you get /dev/hd* or /dev/sd* device names. Normally, VIA engineers always recommend pata_via. This is why for this particular project (and resulting bug report), pata_via was recommended. Also, without recompiling the kernel, a modified pata_via kernel module from a driver disk can solve the problem. However, since RHEL is based on older kernels and doesn't use any of the pata_* drivers, I recommended to VIA's engineers that they should provide a solution/patch based on via82cxxx. I thought such a minimal-invasive approach is more useful to RedHat than suddenly dealing with pata_* drivers just for this bug. The alternate technical solution really is to put the two ID's you mentioned into the driver. However, I would propose to add all the new PATA and isa bridge ID's to via82cxx, not just the VX800. There will be more customers using non-vx800 chipsets and they will be happy to have RHEL suport. Since there is no code change, the risk to any existing system is basically zero.
Thanks for your input Harald. Given the current situation, I believe I am only going to fix what the bz says should be fixed, the VX800. I assume inclusion of the following line should allow the VX800 to work but please let me know if I need to include anything else for the VX800 to work properly. --- linux-2.6.18.noarch/drivers/ide/pci/via82cxxx.c.orig +++ linux-2.6.18.noarch/drivers/ide/pci/via82cxxx.c @@ -78,6 +78,7 @@ static struct via_isa_bridge { u8 rev_max; u16 flags; } via_isa_bridges[] = { + { "vx800", PCI_DEVICE_ID_VIA_VX800, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, { "vt6410", PCI_DEVICE_ID_VIA_6410, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, { "vt8251", PCI_DEVICE_ID_VIA_8251, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, { "vt8237", PCI_DEVICE_ID_VIA_8237, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, I agree that including more VIA devices (such as the cx700, vt8237s, vt8237a, and vt8261) would be good. Perhaps you would be so kind as to follow the proper channels to create a feature request for their inclusion into RHEL5.5.
A kernel rpm with the specific fix (see previous comment) for vx800 for x86_64 can be downloaded from my people page. I would ask that this be tested to confirm it is sufficient. Thanks. http://people.redhat.com/jfeeney/.bz504121
Thanks, John. Harald -- I just want to stress that time is of the essence here. We would appreciate your feedback as soon as possible. Thanks!
Hello Marizol and John: Thank you very much for your great support. I hope I can finish the testing within next 12 hours.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Hello John: Thank you very much for your help. But I have bad news for the new 2.6.18-154.el5jfeeney504121.2 rpm. It is unable to enable the DMA mode. However, the rpm 2.6.18-128.el5.IT304317 works well. Following is the comparison between these 3 condition. As you can see the TX rate of the HD for 2.6.18-128.el5.IT304317 is 20MB/sec. However, 2.6.18-154.el5jfeeney504121.2 is only 4.39MB/sec same as no any rpm installed. /dev/hda: Timing buffered disk reads: 14 MB in 3.20 seconds = 4.37 MB/sec Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 34248400 2958456 29522112 10% / /dev/hda1 101086 12157 83710 13% /boot tmpfs 900008 0 900008 0% /dev/shm 2.6.18-128.el5 x86_64 /dev/hda: Timing buffered disk reads: 14 MB in 3.19 seconds = 4.39 MB/sec Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 34248400 3052096 29428472 10% / /dev/hda1 101086 18515 77352 20% /boot tmpfs 899940 0 899940 0% /dev/shm 2.6.18-154.el5jfeeney504121.2 x86_64 /dev/hda: Timing buffered disk reads: 60 MB in 3.02 seconds = 19.87 MB/sec Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 34248400 3048592 29431976 10% / /dev/hda1 101086 18428 77439 20% /boot tmpfs 900008 0 900008 0% /dev/shm 2.6.18-128.el5.IT304317 x86_64 Regards
Bruce, That's too bad about my kernel. Since you provided a patch that works but it has extraneous lines of code and I (currently) don't have any hardware, could you provide some guidance as to what additional parts of the patch are needed for this to work? That is, could you provide a patch that has the minimum number of changes for the VX800 to work sufficiently? Otherwise, I will be forced to continue to guess and experiment which is wasting time. Thanks so much. John
BTW, Bruce, I should clarify the following: The first test kernel you received was built on a RHEL 5.3 base (-128) and not on the RHEL 5.4 base (currently -154) which is the one where we are targeting this enablement for. Our apologies for that mishap. As John mentioned, we will need your help in identifying the minimum number of changes that would be required to enable vx800 with RHEL 5.4.
Hello John: Please add the modification of 5324 for the minimun modification. So please use the following suggestions Signed-off-by Joseph Chan<Josephchan.tw> --- a/include/linux/pci_ids.h 2009-06-04 11:43:38.000000000 +0800 +++ b/include/linux/pci_ids.h 2009-06-08 18:43:22.000000000 +0800 @@ -1336,9 +1336,11 @@ #define PCI_DEVICE_ID_VIA_8251 0x3287 #define PCI_DEVICE_ID_VIA_8237A 0x3337 #define PCI_DEVICE_ID_VIA_8237S 0x3372 #define PCI_DEVICE_ID_VIA_8231 0x8231 #define PCI_DEVICE_ID_VIA_8231_4 0x8235 #define PCI_DEVICE_ID_VIA_8365_1 0x8305 +#define PCI_DEVICE_ID_VIA_5324 0x5324 #define PCI_DEVICE_ID_VIA_CX700 0x8324 #define PCI_DEVICE_ID_VIA_VX800 0x8353 #define PCI_DEVICE_ID_VIA_8371_1 0x8391 --- a/drivers/ide/pci/via82cxxx.c 2006-09-20 11:42:06.000000000 +0800 +++ b/drivers/ide/pci/via82cxxx.c 2009-06-08 18:42:28.000000000 +0800 @@ -78,7 +78,12 @@ u8 rev_max; u16 flags; } via_isa_bridges[] = { + { "vx800", PCI_DEVICE_ID_VIA_VX800, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, { "vt6410", PCI_DEVICE_ID_VIA_6410, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, { "vt8251", PCI_DEVICE_ID_VIA_8251, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, { "vt8237", PCI_DEVICE_ID_VIA_8237, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, { "vt8237a", PCI_DEVICE_ID_VIA_8237A, 0x00, 0x2f, VIA_UDMA_133 | VIA_BAD_AST }, @@ -498,6 +503,7 @@ { PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C576_1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, { PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, { PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_6410, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 1}, + { PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_5324, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 1}, { 0, }, }; MODULE_DEVICE_TABLE(pci, via_pci_tbl); Thanks and Best Regards Bruce C. Chang
Wow, thanks Bruce! I took the patch above and built a new rpm. I would appreciate it if it were tested. See kernel-2.6.18-154.el5jfeeney504121.3.x86_64.rpm in http://people.redhat.com/jfeeney/.bz504121
Hello John: Thank you very much for your great help!!!! It works very good. I got HD performance back to 19MB/Sec with your patch again!! The test data is listed as below: /dev/hda: Timing buffered disk reads: 60 MB in 3.02 seconds = 19.84 MB/sec Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 34248400 3070432 29410136 10% / /dev/hda1 101086 18515 77352 20% /boot tmpfs 899940 0 899940 0% /dev/shm 2.6.18-154.el5jfeeney504121.3 x86_64
Great job, thank you!
in kernel-2.6.18-156.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5 Please do NOT transition this bugzilla state to VERIFIED until our QE team has sent specific instructions indicating when to do so. However feel free to provide a comment indicating that this fix has been verified.
~~ Attention - RHEL 5.4 Beta Released! ~~ RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner! If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity. Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value. Questions can be posted to this bug or your customer or partner representative.
Hello Chris: Thank you very much for your information. The RHEL 5.3 beta was tested in the VX800 board. Unfortunately, the storage performance is still in PIO mode. The following is the test data *Trying to enable the DMA mode by hdparm -d 1 /dev/hda /dev/hda: setting using_dma to 1 (on) using_dma = 0 (off) * Test HD performance by hdparm -tT /dev/hda /dev/hda: Timing cached reads: 2280 MB in 2.00 seconds = 1140.08 MB/sec Timing buffered disk reads: 14 MB in 3.40 seconds = 4.12 MB/sec * confirm the kernel version by uname -a Linux localhost.localdomain 2.6.18-155.el5 #1 SMP Fri Jun 19 17:06:31 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux * file system status by df Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup01-LogVol00 232506112 2322520 218182312 2% / /dev/hda1 101086 12265 83602 13% /boot tmpfs 1013100 0 1013100 0% /dev/shm Regards
Please retest with snapshot 1 (kernel-2.6.18-156.el5) as this was the first kernel which included the fix.
~~ Attention Partners - RHEL 5.4 Snapshot 1 Released! ~~ RHEL 5.4 Snapshot 1 has been released on partners.redhat.com. If you have already reported your test results, you can safely ignore this request. Otherwise, please notice that there should be a fix available now that addresses this particular request. Please test and report back your results here, at your earliest convenience. The RHEL 5.4 exception freeze is quickly approaching. If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity. Do not flip the bug status to VERIFIED. Instead, please set your Partner ID in the Verified field above if you have successfully verified the resolution of this issue. Further questions can be directed to your Red Hat Partner Manager or other appropriate customer representative.
Hello Chris and John: I would like to share the test result of 5U4 in VX800 platform for this item. The following is the log I have. The original 5U4 (Kernel-2.6.18-155) has poor storage performance with VX855. However, the performance has 10 times improvement after patch with kernel-2.6.18-156 or kernel-2.6.18-157. Linux localhost.localdomain 2.6.18-155.el5 #1 SMP Fri Jun 19 17:06:31 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 146295140 2928016 135815740 3% / /dev/hdc1 101086 12265 83602 13% /boot tmpfs 1544800 0 1544800 0% /dev/shm /dev/hdc: setting using_dma to 1 (on) using_dma = 0 (off) /dev/hdc: Timing buffered disk reads: 12 MB in 3.50 seconds = 3.43 MB/sec Linux localhost.localdomain 2.6.18-156.el5 #1 SMP Mon Jun 29 18:16:54 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 146295140 3081812 135661944 3% / /dev/hdc1 101086 18651 77216 20% /boot tmpfs 1544796 0 1544796 0% /dev/shm /dev/hdc: setting using_dma to 1 (on) using_dma = 1 (on) /dev/hdc: Timing buffered disk reads: 168 MB in 3.02 seconds = 55.56 MB/sec Linux localhost.localdomain 2.6.18-157.el5 #1 SMP Mon Jul 6 18:12:07 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 146295140 3081996 135661760 3% / /dev/hdc1 101086 18647 77220 20% /boot tmpfs 1544796 0 1544796 0% /dev/shm /dev/hdc: setting using_dma to 1 (on) using_dma = 1 (on) /dev/hdc: Timing buffered disk reads: 168 MB in 3.02 seconds = 55.65 MB/sec Thanks and Best Regards Bruce C. Chang
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-1243.html