Bug 91272 - Kernel version 2.4.20-13.9 panic on ASUS A7S333 motherboard
Summary: Kernel version 2.4.20-13.9 panic on ASUS A7S333 motherboard
Status: CLOSED DUPLICATE of bug 90442
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 9
Hardware: athlon
OS: Linux
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-05-20 17:53 UTC by Gregory Gulik
Modified: 2005-10-31 22:00 UTC (History)
0 users

Clone Of:
Last Closed: 2003-06-06 02:49:29 UTC

Attachments (Terms of Use)

Description Gregory Gulik 2003-05-20 17:53:20 UTC
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):


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.

Comment 1 Gregory Gulik 2003-05-20 17:55:16 UTC
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
(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

Comment 2 Gregory Gulik 2003-05-21 05:20:00 UTC
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

Comment 3 Pete Zaitcev 2003-06-05 20:22:55 UTC
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.

Comment 4 Pete Zaitcev 2003-06-06 00:41:35 UTC
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.

Comment 5 Pete Zaitcev 2003-06-06 01:04:03 UTC

*** This bug has been marked as a duplicate of 90442 ***

Comment 6 Gregory Gulik 2003-06-06 01:49:05 UTC
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

Note You need to log in before you can comment on or make changes to this bug.