Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Andries.Brouwer]

    From: Andre Hedrick <andre@aslab.com>

    You know yourself first and all the screwed up ATAPI products that are
    still using SFF-8020 that has been obsoleted before I start maintaining
    the subsystem three plus years ago. 

Hi Andre -

Why precisely is complying to SFF-8020 broken?
That was the standard. The standard that Microsoft required.
Other people made a different standard, and claimed that theirs
was better or more official or whatever, but reality is that
the products were not manufactured following this so-called
better standard.
You are a good disciple of Hale, but it is no use ignoring the
fact that a very large number of devices was made following SFF-8020.
These devices are not necessarily screwed, they tend to work fine,
although both ATA and ATAPI devices have their quirks.

SFF-8020, later INF-8020, became part of ATA/ATAPI-4 (1998).
The T13 people that merged SFF-8020 and produced ATA/ATAPI-4
changed a few details about how a master is supposed to react
when a nonexistent slave is selected. Nobody really noticed,
and ATA/ATAPI-5 still had the same requirements. But then long
discussions about this difference caused ATA/ATAPI-6 to go back
to the original SFF-8020 requirements. Do you disagree with this
description of history? If you agree then it is not SFF-8020
but ATA/ATAPI-4 and ATA/ATAPI-5 that today must be considered broken
in this respect. I am referring to Section 9.16.1 of these standards.

Maybe there are other things in SFF-8020 that you consider broken?

Andries

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Andre Hedrick]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3371 bytes --]


On Thu, 28 Jun 2001 Andries.Brouwer@cwi.nl wrote:

>     From: Andre Hedrick <andre@aslab.com>
> 
>     You know yourself first and all the screwed up ATAPI products that are
>     still using SFF-8020 that has been obsoleted before I start maintaining
>     the subsystem three plus years ago. 
> 
> Hi Andre -
> 
> Why precisely is complying to SFF-8020 broken?
> That was the standard. The standard that Microsoft required.

You have stated it clearly it is past tense.

> Other people made a different standard, and claimed that theirs
> was better or more official or whatever, but reality is that
> the products were not manufactured following this so-called
> better standard.

Ignoring "junk hardware" is not practical it will bite you everyday all
day long.........Best example is VIA.

> You are a good disciple of Hale, but it is no use ignoring the

If one is going to learn the rules it is best to have learned from on of
the "Fathers of ATA", and given that I have been crowned "Hale Jr." I take
this a compliment.  The reality is that I am not anywhere in the same
class of understanding as Hale Landis, but getting there.

> fact that a very large number of devices was made following SFF-8020.
> These devices are not necessarily screwed, they tend to work fine,
> although both ATA and ATAPI devices have their quirks.

If they all did the same thing (regardless of class) it would be a
different issue.  Basic things like asking for N amounts of data and
getting back N+M > N the buffer allocated.  Or worse is the under
data-run.  Other issues are DRQ, failure to hold/set busy-bit.

The ATAPI people do not even follow the rules in the defunct guide.

> SFF-8020, later INF-8020, became part of ATA/ATAPI-4 (1998).
> The T13 people that merged SFF-8020 and produced ATA/ATAPI-4
> changed a few details about how a master is supposed to react
> when a nonexistent slave is selected. Nobody really noticed,

That point is only important during POST and execution of drive
diagnostics command and Linux does not call that command.

> and ATA/ATAPI-5 still had the same requirements. But then long
> discussions about this difference caused ATA/ATAPI-6 to go back
> to the original SFF-8020 requirements. Do you disagree with this
> description of history? If you agree then it is not SFF-8020
> but ATA/ATAPI-4 and ATA/ATAPI-5 that today must be considered broken
> in this respect. I am referring to Section 9.16.1 of these standards.
> 
> Maybe there are other things in SFF-8020 that you consider broken?

See above, regardless of the brokeness whe have to mucky with it.
So I move to develop to a standard that I have influence and direction
control, then deal with the exceptions.

ATA-X created the "packet-command" and "data-phase-handlers" based on the
zero-bit in the error_feature task-register.

Lastly it does not exist anymore, a real problem for manufacturers
building product on a document that does not exist.  Worse is that there
are companies making hardware based on SFF-8020 v2.5!

Cheers,

Andre Hedrick
ASL Kernel Development
Linux ATA Development
-----------------------------------------------------------------------------
ASL, Inc.                                     Toll free: 1-877-ASL-3535
1757 Houret Court                             Fax: 1-408-941-2071
Milpitas, CA 95035                            Web: www.aslab.com


[-- Attachment #2: Type: TEXT/plain, Size: 995 bytes --]

Expired                                                       SFF-8020i Rev 2.6 


SFF Committee documentation may be purchased (see p4).
SFF Committee documents are available by FaxAccess at 408-741-1600






                                SFF Committee

                          SFF-8020i Specification for 

                      ATA Packet Interface for CD-ROM 

                          Rev 2.6   January 22, 1996



Secretariat:  SFF Committee


Abstract:  INF-8020i defines defines a Packet Interface for use with CD-ROM 
drives that use the ATA (AT Attachment) interface.

The members voted in September 1999 that this specification Expire. 

SFF-8020 has been incorporated into two national standards, SCSI MMC (Multi 
Media Commands) and ATA/ATAPI (AT Attachment). 

For current information, see:

 - www.t10.org for the latest revision of SCSI MMC-x 
 - www.t13.org for the latest revision of ATA/ATAPI-x

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Jens Axboe]

On Thu, Jun 28 2001, Andries.Brouwer@cwi.nl wrote:
> Why precisely is complying to SFF-8020 broken?

Because 8020 is _old and dated_, yet some manufacturers still base new
devices on it. That is what is broken, clearly noone is faulting a '96
device for being based on SFF-8020, however a '09 and '01 is a different
story.

> You are a good disciple of Hale, but it is no use ignoring the

:-)

-- 
Jens Axboe

Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Gunther Mayer]

Hi,

this patch fixes the hard hang (no SYSRQ) on inserting
any PCMCIA ATA/IDE card (e.g. CompactFlash, Clik40 etc)
to a PCI-Cardbus bridge add-in card.

Thanks David for his valuable explanation about what happens:
ide-probe registers it's irq handler too late! After it
triggers the interrupt during the probe the (shared) irq
loops forever, effectively wedging the machine completely.

Regards, Gunther



--- linux245.orig/drivers/ide/ide-cs.c  Fri Feb  9 20:40:02 2001
+++ linux/drivers/ide/ide-cs.c  Tue Jun 26 21:22:19 2001
@@ -324,6 +324,9 @@
     if (link->io.NumPorts2)
        release_region(link->io.BasePort2, link->io.NumPorts2);
 
+    outb(0x02, ctl_base); // Set nIEN = disable device interrupts
+                         // else it hangs on PCI-Cardbus add-in cards, wedging irq
+
     /* retry registration in case device is still spinning up */
     for (i = 0; i < 10; i++) {
        hd = ide_register(io_base, ctl_base, link->irq.AssignedIRQ);
--- linux245.orig/drivers/ide/ide-probe.c       Sun Mar 18 18:25:02 2001
+++ linux/drivers/ide/ide-probe.c       Tue Jun 26 21:25:07 2001
@@ -685,6 +685,8 @@
 #else /* !CONFIG_IDEPCI_SHARE_IRQ */
                int sa = (hwif->chipset == ide_pci) ? SA_INTERRUPT|SA_SHIRQ : SA_INTERRUPT;
 #endif /* CONFIG_IDEPCI_SHARE_IRQ */
+
+               outb(0x00, hwif->io_ports[IDE_CONTROL_OFFSET]); // clear nIEN == enable irqs
                if (ide_request_irq(hwif->irq, &ide_intr, sa, hwif->name, hwgroup)) {
                        if (!match)
                                kfree(hwgroup);

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Andre Hedrick]

I can not help if you have a device that not compliant to the rules.
ATA-2 is OBSOLETED thus we forced (the NCITS Standards Body) the CFA
people to move to ATA-4 or ATA-5.

That device is enabling with its ablity to assert its device->host
interrupt regardless of the HOST...that is a bad device.

Send me the manufacturer and I will tear them apart for making a
non-compliant device.  Then figure out a way to de-assert the like
regardless if it exists without hang the rest of the driver.

Cheers,


On Tue, 26 Jun 2001, Gunther Mayer wrote:

> Hi,
> 
> this patch fixes the hard hang (no SYSRQ) on inserting
> any PCMCIA ATA/IDE card (e.g. CompactFlash, Clik40 etc)
> to a PCI-Cardbus bridge add-in card.
> 
> Thanks David for his valuable explanation about what happens:
> ide-probe registers it's irq handler too late! After it
> triggers the interrupt during the probe the (shared) irq
> loops forever, effectively wedging the machine completely.
> 
> Regards, Gunther
> 
> 
> 
> --- linux245.orig/drivers/ide/ide-cs.c  Fri Feb  9 20:40:02 2001
> +++ linux/drivers/ide/ide-cs.c  Tue Jun 26 21:22:19 2001
> @@ -324,6 +324,9 @@
>      if (link->io.NumPorts2)
>         release_region(link->io.BasePort2, link->io.NumPorts2);
>  
> +    outb(0x02, ctl_base); // Set nIEN = disable device interrupts
> +                         // else it hangs on PCI-Cardbus add-in cards, wedging irq
> +
>      /* retry registration in case device is still spinning up */
>      for (i = 0; i < 10; i++) {
>         hd = ide_register(io_base, ctl_base, link->irq.AssignedIRQ);
> --- linux245.orig/drivers/ide/ide-probe.c       Sun Mar 18 18:25:02 2001
> +++ linux/drivers/ide/ide-probe.c       Tue Jun 26 21:25:07 2001
> @@ -685,6 +685,8 @@
>  #else /* !CONFIG_IDEPCI_SHARE_IRQ */
>                 int sa = (hwif->chipset == ide_pci) ? SA_INTERRUPT|SA_SHIRQ : SA_INTERRUPT;
>  #endif /* CONFIG_IDEPCI_SHARE_IRQ */
> +
> +               outb(0x00, hwif->io_ports[IDE_CONTROL_OFFSET]); // clear nIEN == enable irqs
>                 if (ide_request_irq(hwif->irq, &ide_intr, sa, hwif->name, hwgroup)) {
>                         if (!match)
>                                 kfree(hwgroup);
> 

Andre Hedrick
ASL Kernel Development
Linux ATA Development
-----------------------------------------------------------------------------
ASL, Inc.                                     Toll free: 1-877-ASL-3535
1757 Houret Court                             Fax: 1-408-941-2071
Milpitas, CA 95035                            Web: www.aslab.com

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Alan Cox]

> I can not help if you have a device that not compliant to the rules.
> ATA-2 is OBSOLETED thus we forced (the NCITS Standards Body) the CFA

ATA-2 may be obsolete but existing ATA-2 hardware doesnt spontaenously
combust when the spec changes (much Im sure to some vendors dissappointmnent)

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Andre Hedrick]

Alan,

It is an issue that we have been trying to get fixed, and only after
obsoleting ATA-2 did their attention at CFA become alarmed.  I agree that
there needs to be a fix, but not at the price of locking the rest of the
driver.  Since we now the identity of the device prior to assigned the
interrupt we can handle the execption, but you do not go around blanket
wacking the control register of all devices.

You know yourself first and all the screwed up ATAPI products that are
still using SFF-8020 that has been obsoleted before I start maintaining
the subsystem three plus years ago. 

The only way to get hardware fixed is to point out is broken and force the
issue.

I have one of these broken device with me, but I quit using it because of
that hardware flaw, mostly because I did not have the time to deal with
CFA and there lameness to follow the rules even when huge amounts of time
have passed between the notification and execution of obsolesense (sp).

Since David claims it is a known error we need to take the dirty list in
ide.c dealing with CFA's that are detected by name strings or correctly
putting in the CFA signature in word0 of identify.

I have no problem in fixing it, just blanket chopper gunning is not always
safe.

Cheers,

Andre Hedrick
ASL Kernel Development
Linux ATA Development
-----------------------------------------------------------------------------
ASL, Inc.                                     Toll free: 1-877-ASL-3535
1757 Houret Court                             Fax: 1-408-941-2071
Milpitas, CA 95035                            Web: www.aslab.com

On Wed, 27 Jun 2001, Alan Cox wrote:

> > I can not help if you have a device that not compliant to the rules.
> > ATA-2 is OBSOLETED thus we forced (the NCITS Standards Body) the CFA
> 
> ATA-2 may be obsolete but existing ATA-2 hardware doesnt spontaenously
> combust when the spec changes (much Im sure to some vendors dissappointmnent)
> 

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Alan Cox]

> obsoleting ATA-2 did their attention at CFA become alarmed.  I agree that
> there needs to be a fix, but not at the price of locking the rest of the
> driver.  Since we now the identity of the device prior to assigned the
> interrupt we can handle the execption, but you do not go around blanket
> wacking the control register of all devices.

I dont see why it locks up the driver ?

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Andre Hedrick]

PARANIOA.

Remember that ATAPI is generally screwed beyond reality, so adjusting the
probe code in general (global) is a bad thing.

Andre Hedrick
ASL Kernel Development
Linux ATA Development
-----------------------------------------------------------------------------
ASL, Inc.                                     Toll free: 1-877-ASL-3535
1757 Houret Court                             Fax: 1-408-941-2071
Milpitas, CA 95035                            Web: www.aslab.com

On Wed, 27 Jun 2001, Alan Cox wrote:

> > obsoleting ATA-2 did their attention at CFA become alarmed.  I agree that
> > there needs to be a fix, but not at the price of locking the rest of the
> > driver.  Since we now the identity of the device prior to assigned the
> > interrupt we can handle the execption, but you do not go around blanket
> > wacking the control register of all devices.
> 
> I dont see why it locks up the driver ?
> 
> 

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Gunther Mayer]

Andre Hedrick wrote:
> 
> PARANIOA.

This is not a valid reason.

This clearly fixes a bug in linux. Note: the irq disable
is local to ide-cs. Are you paranoid enough to believe
enabling the irq by writing globally to the control register that
existed since ATA will have ill effects? 

You claim the relevant PCMCIA ATA behaviour is not ATA(>3?) compliant,
however you didn`t yet give any facts to support this !

You claim this locks the driver, again no facts.


> 
> Remember that ATAPI is generally screwed beyond reality, so adjusting the
> probe code in general (global) is a bad thing.
...
> On Wed, 27 Jun 2001, Alan Cox wrote:
> 
> > > obsoleting ATA-2 did their attention at CFA become alarmed.  I agree that
> > > there needs to be a fix, but not at the price of locking the rest of the
> > > driver.  Since we now the identity of the device prior to assigned the
> > > interrupt we can handle the execption, but you do not go around blanket
> > > wacking the control register of all devices.

The proposed patch is very simple (as per Linus' liking). When considering to
install an earlier (and  global) irq handler I believe you can see
this will impose a much greater risk !

> >
> > I dont see why it locks up the driver ?

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Andre Hedrick]

Gunther,

It fixes a BUG in CFA, but what will it do to the other stuff?
Parse it exclusive to CFA and there is not an issue.

Also look closely....

No all ./arch have a control register doing this randomly without know the
rest of the driver will kill more than it fixes.

static int try_to_identify (ide_drive_t *drive, byte cmd)
{
        int rc;
        ide_ioreg_t hd_status;
        unsigned long timeout;
        unsigned long irqs = 0;
        byte s, a;

        if (IDE_CONTROL_REG) {
<snip>
        } else {
                ide_delay_50ms();
                hd_status = IDE_STATUS_REG;
        }
<snip>
}

It will not be accepted until it correctly address and handles all HOSTs
correctly, period.

Andre Hedrick
ASL Kernel Development
Linux ATA Development
-----------------------------------------------------------------------------
ASL, Inc.                                     Toll free: 1-877-ASL-3535
1757 Houret Court                             Fax: 1-408-941-2071
Milpitas, CA 95035                            Web: www.aslab.com

On Wed, 27 Jun 2001, Gunther Mayer wrote:

> Andre Hedrick wrote:
> > 
> > PARANIOA.
> 
> This is not a valid reason.
> 
> This clearly fixes a bug in linux. Note: the irq disable
> is local to ide-cs. Are you paranoid enough to believe
> enabling the irq by writing globally to the control register that
> existed since ATA will have ill effects? 
> 
> You claim the relevant PCMCIA ATA behaviour is not ATA(>3?) compliant,
> however you didn`t yet give any facts to support this !
> 
> You claim this locks the driver, again no facts.
> 
> 
> > 
> > Remember that ATAPI is generally screwed beyond reality, so adjusting the
> > probe code in general (global) is a bad thing.
> ...
> > On Wed, 27 Jun 2001, Alan Cox wrote:
> > 
> > > > obsoleting ATA-2 did their attention at CFA become alarmed.  I agree that
> > > > there needs to be a fix, but not at the price of locking the rest of the
> > > > driver.  Since we now the identity of the device prior to assigned the
> > > > interrupt we can handle the execption, but you do not go around blanket
> > > > wacking the control register of all devices.
> 
> The proposed patch is very simple (as per Linus' liking). When considering to
> install an earlier (and  global) irq handler I believe you can see
> this will impose a much greater risk !
> 
> > >
> > > I dont see why it locks up the driver ?
> 

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[David Hinds]

On Wed, Jun 27, 2001 at 12:29:47AM -0700, Andre Hedrick wrote:
> 
> I can not help if you have a device that not compliant to the rules.
> ATA-2 is OBSOLETED thus we forced (the NCITS Standards Body) the CFA
> people to move to ATA-4 or ATA-5.
> 
> That device is enabling with its ablity to assert its device->host
> interrupt regardless of the HOST...that is a bad device.
> 
> Send me the manufacturer and I will tear them apart for making a
> non-compliant device.  Then figure out a way to de-assert the like
> regardless if it exists without hang the rest of the driver.

I don't understand the ATA spec issue, but *every* PCMCIA ATA device I
know of (including all SmartMedia, CompactFlash, etc) suffers from
this problem.  It is not an isolated manufacturer.  As far as I know,
the IDE driver has always had the problem that it may trigger
interrupts before it installs a handler.  Are you saying that is only
true of pre-ATA-4 devices, or only devices that deviate from the spec?

-- Dave

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Andre Hedrick]

It should be all devices that do not claim ATA-4/5 support.
I have to go back and look to see what the cut-off was that CFA agreed to
move forward off the dead docs.

Cheers,

Andre Hedrick
ASL Kernel Development
Linux ATA Development
-----------------------------------------------------------------------------
ASL, Inc.                                     Toll free: 1-877-ASL-3535
1757 Houret Court                             Fax: 1-408-941-2071
Milpitas, CA 95035                            Web: www.aslab.com

On Wed, 27 Jun 2001, David Hinds wrote:

> On Wed, Jun 27, 2001 at 12:29:47AM -0700, Andre Hedrick wrote:
> > 
> > I can not help if you have a device that not compliant to the rules.
> > ATA-2 is OBSOLETED thus we forced (the NCITS Standards Body) the CFA
> > people to move to ATA-4 or ATA-5.
> > 
> > That device is enabling with its ablity to assert its device->host
> > interrupt regardless of the HOST...that is a bad device.
> > 
> > Send me the manufacturer and I will tear them apart for making a
> > non-compliant device.  Then figure out a way to de-assert the like
> > regardless if it exists without hang the rest of the driver.
> 
> I don't understand the ATA spec issue, but *every* PCMCIA ATA device I
> know of (including all SmartMedia, CompactFlash, etc) suffers from
> this problem.  It is not an isolated manufacturer.  As far as I know,
> the IDE driver has always had the problem that it may trigger
> interrupts before it installs a handler.  Are you saying that is only
> true of pre-ATA-4 devices, or only devices that deviate from the spec?
> 
> -- Dave
> 

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Gunther Mayer]

Andre Hedrick wrote:
> 
> I can not help if you have a device that not compliant to the rules.
> ATA-2 is OBSOLETED thus we forced (the NCITS Standards Body) the CFA
> people to move to ATA-4 or ATA-5.

See Alan's point about existing hardware.

> 
> That device is enabling (with its ablity to assert) its device->host
> interrupt regardless of the HOST...that is a bad device.

Does this imply ATA-4 specifies the device should
come up with nIEN set (i.e. interrupts disabled)?


> 
> Send me the manufacturer and I will tear them apart for making a
> non-compliant device.  

see below.

>Then figure out a way to de-assert the like
> regardless if it exists without hang the rest of the driver.
>

My patch has figured this out !
It enables interrupts again (clear nIEN) shortly before it registers the irq handler.
At least boot+root on /dev/hda do not hang.

Regards, Gunther



1) Compact Flash 48MB, Silicon Tech/Hitachi 
===========================================
dump_cis
Socket 0:
  dev_info
    fn_specific 400ns, 2kb
  common_jedec 0xdf 0x01
  manfid 0x014d, 0x0001
  vers_1 4.1, "SiliconTech,Inc.", "48MB Compact PC Card", "Ver 3.0"
  funcid fixed_disk [post]
  disk_interface [ide]
  disk_features [silicon] [unique] [single]
    [sleep] [standby] [idle] [low power]
  config base 0x0200 mask 0x000f last_index 0x03
  cftable_entry 0x00 [default]
    [rdybsy] [pwrdown]
    Vcc Vnom 5V
    memory 0x0000-0x07ff @ 0x0000
  cftable_entry 0x00
    Vcc Vnom 3300mV Ipeak 45mA
  cftable_entry 0x01 [default]
    [rdybsy] [pwrdown]
    Vcc Vnom 5V
    io 0x0000-0x000f [lines=4] [8bit] [16bit]
    irq mask 0xffff [level] [pulse] [shared]
  cftable_entry 0x01
    Vcc Vnom 3300mV Ipeak 45mA
  cftable_entry 0x02 [default]
    [rdybsy] [pwrdown]
    Vcc Vnom 5V
    io 0x01f0-0x01f7, 0x03f6-0x03f7 [lines=10] [8bit] [16bit] [range]
    irq 14 [level] [pulse] [shared]
  cftable_entry 0x02
    Vcc Vnom 3300mV Ipeak 45mA
  cftable_entry 0x03 [default]
    [rdybsy] [pwrdown]
    Vcc Vnom 5V
    io 0x0170-0x0177, 0x0376-0x0377 [lines=10] [8bit] [16bit] [range]
    irq 14 [level] [pulse] [shared]
  cftable_entry 0x03
    Vcc Vnom 3300mV Ipeak 45mA

Jun 27 17:32:13 linux kernel: hde: Hitachi CV 7.1.1, ATA DISK drive

2) Iomega Clik40
================
 dump_cis
Socket 0:
  dev_info
    NULL 0ns, 512b
  attr_dev_info
    EEPROM 250ns, 2kb
  vers_1 4.1, "PC CARD MANUFACTURER", "PCMCIA ATA/ATAPI Adapter",
    "Version 3.00"
  manfid 0xffff, 0x0003
  funcid fixed_disk
  disk_interface [ide]
  config base 0x0800 mask 0x0001 last_index 0x05
  cftable_entry 0x25 [default]
    io 0x0180-0x0187, 0x0386-0x0387 [lines=10] [16bit] [range]
    irq mask 0xfe00 [level] [pulse]
  cftable_entry 0x0d
    io 0x0170-0x0177, 0x0376-0x0377 [lines=10] [16bit] [range]
  cftable_entry 0x15
    io 0x01e8-0x01ef, 0x03ee-0x03ef [lines=10] [16bit] [range]
  cftable_entry 0x1d
    io 0x0168-0x016f, 0x036e-0x036f [lines=10] [16bit] [range]
  cftable_entry 0x05
    io 0x01f0-0x01f7, 0x03f6-0x03f7 [lines=10] [16bit] [range]

Jun 27 17:36:39 linux kernel: hde: IOMEGA Clik! 40 CZ ATAPI, ATAPI cdrom or floppy?, assuming FLOPPY drive

> 
> On Tue, 26 Jun 2001, Gunther Mayer wrote:
> 
> > Hi,
> >
> > this patch fixes the hard hang (no SYSRQ) on inserting
> > any PCMCIA ATA/IDE card (e.g. CompactFlash, Clik40 etc)
> > to a PCI-Cardbus bridge add-in card.
> >
> > Thanks David for his valuable explanation about what happens:
> > ide-probe registers it's irq handler too late! After it
> > triggers the interrupt during the probe the (shared) irq
> > loops forever, effectively wedging the machine completely.
> >
> > Regards, Gunther
> >
> >
> >
> > --- linux245.orig/drivers/ide/ide-cs.c  Fri Feb  9 20:40:02 2001
> > +++ linux/drivers/ide/ide-cs.c  Tue Jun 26 21:22:19 2001
> > @@ -324,6 +324,9 @@
> >      if (link->io.NumPorts2)
> >         release_region(link->io.BasePort2, link->io.NumPorts2);
> >
> > +    outb(0x02, ctl_base); // Set nIEN = disable device interrupts
> > +                         // else it hangs on PCI-Cardbus add-in cards, wedging irq
> > +
> >      /* retry registration in case device is still spinning up */
> >      for (i = 0; i < 10; i++) {
> >         hd = ide_register(io_base, ctl_base, link->irq.AssignedIRQ);
> > --- linux245.orig/drivers/ide/ide-probe.c       Sun Mar 18 18:25:02 2001
> > +++ linux/drivers/ide/ide-probe.c       Tue Jun 26 21:25:07 2001
> > @@ -685,6 +685,8 @@
> >  #else /* !CONFIG_IDEPCI_SHARE_IRQ */
> >                 int sa = (hwif->chipset == ide_pci) ? SA_INTERRUPT|SA_SHIRQ : SA_INTERRUPT;
> >  #endif /* CONFIG_IDEPCI_SHARE_IRQ */
> > +
> > +               outb(0x00, hwif->io_ports[IDE_CONTROL_OFFSET]); // clear nIEN == enable irqs
> >                 if (ide_request_irq(hwif->irq, &ide_intr, sa, hwif->name, hwgroup)) {
> >                         if (!match)
> >                                 kfree(hwgroup);
> >