![](https://seccdn.libravatar.org/avatar/7ec4c6d48964b25c3232ec6b29240b2a.jpg?s=120&d=mm&r=g)
On 9/30/18 1:31 AM, Andrei Borzenkov wrote:
28.09.2018 23:46, don fisher пишет:
I have now built both the netconsole interface and the alx driver native to the kernel. This works fine outputting a dmesg dump for about 12 seconds, then the output stops. That is about the same time it took for my Ethernet devices to come up. So there could be a conflict between the networks setup by netconsole and maybe being clobbered by wicked.
That's logical fallacy. Two events happening one after another does not imply two events are related.
netconsole is exactly that - net*console*. It does not record all kernel output, only messages that would be printed on (local) console. This is controlled by console log level parameter. For kernel message to appear in netconsole output its priority must be higher than console log level.
Default kernel console log level is DEBUG; when booting with "quiet" parameter it is WARNING meaning only errors appear on console.
The value of console log level can be changed at any time. So most likely something in your case does it. Check the value after boot. In my case (pretty vanilla Leap 15 install) it is rsyslog which resets console log level to ALERT meaning only emergency messages are printed.
I admit it was not straightforward to find out, I had to use kernel auditing to do it.
The documentation claims that system messages may go over the net with the kernel messages.
I do not know what documentation you mean nor what "system messages" means.
The documentation is in: /usr/src/linux-4.18.7/Documentation/networking/netconsole.txt My system is currently running at loglevel=8. By system messages I did mean the standard network traffic from the system. From the netconsole.txt, "the network device (eth1 in the above case) can run any kind of other network traffic, netconsole is not intrusive". I do now know enough about networking to diagnose the problem. I am not even sure if the problem is with the transmitter or receiver. I am sure that it stops at he same place every boot. The only exception is when I went into Yast2 and disabled wicked. Then it went a little further, but still not to completion. Is there a way to look at the receiver and see if it has messages in the queue, or some overflow, or something else? Any other lists to report to? This is almost working, so I hate to give up now. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org