[systemd-devel] systemd-udevd Oops

[Greg KH]

On Tue, Jan 14, 2014 at 10:17:36AM -0500, Mark Hounschell wrote:
> 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.

Lidza only was able to work on stuff for 3 months through the OPW intern
program, and I don't have another intern this cycle, so there's no one
else to work on this at the moment.

But, I'll be glad to look at the driver, can you send me the link to the
one(s) that are not yet merged off-list?

> 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'd blame the driver here.  From what I recall with the 2 drivers we did
merge they were abusing sysfs and procfs in lots of different ways that
needed to be fixed up.  Odds are you are hitting one of those problems
at the moment, and it's a timing issue at boot time vs. loading the
module on a "quiet" system.

Either way, this isn't a systemd/udev issue, nothing from userspace
should be able to crash the kernel, it's a driver issue that I'll work
with you on off-list.

> 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.

You are asking the systemd developer community for support for a system
configuration that the original creator of it will not even support,
which kind of is a bit worse than trying to ask openSUSE for support :)

Let's continue this off-list, it's not relevant for systemd-devel.

thanks,

greg k-h