Bug 30503
| Summary: | stray pccard card insertion events after resume | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Joerg Lehners <Lehners> |
| Component: | i386 | Assignee: | Warner Losh <imp> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
Responsible Changed From-To: freebsd-bugs->imp Over to maintainer State Changed From-To: open->closed I've fixed very similar problems with ToPIC cardbus. So if there's still a problem, lemme know. |
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.