isa memory address

isa memory address

[Antonino Sergi]

Hi,

I'm working with an old data acquisition system that uses an 8-bit card
in an ISA slot (address 0xd0000), by a simple driver I ported from
kernel 1.1.x to 2.2.24.

It works fine, but I'd like to have features by newer kernels (2.4 or
even 2.6), like new filesystems support.

On kernels >=2.4.0 check_region returns -EBUSY for that address,
but it is not actually used; I tried to understand if something has been
changed/removed, because of obsolescence of devices, in IO management,
but I couldn't.

Does anybody have any explanation/suggestion?

Thank you

Best Regards,

Antonino Sergi

PS:As I'm not subscribed, please CC me your answers.


Antonino Sergi <Antonino.Sergi@Roma1.INFN.it>

Radiodating Laboratory
Physics Department
University of Rome "La Sapienza"
P.le Aldo Moro 2
00185 Rome Italy
Tel +390649914206
Fax +390649914208

Re: isa memory address

[Randy.Dunlap]

Antonino Sergi wrote:
> Hi,
> 
> I'm working with an old data acquisition system that uses an 8-bit card
> in an ISA slot (address 0xd0000), by a simple driver I ported from
> kernel 1.1.x to 2.2.24.
> 
> It works fine, but I'd like to have features by newer kernels (2.4 or
> even 2.6), like new filesystems support.
> 
> On kernels >=2.4.0 check_region returns -EBUSY for that address,
> but it is not actually used; I tried to understand if something has been
> changed/removed, because of obsolescence of devices, in IO management,
> but I couldn't.
> 
> Does anybody have any explanation/suggestion?

Please post contents of /proc/iomem .
I'm guessing that it will show something like:
000e0000-000effff : Extension ROM
(but for address 000d0000).
So then the question becomes how to assign/allocate it for your
driver.

You might have to dummy up a call to release_resource() first,
then use request_resource() to acquire it.
Or just use the addresses anyway.... even though check_region() says
-EBUSY.  BTW, check_region() is deprecated in 2.6.x, so if your
driver could just use request_region() and release_region(), that
would be better.

> Thank you
> 
> Best Regards,
> 
> Antonino Sergi
> 
> PS:As I'm not subscribed, please CC me your answers.


-- 
~Randy

Re: isa memory address

[Antonino Sergi]

On Mon, 2004-11-08 at 17:46, Randy.Dunlap wrote:
> Antonino Sergi wrote:
> > Hi,
> > 
> > I'm working with an old data acquisition system that uses an 8-bit card
> > in an ISA slot (address 0xd0000), by a simple driver I ported from
> > kernel 1.1.x to 2.2.24.
> > 
> > It works fine, but I'd like to have features by newer kernels (2.4 or
> > even 2.6), like new filesystems support.
> > 
> > On kernels >=2.4.0 check_region returns -EBUSY for that address,
> > but it is not actually used; I tried to understand if something has been
> > changed/removed, because of obsolescence of devices, in IO management,
> > but I couldn't.
> > 
> > Does anybody have any explanation/suggestion?
> 
> Please post contents of /proc/iomem .
> I'm guessing that it will show something like:
> 000e0000-000effff : Extension ROM
I can't. Now it is installed redhat 6.2 (2.2.14) (I gave up about this
issue some moths ago) and I think I won't ever succeed in satisfying rpm
dep to install a compiled 2.6.x. I'll try to compile it from scratch
ASAP 
> (but for address 000d0000).
> So then the question becomes how to assign/allocate it for your
> driver.
> 
> You might have to dummy up a call to release_resource() first,
> then use request_resource() to acquire it.
> Or just use the addresses anyway.... even though check_region() says
> -EBUSY. 
I'll try, but the question is why this would be needed?  

Thank you

> > PS:As I'm not subscribed, please CC me your answers.



Antonino Sergi <Antonino.Sergi@Roma1.INFN.it>

Radiodating Laboratory
Physics Department
University of Rome "La Sapienza"
P.le Aldo Moro 2
00185 Rome Italy
Tel +390649914206
Fax +390649914208

Re: isa memory address

[Antonino Sergi]

I looked for iomem with a kernel-2.4.2:

/proc/iomem reports
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-1fffbfff : System RAM

Nothing in the region 000d0000-000d0006 (used by my driver),
so why is it BUSY?

I have not tried yet to use it anyway.

Thanks

Antonino Sergi

On Mon, 2004-11-08 at 17:46, Randy.Dunlap wrote:
> Antonino Sergi wrote:
> > Hi,
> > 
> > I'm working with an old data acquisition system that uses an 8-bit card
> > in an ISA slot (address 0xd0000), by a simple driver I ported from
> > kernel 1.1.x to 2.2.24.
> > 
> > It works fine, but I'd like to have features by newer kernels (2.4 or
> > even 2.6), like new filesystems support.
> > 
> > On kernels >=2.4.0 check_region returns -EBUSY for that address,
> > but it is not actually used; I tried to understand if something has been
> > changed/removed, because of obsolescence of devices, in IO management,
> > but I couldn't.
> > 
> > Does anybody have any explanation/suggestion?
> 
> Please post contents of /proc/iomem .
> I'm guessing that it will show something like:
> 000e0000-000effff : Extension ROM
> (but for address 000d0000).
> So then the question becomes how to assign/allocate it for your
> driver.
> 
> You might have to dummy up a call to release_resource() first,
> then use request_resource() to acquire it.
> Or just use the addresses anyway.... even though check_region() says
> -EBUSY.  BTW, check_region() is deprecated in 2.6.x, so if your
> driver could just use request_region() and release_region(), that
> would be better.
> 
> > Thank you
> > 
> > Best Regards,
> > 
> > Antonino Sergi
> > 
> > PS:As I'm not subscribed, please CC me your answers.
> 

Re: isa memory address

[Maciej W. Rozycki]

On Tue, 9 Nov 2004, Antonino Sergi wrote:

> I looked for iomem with a kernel-2.4.2:
> 
> /proc/iomem reports
> 00000000-0009fbff : System RAM
> 0009fc00-0009ffff : reserved
> 000a0000-000bffff : Video RAM area
> 000c0000-000c7fff : Video ROM
> 000f0000-000fffff : System ROM
> 00100000-1fffbfff : System RAM
> 
> Nothing in the region 000d0000-000d0006 (used by my driver),
> so why is it BUSY?

 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.

> > > I'm working with an old data acquisition system that uses an 8-bit card
> > > in an ISA slot (address 0xd0000), by a simple driver I ported from
> > > kernel 1.1.x to 2.2.24.
> > > 
> > > It works fine, but I'd like to have features by newer kernels (2.4 or
> > > even 2.6), like new filesystems support.
> > > 
> > > On kernels >=2.4.0 check_region returns -EBUSY for that address,
> > > but it is not actually used; I tried to understand if something has been
> > > changed/removed, because of obsolescence of devices, in IO management,
> > > but I couldn't.

 Try check_mem_region() instead, ...

> > You might have to dummy up a call to release_resource() first,
> > then use request_resource() to acquire it.

 ... or better yet request_mem_region()/release_resource(), as the former 
is deprecated and will be removed.

  Maciej

Re: isa memory address

[Antonino Sergi]

On Tue, 2004-11-09 at 17:56, Maciej W. Rozycki wrote:
> On Tue, 9 Nov 2004, Antonino Sergi wrote:
> 
> > I looked for iomem with a kernel-2.4.2:
> > 
> > /proc/iomem reports
> > 00000000-0009fbff : System RAM
> > 0009fc00-0009ffff : reserved
> > 000a0000-000bffff : Video RAM area
> > 000c0000-000c7fff : Video ROM
> > 000f0000-000fffff : System ROM
> > 00100000-1fffbfff : System RAM
> > 
> > Nothing in the region 000d0000-000d0006 (used by my driver),
> > so why is it BUSY?
> 
>  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.

> > > > I'm working with an old data acquisition system that uses an 8-bit card
> > > > in an ISA slot (address 0xd0000), by a simple driver I ported from
> > > > kernel 1.1.x to 2.2.24.
> > > > 
> > > > It works fine, but I'd like to have features by newer kernels (2.4 or
> > > > even 2.6), like new filesystems support.
> > > > 
> > > > On kernels >=2.4.0 check_region returns -EBUSY for that address,
> > > > but it is not actually used; I tried to understand if something has been
> > > > changed/removed, because of obsolescence of devices, in IO management,
> > > > but I couldn't.
> 
>  Try check_mem_region() instead, ...
> 
> > > You might have to dummy up a call to release_resource() first,
> > > then use request_resource() to acquire it.
> 
>  ... 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.

I couldn't understand what is the actual difference between
ioport_resource and iomem_resource to track the problem.

Antonino


>   Maciej

Re: isa memory address

[Maciej W. Rozycki]

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

Re: isa memory address

[Antonino Sergi]

> > 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.
> 

You were right, there was a wrong symlink that made me compile for 2.4
with headers from 2.2; maybe some different macro substitution lead to
an actual different code. Now it works fine, with 2.6 too.

Thank you

Antonino Sergi

>   Maciej


Antonino Sergi <Antonino.Sergi@Roma1.INFN.it>

Radiodating Laboratory
Physics Department
University of Rome "La Sapienza"
P.le Aldo Moro 2
00185 Rome Italy
Tel +390649914206
Fax +390649914208

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

Re: isa memory address

[Antonino Sergi]

Hi,

I made another test: I tried the same compiled kernel version on both
machines (P233MMX and PIII500) without any other module loaded and I
still have different behavior, as described in my previous e-mail, so it
should be some hardware difference, but I don't know.

Thank you for any suggestion

Antonino Sergi  


On Tue, 2004-11-16 at 17:22, Antonino Sergi wrote:
> 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