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
