Bug #1648
closed
AHCI driver reports FIS structure fails
Added by eocallaghan almost 15 years ago.
Updated over 14 years ago.
Description
When booting a Compaq Presario CQ61-311A, in dmesg we have a stream of the
following fails:
ahci0.1: PMPROBE First FIS failed
ahci0.0.15: Poll timeout slot 1 CMD: 26016<PMA,FR,MPSS,FRE,POD,SUD> TFD: 0x150
SERR: c0000<DIAG.B,DIAG.W>
ahci0.0: PMPROBE First FIS failed
..
ahci0.1: PMPROBE Second FIS failed
ahci0.0: PMPROBE Second FIS failed
:ahci0.1: PMPROBE First FIS failed
:ahci0.0.15: Poll timeout slot 1 CMD: 26016<PMA,FR,MPSS,FRE,POD,SUD> TFD: 0x=
:150
:SERR: c0000<DIAG.B,DIAG.W>
:ahci0.0: PMPROBE First FIS failed
:..
:
:ahci0.1: PMPROBE Second FIS failed
:ahci0.0: PMPROBE Second FIS failed
If you don't have a port multiplier connected those messages can
be ignored. Does it detect the attached devices?
-Matt
Everything is detected on that machine and seems to be working fine, just
thought I would report the messages, they looked nasty.
Cheers,
Edward.
:
:Edward O'Callaghan <eocallaghan@auroraux.org> added the comment:
:
:Everything is detected on that machine and seems to be working fine, just
:thought I would report the messages, they looked nasty.
:
:Cheers,
:Edward.
It's ok. What it is doing is probing for a port multiplier. The only
way one can determine if a port multiplier is on the port is to
probe target 15, and of course this will fail if there is no port
multiplier.
The probing has to be done whether or not a device is probed on
target 0, because when a PM is attached target 0 represents slot #0
behind the PM.
Basically Intel screwed the standard up to try to make it easier for
BIOS writers to boot from devices behind a port multiplier. Even worse,
there is no safe value for timing-out a software reset command (in fact,
on some chipsets if you timeout the command too quickly the chipset
will brick), so the entire probe sequence runs a lot slower then it
needs to if Intel hadn't messed up the standard.
-Matt
Matthew Dillon
<dillon@backplane.com>
On Tue, January 12, 2010 12:26 am, Matthew Dillon wrote:
:
:Edward O'Callaghan <eocallaghan@auroraux.org> added the comment:
:
:Everything is detected on that machine and seems to be working fine, just
:thought I would report the messages, they looked nasty.
:
:Cheers,
:Edward.
It's ok. What it is doing is probing for a port multiplier. The only
way one can determine if a port multiplier is on the port is to
probe target 15, and of course this will fail if there is no port
multiplier.
Would it make sense to say "no port multiplier found" in that error
message? I feel like we've had a number of these "what does this
ultimately harmless error message mean?" posts lately.
patch applied in commit cae23e979c563e1d23122c863989f6faf439c217
AHCI - Improve warning messages when probing for a port multiplier
Also available in: Atom
PDF