Artem Kachitchkine writes: > > From a cursory look, only two threads stand out: <...> > Both are handling nxge interrupts. Neither seems to be blocked: > > - the first one is in the busy wait loop, probably in nge_mii_access() > (not shown due to tail call optimization), 30 attempts max 10 usec each; > > - the second one is bcopying some data; > > Are you sure the boot process really hangs or is just very slow? There's > a bunch of nxge instances (12?) which might take a while to complete > net-physical. On a live system under kmdb, it would make sense to > capture threadlist several times and see if it changes over time.
No, I'm not sure that the boot process is entirely blocked. All I know is that the person claims that after inserting our NIC into the system (not nge or nxge), that the system "stops booting". For all I know, it could be something simple like an irq routing problem where having another PCIe card forces some different legacy IRQ routing, or something (hence getting nxge stuck handing interrupts). I agree about getting multple snapshots. It is what I would do if I had access to the system. Unfortunately, I don't have access to the system, so I can't get multiple kmdb snapshots. Is there some way to leverage dtrace to see what the system was doing? Eg, can you somehow enable dtrace on all fbt probes at boot, and look at the dtrace buffers from a dump? Thanks, Drew _______________________________________________ networking-discuss mailing list [email protected]
