Messages in this thread | | | Date | Fri, 11 Jun 1999 13:08:33 +0400 (????) | From | Eugene Zhiganov <> | Subject | PROBLEM: 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/
| |