netconsole should retry. There is no timeout programmed here since that mightWell, the trouble is that it ends up spinning forever in the suspend case. The driver's suspend routine has XOFFed the queue, and its never going to come back if netconsole clogs everything up over it.
lose important information, and you rather want netconsole to survive an odd
unplugged cable then to lose vital debugging information when the system is
busy for instance. (losing link will cause the interface to be down and thus
the queue to be stopped)
polling is for receives. We're basically telling the stack not to poll ourOK, I see.
interface anymore.
e1000_suspend saves the entire configuration of the device and puts it inNot sure that's terribly useful. It would be nice to be able to zap the ethernet to get a console dump from early stages, but talking to the device depends on all the intermediate PCI stuff being set up first, so netconsole could cause even more of a mess.
Wake-on-Lan mode, allowing it to be waken up by your 'zap' in the proper way.
Yes, but I think that's OK for what I'm looking at. The problems I'm seeing happen later, and as I said in the first mail, I'm willing to accept a bletcherous hack if necessary (though obviously something clean and mergable would be preferable).Then the e1000 would resume normally, including restarting the xmit queue so that netconsole can start again immediately; any netconsole output before the e1000 resume would be lost, of course (I guess it could be buffered). That would suit me for now.
after coming out of suspend, e1000_resume is called which basically
reinitializes the entire device. In the entire sequence it is unlikely that
you'll actually be able to maintain netconsole in the first boot stage - the
network device will not be initialized by the kernel yet, and obviously will
be useless until e1000_resume is called!
I'm not sure that tweaking e1000 to survive longer is the answer here, and youPretty sure netpoll can't sleep there...
might be better off trying to have netconsole graciously wait
(msleep_interruptable instead of udelay?)
In any case, I see the biggestnetconsole has already been initialized. It doesn't need reinit on resume.
problem in the early boot stage when all nics are basically uninitialized
until resume starts. You just can't assign it an IP address for instance that
easy, and even resume causes the device to reset and thus link renegotiation,
adding crucial seconds to the time that the link is down, in which time you're
stacking up netconsole messages, or worse, fail to initialize netconsole
I hope this helps - I can't help but thinking that netconsole definatelyPerhaps not, but it isn't far from being a useful tool in this case. Its much better than the alternative of having no information at all about the whole process.
wasn't designed with this in mind.