Messages in this thread | | | Subject | Re: isa memory address | From | Antonino Sergi <> | Date | Wed, 17 Nov 2004 16:00:33 +0100 |
| |
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
- 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/
| |