On inserting a pcmcia gsm card: Oct 19 19:02:11 - kernel: pcmcia_socket pcmcia_socket0: pccard: PCMCIA card inserted into slot 0 Oct 19 19:02:11 - kernel: pcmcia_socket pcmcia_socket0: cs: memory probe 0xe46d0000-0xe7ffffff: Oct 19 19:02:11 - kernel: excluding 0xe4df4000-0xe5185fff 0xe5fce000-0xe635ffff 0xe6e16000-0xe71a7fff 0xe7ff0000-0xe8381fff Oct 19 19:02:11 - kernel: pcmcia 0.0: pcmcia: registering new device pcmcia0.0 (IRQ: 16) Oct 19 19:02:41 - systemd-udevd[265]: worker [3698] /devices/pci0000:00/0000:00:1e.0/0000:15:00.0/0.0 timeout; kill it Oct 19 19:02:41 - systemd-udevd[265]: seq 2009 '/devices/pci0000:00/0000:00:1e.0/0000:15:00.0/0.0' killed Oct 19 19:02:41 - kernel: pcmcia_socket pcmcia_socket0: Using replacement CIS Oct 19 19:02:41 - kernel: serial_cs 0.0: trying to set up [0x0192:0x0710] (pfc: 0, multi: 1, quirk: (null)) Oct 19 19:02:41 - systemd-udevd[265]: worker [3698] terminated by signal 9 (Killed) Oct 19 19:02:41 - dbus-daemon[303]: modem-manager[475]: <info> (ttyS0) opening serial port... Oct 19 19:02:41 - modem-manager[475]: <info> (ttyS0) opening serial port... Oct 19 19:02:41 - dbus-daemon[303]: modem-manager[475]: <info> (ttyS0) opening serial port... Oct 19 19:02:41 - modem-manager[475]: <info> (ttyS0) opening serial port... # pccardctl ident Socket 0: product info: "Sierra Wireless", "AC850", "3G Network Adapter", "R1" manfid: 0x0192, 0x0710 function: 2 (serial) - which presumably loads /lib/firmware/cis/SW_8xx_SER.cis systemd-194-1.fc18.i686 pcmciautils-018-3.fc18.i686 kernel-PAE-3.6.2-2.fc18.i686
Same problem is seen in f17. See also Bug 868378 - "Failed to add/activate connection" for PCMCIA / pccard
Assumption: pcmciautils is installed?
(In reply to comment #2) > Assumption: pcmciautils is installed? Yes, pcmciautils-018-3.fc18.i686 as reported in comment 0. After the timeout it mostly works - it can connect and get the right DNS settings, but actual traffic doesn't work; Bug 871809 - broadband connection with pcmcia AirCard 850 doesn't work
Could this be related to http://www.spinics.net/lists/netdev/msg185742.html ? It seems like f16 with kernel 3.6.6 doesn't have this problem. (But it still doesn't work, so I can't tell for sure.) It could thus be related to the udev version.
This really looks like a problem with the driver in question. udev tries to interface with it, and the worker hangs, which is then killed after a timeout. SInce newer kernel versions appear to fix this (as #4 suggests) I guess we can just close this.
(In reply to comment #5) > SInce newer kernel versions appear to fix this (as #4 suggests) I guess we > can just close this. You mean because 3.6.6 in f16 works? I disagree. I attribute that to f16 using a udev that is compatible with the kernel. Or has the "incompatibility introduced by systemd" been fully fixed in later kernel versions? If so: Which version is relevant to test?
There is no "incompability", just a timeout and a message logged. The message is not the reason for any failure, it might only cause a delay of 30 seconds until the device is fully set up. Nothing is "killed" here besides the dead-locking udev process which is not relevant for the function of the device. Later kernels load firmware on their own, and later systemd versions work around it again, the same way as the standalone udev did. We need a newer kernel or backport the udev fix to F16, but it will unlikely cause any change in behaviour besides that the message is not logged and the device setup might finish a 20-30 seconds earlier.
The issue should not exist in recent releases, the kernel firmware loading should work around the blocking driver requests.