Bug 78135 - Flurry of Oops when ejecting Xircom pcmcia card
Summary: Flurry of Oops when ejecting Xircom pcmcia card
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 8.0
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-11-19 11:44 UTC by diego.santacruz
Modified: 2008-08-01 16:22 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-09-30 15:40:13 UTC
Embargoed:

Attachments (Terms of Use)

Description diego.santacruz 2002-11-19 11:44:30 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830
(compatible; Netscape/7.0;)

Description of problem:
When ejecting a Xircom CreditCard Ethernet 10/100+ Modem 56 PCMCIA card
(CEM56-100) I get a flurry of OOPS messages and the machine becomes unusable.

Version-Release number of selected component (if applicable):
kernel-2.4.18-18.8.0

How reproducible:
Always

Steps to Reproduce:
1. Insert a Xircom CEM56-100 card
2. Wait for initialization
3. Eject the card (without previously doing cardctl eject)
	

Actual Results:  Nonending series of OOPS messages on console and machine
becomes unusable. Unfortunately no OOPS get saved on disk.

Expected Results:  No OOPS and machines continues to work without problem.

Additional info:

This bug was introduced with the errata kernel 2.4.18-18.8.0 to fix the bug #76233.
Comment 1 Martin C. Messer 2002-11-26 13:36:25 UTC 
I don't get an lockup oops on eject, I get this on the console:

vfree(): sleeping in interrupt!!
c0317ee0 c022cca0 df12fc00 e1064160 e10641a8 e106b000 df12fc18 c011fd67
       df12fc00 c0317f0c c011fec5 c0373434 c0373434 00000000 c03414a0 00000000
       00000046 c011c5db c011c4e4 00000000 00000001 c03414c0 fffffffe c011c30b
Call Trace: [<e1064160>] xirc2ps_release [xirc2ps_cs] 0x0 (0xc0317eec))
[<e10641a8>] xirc2ps_release [xirc2ps_cs] 0x48 (0xc0317ef0))
[<c011fd67>] timer_bh [kernel] 0x257 (0xc0317efc))
[<c011fec5>] do_timer [kernel] 0x45 (0xc0317f08))
[<c011c5db>] bh_action [kernel] 0x1b (0xc0317f24))
[<c011c4e4>] tasklet_hi_action [kernel] 0x44 (0xc0317f28))
[<c011c30b>] do_softirq [kernel] 0x4b (0xc0317f3c))
[<c0109f2c>] do_IRQ [kernel] 0xbc (0xc0317f54))
[<c010c308>] call_do_IRQ [kernel] 0x5 (0xc0317f68))
[<c0110018>] pcibios_setup [kernel] 0xf8 (0xc0317f88))
[<c0112bbb>] apm_bios_call_simple [kernel] 0x5b (0xc0317f94))
[<c0112ca4>] apm_do_idle [kernel] 0x14 (0xc0317fbc))
[<c0112dd5>] apm_cpu_idle [kernel] 0xc5 (0xc0317fd4))
[<c0106de0>] default_idle [kernel] 0x0 (0xc0317fdc))
[<c0105000>] stext [kernel] 0x0 (0xc0317fe0))
[<c0106e64>] cpu_idle [kernel] 0x24 (0xc0317fe8))

The system acts normally afterwards with no reboot.
Comment 2 diego.santacruz 2002-11-26 13:43:33 UTC 
I got this problem with previous kernels (see bug #74735), but with the latest
update (2.4.18-18.8.0) it gets very much worse: machine becomes unusable.
Comment 3 Martin C. Messer 2002-11-26 13:47:34 UTC 
Hmm, I see. I'm running the latest 7.3 kernel, 2.4.18-18.7.x.
Comment 4 Bugzilla owner 2004-09-30 15:40:13 UTC 
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/
Note You need to log in before you can comment on or make changes to this bug.