Re: 2.6.17-rc[56]-mm*: pcmcia "I/O resource not free"

[Vivek Goyal <vgoyal@in.ibm.com>]

On Wed, Jun 21, 2006 at 10:10:48AM -0700, Andy Isaacson wrote:
> On Wed, Jun 21, 2006 at 12:46:30AM -0700, Andrew Morton wrote:
> > > [ 2034.060000] pcmcia: registering new device pcmcia0.0
> > > [ 2034.060000] PM: Adding info for pcmcia:0.0
> > > [ 2035.976000] conflict: PCI IO[0->ffff]
> > > [ 2035.976000] hwif_request_region: single-byte request for ide2
> > > [ 2035.976000]  [<c0257386>] hwif_request_region+0xa6/0xb0
> [snip]
> > > [ 2035.976000] ide2: I/O resource 0xF8B0200E-0xF8B0200E not free.
> > > [ 2035.976000] ide2: ports already in use, skipping probe
> > 
> > hm.  It appears to have decided that 0 < 0xF8B0200E < 0xffff, which is
> > clever of it.
> > 
> > Does it help if you set CONFIG_RESOURCES_32BIT?
> 
> Nope, same conflict with CONFIG_RESOURCES_32BIT set.  You're right, it
> is deciding that 0xF8B0200E conflicts with that range:
> 
> conflict: PCI IO[0->ffff] conflicts with ide2[f8b3c00e->f8b3c00e]
> 
> Looking at the code, I don't understand how this could have worked in
> -rc6; __request_resource hasn't changed, and it says
> 
>     167         if (end < start)
>     168                 return root;
>     169         if (start < root->start)
>     170                 return root;
>     171         if (end > root->end)
>     172                 return root;
> 
> If root-> start == 0 and root->end == 0xffff, we should always hit line
> 172, unless sign extension is in effect... and all the variables are
> unsigned long in -rc6, so that doesn't make sense.
> 

I think this makes sense. We are hitting line 172 in case of -mm because
f8b3c00e is not a valid io port at all. Maximum valid value can be 0xffff.
So _request_region considers this to be a conflict and returns.
 
It succeeds in -rc6 because ide code is requesting a valid ioport region
ide2[310e->310e].

So __request_region() code seems to be fine. Problem seems to be that
why do we get an invalid ioport range in following call.

addr = hwif->io_ports[IDE_CONTROL_OFFSET];

Either hwif pointer is bad or somehow the location it is pointing to
is corrupt or something else. Can you do some more tracing on hwif.

Thanks
Vivek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/