Bug 78135 - Flurry of Oops when ejecting Xircom pcmcia card
Flurry of Oops when ejecting Xircom pcmcia card
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
8.0
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-11-19 06:44 EST by diego.santacruz
Modified: 2008-08-01 12:22 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:40:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description diego.santacruz 2002-11-19 06:44:30 EST
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 08:36:25 EST
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 08:43:33 EST
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 08:47:34 EST
Hmm, I see. I'm running the latest 7.3 kernel, 2.4.18-18.7.x.
Comment 4 Bugzilla owner 2004-09-30 11:40:13 EDT
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.