Re: AHCI/ADA regression?

2016-05-25 Thread Kenneth D. Merry 
On Wed, May 25, 2016 at 14:36:59 +0200, Gary Jennejohn wrote:
> On Wed, 25 May 2016 08:15:11 +0200
> Gary Jennejohn  wrote:
> 
> > On Tue, 24 May 2016 15:10:41 -0400
> > "Kenneth D. Merry"  wrote:
> > 
> > > Can you send full dmesg output from the working kernel?
> > >   
> > 
> > I'll give it a try and hope that the mail server doesn't strip it ==>
> > dmesg.boot.gz.
> > 
> > > It looks like you have some ATAPI devcies on your machine (signature 
> > > eb14).
> > > They would likely be attaching to the da(4) driver if they are disks, and
> > > that is a different code path.
> > >   
> > 
> > The one and only ATAPI device is cd0.
> > 
> 
> OK, it appears that one of the ATA fixes ken@ recently committed
> fixed my problem also.

Great!  I'm glad it's working!

> I'm now at r300677 and booting succeeds.
> 
> I guess the ATAPI DVD drive was the culprite.

It was most likely the Samsung hard drive.  This drive is the exact same
model that Alex Petrov also had problems with:

ada1 at ahcich2 bus 0 scbus2 target 0 lun 0
ada1:  ATA8-ACS SATA 2.x device
ada1: Serial Number S0MUJ1KP317818
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 476938MB (976771055 512 byte sectors)

It claims to support Read Log, but actually doesn't.

The change I checked in in revision 300640 will only send a Read Log (and
additional SMR probe steps) to drives that claim they're SMR drives.  Any
non-SMR drives should get the same probe as before.

Ken
-- 
Kenneth Merry
k...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: AHCI/ADA regression?

2016-05-25 Thread Gary Jennejohn 
On Wed, 25 May 2016 08:15:11 +0200
Gary Jennejohn  wrote:

> On Tue, 24 May 2016 15:10:41 -0400
> "Kenneth D. Merry"  wrote:
> 
> > Can you send full dmesg output from the working kernel?
> >   
> 
> I'll give it a try and hope that the mail server doesn't strip it ==>
> dmesg.boot.gz.
> 
> > It looks like you have some ATAPI devcies on your machine (signature eb14).
> > They would likely be attaching to the da(4) driver if they are disks, and
> > that is a different code path.
> >   
> 
> The one and only ATAPI device is cd0.
> 

OK, it appears that one of the ATA fixes ken@ recently committed
fixed my problem also.

I'm now at r300677 and booting succeeds.

I guess the ATAPI DVD drive was the culprite.

-- 
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: AHCI/ADA regression?

2016-05-24 Thread Kenneth D. Merry 
On Tue, May 24, 2016 at 20:00:51 +0200, Gary Jennejohn wrote:
> On Tue, 24 May 2016 10:41:25 -0400
> "Kenneth D. Merry"  wrote:
> 
> > > 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.
> > 
> 
> OK, both the old and new kernel versions do an extremely fast intial
> probe with these results (note: obtained with grep over dmesg.boot):
> 
> (aprobe0:ahcich0:0:15:0): Probe started
> (aprobe0:ahcich0:0:15:0): Probe PROBE_INVALID to PROBE_RESET
> (aprobe1:ahcich1:0:15:0): Probe started
> (aprobe1:ahcich1:0:15:0): Probe PROBE_INVALID to PROBE_RESET
> (aprobe2:ahcich2:0:15:0): Probe started
> (aprobe2:ahcich2:0:15:0): Probe PROBE_INVALID to PROBE_RESET
> (aprobe3:ahcich3:0:15:0): Probe started
> (aprobe3:ahcich3:0:15:0): Probe PROBE_INVALID to PROBE_RESET
> (aprobe4:ahcich4:0:15:0): Probe started
> (aprobe4:ahcich4:0:15:0): Probe PROBE_INVALID to PROBE_RESET
> (aprobe5:ahcich5:0:15:0): Probe started
> (aprobe5:ahcich5:0:15:0): Probe PROBE_INVALID to PROBE_RESET
> (aprobe4:ahcich4:0:15:0): Probe PROBE_RESET to PROBE_RESET
> (aprobe4:ahcich4:0:15:0): Probe PROBE_RESET to PROBE_INVALID
> (aprobe4:ahcich4:0:15:0): Probe completed
> (aprobe4:ahcich4:0:0:0): Probe started
> (aprobe4:ahcich4:0:0:0): Probe PROBE_INVALID to PROBE_RESET
> (aprobe4:ahcich4:0:0:0): Probe PROBE_RESET to PROBE_INVALID
> (aprobe4:ahcich4:0:0:0): Probe completed
> (aprobe0:ahcich0:0:15:0): Probe PROBE_RESET to PROBE_RESET
> (aprobe2:ahcich2:0:15:0): Probe PROBE_RESET to PROBE_RESET
> (aprobe0:ahcich0:0:15:0): SIGNATURE: 
> (aprobe0:ahcich0:0:15:0): Probe PROBE_RESET to PROBE_INVALID
> (aprobe0:ahcich0:0:15:0): Probe completed
> (aprobe2:ahcich2:0:15:0): SIGNATURE: 
> (aprobe2:ahcich2:0:15:0): Probe PROBE_RESET to PROBE_INVALID
> (aprobe2:ahcich2:0:15:0): Probe completed
> (aprobe0:ahcich0:0:0:0): Probe started
> (aprobe0:ahcich0:0:0:0): Probe PROBE_INVALID to PROBE_RESET
> (aprobe2:ahcich2:0:0:0): Probe started
> (aprobe2:ahcich2:0:0:0): Probe PROBE_INVALID to PROBE_RESET
> (aprobe3:ahcich3:0:15:0): Probe PROBE_RESET to PROBE_RESET
> (aprobe5:ahcich5:0:15:0): Probe PROBE_RESET to PROBE_RESET
> (aprobe0:ahcich0:0:0:0): SIGNATURE: 
> (aprobe0:ahcich0:0:0:0): Probe PROBE_RESET to PROBE_IDENTIFY
> (aprobe2:ahcich2:0:0:0): SIGNATURE: 
> (aprobe2:ahcich2:0:0:0): Probe PROBE_RESET to PROBE_IDENTIFY
> (aprobe1:ahcich1:0:15:0): Probe PROBE_RESET to PROBE_RESET
> (aprobe3:ahcich3:0:15:0): SIGNATURE: 
> (aprobe3:ahcich3:0:15:0): Probe PROBE_RESET to PROBE_INVALID
> (aprobe3:ahcich3:0:15:0): Probe completed
> (aprobe5:ahcich5:0:15:0): SIGNATURE: 
> (aprobe5:ahcich5:0:15:0): Probe PROBE_RESET to PROBE_INVALID
> (aprobe5:ahcich5:0:15:0): Probe completed
> (aprobe1:ahcich1:0:15:0): SIGNATURE: eb14
> (aprobe1:ahcich1:0:15:0): Probe PROBE_RESET to PROBE_INVALID
> (aprobe1:ahcich1:0:15:0): Probe completed
> (aprobe1:ahcich3:0:0:0): Probe started
> (aprobe1:ahcich3:0:0:0): Probe PROBE_INVALID to PROBE_RESET
> (aprobe3:ahcich5:0:0:0): Probe started
> (aprobe3:ahcich5:0:0:0): Probe PROBE_INVALID to PROBE_RESET
> (aprobe4:ahcich1:0:0:0): Probe started
> (aprobe4:ahcich1:0:0:0): Probe PROBE_INVALID to PROBE_RESET
> (aprobe1:ahcich3:0:0:0): SIGNATURE: 
> (aprobe1:ahcich3:0:0:0): Probe PROBE_RESET to PROBE_IDENTIFY
> (aprobe3:ahcich5:0:0:0): SIGNATURE: 
> (aprobe3:ahcich5:0:0:0): Probe PROBE_RESET to PROBE_IDENTIFY
> (aprobe4:ahcich1:0:0:0): SIGNATURE: eb14
> (aprobe4:ahcich1:0:0:0): Probe PROBE_RESET to PROBE_IDENTIFY
> (aprobe0:ahcich0:0:0:0): Probe PROBE_IDENTIFY to PROBE_SETMODE
> (aprobe1:ahcich3:0:0:0): Probe PROBE_IDENTIFY to PROBE_SETMODE
> (aprobe3:ahcich5:0:0:0): Probe PROBE_IDENTIFY to PROBE_SETMODE
> (aprobe0:ahcich0:0:0:0): Probe PROBE_SETMODE to PROBE_SET_MULTI
> (aprobe1:ahcich3:0:0:0): Probe PROBE_SETMODE to PROBE_SETDMAAA
> (aprobe3:ahcich5:0:0:0): Probe PROBE_SETMODE to PROBE_SETDMAAA
> (aprobe0:ahcich0:0:0:0): Probe PROBE_SET_MULTI to PROBE_DONE
> (aprobe0:ahcich0:0:0:0): Probe completed
> (aprobe1:ahcich3:0:0:0): Probe

Re: AHCI/ADA regression?

2016-05-24 Thread Gary Jennejohn 
On Tue, 24 May 2016 10:41:25 -0400
"Kenneth D. Merry"  wrote:

> > 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.
> 

OK, both the old and new kernel versions do an extremely fast intial
probe with these results (note: obtained with grep over dmesg.boot):

(aprobe0:ahcich0:0:15:0): Probe started
(aprobe0:ahcich0:0:15:0): Probe PROBE_INVALID to PROBE_RESET
(aprobe1:ahcich1:0:15:0): Probe started
(aprobe1:ahcich1:0:15:0): Probe PROBE_INVALID to PROBE_RESET
(aprobe2:ahcich2:0:15:0): Probe started
(aprobe2:ahcich2:0:15:0): Probe PROBE_INVALID to PROBE_RESET
(aprobe3:ahcich3:0:15:0): Probe started
(aprobe3:ahcich3:0:15:0): Probe PROBE_INVALID to PROBE_RESET
(aprobe4:ahcich4:0:15:0): Probe started
(aprobe4:ahcich4:0:15:0): Probe PROBE_INVALID to PROBE_RESET
(aprobe5:ahcich5:0:15:0): Probe started
(aprobe5:ahcich5:0:15:0): Probe PROBE_INVALID to PROBE_RESET
(aprobe4:ahcich4:0:15:0): Probe PROBE_RESET to PROBE_RESET
(aprobe4:ahcich4:0:15:0): Probe PROBE_RESET to PROBE_INVALID
(aprobe4:ahcich4:0:15:0): Probe completed
(aprobe4:ahcich4:0:0:0): Probe started
(aprobe4:ahcich4:0:0:0): Probe PROBE_INVALID to PROBE_RESET
(aprobe4:ahcich4:0:0:0): Probe PROBE_RESET to PROBE_INVALID
(aprobe4:ahcich4:0:0:0): Probe completed
(aprobe0:ahcich0:0:15:0): Probe PROBE_RESET to PROBE_RESET
(aprobe2:ahcich2:0:15:0): Probe PROBE_RESET to PROBE_RESET
(aprobe0:ahcich0:0:15:0): SIGNATURE: 
(aprobe0:ahcich0:0:15:0): Probe PROBE_RESET to PROBE_INVALID
(aprobe0:ahcich0:0:15:0): Probe completed
(aprobe2:ahcich2:0:15:0): SIGNATURE: 
(aprobe2:ahcich2:0:15:0): Probe PROBE_RESET to PROBE_INVALID
(aprobe2:ahcich2:0:15:0): Probe completed
(aprobe0:ahcich0:0:0:0): Probe started
(aprobe0:ahcich0:0:0:0): Probe PROBE_INVALID to PROBE_RESET
(aprobe2:ahcich2:0:0:0): Probe started
(aprobe2:ahcich2:0:0:0): Probe PROBE_INVALID to PROBE_RESET
(aprobe3:ahcich3:0:15:0): Probe PROBE_RESET to PROBE_RESET
(aprobe5:ahcich5:0:15:0): Probe PROBE_RESET to PROBE_RESET
(aprobe0:ahcich0:0:0:0): SIGNATURE: 
(aprobe0:ahcich0:0:0:0): Probe PROBE_RESET to PROBE_IDENTIFY
(aprobe2:ahcich2:0:0:0): SIGNATURE: 
(aprobe2:ahcich2:0:0:0): Probe PROBE_RESET to PROBE_IDENTIFY
(aprobe1:ahcich1:0:15:0): Probe PROBE_RESET to PROBE_RESET
(aprobe3:ahcich3:0:15:0): SIGNATURE: 
(aprobe3:ahcich3:0:15:0): Probe PROBE_RESET to PROBE_INVALID
(aprobe3:ahcich3:0:15:0): Probe completed
(aprobe5:ahcich5:0:15:0): SIGNATURE: 
(aprobe5:ahcich5:0:15:0): Probe PROBE_RESET to PROBE_INVALID
(aprobe5:ahcich5:0:15:0): Probe completed
(aprobe1:ahcich1:0:15:0): SIGNATURE: eb14
(aprobe1:ahcich1:0:15:0): Probe PROBE_RESET to PROBE_INVALID
(aprobe1:ahcich1:0:15:0): Probe completed
(aprobe1:ahcich3:0:0:0): Probe started
(aprobe1:ahcich3:0:0:0): Probe PROBE_INVALID to PROBE_RESET
(aprobe3:ahcich5:0:0:0): Probe started
(aprobe3:ahcich5:0:0:0): Probe PROBE_INVALID to PROBE_RESET
(aprobe4:ahcich1:0:0:0): Probe started
(aprobe4:ahcich1:0:0:0): Probe PROBE_INVALID to PROBE_RESET
(aprobe1:ahcich3:0:0:0): SIGNATURE: 
(aprobe1:ahcich3:0:0:0): Probe PROBE_RESET to PROBE_IDENTIFY
(aprobe3:ahcich5:0:0:0): SIGNATURE: 
(aprobe3:ahcich5:0:0:0): Probe PROBE_RESET to PROBE_IDENTIFY
(aprobe4:ahcich1:0:0:0): SIGNATURE: eb14
(aprobe4:ahcich1:0:0:0): Probe PROBE_RESET to PROBE_IDENTIFY
(aprobe0:ahcich0:0:0:0): Probe PROBE_IDENTIFY to PROBE_SETMODE
(aprobe1:ahcich3:0:0:0): Probe PROBE_IDENTIFY to PROBE_SETMODE
(aprobe3:ahcich5:0:0:0): Probe PROBE_IDENTIFY to PROBE_SETMODE
(aprobe0:ahcich0:0:0:0): Probe PROBE_SETMODE to PROBE_SET_MULTI
(aprobe1:ahcich3:0:0:0): Probe PROBE_SETMODE to PROBE_SETDMAAA
(aprobe3:ahcich5:0:0:0): Probe PROBE_SETMODE to PROBE_SETDMAAA
(aprobe0:ahcich0:0:0:0): Probe PROBE_SET_MULTI to PROBE_DONE
(aprobe0:ahcich0:0:0:0): Probe completed
(aprobe1:ahcich3:0:0:0): Probe PROBE_SETDMAAA to PROBE_SET_MULTI
(aprobe4:ahcich1:0:0:0): Probe PROBE_IDENTIFY to PROBE_SETMODE
(aprobe3:ahcich5:0:0:0): Probe PROBE_SETDMAAA to PROBE_SET_MULTI
(aprobe1:ahcich3:0:0:0): Probe PROBE_SET_MULTI to PROBE_DONE
(aprobe1:ahcich3:0:0:0): Probe

Re: AHCI/ADA regression?

2016-05-24 Thread 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"  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: 
> > > 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:  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
k...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: AHCI/ADA regression?

2016-05-24 Thread Gary Jennejohn 
On Mon, 23 May 2016 13:51:05 -0400
"Kenneth D. Merry"  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.

> > ahci0: 
> > 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:  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?

-- 
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: AHCI/ADA regression?

2016-05-23 Thread Kenneth D. Merry 
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?

> ahci0: 
> 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?

> ahcich2:  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?

Ken
-- 
Kenneth Merry
k...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

AHCI/ADA regression?

2016-05-21 Thread Gary Jennejohn 
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:
ahci0: 
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

ahcich2:  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.

-- 
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"