Bug #1648

AHCI driver reports FIS structure fails

Added by eocallaghan over 4 years ago. Updated about 4 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

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

History

#1 Updated by dillon over 4 years ago

: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

#2 Updated by eocallaghan over 4 years ago

Everything is detected on that machine and seems to be working fine, just
thought I would report the messages, they looked nasty.

Cheers,
Edward.

#3 Updated by dillon over 4 years ago

:
:Edward O'Callaghan <> 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
<>

#4 Updated by justin over 4 years ago

On Tue, January 12, 2010 12:26 am, Matthew Dillon wrote:
> :
> :Edward O'Callaghan <> 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.

#5 Updated by thomas.nikolajsen about 4 years ago

patch applied in commit cae23e979c563e1d23122c863989f6faf439c217
AHCI - Improve warning messages when probing for a port multiplier

Also available in: Atom PDF