Bug 149580 - [ata] [patch] When using an SIIG SATA card the error "Unexpected signature 0xa05f" is reported when a new drive is connected
Summary: [ata] [patch] When using an SIIG SATA card the error "Unexpected signature 0x...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 8.1-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-12 16:40 UTC by Bryce Simonds
Modified: 2018-01-03 05:14 UTC (History)
0 users

See Also:


Attachments
file.diff (511 bytes, patch)
2010-08-12 16:40 UTC, Bryce Simonds
no flags Details | Diff
pcidump.txt (18.19 KB, text/plain)
2010-08-16 17:10 UTC, Bryce Simonds
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bryce Simonds 2010-08-12 16:40:03 UTC
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)
Comment 1 Volker Werth freebsd_committer 2010-08-15 22:24:13 UTC
Responsible Changed
From-To: freebsd-bugs->mav

Alexander, can you care about this? Thx!
Comment 2 Alexander Motin freebsd_committer 2010-08-15 22:52:06 UTC
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
Comment 3 Bryce Simonds 2010-08-16 17:10:12 UTC
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
Comment 4 Alexander Motin freebsd_committer 2010-08-16 19:14:36 UTC
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
Comment 5 Bryce Simonds 2010-08-16 19:49:53 UTC
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
Comment 6 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:40 UTC
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