r284665 causes MSI problems -> ahcich2: Timeout in slot 11 port 0
h.schmalzbauer at omnilan.de
Mon Jul 13 08:07:36 UTC 2015
Bezüglich Harald Schmalzbauer's Nachricht vom 12.07.2015 11:59 (localtime):
>>> I can't find suspicious code in r282213 which could cause this strange
>>> regression, but I verified carefully that problem arises with r284665.
>>> Actually, r282901
>>> is the real trigger, verified by putting
>>> nooptions RACCT
>>> nooptions RACCT_DEFAULT_TO_DISABLED
>>> nooptions RCTL
>>> into my kernel config -> problem vanishes!
>>> Setting "kern.racct.enable=1" doesn't make any difference, as soon as
>>> 'kern.features.racct' exists, there's the ahci(4)/ahcich2 timeout and
>>> machine doesn't finish booting.
>>> Unfortunately, I don't have any idea how to track this down to the
>>> actual culprit, but I hope the RACCT hackers do have ;-)
>>> Shall I open a bugzilla ticket?
>> That's... curious. I don't see how those two things could be related.
>> What's the FreeBSD version? How reproducible it is? Have you tried
>> compiling with and without those three lines a couple of times?
> Yes, I tried several times, and falsified that with r284665 the timeouts
> reproducably show up (which blocks the booting process, a major issue in
> my case).
> I also verified that several different revisions <284665 don't lead to
> that problem, and also that the changes in ahci code paths for the last
> year are not involved.
> I also can't see any relation, wich doesn't mean much since I don't have
> the kernel skills, but I'm sure the symptoms start with "options RACCT"
While still true that I _always_ had troubles with ahcich-timeouts and
"options RACCT". I now saw the same problem with kernel compiled without
RACCT option :-(
In this case, it's random and I had luck several times in a row, but
later on, several times in a row not, when the ahcich-timeouts prevented
the box from booting.
So "options RACCT" does have an influence – like mentioned, I could
never boot the machine with kernel >= r284665 and "options RACCT", but
most times with the same kernel without "options RACCT" – but removing
"options RACCT" from the kernel config is _not_ a true solution. It just
improves things in the way that it's possible to boot at all – most
times – but sometimes also leads to ahcich-timeouts. At least with
kernel >= r284665. I couldn't re-checked with older revisions. Next
chance for tests is the weekende after the next :-(
Do you have an idea which race "options RACCT" could influence?
Verbose booting showed in all cases (with or without timeouts) the same
IRQ mapping as far as I could see.
Is it likely to be a ACPI-Routing problem?
Once the machine booted, I couldn't see any ahcich-timeout yet in
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 196 bytes
Desc: OpenPGP digital signature
More information about the freebsd-stable