All roads on following problem have terminated in more questions than answers. This means it has to be something simple!
PROBLEM: Galaxy S4 active not accessible from desktop or from any where.
EXPECTED BEHAVIOR: Plug up phone and either find mounted drive in "Dolphin Places" or at the very least be notified by desktop and be able to mount drive via console command.
WHAT I GOT: No notifications in desktop after plugging in. There is some o/p on vt1 as follows:
Hmm' is that two devices, or just one device, being misinterpreted as a serial port instead of a umass device? <<<P.S (this is my best guess right now)
HISTORY/other factoids: This problem shows up on two different boxes both of which dual boot with another O.S. One with win7 and the other with win10. Both windows platforms happily munch their way through this, mount the phone and give notification. That takes care of confirming the hardware.
The older box has been around since FreeBSD 9.2 and this functionality disappeared with the advent of FreeBSD 11. It's been upgraded to 12.1 the whole way. The new box has a just received a virgin install of 12.1, Xorg, and of course KDE5 desktop or whatever its known by. From root on up its a shiny new box stock kernel on a relatively newer model laptop. All these years I've been hunting around in my environment for the culprit. So that pretty much rules out the environment. The behavior of this operation is exactly the same on both machines, right down to the notifications.
Included below is what TRUSS is able to see after attempting to mount using
SYMPTOMS OF MOUNT FAILURE: Using almost any mtp method results in file browser 'Dolphin' apparently locking up but only after migrating to /media/phon. Since at that point things were already untenable I unmounted, unpluged, restarted everything and did a
.
If the above is not interrupted with cntrl+c system will become unresponsive i.e. 'lock-up' and at that point the only thing to do is pull plug on phone and were back in business. I can't help but think that something is going on with fstab but have not dithered with it for fear of breaking some vital mechanism and regressing even further to a blue or black screen. Below is o/p from
On a more happy note FreeBSD 12.1 was a welcome switch and in most all other aspects definitely outperforms 11. I was happy to leave 11 behind.
Merry Christmas!
simple-mtpfs.out
mtp-detect
PROBLEM: Galaxy S4 active not accessible from desktop or from any where.
EXPECTED BEHAVIOR: Plug up phone and either find mounted drive in "Dolphin Places" or at the very least be notified by desktop and be able to mount drive via console command.
WHAT I GOT: No notifications in desktop after plugging in. There is some o/p on vt1 as follows:
Code:
ugen0.8: <SAMSUNG SAMSUNGAndroid> at usbus0
umodem0 on uhub2
umodem0: <CDC Abstract Control Model (ACM)> on usbus0
umodem0: data interface 2, has no CM over data, has no breakHISTORY/other factoids: This problem shows up on two different boxes both of which dual boot with another O.S. One with win7 and the other with win10. Both windows platforms happily munch their way through this, mount the phone and give notification. That takes care of confirming the hardware.
The older box has been around since FreeBSD 9.2 and this functionality disappeared with the advent of FreeBSD 11. It's been upgraded to 12.1 the whole way. The new box has a just received a virgin install of 12.1, Xorg, and of course KDE5 desktop or whatever its known by. From root on up its a shiny new box stock kernel on a relatively newer model laptop. All these years I've been hunting around in my environment for the culprit. So that pretty much rules out the environment. The behavior of this operation is exactly the same on both machines, right down to the notifications.
Included below is what TRUSS is able to see after attempting to mount using
truss -o simpmtpfs.out -d -D -S simple-mtpfs -o allow_other /media/phon. You can see mtp hunting around for its family of executables, finding them all, and then something happens? I cant understand this trace. If you would like some other trace give me your code and it will happen. Please be patient. I am committed to resolving this. The other attached file # mtp-detect is a unexpected surprise. If mtp can cull this much info, why is this thing not mounting? See what I mean, "It's got to be simple." Also have tried sysutils/automount, and mtpfs in all manner of incantations.SYMPTOMS OF MOUNT FAILURE: Using almost any mtp method results in file browser 'Dolphin' apparently locking up but only after migrating to /media/phon. Since at that point things were already untenable I unmounted, unpluged, restarted everything and did a
truss -p <pid of mtp process> in a vt since truss complained when trying to do this from a console. It was a blank check, but after migrating to /media/phon there were zillions of these:
Code:
ioctl(8,USB_FS_COMPLETE, 0x7fffffffd608) ERR#16 'Device busy'
poll({5|POLLIN 8|POLLOUT|POLLRDNORM},2,-1=1 (0x1) read(5,0x7fffffffd69f,1) ERR#35 'Resource temporarily unavailable'If the above is not interrupted with cntrl+c system will become unresponsive i.e. 'lock-up' and at that point the only thing to do is pull plug on phone and were back in business. I can't help but think that something is going on with fstab but have not dithered with it for fear of breaking some vital mechanism and regressing even further to a blue or black screen. Below is o/p from
mount without phone:
Code:
# mount
/dev/ada0s3a on / (ufs, local, journaled soft-updates)
devfs on /dev (devfs, local, multilabel)
/dev/ada0s3b on /var (ufs, local, journaled soft-updates)
/dev/ada0s3d on /tmp (ufs, local, journaled soft-updates)
/dev/ada0s3e on /usr (ufs, local, journaled soft-updates)
procfs on /proc (procfs, local)
fdescfs on /dev/fd (fdescfs)
tmpfs on /tmp (tmpfs, local)
/dev/fuse on /mnt/windows (fusefs)
/dev/fuse on /var/run/user/1001/gvfs (fusefs)Merry Christmas!
simple-mtpfs.out
mtp-detect
