Re: isa memory address

[Antonino Sergi]

Hi,

I found a new problem: I was testing my driver on a P233MMX with
2.6.5 i586 compiled without any trouble. When I moved to a PIII500
with the 2.6.9 i686 compiled I got kernel oops because the IOaddresss
(0xd0000) was remapped to 0x20d0000 and
"Unable to handle kernel paging request at virtual address fef66c58"
I think it is something related to 4GB memory kernel config parameter

Because of some hurry I tried the other kernel (2.6.9 i586 compiled)
and this problem disappeared (IOaddresss 0xd0000 remapped to
0xc00d0000), but it seems that the requested memory area is not
protected anymore by foreign access, in fact:
-on both machines, if the kernel module is not loaded, I can see, on
hard disk activity, a blinking LED on the data acquisition system,
notifying some access to the device
-on P233MMX and NOT on PIII500, once the module is loaded, these
accidental accesses are actually forbidden. This produces, on PIII500,
fake data

Is there any remarkable difference in resource reservation between these
two kernels or it is due to some hardware difference? I tried to look at
include/linux/ioport.h and kernel/resource.c but I could not notice any
difference.

Thank you

Antonino Sergi

On Thu, 2004-11-11 at 04:54, Maciej W. Rozycki wrote:
> On Wed, 10 Nov 2004, Antonino Sergi wrote:
> 
> > >  Because you are trying to use the region in the I/O port space.  That's
> > > probably not what you want to do and an 8-bit ISA board cannot decode it
> > > at all anyway.  Actually for some platforms using the I/O space outside
> > > the low 16-bit range may be quite difficult even for buses and devices
> > > that support it and Linux does not support it then, either.  So Linux 
> > > correctly informs you you cannot use that range.
> > 
> > This is actually not clear for me.
> 
>  The port I/O space range differs among platforms.  You get -EBUSY in a
> response to a request for a range of ports outside the supported range.
> 
> > >  ... or better yet request_mem_region()/release_resource(), as the former 
> > > is deprecated and will be removed.
> > 
> > I tried but (on 2.4.2):
> > - request_region fails but, ignoring it and remapping physical address
> > to virtual, everything works fine, except for release_region, of course.
> > - request_mem_region works but what I get from communication with the
> > actual device are numbers that sometimes are surely wrong.
> 
>  As both request_region() and request_mem_region() merely reserve
> different resources in Linux structures, you can't get a different
> behavior from your device depending on which one you call, if any at all,
> unless you change code elsewhere at the same time.
> 
> > I couldn't understand what is the actual difference between
> > ioport_resource and iomem_resource to track the problem.
> 
>  The former holds I/O resources mapped in the port space, whilst the
> latter holds ones mapped in the memory space.  The spaces use different
> cycles each at the bus the destined device is located on.
> 
>   Maciej

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