AHCI/ADA regression?

[Kenneth D. Merry]

On Tue, May 24, 2016 at 15:58:28 +0200, Gary Jennejohn wrote:
> On Mon, 23 May 2016 13:51:05 -0400
> "Kenneth D. Merry" <ken at FreeBSD.ORG> wrote:
> 
> > On Sat, May 21, 2016 at 10:09:49 +0200, Gary Jennejohn wrote:
> > > There appears to be a regression in AHCI/ADA behavior since r300207.
> > > 
> > > Starting a test kernel at r300293 results in extremely long timeouts
> > > probing ahcich2 for non-existent multiplier ports.
> > > 
> > > Here some kernel output:  
> > 
> > Is this dmesg output with or without the problem?
> > 
> 
> Actually it's the same with and without the problem.  The only real
> difference is the timeouts.

Ahh.

> > > ahci0: <AMD SB7x0/SB8x0/SB9x0 AHCI SATA controller>
> > > port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,
> > > 0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 17.0 on pci0
> > > 
> > > ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported  
> > 
> > Has the controller always claimed support for Port Multipliers?
> > 
> 
> Yes, this from today's dmesg.boot:
> ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported
> 
> > > ahcich2: <AHCI channel> at channel 2 on ahci0
> > > 
> > > ada1 at ahcich2 bus 0 scbus2 target 0 lun 0
> > > 
> > > /dev/ada1p1 on /home (ufs, local, journaled soft-updates)
> > > 
> > > An older kernel at r299170 does not exhibit this peculiar behavior and
> > > mounts /home with no delays.  
> > 
> > Are you able to send dmesg output before and after?
> > 
> 
> Before is easy, since I have a dmesg.boot.  After - I'll have to
> copy it from the screen since I don't have the patience to wait
> for booting to complete.  The above is pretty much after, but I
> can copy down the timeout messages which arise when the
> mulitplier ports are probed (no disk is present on any of them,
> so it takes forever).
> 
> The question in my mind is - why are "empty" multiplier ports being
> probed with the new code but not with the old code?

If the HBA says that it supports port multipliers, the kernel should always
look for them.  It probes the port multiplier first, before moving on to
look for regular targets.

So, from that standpoint, it should not be any different.  It sounds like
we're either getting further in the port multiplier probe process, or there
is something different about the way things are behaving.

If you can determine which commands are timing out, that may give us an
idea about where it is in the probe process.

Here is one way we may be able to track things down...  Build a kernel with
these options:

options	CAMDEBUG
options CAM_DEBUG_FLAGS=CAM_DEBUG_PROBE

If you build a kernel before and after the change with those options, it
will hopefully allow us to compare the probe sequence and get a clue about
where to look for the problem.

Thanks,

Ken
-- 
Kenneth Merry
ken at FreeBSD.ORG