lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ