[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-stable
Subject:    Re: igb(4) watchdog timeout, lagg(4) fails
From:       Harald Schmalzbauer <h.schmalzbauer () omnilan ! de>
Date:       2015-02-20 13:17:46
Message-ID: 54E733FA.1020208 () omnilan ! de
[Download RAW message or body]


 Bezüglich Harald Schmalzbauer's Nachricht vom 11.02.2015 20:48
(localtime):
>  Bezüglich Jack Vogel's Nachricht vom 11.02.2015 18:31 (localtime):
>> tdh and tdt mean the head and tail indices of the ring, and these
>> values are
>> obviously severely borked :)
>>
>> I'm buried with some other issues, but I'll try and find some time to look
>> at this a bit more.
> Highly appreciated, thanks in advance!
>
> For the records: Rebooting the machine (ESXi guest-only!) brought the
> stalled igb1 back to operation.
> The guest has 2 igb (kawela) ports, one from a NIC(Intel ET Dual Port
> 82576)@CPU-PCIe and the second port from an identical NIC, but connected
> via PCH-PCIe.
> The watchdog timeout problem only occurs with the port from the
> PCH-PCIe-connected NIC (falisfied)!
> After the reboot the suspicious "dev.igb.1.link_irq=848" turned into:
> dev.igb.0.link_irq: 3
> dev.igb.1.link_irq: 4

Jack,

I'd like to let you know that "dev.igb.1.link_irq" again shows garbage
after the watchdog timeout problem occured again:
dev.igb.1.link_irq: 1458

I can imagine that resetting goes wrong and ends in loss of link_irq.
I now have to reboot the guest to get igb1 back to a working state, then
the link_irq will show "4" again, but I can't tell you what was first,
the timeour-reset or the "link_irq" jam. I guess the latter can't be the
case, but I have no idea about the code…

Thanks

-Harry


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]