#15016: KDL (network related) when booting on a Hades Canyon NUC8.
----------------------------------------+----------------------------
Reporter: bga | Owner: nobody
Type: bug | Status: new
Priority: normal | Milestone: Unscheduled
Component: Drivers/Network/ipro1000 | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
----------------------------------------+----------------------------
Comment (by bga):
I managed to compile FreeBSD with debug enabled and compare what happens
in it with what happens in Haiku. Up to the point where it fails, it seems
the call chain is exactly the same. I also zeroed in in the actual
failure. The problem is in this function here:
http://xref.plausible.coop/source/xref/haiku/src/add-
ons/kernel/drivers/network/ipro1000/dev/e1000/e1000_ich8lan.c#1404
There is an associated comment, in case it might be relevant:
{{{
1389 /**
1390 * e1000_disable_ulp_lpt_lp - unconfigure Ultra Low Power mode for
LynxPoint-LP
1391 * @hw: pointer to the HW structure
1392 * @force: boolean indicating whether or not to force disabling ULP
1393 *
1394 * Un-configure ULP mode when link is up, the system is transitioned
from
1395 * Sx or the driver is unloaded. If on a Manageability Engine (ME)
enabled
1396 * system, poll for an indication from ME that ULP has been un-
configured.
1397 * If not on an ME enabled system, un-configure the ULP mode by
software.
1398 *
1399 * During nominal operation, this function is called when link is
acquired
1400 * to disable ULP mode (force=FALSE); otherwise, for example when
unloading
1401 * the driver or during Sx->S0 transitions, this is called with
force=TRUE
1402 * to forcibly disable ULP.
1403 */
}}}
The actual failure happens in this loop:
http://xref.plausible.coop/source/xref/haiku/src/add-
ons/kernel/drivers/network/ipro1000/dev/e1000/e1000_ich8lan.c#1429
It pokes a register and checks a different one for a state change that
never happens. I added reads (or extra reads) to registers in this
function and notice all reads are returning FFFFFFFF. In fact, it probably
only reached this point by chance (the if that contains it checks for a
bit in a register which is set as all bits are set). It is even possible
that the FreeBSD code does not get to this point (although I did not check
for this specifically).
Augustin mentioned that registers returning FFFFFFFF probably indicated
that the card was not correctly initialized. Any pointers on where this
initialization would happen? Whould it be in the Haiku (maybe at the time
of PCI initialization?) side of things or in the actual driver?
--
Ticket URL: <https://dev.haiku-os.org/ticket/15016#comment:46>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.
