[Bug 237261] Boot stuck in endless ATAPI_IDENTIFY attempts

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237261

Andriy Gapon <***@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Assignee|***@FreeBSD.org |***@FreeBSD.org

--- Comment #6 from Andriy Gapon <***@FreeBSD.org> ---
(In reply to Mikhail Teterin from comment #5)
Thank you!
So, we can see that the old stack also sees the phantom device, tries to
identify it and fails. But I guess that that happens rather quickly (?) and,
certainly, there are no endless retries. That seems to be the main difference
between the old code and the new one.

I would try to draw attention of CAM experts like Scott Long or Alexander Motin
or Kenneth Merry to this bug. I'll re-assign this bug to scsi@ as well.

Here are the relevant bits from the log:
ata1: <ATA channel 1> on atapci0
ata1: reset tp1 mask=03 ostat0=50 ostat1=00
ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb
ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb
ata1: reset tp2 stat0=00 stat1=00 devices=0x30000
ata1: Identifying devices: 00030000
ata1: New devices: 00030000
ata1: reiniting channel ..
ata1: reset tp1 mask=03 ostat0=00 ostat1=00
ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb
ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb
ata1: reset tp2 stat0=00 stat1=00 devices=0x30000
ata1: reinit done ..
unknown: FAILURE - ATAPI_IDENTIFY timed out LBA=0
ata1: reiniting channel ..
ata1: reset tp1 mask=03 ostat0=00 ostat1=00
ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb
ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb
ata1: reset tp2 stat0=00 stat1=00 devices=0x30000
ata1: reinit done ..
unknown: FAILURE - ATAPI_IDENTIFY timed out LBA=0

And then success for the real device:
ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire
acd0: setting UDMA33
acd0: <UJDA755 DVD/CDRW/1.00> CDRW drive at ata1 as master
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237261

Mikhail Teterin <***@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@FreeBSD.org,
| |***@FreeBSD.org,
| |***@FreeBSD.org

--- Comment #7 from Mikhail Teterin <***@FreeBSD.org> ---
(In reply to Andriy Gapon from comment #6)
Ok, so why does it never give up with the new code? It claims that "Retries
exhausted", but comes right back to the same exhaustion again and again...
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237261

--- Comment #8 from Alexander Motin <***@FreeBSD.org> ---
I suppose it is not really a command retry, but a restart of probe process,
triggered by ATA bus reset, triggered by ATAPI_IDENTIFY command timeout for
phantom CDROM. That should probably be work-arounded, but honestly I have no
big wish to workaround PATA hardware issue in year 2019.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237261

Mikhail T. <***@ALDAN.algebra.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@ALDAN.algebra.com

--- Comment #9 from Mikhail T. <***@ALDAN.algebra.com> ---
PATA or not, an endless loop in device-detection like this is a bug on its own,
is not it? There is got to be a limit on the number of iterations. What if it
were a real device - with a broken controller?

Post by b***@freebsd.org
I have no

big wish to workaround PATA hardware issue in year 2019.

A small wish, maybe? Things got broken in 9.0, it seems - much earlier than
2019...
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de