Re: PCMCIA and interrupts?
ok, get hte package strace.
send that to the debian list .
tyler@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
On Sun, 18 Jul 1999 mcclosk@ling.ucsc.edu wrote:
>
> 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
>
>
> --
> Unsubscribe? mail -s unsubscribe debian-user-request@lists.debian.org < /dev/null
>
>
Reply to: