Re: AHCI/ADA regression?
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?
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?
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 PROBE_SETDMAAA to P
Re: AHCI/ADA regression?
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 completed (aprobe3:ahci
Re: AHCI/ADA regression?
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?
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?
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?
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"