[fixed] orinoco_cs.c cannot get io ports (cs.c 1.271), can anyone
help me understand why?
Jens B. Jorgensen
jbj1 at ultraemail.net
Tue Jun 8 18:47:07 EDT 2004
So after putting in all manner of printk() statements deeper and deeper
I discovered something interesting. I was using lxr to trace through the
source on the web and noticed that my fedora core 2 source for
rsrc_mgr.c didn't match that of the "stock" 2.6.5 code. In particular, I
noticed that the fedora core 2 code has
int find_io_region(ioaddr_t *base, ioaddr_t num, unsigned long align,
char *name, struct pcmcia_socket *s)
{
struct resource *res = make_resource(0, num, IORESOURCE_IO, name);
struct pcmcia_align_data data;
unsigned long min = *base;
int ret;
if (align == 0)
align = 0x10000;
data.mask = align - 1;
data.offset = *base & data.mask;
data.map = &io_db;
#ifdef CONFIG_PCI
if (s->cb_dev) {
ret = pci_bus_alloc_resource(s->cb_dev->bus, res, num, 1,
min, 0, pcmcia_align, &data);
printk(KERN_ERR "rsrc_mgr.c: pci_bus_alloc_resource(...)
returne
d %d\n", ret);
} else
#endif
{
down(&rsrc_sem);
ret = allocate_resource(&ioport_resource, res, num, min,
~0UL, 0
,
pcmcia_align, &data);
printk(KERN_ERR "rsrc_mgr.c: allocate_resource(...)
returned %d\n", ret);
up(&rsrc_sem);
}
if (ret != 0) {
kfree(res);
} else {
*base = res->start;
}
return ret;
}
while the 2.6.5 code I was looking at on lxr was:
569 int find_io_region(ioaddr_t *base, ioaddr_t num, ioaddr_t align,
570 char *name, struct pcmcia_socket *s)
571 {
572 ioaddr_t try;
573 resource_map_t *m;
574 int ret = -1;
575
576 down(&rsrc_sem);
577 for (m = io_db.next; m != &io_db; m = m->next) {
578 try = (m->base & ~(align-1)) + *base;
579 for (try = (try >= m->base) ? try : try+align;
580 (try >= m->base) && (try+num <= m->base+m->num);
581 try += align) {
582 if (request_io_resource(try, num, name, s->cb_dev) == 0) {
583 *base = try;
584 ret = 0;
585 goto out;
586 }
587 if (!align)
588 break;
589 }
590 }
591 out:
592 up(&rsrc_sem);
593 return ret;
594 }
So I thought to myself: hey, it looks like those Fedora guys decided to
make their pcmcia code use this new-fangled allocate_resource function
but perhaps the "include ..." lines in /etc/pcmcia/config.opts are
causing it to /reserve/ those ioports in such a way that they are not
available to allocate_resource? While I am not dedicated enough to
digging that far into it I saw I could easily test my theory. I
commented out the line:
include port 0x100-0x4ff, port 0xc00-0xcff
Since I new the region it was after was in that range. I did that,
restarted cardmgr and sure enough now the device came up! I'm going to
guess that /all/ off the resource lines in /etc/pcmcia/config.opts
should be commented out under fedora core 2. It looks like this would
only affect ISA bus people which are probably in the minority amongst
pcmcia users so perhaps that is why this went unnoticed.
Jens B. Jorgensen wrote:
> Hello,
>
> I'm trying to get a wireless card working under a new Fedora
> installation. I worked find under a previous install and I'm stymied
> as to why it won't work in this system. The card lives in an
> isa-to-pcmcia adapter. The Fedora install uses kernel 2.6.5-1.358. A
> working example system is a recent Knoppix using 2.4.20-xfs. In
> Knoppix I see:
>
> Linux Kernel Card Services 3.1.22
> options: [pci] [cardbus] [pm]
> Intel PCIC probe:
> Vadem VG-469 ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 2 sockets
> host opts [0]: [ext mode] [isa buf]
> host opts [1]: [ext mode] [isa buf]
> ISA irqs (scanned) = 3,4,7 polling interval = 1000 ms
> cs: IO port probe 0x0c00-0x0cff: clean.
> cs: IO port probe 0x0820-0x08ff: clean.
> cs: IO port probe 0x0800-0x080f: clean.
> cs: IO port probe 0x0100-0x04ff: excluding 0x100-0x107 0x2f8-0x2ff
> 0x378-0x37f 0
> x3f8-0x3ff 0x4d0-0x4d7
> cs: IO port probe 0x0a00-0x0aff: clean.
> cs: memory probe 0x0d0000-0x0dffff: excluding 0xdc000-0xdffff
> cs: memory probe 0x0c0000-0x0cffff: excluding 0xc0000-0xcffff
> hermes.c: 4 Dec 2002 David Gibson <hermes at gibson.dropbear.id.au>
> orinoco.c 0.13b (David Gibson <hermes at gibson.dropbear.id.au> and others)
> orinoco_cs.c 0.13b (David Gibson <hermes at gibson.dropbear.id.au> and
> others)
> eth0: Station identity 001f:0002:0001:0004
> eth0: Looks like an Intersil firmware version 1.4.2
> eth0: Ad-hoc demo mode supported
> eth0: IEEE standard IBSS ad-hoc mode supported
> eth0: WEP supported, 104-bit key
> eth0: MAC address 00:03:9D:40:1F:74
> eth0: Station name "Prism I"
> eth0: ready
> eth0: index 0x01: Vcc 3.3, irq 3, io 0x0180-0x01bf
> eth0: New link status: Connected (0001)
>
> while under the fedora system I get:
>
> Linux Kernel Card Services
> options: [pci] [cardbus] [pm]
> Intel ISA PCIC probe:
> Vadem VG-469 ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 2 sockets
> host opts [0]: [ext mode]
> host opts [1]: [ext mode]
> ISA irqs (scanned) = 3,4,7 polling interval = 1000 ms
> eth0: no IPv6 routers present
> cs: IO port probe 0x0c00-0x0cff: clean.
> cs: IO port probe 0x0100-0x04ff: excluding 0x100-0x107 0x378-0x37f
> 0x4d0-0x4d7
> cs: IO port probe 0x0a00-0x0aff: clean.
> cs: memory probe 0x0d0000-0x0dffff: clean.
> orinoco.c 0.13e (David Gibson <hermes at gibson.dropbear.id.au> and others)
> orinoco_cs.c 0.13e (David Gibson <hermes at gibson.dropbear.id.au> and
> others)
> GetNextTuple(). No matching CIS configuration, maybe you need the
> ignore_cis_vcc=1 parameter.
> orinoco_cs: GetFirstTuple: No more items
>
> I thought it curious that I don't see [isa buf] after host opts under
> 2.6.5 but I'm not even sure what that does so I've not pursued that.
> The obvious check was to try the ignore_cis_vcc. I added that and
> still the same error. So, I hacked some extra debugging info into
> orinoco_cs.c to see where things were *actually* failing. The above is
> from the first run. After having added my own debugging printks I see:
>
> orinoco_cs: skipping because pcmcia_request_io(link->handle,
> &link->io) failed: 30
> orinoco_cs: req->Attributes1 = 8, req->BasePort1 = 0, req->NumPorts1 =
> 64, req->IOAddrLines = 6
>
> so pcmcia_request_io is failing with CS_IN_USE with the above params.
> However, I cannot for the life of me figure why it was unable to find
> an ioport region. It seems to be instructed to consider the ioport
> region 0x180 - 0x1bf and in fact with this installation it is not in
> use: (excerpt from /proc/ioports)
>
> 00c0-00df : dma2
> 00f0-00ff : fpu
> 0170-0177 : ide1
> 01f0-01f7 : ide0
> 0213-0213 : ISAPnP
>
> So why would it not choose to use 0x180 - 0x1bf?! What am I missing?
>
> Thanks for any help,
>
--
Jens B. Jorgensen
jbj1 at ultraemail.net
More information about the linux-pcmcia
mailing list