PCMCIA and interrupts?
Hello.
I recently installed Slink on a 5-year old laptop that had remained
unused for some time. This was never a top-of-the-line model, and the
hardware at this point might not be the most trustworthy.
Nevertheless, the installation went smoothly. I compiled a custom
kernel (2.0.36), and that went smoothly as well. Everything
seems fine, judging both by the machine's behaviour and by what gets
written to the log files.
Problems arose only when I decided to install the Pcmcia Card Manager
Packages, so that I could use my fax-modem card to connect to the
net. (I had done the install from floppies, and then by way of a PLIP
connection to my desktop machine, using a CD mounted there as the
archive). Then I entered a little private hell.
I installed the pcmcia-cs package and the pcmcia-modules package from
Slink. But the pcmcia-modules package is designed to work with the
stock 2.0.36 kernel, and since I had compiled a custom-kernel, it
didn't work. I read the FAQ in /usr/doc/, got the pcmcia-source
package, and recompiled the modules from source. Everything seemed to
go smoothly---I could install the modules and start the cardmanager
with no complaints about unresolved symbols. Insertion and removal of
cards was detected (double beep), and the card was successfully
recognized as a serial modem.
But when I try to actually use the modules---disaster. Trying to make
the modem dial (PPP or Minicom), or trying to use setserial to
configure /dev/ttyS1, produces a segmentation fault and a
kernel-oops. Here's a typical entry from syslog:
------------------------------------------------------------
Jul 16 19:45:11 lapdog cardmgr[107]: executing: './serial start ttyS1'
Jul 16 19:45:15 lapdog /usr/sbin/cron[134]: (CRON) STARTUP (fork ok)
Jul 16 19:47:16 lapdog kernel: Unable to handle kernel NULL pointer dereference at virtual address c0000000
Jul 16 19:47:16 lapdog kernel: current->tss.cr3 = 00101000, %cr3 = 00101000
Jul 16 19:47:16 lapdog kernel: *pde = 00102067
Jul 16 19:47:16 lapdog kernel: *pte = 00000000
Jul 16 19:47:16 lapdog kernel: Oops: 0000
Jul 16 19:47:16 lapdog kernel: CPU: 0
Jul 16 19:47:16 lapdog kernel: EIP: 0010:[<00000000>]
Jul 16 19:47:16 lapdog kernel: EFLAGS: 00010206
Jul 16 19:47:16 lapdog kernel: eax: 00000000 ebx: 00000004 ecx: 00000064 edx: 00000009
Jul 16 19:47:16 lapdog kernel: esi: 001bd6e0 edi: 00000001 ebp: 0019d5b0 esp: 0019d598
Jul 16 19:47:16 lapdog kernel: ds: 0018 es: 0018 fs: 002b gs: 0018 ss: 0018
Jul 16 19:47:16 lapdog kernel: Process swapper (pid: 0, process nr: 0, stackpage=0019b678)
Jul 16 19:47:16 lapdog kernel: Stack: 00113688 00000001 ffffffff 00000001 00000001 0019d5cc 001bd5d0 00119afb
Jul 16 19:47:16 lapdog kernel: 0019d5cc 0019d654 00000000 00009000 0010ab0b 00005c85 00000013 0019de2c
Jul 16 19:47:16 lapdog kerneld: error: exit: Identifier removed
Jul 16 19:47:16 lapdog kernel: 0019d654 00000000 00009000 00000000 00a90018 00190018 0000002b ffff0018
Jul 16 19:47:16 lapdog kernel: Call Trace: [timer_bh+248/864] [do_bottom_half+59/112] [handle_bottom_half+11/24] [sys_idle+108/128] [system_call+85/124] [init+0/624] [save_cur+152/272]
Jul 16 19:47:16 lapdog kernel: [start_kernel+429/448] [it_real_fn+0/80]
Jul 16 19:47:16 lapdog kernel: Code: <1>Unable to handle kernel NULL pointer dereference at virtual address c0000000
Jul 16 19:47:16 lapdog kernel: current->tss.cr3 = 00101000, %cr3 = 00101000
Jul 16 19:47:16 lapdog kernel: *pde = 00102067
Jul 16 19:47:16 lapdog kernel: *pte = 00000000
Jul 16 19:47:16 lapdog kernel: Oops: 0000
Jul 16 19:47:16 lapdog kernel: CPU: 0
Jul 16 19:47:16 lapdog kernel: EIP: 0010:[die_if_kernel+652/736]
Jul 16 19:47:16 lapdog kernel: EFLAGS: 00010202
Jul 16 19:47:16 lapdog kernel: eax: 00000010 ebx: 00000100 ecx: 00000000 edx: 00367c0c
Jul 16 19:47:16 lapdog kernel: esi: 00000000 edi: 0019e000 ebp: 0019d55c esp: 0019d500
Jul 16 19:47:16 lapdog kernel: ds: 0018 es: 0018 fs: 0010 gs: 0018 ss: 0018
Jul 16 19:47:16 lapdog kernel: Process swapper (pid: 0, process nr: 0, stackpage=0019b678)
Jul 16 19:47:16 lapdog kernel: Stack: 0018002b 00000000 00000000 0019d55c 0019de2c 01400000 01800000 01000000
Jul 16 19:47:16 lapdog kernel: 00190018 0011260e 0018e798 0019d55c 00190000 00112310 001bd6e0 00000001
Jul 16 19:47:16 lapdog kernel: 0019d5b0 00000002 0019ddc8 0000001c 0010acdc 0019d55c 00190000 00000004
Jul 16 19:47:16 lapdog kernel: Call Trace: [save_cur+171/272] [<01400000>] [<01800000>] [serial:register_serial_R3425f38c+-56452/324] [do_page_fault+766/800] [do_page_fault+0/800] [error_code+64/72]
Jul 16 19:47:16 lapdog kernel: [timer_bh+248/864] [do_bottom_half+59/112] [handle_bottom_half+11/24] [sys_idle+108/128] [system_call+85/124] [init+0/624] [save_cur+152/272] [start_kernel+429/448]
Jul 16 19:47:16 lapdog kernel: [it_real_fn+0/80]
Jul 16 19:47:16 lapdog kernel: Code: 64 8a 04 0e 0f a1 88 c2 81 e2 ff 00 00 00 89 54 24 10 52 68
Jul 16 19:47:16 lapdog kernel: Aiee, killing interrupt handler
Jul 16 19:47:16 lapdog kernel: kfree of non-kmalloced memory: 0019d6c0, next= 00000000, order=0
Jul 16 19:47:16 lapdog kernel: kfree of non-kmalloced memory: 0019d6b0, next= 00000000, order=0
Jul 16 19:47:16 lapdog kernel: kfree of non-kmalloced memory: 0019dbc4, next= 00000000, order=0
Jul 16 19:47:16 lapdog kernel: idle task may not sleep
Jul 16 19:47:16 lapdog last message repeated 4 times
----------------------------------------------------------------------
What is common to all these events is:
kernel: Aiee, killing interrupt handler
which made me think that the source of the problem was an IRQ-conflict
(a common source of problems according to the PCMCIA-HOWTO). I tried
over a couple of days and in different ways to assign different IRQ's
to /dev/ttyS1 but with no effect so far (by which I mean that even if
setserial reveals that a different IRQ has been assigned, the problem
persists). If I don't intervene, ttyS1 is assigned IRQ 3; I can't tell
for sure if that IRQ is assigned to any other device.
I've always found the business of understanding and managing IRQ
assignments completely obscure. I know about /proc/interrupts, but
that's really not much use as a source of information about *all* the
IRQ's assigned in a given system.
If anyone has any advice or pointers to offer, I'd be very grateful
indeed.
Jim
Reply to: