I should may add, that on the card which failed, only the signature key was generated and written to the card. The authentication and encryption keys could not be generated..

Please let us know what kind of key and how large, like RSA-4096 or ECC Brainpool.
For RSA 2048 or larger, yes, it takes too long.

All my keys are RSA 4096. It worked fine with OpenPGP smart cards and with two Yubikey 5. On all devices a set of RSA 4096 keys were geneated on the device itself. Only one card failed. But even the card which failed, generated at least the signature key in RSA 4096.

Are you using pcscd (is that process running) or the internal driver.? Please try the latter if you are not already using it.

I use the internal driver.

Please note that key generation is takes time unusually longer from a viewpoint of card reader.
It is possible for a card reader to give up the execution of key generation command as timeout.

I observed that OpenPGPcard V3.3 has BWI=100, and it periodically sends time extension to host (period is 42-43 seconds), during key generation. As long as this time extension is kept sending, a card reader should wait. But it is likely that some readers have a limit for total time for an execution.

I do not wonder, that you face difficulties to reproduce it. It happened only with one card from my six cards; so five cards working fine. Therefore, I thought that this particular card was may dead at arrival and I contacted the vendor. They refused to replace it with the comment, it would be a well known issue. Do you know a test where I can demonstrate that the card is dead at arrival?

This weekend I´ll generate a test key pair on my notebook and then I´ll transfer it to the troublesome card. If the transfer fails too, it is may an indicator that the card is dead.

Concerning your comment above with BWI=100 and time extension: Five cards worked, it took a while, but no trouble at all. One card needed much more longer as the others and then the error message occured. I used always the same card reader for every card (it is an integrated card reader). So I belive that the root cause will may point to the card.

I applied the following with gpg-connect-agent --hex:

scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40

so often until the reply was "D[000] 69 83"

Then termination and re-opening with:

scd apdu 00 e6 00 00
scd apdu 00 44 00 00
bye

I removed the card and tested again. The single signature key which was written to the card, before a card error ist still existing, it was not deleted. I applied it once to another card where I entered the admin PIN three times wrong. It was possible to reset the card. With the card reset it was possible to to initialize the admin PIN counter, but all existing keys on the card where deleted. In this case not, therefore, I believe it is something wrong with the card itself.

FYI, we have "factory-reset" command in gpg --card-edit; It is not enough for a card to have admin locked state, but it requires normal user locked state, too.

The card was replaced by the vendor. It seems to be a problem with the specific card. All other cards so far worked well. The issue can be closed.