Re: [systemd-devel] systemd-udevd Oops
On 01/13/2014 10:20 PM, Cristian RodrÌguez wrote: El 13/01/14 18:59, Greg KH escribiÛ: On Mon, Jan 13, 2014 at 04:20:05PM -0500, Mark Hounschell wrote: I'll have to admit, I don't have a very good understanding of systemd/udev. I am using systemd/udev version 208-15.1 on an openSuSE-13.1 dist and a 3.4.74 kernel. 3.4? That's an incompatible thing right there with openSUSE 13.1, sorry. While off-topic for sure, yes, that is bound to cause issues. we might want to force a minimal kernel version in the systemd spec file. most likely the base release number of the kernel used in the particular product, in this case 3.11 or later but not previous. This may not be enforced at runtime though as multiple kernels including older ones can be installed. Well, the systemd/udev README file from 208-15.1: REQUIREMENTS: Linux kernel = 3.0 CONFIG_DEVTMPFS CONFIG_CGROUPS (it's OK to disable all controllers) CONFIG_INOTIFY_USER CONFIG_SIGNALFD CONFIG_TIMERFD CONFIG_EPOLL CONFIG_NET CONFIG_SYSFS . . Mark ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-udevd Oops
El 14/01/14 09:52, Mark Hounschell escribió: Well, the systemd/udev README file from 208-15.1: yeah, one thing is what systemd upstream requires and a completely different one is what openSUSE can/will support or allow. It is not just systemd really, other applications or libraries may require particular features only found in a kernel of either the same major version or something close.. let's say.. openSUSE 13.1 has 3.11 , some app might require 3.10 or 3.9, things might start to very subtle fail, particularly if error handling is shaky or we might sneak-in distribution or OS specific patches that just assume you run the product's minimal kernel version or later. I cannot give you assurance that the above is not already a de-facto condition. distributions are currently quite complex and there is enough low hanging fruit to open a dessert factory. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-udevd Oops
Am 14.01.2014 15:03, schrieb Cristian Rodríguez: El 14/01/14 09:52, Mark Hounschell escribió: Well, the systemd/udev README file from 208-15.1: yeah, one thing is what systemd upstream requires and a completely different one is what openSUSE can/will support or allow. It is not just systemd really, other applications or libraries may require particular features only found in a kernel of either the same major version or something close.. let's say.. openSUSE 13.1 has 3.11 , some app might require 3.10 or 3.9, things might start to very subtle fail, particularly if error handling is shaky or we might sneak-in distribution or OS specific patches that just assume you run the product's minimal kernel version or later which application should this be? please state a real-world example - the Kernel usually does not break userland Fedora 18 as example was released with Kernel 3.6 and is now at EOL on 3.11.10 Fedora 17 as example was released with Kernel 3.3 and at EOL had 3.9.10 you can even use the 3.11.10-100.fc18.x86_64 on F17 in case you have a dying platform on a machine and want at least kernel fixes signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-udevd Oops
On Tue, Jan 14, 2014 at 07:52:31AM -0500, Mark Hounschell wrote: On 01/13/2014 10:20 PM, Cristian RodrÌguez wrote: El 13/01/14 18:59, Greg KH escribiÛ: On Mon, Jan 13, 2014 at 04:20:05PM -0500, Mark Hounschell wrote: I'll have to admit, I don't have a very good understanding of systemd/udev. I am using systemd/udev version 208-15.1 on an openSuSE-13.1 dist and a 3.4.74 kernel. 3.4? That's an incompatible thing right there with openSUSE 13.1, sorry. While off-topic for sure, yes, that is bound to cause issues. we might want to force a minimal kernel version in the systemd spec file. most likely the base release number of the kernel used in the particular product, in this case 3.11 or later but not previous. This may not be enforced at runtime though as multiple kernels including older ones can be installed. Well, the systemd/udev README file from 208-15.1: REQUIREMENTS: Linux kernel = 3.0 CONFIG_DEVTMPFS CONFIG_CGROUPS (it's OK to disable all controllers) CONFIG_INOTIFY_USER CONFIG_SIGNALFD CONFIG_TIMERFD CONFIG_EPOLL CONFIG_NET CONFIG_SYSFS . . But that has nothing to do with what openSUSE 13.1 requires. It does not support putting an older kernel version on it at all. If you do so, you get to keep all of the pieces that you end up with :) You can almost always put a newer kernel version on a distro, and openSUSE does support this if you run the Tumbleweed variation, which handles any needed package updates and other system changes that a newer kernel sometimes requires. Fedora does much the same thing with their releases, providing newer kernel releases over the lifetime of a release cycle. good luck, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-udevd Oops
El 14/01/14 11:10, Reindl Harald escribió: which application should this be? please state a real-world example - the Kernel usually does not break userland Fedora 18 as example was released with Kernel 3.6 and is now at EOL on 3.11.10 Fedora 17 as example was released with Kernel 3.3 and at EOL had 3.9.10 you can even use the 3.11.10-100.fc18.x86_64 on F17 in case you have a dying platform on a machine and want at least kernel fixes yeah, *later* kernels are ok, but in the OP case he is downgrading to a version older than the kernel headers used to build the complete distribution. I do not have a particular real world example handy. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-udevd Oops
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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-udevd Oops
On Mon, Jan 13, 2014 at 04:20:05PM -0500, Mark Hounschell wrote: Basically, I don't think this problem is the driver. I think the problem is systemd/udev related so I'm posting this here hoping the get some input on what the problem is. If the kernel crashes, then it's kernel's fault (usually). Here systemd-udevd triggers the crash in the kernel, by causing it to dereference NULL, when it interacts with it. But it still is a bug in the kernel if a user-space application can crash it in this way. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-udevd Oops
On Mon, Jan 13, 2014 at 04:20:05PM -0500, Mark Hounschell wrote: I'll have to admit, I don't have a very good understanding of systemd/udev. I am using systemd/udev version 208-15.1 on an openSuSE-13.1 dist and a 3.4.74 kernel. 3.4? That's an incompatible thing right there with openSUSE 13.1, sorry. The back trace indicates an out of kernel driver I have to maintain. Yet this also indicates Pid: 361, comm: systemd-udevd caused the Oops. I don't understand this. I'd blame your driver, as no one can really help you with a tainted kernel like that, there's not much we can do here, sorry. What is keeping your driver from being merged into the main kernel tree? In any case, this particular driver and systemd/udev (195.x.x) using the very same kernel work just fine. Also if I only have a single pci card installed this particular driver and systemd/udev version 208-15.1 work just fine. It's just when additional pci cards are added I get this failure. This particular driver takes a few seconds from the time init_module is called to when it creates all its device entries. The more pci cards the longer that is. The cards themselves are basically loaded and booted before the device entries(192 each) are created. This error seems to be occurring during that load and boot process though. 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. And userspace shouldn't be able to crash the kernel, so you can't really blame udev :) best of luck, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-udevd Oops
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, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-udevd Oops
El 13/01/14 18:59, Greg KH escribió: On Mon, Jan 13, 2014 at 04:20:05PM -0500, Mark Hounschell wrote: I'll have to admit, I don't have a very good understanding of systemd/udev. I am using systemd/udev version 208-15.1 on an openSuSE-13.1 dist and a 3.4.74 kernel. 3.4? That's an incompatible thing right there with openSUSE 13.1, sorry. While off-topic for sure, yes, that is bound to cause issues. we might want to force a minimal kernel version in the systemd spec file. most likely the base release number of the kernel used in the particular product, in this case 3.11 or later but not previous. This may not be enforced at runtime though as multiple kernels including older ones can be installed. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
