Bug 91032

Summary: Please add old Palm OS devices to udev blacklist
Product: ModemManager Reporter: Lincoln Roop <lroop>
Component: generalAssignee: ModemManager bug user <modemmanager>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: noloader
Version: unspecified   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Lincoln Roop 2015-06-19 18:48:47 UTC
ModemManager probing USB-connected Palm OS hardware during HotSync results in failure to sync, and in many cases the Palm device crashing.  I have observed this on Debian Wheezy and Jessie, and the crashing/hotsync failure is not seen if I stop ModemManager or add a file containing the following lines to lib/udev/rules.d/. If it's beneficial, I can try to dig through the source for 
the Palm/Visor driver for other USB PID/VID pairs that correspond to old 
Palm handhelds that should not be probed.

# Rules to blacklist certain Palm Pilot devices from modem-manager probing

ACTION!="add|change", GOTO="mm_usb_device_blacklist_end"
SUBSYSTEM!="usb", GOTO="mm_usb_device_blacklist_end"
ENV{DEVTYPE}!="usb_device",  GOTO="mm_usb_device_blacklist_end"

# Palm M500
ATTRS{idVendor}=="0830", ATTRS{idProduct}=="0001", 
ENV{ID_MM_DEVICE_IGNORE}="1"

# Palm M505
ATTRS{idVendor}=="0830", ATTRS{idProduct}=="0002", 
ENV{ID_MM_DEVICE_IGNORE}="1"

# Palm M515
ATTRS{idVendor}=="0830", ATTRS{idProduct}=="0003", 
ENV{ID_MM_DEVICE_IGNORE}="1"
Comment 1 Aleksander Morgado 2015-06-19 19:21:14 UTC
Pushed fix to git master and mm-1-4.
Comment 2 Jeffrey Walton 2019-03-14 11:13:26 UTC
I'm not sure how helpful this will be in general, but in my C program:

    int modem = open(device_path, O_RDWR | O_NOCTTY | O_SYNC);
    ...

    int res = ioctl(fd, TIOCEXCL, NULL);
    ...

TIOCEXCL puts the file descriptor into exclusive mode, and it stops other programs from opening the device and mucking with state. The downside is it suffers a race.

I think the ultimate fix is have the kernel honor O_EXCL on character devices and honor exclusive semantics. The kernel folks say no one has submitted a patch to make O_EXCL work as expected by typical user.

I'm not sure what the shell folks will do if they have O_EXCL and use two shells to control the modem. But they will have what they need to stop the problem, so I guess they can figure it out.

Having the kernel provide exclusive semantics for O_EXCL seems very natural to me. There's no sense in introducing a new flag like they did with sockets and SOCK_NONBLOCK.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.