hi,
I've been trying to get a CompactFlash act as an IDE-drive, 2nd or 3rd
ide-channel, that is, IDE1 or IDE2 resp. Didn't work. Seems to be driver
related.
I downloaded 2.4.18 and pcmcia-3.1.31, from the later I got "ide_cs.o"
The hardware I am using a a two socket PCI to PCMCIA bridge:
hale-bopp:~ # cat /proc/interrupts
[...]
10: 1 XT-PIC Texas Instruments PCI1221, Texas Instruments PCI1221 (#2)
when the init-script starts the pcmcia modules + cardmgr, the following
messages will appear in the kernel-log:
: Linux Kernel Card Services 3.1.22
: options: [pci] [cardbus] [pm]
: PCI: Found IRQ 10 for device 00:09.0
: PCI: Sharing IRQ 10 with 00:09.1
: PCI: Found IRQ 10 for device 00:09.1
: PCI: Sharing IRQ 10 with 00:09.0
: Yenta IRQ list 0000, PCI irq10
: Socket status: 30000006
: Yenta IRQ list 0000, PCI irq10
: Socket status: 30000010
: cs: IO port probe 0x0c00-0x0cff: clean.
: cs: IO port probe 0x0800-0x08ff: clean.
: cs: IO port probe 0x0100-0x04ff: excluding 0x4d0-0x4d7
: cs: IO port probe 0x0a00-0x0aff: clean.
: cs: memory probe 0xa0000000-0xa0ffffff: clean.
: hde: SanDisk SDCFB-16, ATA DISK drive
: ide2: Disabled unable to get IRQ 10.
: hde: ERROR, PORTS ALREADY IN USE
: ide2: ports already in use, skipping probe
: ide2: ports already in use, skipping probe
: ide2: ports already in use, skipping probe
: ide2: ports already in use, skipping probe
: ide2: ports already in use, skipping probe
: ide2: ports already in use, skipping probe
: ide2: ports already in use, skipping probe
: ide2: ports already in use, skipping probe
: ide_cs: ide_register() at 0x100 & 0x10e, irq 10 failed
: Trying to free nonexistent resource <00000100-0000010f>
"unable to get IRQ 10" is somewhat funny, since IRQ-10 is used by
the cardbus device. what I don't understand is if the IDE-drive
sould get its own interrupt or not.
"ports already in use" doesnt go away even when I remove all IDE-drives
(one CDROM, that is ;-) from ide1 and try to have the CompactFlash as
2ndry IDE (the message would then read: ide1: ports alread yin use,
skipping probe).
and finally an ugly detail: when removing the ComapctFlash and
unloading pcmcia, ide_cs will still have the ioport-ressources
clailed form /proc/ioport. seems there's a call to *_unregister
missing.
/herp
Hello!
Am Mittwoch, 27. Februar 2002 01:26 schrieb Herbert Rosmanith:
> I downloaded 2.4.18 and pcmcia-3.1.31, from the later I got "ide_cs.o"
Apart from your problem I finally found out that all dldwd_* stuff in 2.4.18
has been renamed to orinoco_*, so pcmcia-3.1.31 is not usable with 2.4.18...
Andi
--
Web: http://www.flood-net.de/
Mail: [email protected]
Phone: +49-(0)-30-680577-44
Linux opens doors, not windows!
http://www.bundestux.de/ http://counter.li.org/
diff -ur linux-2.4.15.orig/drivers/ide/ide-cs.c linux/drivers/ide/ide-cs.c
--- linux-2.4.15.orig/drivers/ide/ide-cs.c Sun Sep 30 21:26:05 2001
+++ linux/drivers/ide/ide-cs.c Sun Nov 25 13:11:36 2001
@@ -42,6 +42,7 @@
#include <linux/ioport.h>
#include <linux/hdreg.h>
#include <linux/major.h>
+#include <linux/ide.h>
#include <asm/io.h>
#include <asm/system.h>
@@ -226,6 +227,16 @@
#define CFG_CHECK(fn, args...) \
if (CardServices(fn, args) != 0) goto next_entry
+int idecs_register (int io_base, int ctl_base, int irq)
+{
+ hw_regs_t hw;
+ ide_init_hwif_ports(&hw, (ide_ioreg_t) io_base, (ide_ioreg_t) ctl_base, NULL);
+ hw.irq = irq;
+ hw.chipset = ide_pci; // this enables IRQ sharing w/ PCI irqs
+ return ide_register_hw(&hw, NULL);
+}
+
+
void ide_config(dev_link_t *link)
{
client_handle_t handle = link->handle;
@@ -327,12 +338,16 @@
if (link->io.NumPorts2)
release_region(link->io.BasePort2, link->io.NumPorts2);
+ /* disable drive interrupts during IDE probe */
+ if(ctl_base)
+ outb(0x02, ctl_base);
+
/* 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);
+ hd = idecs_register(io_base, ctl_base, link->irq.AssignedIRQ);
if (hd >= 0) break;
if (link->io.NumPorts1 == 0x20) {
- hd = ide_register(io_base+0x10, ctl_base+0x10,
+ hd = idecs_register(io_base+0x10, ctl_base+0x10,
link->irq.AssignedIRQ);
if (hd >= 0) {
io_base += 0x10; ctl_base += 0x10;
Only in linux/drivers/ide: ide-cs.c-2415
diff -ur linux-2.4.15.orig/drivers/ide/ide.c linux/drivers/ide/ide.c
--- linux-2.4.15.orig/drivers/ide/ide.c Thu Oct 25 22:58:35 2001
+++ linux/drivers/ide/ide.c Sun Nov 25 13:02:34 2001
@@ -2293,6 +2293,7 @@
memcpy(hwif->io_ports, hwif->hw.io_ports, sizeof(hwif->hw.io_ports));
hwif->irq = hw->irq;
hwif->noprobe = 0;
+ hwif->chipset = hw->chipset;
if (!initializing) {
ide_probe_module();
diff -ur linux-2.4.15.orig/include/linux/ide.h linux/include/linux/ide.h
--- linux-2.4.15.orig/include/linux/ide.h Thu Nov 22 20:48:07 2001
+++ linux/include/linux/ide.h Sun Nov 25 13:05:57 2001
@@ -223,6 +223,23 @@
#endif
/*
+ * hwif_chipset_t is used to keep track of the specific hardware
+ * chipset used by each IDE interface, if known.
+ */
+typedef enum { ide_unknown, ide_generic, ide_pci,
+ ide_cmd640, ide_dtc2278, ide_ali14xx,
+ ide_qd65xx, ide_umc8672, ide_ht6560b,
+ ide_pdc4030, ide_rz1000, ide_trm290,
+ ide_cmd646, ide_cy82c693, ide_4drives,
+ ide_pmac, ide_etrax100
+} hwif_chipset_t;
+
+#define IDE_CHIPSET_PCI_MASK \
+ ((1<<ide_pci)|(1<<ide_cmd646)|(1<<ide_ali14xx))
+#define IDE_CHIPSET_IS_PCI(c) ((IDE_CHIPSET_PCI_MASK >> (c)) & 1)
+
+
+/*
* Structure to hold all information about the location of this port
*/
typedef struct hw_regs_s {
@@ -231,6 +248,7 @@
int dma; /* our dma entry */
ide_ack_intr_t *ack_intr; /* acknowledge interrupt */
void *priv; /* interface specific data */
+ hwif_chipset_t chipset;
} hw_regs_t;
/*
@@ -439,22 +457,6 @@
* ide soft-power support
*/
typedef int (ide_busproc_t) (struct hwif_s *, int);
-
-/*
- * hwif_chipset_t is used to keep track of the specific hardware
- * chipset used by each IDE interface, if known.
- */
-typedef enum { ide_unknown, ide_generic, ide_pci,
- ide_cmd640, ide_dtc2278, ide_ali14xx,
- ide_qd65xx, ide_umc8672, ide_ht6560b,
- ide_pdc4030, ide_rz1000, ide_trm290,
- ide_cmd646, ide_cy82c693, ide_4drives,
- ide_pmac, ide_etrax100
-} hwif_chipset_t;
-
-#define IDE_CHIPSET_PCI_MASK \
- ((1<<ide_pci)|(1<<ide_cmd646)|(1<<ide_ali14xx))
-#define IDE_CHIPSET_IS_PCI(c) ((IDE_CHIPSET_PCI_MASK >> (c)) & 1)
#ifdef CONFIG_BLK_DEV_IDEPCI
typedef struct ide_pci_devid_s {
Gunther,
I gave this the heads up and verified a long time ago.
I am puzzled why this has not been adopted.
It at least made it into 2.5.3.
Marcelo, please take this fix!
On Wed, 27 Feb 2002, Gunther Mayer wrote:
> Herbert Rosmanith wrote:
>
> > hi,
> >
> > I've been trying to get a CompactFlash act as an IDE-drive, 2nd or 3rd
> > ide-channel, that is, IDE1 or IDE2 resp. Didn't work. Seems to be driver
> > related.
> >
> > I downloaded 2.4.18 and pcmcia-3.1.31, from the later I got "ide_cs.o"
> >
> > The hardware I am using a a two socket PCI to PCMCIA bridge:
> >
> > hale-bopp:~ # cat /proc/interrupts
> > [...]
> > 10: 1 XT-PIC Texas Instruments PCI1221, Texas Instruments PCI1221 (#2)
> > ...
> > : hde: SanDisk SDCFB-16, ATA DISK drive
> > : ide2: Disabled unable to get IRQ 10.
> > ...
> > : ide_cs: ide_register() at 0x100 & 0x10e, irq 10 failed
> > : Trying to free nonexistent resource <00000100-0000010f>
> >
> > "unable to get IRQ 10" is somewhat funny, since IRQ-10 is used by
> > the cardbus device. what I don't understand is if the IDE-drive
> > sould get its own interrupt or not.
>
> With PCI-PCMCIA bridges you only have _one_ PCI irq, but linux
> falsely fails to share irq in this case.
>
> This patch exists since 6 months but due to communiation problems
> between Linux and IDE maintainer nobody cared to include it.
>
> Find my patch for 2.4.15 appended.
> -
> Gunther
>
>
>
Andre Hedrick
Linux Disk Certification Project Linux ATA Development
Herbert Rosmanith wrote:
> "unable to get IRQ 10" is somewhat funny, since IRQ-10 is used by
> the cardbus device. what I don't understand is if the IDE-drive
> sould get its own interrupt or not.
The card should (must) share the PCI interrupt with the CardBus bridge
device. However, the IDE driver assumes that it should have exclusive
use of the interrupt, because it doesn't believe that this is a PCI
IDE device (well, it is sort of an ISA IDE device sitting behind a PCI
bridge).
> and finally an ugly detail: when removing the ComapctFlash and
> unloading pcmcia, ide_cs will still have the ioport-ressources
> clailed form /proc/ioport. seems there's a call to *_unregister
> missing.
The ide_cs driver does call ide_unregister(). The problem is that the
IDE driver doesn't clean up properly if you hot-eject an interface
that has active devices associated with it. Use "cardctl eject"
before you eject an IDE card.
-- Dave
Andreas Roedl wrote:
> Apart from your problem I finally found out that all dldwd_* stuff in 2.4.18
> has been renamed to orinoco_*, so pcmcia-3.1.31 is not usable with 2.4.18...
Err what?
Why would the names of functions in the orinoco_cs driver affect the
usability of the pcmcia-cs package on a particular kernel?
I think you're doing something wrong. The only circumstance I could
imagine this making a difference is if you're trying to mix some of
the orinoco modules from the kernel tree with other orinoco modules
from the pcmcia-cs tree.
-- Dave
Hello!
Am Mittwoch, 27. Februar 2002 20:10 schrieb dhinds:
> Andreas Roedl wrote:
> > Apart from your problem I finally found out that all dldwd_* stuff in
> > 2.4.18 has been renamed to orinoco_*, so pcmcia-3.1.31 is not usable with
> > 2.4.18...
>
> Err what?
/lib/modules/2.4.18/pcmcia/orinoco_cs.o: unresolved symbol dldwd_proc_dev_init
/lib/modules/2.4.18/pcmcia/orinoco_cs.o: unresolved symbol dldwd_setup
/lib/modules/2.4.18/pcmcia/orinoco_cs.o: unresolved symbol dldwd_shutdown
/lib/modules/2.4.18/pcmcia/orinoco_cs.o: unresolved symbol
dldwd_proc_dev_cleanup
/lib/modules/2.4.18/pcmcia/orinoco_cs.o: unresolved symbol dldwd_reset
/lib/modules/2.4.18/pcmcia/orinoco_cs.o: unresolved symbol dldwd_interrupt
/lib/modules/2.4.18/pcmcia/orinoco_cs.o: insmod
/lib/modules/2.4.18/pcmcia/orinoco_cs.o failed
/lib/modules/2.4.18/pcmcia/orinoco_cs.o: insmod orinoco_cs failed
?
Andi
--
Web: http://www.flood-net.de/
Mail: [email protected]
Phone: +49-(0)-30-680577-44
Linux opens doors, not windows!
http://www.bundestux.de/ http://counter.li.org/
On Wed, Feb 27, 2002 at 09:49:51PM +0100, Andreas Roedl wrote:
>
> /lib/modules/2.4.18/pcmcia/orinoco_cs.o: unresolved symbol dldwd_proc_dev_init
> /lib/modules/2.4.18/pcmcia/orinoco_cs.o: unresolved symbol dldwd_setup
> /lib/modules/2.4.18/pcmcia/orinoco_cs.o: unresolved symbol dldwd_shutdown
> /lib/modules/2.4.18/pcmcia/orinoco_cs.o: unresolved symbol
> dldwd_proc_dev_cleanup
> /lib/modules/2.4.18/pcmcia/orinoco_cs.o: unresolved symbol dldwd_reset
> /lib/modules/2.4.18/pcmcia/orinoco_cs.o: unresolved symbol dldwd_interrupt
> /lib/modules/2.4.18/pcmcia/orinoco_cs.o: insmod
> /lib/modules/2.4.18/pcmcia/orinoco_cs.o failed
> /lib/modules/2.4.18/pcmcia/orinoco_cs.o: insmod orinoco_cs failed
>
> ?
Did you read my explanation?
You've somehow ended up loading the hermes module from the 2.4.18
kernel tree, and the orinoco_cs module from the pcmcia-cs package.
"modprobe" is probably getting confused by having several modules with
the same names, in different directories.
If you use just the pcmcia-cs modules, (or just the kernel modules),
then everything should work fine on 2.4.18.
-- Dave