Bug 65819 - Cannot enable Serverworks CSB5 IDE controller
Cannot enable Serverworks CSB5 IDE controller
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-05-31 20:20 EDT by Roderick Constance
Modified: 2007-04-18 12:42 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-07 22:31:05 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)
dmesg (11.41 KB, text/plain)
2002-05-31 20:37 EDT, Roderick Constance
no flags Details
lspci (716 bytes, text/plain)
2002-05-31 20:37 EDT, Roderick Constance
no flags Details
lspci of CSB5 IDE Controller (589 bytes, text/plain)
2002-05-31 20:38 EDT, Roderick Constance
no flags Details
lspci of ServerWorks Host bridge (304 bytes, text/plain)
2002-05-31 20:39 EDT, Roderick Constance
no flags Details
This patch qualifies the call to pci_enable_device in ide-pci.c to avoid issues with these BIOS that don't assign unused BAR's (1.05 KB, patch)
2002-07-23 13:00 EDT, Philip Pokorny
no flags Details | Diff
This patch REALLY fixes the problem. Please ignore previous patch (1.05 KB, patch)
2002-07-23 16:46 EDT, Philip Pokorny
no flags Details | Diff

  None (edit)
Description Roderick Constance 2002-05-31 20:20:35 EDT
Description of Problem:

The kernel reports inability to enable the Serverworks CSB5 IDE controller.  
hdparm seems to disallow the enabling of DMA, as a result (I've tried 
"USE_DMA=1" in /etc/sysconfig/harddiskhda).

SvrWks CSB5: IDE controller on PCI bus 00 dev 79
PCI: Device 00:0f.1 not available because of resource collisions
SvrWks CSB5: (ide_setup_pci_device:) Could not enable device.

Version-Release number of selected component (if applicable):
RedHat 7.3 errata (2.4.18-4smp)

How Reproducible:
Always

Steps to Reproduce:
1. hdparm -d1 /dev/hda
2. 
3. 

Actual Results:

/dev/hda:
 setting using_dma to 1 (on)
 HDIO_SET_DMA failed: Operation not permitted
 using_dma    =  0 (off)
Expected Results:


Additional Information:
Comment 1 Roderick Constance 2002-05-31 20:37:16 EDT
Created attachment 59186 [details]
dmesg
Comment 2 Roderick Constance 2002-05-31 20:37:56 EDT
Created attachment 59187 [details]
lspci
Comment 3 Roderick Constance 2002-05-31 20:38:53 EDT
Created attachment 59188 [details]
lspci of CSB5 IDE Controller
Comment 4 Roderick Constance 2002-05-31 20:39:52 EDT
Created attachment 59189 [details]
lspci of ServerWorks Host bridge
Comment 5 Roderick Constance 2002-05-31 20:41:45 EDT
Also there is no /proc/ide/svwks.
Comment 6 Philip Pokorny 2002-05-31 23:05:11 EDT
See also
  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=49353
  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62031

Seems that we have two "identical" chips from differnt manufacturers (Intel and
ServerWorks).  The CSB5 worked with 7.2 (2.4.9-31) kernel and is now broke with
2.4.18.

Was the code in arch/i386/kernel/pci-i386.c that checks all resources recently
added?  Perhaps it would be better for the PCI drivers to specify which PCI
regions they are actually going to use so that if the BIOS doesn't assign the
BAR's an address, it won't cause an error.  This should be ok since those
resources won't ever be used.

Comment 7 Arjan van de Ven 2002-06-01 05:28:18 EDT
PCI: Device 00:0f.1 not available because of resource collisions

That's a bios bug.... And yes the BIOS should not assign conflicting resources.
Comment 8 Philip Pokorny 2002-06-03 13:06:56 EDT
I respectfully disagree.  The PCI device in question has two "Programming
Interfaces" according to Intel's 82801CA I/O Controller Hub-3 Datasheet dated
March 2002 on page 368. Of the 5 Base Address Registers, 4 are used to specify
resources for the "native" programming interface and the 5th is for the "legacy"
programming interface.

Since the Linux (and DOS and probably Windows) drivers use the default "legacy"
interface and have set or accept the PI register setting.  There is no need to
allocate resources for the "native" interface which isn't being used.

Thus the PCI layers assumption that a resource collision caused resources not to
be allocated is false and the device *SHOULD* be made available because the
necessary resources *HAVE* been assigned.  Assigning resources to the "native"
interface is unnecessary and a waste of resources.
Comment 9 Philip Pokorny 2002-07-23 13:00:18 EDT
Created attachment 66625 [details]
This patch qualifies the call to pci_enable_device in ide-pci.c to avoid issues with these BIOS that don't assign unused BAR's
Comment 10 Philip Pokorny 2002-07-23 16:46:47 EDT
Created attachment 66664 [details]
This patch REALLY fixes the problem. Please ignore previous patch
Comment 11 Philip Pokorny 2002-07-23 16:47:44 EDT
Sorry about that.  Should have compiled and tested *before* submitting my patch...

This last patch has been tested, and works.
Comment 12 Alan Cox 2002-07-28 19:35:45 EDT
This patch is incorrect and will cause machines to hang. Please see the correct
IDE southbridge handler for broken bioses in the current 2.4.19rc kernel tree
Comment 13 Philip Pokorny 2002-07-28 20:48:25 EDT
So I've looked at 2.4.19rc3 on kernel.org and I don't see anything in ide-pci.c
that will solve this problem.  Was the patch applied between 2.4.18 and 2.4.19?

http://www.kernel.org/diff/diffview.cgi?css=%2Fdiff%2Fdiff.css;file=%2Fpub%2Flinux%2Fkernel%2Fv2.4%2Ftesting%2Fpatch-2.4.19-rc3.gz;z=1634

Can someone please give me a more specific pointer?  filename, function, line
number, URL of a patch, etc.  We've got several different motherboards with this
problem and I want to be sure it gets fixed.
Comment 14 Philip Pokorny 2002-07-29 21:35:38 EDT
OK.  I see the code in 2.4.18-7.80 from RAWHIDE.  Several chipsets got a
fixup_device_<name> function with a call to ide_register_xp_fix(dev).

All except the CSB5 that is.  The CSB6 got one *without* a call to
ide_register_xp_fix.  Not sure what to make of that...

So THIS BUG is still NOT fixed by the RAWHIDE kernel.  We have verified that the
fix does work for Intel ICH (PIIX) southbridge's.  We have also verified that
it's still broke on the CSB5.

On a stylistic note...

It seems odd that a function (ide_register_xp_fix) that is 25 lines long, with
no comments is in it and shared by at least 4 drivers is declared as "inline" in
 linux/ide.h but #ifdef LINUX_PCI_H..

Why wouldn't it be better to declare it once in ide-pci.c?
Comment 15 Jim Wright 2002-10-25 23:22:21 EDT
Installed the 2.4.18-17.7.xbigmem kernel on one of the affected systems.  (There
are many different motherboards which suffer from this problem; I haven't tried
them all.)  This problem is still not fixed.

Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SvrWks CSB5: IDE controller on PCI bus 00 dev 79
PCI: Device 00:0f.1 not available because of resource collisions
SvrWks CSB5: (ide_setup_pci_device:) Could not enable device.
Comment 16 Chip Y 2003-03-10 17:54:00 EST
I had the same problem and it was resolved with an upgrade to the latest BIOS.  
My system is a Penguin Computing 1U with a SuperMicro P3TDER mobo.  The AMI 
BIOS upgrade was from 1.1 to 1.1a and can be found at www.supermicro.com.

Comment 17 Alan Cox 2003-06-07 22:31:05 EDT
Current errata also fix this

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