ok, get hte package strace. send that to the debian list .
[EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org On Sun, 18 Jul 1999 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] < /dev/null > >
