Big harddrive doesn't work (reported 1TB instead of 4TB)

[pa4wdh]

Sorry for my late follow-up, life of in the way

I've upgraded one of my other systems to kernel 6.1.19 and the USB-SATA bridge works fine without any patches. That brings it back to differences in config.
I'm now changing my new config to take away one difference at the time and see when things start working. It does quite a while because some settings trigger a full recompile of the kernel .
I also noticed the gcc version is different, but i don't expect that would result in a problem like this.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com

[NeddySeagoon]

pa4wdh,

You need to use a binary search.

Include half the changes in a kernel build.
If the problem has gone, it was caused by something in the removed half.
If it remains, it's in the half that you kept.

Apply the process recursively until only one option is left.
10 kernel builds lets you search 1024 option changes.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[pa4wdh]

Well, i just did another test with turned different than i expected ...

First i copied the binary kernel from a working system to the not working system, just to verify it still works and it did. The drive is properly detected.
Then i used the kernel config from the working system and recompiled the kernel on the not working system with that configuration. That didn't work, the drive is detected as 1TB again.

The only difference between those two is the GCC version it's compiled with, so i'll see if i can downgrade from gcc 12 to gcc 11.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com

[pietinger]

[pa4wdh]

Thanks for the suggestion. The systems' BIOS is rather minimal, there are no settings regarding to storage or USB that point in this direction. Also, BIOS settings didn't change between the working binary kernel and the recompiled kernel with the same configuration.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com

[Anon-E-moose]

Do you have both the usb2 and usb3 connectors plugged in? (The manual mentions that both can't be connected at the same time)
(I believe it's j9 and j10)
It doesn't say what happens if both are connected at the same time (either inconsistent results or doesn't work at all)

Other than that, if anything in the bios affects it, it would be in the usb area.


Edit to add: never mind - what I linked to was wrong.

Did you originally have UAS turned off on the "bad" machine? If not recompile with UAS completely turned off.
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland

[logrusx]

[pa4wdh]

[Anon-E-moose]

Given that there are no obvious problems, I can only assume that jmicron (enclosure) and intel usb chipset don't work well together.
And it's not that it doesn't work it just needs the quirk for it to work right.
I've had motherboards in the past where I couldn't use some usb devices fully, and had to use the quirk files to get around problems.

At this point, I would leave the quirk, and just use the drive (as long as it keeps working).

Edit to add: this is from the scsiglue.c file in usb/storage

[pa4wdh]

I understand the quirk is a way to solve this. There are also a few reasons to assume it only to work around a symptom of other problems:
- The drive/bridge has been working without the quirk for years on many different systems
- With a different kernel config and compiled with gcc 11 it works correctly with on hardware where it initially misbehaved
- The comment in scsiglue.c mentions "capacity modulo 2TB" which is not the case with my problem: 4TB modulo 2TB should be either close to 0 or close to 2TB depending on the exact numbers, my drive reports 1TB
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com

[Anon-E-moose]

[pa4wdh]

It has even been working on the "bad machine" with a kernel build on that system with gcc 11 (reported a few posts back), it doesn't get better than that . It's just that the rest of the used config is not tuned to that PC, so i'd like to find out which setting it is that makes the difference.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com

[pa4wdh]

It took me quite some steps, and quite some time because most of the changes triggered a full rebuild of the kernel.

The offending setting is: CONFIG_PM which has to be not set. I would never have guessed that.

Now knowing this, especially in drivers/usb there is a lot of code for CONFIG_PM and CONFIG_PM_SLEEP, so that somewhat makes sense.

Edit:
I've done two additional tests:
1) Reverted back to the original config i started this topic with, only changed CONFIG_PM and recompiled with gcc 11. This worked and drive is detected properly.
2) Using the config from the previous step, i switched my compiler to gcc 12 again. This also worked and the drive is detected properly.

I don't really understand where the gcc thing came from, but now it seems that only CONFIG_PM was the cause of the problems.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com