Bug 504121 - RHEL 5.3 long installation time and low hard disk performance in VX800 platform
RHEL 5.3 long installation time and low hard disk performance in VX800 platform
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.3
i686 Linux
urgent Severity urgent
: rc
: 5.4
Assigned To: John Feeney
Red Hat Kernel QE team
: OtherQA
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-04 07:32 EDT by Bruce C. Chang
Modified: 2010-10-23 05:58 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 04:07:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bruce C. Chang 2009-06-04 07:32:02 EDT
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.
Comment 1 Matt Domsch 2009-06-04 09:04:48 EDT
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.
Comment 2 Matt Domsch 2009-06-04 09:18:38 EDT
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.
Comment 3 Bruce C. Chang 2009-06-08 07:30:07 EDT
Hello All:
    Patched provided from VIA on 82cxxxx for supporting VX800.

Signed off by Joseph Chan <JosephChan@via.com.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},
Comment 4 Subhendu Ghosh 2009-06-16 23:23:59 EDT
Bruce

Can you confirm if the above patch is sufficient - and there are no other changes to kernel module options?
Comment 5 Bruce C. Chang 2009-06-16 23:33:16 EDT
Hello Subhendu:
   For the storage DMA support in RHEL 5U3, yes, the patch listed as above can solve the issue.
Thanks and Best Regards
Comment 12 John Feeney 2009-06-22 13:04:57 EDT
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.
Comment 13 Harald Welte 2009-06-22 14:23:46 EDT
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.
Comment 14 John Feeney 2009-06-22 17:03:04 EDT
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.
Comment 15 John Feeney 2009-06-23 10:30:43 EDT
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
Comment 16 Marizol Martinez 2009-06-23 11:10:11 EDT
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!
Comment 17 Bruce C. Chang 2009-06-23 11:36:13 EDT
Hello Marizol and John:
    Thank you very much for your great support. I hope I can finish the testing within next 12 hours.
Comment 19 RHEL Product and Program Management 2009-06-23 11:53:10 EDT
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.
Comment 21 Bruce C. Chang 2009-06-24 09:32:47 EDT
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
Comment 22 John Feeney 2009-06-24 10:41:54 EDT
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
Comment 23 Marizol Martinez 2009-06-24 11:46:02 EDT
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.
Comment 25 Bruce C. Chang 2009-06-25 03:14:53 EDT
Hello John:
    Please add the modification of 5324 for the minimun modification. So please use the following suggestions
Signed-off-by Joseph Chan<Josephchan@via.com.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
Comment 26 John Feeney 2009-06-25 17:05:52 EDT
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
Comment 27 Bruce C. Chang 2009-06-25 22:13:02 EDT
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
Comment 28 Marizol Martinez 2009-06-26 09:24:51 EDT
Great job, thank you!
Comment 29 Don Zickus 2009-06-30 16:22:33 EDT
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.
Comment 31 Chris Ward 2009-07-03 14:45:11 EDT
~~ 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.
Comment 32 Bruce C. Chang 2009-07-07 07:07:35 EDT
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
Comment 35 John Jarvis 2009-07-07 09:58:53 EDT
Please retest with snapshot 1 (kernel-2.6.18-156.el5) as this was the first kernel which included the fix.
Comment 37 Chris Ward 2009-07-10 15:14:05 EDT
~~ 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.
Comment 38 Bruce C. Chang 2009-07-13 02:19:15 EDT
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
Comment 41 errata-xmlrpc 2009-09-02 04:07:28 EDT
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

Note You need to log in before you can comment on or make changes to this bug.