Hello:

The readme says:

For testing, I have everything in the same directory:

groucho@devuan:~/Downloads/renesas/work$ ls
K2013080.mem
README.md
upd72020x-check-and-init
upd72020x-load
upd72020x-load.c
Makefile
check-and-init
upd72020x-fwload.service
groucho@devuan:~/Downloads/renesas/work$ 

Like this?

For the firmware file ---> UPD72020X_FW=[path-to-file] K2026.mem

For the executable ---> UPD72020X_CMD=[path-to-file]./upd72020x-load

Q: where in the system should these two (firmware and executable) files be saved?

Yes.
If it works.
Then I'll have to run it at every boot.

At least until the patch makes it into the kernel but I don't see that happening too soon.  8^/
This issue with Renesas USB .0 cards comes from way back.

I did a dry run to see if everything was in place:

[root@devuan work]# 
[root@devuan work]# ./upd72020x-load
upd72020x-load: version 0.1
usage: upd72020 -r -b bus -d dev -f fct -s -o outfile : read eeprom to file (size default is 0x10000 or 64KB)
usage: upd72020 -w -b bus -d dev -f fct -i infile : write file to eeprom
usage: upd72020 -u -b bus -d dev -f fct -i infile : upload file to firmware memory
[root@devuan work]# 

Usage is specified at GitHub as being this:

./upd72020x-load -u -b 0x02 -d 0x00 -f 0x0 -i Kxxxxxx.mem

But I still need to find the values for -u, -b and -f.

lspci says:

groucho@devuan:~/Downloads/renesas/work$ lspci
04:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03)
groucho@devuan:~/Downloads/renesas/work$ 

So it would be PCI bus 04:00.0 
Yes?

lsusb says:

groucho@devuan:~/Downloads/renesas/work$ lsusb
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
groucho@devuan:~/Downloads/renesas/work$ 

So it would be Device 001 
Yes?

Is the function address 1d6b:0003?

I'm at a loss as to how to put together the line.
I'd appreciate some pointers as to how to do it.

---

Quite obvious ...
Just who do you take me for?
---

Thanks in advance.

Best,

A.

Hello:

More additional information.

Kernel configuration has the card ticked:

groucho@devuan:~$ grep -i renesas /boot/config-4.19.0-14-amd64
CONFIG_NET_VENDOR_RENESAS=y
CONFIG_RENESAS_PHY=m

The card is detected as PCI card ...

groucho@devuan:~$ lspci -nn | grep -i usb    
--- snip ---
04:00.0 USB controller [0c03]: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller [1912:0014] (rev 03)
groucho@devuan:~$ 

... and as a USB3.0 hub:

groucho@devuan:~$ lsusb | grep -i hub    
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 010 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub <--------- |x|
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
groucho@devuan:~$ 

Does it matter that it is not referenced in the same way the Dell monitor's hub is?
eg:

Bus 002 Device 001: ID 1d6b:0003 Renesas Technology Corp.USB 3.0 Hub

Edit:

groucho@devuan:~$ locate renesas
/usr/src/linux-headers-4.19.0-14-amd64/include/config/renesas
/usr/src/linux-headers-4.19.0-14-amd64/include/config/net/vendor/renesas.h
/usr/src/linux-headers-4.19.0-14-amd64/include/config/renesas/phy.h
/usr/src/linux-headers-4.19.0-14-common/arch/arm/include/debug/renesas-scif.S
/usr/src/linux-headers-4.19.0-14-common/include/dt-bindings/clock/renesas-cpg-mssr.h
/usr/src/linux-headers-4.19.0-14-common/include/linux/clk/renesas.h
/usr/src/linux-headers-4.19.0-14-common/include/linux/soc/renesas
/usr/src/linux-headers-4.19.0-14-common/include/linux/soc/renesas/rcar-rst.h
/usr/src/linux-headers-4.19.0-14-common/include/linux/soc/renesas/rcar-sysc.h
/usr/src/linux-headers-4.19.0-14-common/include/linux/usb/renesas_usbhs.h
/usr/src/linux-headers-4.19.0-14-common/include/media/drv-intf/renesas-ceu.h
groucho@devuan:~$ 

Thanks in advance.

Best,

A.

Hello:

The plot thickens.
I think there may be more to this USB problem than meets the eye.

This morning, the third or fourth time I rebooted my rig while in the course of running some tests, I was greeted by a non-working Logitech USB Optical mouse.
But not entirely as the mouse's LED was on with the pointer is visible on the desktop, albeit frozen.

I rebooted the box right there and then but nothing changed.

I then dropped into a virtual console with and checked dmesg.
It was not listed in dmsg, a is usual.

Back into X and without rebooting, I unplugged it from a rear socket of the onboard USB2.0 hub and plugged it in again in (same socket), to no avail.
I then plugged it into one of the front panel USB2.0 sockets and it came to life, as you can see here:

groucho@devuan:~$ sudo dmesg | tail -8
[   53.916788] fuse init (API version 7.27)
[  111.196029] usb 10-2: new low-speed USB device number 2 using uhci_hcd
[  111.391046] usb 10-2: New USB device found, idVendor=046d, idProduct=c077, bcdDevice=72.00
[  111.391051] usb 10-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  111.391054] usb 10-2: Product: USB Optical Mouse
[  111.391056] usb 10-2: Manufacturer: Logitech
[  111.406441] input: Logitech USB Optical Mouse as /devices/pci0000:00/0000:00:1d.2/usb10/10-2/10-2:1.0/0003:046D:C077.0002/input/input15
[  111.406624] hid-generic 0003:046D:C077.0002: input,hidraw1: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-0000:00:1d.2-2/input0
groucho@devuan:~$ 

As you can see here, the mouse was not there when I first booted:

groucho@devuan:~$ sudo dmesg | grep -i "Logitech USB"
[  111.406441] input: Logitech USB Optical Mouse as /devices/pci0000:00/0000:00:1d.2/usb10/10-2/10-2:1.0/0003:046D:C077.0002/input/input15
[  111.406624] hid-generic 0003:046D:C077.0002: input,hidraw1: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-0000:00:1d.2-2/input0
groucho@devuan:~$ 

A dmesg snip from this morning's first boot (as seen in /var/log/mesages) shows where, early in the boot sequence, it is found and initialised by the system:

Mar 20 06:58:41 [    4.964090] input: Logitech USB Optical Mouse as /devices/pci0000:00/0000:00:1d.1/usb9/9-2/9-2:1.0/0003:046D:C077.0002/input/input5
Mar 20 06:58:41 [    4.985718] hid-generic 0003:046D:C077.0002: input,hidraw1: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-0000:00:1d.1-2/input0

Now this non-working mouse problem had already happened a couple of times before.

I had it plugged into the Dell monitor's hub for less cable clutter at floor level and as I do not use a mouse outside X, it was not a problem if the BIOS did no initilalise it at boot.

I thought that being plugged into the monitor's hub could somehow be causing the problem, so I plugged it back into the rear port and it started working immediately.

Until this morning.

I have now unplugged it from the front panel after and plugged it in the back socket again: it works without issue.
If on reboot it the problem crops up again, I'll edit this post about it.

Edit:
No problem on reboot, was not reproduced.

groucho@devuan:~$ sudo dmesg | grep -i "Logitech USB"
[    4.477408] input: Logitech USB Optical Mouse as /devices/pci0000:00/0000:00:1d.1/usb9/9-1/9-1:1.0/0003:046D:C077.0001/input/input4
[    4.487583] hid-generic 0003:046D:C077.0001: input,hidraw0: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-0000:00:1d.1-1/input0
groucho@devuan:~$ 

Any ideas?

Thanks in advance,

A.

Hello:

Read my mind ...
My dmesg does have a reference to IOMMU:

groucho@devuan:~$ sudo dmesg | grep -i iommu
[    1.903203] AMD IOMMUv2 driver by Joerg Roedel <jroedel@suse.de>
[    1.903420] AMD IOMMUv2 functionality not available on this system
groucho@devuan:~$ 

Tried iommu=soft just now, but made no difference in what happens when I plug in the drive into a USB3.0 port.

Thanks for your input.

Cheers,

A.

Hello:

I looked at Gnome under Debian just once years ago in my first attempt at Linux.
Not really what I was wanting to see.

A couple of years later I used Cinammon and then Mate in a few other distributions.
I did not like them too much, really didn't see any need for so much bling and flash.
You have MS for that type of thing.

#! Linux with it's customised Openbox WM was great but that distrubution went south in 2015.
Then systemd crept into everything around me but then found Devuan which came with with Xfce.

As time goes by and I use it more (no more office IT work+MS stuff to deal with), I find Xfce more and more annoying.
The fact that at v4.12 Xfce has not been able to get icon behaviour working properly is really annoying and if 4.16 ends up being what it says it will be ...

But I do mind.
Both in principle and in practice.

[rant]
Things are what they are in IT because the concept of lean and mean has long been abandoned.
Intelligent/clean coding seems to have become a thing of the past.

If those chaps who write those absolutely incredibly efficient viruses in 8 or 10 lines of code used their skills to write a Linux desktop, Linux would be the king of the desktop PCs today.

Yes, one highly adaptable and configurable desktop, instead of the absurd number of bloated DE we have today.
There's far too much crap (and time/effort spent) in the name of a mis-interpreted freedom within an ecosystem where everyone and his dog wants to be a prima donna.
[/rant]

Right.
I will now quietly step off my box and go have my second morning espresso.
Maybe then I'll feel better.  8^7

Thanks for your input.

Best,

A.

Hello:

Yes.
It's all xfwm4: thunar, compositing, etc.

Unfortunately, removing thunar is a messy affaire.
It is so ingrained into Xfce and the desktop that without it, the icons on my desktop would not open and the system complained about org.xfce.filemanager not being found.
The workarounds I found on the web did not work and I had to install it again, bringing along thunar-volman.

It's a real pain in the ass and yet another reason to consider dumping Xfce.

Thanks for your input.

A.

Hello:

An update on this post.

While testing, I realised that this problem only happens only inside thunar, in or from a thunar window.
I can "drag and drop" a file or folder from the desktop into a thunar window and everything will work as intended.
ie: thunar does not crash nor does the desktop freeze.

I cross-posted it to the Xfce forum, also with no luck.

So then I posted the problem to gitlab.xfce.org.
See: https://gitlab.xfce.org/xfce/thunar/-/i … note_27697

One comment was this:

thunar, GTK, X and xfwm4 are all linked by being in the same bag so to speak. ie: Xfce 4.12.
So I don't really get the idea behind this comment.

I probably won't be upgrading to Xfce 4.16.
See https://www.xfce.org/about/news/?post=1608595200 and this thread https://forum.xfce.org/viewtopic.php?id=13689.

Acting on a question in the bug report, I turned off compositing in Applications > Settings > Window Manager Tweaks > Compositor and unchecked "Enable display compositing".
The problem went away.

Then I decided to try with another file manager to see if the "drag and drop" problem was common to any other one.
My first choice was PCManFM as it was the lightest download.

I did it without uninstalling thunar and with compositing enabled.
The experiment was a 100% success, the "drag and drop" problem did not happen with PCManFM.   

At first I thought that installing PCManFM may have fixed something as the install also downloaded these files:
libfm4:amd64 - libfm-modules:amd64 - libfm-extra4:amd64 - lxmenu-data:amd64 - libfm-gtk4:amd64 - gvfs-fuse:amd64
libmenu-cache-bin:amd64 - libfm-data:amd64 - pcmanfm:amd64 - libmenu-cache3:amd64 - libfm-gtk-data:amd64

But no: running Thunar again with compositing enabled still has the "drag and drop" problem.

That's about it.
I will be keeping PCManFM and seriously considering leaving Xfce and if not, least pinning it at 4.12.

Cheers,

A.

Hello:

Both this and the previous version (fwts_18.03.00-0ubuntu1_amd64.deb) have some dependency problems.

groucho@devuan:~/Downloads$ sudo apt install /home/groucho/Downloads/fwts_18.03.00-0ubuntu1_amd64.deb
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Note, selecting 'fwts' instead of '/home/groucho/Downloads/fwts_18.03.00-0ubuntu1_amd64.deb'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.

The following information may help to resolve the situation:

The following packages have unmet dependencies:
 fwts : Depends: libfwtsiasl1 (= 18.03.00-0ubuntu1) but it is not installable
        Depends: libfwtsacpica1 (= 18.03.00-0ubuntu1) but it is not installable
        Depends: libfwts1 (= 18.03.00-0ubuntu1) but it is not installable
        Depends: fwts-efi-runtime-dkms (= 18.03.00-0ubuntu1) but it is not installable
E: Unable to correct problems, you have held broken packages.
groucho@devuan:~/Downloads$ 

I installed with apt install because it is supposed to solve dependencies but these don't show up with apt list.

Should I enable the Ubuntu repo? (I think not ...)

Thanks in advance,

A.

Hello:

Don't think so.

If you mean that I may have burnt an *.iso image to that HDD, I can tell you with certainty that it is not the case.
Either I mounted a that specific *.iso file with AcetoneISO, burnt it to a CD or DVD or wrote it to an SD card.

In any case, is there something that can be done so this does not happen again?

Thanks a lot for your input.

Cheers,

A.

Hello:

Done.
Worked a charm.  8^D

gparted now reports as it should, like parted and gnome-disks do .
But then gparted does read from the drive itself, albeit data which is not correct and in doing so prevents it from being able to do anything on that drive.

Which brings me back to why this happened.
Any idea as to what may have caused it?

Thanks a lot for your help.

Cheers,

A.

Hello:

Hmm ...
There is something strange going on here.

Because, just what is recreating these links the instant they are deleted?

I searched for the string with the last digits of the drive's UUID and found two files.
They were in /.local/share/gcfs-metadata.

There were also about 100 or so files of the same type, most dated 2018, 2019 and 2020.
So I got rid of them, to no avail.

The problem remains.

But hold on because the plot thickens considerably.

I then boot into my alternate (in construction) Beowulf 3.1.0 install to see if I can reach into the other installation's system files but I cannot see past /media/groucho/devuan/dev, even as root.

And here is the deal:

As I am writing this post from my alternate Boewulf installation and on a hunch decide to look further.
So I start gparted and what do I see?

I see /dev/sda (instead of /dev/sdb) with the very same filesystem (iso9660) and label (MAGIC_BOOT_DISK_V2_0) and UUID (2006-02-09-19-22-00-00) I see in my other Beowulf 3.1.0 installation.

Not only that, it turns out that (expectedly) /dev/disk/by-label/ has the same link, just to /sda instead of /sdb.
It is obviously the same drive.

What to do now?

Thanks in advance,

A.

Hello:

Happens.
We are all in the midst of some real bad shit these days.

Of course.

I'll close this post and see again.

Cheers,

A.

Edit: yes, now it is there. Thanks @ralph.ronnquist for getting it fixed.  8^)