On 2015-12-11 08:20 +0100, Adam Borowski wrote: > On Thu, Dec 10, 2015 at 07:17:43PM -0800, Nigra Truo wrote: >> That does not work neither unfortunately. I installed the proprietary >> driver and now X crashes. At least the whole machine does not crash, but I >> can open a Desktop, KDE or Gnome, then open an app, maximize the window and >> I get a prompt crash. > > Oif. I'm afraid I can't help you further here -- I'm a mere user when it > comes to X drivers. I could help with installing a newer version or an > alternate driver, but for more, we need actual driver guys :(
Problem is, there is no such person in Debian for the nouveau driver. >> The unability to get logs in the Kernel Panic is a huge problem, I can't >> believe that this his still not solved, that there is no automatic >> mechanism, to at least see what caused the panic or, for the matter, >> logging that ANY panic has occurred. Right now, the most serious of errors >> does not have any accounting whatsoever. > > When the kernel panics, most of its facilities are considered dead. Doing > something as complex as a filesystem write would require temporarily > ignoring the panic, with a huge risk of data corruption. A generally pretty > bad idea. > > Thus, you'd need to pass the remaining piece of the log somehow. Ways to do > so include: > * a serial console. My main desktop box happens to include a real serial > port, but that's sadly a rarity for modern machines these days. There are > USB connectors which you could use to pass the logs from your laptop to > another machine. > * kdump. This keeps a whole secondary kernel in memory which takes over > during a crash and can do a post-mortem on the primary kernel which just > panicked. > * some way over the network. User-mode syslog won't work but there are > kernel-based ones, google says netdump. The best choice is actually netconsole, see https://mraw.org/blog/2010/11/08/Debugging_using_netconsole/ and Documentation/networking/netconsole.txt in the kernel source. Cheers, Sven
