[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFdVvOz9=wuxeH6nUkmSMRe0vxDRL-b62aaLg_4uaXWD9kK8cA@mail.gmail.com>
Date: Tue, 15 Aug 2023 08:45:13 -0600
From: Sathya Prakash Veerichetty <sathya.prakash@...adcom.com>
To: emanoil.kotsev@...optes.org
Cc: linux-scsi@...r.kernel.org, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: SSD SATA 3.3 and Broadcom / LSI SAS1068E PCI-Express Fusion-MPT SAS
This has nothing to do with the driver and would require analysis from
the controller hardware/firmware perspective. The 1068 chip is pretty
old and out of support and it will be difficult to get any analysis
done on that. If you want to upgrade, the latest 12G SAS-NVMe Tri
Mode controllers are better from a long term support perspective.
https://www.broadcom.com/products/storage/host-bus-adapters.
Thanks.
On Tue, Aug 15, 2023 at 3:41 AM deloptes <emanoil.kotsev@...optes.org> wrote:
>
> Bjorn Helgaas wrote:
>
> > I don't know why that would be. Are there any hints in the dmesg log?
> > Can you collect the complete dmesg log with the old drives and again
> > with the new SSDs so we can compare them? I assume you have good
> > cables? I assume the same cables worked at 3.0 Gb/s with the old
> > drives.
> >
> > I would *expect* that SATA r3.3 would be completely backwards
> > compatible, so since mptsas worked just fine at 3.0 Gb/s with the old
> > SATA r3.0 drives, it should also work just fine at 3.0 Gb/s with the
> > new SATA r3.3 drives. But I have no actual knowledge about that.
>
> Thank you for your answer. I am also confused and couldn't think of any
> meaningful reason. This is why I allowed myself to bother you.
>
> I did not change anything - wiring or such. The server has 12 disk bays on
> the front. Old disks were pulled out and new disks were inserted into the
> bays.
>
> You (probably much knowable in this matters than me) also assume negotiation
> should result in 3.0Gb/s. And if I understand correctly it should be not a
> driver issue.
>
> The only difference I could find out for now is that Rev3.3 introduced PWDIS
> on Pin 3. To check if the cables provide wiring on P3 I should disassemble
> the server, but I can do this in September :/ and it is a lot of effort.
>
> I am attaching a portion of the log and dmesg with the relevant information.
> I see that ASPM is disabled by default (could it be related to P3?).
>
> Thank you all in advance
> BR
>
> --
> FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4227 bytes)
Powered by blists - more mailing lists