* [CFT] Hopefully fix PCMCIA boot deadlocks
@ 2003-04-14 15:50 Russell King
2003-04-14 22:55 ` Felipe Alfaro Solana
0 siblings, 1 reply; 3+ messages in thread
From: Russell King @ 2003-04-14 15:50 UTC (permalink / raw)
To: Linux Kernel List; +Cc: seanlkml, felipe_alfaro, Dominik Brodowski
Ok,
Here's my latest patch against 2.5.67 which introduces a proper state
machine into the PCMCIA layer for handling the sockets. Unfortunately,
I fear that this isn't the answer for the following reasons:
* We create our own workqueue (which spawns N threads, one thread per CPU.)
We need to use a separate thread from the keventd since we call
PCI probe and remove methods from this thread, which are free to
use flush_scheduled_work() - which would be another deadlock waiting
to happen. I think we need to go to a per-socket thread instead.
* The state machine isn't as readable as it should be. To be quite frank,
I think it was a mistake to code it as a state machine - IMO its
completely unreadable.
* We allow cardbus cards to be suspended and reset as though they are
normal PCMCIA cards. Unfortunately, PCI drivers have no knowledge
that these operations occur. This also applies to older kernels, so
this isn't really a problem that's created by this patch.
This is even more true now that we have the capability to plug in a
complete (possibly complex) PCI bus structure.
* There seems to be a whole bunch of setup stuff going on in
pcmcia_register_client(). This is run each time a card device driver
is inserted by cardmgr. Although this has buggy for the case where
all drivers are built in, this patch makes it more buggy; if a card
is inserted at the time ds.ko is loaded, we kick off the asynchronous
state machine to process the card and carry on regardless.
However, we can not wait here - if we do wait for the state machine
to complete, we will hit the same deadlock in the device model which
we're hitting today.
It appears that it would mainly affect multi-function PCMCIA cards.
Unfortunately, I don't have any to test.
That said, it seems to work for me.
The patch can be found at
http://patches.arm.linux.org.uk/pcmcia/pcmcia-1.diff
Now, thing is, I can't test this patch on its own; I can test it on ARM
boxen with yenta cardbus bridges, or statically mapped PCMCIA-only
sockets, but the former requires several other patches to the PCMCIA
resource subsystem to be functional.
Hence I need other peoples feedback on this patch before I push it
Linus-wards.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [CFT] Hopefully fix PCMCIA boot deadlocks
2003-04-14 15:50 [CFT] Hopefully fix PCMCIA boot deadlocks Russell King
@ 2003-04-14 22:55 ` Felipe Alfaro Solana
2003-04-15 2:03 ` Valdis.Kletnieks
0 siblings, 1 reply; 3+ messages in thread
From: Felipe Alfaro Solana @ 2003-04-14 22:55 UTC (permalink / raw)
To: Russell King; +Cc: Linux Kernel List, seanlkml, Dominik Brodowski
On Mon, 2003-04-14 at 17:50, Russell King wrote:
> Ok,
>
> Here's my latest patch against 2.5.67 which introduces a proper state
> machine into the PCMCIA layer for handling the sockets. Unfortunately,
> I fear that this isn't the answer for the following reasons:
Well, maybe it's not the answer, but it's working for me with
2.5.67-mm3. Besides being too verbose, I have tried booting with the
card plugged, booting with the card unplugged and then plugging it, and
plugging/unplugging it several time to check that hotplug is working.
Haven't found any problems, although I'm testing right now on my main
system (my everyday use laptop).
Nice work, Russell :-)
--
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
Linux Registered User #287198
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [CFT] Hopefully fix PCMCIA boot deadlocks
2003-04-14 22:55 ` Felipe Alfaro Solana
@ 2003-04-15 2:03 ` Valdis.Kletnieks
0 siblings, 0 replies; 3+ messages in thread
From: Valdis.Kletnieks @ 2003-04-15 2:03 UTC (permalink / raw)
To: Felipe Alfaro Solana
Cc: Russell King, Linux Kernel List, seanlkml, Dominik Brodowski
[-- Attachment #1: Type: text/plain, Size: 2798 bytes --]
On Tue, 15 Apr 2003 00:55:03 +0200, Felipe Alfaro Solana said:
> On Mon, 2003-04-14 at 17:50, Russell King wrote:
> > Ok,
> >
> > Here's my latest patch against 2.5.67 which introduces a proper state
> > machine into the PCMCIA layer for handling the sockets. Unfortunately,
> > I fear that this isn't the answer for the following reasons:
>
> Well, maybe it's not the answer, but it's working for me with
> 2.5.67-mm3. Besides being too verbose, I have tried booting with the
> card plugged, booting with the card unplugged and then plugging it, and
> plugging/unplugging it several time to check that hotplug is working.
Confirmed under vanilla 2.5.67 on a Dell C840. It's chatty, and I'll
not comment on the neatness of implementation. But... ;)
It now boots with the offending card, without it, insert it, eject it, I
haven't been able to confuse it (though I admit I havent tried a very fast
insert/eject cycle so the eject arrives before the insert finishes). And yes,
the card in question was a multifunction (abbreviated lspci -vv output):
03:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03)
Subsystem: Xircom Cardbus Ethernet 10/100
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (5000ns min, 10000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 1000 [size=128]
Region 1: Memory at 10800000 (32-bit, non-prefetchable) [size=2K]
Region 2: Memory at 10800800 (32-bit, non-prefetchable) [size=2K]
Expansion ROM at 10400000 [disabled] [size=16K]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
03:00.1 Serial controller: Xircom Cardbus Ethernet + 56k Modem (rev 03) (prog-if 02 [16550])
Subsystem: Xircom CBEM56G-100 Ethernet + 56k Modem
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 1080 [size=8]
Region 1: Memory at 10801000 (32-bit, non-prefetchable) [size=2K]
Region 2: Memory at 10801800 (32-bit, non-prefetchable) [size=2K]
Expansion ROM at 10404000 [disabled] [size=16K]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
Thanks Russell!
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-04-15 1:52 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-14 15:50 [CFT] Hopefully fix PCMCIA boot deadlocks Russell King
2003-04-14 22:55 ` Felipe Alfaro Solana
2003-04-15 2:03 ` Valdis.Kletnieks
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).