From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: unsolvable technical issues?
Date: Tue, 3 Jul 2018 07:54:14 -0400 [thread overview]
Message-ID: <0ef3c37b-d8a3-2134-d39e-5aa7605c498c@gmail.com> (raw)
In-Reply-To: <pan$f3f7b$53185d9e$ee073b92$d7d590bf@cox.net>
On 2018-07-03 03:35, Duncan wrote:
> Austin S. Hemmelgarn posted on Mon, 02 Jul 2018 07:49:05 -0400 as
> excerpted:
>
>> Notably, most Intel systems I've seen have the SATA controllers in the
>> chipset enumerate after the USB controllers, and the whole chipset
>> enumerates after add-in cards (so they almost always have this issue),
>> while most AMD systems I've seen demonstrate the exact opposite
>> behavior,
>> they enumerate the SATA controller from the chipset before the USB
>> controllers, and then enumerate the chipset before all the add-in cards
>> (so they almost never have this issue).
>
> Thanks. That's a difference I wasn't aware of, and would (because I tend
> to favor amd) explain why I've never seen a change in enumeration order
> unless I've done something like unplug my sata cables for maintenance and
> forget which ones I had plugged in where -- random USB stuff left plugged
> in doesn't seem to matter, even choosing different boot media from the
> bios doesn't seem to matter by the time the kernel runs (I'm less sure
> about grub).
>
Additionally though, if you in some way make sure SATA drivers are
loaded before USB ones, you will also never see this issue because of
USB devices (same goes for GRUB). A lot of laptops that use connections
other than USB for the keyboard and mouse behave like this if you use a
properly stripped down initramfs because you won't have USB drivers in
the initramfs (and therefore the SATA drivers always load first).
next prev parent reply other threads:[~2018-07-03 11:54 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-21 23:13 unsolvable technical issues? waxhead
2018-06-22 2:39 ` Chris Murphy
2018-06-27 18:50 ` waxhead
2018-06-28 14:46 ` Adam Borowski
2018-06-22 5:48 ` Nikolay Borisov
2018-06-23 22:01 ` waxhead
2018-06-24 3:55 ` Jukka Larja
2018-06-24 8:41 ` waxhead
2018-06-24 15:06 ` Ferry Toth
2018-06-23 5:11 ` Duncan
2018-06-24 20:22 ` Goffredo Baroncelli
2018-06-25 11:26 ` Austin S. Hemmelgarn
2018-06-30 3:22 ` Duncan
2018-06-30 5:32 ` Andrei Borzenkov
2018-07-02 11:49 ` Austin S. Hemmelgarn
2018-07-03 7:35 ` Duncan
2018-07-03 11:54 ` Austin S. Hemmelgarn [this message]
2018-07-02 11:44 ` Austin S. Hemmelgarn
2018-06-25 14:20 ` David Sterba
2018-06-25 13:36 ` David Sterba
2018-06-25 16:43 ` waxhead
2018-06-25 16:54 ` Hugo Mills
2018-06-30 3:59 ` Duncan
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=0ef3c37b-d8a3-2134-d39e-5aa7605c498c@gmail.com \
--to=ahferroin7@gmail.com \
--cc=linux-btrfs@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).