When using the SIIG DP SATA 6Gb/s 2S1P PCIe card an error is reported when a drive is hot plugged into the card: Aug 11 16:59:05 fossel kernel: (aprobe0:ahcich0:0:0:0): Unexpected signature 0xa05f The SATA controller on the motherboard works fine. Fix: Submitted a patch that appears to work around the problem okay, but I'm not certain this this is a correct fix. I believe this might be a RAID signature code, but I'm using the card for individual SATA drives not the RAID portion so it suits our needs. Patch attached with submission follows: How-To-Repeat: Need a SIIG DP SATA 6Gb/s 2S1P PCIe card. While using the ahci(4) driver, hot plug a SATA drive into the card, this should generate the error (the error is viewable from dmesg)
Responsible Changed From-To: freebsd-bugs->mav Alexander, can you care about this? Thx!
This signature is unknown to me. It is not defined in standard. As I understand, this controller based on some Marvell 88SE912x chip. I've tested few of them and they were working fine. Could you collect more data, including `pciconf -lvbc` output? -- Alexander Motin
Sure thing, here it is. I had fiddled with the hardware configuration of this box (moved the card into another slot) and the signature changed: "Unexpected signature 0x2c56" My hack also didn't correct the problem permanently like I had originally thought: [[ FIRST INSERT ]] (aprobe0:ahcich0:0:0:0): Unexpected signature 0x2c560000, assuming ATA drive. ada1 at ahcich0 bus 0 scbus0 target 0 lun 0 ada1: <WDC WD1600JS-75NCB3 10.02E04> ATA-7 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 157066MB (321672960 512 byte sectors: 16H 63S/T 16383C) [[ REMOVAL ]] (ada1:ahcich0:0:0:0): lost device (ada1:ahcich0:0:0:0): removing device entry [[ SECOND INSERT ]] ahcich0: device is not ready after soft-reset: tfd = 000000ff [[ THIRD INSERT ]] ahcich0: device is not ready after soft-reset: tfd = 000000ff It continues like this until I reboot. Looking at 7.2's ATA driver it would appear that the driver there attempts to treat any unknown signatures as an ATA disk drive. However, that driver consequently doesn't seem to pick up drives hot plugged into the SATA controllers built into my MB, with a similar such problem: Aug 16 23:48:34 carbon kernel: ata16: CONNECT requested Aug 16 23:48:34 carbon kernel: ata16: CONNECTED Aug 16 23:48:34 carbon kernel: ata16: SATA connect time=0ms Aug 16 23:48:34 carbon kernel: ata16: SIGNATURE: ffffffff Aug 16 23:48:34 carbon kernel: ata16: No signature, asuming disk device Aug 16 23:48:34 carbon kernel: ata16: ahci_reset devices=0x1<ATA_MASTER> Aug 16 23:48:35 carbon kernel: ata16: reiniting channel .. Aug 16 23:48:35 carbon kernel: ata16: SATA connect time=0ms Aug 16 23:48:35 carbon kernel: ata16: SIGNATURE: ffffffff Aug 16 23:48:35 carbon kernel: ata16: No signature, asuming disk device Aug 16 23:48:35 carbon kernel: ata16: ahci_reset devices=0x1<ATA_MASTER> Aug 16 23:48:35 carbon kernel: ata16: reinit done .. Aug 16 23:48:36 carbon kernel: ata16: reiniting channel .. Aug 16 23:48:36 carbon kernel: ata16: SATA connect time=0ms Aug 16 23:48:36 carbon kernel: ata16: SIGNATURE: ffffffff Aug 16 23:48:36 carbon kernel: ata16: No signature, asuming disk device Aug 16 23:48:36 carbon kernel: ata16: ahci_reset devices=0x1<ATA_MASTER> Aug 16 23:48:36 carbon kernel: ata16: reinit done .. The only benefit about 7.2 at this point right now for me is that if I use the atacontrol command to detach and reattach the ATA controller the drive will then show up okay. The problem is that I'm writing some software that needs to be able to pick up drive attachments automatically so it can begin purging the disk of its contents; constantly issuing an attach/detach to that controller while it's trying to do the above reinit causes the kernel to panic. :/ Any help you can provide on this would be much appreciated. Thank you, Bryce Simonds Veriam Technologies, Inc. -----Original Message----- From: Alexander Motin [mailto:mavbsd@gmail.com] On Behalf Of Alexander Motin Sent: Sunday, August 15, 2010 4:52 PM To: bug-followup@FreeBSD.org; bsimonds@veriam.com Subject: Re: kern/149580: [ata] [patch] When using an SIIG SATA card the error "Unexpected signature 0xa05f" is reported when a new drive is connected This signature is unknown to me. It is not defined in standard. As I understand, this controller based on some Marvell 88SE912x chip. I've tested few of them and they were working fine. Could you collect more data, including `pciconf -lvbc` output? -- Alexander Motin
Bryce Simonds wrote: > Sure thing, here it is. I have board with the same chip revision. I've remade small series of tests and couldn't found problem. Both initial probe and hot-plug were working fine for Intel SSD and WD Green HDD. > I had fiddled with the hardware configuration of this box (moved the card > into another slot) and the signature changed: "Unexpected signature 0x2c56" > > My hack also didn't correct the problem permanently like I had originally > thought: > > [[ FIRST INSERT ]] > (aprobe0:ahcich0:0:0:0): Unexpected signature 0x2c560000, assuming ATA > drive. > ada1 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada1: <WDC WD1600JS-75NCB3 10.02E04> ATA-7 SATA 2.x device > ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 157066MB (321672960 512 byte sectors: 16H 63S/T 16383C) This may mean that reset sequence was completed prematurely, before drive reported signature. What is also looks strange in this output - is how last signature value can be bigger then 16 bits, looking on the code: int sign = (done_ccb->ataio.res.lba_high << 8) + done_ccb->ataio.res.lba_mid; It is difficult to say something until I can reproduce problem and make set of experiments. Unless I can reproduce it locally, it could help if you give me an access to the problematic system and help to setup reproducible fault. BTW, you are only speaking about hot-plug problems. Does it work fine during boot? -- Alexander Motin
I don't mind giving you access to the system, I will need a login and a SSH key for me to put into that login for you. After I receive that I'll give you the directions for accessing the system. The signature is > 16 bits on the one because I had hacked the driver in an effort to try and correct the issue on my own. I can leave that in place on the system I can give you access to if you want, the original source file is still there for me to go back to pretty quickly. If I put the drives in at boot it does work fine, however, this is for an appliance that will have the drives added and removed quite frequently, several times in a day quite possibly on the order of hundreds. The system will ultimately have every last PCIe slot filled with one of these cards connected to a hot swapping SATA tray. If it helps, it is quite possible that it could be because I have an older drive. The WD Green drives are fairly new large drives IIRC. The drives that I'm working with are refurbished/used drives destined for erasure before getting resold. -----Original Message----- From: Alexander Motin [mailto:mavbsd@gmail.com] On Behalf Of Alexander Motin Sent: Monday, August 16, 2010 1:15 PM To: Bryce Simonds Cc: bug-followup@FreeBSD.org Subject: Re: kern/149580: [ata] [patch] When using an SIIG SATA card the error "Unexpected signature 0xa05f" is reported when a new drive is connected Bryce Simonds wrote: > Sure thing, here it is. I have board with the same chip revision. I've remade small series of tests and couldn't found problem. Both initial probe and hot-plug were working fine for Intel SSD and WD Green HDD. > I had fiddled with the hardware configuration of this box (moved the card > into another slot) and the signature changed: "Unexpected signature 0x2c56" > > My hack also didn't correct the problem permanently like I had originally > thought: > > [[ FIRST INSERT ]] > (aprobe0:ahcich0:0:0:0): Unexpected signature 0x2c560000, assuming ATA > drive. > ada1 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada1: <WDC WD1600JS-75NCB3 10.02E04> ATA-7 SATA 2.x device > ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 157066MB (321672960 512 byte sectors: 16H 63S/T 16383C) This may mean that reset sequence was completed prematurely, before drive reported signature. What is also looks strange in this output - is how last signature value can be bigger then 16 bits, looking on the code: int sign = (done_ccb->ataio.res.lba_high << 8) + done_ccb->ataio.res.lba_mid; It is difficult to say something until I can reproduce problem and make set of experiments. Unless I can reproduce it locally, it could help if you give me an access to the problematic system and help to setup reproducible fault. BTW, you are only speaking about hot-plug problems. Does it work fine during boot? -- Alexander Motin
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
Keyword: patch or patch-ready – in lieu of summary line prefix: [patch] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>