Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Sep 2001 23:52:18 +0200
From:      "Joerg Lehners" <Lehners@Informatik.Uni-Oldenburg.DE>
To:        FreeBSD-gnats-submit@freebsd.org
Subject:   i386/30503: stray pccard card insertion events after resume
Message-ID:  <E15gYyY-0000Fb-00@flunder.Informatik.Uni-Oldenburg.DE>

next in thread | raw e-mail | index | archive | help

>Number:         30503
>Category:       i386
>Synopsis:       stray pccard card insertion events after resume
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Sep 11 00:40:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Joerg Lehners
>Release:        FreeBSD 4.4-RC i386
>Organization:
private
>Environment:
System: FreeBSD flunder 4.4-RC FreeBSD 4.4-RC #8: Mon Sep 10 22:57:06 MEST 2001
root@flunder:/usr/src/sys/compile/FLUNDER i386

Toshiba Tecra 750 and Toshiba Libretto 100CT

Problem: I get stray pccard insertion events after a suspend/resume
cycle. This is only when using IRQ driven pccard management.

>Description:
>How-To-Repeat:

Power down a pccard slot with pccardc, remove the card while the
notebook runs, suspend the notebook, insert a card while the
notebook is suspend, resume the notebook.
I'll get a 'pccard: card inserted, slot X' messages. The pccardd
activates the driver. All is fine until I use the associated device.
I get another 'pccard: card inserted, slot X' messages after opening
and using the device (for instance a sio device with kermit). The second
sequence of power_off_slot()/slt->ctrl->power() in pccard.c:inserted()
wegdes the card. Results possible are a hung machine or even a panic
(depending on the hardware/driver/device).

When I set PCIC comptibility in the BIOS with polling mode, I do not
have this problem.

Kernel Messages (for reference):

Using BIOS-setting PCIC compatible:
Sep 10 22:08:25 flunder /kernel: pcic0: <Intel i82365SL-A/B> at port 0x3e0-0x3e1 on isa0
Sep 10 22:08:25 flunder /kernel: pcic0: Polling mode
Sep 10 22:08:25 flunder /kernel: pccard0: <PC Card bus (classic)> on pcic0
Sep 10 22:08:25 flunder /kernel: pccard1: <PC Card bus (classic)> on pcic0

Using BIOS-setting Automatic:
Sep 10 22:03:29 flunder /kernel: pci_cfgintr_virgin: using routable interrupt 3
Sep 10 22:03:29 flunder /kernel: pci_cfgintr: 0:2 INTA routed to irq 3
Sep 10 22:03:29 flunder /kernel: pcic0: <Toshiba ToPIC97 PCI-CardBus Bridge> irq 3 at device 2.0 on pci0
Sep 10 22:03:29 flunder /kernel: pcic0: PCI Memory allocated: 0x44000000
Sep 10 22:03:29 flunder /kernel: pccard0: <PC Card bus (classic)> on pcic0
Sep 10 22:03:29 flunder /kernel: pci_cfgintr_search: linked (1) to configured irq 3 at 0:2:0
Sep 10 22:03:29 flunder /kernel: pci_cfgintr: 0:2 INTB routed to irq 3
Sep 10 22:03:29 flunder /kernel: pcic1: <Toshiba ToPIC97 PCI-CardBus Bridge> irq 3 at device 2.1 on pci0
Sep 10 22:03:29 flunder /kernel: pcic1: PCI Memory allocated: 0x44001000
Sep 10 22:03:29 flunder /kernel: pccard1: <PC Card bus (classic)> on pcic1

Using BIOS-setting Cardbus/16 Bit:
Sep  8 23:13:35 flunder /kernel: pcic0: <Toshiba ToPIC95B PCI-CardBus Bridge> irq 11 at device 2.0 on pci0
Sep  8 23:13:35 flunder /kernel: pcic0: PCI Memory allocated: 0x44000000
Sep  8 23:13:35 flunder /kernel: pccard0: <PC Card bus (classic)> on pcic0
Sep  8 23:13:35 flunder /kernel: pcic1: <Toshiba ToPIC95B PCI-CardBus Bridge> irq 11 at device 2.1 on pci0
Sep  8 23:13:35 flunder /kernel: pcic1: PCI Memory allocated: 0x44001000
Sep  8 23:13:35 flunder /kernel: pccard1: <PC Card bus (classic)> on pcic1



I think there is a small error in the suspend/resume handling of
the pccard system when using IRQ management: After resuming the machine
pcic_resume() may call pcic_do_stat_delta() which in turn may active
a slot (the first card inserted event after the resume). The card
is ready to use now. But it seems some pccard controller still have
a management event in the hardware pending. An unlash of the corresponding
IRQ seems to fire the second card inserted event (more or less the real
one).

My suggested fix: either clear all pending managment events after resuming
or do even better debouncing of insertion events.

As a first measure I inserted some code at the top of pccard.c:inserted():

        if (slt->state == filled) {
                printf("pccard: card already inserted, slot %d\n",
                                slt->slotnum);
                return;
        }

But I'm not 100% confident that this is the right way to handle this problem.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E15gYyY-0000Fb-00>