From: Michael <confabulate@kintzios.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Problem with detecting ZFS HDD
Date: Mon, 03 Mar 2025 09:55:25 +0000 [thread overview]
Message-ID: <3272059.5fSG56mABF@rogueboard> (raw)
In-Reply-To: <CA+t6X7cvneMM65KcHo8xZAsYGxKAxm=2oy=wYu0H1mbkJVGZBw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5670 bytes --]
On Sunday, 2 March 2025 21:58:15 Greenwich Mean Time gevisz wrote:
> вс, 16 февр. 2025 г. в 18:51, Wols Lists <antlists@youngman.org.uk>:
> > On 01/02/2025 00:13, gevisz wrote:
> > > The problem is that after booting with an additional HDD,
> > > one of these ZFS HDDs does not report any of its disk id:
> > > nor wwn neighter in the form ata-WDC_WD5000*.
> > >
> > >>> The situation remained the same even after swapping the
> > >>> undetected 500GB WD HDD with the one.
> > >
> > > And now, this makes me think that the problem is indeed with the SATA
> > > port.
> >
> > I know I'm very late to the party but ...
> >
> > As linux boots, it will allocate an sd* address to all the drives it
> > sees. So if you've got three drives, but only sda and sdb, then one of
> > them hasn't been detected.
> >
> > Seeing as /dev/disk/by-id is only a symlink to /dev/sda, /dev/sdb etc,
> > from what you say I suspect you won't see the relevant sdx entry in /dev
> > That to me seems the obvious way to do things - linux assigns a "random"
> > name to the device, so it can read the device, and then symlinks the
> > device name to whatever random code got assigned initially.
> >
> > As to why, do you have a manual for your mobo? It's an unfortunate fact
> > (and I don't know when it started) that a lot of SATA ports nowadays
> > don't work a lot of the time. When I was looking for a mobo, there was a
> > lot of "if you stick an NVMe in, it will disable SATA4" or whatever.
> > Likewise, if you used an external graphics card, depending on what PCIe
> > it was, it might disable certain SATA ports. Given that I wanted about
> > six *working* sata ports, that was a pain in the proverbial!
> >
> > Basically, a lot of things nowadays run over the PCIe bus, and it's very
> > common for (a) lanes to be shared between different devices, and (b)
> > there's a pecking order - if multiple devices share a lane, only the
> > highest up the pecking order will work.
> >
> > So of course, sods law probably says you can't even get a SATA expansion
> > board, because that will require the hijacked lane and won't work ...
With marketing names changing faster than the seasons it is not always easy to
understand from a MoBo manual what's what. It may take some digging in old
reviews and diagrams of the CPU architecture to bottom out what components are
driven by the CPU, the Northbridge (NB) via the Front Side Bus (FSB), or the
slower Southbridge (SB). Normally the PCIe bus or AGP would be hooked off the
NB to attain a higher throughput to the CPU/RAM. IDE/ATA/SATA/PCI would be
driven off the SB. As CPUs became faster the FSB to the MoBo chipset became a
bottleneck, so components started being incorporated into the CPU.
> Thank you for your insight.
>
> Probably, after using my Gigabyte GA-MA790FXT-UD5P
> motherboard for almost 20 years, I indeed should read its manual. :)
>
> After all, "if nothing else helps, try to read the manual." :)
>
> Will do it in the nearest future, but I doubt that it says something
> about this issue.
>
> However, I think that you are right and the problem lies in the motherboard.
It should hopefully hint as to where SATA ports are connected to on the MoBo.
PCIe driven SATA via a SATA bus controller may be faster than some SB chip, if
only marginally so.
As already mentioned the PCIe bus may be sharing lanes between components
which could cause drives to disappear, or lose their expected speed.
> By the way, for years, I have had another issue with it that confirms your
> point of view: if I start my computer with a Logitech USB video camera
> plugged in, I randomly do not have a sound out. By "randomly" I mean
> that sometimes the sound out may be present and sometimes not.
>
> I have tried everything and even started a thread about it here, but
> nothing helped.
>
> Finally, I used to start my computer without my USB video camera
> plugged in, and it guarantees the presence of an audio after booting.
Only recently, in the age of pipewire and wireplumber, I noticed something
similar. If I am playing a video on a browser and at the same time try to
play another video on mpv, the mpv remains silent until I stop/close the
browser. :-/
> Additional information: I have AMD/ATI RV740 PRO [Radeon HD 4770]
> video card plugged into PCIEX16_1 slot and (never used) "brackets",
> one of which is connected to F_AUDIO and the other is connected to a SATA
> port.
>
> The manual also says that my motherboard has 6 SATA ports working
> via South Bridge and 4 SATA ports working via another Gigabyte SATA chip.
OK, the SB chipset is the conventional way to hook drives, while the 4 SATA
ports driven off the PCIe via a SATA controller chip were provided to fulfil a
user need for MOAR disks because ... MOAR data. Theoretically, the MoBo OEMs
would have matched the PCIe Vs SB generations and throughput, but when every
port is occupied I expect you would notice small throughput differences in
benchmarks. However, this does not explain why a whole drive decides to go
AWOL, *unless* the MoBo manual provides an explicit statement to this effect.
For example, this MoBo claims to lose one SATA port when an M.2 connected
drive is also operated in SATA mode:
https://www.asus.com/support/faq/1044083/
> Maybe, I have to experiment with connecting my hard drives to SATA
> ports in different order...
I'd start with the manual, Gigabyte's support pages and reviews/benchmarks, to
bottom out what are the real-world limits of your board.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2025-03-03 9:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-30 16:55 [gentoo-user] Problem with detecting ZFS HDD gevisz
2025-01-30 17:03 ` [gentoo-user] " gevisz
2025-01-30 21:08 ` [gentoo-user] " Grant Taylor
2025-01-30 22:58 ` gevisz
2025-01-31 0:13 ` Grant Taylor
2025-01-31 11:24 ` Michael
2025-02-01 0:13 ` gevisz
2025-02-16 16:50 ` Wols Lists
2025-03-02 21:58 ` gevisz
2025-03-03 9:55 ` Michael [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3272059.5fSG56mABF@rogueboard \
--to=confabulate@kintzios.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox