[systemd-devel] Fedora 25 XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":1024"

2017-01-11 Thread Robert Kudyba 
HP Compaq 8200 Elite CMT PC, Fedora 25, VGA compatible controller: Advanced 
Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series]

Seeing these errors:

Jan 11 15:34:47 ourdomain systemd[1]: Stopping GNOME Display Manager...
-- Subject: Unit gdm.service has begun shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit gdm.service has begun shutting down.
Jan 11 15:34:47 end gnome-shell[1843]: Connection to xwayland lost
Jan 11 15:34:47 ourdomain at-spi-bus-launcher[2207]: XIO: fatal IO error 11 
(Resource temporarily unavailable) on X server ":1024"
Jan 11 15:34:47 ourdomain at-spi-bus-launcher[2207]:   after 21 requests 
(21 known processed) with 0 events remaining.
Jan 11 15:34:47 ourdomain gnome-settings-[2992]: gnome-settings-daemon: Fatal 
IO error 11 (Resource temporarily unavailable) on X server :1024.
Jan 11 15:34:47 ourdomain audit[1843]: ANOM_ABEND auid=4294967295 uid=42 gid=42 
ses=4294967295 pid=1843 comm="gnome-shell" exe="/usr/bin/gnome-shell" sig=5
Jan 11 15:34:47 ourdomain kernel: do_trap: 18 callbacks suppressed
Jan 11 15:34:47 ourdomain kernel: traps: gnome-shell[1843] trap int3 
ip:7fbf22d58a21 sp:7fff0ba42750 error:0 in 
libglib-2.0.so.0.5000.2[7fbf22d09000+11]
Jan 11 15:34:47 ourdomain gnome-session-binary[1751]: GLib-GObject-CRITICAL: 
g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Jan 11 15:34:47 ourdomain gnome-session[1751]: gnome-session-binary[1751]: 
GLib-GObject-CRITICAL: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Jan 11 15:34:47 ourdomain gnome-session[1751]: gnome-session-binary[1751]: 
WARNING: App 'gnome-settings-daemon.desktop' exited with code 1
Jan 11 15:34:47 ourdomain gnome-session-binary[1751]: WARNING: App 
'gnome-settings-daemon.desktop' exited with code 1
Jan 11 15:34:47 ourdomain systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
-- Subject: Unit system-systemd\x2dcoredump.slice has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit system-systemd\x2dcoredump.slice has finished starting up.
-- 
-- The start-up result is done.
Jan 11 15:34:47 ourdomain systemd[1]: Started Process Core Dump (PID 5376/UID 
0).
-- Subject: Unit systemd-coredump@0-5376-0.service has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit systemd-coredump@0-5376-0.service has finished starting up.
-- 
-- The start-up result is done.
Jan 11 15:34:47 ourdomain audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=systemd-coredump@0-5376-0 comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? termi
Jan 11 15:34:47 ourdomain gdm[1406]: GLib: g_hash_table_find: assertion 
'version == hash_table->version' failed
Jan 11 15:34:47 ourdomain systemd[1]: Stopped GNOME Display Manager.
-- Subject: Unit gdm.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit gdm.service has finished shutting down.
Jan 11 15:34:47 ourdomain audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=gdm comm="systemd" exe="/usr/lib/systemd/systemd" 
hostname=? addr=? terminal=? res=success'
Jan 11 15:34:48 ourdomain systemd-coredump[5377]: Process 1843 (gnome-shell) of 
user 42 dumped core.

Stack trace of 
thread 1843:
#0  
0x7fbf22d58a21 _g_log_abort (libglib-2.0.so.0)
#1  
0x7fbf22d59a77 g_log_default_handler (libglib-2.0.so.0)
#2  
0x55e064de79ee default_log_handler (gnome-shell)
#3  
0x7fbf22d59d84 g_logv (libglib-2.0.so.0)
#4  
0x7fbf22d59f8f g_log (libglib-2.0.so.0)
#5  
0x7fbf2757768e x_io_error (libmutter.so.0)
#6  
0x7fbf21780e8e _XIOError (libX11.so.6)
#7  
0x7fbf2177e6ed _XEventsQueued (libX11.so.6)
#8  
0x7fbf21770397 XPending (libX11.so.6)
#9  
0x7fbf2692b511 gdk_event_source_check (libgdk-3.so.0)
#10 
0x7fbf22d52ba9 g_main_context_check (libglib-2.0.so.0)
#11

Re: [systemd-devel] unit names in systemd log entries

2017-01-11 Thread Yuri D'Elia 
On Wed, Jan 11 2017, Michael Biebl wrote:
> 2017-01-11 15:41 GMT+01:00 Yuri D'Elia :
>> The description is fine for looking at the status of a service (as the
>> unit name is right there), but it does not help in the log, since I have
>> to go and look which unit has the same description (essentially, I have
>> to grep). The unit name is what matters.
>
> You can use the journal (instead of the syslog output) with a
> different output format (-o).
> The journal has the necessary meta data and can show you the service name.

Yes, but I cannot use the journal everywhere.

Also, this indirectly affects what is written as the text entry in the
journal entry.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] unit names in systemd log entries

2017-01-11 Thread Reindl Harald 



Am 11.01.2017 um 16:11 schrieb Yuri D'Elia:

On Wed, Jan 11 2017, Reindl Harald wrote:

The description is fine for looking at the status of a service (as the
unit name is right there), but it does not help in the log, since I have
to go and look which unit has the same description (essentially, I have
to grep). The unit name is what matters


IMHO that behavior was always wrong because it's "Description=" while
description != title, in fact the unit-definition is missing a "Title=" which
is showed in logs and at startup/shutdown and the description is only useful
for "systemcl status"


I want to see the _handle_ I can manipulate through the commands (for
example, to set filters).

I'd actually avoid title as well: Title= would still require grepping
through files to get unit names, which is no different


agreed - but the title would be way nicer at boot/startup comapred to a 
long description which wraps line or get cutted in the middle


currently you can't or shouldn't use "description" for what 
"description" means because it's re-use everywehere

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

2017-01-11 Thread Oliver Neukum 
Am Mittwoch, den 11.01.2017, 16:01 +0100 schrieb Lars Knudsen:
> If it can be invoked via DBus - what is the harm to only do the scan
> for the greylisted (in this case webusb) modems when the user
> actually wants to search for a modem (like a printer) - and leave the
> poor devices alone otherwise?  In headless systems, it will not be
> the same problem as they will most probably be custom made anyway.

Why have a list at all? Would you want the kernel to do an unrequested
probe of a device (function) with WebUSB descriptors at all?
It seems to me that the finest granularity you might need is by
device class, e.g. probing HID devices, so you don't block
the keyboard.

Regards
Oliver

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] unit names in systemd log entries

2017-01-11 Thread Yuri D'Elia 
On Wed, Jan 11 2017, Reindl Harald wrote:
>> The description is fine for looking at the status of a service (as the
>> unit name is right there), but it does not help in the log, since I have
>> to go and look which unit has the same description (essentially, I have
>> to grep). The unit name is what matters
>
> IMHO that behavior was always wrong because it's "Description=" while
> description != title, in fact the unit-definition is missing a "Title=" which
> is showed in logs and at startup/shutdown and the description is only useful
> for "systemcl status"

I want to see the _handle_ I can manipulate through the commands (for
example, to set filters).

I'd actually avoid title as well: Title= would still require grepping
through files to get unit names, which is no different.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

2017-01-11 Thread Lars Knudsen 
If it can be invoked via DBus - what is the harm to only do the scan for
the greylisted (in this case webusb) modems when the user actually wants to
search for a modem (like a printer) - and leave the poor devices alone
otherwise?  In headless systems, it will not be the same problem as they
will most probably be custom made anyway.

On Wed, Jan 11, 2017 at 3:32 PM, Dan Williams  wrote:

> On Wed, 2017-01-11 at 14:21 +0100, Christer Weinigel wrote:
> > On 2017-01-10 19:55, Lars Knudsen wrote:
> > > On Tue, Jan 10, 2017 at 7:08 PM, Dan Williams  > > > wrote:
> > > And we're quite happy to keep blacklisting specific VID/PID
> > > combos we
> > > know are not modems. Another possible solution is to greylist
> > > devices
> > > that happen to have webusb descriptors, such that they won't
> > > get auto-
> > > probed, but could be probed on-demand via D-Bus.  But I'd
> > > rather that
> > > happen via udev rules than MM trying to walk USB device
> > > attributes and
> > > parsing webusb descriptors.
> > >
> > > Actually, that sounds like a very good compromise.  I remember my
> > > own
> > > struggles 3-4 years ago when I had to get a device working properly
> > > on
> > > ChromeOS and Ubuntu, where the firmware had to handle that the
> > > first ~16
> > > seconds it would *sometimes* get sent strange AT commands (the
> > > probing)
> > > all while the system thought it could already start speaking with
> > > the
> > > device over e.g. chrome.serial.  Eventually you (modemmanager) were
> > > kind
> > > enough to get our VID/PID listed and ChromeOS was quick to pick it
> > > up
> > > (~5-6 months to get in stable) and ubuntu so kind to upgrade to the
> > > version of modemmanager including our blacklisting approx 2.5 years
> > > later (sigh) ;)
> >
> > Weird question: should modem manager really autoprobe _every_ serial
> > device nowdays?  99% of the devices I connect to my laptop are not
> > modems.  They are serial ports on development platforms, RS485
> > interfaces, Arduinos with a FTDI, CP210x or CH341 USB-UART bridge,
> > and
> > so on.  Modems with a physical serial port are almost nonexistent
> > today.
> >  For me it's a pain in the back to have to update the blacklist of
> > things modem manger shouldn't touch.
>
> MM does already whitelist platform serial devices (eg, i8250 UART) and
> already greylists USB<->serial adapters like FTDI and CP210x.
>
> Unfortunately, you'd be surprised how many modems actually *do* get
> hooked up with USB<->serial converters like FTDI and CP210x.  Modem
> manufacturers often build these chips into devices so the modem looks
> like USB but uses a generic VID/PID and a generic driver (FTDI).
>
> If you have updates to the blacklist, we'd happily take them.
>
> > Wouldn't it be better to whitelist known ḿodems and have modem
> > manager
> > ignore everything else?  Devices which are so new that modem manager
> > don't know about them can be configured manually.
>
> I ran a list of explicit modem VID/PID pairs in kernel drivers (like
> option, qmi_wwan, sierra, hso, etc) 2 years ago and there were >1000
> known WWAN modems.
>
> That >1000 does *not* count attribute-matched devices like CDC ACM
> devices, CDC WDM/ether, generic serial bridge modems (FTDI/CP210x), or
> USB interface class/subclass/protocol matching which many Huawei
> devices now use instead.  Whitelisting is simply not really an option,
> unfortunately, as too many new modem devices actually do come out every
> year.  Thankfully, many these days are MBIM (thanks to Windows 8+) or
> QMI, but the embedded world still does a lot of serially-bridged
> devices.
>
> Dan
>
> > At least to me that seems like a much more sane default.
> >
> >   /Christer
> > ___
> > ModemManager-devel mailing list
> > modemmanager-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] unit names in systemd log entries

2017-01-11 Thread Yuri D'Elia 
When systemd is generating log entries for some units, it writes the
human description in the syslog:

systemd[xy]: Starting GnuPG cryptographic agent...
systemd[xy]: Stopping GnuPG cryptographic agent...
systemd[xy]: Closing GnuPG cryptographic agent...

however, over time I've found this behavior increasingly annoying. I
don't want to see the human description in there, but the actual unit
name.

The description is fine for looking at the status of a service (as the
unit name is right there), but it does not help in the log, since I have
to go and look which unit has the same description (essentially, I have
to grep). The unit name is what matters.

Any thoughts?

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

2017-01-11 Thread Dan Williams 
On Wed, 2017-01-11 at 14:21 +0100, Christer Weinigel wrote:
> On 2017-01-10 19:55, Lars Knudsen wrote:
> > On Tue, Jan 10, 2017 at 7:08 PM, Dan Williams  > > wrote:
> > And we're quite happy to keep blacklisting specific VID/PID
> > combos we
> > know are not modems. Another possible solution is to greylist
> > devices
> > that happen to have webusb descriptors, such that they won't
> > get auto-
> > probed, but could be probed on-demand via D-Bus.  But I'd
> > rather that
> > happen via udev rules than MM trying to walk USB device
> > attributes and
> > parsing webusb descriptors.
> > 
> > Actually, that sounds like a very good compromise.  I remember my
> > own
> > struggles 3-4 years ago when I had to get a device working properly
> > on
> > ChromeOS and Ubuntu, where the firmware had to handle that the
> > first ~16
> > seconds it would *sometimes* get sent strange AT commands (the
> > probing)
> > all while the system thought it could already start speaking with
> > the
> > device over e.g. chrome.serial.  Eventually you (modemmanager) were
> > kind
> > enough to get our VID/PID listed and ChromeOS was quick to pick it
> > up
> > (~5-6 months to get in stable) and ubuntu so kind to upgrade to the
> > version of modemmanager including our blacklisting approx 2.5 years
> > later (sigh) ;)
> 
> Weird question: should modem manager really autoprobe _every_ serial
> device nowdays?  99% of the devices I connect to my laptop are not
> modems.  They are serial ports on development platforms, RS485
> interfaces, Arduinos with a FTDI, CP210x or CH341 USB-UART bridge,
> and
> so on.  Modems with a physical serial port are almost nonexistent
> today.
>  For me it's a pain in the back to have to update the blacklist of
> things modem manger shouldn't touch.

MM does already whitelist platform serial devices (eg, i8250 UART) and
already greylists USB<->serial adapters like FTDI and CP210x.

Unfortunately, you'd be surprised how many modems actually *do* get
hooked up with USB<->serial converters like FTDI and CP210x.  Modem
manufacturers often build these chips into devices so the modem looks
like USB but uses a generic VID/PID and a generic driver (FTDI).

If you have updates to the blacklist, we'd happily take them.

> Wouldn't it be better to whitelist known ḿodems and have modem
> manager
> ignore everything else?  Devices which are so new that modem manager
> don't know about them can be configured manually.

I ran a list of explicit modem VID/PID pairs in kernel drivers (like
option, qmi_wwan, sierra, hso, etc) 2 years ago and there were >1000
known WWAN modems.

That >1000 does *not* count attribute-matched devices like CDC ACM
devices, CDC WDM/ether, generic serial bridge modems (FTDI/CP210x), or
USB interface class/subclass/protocol matching which many Huawei
devices now use instead.  Whitelisting is simply not really an option,
unfortunately, as too many new modem devices actually do come out every
year.  Thankfully, many these days are MBIM (thanks to Windows 8+) or
QMI, but the embedded world still does a lot of serially-bridged
devices.

Dan

> At least to me that seems like a much more sane default.
> 
>   /Christer
> ___
> ModemManager-devel mailing list
> modemmanager-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

2017-01-11 Thread Oliver Neukum 
On Tue, 2017-01-10 at 19:55 +0100, Lars Knudsen wrote



> And we're quite happy to keep blacklisting specific VID/PID
> combos we
> know are not modems. Another possible solution is to greylist
> devices
> that happen to have webusb descriptors, such that they won't
> get auto-
> probed, but could be probed on-demand via D-Bus.  But I'd
> rather that
> happen via udev rules than MM trying to walk USB device
> attributes and
> parsing webusb descriptors.

> 
> If greylisting prevents auto-probing, I think it would be very
> valuable for devices with a WebUSB header because those will in most
> cases (as I see them used) be industrial things (like my current
> medical company employer) or IoT devices.  And waiting ~16 seconds for
> a fallback to USB Serial where WebUSB is not available (or for other
> reasons not chosen), can be a real pain.
> 
> 
> I agree that a solid udev rule would be a good way forward (I'll look
> into greylisting and see if I can come up with something that covers)
> and maybe this could also be the place to do the user space access (or
> not - I'll try to come back with something.

I am afraid this would not work. Or rather it would work once.
But as soon as the driver is already loaded, it will bind and
we have a beautiful race condition, which the kernel will almost
certainly win.
> 
And if we happen to look at a storage device we may see an unclean
removal if you kick the kernel off a device. I am afraid if you
really want to go to triggered probing, you need a sysctl for that.

Regards
Oliver


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel