1 |
On Wed, Oct 7, 2015 at 4:13 PM, <covici@××××××××××.com> wrote: |
2 |
> Hi. I am getting some kind of kernel panick in 4.2.1 -- it boots up OK, |
3 |
> ... |
4 |
> how |
5 |
> do I get any information about what happened -- serial console or other |
6 |
> means? Can I do a console over the network without additional hardware? |
7 |
|
8 |
That is pretty simple actually. |
9 |
|
10 |
Set CONFIG_NETCONSOLE=y/m in your kernel config if it is not already set. |
11 |
add to your kernel command line: |
12 |
netconsole=6666@192.168.0.10/eth0,6666@192.168.0.5/1c:6f:65:ab:07:b2 |
13 |
|
14 |
(The first set of values is port@src-ip/interface. The second set of |
15 |
values is port@dest-ip/MAC. This is low-level code in the kernel so |
16 |
it is just sending raw UDP packets - the routine sending them has no |
17 |
idea what your interface IP is, and it can't use ARP.) |
18 |
|
19 |
On the destination machine, run "nc -u -l -p 6666" |
20 |
|
21 |
That will listen for console output and dump it to stdout. You'll get |
22 |
everything that goes to dmesg on the remote machine, including |
23 |
BUG/PANIC/etc output. It works fine even if the disks stop syncing. |
24 |
|
25 |
> |
26 |
> The reason I went with that kernel is because I want to try btrfs and |
27 |
> they develop fast, so it looked from Google searching that I should be |
28 |
> on 4.2 or thereabouts. The btrfs programs I emerged did say 4.2. |
29 |
> |
30 |
|
31 |
If you're having btrfs issues on such a recent kernel you should |
32 |
probably at least run all the backports that are available for it. |
33 |
|
34 |
There are undoubtedly many btrfs issues in 4.2.1 that have been fixed |
35 |
in 4.2.3, so you should probably be running this version if you want |
36 |
to stick with 4.2. |
37 |
|
38 |
Personally, I've been sticking with 3.18 until 4.1 quiets down. There |
39 |
are usually regressions in any new kernel version with btrfs. |
40 |
|
41 |
> So, I would like to go on two paths at once -- find out about the |
42 |
> panick, and maybe go to a lower kernel as well, but I was concerned |
43 |
> about btrfs if I do that. I have not created the pool yet. |
44 |
|
45 |
Generally speaking the btrfs on-disk format is stable, so for the most |
46 |
part you can switch back and forth between versions without issue. If |
47 |
you want to go to a really old kernel series like maybe 3.12 there |
48 |
might be a few optional btrfs features that won't work, but in general |
49 |
I'd stick with something newer. |
50 |
|
51 |
So, if you want to be bleeding-edge then stick with the bleeding edge |
52 |
and run the latest stable. If you want something longterm I'd stick |
53 |
with the 1st-2nd most recent longterm. 4.1 is still pretty new, but |
54 |
I'm close to switching over to it. |
55 |
|
56 |
You'd need to post the details of the panic to know more - the btrfs |
57 |
list is probably the best place. But again I'd confirm the panic on |
58 |
the latest release in the series you're running so as to not waste |
59 |
time on issues that may already be fixed. |
60 |
|
61 |
-- |
62 |
Rich |