The officially official Devuan Forum!

You are not logged in.

#1326 Re: Installation » pcc_cpufreq instead of acpi_cpufreq » 2021-03-24 20:20:09

Hello:

Head_on_a_Stick wrote:

I can't load pcc_cpufreq unless acpi_cpufreq is also loaded ...

I see.

Head_on_a_Stick wrote:

How did you determine that Slackware system uses pcc instead of acpi?

No.
I didn't figure that one out.

A chap that posted on bugzilla.kernel.org told me.

He has two identical workstations.
One runs a proprietary OS called Unraid which is based on Slackware, the other plain Linux.

One of the workstations had the shutdown issue while the other (identical) runs Unraid and does not get the bad shutdowns.
The first WS BIOS has since been patched but the second one has not.

See https://bugzilla.kernel.org/show_bug.cgi?id=210689#c4.

Head_on_a_Stick wrote:

... don't think they can be used independently but this is just a guess.
... can't really understand ...

Imagine me trying to get anything out of it.  8^7

Head_on_a_Stick wrote:

And btw ...

Yes, I know.
But I forget, being accustomed to using cat and then grep from ages ago.

Eventually, I guess.

Thanks for your input.

Best,

A.

#1327 Re: Installation » pcc_cpufreq instead of acpi_cpufreq » 2021-03-24 19:16:41

Hello:

Head_on_a_Stick wrote:

... try blocking the acpi_cpufreq module from the GRUB menu ...

This what is going on before blocking it:

groucho@devuan:~$ cpupower frequency-info # supplied by the linux-cpupower package
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us
  hardware limits: 2.00 GHz - 2.83 GHz
  available frequency steps:  2.83 GHz, 2.34 GHz, 2.00 GHz
  available cpufreq governors: ondemand performance schedutil
  current policy: frequency should be within 2.00 GHz and 2.83 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 2.03 GHz (asserted by call to kernel)
  boost state support:
    Supported: no
    Active: no
groucho@devuan:~$

This is the result:

groucho@devuan:~$ cpupower frequency-info # supplied by the linux-cpupower package
analyzing CPU 0:
  no or unknown cpufreq driver is active on this CPU
  CPUs which run at the same hardware frequency: Not Available
  CPUs which need to have their frequency coordinated by software: Not Available
  maximum transition latency:  Cannot determine or is not supported.
Not Available
  available cpufreq governors: Not Available
  Unable to determine current policy
  current CPU frequency: Unable to call hardware
  current CPU frequency:  Unable to call to kernel
  boost state support:
    Supported: no
    Active: no
groucho@devuan:~$

But is would seem that if acpi_cpufreq is not loaded, pcc_cpufreq is not loade either:

groucho@devuan:~$ lsmod | grep -i cpu
groucho@devuan:~$ lsmod | grep -i freq
groucho@devuan:~$ lsmod | grep cpu
groucho@devuan:~$ lsmod | grep _cpufreq
groucho@devuan:~$
groucho@devuan:~$ cat /proc/modules | grep _cpufreq
groucho@devuan:~$ 

Thanks for your input.

Best,

A.

#1328 Installation » pcc_cpufreq instead of acpi_cpufreq » 2021-03-24 14:07:55

Altoid
Replies: 5

Hello:

Running up to date Devuan Beowulf 3.1.0:

groucho@devuan:~$ uname -a
Linux devuan 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux
groucho@devuan:~$ 

My Sun Ultra 24 box has for the longes time had a persistent bad shutdown issue to which I have not been able to find a soluton, even by injecting a modified DSDT file at boot time.
It has been present across many Linux kernels and distributions.

See https://bugzilla.kernel.org/show_bug.cgi?id=201965

I have recently learned that this issue could be related to the cpu scaling driver.

It seems that a proprietary Slackware based OS which uses pcc_cpufreq instead of acpi_cpufreq does not show the problem when run on a workstation which, running another Linux distribution using acpi_cpufreq, does.

Although the WS is not a Sun U24 such as mine, the problem is exactly the same one, presenting the same symptoms.

See:
https://bugzilla.kernel.org/show_bug.cgi?id=199349#c4
https://lkml.org/lkml/2018/11/13/857.

Both modules are present in my installation, the one in use being acpi_cpufreq:

groucho@devuan:~$ lsmod | grep cpu
pcc_cpufreq            16384  0
acpi_cpufreq           24576  1
groucho@devuan:~$ 
groucho@devuan:~$ cat /proc/modules | grep _cpufreq
pcc_cpufreq 16384 0 - Live 0x0000000000000000
acpi_cpufreq 24576 1 - Live 0x0000000000000000
groucho@devuan:~$ 

Is it possible to make the system use pcc_cpufreq instead of acpi_cpufreq?
Testing without a module that seems to have issues could get me a solution. 

My CPU is a Core2 Q9550 - Yorkfield.

Thanks in advance,

A.

#1329 Re: Hardware & System Configuration » [SOLVED] USB 3.0 card, external drive and unknown algorithms » 2021-03-23 21:19:18

Hello:

ralph.ronnquist wrote:

... try using the USB "address" ...

Well ...
I'll be quick so my mood does not get worse yet.

---

I really deserve to be mocked to extintion.

I got these USB drives long ago to do some installations that were eventually cancelled.
Got to keep them but have since had very little use.
They are in pristine condition.

Each drive came with it's own OEM cable in the box.

These cables are, as far as I can see, identical and have the same markings: AWM 2725   80°C   30V  VM-1
One says "USB 3.0 HighSpeed Cable Broad" and the other says "Universal Serial Bus 3.0", only difference.

But the drives are both USB3.0 ...

Having no reason to think otherwise, I assumed that they were also electrically identical.
More so coming from the same OEM that sells these drives.

So ...
USB cable A bundled with USB3.0 drive A is the same as USB cable B bundled with USB3.0 drive B, in every sense.
Same OEM, same USB standard, same capacity drive, same markings ...
And as such, obviously interchangeable.
Right?

---
BTW: I was asked about the cable at GitHub.
But as they both worked, there wasn't anything wrong with them.
---

Well ...
Tl,dr: I switched the cables and now both drives are recognised.

groucho@devuan:~ $ sudo uhubctl
[sudo] password for groucho:
Current status for hub 5 [1d6b:0003 Linux 4.19.0-14-amd64 xhci-hcd xHCI Host Controller 0000:04:00.0, USB 3.00, 4 ports, ppps]
Port 1: 0203 power 5gbps U0 enable connect [043e:70f5 LG Electronics Inc. LG External HDD A3110300000A]      <--- | x |
Port 2: 0203 power 5gbps U0 enable connect [043e:70f5 LG Electronics Inc. LG External HDD A1204000000004C7]  <--- | x |
Port 3: 02a0 power 5gbps Rx.Detect
Port 4: 02a0 power 5gbps Rx.Detect
Current status for hub 3-3 [0424:2514, USB 2.00, 4 ports, ppps]
Port 1: 0100 power
Port 2: 0100 power
Port 3: 0100 power
Port 4: 0100 power
Current status for hub 3 [1d6b:0002 Linux 4.19.0-14-amd64 xhci-hcd xHCI Host Controller 0000:04:00.0, USB 2.00, 4 ports, ppps]
Port 1: 0100 power
Port 2: 0100 power
Port 3: 0507 power highspeed suspend enable connect [0424:2514, USB 2.00, 4 ports, ppps]
Port 4: 0100 power
groucho@devuan:~ $

For whatever reason, drive A will only work properly with cable A but drive B will work properly with cable A or cable B.
Seems that "USB 3.0 HighSpeed" is not the same as "Universal Serial Bus 3.0"

[rant]
Is it possible that Toshiba skimped $0.05 on a 30cm USB3.0 cable for their #$%& external USB3.0 drives?
Unbelievable ...
[/rant]

So that's it.
Tomorrow I'll feel better.

Thanks for your input.

A.

#1330 Re: Hardware & System Configuration » [SOLVED] USB 3.0 card, external drive and unknown algorithms » 2021-03-23 18:04:54

Hello:

I (think) I have been able to solve the riddle but not the problem.
Of great help was rtreffer @Github.

On a whim, I connected another 500Gb USB3.0 drive I have, unused in a box.

It worked: same cable, same USB3.0 card, same port.
Both USB3.0 drives are Toshiba but they are different models.

The one that works is model HXD7 USB 3.0.
The one that does not work is model HXE4 USB 3.0.

dmesg

[ 2420.760462] usb 2-1: new SuperSpeed Gen 1 USB device number 4 using xhci_hcd
[ 2420.787113] usb 2-1: New USB device found, idVendor=043e, idProduct=70f5, bcdDevice= 1.00
[ 2420.787117] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 2420.787120] usb 2-1: Product: LG External HDD
[ 2420.787123] usb 2-1: Manufacturer: LG Electronics Inc.
[ 2420.787125] usb 2-1: SerialNumber: A3110300000A
[ 2420.791771] usb-storage 2-1:1.0: USB Mass Storage device detected
[ 2420.791953] scsi host9: usb-storage 2-1:1.0
[ 2424.446142] scsi 9:0:0:0: Direct-Access LG External HDD AX00 PQ: 0 ANSI: 5
[ 2424.446523] sd 9:0:0:0: Attached scsi generic sg7 type 0
[ 2424.446645] sd 9:0:0:0: [sdg] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[ 2424.447552] sd 9:0:0:0: [sdg] Write Protect is off
[ 2424.447555] sd 9:0:0:0: [sdg] Mode Sense: 23 00 00 00

So the USB3.0 card and both USB3.0 drives work properly.
It's just that one of them does not do it at USB3.0 speeds.

Since both drives work with the same cable and the same USB3.0 card, I thought the problem had to be with whatever gets done between the card and the SATA/USB bridge.
Nothing else came to mind.

So I opened up the cases (a real PITA) and saw the difference between them:

Model HXD7 has a ASM1053 SATA/USB controller chip.
[http://j5d2v7d7.stackpathcdn.com/wp-con … SM1051.gif] (url) photo from the web

Model HXD7 has a VIA Labs VL 701-04
[https://www.via-labs.com/archive/images … VL701_.jpg] (url) photo from tthe web

Plugged in the way I knew worked, printout from uhubctl* was clear: both drives are detected
---
*An interesting utility to control USB ports in compatible cards.  ->  https://github.com/mvp/uhubctl
---

groucho@devuan:~ $ sudo uhubctl
Current status for hub 2 [1d6b:0003 Linux 4.19.0-14-amd64 xhci-hcd xHCI Host Controller 0000:04:00.0, USB 3.00, 4 ports, ppps]
Port 1: 0203 power 5gbps U0 enable connect [043e:70f5 LG Electronics Inc. LG External HDD A3110300000A]      <----- | x |
Port 2: 02a0 power 5gbps Rx.Detect
Port 3: 02a0 power 5gbps Rx.Detect
Port 4: 02a0 power 5gbps Rx.Detect
Current status for hub 1-3 [0424:2514, USB 2.00, 4 ports, ppps]
Port 1: 0503 power highspeed enable connect [043e:70f5 LG Electronics Inc. LG External HDD A1204000000004C7] <----- | x |
Port 2: 0100 power
Port 3: 0100 power
Port 4: 0100 power
Current status for hub 1 [1d6b:0002 Linux 4.19.0-14-amd64 xhci-hcd xHCI Host Controller 0000:04:00.0, USB 2.00, 4 ports, ppps]
Port 1: 0100 power
Port 2: 0100 power
Port 3: 0503 power highspeed enable connect [0424:2514, USB 2.00, 4 ports, ppps]
Port 4: 0100 power
groucho@devuan:~ $

But when I switch them around, the one with the VIA SATA/USB bridge is no longer detected:

groucho@devuan:~ $ sudo uhubctl
Current status for hub 2 [1d6b:0003 Linux 4.19.0-14-amd64 xhci-hcd xHCI Host Controller 0000:04:00.0, USB 3.00, 4 ports, ppps]
Port 1: 02a0 power 5gbps Rx.Detect                                                                        <----- | o |   
Port 2: 02a0 power 5gbps Rx.Detect
Port 3: 02a0 power 5gbps Rx.Detect
Port 4: 02a0 power 5gbps Rx.Detect
Current status for hub 1-3 [0424:2514, USB 2.00, 4 ports, ppps]
Port 1: 0503 power highspeed enable connect [043e:70f5 LG Electronics Inc. LG External HDD A3110300000A]  <----- | x |
Port 2: 0100 power
Port 3: 0100 power
Port 4: 0100 power
Current status for hub 1 [1d6b:0002 Linux 4.19.0-14-amd64 xhci-hcd xHCI Host Controller 0000:04:00.0, USB 2.00, 4 ports, ppps]
Port 1: 0100 power
Port 2: 0100 power
Port 3: 0503 power highspeed enable connect [0424:2514, USB 2.00, 4 ports, ppps]
Port 4: 0100 power
groucho@devuan:~ $

That seems to be what it is all about.

lsusb -vv can reveal interesting things:

groucho@devuan:~$ sudo lsusb -vv 
--- snip ---
Bus 002 Device 007: ID 043e:70f5 LG Electronics USA, Inc. External HDD
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         9
  idVendor           0x043e LG Electronics USA, Inc.
  idProduct          0x70f5 External HDD
  bcdDevice            1.00
  iManufacturer           2 LG Electronics Inc.
  iProduct                3 LG External HDD
  iSerial                 1 A3110300000A
--- snip ---
 wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)    <---
      Device can operate at High Speed (480Mbps)   <---
      Device can operate at SuperSpeed (5Gbps)     <---
--- snip ---  
Bus 001 Device 006: ID 043e:70f5 LG Electronics USA, Inc. External HDD
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x043e LG Electronics USA, Inc.
  idProduct          0x70f5 External HDD
  bcdDevice            6.00
  iManufacturer           1 LG Electronics Inc.
  iProduct                2 LG External HDD
  iSerial                 3 A1204000000004C7
--- snip ---
   wSpeedsSupported   0x000c
      Device can operate at High Speed (480Mbps)    <---
      Device can operate at SuperSpeed (5Gbps)      <---
--- snip ---

lsusb reveals that both external USB3.0 drives support USB3.0 speeds.
I'd think that data that comes from somewhere in the drive's SATA/USB3.0 bridge, not the HDD.

If I had to make an (un)educated guess, I'd say that one SATA/USB bridge has a problem with the USB3.0 ports' Rx.Detect.
And if this were true, could it be a xHCI_PCI module problem/setting causing this?

But it is all over my head.

Any comments of suggestions will be welcome.

Thanks in advance,

Best,

A.

#1331 Re: Hardware & System Configuration » [SOLVED] USB 3.0 card, external drive and unknown algorithms » 2021-03-22 21:08:52

Hello:

rolfie wrote:

Also got a PCIe card with a Renesas 720201 installed. Used the same tools and failed:

05:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03)

It seems to be a problematic card, to say the least.

It seems that application has a bug.
See here: https://github.com/markusj/upd72020x-load/issues/16 <- fourth post

rtreffer wrote:

So if you compiled the project in the past edit that line to read `is_x1 = true, is_x2 = true;`,
then compile as usual (`make` is enough - the task of make is to figure out what changed an needs to be recompiled)
Then use the new binary to upload.

Now the application apparently works.
But I am doing something wrong.
ie: -w is a no-no and I'm downgrading which apparently won'r work.

See the rest of the thread there, that chap seems to know about it.

Could you send me a link to the firmware you have?

Thanks in advance.

Best,

A.

#1332 Re: Hardware & System Configuration » [SOLVED] USB 3.0 card, external drive and unknown algorithms » 2021-03-22 18:07:43

Hello:

Head_on_a_Stick wrote:

I would place the script under /usr/local/bin/ and place the firmware under /usr/local/lib/firmware/ then change the script like this:

# set paths to loader and firmware, if not provided by environment
readonly UPD72020X_CMD="${UPD72020X_CMD:-/usr/local/bin/upd72020x-load}"
readonly UPD72020X_FW="${UPD72020X_FW:-/usr/local/lib/firmware/K2026.mem}"

^ That replaces lines 7-13 (inclusive) in the original script. It does the same thing without having to run two if...fi loops.

Right, will do.
But it's still not working, some problem with the application and the card's ID and some missing data somewhere.
Hopefully I won't brick the damn thing.

Not as easy as it seemed at first.
But I got to use "make" for the first time.

Head_on_a_Stick wrote:
Altoid wrote:

Just who do you take me for?

Sorry, that was a comment about ...

Sorry?
Hmm ...
Have you had your tea yet? 

I was just taking the piss ... 8^D!
Can't take me that seriously.

Right.
Once I get this working manually, I'll fix that.
Thanks a lot for your input.

Best,

A.

#1333 Re: Hardware & System Configuration » [SOLVED] USB 3.0 card, external drive and unknown algorithms » 2021-03-22 17:53:03

ralph.ronnquist wrote:

... so I would guess on

-b 0x04 -d 0x00 -f 0x00

Right ...

But I am getting errors and cannot save the original or upload a new/different firmware.

According to the application, usage is like this:

[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]# 

Reading:

[root@devuan work]# ./upd72020x-load -r -b 0x04 -d 0x00 -f 0x00 -s -o original.mem
Doing the reading     <---- must be right because it says it is reading.
bus = 4 
dev = 0 
fct = 0 
fname = (null) 
ERROR: wrong vendorid/devid. Expected an UPD720201 or UPD720202 chip and this is not one!
       reported vendorid/devid: 1912:0014 
 ======> FAILED

Writing:

[root@devuan work]#   ./upd72020x-load -u -b 0x04 -d 0x00 -f 0x00 -i K2013080.mem
Doing the upload      <---- must be right because it says it is uploading.
bus = 4 
dev = 0 
fct = 0 
fname = K2013080.mem 
ERROR: wrong vendorid/devid. Expected an UPD720201 or UPD720202 chip and this is not one!
       reported vendorid/devid: 1912:0014 
 ======> FAILED
[root@devuan work]# 

or

[root@devuan work]# ./upd72020x-load -w -b 0x04 -d 0x00 -f 0x00 -i K2013080.mem
Doing the writing
bus = 4 
dev = 0 
fct = 0 
fname = K2013080.mem 
ERROR: wrong vendorid/devid. Expected an UPD720201 or UPD720202 chip and this is not one!
       reported vendorid/devid: 1912:0014 
 ======> FAILED
[root@devuan work]# 

I've posted at GitHub to see if I can get a solution.

Thanks for your input.

A.

#1334 Re: Hardware & System Configuration » [SOLVED] USB 3.0 card, external drive and unknown algorithms » 2021-03-21 22:41:14

Hello:

Head_on_a_Stick wrote:

... supplies a systemd[0] unit file to load the firmware at boot but that won't work for Devuan.

The readme says:

For using SystemD, please adjust the paths/environment variables in the unit file according to your install locations of script, loader and firmware image.
If no environment variables are set, the script presumes that loader and firmware image are co-located with itself in the same directory.

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$ 
Head_on_a_Stick wrote:

Change ...
... and change

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?

Head_on_a_Stick wrote:

You could call the script using /etc/rc.local instead.

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.

---

Head_on_a_Stick wrote:

[0] Not "SystemD"!

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

Thanks in advance.

Best,

A.

#1335 Re: Hardware & System Configuration » [SOLVED] USB 3.0 card, external drive and unknown algorithms » 2021-03-21 17:26:56

Hello:

I think I found the necessary bits/data for a solution to this but to be honest, have no idea as to how to go about it.
ie: properly and without bricking something.

Here's the link that has what seems to be a solution:
https://github.com/markusj/upd72020x-load

Here's a blog with the hows and whys:
https://mjott.de/blog/881-renesas-usb-3 … -vs-linux/

The uPD720202 chipset requires additional firmware to operate.
It must be either uploaded by the driver during initialization, or can be stored on an external EEPROM.
--- snip ---
For the first case, there exists a patch for the Linux kernel driver for this chipset to support uploading the firmware image at boot time.
But apparently, this patch never made it into the kernel and I have not found the firmware image in the linux-firmware repository.

Here's the link to the firmware file:
https://raw.githubusercontent.com/chunk … 120615.zip

Firmware file Release Note:

****************************************************************************
******* D720201 & D720202 Design Resources Release *******
****************************************************************************
Release Note                                                   June 15.2012

Renesas Electronics D720201 & uPD720202
USB3.0 Host Controller Firmware

Version : 2.0.1.3 :June 15th, 2012
Copyright (C) 2011-2012 Renesas Electronics Corporation All Rights Reserved
***************************************************************************************************

Note : This firmware is for the following devices.
      - uPD720201 ES 2.0 sample whose revision ID (in the PCI Configuration
       Register) is 2h.
      - uPD720201 ES 2.1 sample & CS sample & Mass product whose revision
       ID (in the PCI Configuration Register) is 3h.
      - uPD720202 ES 2.0 sample & CS sample & Mass product whose revision
       ID (in the PCI Configuration Register) is 2h.

This is all I could find.

Anyone care to have alook/comment?

Thanks in advance,

A.

#1336 Re: Hardware & System Configuration » [SOLVED] USB 3.0 card, external drive and unknown algorithms » 2021-03-20 20:37:04

Hello:

Altoid wrote:

Any ideas?

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.

#1337 Re: Hardware & System Configuration » [SOLVED] USB 3.0 card, external drive and unknown algorithms » 2021-03-20 13:57:28

Hello:

Altoid wrote:

Any ideas?

Some additional information.

I booted the box with an ubuntu fwts-live image which uses the 5.4.0 LTS kernel to see what showed up in dmesg:

[    0.000000] Linux version 5.4.0-66-generic (buildd@lgw01-amd64-039) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #74-Ubuntu SMP Wed Jan 27 22:54:38 UTC 2021 (Ubuntu 5.4.0-66.74-generic 5.4.86)
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz root=LABEL=writable ro console=tty1 console=ttyS0 quiet
--- snip ---
[    0.628135] xhci_hcd 0000:04:00.0: xHCI Host Controller
[    0.628138] xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 10
[    0.628141] xhci_hcd 0000:04:00.0: Host supports USB 3.0 SuperSpeed
[    0.631214] usb usb10: We don't know the algorithms for LPM for this host, disabling LPM.      <------------ | x |
[    0.631234] usb usb10: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.04
[    0.631236] usb usb10: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.631237] usb usb10: Product: xHCI Host Controller
[    0.631238] usb usb10: Manufacturer: Linux 5.4.0-66-generic xhci-hcd
[    0.631239] usb usb10: SerialNumber: 0000:04:00.0

Then in lspci:

04:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03)

As before, nothing happened when I pugged in the external USB3.0 drive in the USB3.0 card socket.

Thanks in advance,

A.

#1338 Re: Hardware & System Configuration » [SOLVED] USB 3.0 card, external drive and unknown algorithms » 2021-03-20 12:34:00

Hello:

Altoid wrote:

Any ideas?

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.

#1339 Re: Hardware & System Configuration » [SOLVED] USB 3.0 card, external drive and unknown algorithms » 2021-03-20 01:12:21

Hello:

Head_on_a_Stick wrote:

Add amd-iommu=off as well (as per my link).

Sorry ...
Confused it with another link where only iommu=soft was mentioned.

No change.
Also tried booting with the drive attached and also with pci=nomsi in the kernel command but no luck.

See here:
https://github.com/torvalds/linux/commi … 11094b6f09

github.com @May 15, 2020  wrote:

usb: xhci: Add support for Renesas controller with memory

Some rensas controller like uPD720201 and uPD720202 need firmware to be
loaded. Add these devices in table and invoke renesas firmware loader
functions to check and load the firmware into device memory when
required.

See this post also: https://bbs.archlinux.org/viewtopic.php … 0#p1925250

Thanks for your input.

Cheers,

A.

#1340 Re: Hardware & System Configuration » [SOLVED] USB 3.0 card, external drive and unknown algorithms » 2021-03-19 23:32:06

Hello:

Head_on_a_Stick wrote:

tl;dr: add iommu=soft as a kernel command line parameter.

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.

#1341 Hardware & System Configuration » [SOLVED] USB 3.0 card, external drive and unknown algorithms » 2021-03-19 22:51:50

Altoid
Replies: 19

Hello:

Running up to date Devuan Beowulf 3.1.0:

groucho@devuan:~$ uname -a
Linux devuan 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux
groucho@devuan:~$ 

My Sun Ultra 24 box has six onboard USB 2.0 ports and I've added a 4 port USB 3.0 card to the empty PCIe 8x slot.
Card shows up in lspci:

groucho@devuan:~$ lspci
--- snip ---
04:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03)
--- snip ---
groucho@devuan:~$ 

dmesg finds it at USB5:

groucho@devuan:~$ sudo dmesg | grep -i "usb usb"
--- snip ---
[    3.187425] usb usb5: We don't know the algorithms for LPM for this host, disabling LPM.        <------------ | ? |
[    3.187444] usb usb5: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 4.19
[    3.187446] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.187447] usb usb5: Product: xHCI Host Controller
[    3.187448] usb usb5: Manufacturer: Linux 4.19.0-14-amd64 xhci-hcd
[    3.187449] usb usb5: SerialNumber: 0000:04:00.0
--- snip ---
groucho@devuan:~$ 

If I plug in an external USB3.0 HDD in any of the onboard USB2.0 ports , I get this in dmesg:

groucho@devuan:~$ sudo dmesg | tail -20
--- snip ---
[ 2090.462935] usb 6-5: new high-speed USB device number 4 using ehci-pci
[ 2090.624537] usb 6-5: New USB device found, idVendor=043e, idProduct=70f5, bcdDevice= 6.00
[ 2090.624541] usb 6-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2090.624544] usb 6-5: Product: LG External HDD
[ 2090.624547] usb 6-5: Manufacturer: LG Electronics Inc.
[ 2090.624549] usb 6-5: SerialNumber: A1204000000004C7
[ 2090.646562] usb-storage 6-5:1.0: USB Mass Storage device detected
[ 2090.646692] scsi host8: usb-storage 6-5:1.0
[ 2090.646818] usbcore: registered new interface driver usb-storage
[ 2095.346949] scsi 8:0:0:0: Direct-Access     Hitachi  HTS545050A7E     GG2O PQ: 0 ANSI: 2
[ 2095.347330] sd 8:0:0:0: Attached scsi generic sg6 type 0
[ 2095.351172] sd 8:0:0:0: [sdf] 976773164 512-byte logical blocks: (500 GB/466 GiB)
[ 2095.351792] sd 8:0:0:0: [sdf] Write Protect is off
[ 2095.351795] sd 8:0:0:0: [sdf] Mode Sense: 00 06 00 00
[ 2095.352416] sd 8:0:0:0: [sdf] No Caching mode page found
[ 2095.352419] sd 8:0:0:0: [sdf] Assuming drive cache: write through
[ 2095.384932]  sdf: sdf1
[ 2096.469187] sd 8:0:0:0: [sdf] Attached SCSI disk
groucho@devuan:~$ 

lsusb sees it:

groucho@devuan:~$ lsusb
Bus 006 Device 005: ID 043e:70f5 LG Electronics USA, Inc. External HDD
--- snip ---
groucho@devuan:~$ 

But ...

If I unplug it and plug into one of the USB3.0 card's ports, I don't get anything in dmesg ...

[ 2592.690873]  sdf: sdf1
[ 2593.767241] sd 8:0:0:0: [sdf] Attached SCSI disk
[ 3085.450843] usb 6-5: USB disconnect, device number 5

...  or lsusb.

Curiously enough, if I plug it into my Dell monitor's USB2.0 hub (plugged into one of the USB3.0 card's ports), dmesg sees it ...   

groucho@devuan:~$ sudo dmesg | tail -20
[ 2592.690873]  sdf: sdf1
[ 2593.767241] sd 8:0:0:0: [sdf] Attached SCSI disk
[ 3085.450843] usb 6-5: USB disconnect, device number 5

[ 3439.586951] usb 4-3.1: new high-speed USB device number 3 using xhci_hcd
[ 3439.694613] usb 4-3.1: New USB device found, idVendor=043e, idProduct=70f5, bcdDevice= 6.00
[ 3439.694617] usb 4-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3439.694620] usb 4-3.1: Product: LG External HDD
[ 3439.694622] usb 4-3.1: Manufacturer: LG Electronics Inc.
[ 3439.694625] usb 4-3.1: SerialNumber: A1204000000004C7
[ 3439.701034] usb-storage 4-3.1:1.0: USB Mass Storage device detected
[ 3439.701160] scsi host8: usb-storage 4-3.1:1.0
[ 3443.643398] scsi 8:0:0:0: Direct-Access     Hitachi  HTS545050A7E     GG2O PQ: 0 ANSI: 2
[ 3443.643741] sd 8:0:0:0: Attached scsi generic sg6 type 0
[ 3443.647507] sd 8:0:0:0: [sdf] 976773164 512-byte logical blocks: (500 GB/466 GiB)
[ 3443.648127] sd 8:0:0:0: [sdf] Write Protect is off
[ 3443.648132] sd 8:0:0:0: [sdf] Mode Sense: 00 06 00 00
[ 3443.648754] sd 8:0:0:0: [sdf] No Caching mode page found
[ 3443.648757] sd 8:0:0:0: [sdf] Assuming drive cache: write through
[ 3443.681214]  sdf: sdf1
[ 3444.749112] sd 8:0:0:0: [sdf] Attached SCSI disk
groucho@devuan:~$ 

... so does lsusb:

groucho@devuan:~$ lsusb
--- snip ---
Bus 004 Device 003: ID 043e:70f5 LG Electronics USA, Inc. External HDD
--- snip ---
groucho@devuan:~$ 

But as USBView says, it is working at USB2.0 speeds:

LG External HDD
Manufacturer: LG Electronics Inc.
Serial Number: A1204000000004C7
Speed: 480Mb/s (high)           <----
Bus:   4
Address:   3
USB Version:  2.10
Device Class: 00(>ifc )
Device Subclass: 00
Device Protocol: 00
Maximum Default Endpoint Size: 64
Number of Configurations: 1
Vendor Id: 043e
Product Id: 70f5
Revision Number:  6.00

The USB3.0 HDD drive works, the on board USB2.0 ports work, the USB3.0 card's ports work albeit through a hub and at USB2.0 speeds.
Thinking that there being a USB2.0 hub plugged into one of the card's ports, I unplugged it to check.
But nothing changed.

It would seem there is some sort of problem with the USB3.0 card working at USB3.0 speeds with USB3.0 devices.
Maybe it has to do with this line in dmsg?

[    3.187425] usb usb5: We don't know the algorithms for LPM for this host, disabling LPM.

Any ideas?

Thanks in advance,

A.

#1342 Re: Desktop and Multimedia » Thunar crashes on "Drag and Drop" » 2021-03-19 13:04:18

Hello:

dice wrote:

... using cinnamon desktop ...

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 ...

dice wrote:

... dont mind the extra ram usage and a bit of gnome ...

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.

#1343 Re: Desktop and Multimedia » Thunar crashes on "Drag and Drop" » 2021-03-19 01:04:14

Hello:

dice wrote:

... if the xfce4 compositor is the issue, maybe see what happens using compton ...

The issue is evidently xfce4 inter-component related.
And from what I have seen with how the 4.16 version is coming along, things won't get better.

It's a pity but that's how it is rolling these days.

So I won't insist with Thunar unless PCManFM ends up not being up to par and have to try something else.
I already have a parallel Beowulf installation that I am attempting to build up as what at one time #! Linux was, I really liked it.

Thanks a lot for your input.

Best,

A.

#1344 Re: Desktop and Multimedia » Thunar crashes on "Drag and Drop" » 2021-03-18 06:55:26

Hello:

dice wrote:

... using xfwm4 compositing from the tweaks dialog ...

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.

#1345 Re: Desktop and Multimedia » Thunar crashes on "Drag and Drop" » 2021-03-17 20:44:43

Hello:

dice wrote:

... play with mouse settings and see if this helps?

Does not make any difference, it is not a mouse problem.

Given my observations, I have concluded that this is a problem with thunar and how it interacts with compositing.
Maybe it is related to how Xfce intruments compositing?

The maintainers at gitlab.xfce.org first made a reference to my using " ... outdated versions of the various involved components (Thunar, GTK, X and xfwm4) ..."
They have told me me that no one else has reported it and had not been able to reproduce it.

On their suggestion, I also tried to get a backtrace but the gdb utility did not produce a stack on thread apply all bt full or bt.
Alternatively, running it as root completely froze my desktop and did not produce a stack either.

So there's evidently something wrong there.

So I will just get rid of thunar and stay with PCManFM.
It seems to work quite well and most importantly, does not crash under the same conditions thunar does.

Best,

A.

#1346 Re: Desktop and Multimedia » Thunar crashes on "Drag and Drop" » 2021-03-17 12:48:52

Hello:

An update on this post.

Altoid wrote:

I have come across a problem in thunar which consists of it crashing ...

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:

Note that, the bug reporter is using outdated versions of the various involved components (thunar, GTK, X and xfwm4), so it may be the case that this issue was fixed long ago.

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.

#1347 Re: Hardware & System Configuration » [SOLVED] fwts in for Devuan Beowulf » 2021-03-16 19:53:37

Hello:

rolfie wrote:

Try apt -f install ....

Didn't work.
Those packages do not seem to be in the Devuan Beowulf repositories.

Head_on_a_Stick wrote:
Altoid wrote:

Should I enable the Ubuntu repo?

No. You'll have to download the individual .debs from the Ubuntu repositories ...

I see ...

Seems there is a snap package which I distrust because of snap and a live version I can run from an SD card.
I think that's the best option for now.

Thanks for your input.

Best,

A.

#1348 Re: Hardware & System Configuration » [SOLVED] fwts in for Devuan Beowulf » 2021-03-16 19:08:10

Hello:

Head_on_a_Stick wrote:

... latest version would be best (fwts_18.03.00-0ubuntu5_amd64.deb).

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.

#1349 Re: Hardware & System Configuration » [SOLVED] fwts in for Devuan Beowulf » 2021-03-16 17:23:45

Hello:

Head_on_a_Stick wrote:

I think the latest version would be best (fwts_18.03.00-0ubuntu5_amd64.deb).

Right, thank you.

Head_on_a_Stick wrote:

... fix things with acpica-tools instead.
See https://wiki.archlinux.org/index.php/DSDT for an overview of the technique.

Thanks, I'll have a look at that.
I know how and have been able to load an alternate DSDT, modified to be able to re-compile with no errors vis-a-vis the 30+ errors the original DSDT has.
It turned out to be rather tricky because different version of the Intel compiler produce different results on errors and warnings.

For this specific BIOS I settled on the one that supports ACPI Specification Revision 6.2A.

The catch is that I have not been able to solve the problems I describe in my previous post and it seems that the fwst application may shed some light on it as it has a number of tests to run and (try) to debug the BIOS/tables.

Head_on_a_Stick wrote:

... submit a bug report with your findings so that the upstream kernel developers can make things work for everybody else.

Of course I will.
But to be honest, I don't expect anything much.

I wrote about this in 2019, a comment on a previous bug report in 2018:
https://bugzilla.kernel.org/show_bug.cgi?id=201965
No answers or fixes upstream.

A chap found a solution for a similar problem with a relatively new (?) Asus board.
He posted his findings here:
https://bugzilla.kernel.org/show_bug.cgi?id=210689 
No answers either.

He then saw my post, wrote to me about his findings and got me started on this again, after a couple of years.
I used his DSDT data on mt tables but was not able to solve my problem.

I'm aware that I have the perfect combination: 10 year old + unmaintained hardware + non-existent OEM.
If you add that Sun evidently employed untrained monkeys to write this BIOS ...

rant
ie: how is it possible that a top of the line Sun WS worth US$1800/2300 in 2007 had a BIOS reporting it as "portable"?
A bug that was never fixed in later BIOS versions?
/rant

Thanks for your input.

Best,

A.

#1350 Re: Hardware & System Configuration » [SOLVED] Strange gparted situation » 2021-03-16 16:06:23

Hello:

Head_on_a_Stick wrote:
Altoid wrote:

Any idea as to what may have caused it?

... an ISO image was burned to the device at some point. The magic string laid down by that process can be very persistent.

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.

Board footer

Forum Software