* udev blacklist ineffective @ 2013-01-28 16:36 Michael_E_Brown 2013-01-28 18:52 ` Darren Hart 0 siblings, 1 reply; 4+ messages in thread From: Michael_E_Brown @ 2013-01-28 16:36 UTC (permalink / raw) To: openembedded-core I have two embedded systems that share some devices over an i2c bus. Only one system may load the device driver at a time, and loading the device driver is already well-controlled by the HA subsystem. Our new yocto build with udev enabled is auto-loading these device drivers with catastrophic results. We must absolutely prohibit such automatic behaviour for our list of devices. I have tried: $ cat etc/modprobe.d/blacklist.conf blacklist seepmtd ... cut ... And this does *NOT* work. I have tried renaming blacklist.conf to modprobe.conf as well as creating modprobe.conf with these blacklist entries. This is a huge blocking issue and I have been unable to figure out a workaround for it. I would appreciate any suggestions. -- Michael ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: udev blacklist ineffective 2013-01-28 16:36 udev blacklist ineffective Michael_E_Brown @ 2013-01-28 18:52 ` Darren Hart 2013-01-28 19:09 ` Michael_E_Brown 0 siblings, 1 reply; 4+ messages in thread From: Darren Hart @ 2013-01-28 18:52 UTC (permalink / raw) To: Michael_E_Brown; +Cc: openembedded-core On 01/28/2013 08:36 AM, Michael_E_Brown@Dell.com wrote: > I have two embedded systems that share some devices over an i2c bus. Only one system may load the device driver at a time, and loading the device driver is already well-controlled by the HA subsystem. > > Our new yocto build with udev enabled is auto-loading these device drivers with catastrophic results. We must absolutely prohibit such automatic behaviour for our list of devices. I have tried: > > $ cat etc/modprobe.d/blacklist.conf > blacklist seepmtd > ... cut ... > > And this does *NOT* work. I have tried renaming blacklist.conf to > modprobe.conf as well as creating modprobe.conf with these blacklist > entries. > > This is a huge blocking issue and I have been unable to figure out a > workaround for it. I would appreciate any suggestions. OK, so... this needs to be addressed. However, can you just not build/install the drivers for the system that shouldn't be accessing them? Or do you require a more general image? You will need to provide details about the version of oe-core you are using, kmod or modutils, and any relevant DISTRO configurations you have made, which bit of software do you expect to be honoring the blacklist, etc. -- Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: udev blacklist ineffective 2013-01-28 18:52 ` Darren Hart @ 2013-01-28 19:09 ` Michael_E_Brown 2013-02-20 7:34 ` Khem Raj 0 siblings, 1 reply; 4+ messages in thread From: Michael_E_Brown @ 2013-01-28 19:09 UTC (permalink / raw) To: dvhart; +Cc: openembedded-core > _______________________________________ > From: Darren Hart [dvhart@linux.intel.com] > Sent: Monday, January 28, 2013 12:52 PM > To: Brown, Michael E > Cc: openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] udev blacklist ineffective > > On 01/28/2013 08:36 AM, Michael_E_Brown@Dell.com wrote: > > I have two embedded systems that share some devices over an i2c bus. Only one system may load the device driver at a time, and loading the device driver is already well-controlled by the HA subsystem. > > > > Our new yocto build with udev enabled is auto-loading these device drivers with catastrophic results. We must absolutely prohibit such automatic behaviour for our list of devices. I have tried: > > > > $ cat etc/modprobe.d/blacklist.conf > > blacklist seepmtd > > ... cut ... > > > > And this does *NOT* work. I have tried renaming blacklist.conf to > > modprobe.conf as well as creating modprobe.conf with these blacklist > > entries. > > > > This is a huge blocking issue and I have been unable to figure out a > > workaround for it. I would appreciate any suggestions. > > > OK, so... this needs to be addressed. > > However, can you just not build/install the drivers for the system that > shouldn't be accessing them? Or do you require a more general image? Both systems have to access these devices. They just cannot load the drivers simultaneously. The driver load is under control of the HA process that ensures that only one system at a time accesses the devices, and takes care of fencing, etc. We have a custom FPGA that can switch access to the devices between two systems, loading drivers from both systems twiddles bits that ought not to be twiddled and catastrophically crashes one or both systems. > You will need to provide details about the version of oe-core you are > using, kmod or modutils, and any relevant DISTRO configurations you have > made, which bit of software do you expect to be honoring the blacklist, etc. Yocto release 1.3, danny branch + meta-oe/meta-systemd for system startup udev_v195-r10 libkmod2_9-r0.0 Distro is poky + systemd What is happening is that, on boot, the udev Coldplug startup step is loading drivers that must not be loaded based on i2c discovery. -- Michael ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: udev blacklist ineffective 2013-01-28 19:09 ` Michael_E_Brown @ 2013-02-20 7:34 ` Khem Raj 0 siblings, 0 replies; 4+ messages in thread From: Khem Raj @ 2013-02-20 7:34 UTC (permalink / raw) To: Michael_E_Brown; +Cc: dvhart, openembedded-core On (28/01/13 13:09), Michael_E_Brown@Dell.com wrote: > > _______________________________________ > > From: Darren Hart [dvhart@linux.intel.com] > > Sent: Monday, January 28, 2013 12:52 PM > > To: Brown, Michael E > > Cc: openembedded-core@lists.openembedded.org > > Subject: Re: [OE-core] udev blacklist ineffective > > > > On 01/28/2013 08:36 AM, Michael_E_Brown@Dell.com wrote: > > > I have two embedded systems that share some devices over an i2c bus. Only one system may load the device driver at a time, and loading the device driver is already well-controlled by the HA subsystem. > > > > > > Our new yocto build with udev enabled is auto-loading these device drivers with catastrophic results. We must absolutely prohibit such automatic behaviour for our list of devices. I have tried: > > > > > > $ cat etc/modprobe.d/blacklist.conf > > > blacklist seepmtd > > > ... cut ... > > > > > > And this does *NOT* work. I have tried renaming blacklist.conf to > > > modprobe.conf as well as creating modprobe.conf with these blacklist > > > entries. > > > > > > This is a huge blocking issue and I have been unable to figure out a > > > workaround for it. I would appreciate any suggestions. > > > > > > OK, so... this needs to be addressed. > > > > However, can you just not build/install the drivers for the system that > > shouldn't be accessing them? Or do you require a more general image? > > Both systems have to access these devices. They just cannot load the drivers simultaneously. The driver load is under control of the HA process that ensures that only one system at a time accesses the devices, and takes care of fencing, etc. > > We have a custom FPGA that can switch access to the devices between two systems, loading drivers from both systems twiddles bits that ought not to be twiddled and catastrophically crashes one or both systems. > > > You will need to provide details about the version of oe-core you are > > using, kmod or modutils, and any relevant DISTRO configurations you have > > made, which bit of software do you expect to be honoring the blacklist, etc. > > Yocto release 1.3, danny branch + meta-oe/meta-systemd for system startup > udev_v195-r10 > libkmod2_9-r0.0 > > Distro is poky + systemd > > What is happening is that, on boot, the udev Coldplug startup step is loading drivers that must not be loaded based on i2c discovery. yes udev is exactly for that. You are up for writing some udev rules here may be something etc/udev/rules.d/10-local.rules and add OPTIONS=="ignore_device" if condition (that you will define based on device you want to ignore) is met. > -- > Michael > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- -Khem ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-02-20 7:51 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-01-28 16:36 udev blacklist ineffective Michael_E_Brown 2013-01-28 18:52 ` Darren Hart 2013-01-28 19:09 ` Michael_E_Brown 2013-02-20 7:34 ` Khem Raj
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.