Description of problem: Recently performed a fresh RH9 install on ASUS A7S333 motherboard based system. The system has an Athlon XP 1600+ processor and 1.25G of RAM. The RAM was tested with memtest86 and passed. The system was fine until I performed an upgrade to the latest kernel 2.4.20-13.9. With the new kernel boot process will not finish and the system will panic. Version-Release number of selected component (if applicable): 2.4.20-13.9 How reproducible: 100% reproducible. Steps to Reproduce: 1. Install RH9 from CDs 2. Upgrade kernel using up2date 3. Reboot Actual results: Kernel will panic during the boot process. It's hard to tell exactly when because the information scrolls off the screen. Code: 0f 0b e7 03 3f 92 25 c0 e9 69 fd ff ff 89 f6 8d bc 27 00 00 <0>Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing Expected results: Working system. Additional info: Reverting back to the original RH9 kernel as provided on CD works fine.
Additional info that might be helpful: # lspci 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 745 Host (rev 01) 00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SiS 530 Virtual PCI-to-PCI bridge (AGP) 00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS85C503/5513 (LPC Bridge)00:02.2 USB Controller: Silicon Integrated Systems [SiS] SiS7001 USB Controller (rev 07) 00:02.3 USB Controller: Silicon Integrated Systems [SiS] SiS7001 USB Controller (rev 07) 00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) 00:05.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10) 00:0b.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 22) 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 Pro Ultra TF
I hooked up a serial console and obtained more information about this problem. . . Starting crond: [ OK ] Starting cups: ------------[ cut here ]------------ kernel BUG at sched.c:999! invalid operand: 0000 parport_pc lp parport nfsd lockd sunrpc iptable_filter ip_tables autofs tulip nCPU: 0 EIP: 0060:[<c01187fa>] Not tainted EFLAGS: 00010202 EIP is at schedule [kernel] 0x2aa (2.4.20-13.9) eax: 00000001 ebx: c3ad8c74 ecx: c0349d64 edx: c0349d5c esi: c0348000 edi: c3ad8c7c ebp: c0349d54 esp: c0349d44 ds: 0068 es: 0068 ss: 0068 Process swapper (pid: 0, stackpage=c0349000) Stack: 3201a8c0 c3ad8c74 c0348000 c3ad8c7c c0349d5c c01081ff 00000001 c0348000 c3ad8c7c c3ad8c7c c3ad8c1c c3ad8c74 c3ad8c00 ffffffea c0108354 c3ad8c74 c3ad8c00 ffffffed f88f69bf c3ad8c1c f88f6b5b 00000000 f7320000 f73d7000 Call Trace: [<c01081ff>] __down [kernel] 0x5f (0xc0349d58)) [<c0108354>] __down_failed [kernel] 0x8 (0xc0349d7c)) [<f88f69bf>] .text.lock.usbserial [usbserial] 0x2d (0xc0349d8c)) [<f88f6b5b>] .rodata.str1.1 [usbserial] 0xed (0xc0349d94)) [<c0182aed>] tty_default_put_char [kernel] 0x2d (0xc0349db0)) [<c0183718>] echo_char [kernel] 0x48 (0xc0349dc8)) [<c0184f79>] n_tty_receive_char [kernel] 0x159 (0xc0349ddc)) [<c0183e37>] n_tty_receive_buf [kernel] 0x237 (0xc0349e04)) [<c01cdc98>] __ide_dma_begin [kernel] 0x38 (0xc0349e44)) [<c01cde46>] __ide_dma_count [kernel] 0x16 (0xc0349e54)) [<c01827ae>] flush_to_ldisc [kernel] 0xbe (0xc0349eac)) [<f88fb9a5>] visor_read_bulk_callback [visor] 0x125 (0xc0349ec8)) [<f88fd30a>] .rodata.str1.1 [visor] 0xb9 (0xc0349ed0)) [<f88433b2>] sohci_return_urb [usb-ohci] 0x52 (0xc0349ef4)) [<f88456ae>] dl_done_list [usb-ohci] 0xce (0xc0349f08)) [<f88463bb>] hc_interrupt [usb-ohci] 0x12b (0xc0349f2c)) [<c010a8c5>] handle_IRQ_event [kernel] 0x45 (0xc0349f48)) [<c010aa55>] do_IRQ [kernel] 0x75 (0xc0349f68)) [<c01155b0>] apm_cpu_idle [kernel] 0x0 (0xc0349f78)) [<c010d498>] call_do_IRQ [kernel] 0x5 (0xc0349f88)) [<c01155b0>] apm_cpu_idle [kernel] 0x0 (0xc0349f8c)) [<c0106ec3>] default_idle [kernel] 0x23 (0xc0349fb4)) [<c011564f>] apm_cpu_idle [kernel] 0x9f (0xc0349fc0)) [<c01155b0>] apm_cpu_idle [kernel] 0x0 (0xc0349fc4)) [<c0106f35>] cpu_idle [kernel] 0x35 (0xc0349fd4)) [<c0105000>] stext [kernel] 0x0 (0xc0349fe0)) Code: 0f 0b e7 03 3f 92 25 c0 e9 69 fd ff ff 89 f6 8d bc 27 00 00 <0>Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing I then tried turning off cups and the system successfully booted. However within a few minutes my ethernet port ceased to function: May 20 23:57:54 penguin kernel: NETDEV WATCHDOG: eth0: transmit timed out May 20 23:57:55 penguin autofs: automount -USR2 succeeded May 20 23:57:56 penguin apmd[2796]: Exiting May 20 23:57:57 penguin apmd: apmd shutdown succeeded May 20 23:57:58 penguin ntpd[2934]: ntpd exiting on signal 15 May 20 23:57:58 penguin ntpd: ntpd shutdown succeeded May 20 23:58:01 penguin umount: Cannot MOUNTPROG RPC: RPC: Port mapper failure - RPC: Unable to receive May 20 23:58:01 penguin netfs: Unmounting NFS filesystems: succeeded May 20 23:58:02 penguin kernel: NETDEV WATCHDOG: eth0: transmit timed out
Greg, thanks for great capture. Forgot to ask, does the 2.4.20-18.9 oops too? The upstream keeps fixing the USB serial subsystem, perhaps they changed it.
Actually, I'm almost sure 2.4.20-18 fails. De-needinfo-ing. This seems to be a combination of several circumstances. 1. The usbserial sets tty->low_latency by default. Thus, tty_flip_buffer_push falls through to flush_to_ldisc. 2. Likely, he PDA continuously sends crap, so when app opens a port (kudzu?), a cooked port gets connected to PDA; then the line discipline echoes. 3. The usbserial assumes that its ->serial_write method is only called from actual writes from a process, and so downs a semaphore. In this case, line discipline echo writes and not a process. Removing any single condition will fix the problem.
*** This bug has been marked as a duplicate of 90442 ***
In response to the question about if it works on 2.4.20-18.9, yes it works just fine with that kernel. Someone also referred me to a 2.4.20-13.9.1 kernel from a Red Hat FTP site (don't remember original URL) that I'm currently running successfully.