kernel panic - Logs to look at?

[MagnusB]

I have started to get a daily kernel panic, which seem to "repair" it self with a complete shutdown, but it is pretty annoying to have to reboot at least once a day... It started after I installed Epiphany, not sure whether that is the reason or not, though, but the first happened WHILE installing Epiphany. I have removed Epiphany, but the problem persists, so I do not think that is the issue, I am thinking APT, maybe.
But which logs to I look at to find out the specifics on what causes it? Or do I have to do a re installation? (that might not solve the problem though). Any help is appreciated..

[Husse]

I know that you know quite a bit of Linux...
logs are in /var/logs
I think kernel or messages are the logs...

[MagnusB]

*sits in the shame on me corner*
Of course, kind of obvious. Found one that looks interesting

Jan 22 18:47:26 medilap-mintiness kernel: [ 17.968000] nvidia: module license 'NVIDIA' taints kernel.

Sound kind of dirty....
Found the previous reboot after the last kernel panic:

Jan 22 18:31:07 medilap-mintiness kernel: [13977.900000] Attempt to release TCP socket in state 1 f338b300
Jan 22 18:31:07 medilap-mintiness kernel: [13977.904000] Attempt to release TCP socket in state 1 f336f300
Jan 22 18:31:07 medilap-mintiness kernel: [13978.152000] Attempt to release TCP socket in state 0 f338b300
Jan 22 18:31:07 medilap-mintiness kernel: [13978.228000] Attempt to release TCP socket in state 56 f338b300
Jan 22 18:31:07 medilap-mintiness kernel: [13978.268000] Attempt to release TCP socket in state 56 f338b300
Jan 22 18:31:07 medilap-mintiness kernel: [13978.288000] Attempt to release TCP socket in state 56 f338b300
Jan 22 18:31:07 medilap-mintiness kernel: [13978.296000] Attempt to release TCP socket in state 56 f338b300
Jan 22 18:31:07 medilap-mintiness kernel: [13978.296000] Attempt to release TCP socket in state 56 f338b300
Jan 22 18:31:08 medilap-mintiness kernel: [13979.076000] Attempt to release TCP socket in state 54 f336f300
Jan 22 18:31:08 medilap-mintiness kernel: [13979.128000] Attempt to release TCP socket in state 54 f336f300
Jan 22 18:31:08 medilap-mintiness kernel: [13979.176000] Attempt to release TCP socket in state 54 f336f300
Jan 22 18:31:08 medilap-mintiness kernel: [13979.400000] Attempt to release TCP socket in state 56 f338b300
Jan 22 18:31:08 medilap-mintiness kernel: [13979.408000] Attempt to release TCP socket in state 54 f336f300

Only thing that is out of routine, as far as I can see.
Same in messages, looks like a fresh install for me.. It seems to be network related, but I have no idea what causes it..

[Husse]

an 22 18:47:26 medilap-mintiness kernel: [ 17.968000] nvidia: module license 'NVIDIA' taints kernel.

That is as far as I know a "Linux purist" message to tell you "I don't like this, but Ok I'll do it"

[MagnusB]

Yeah, it say nVidia license... I am guessing since it is non foss it "taints" the kernel. I am guessing it is network related, I saw some other error messages concerning network modules... But I haven't had a panic in two days, so I have decided that after next panic, fresh install...

[MagnusB]

Think I found the source: ndiswrapper. A newer version will hopefully fix the problem, will try another fresh install and compiling a newer version of ndiswrapper.

[Husse]

ndiswrapper?
Can you elaborate - I mean we need it....

[MagnusB]

Well, as I posted, I think the culprit was ndiswrapper, I am pretty sure now that I have had the time to think about it. I think the version of ndiswrapper shipped with Mint is 1.43 and for my card, Broadcom Corporation BCM94311MCG using bcmwl5.inf, I need ndiswrapper as b43 does not work.
I got the idea when I tried PCLOS GNOME, first time I ran the liveCD it worked fine, each successive attempt to run would cause a panic when I installed bcmwl5.inf. I also used Ubuntu 7.10 (and Daryna, but I did a new installation for some reason, was to lazy to compile ndiswrapper) fine for several weeks with a compiled version of ndiswrapper. How or what causes this, I am not sure, but I am pretty confident that ndiswrapper 1.43 was the culprit.