search for: uevents

Good day! I'm struggling to connect by Advice Partner PRPC650 UPS to Nut. The UPS uses USB for communication and the current problem is that serial device (/dev/ttyUSB*) is not detected. OS is Debian Lenny (same behavior on Ubuntu Hardy). Did anyone have any success with this UPS? Here is what my dmesg and udevmonitor say (on Debian): dmesg: usb 2-3: new low speed USB device using ohci_hcd

> -----Original Message----- > From: Ewan Mellor [mailto:ewan@xensource.com] > Sent: Tuesday, December 06, 2005 5:25 AM > To: Dave Thompson (davetho) > Cc: Xen Mailing List > Subject: Re: [Xen-devel] Hotplug scripts not working... > xen/ia64 domU stoppedworking > > On Mon, Dec 05, 2005 at 03:03:54PM -0500, Dave Thompson > (davetho) wrote: > > > >

On Fri, 11 Oct 2019 16:15:52 +0800 Jason Wang <jasowang at redhat.com> wrote: > This patch adds bus uevent support for mdev bus in order to allow > cooperation with userspace. > > Signed-off-by: Jason Wang <jasowang at redhat.com> > --- > drivers/vfio/mdev/mdev_driver.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git

Provide private field for event handlers exclusive use. Convert nouveau_fence_wait_uevent() and nouveau_fence_wait_uevent_handler(); drop struct nouveau_fence_uevent. Signed-off-by: Peter Hurley <peter at hurleysoftware.com> --- drivers/gpu/drm/nouveau/core/include/core/event.h | 1 + drivers/gpu/drm/nouveau/nouveau_fence.c | 20 +++++++------------- 2 files changed, 8

I''m running SLES10 SP1 and have been using file:/ for my file-backed domUs. The domUs sit on a shared OCFS2 SAN-backed filesystem and are run on my three or four XEN servers. I''m having issues with the loopback devices not being released when the domUs shutdown or migrate, so I decided to switch over to tap:aio for my file-backed domUs. This isn''t working, either.

> -----Original Message----- > From: Ewan Mellor [mailto:ewan@xensource.com] > Sent: Tuesday, December 06, 2005 9:16 AM > To: Dave Thompson (davetho) > Cc: Xen Mailing List > Subject: Re: [Xen-devel] Hotplug scripts not working... > xen/ia64 domU stoppedworking > > On Tue, Dec 06, 2005 at 09:51:24AM -0500, Dave Thompson > (davetho) wrote: > > >

Hello list. My server: Gentoo 2.6.21-xen dom0 xen-tools 3.2.1 lvm 2.02.28-r2 udev-115-r1 Symptoms: normally I run 4 domUs. About once a week I have a need to restart a domU. Sometimes it works just fine, but other times it does not and I''ll get a message back saying "Error: Device 0 (vif) could not be connected. Hotplug scripts not working". The domU config file has not

...> drm_kms_helper_hotplug_event(dev); > > I'm curious if you think there might be an advantage to doing this per- > connector even with multiple connectors? Seems like we could do that if we > stored changed connectors as a bitmask. I believe firing off multiple per-connector uevents would be worse than a single per-device uevent because user-space would see intermediate states instead of an atomic change. Let's say I have 3 connectors connected, and different settings set in my compositor when 1, 2 or 3 screens are connected. Let's say an unplug disconnects 2 monitors...

Userspace listens to the KOBJ_ADD uevent generated in add_disk. At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. This race condition can be easily reproduced by hot plugging a number of virtio-blk disks. Also in systemd, there used to be a related workaround in udev rules called

Userspace listens to the KOBJ_ADD uevent generated in add_disk. At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. This race condition can be easily reproduced by hot plugging a number of virtio-blk disks. Also in systemd, there used to be a related workaround in udev rules called

On Tue, 06/28 04:45, Christoph Hellwig wrote: > On Tue, Jun 28, 2016 at 10:39:15AM +0800, Fam Zheng wrote: > > Userspace listens to the KOBJ_ADD uevent generated in add_disk. At that > > point we haven't created the serial attribute file, therefore depending > > on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get > > created. > > >

On Tue, 06/28 04:45, Christoph Hellwig wrote: > On Tue, Jun 28, 2016 at 10:39:15AM +0800, Fam Zheng wrote: > > Userspace listens to the KOBJ_ADD uevent generated in add_disk. At that > > point we haven't created the serial attribute file, therefore depending > > on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get > > created. > > >

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add information so rproc-serial can be easily recogniced from user space. Add the following information to uevent: DRIVER=virtio_console|virtio_rproc_serial INTERFACE=grand-parent/parent/name Signed-off-by: Sjur Br?ndeland <sjur.brandeland at stericsson.com> --- Hi, I need some way to identify the major/minor number for the

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add information so rproc-serial can be easily recogniced from user space. Add the following information to uevent: DRIVER=virtio_console|virtio_rproc_serial INTERFACE=grand-parent/parent/name Signed-off-by: Sjur Br?ndeland <sjur.brandeland at stericsson.com> --- Hi, I need some way to identify the major/minor number for the

On Thu, Jun 30, 2016 at 09:59:41AM +0800, Fam Zheng wrote: > Documentation/kobject.txt: > > Use the KOBJ_ADD action for when the kobject is first added to the kernel. > > This should be done only after any attributes or children of the kobject > > have been initialized properly, as userspace will instantly start to look > > for them when this call happens. > >

On Wed, 06/29 23:24, Christoph Hellwig wrote: > On Thu, Jun 30, 2016 at 09:59:41AM +0800, Fam Zheng wrote: > > Documentation/kobject.txt: > > > Use the KOBJ_ADD action for when the kobject is first added to the kernel. > > > This should be done only after any attributes or children of the kobject > > > have been initialized properly, as userspace will instantly

This patch adds bus uevent support for mdev bus in order to allow cooperation with userspace. Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vfio/mdev/mdev_driver.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/vfio/mdev/mdev_driver.c b/drivers/vfio/mdev/mdev_driver.c index b7c40ce86ee3..319d886ffaf7 100644 --- a/drivers/vfio/mdev/mdev_driver.c +++

On Wed, 06/29 23:24, Christoph Hellwig wrote: > On Thu, Jun 30, 2016 at 09:59:41AM +0800, Fam Zheng wrote: > > Documentation/kobject.txt: > > > Use the KOBJ_ADD action for when the kobject is first added to the kernel. > > > This should be done only after any attributes or children of the kobject > > > have been initialized properly, as userspace will instantly

I get the error while starting hvm doms. Any workarounds... suggestions.. Thanks /Jd Some thiings that might be useful are cut-pasted below. ifconfig -a udevmonitor output (as suggested in prev posts) qemu-dm log xend.log xend-debug does not seem to have anything interesting. ifconfig -a =========== eth0 Link encap:Ethernet HWaddr 00:0F:EA:53:5C:79 inet addr:192.168.12.103

On Wed, Jun 29, 2016 at 6:59 PM, Fam Zheng <famz at redhat.com> wrote: > It is documented that KOBJ_ADD should be generated after the object's > attributes and children are ready. We can achieve this with the new > disk_gen_uevents interface. > > Signed-off-by: Fam Zheng <famz at redhat.com> > --- > arch/powerpc/sysdev/axonram.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/sysdev/axonram.c b/arch/powerpc/sysdev/axonram.c > index 4efd69b..27e7175 100644...