Scott Colby wrote:
> Well, I spent some more time reading dmesg logs and messing around in
> the BIOS. I enabled SR-IOV [1] and the drives appeared! I'm not
> entirely sure _why_ this worked,
Yes, me neither. Maybe that option also changed something in the
background as well.
> but at this poi
Well, I spent some more time reading dmesg logs and messing around
in the BIOS. I enabled SR-IOV [1] and the drives appeared! I'm not
entirely sure _why_ this worked, but at this point (it's been over
a week of messing with this), I'm a bit tired of looking. If anyone
has thoughts on why this chang
On Wed, Nov 25, 2020, at 05:04, Sven Hartge wrote:
> Hmm. The controller at 49:00.0 is missing here. Could it be hosting the
> missing drives?
Good catch! I did some more investigation with verbose lspci output,
here's the diff between 48:00.0 and 49:00.0:
1c1
< 48:00.0 SATA controller [0106]: Ad
Scott Colby wrote:
> On Tue, Nov 24, 2020, at 02:40, Sven Hartge wrote:
>> Which would mean that the Kernel does not have a driver for the chip
>> driving SATA0_3 as it seems.
> Makes sense.
>> Can you provide more information, for example a lspci listing?
> No problem, here you go, with apolo
Hi Sven, thanks for the response!
On Tue, Nov 24, 2020, at 02:40, Sven Hartge wrote:
> Which would mean that the Kernel does not have a driver for the chip
> driving SATA0_3 as it seems.
Makes sense.
> Can you provide more information, for example a lspci listing?
No problem, here you go, with
Scott Colby wrote:
> In all cases, the behavior was the same: all expected drives are
> reported in the firmware, and the drives attached to SATA4_7 show
> up in the OS (sd{a,b,c,d}), but the others are absent.
Which would mean that the Kernel does not have a driver for the chip
driving SATA0_3
6 matches
Mail list logo
