On 01/13/2014 05:00 PM, Greg KH wrote: > On Mon, Jan 13, 2014 at 01:59:39PM -0800, Greg KH wrote: >> That really sounds like a driver problem, especially given your trace >> shows it is failing somewhere. The udevd PID is probably because udev >> loaded your driver. > > Sorry, not loading it, but rather reading sysfs files that your driver > is creating. > > As your driver isn't a closed source one, have a pointer to the source > anywhere that we can see what you are doing in your sysfs callbacks? > > thanks, >
Hi Greg, you have already been given the sources for this driver (and 3 others) and supposedly it is in progress of being merged by your linux-dev group (Lidza Louina). Of the four Digi drivers we provided to you, this one (digixp) has had no attention as of yet that I am aware of. I've sort of gotten discouraged at the progress of getting these drivers merged, but I'm staying optimistic. Again, as I stated in the original post, I don't understand the specifics of the kernel/udev/systemd relationship. But as for what this driver has done and appears to be doing at the time of the Oops seems pretty straight forward. The driver does a pci_register_driver(driver) then loads the firmware and boots the card. After the load/boot process, which is what it's doing when the Oops occurs, all the device entries (192 per board) are created. And again this load/boot process takes a lot of time. I personally think that time is what is causing the problem. If I prevent the driver from loading during the system boot process and manually load it after the box comes up, all is good. If I have only a single card installed, all is good. If I have 2 cards installed sometimes it works and some times it does not. The more cards installed, the longer it takes for the driver to complete the process. Sometimes with 3 cards installed, instead of the Oops, I get a systemd/udev timeout message and that task is just killed by systemd. I guess I need to better understand this kernel/udev/systemd relationship. Is there a "kernel/udev/systemd for dummies" somewhere?? FYI, I understand what all is being said about this kernel version and SuSE-13.1. I'm not asking SuSE for any sort of support. However I do not think this has anything to do with this problem. Regards Mark _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel