July 2018 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1093378] conflicting udev rules completely break USB Serial bridges
by bugzilla_noreply＠novell.com 06 Jul '18

06 Jul '18

http://bugzilla.suse.com/show_bug.cgi?id=1093378 http://bugzilla.suse.com/show_bug.cgi?id=1093378#c29 --- Comment #29 from Stefan Brüns <stefan.bruens(a)rwth-aachen.de> --- (In reply to Martin Wilck from comment #28) > (In reply to Stefan Brüns from comment #27) > > So I doubt one could catch > > everything with some BLACKLIST_foo option. > > IMO it would work for everything that's proved by udev. User-space tools > that try to access devices directly would need explicit support, which opens > a can of worms. Thats no differentiation: 1. The device is hot-/cold-plugged 2. The kernel loads a driver and generates a udev event 3. udev starts some kind of userspace "helper", e.g. gpsd, brltty 4a. the helper *may* detach the kernel driver and use e.g. libusb, or 4b. the helper opens e.g. the tty port Breaking can happen both ways, no matter if using ttyUSB or libusb. Everything not triggered from udev typically runs in a user session, e.g. argyllcms and sigrok. These are already covered by the "uaccess" udev tag and logind. > > A driver which can not accurately determine in a passive if it should be > > used should not be selected without manual intervention. > > I fear that rule would exclude a lot of drivers. I am very much in favor of manual intervention (which could be a single mouse click or enter key) instead of causing physical damage. *many* devices can be passively probed - many have unique USB ids, and some output sufficiently unique data, see e.g. the brltty Albatrols driver, comment #12 I think its quite stupid if a device costing several thousand euros does not support autoconfiguration, although its absolutely essential. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1094895] error in descriptio
by bugzilla_noreply＠novell.com 06 Jul '18

06 Jul '18

http://bugzilla.suse.com/show_bug.cgi?id=1094895 http://bugzilla.suse.com/show_bug.cgi?id=1094895#c1 Frank Sundermeyer <fs(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Frank Sundermeyer <fs(a)suse.com> --- Thanks for reporting! Fixed with https://github.com/SUSE/doc-sle/commit/427e7a26 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1093378] conflicting udev rules completely break USB Serial bridges
by bugzilla_noreply＠novell.com 06 Jul '18

06 Jul '18

http://bugzilla.suse.com/show_bug.cgi?id=1093378 http://bugzilla.suse.com/show_bug.cgi?id=1093378#c28 --- Comment #28 from Martin Wilck <martin.wilck(a)suse.com> --- (In reply to Stefan Brüns from comment #27) > So I doubt one could catch > everything with some BLACKLIST_foo option. IMO it would work for everything that's proved by udev. User-space tools that try to access devices directly would need explicit support, which opens a can of worms. > There is no reason to create an extra marker, udev supports "tags" which can > be attached to a device. Nice idea. > A driver which can not accurately determine in a passive if it should be > used should not be selected without manual intervention. I fear that rule would exclude a lot of drivers. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1096401] snapper: segfault found in openQA tests
by bugzilla_noreply＠novell.com 06 Jul '18

06 Jul '18

http://bugzilla.suse.com/show_bug.cgi?id=1096401 http://bugzilla.suse.com/show_bug.cgi?id=1096401#c19 --- Comment #19 from Stefan Schubert <schubi(a)suse.com> --- (In reply to Dominique Leuenberger from comment #17) > Seems I was once able to reproduce it on my machine (using pkcon install > emacs), zypper seems not to show the issue. > > One thing I noticed, which is special to PK vs zypper: PK is a long-running > daemon, and libzypp fires off various scripts in a 'unmonitored' way - > leaving zombies in the system: > > 2013 ? Ssl 6:30 /usr/lib/packagekitd > 7869 ? Z 0:00 \_ [InstallAppdata] <defunct> > 10408 ? Z 0:00 \_ [InstallAppdata] <defunct> > 1746 ? Z 0:00 \_ [InstallAppdata] <defunct> > 9126 ? Z 0:00 \_ [InstallAppdata] <defunct> > 19944 ? Z 0:00 \_ [InstallAppdata] <defunct> > 29375 ? Z 0:00 \_ [InstallAppdata] <defunct> > 5410 ? Z 0:00 \_ [InstallAppdata] <defunct> > 15683 ? Z 0:00 \_ [btrfs-defrag-pl] <defunct> > 15685 ? Z 0:00 \_ [snapper.py] <defunct> > 28641 ? Z 0:00 \_ [InstallAppdata] <defunct> > 22170 ? Z 0:00 \_ [btrfs-defrag-pl] <defunct> > 22172 ? Z 0:00 \_ [snapper.py] <defunct> > 25146 ? Z 0:00 \_ [btrfs-defrag-pl] <defunct> > 25148 ? Z 0:00 \_ [snapper.py] <defunct> > 25870 ? Z 0:00 \_ [btrfs-defrag-pl] <defunct> > 25872 ? Z 0:00 \_ [snapper.py] <defunct> > 26888 ? Z 0:00 \_ [btrfs-defrag-pl] <defunct> > 26890 ? Z 0:00 \_ [snapper.py] <defunct> > 28577 ? Z 0:00 \_ [btrfs-defrag-pl] <defunct> > 28579 ? Z 0:00 \_ [snapper.py] <defunct> > 28983 ? Z 0:00 \_ [btrfs-defrag-pl] <defunct> > 28985 ? Z 0:00 \_ [snapper.py] <defunct> Yes, I can confirm this. But even with 10 <defunct> snappers I cannot reproduce the error with the packagekit calls. I have also tested it in conjunction with zypper at the same time. Also with no core dumps. The libzypp lock mechanism has worked well too. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1093378] conflicting udev rules completely break USB Serial bridges
by bugzilla_noreply＠novell.com 06 Jul '18

06 Jul '18

http://bugzilla.suse.com/show_bug.cgi?id=1093378 http://bugzilla.suse.com/show_bug.cgi?id=1093378#c27 --- Comment #27 from Stefan Brüns <stefan.bruens(a)rwth-aachen.de> --- Although the problematic drivers are all USB-serial style bridges, these can be either handled by a kernel driver (hid or tty) or a userspace driver, i.e. libusb or libhidapi-{hidraw,libusb}. So I doubt one could catch everything with some BLACKLIST_foo option. I don't know how brltty interfaces with the input system and if it runs as a separate system user or as part of the user session. argyllcms runs as part of the user session, as does (lib)sigrok. ModemManager, upower and gpsd run as daemons under a system user. For user sessions, there already is a way to attach devices to a session - systemd-logind. See "loginctl seat-status" and "loginctl attach ...." There is no reason to create an extra marker, udev supports "tags" which can be attached to a device. A driver which can not accurately determine in a passive if it should be used should not be selected without manual intervention. Passive means either by a *unique* device identifier like USB VID/PID, or by passively listening on a tty port. "Everytime brltty is loaded, my bench power supply switches from 2 volts to 15 volts ...". -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1096816] when screen energy saving is turned on, picture doesnt come up after using mouse/keyboard
by bugzilla_noreply＠novell.com 06 Jul '18

06 Jul '18

http://bugzilla.suse.com/show_bug.cgi?id=1096816 http://bugzilla.suse.com/show_bug.cgi?id=1096816#c5 Fabian Vogt <fvogt(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fvogt(a)suse.com, | |mspehar(a)gmail.com Flags| |needinfo?(mspehar(a)gmail.com | |) --- Comment #5 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Miroslav Špehar from comment #1) > Created attachment 776295 [details] > journal with kwin segfault Please try to provide a backtrace. How reproducible is this? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1100181] WIFI PEAP deauthenticated with Reason: 1=UNSPECIFIED
by bugzilla_noreply＠novell.com 06 Jul '18

06 Jul '18

1 0

[Bug 1093378] conflicting udev rules completely break USB Serial bridges
by bugzilla_noreply＠novell.com 06 Jul '18

06 Jul '18

http://bugzilla.suse.com/show_bug.cgi?id=1093378 http://bugzilla.suse.com/show_bug.cgi?id=1093378#c26 Martin Wilck <martin.wilck(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.wilck(a)suse.com --- Comment #26 from Martin Wilck <martin.wilck(a)suse.com> --- I have a few remarks on this (stumbled on this while browsing hack week projects) Firstly, I think automation can be improved, even if no unique identification is possible: 1. The udev rules need to make sure that no two (conflicting) drivers grab the same device. That should be fairly easy, create a variable that indicates a driver has grabbed the device, and don't attempt probing any more if it has happened already. 2. Allow users to set something like BLACKLIST_DRIVERS="brltty" for a device. Udev rules evaluate that variable and don't probe if set. If there are many drivers, a WHITELIST_DRIVERS or PREFERRED_DRIVERS setting might be better. 3. If a driver's probing is dangerous (i.e. can cause certain devices not to respond any more, or the probing to hang, comment 13), that driver should be last in the list of drivers tried. Most importantly, the udev(7) man page says that "[RUN] can only be used for very short-running foreground tasks". That's not quite true for an interactive program. I believe some other approach has to be devised. It could be creating a marker under /run somewhere to indicate a dubious device, or sending a dbus event to the session manager of a logged-in user. The GUI program would be started at login, if the marker was found, or if a dbus event was received while logged in, create user-defined udev rules, and generate another uevent (as you already proposed). For a device with a switch (comment 23) it'd be useful to be able to start the GUI program manually to change the setting (I'd expect this to show up e.g. in the GNOME device manager). Btw I guess the "Windows way" of doing this would be to display a question mark on top of the device icon in the system tray. But we don't have a system tray in GNOME any more ... Third, I fear there's little value in remembering USB devices by port or by bus number. I'd suggest remembering the setting either until the device is plugged out, or forever, at user's discretion. Fourth, a list of device descriptions as in comment 23 looks is hard to get right. The usability depends on the availability of a good device data base, which is very hard to obtain and maintain. Lots of such devices are OEM devices, so the same device may ship with various different brand names. It might be better so simply list the available high-level drivers / consumers with an explanation what the driver is for, e.g. - brltty (Braille display) - gpsd (GPS device) - upowerd (Power meter) - ttyUSB (Serial converter) That's more technical and less "user friendly" at first sight, but IMO less confusing. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1096401] snapper: segfault found in openQA tests
by bugzilla_noreply＠novell.com 06 Jul '18

06 Jul '18

http://bugzilla.suse.com/show_bug.cgi?id=1096401 http://bugzilla.suse.com/show_bug.cgi?id=1096401#c18 --- Comment #18 from Dominique Leuenberger <dimstar(a)opensuse.org> --- (In reply to Dominique Leuenberger from comment #17) > Seems I was once able to reproduce it on my machine (using pkcon install > emacs), zypper seems not to show the issue. I mean I see a coredump in my coredumpctl list - but re-issuing pkcon remove emacs / pkcon install emacs does not give me a new coredump, hence 'once' -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1096401] snapper: segfault found in openQA tests
by bugzilla_noreply＠novell.com 06 Jul '18

06 Jul '18

http://bugzilla.suse.com/show_bug.cgi?id=1096401 http://bugzilla.suse.com/show_bug.cgi?id=1096401#c17 --- Comment #17 from Dominique Leuenberger <dimstar(a)opensuse.org> --- Seems I was once able to reproduce it on my machine (using pkcon install emacs), zypper seems not to show the issue. One thing I noticed, which is special to PK vs zypper: PK is a long-running daemon, and libzypp fires off various scripts in a 'unmonitored' way - leaving zombies in the system: 2013 ? Ssl 6:30 /usr/lib/packagekitd 7869 ? Z 0:00 \_ [InstallAppdata] <defunct> 10408 ? Z 0:00 \_ [InstallAppdata] <defunct> 1746 ? Z 0:00 \_ [InstallAppdata] <defunct> 9126 ? Z 0:00 \_ [InstallAppdata] <defunct> 19944 ? Z 0:00 \_ [InstallAppdata] <defunct> 29375 ? Z 0:00 \_ [InstallAppdata] <defunct> 5410 ? Z 0:00 \_ [InstallAppdata] <defunct> 15683 ? Z 0:00 \_ [btrfs-defrag-pl] <defunct> 15685 ? Z 0:00 \_ [snapper.py] <defunct> 28641 ? Z 0:00 \_ [InstallAppdata] <defunct> 22170 ? Z 0:00 \_ [btrfs-defrag-pl] <defunct> 22172 ? Z 0:00 \_ [snapper.py] <defunct> 25146 ? Z 0:00 \_ [btrfs-defrag-pl] <defunct> 25148 ? Z 0:00 \_ [snapper.py] <defunct> 25870 ? Z 0:00 \_ [btrfs-defrag-pl] <defunct> 25872 ? Z 0:00 \_ [snapper.py] <defunct> 26888 ? Z 0:00 \_ [btrfs-defrag-pl] <defunct> 26890 ? Z 0:00 \_ [snapper.py] <defunct> 28577 ? Z 0:00 \_ [btrfs-defrag-pl] <defunct> 28579 ? Z 0:00 \_ [snapper.py] <defunct> 28983 ? Z 0:00 \_ [btrfs-defrag-pl] <defunct> 28985 ? Z 0:00 \_ [snapper.py] <defunct> -- You are receiving this mail because: You are on the CC list for the bug.

1 0