lkml.org 
[lkml]   [1999]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectPROBLEM: module is not loaded when my hardware is off


[1.] One line summary of the problem:
module is not loaded when my hardware is off

[2.] Full description of the problem:
I wrote a device driver ( for a little bit specific device -
CAMAC interface adapter (ISA) ). Driver is written as a loadable
module. The adapter is in the ISA slot and is connected with
the CAMAC crate controller by a cable. CAMAC crate has separate
power source.
When I load the driver by insmod command having the CAMAC crate
powered on, it is loaded without a problem.
If the power on the crate is off, I cannot load the driver.
check_region(..) returns some non-zero value, so I have to exit.
( I call check_region() before doing anything with my board. )
In this case insmod (?) tells (after my diagnostic message about
inabilty to access i/o ports needed, see [7.5])
/lib/modules/2.2.5-15/misc/apex.o: init_module: Device or resource busy.
Moreover, after this happened I can switch the power on the crate
on and off without any effect ( i.e I cannot load the module anymore )
until the system is rebooted.
Some interesting detail: after successfull loading (if the power
was on) I can look at the file /proc/ioports and see
...
100h-106h: apex
120h-13eh: apex
...
among other entries in this file. apex is my module name and
ports specified are those which the adapter use, so everthing is OK.
In the case when insmod fails to load the module ( power was off)
any attempt to read the content of the /proc/ioports after that results
in a OOPS message (see [5.] below). I tried to read the file
by cat and with F3 in Midnight Commander with the same result.
This behaviour does not depend on weither the power on the crate
was on or off during the system booting. What matters is that
in order to load my driver I have got to turn my crate on
before first attempt to do this.
I looked at the kernel/resources.c, but did not find any i/o port
related code in it. All functions there perform some manipulations
with iolist and iotable. I mean check_region(), request_region(),
release_region() and find_gap(). I have been using Unix/Linux only
for half a year, so I can only guess that something
in the kernel permanently does something with i/o ports and
with those iolist and iotable, otherwise the behaviour of insmod
and/or check_region() and/or get_ioport_list (?????)
would not depend on weither the power on my crate is on or off.

[3.] Keywords (i.e., modules, networking, kernel):
modules, driver, i/o ports, check_region(), /proc/ioports
iolist, iotable in /usr/src/linux/kernel/resources.c

[4.] Kernel version (from /proc/version):
Linux version 2.2.5-15 (root@porky.devel.redhat.com)
(gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release))
#1 Mon Apr 19 22:21:09 EDT 1999

[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
I found the stuff below in /var/log/messages. It is the same
I see on the screen. Also I did nm vmlinux | sort | less
and EIP from dump om the screen point also somewhere in vsprintf.
Hope this is what you need.

Jun 11 11:34:22 l127 kernel: Unable to handle kernel paging request at virtual address c184f872
Jun 11 11:34:22 l127 kernel: current->tss.cr3 = 008d6000, %cr3 = 008d6000
Jun 11 11:34:22 l127 kernel: *pde = 00e0e063
Jun 11 11:34:22 l127 kernel: *pte = 00000000
Jun 11 11:34:22 l127 kernel: Oops: 0000
Jun 11 11:34:22 l127 kernel: CPU: 0
Jun 11 11:34:22 l127 kernel: EIP: 0010:[vsprintf+445/876]
Jun 11 11:34:22 l127 kernel: EFLAGS: 00010297
Jun 11 11:34:22 l127 kernel: eax: c184f872 ebx: ffffffff ecx: c184f872 edx: fffffffe
Jun 11 11:34:22 l127 kernel: esi: c0e1c0b0 edi: c0931f3c ebp: 00000000 esp: c0931eec
Jun 11 11:34:22 l127 kernel: ds: 0018 es: 0018 ss: 0018
Jun 11 11:34:22 l127 kernel: Process cat (pid: 823, process nr: 55, stackpage=c0931000)
Jun 11 11:34:22 l127 kernel: Stack: c0e1c000 00000400 ffffffff 00000000 c0440018 00000018 c0442620 c01d084e
Jun 11 11:34:22 l127 kernel: 73000000 0000000a c01cb8f0 c0e1c0a4 c01d0850 c0931f3c c0117ae8 c0e1c0a4
Jun 11 11:34:22 l127 kernel: c01d0841 00000100 00000106 c184f872 00000000 c0931f98 c0201780 c0143f46
Jun 11 11:34:22 l127 kernel: Call Trace: [tvecs+2542/32288] [sprintf+20/4696] [tvecs+2544/32288] [get_ioport_list+56/100] [tvecs+2529/32288] [8390:NS8390_module+270802/793285] [get_root_array+282/372]
Jun 11 11:34:22 l127 kernel: [array_read+230/484] [sys_read+174/196] [system_call+52/56]
Jun 11 11:34:22 l127 kernel: Code: 80 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 89 44 24 10 f7 c5


[6.] A small shell script or example program which triggers the
problem (if possible)
I am afraid it is not possible: you do not have that adapter :-))).

[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)

[7.2.] Processor information (from /proc/cpuinfo):
processor : 0
vendor_id : CyrixInstead
cpu family : 6
model : 2
model name : 6x86MX 2.5x Core/Bus Clock
stepping : 6
cpu MHz : 166.455471
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu de tsc msr cx8 pge cmov mmx
bogomips : 165.89

[7.3.] Module information (from /proc/modules):
My module is not here since I have to get that OOPS.
sound 57208 0 (autoclean) (unused)
soundlow 300 0 (autoclean) [sound]
soundcore 2372 3 (autoclean) [sound]
nfsd 150936 8 (autoclean)
lockd 30856 1 (autoclean) [nfsd]
sunrpc 52356 1 (autoclean) [nfsd lockd]
ne 6512 1 (autoclean)
8390 5920 0 (autoclean) [ne]

[7.4.] SCSI information (from /proc/scsi/scsi)
Attached devices: none

[7.5.] Other information that might be relevant to the problem

Here is my init_module() function from the driver:

int init_module(void)
{
int crate;

if (register_chrdev(major, APEX_NAME, &camac_fio))
{
printk(" unable to get major %i for %s device\n",major,APEX_NAME);
return -EIO;
}

if (check_region(CC_CSR_PORT, APEX_CC_PORTS)) {
/* this is where I have got the trouble when the crate is off */
printk(" unable to access i/o ports %xh-%s\n",CC_CSR_PORT,"106h");
unregister_chrdev(major, APEX_NAME);
return -EIO;
}

/* CC_CSR_PORT = 100h, APEX_CC_PORTS = 7 */
/* CC_MOD_BASE_PORT = 120h, APEX_FM_PORTS = 1Fh */

if (check_region(CC_MOD_BASE_PORT, APEX_FM_PORTS)) {
printk(" unable to access i/o ports %xh-%s\n",CC_MOD_BASE_PORT,"138h");
unregister_chrdev(major, APEX_NAME);
return -EIO;
}

request_region(CC_CSR_PORT, APEX_CC_PORTS, APEX_NAME);
request_region(CC_MOD_BASE_PORT, APEX_FM_PORTS, APEX_NAME);

printk("Detecting board and crates...\n");

printk(" APEX interface board");
if ( !cam_detect_apexboard() ) {
printk(" not detected\n");
unregister_chrdev(major, APEX_NAME);
return -EIO;
}

printk(" detected\n");

for (crate = 0; crate <= APEX_MAX_CRATE; crate++) {

CrateOpen[crate] = 0;
printk(" crate %i :", crate);

if ( !cam_detect_crate(crate) ) {
CratePresent[crate] = 0;
printk(" not");
}
printk(" detected\n");
}

return 0;
}



Sincerely,
Eugene Zhiganov.

Department for Physical Electronics
Petrozavodsk State University
Russia, Karelia, 185640 Petrozavodsk
Lenin str. 33, PetrSU

e-mail: zed@dfe3300.karelia.ru




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

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.040 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site