Summary: | [patch] ahci driver problems with Marvell 88SE9230 (Dell BOSS-S1) | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Peter Eriksson <pen> | ||||||||||||
Component: | kern | Assignee: | Dave Cottlehuber <dch> | ||||||||||||
Status: | Closed FIXED | ||||||||||||||
Severity: | Affects Some People | CC: | dch, ebay, emaste, f.sidoli, fluor, imp, jasonmader, kirill, lopez.on.the.lists, mav, tcs | ||||||||||||
Priority: | --- | Keywords: | patch | ||||||||||||
Version: | 13.1-RELEASE | ||||||||||||||
Hardware: | Any | ||||||||||||||
OS: | Any | ||||||||||||||
URL: | https://reviews.freebsd.org/D37585 | ||||||||||||||
Attachments: |
|
Description
Peter Eriksson
2020-01-16 21:32:33 UTC
Cc: most involved committers with AHCI to ask for quick review. Hi Peter, FWIW, I'm also having this same issue on a PE R740xd2 server with the BOSS-S1. In my particular case, I have the BOSS (in JBOD) and a H730P PERC (in HBA mode)installed. I wanted to replace the latter with an HBA330 as I can't encrypt the disks at the disk level (they're SEDs) without the PERC locking them out and not passing them through to the OS on power cycle. Anyway, with the HBA installed the system partially boots and then fails, but it does just fine with the RAID card put back in. If I try to do a fresh install with the HBA in then I can't see the BOSS cards at all, so can't install to them. With the RAID card in there's no problem. If I firmware patch the BOSS to latest the system just doesn't boot at all regardless of which card I have in. Quite what this all means I don't know. I'm not sure if it's a driver issues in FreeNAS or if Dell are breaking things. I suspect a little bit of A and a little bit of B. That being said, I have been told by Dell that one of their engineers has managed to get a test system of theirs set up running the latest BOSS firmware and FreeNAS 11.3. Seems to me they have the BOSS in a RAID 1 and the legacy BIOS option set. Once verified I will repost here. Just a quick note that this issue is still present in FreeBSD 12.2 and with the latest Dell BOSS-S1 firmware (A07 / 2.5.13.3024) With a configured RAID volume it works - but not with "raw" disks - they just don't show up. This makes it impossible to use the BOSS disks for ZFS-mirrored boot/root pools (Since it only supports one RAID volume that can be RAID 0 or RAID 1). - Peter Created attachment 220793 [details]
Patch for AHCI driver to make Dell BOSS-S1 detect unconfigure disks
Please find enclosed a patch that makes (atleast on my Systems) FreeBSD 12.2 detect unconfigured disks on a Dell BOSS-S1 card running the latest Dell firmware (v7).
The patch basically increases the time limit for the loop when initializing/probing the card for devices. It seems with firmware v5 and later the card takes a lot longer to detect disks after a reset.
The patch also adds a "debug.ahci_verbose" flag and adds some more verbose prints so one can "follow" what happens at probe time.
With firmware v4 (and an older version of the patch without modified timeouts) the probing looks like this:
ahcich14: AHCI reset...
ahcich14: SATA status changed 00000133
ahcich14: SATA connect time=0us status=00000133
ahcich14: AHCI reset: device found
ahcich14: AHCI reset: device ready after 0ms
ahcich15: AHCI reset...
ahcich15: SATA status changed 00000133
ahcich15: SATA connect time=0us status=00000133
ahcich15: AHCI reset: device found
ahcich15: AHCI reset: device ready after 0ms
ahcich16: AHCI reset...
ahcich16: SATA status changed 00000113
ahcich16: SATA connect time=0us status=00000113
ahcich16: AHCI reset: device found
ahcich16: AHCI reset: device ready after 0ms
With the latest firmware and this patch in use:
ahci2: <Marvell 88SE9230 AHCI SATA controller> port 0x7028-0x702f,0x7034-0x7037,0x7020-0x7027,0x7030-0x7033,0x7000-0x701f mem 0xab200000-0xab2007ff at device 0.0 numa-domain 0 on pci6
ahci2: AHCI v1.20 with 3 6Gbps ports, Port Multiplier not supported
ahci2: quirks=0x200900<NOBSYRES,ALTSIG,MRVL_SR_DEL>
ahci2: Caps: 64bit NCQ 6Gbps PMD 32cmd 3ports
ahci2: Caps2:
ahcich14: <AHCI channel> at channel 0 on ahci2
ahcich14: Caps: CPD
ahcich15: <AHCI channel> at channel 1 on ahci2
ahcich15: Caps: CPD
ahcich16: <AHCI channel> at channel 2 on ahci2
ahcich16: Caps: CPD
ahcich14: AHCI reset...
ahcich14: SATA status changed 00000000
ahcich14: SATA status changed 00000001
ahcich14: SATA status changed 00000133
ahcich14: SATA connect timeout time=212300us status=00000133
ahcich14: AHCI reset: device not found
ahcich15: AHCI reset...
ahcich15: SATA status changed 00000000
ahcich15: SATA status changed 00000001
ahcich15: SATA status changed 00000133
ahcich15: SATA connect timeout time=212000us status=00000133
ahcich15: AHCI reset: device not found
ahcich16: AHCI reset...
ahcich16: SATA status changed 00000000
ahcich16: SATA status changed 00000113
ahcich16: SATA connect time=100us status=00000113
ahcich16: AHCI reset: device found
ahcich16: AHCI reset: device ready after 0ms
ahcich16: stopping AHCI engine failed
pass2 at ahcich16 bus 0 scbus18 target 0 lun 0
pass2: <Marvell Console 1.01> Removable Processor SCSI device
pass2: Serial Number HKDP221516WL
pass2: 150.000MB/s transfers (SATA 1.x, UDMA4, ATAPI 12bytes, PIO 8192bytes)
ada0 at ahcich14 bus 0 scbus16 target 0 lun 0
ada0: <MTFDDAV480TDS D3DJ004> ACS-4 ATA SATA 3.x device
ada0: Serial Number 202729652D1E
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 457862MB (937703088 512 byte sectors)
ada1 at ahcich15 bus 0 scbus17 target 0 lun 0
ada1: <MTFDDAV480TDS D3DJ004> ACS-4 ATA SATA 3.x device
ada1: Serial Number 202729652D52
ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 457862MB (937703088 512 byte sectors)
pass4 at ahcich16 bus 0 scbus18 target 0 lun 0
pass4: <Marvell Console 1.01> Removable Processor SCSI device
pass4: Serial Number HKDP221516WL
pass4: 150.000MB/s transfers (SATA 1.x, UDMA4, ATAPI 12bytes, PIO 8192bytes)
(It still claims no device found but they do show up anyway so the patch probably needs some more fine-tuning, but atleast one can access the disks now...)
Note the: "time=212300us"
Peter, your patch is inconsistent in the timeout values. You are using 10000 on line 2614, but 5000 on lines 2634 and 2638. That discrepancy may potentially cause random weird effects. Though it does not explain to me what I see in the provided messages. I can not match it to the patch provided. I guess you was running something different. Also synchronous wait for half a second for every empty port in a system is not great. JFYI IIRC VMware emulates AHCI with 31 port. Have you tried to measure time between "SATA status changed 00000000" and "SATA status changed 00000001" messages? It it happen faster it would allow to not increase the timeout on line 2634, not waiting for devices on completely empty ports. Yes, I've since changed my patch a bit so that it: Only sets the timeout to 5000 (from 1000) if: 1) quirk AHCI_Q_SLOWDEV (a new one) is set - only set on the Marvell 88SE9230 2) only does this _after_ the first status change occurs (0x0000000 -> 0x00000001) Now the trace looks something like this (some more debugging prints added): ahcich14: AHCI reset... ahcich14: AHCI engine: stopping ahcich14: stopping AHCI engine: ci: -1 -> 0 at time 10us ahcich14: stopping AHCI engine: sact: -1 -> 0 at time 10us ahcich14: stopping AHCI engine: ccs: -1 -> 0 at time 10us ahcich14: stopping AHCI engine: cr: -1 -> 0 at time 10us ahcich14: AHCI engine stopped at time 10us ahcich14: SATA changed status 0x00000000 -> 0x00000001 at time=100us ahcich14: SATA changed status 0x00000001 -> 0x00000133 at time=212500us ahcich14: SATA connect status 0x00000133 at time=212500us ahcich14: AHCI reset: device found ahcich14: AHCI reset: device ready after 0ms ahcich14: AHCI engine(fbs=1): starting ahcich15: AHCI reset... ahcich15: AHCI engine: stopping ahcich15: stopping AHCI engine: ci: -1 -> 0 at time 10us ahcich15: stopping AHCI engine: sact: -1 -> 0 at time 10us ahcich15: stopping AHCI engine: ccs: -1 -> 0 at time 10us ahcich15: stopping AHCI engine: cr: -1 -> 0 at time 10us ahcich15: AHCI engine stopped at time 10us ahcich15: SATA changed status 0x00000000 -> 0x00000001 at time=100us ahcich15: SATA changed status 0x00000001 -> 0x00000133 at time=221400us ahcich15: SATA connect status 0x00000133 at time=221400us ahcich15: AHCI reset: device found ahcich15: AHCI reset: device ready after 0ms ahcich15: AHCI engine(fbs=1): starting ahcich16: AHCI reset... ahcich16: AHCI engine: stopping ahcich16: stopping AHCI engine: ci: -1 -> 0 at time 10us ahcich16: stopping AHCI engine: sact: -1 -> 0 at time 10us ahcich16: stopping AHCI engine: ccs: -1 -> 0 at time 10us ahcich16: stopping AHCI engine: cr: -1 -> 0 at time 10us ahcich16: AHCI engine stopped at time 10us ahcich16: SATA changed status 0x00000000 -> 0x00000113 at time=100us ahcich16: SATA connect status 0x00000113 at time=100us ahcich16: AHCI reset: device found ahcich16: AHCI reset: device ready after 0ms ahcich16: AHCI engine(fbs=1): starting Btw, I've been testing some different variants of settings for this controller - for example I removed the quirk (ALTSIG) to see if that would make any difference but it doesn't seem to matter if it's set or not. Anyone know where that quirk comes from? I'll upload a cleaned up version of an improved patch soon. Btw, I noticed one other little thing while reading the source code for ahci.c: ahci_start(ch, fbs) gets called with fbs=1 in all spots in the code, except one spot in ahci_execute_transaction() around line 1650 or so when it receives an ATA_A_RESET - then it sets fbs to 0 (zero). If I'm reading the code correctly then this would cause "FIS-based switched" to be disabled from that time on - if that ever happens? Just for testing I changed that to 1 - but I don't see much of a difference in behaviour. Granted I haven't tested _that_ much. Probably unrelated to this issue anyway. I still see the patch from December 21. Where is the updated version? It is good that DEV_PRESENT is reported fast enough. It allows to not increase timeout in case of device absent and so I am thinking about just increasing the timeout slightly instead of adding the quirk. ALTSIG quirk was required by some early Marvell controllers or firmware versions. I haven't retested it on recent ones, it may no longer be required. I don't remember why I have disabled the FBS there, its being a while ago. My guess is to avoid other commands from trying to execute during soft reset. If you look lower, you'll see "Kick controller into sane state and enable FBS." comment, which should call ahci_start(ch, 1) on line 2121 after soft reset complete. PS: Why do you need AHCI-specific verbosity tunable? Why not just enable it globally? Sorry, have been busy with another problem (a HP server with a lot of disks panic:ing due to bugs in other parts of the kernel - sigh). I'll get back with a better patch soon. Anyway, the way I changed it was basically to chnage the loop: 1. DELAY(10) instead of DELAY(100) - it takes about 30us for status to change from 0 -> 1, so no need to wait the full 100us :-) 2. Only change the "full timeout" from 100ms to 500ms after ATA_SS_DEV_MASK has changed from ATA_SS_DET_NO_DEVICE. My current version of the patch contains a lot of debuging printouts so probably not really good for production use (it makes it easier to watch what's happening though :-) A sample of the dmesg output: First an ununes ahci channel/controller without devices: ahcich13: AHCI engine: stopping ahcich13: stopping AHCI engine: cr: 1 -> 0 at time 10 us ahcich13: AHCI engine stopped at time 10 us ahcich13: ahci_sata_phy_reset: Start ahcich13: ahci_sata_connect: Start ahcich13: SATA connect timeout status 0x00000000 at time=10000us ahcich13: ahci_sata_connect: Done (0) ahcich13: ahci_sata_phy_reset: Done (0) ahcich13: AHCI reset: device not found ahcich13: ahci_reset: Done (ahci_sata_phy_reset failed) First port on the BOSS: ahcich14: ahciaction: Calling ahci_reset (XPT_RESET_BUS) ahcich14: ahci_reset: Start ahcich14: AHCI reset... ahcich14: AHCI engine: stopping ahcich14: stopping AHCI engine: cr: 1 -> 0 at time 10 us ahcich14: AHCI engine stopped at time 10 us ahcich14: ahci_sata_phy_reset: Start ahcich14: ahci_sata_connect: Start ahcich14: SATA changed status 0x00000000 -> 0x00000001 at time=30us ahcich14: SATA changed status 0x00000001 -> 0x00000133 at time=211790us ahcich14: SATA connect status 0x00000133 at time=211790us ahcich14: ahci_sata_connect: Done (1) ahcich14: ahci_sata_phy_reset: Done (1) ahcich14: AHCI reset: device found ahcich14: AHCI reset: device ready after 0ms ahcich14: AHCI engine(fbs=1): starting ahcich14: ahci_start: Done ahcich14: ahci_reset: Done Then it resets the second port/channel (and starts doing stuff on the first port at the same time): ahcich15: ahciaction: Calling ahci_reset (XPT_RESET_BUS) ahcich15: ahci_reset: Start ahcich15: AHCI reset... ahcich15: AHCI engine: stopping ahcich15: stopping AHCI engine: cr: 1 -> 0 at time 10 us ahcich15: AHCI engine stopped at time 10 us ahcich15: ahci_sata_phy_reset: Start ahcich14: ahci_execute_transaction: Kicking controller into sane state ahcich14: AHCI engine: stopping ahcich14: stopping AHCI engine: cr: 1 -> 0 at time 10 us ahcich14: AHCI engine stopped at time 10 us ahcich14: ahci_clo: Start ahcich14: ahci_clo: Done ahcich14: AHCI engine(fbs=0): starting ahcich14: ahci_start: Done ahcich15: ahci_sata_connect: Start ahcich15: SATA changed status 0x00000000 -> 0x00000001 at time=30us ahcich14: ahci_end_transaction: Reinit port (eslots=00000004) ahcich14: AHCI engine: stopping ahcich15: SATA changed status 0x00000001 -> 0x00000133 at time=220650us ahcich15: SATA connect status 0x00000133 at time=220650us ahcich15: ahci_sata_connect: Done (1) ahcich15: ahci_sata_phy_reset: Done (1) ahcich15: AHCI reset: device found ahcich15: AHCI reset: device ready after 0ms ahcich15: AHCI engine(fbs=1): starting ahcich15: ahci_start: Done ahcich15: ahci_reset: Done And then the third (ses?) port - there is only two ports on this controller: ahcich16: ahciaction: Calling ahci_reset (XPT_RESET_BUS) ahcich16: ahci_reset: Start ahcich16: AHCI reset... ahcich16: AHCI engine: stopping ahcich16: stopping AHCI engine: cr: 1 -> 0 at time 10 us ahcich16: AHCI engine stopped at time 10 us ahcich16: ahci_sata_phy_reset: Start ahcich16: ahci_sata_connect: Start ahcich16: SATA changed status 0x00000000 -> 0x00000113 at time=70us ahcich16: SATA connect status 0x00000113 at time=70us ahcich16: ahci_sata_connect: Done (1) ahcich16: ahci_sata_phy_reset: Done (1) ahcich16: AHCI reset: device found ahcich16: AHCI reset: device ready after 0ms ahcich16: AHCI engine(fbs=1): starting ahcich16: ahci_start: Done ahcich16: ahci_reset: Done But then things are a bit strange - notice the 1s timeouts (I increased the max timeout to 1s in this test boot): Root mount waiting for: CAM usbus0 uhub0: 26 ports with 26 removable, self powered ahcich14: stopping AHCI engine: timeout at 1000000 us (cr=1, ccs=0, ci=0, sact=0) ahcich14: ahci_clo: Start ahcich14: ahci_clo: Done ahcich14: AHCI engine(fbs=1): starting ahcich14: ahci_start: Done ahcich15: ahci_execute_transaction: Kicking controller into sane state ahcich15: AHCI engine: stopping ugen0.2: <Kingston DataTraveler 2.0> at usbus0 umass0 numa-domain 0 on uhub0 umass0: <Kingston DataTraveler 2.0, class 0/0, rev 2.00/1.00, addr 1> on usbus0 umass0: SCSI over Bulk-Only; quirks = 0xc000 umass0:20:0: Attached to scbus20 Root mount waiting for: CAM usbus0 ahcich15: stopping AHCI engine: timeout at 1000000 us (cr=1, ccs=0, ci=0, sact=0) ahcich15: ahci_clo: Start ahcich15: ahci_clo: Done ahcich15: AHCI engine(fbs=0): starting ahcich15: ahci_start: Done ahcich15: ahci_end_transaction: Reinit port (eslots=00000004) ahcich15: AHCI engine: stopping ugen0.3: <vendor 0x1604 product 0x10c0> at usbus0 uhub1 numa-domain 0 on uhub0 uhub1: <vendor 0x1604 product 0x10c0, class 9/0, rev 2.00/0.00, addr 2> on usbus0 Root mount waiting for: CAM usbus0 ahcich15: stopping AHCI engine: timeout at 1000000 us (cr=1, ccs=0, ci=0, sact=0) ahcich15: ahci_clo: Start ahcich15: ahci_clo: Done ahcich15: AHCI engine(fbs=1): starting ahcich15: ahci_start: Done ahcich15: ahci_execute_transaction: Kicking controller into sane state ahcich15: AHCI engine: stopping Root mount waiting for: CAM usbus0 ahcich15: stopping AHCI engine: timeout at 1000000 us (cr=1, ccs=0, ci=0, sact=0) ahcich15: ahci_clo: Start ahcich15: ahci_clo: Done ahcich15: AHCI engine(fbs=0): starting ahcich15: ahci_start: Done uhub1: 4 ports with 4 removable, self powered Root mount waiting for: CAM usbus0 ugen0.4: <vendor 0x1604 product 0x10c0> at usbus0 uhub2 numa-domain 0 on uhub1 uhub2: <vendor 0x1604 product 0x10c0, class 9/0, rev 2.00/0.00, addr 3> on usbus0 Root mount waiting for: CAM usbus0 ahcich15: ahci_end_transaction: Reinit port (eslots=00000010) ahcich15: AHCI engine: stopping Root mount waiting for: CAM usbus0 hcich15: stopping AHCI engine: timeout at 1000000 us (cr=1, ccs=0, ci=0, sact=0) ahcich15: ahci_clo: Start ahcich15: ahci_clo: Done ahcich15: AHCI engine(fbs=1): starting ahcich15: ahci_start: Done ahcich16: ahci_execute_transaction: Kicking controller into sane state ahcich16: AHCI engine: stopping ahcich16: stopping AHCI engine: cr: 1 -> 0 at time 10 us ahcich16: AHCI engine stopped at time 10 us ahcich16: ahci_clo: Start ahcich16: ahci_clo: Done ahcich16: AHCI engine(fbs=0): starting ahcich16: ahci_start: Done ahcich16: ahci_end_transaction: Reinit port (eslots=00000004) ahcich16: AHCI engine: stopping uhub2: 4 ports with 4 removable, self powered Root mount waiting for: CAM usbus0 ugen0.5: <vendor 0x1604 product 0x10c0> at usbus0 uhub3 numa-domain 0 on uhub1 uhub3: <vendor 0x1604 product 0x10c0, class 9/0, rev 2.00/0.00, addr 4> on usbus0 ahcich16: stopping AHCI engine: timeout at 1000000 us (cr=1, ccs=0, ci=0, sact=0) ahcich16: ahci_clo: Start ahcich16: ahci_clo: Done ahcich16: AHCI engine(fbs=1): starting ahcich16: ahci_start: Done ahcich16: ahci_execute_transaction: Kicking controller into sane state ahcich16: AHCI engine: stopping Root mount waiting for: CAM usbus0 ahcich16: stopping AHCI engine: timeout at 1000000 us (cr=1, ccs=0, ci=0, sact=0) ahcich16: ahci_clo: Start ahcich16: ahci_clo: Done ahcich16: AHCI engine(fbs=0): starting ahcich16: ahci_start: Done Root mount waiting for: CAM usbus0 uhub3: 4 ports with 4 removable, self powered Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM ahcich16: ahci_end_transaction: Reinit port (eslots=00000010) ahcich16: AHCI engine: stopping Root mount waiting for: CAM ahcich16: stopping AHCI engine: timeout at 1000000 us (cr=1, ccs=0, ci=0, sact=0) ahcich16: ahci_clo: Start ahcich16: ahci_clo: Done ahcich16: AHCI engine(fbs=1): starting ahcich16: ahci_start: Done However, eventually things seem to work anyway. I've attached the full dmesg.boot file Created attachment 221500 [details]
dmesg.boot
Created attachment 221502 [details]
Version 2 of patch (with debugging printfs)
A new version of the patch (still with a lot of debugging printf's - I'll see if I can find time to create a more "clean" version with just the DELAY(10) and "long timeout, but only after state 0 -> 1" fixes.
Still seeing this problem with the latest BOSS-S1 firmware version 2.5.13.3024,A07 on FreeBSD-13.0 (and a Dell HBA330 in non-RAID mode) Created attachment 237998 [details]
updated patch compatible with stable/13
Problem still exists on FreeBSD 13.1, firmware version 2.15.0. The patch posted previously applies cleanly to stable/12, but not to stable/13.
I made a best effort to cleanup conflicts when cherry-picking back the change on stable/13 and am attaching the diff here.
The built kernel works and the disks are seen.
Any chances that someone might pick up on this, review the merged patch, and merge it back into 13 (and 12 using the previous version)?
Best Regards, Lorenzo
Hi all again, particularly committers. Please apologize upfront for adding another comment here to draw attention. I'm not sure how much the merged path needs amendmend and review (and I'm sure there are other bugs which are much more important than this one). However, the controller in question is not some exotic hardware used by "some", but one of the standard options on one of the arguably most used vendors (DELL) serving with our beloved FreeBSD. On short term (before deploying machines), I'd be available for further tests. However I am resorting to USB NVME for boot in the mean time (as I cannot deploy a custom kernel on those machines). Thanks in advance for attention on this. Best Regards. I have split out functional change into https://reviews.freebsd.org/D37585 to make review easier. The Dell hardware mentioned: https://www.dell.com/support/manuals/de-at/boss-s-1/boss_s1_ug_publication/overview > Probably not meaningful to try to report it to Dell since FreeBSD isn't officially supported by them
As an aside, if you have a support contract/channel with Dell, please do report to them - it's important that they are aware that people are using FreeBSD on their hardware, and experiencing trouble.
Thanks Dave for putting the review into Phabricator. I suspect things will be slow over the holidays, but I hope this will get picked up early in the new year.
For other people stumbling upon that issue, I had to revert all the way back to firmware A03 (version 2.5.13.3011) for both M.2 SSDs to be detected. A04 did show one disk, but not both. Looking forward to seeing the workaround committed, so we can flash back to A07? Thanks a bunch in advance to those involved! BOSS-S2 (firmware 2.5.13.4008 , PowerEdge T350 ) has same problem under the non-RAID mode. Use the last patch can detect the disk but still cause the zfs cksum error in some case. welcome to let me know how can I help to do something. A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=346483b1f10454c5617a25d5e136829f60fb1184 commit 346483b1f10454c5617a25d5e136829f60fb1184 Author: Mariusz Zaborski <oshogbo@FreeBSD.org> AuthorDate: 2023-02-10 15:56:04 +0000 Commit: Mariusz Zaborski <oshogbo@FreeBSD.org> CommitDate: 2023-02-10 16:10:04 +0000 ahci: increase timout For some devices, like Marvell 88SE9230, it takes more time to connect to the device. This patch introduces a special flag that extends the timeout from around 100ms to around 500ms. This change is based on the work of: Peter Eriksson <pen@lysator.liu.se> PR: 243401 Reviewed by: imp Tested by: dch MFC after: 3 days Sponsored by: Equinix Sponsored by: SkunkWerks, GmbH Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D38413 sys/dev/ahci/ahci.c | 12 ++++++++---- sys/dev/ahci/ahci.h | 4 +++- sys/dev/ahci/ahci_pci.c | 2 +- 3 files changed, 12 insertions(+), 6 deletions(-) Created attachment 240058 [details]
committed to address above issue, tested on a variety of Dell h/w and firmwares
This patch addressed specifically the Marvell 88SE9230:
{0x92301b4b, 0x00, "Marvell 88SE9230", AHCI_Q_ALTSIG |
- AHCI_Q_IOMMU_BUSWIDE},
+ AHCI_Q_IOMMU_BUSWIDE | AHCI_Q_SLOWDEV},
If you're experiencing this on other h/w please let us know
so we can add further device quirks if needed.
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=65bab39e140f97cace92a2923e50c6b654b02e22 commit 65bab39e140f97cace92a2923e50c6b654b02e22 Author: Mariusz Zaborski <oshogbo@FreeBSD.org> AuthorDate: 2023-02-10 15:56:04 +0000 Commit: Mariusz Zaborski <oshogbo@FreeBSD.org> CommitDate: 2023-02-13 23:45:01 +0000 ahci: increase timout For some devices, like Marvell 88SE9230, it takes more time to connect to the device. This patch introduces a special flag that extends the timeout from around 100ms to around 500ms. This change is based on the work of: Peter Eriksson <pen@lysator.liu.se> PR: 243401 Reviewed by: imp Tested by: dch MFC after: 3 days Sponsored by: Equinix Sponsored by: SkunkWerks, GmbH Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D38413 (cherry picked from commit f08ac4cb14c1c0740346a4363f82e1e1367c2bad) sys/dev/ahci/ahci.c | 12 ++++++++---- sys/dev/ahci/ahci.h | 4 +++- sys/dev/ahci/ahci_pci.c | 2 +- 3 files changed, 12 insertions(+), 6 deletions(-) A commit in branch releng/13.2 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=f09f828a41d8eaf6456d2894a97a2a10f8979ea1 commit f09f828a41d8eaf6456d2894a97a2a10f8979ea1 Author: Mariusz Zaborski <oshogbo@FreeBSD.org> AuthorDate: 2023-02-10 15:56:04 +0000 Commit: Mariusz Zaborski <oshogbo@FreeBSD.org> CommitDate: 2023-02-14 23:17:57 +0000 ahci: increase timout For some devices, like Marvell 88SE9230, it takes more time to connect to the device. This patch introduces a special flag that extends the timeout from around 100ms to around 500ms. This change is based on the work of: Peter Eriksson <pen@lysator.liu.se> Approved by: re (cperciva) PR: 243401 Reviewed by: imp Tested by: dch MFC after: 3 days Sponsored by: Equinix Sponsored by: SkunkWerks, GmbH Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D38413 (cherry picked from commit f08ac4cb14c1c0740346a4363f82e1e1367c2bad) (cherry picked from commit 65bab39e140f97cace92a2923e50c6b654b02e22) sys/dev/ahci/ahci.c | 12 ++++++++---- sys/dev/ahci/ahci.h | 4 +++- sys/dev/ahci/ahci_pci.c | 2 +- 3 files changed, 12 insertions(+), 6 deletions(-) |