This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Rawhide has a newer pcsc-lite and ccid versions where the issue might have been fixed. Pierre, if you are still running rawhide, can you see if you get the same noise in the log file with rawhide's pcsc-lite-1.5.5-1.fc13 and ccid-1.3.11-1.fc13?

What reader do you have?

I'm afraid I stuck with Fedora 12 for now.

My reader is a Omnikey CardMan 4321 connected via USB (albeit in the ExpressCard slot).

I tried CardMan 4321 on my laptop and I can confirm that I'm also getting lots of "Card Not Powered" lines in /var/log/messages even with latest pcsc-lite [1] and ccid [2] snapshots.

Ludovic, could you take a look at this?

[1] http://ludovic.rousseau.free.fr/softwares/pcsc-lite/pcsc-lite-1.5.6-svn-4563.tar.bz2
[2] http://ludovic.rousseau.free.fr/softwares/pcsc-lite/ccid-1.3.11-svn-4563.tar.bz2

One if your application is doing a SCardConnect() even if no card is present. You will have to find this application and report the bug.

I guess the application is doing some kind a polling in a very stupid way.

I don't suppose there's an easy way to trace this?

No easy way.

You can try to remove the libpsclite package. This should also try to remove other packages depending on it (I only know Debian dependencies, no idea about Red Hat). This should give you a list of suspects.

I think I've found a way to find active users of pcsc. The file /var/run/pcscd.pub seems to be mapped for communication between pcscd and the clients. So "lsof /var/run/pcscd.pub" finds possible suspects.

And for my machine, the only application that finds (except for pcscd itself) is escd, Red Hat's smart card management daemon.

Hmm... it seems OpenSC also does things incorrectly. Doing a simple "pkcs11-tool -L" results in a bunch of "SCardConnect() Card Not Powered" in the log.

Some problem with this reader not properly reporting that the slot is empty?

(In reply to comment #8)
> I think I've found a way to find active users of pcsc. The file
> /var/run/pcscd.pub seems to be mapped for communication between pcscd and the
> clients. So "lsof /var/run/pcscd.pub" finds possible suspects.

Very good idea.

> And for my machine, the only application that finds (except for pcscd itself)
> is escd, Red Hat's smart card management daemon.  

Try to stop/kill escd and watch your log file.

(In reply to comment #9)
> Hmm... it seems OpenSC also does things incorrectly. Doing a simple
> "pkcs11-tool -L" results in a bunch of "SCardConnect() Card Not Powered" in the
> log.
> 
> Some problem with this reader not properly reporting that the slot is empty?  

You can try pcsc_scan from pcsc-tools [1].

You can also send a pcscd log generated as described in [2]. Generate the log using LIBCCID_ifdLogLevel=0x000f instead of 0x0007
Maybe your reader is bogus.

[1] http://ludovic.rousseau.free.fr/softwares/pcsc-tools/index.html
[2] http://pcsclite.alioth.debian.org/ccid.html#support

I've found the problem, and it's purely mechanical. Omnikey has simply screwed up when they designed this reader. When the reader is inserted into the ExpressCard slot, it gets slightly compressed. This is enough to trigger the mechanical switch that detects insertions. If I jam something in there and force it apart, then pcscd starts reporting that the slot is empty.

As the hardware is more or less impossible to fix, is it possible to get some workaround in pcsc-lite for broken readers like this?

(In reply to comment #12)
> As the hardware is more or less impossible to fix, is it possible to get some
> workaround in pcsc-lite for broken readers like this?  

This would be a horrible hack with possible strange side effects. I am really not ready for such a patch.

It will be hard to differentiate between no card but a bogus reader and card present but mute.

I'll close the ticket here as CANTFIX as it's really the card reader's bug.