08/02/10
It’s not quite upstream yet, but there’s enough code out there for it to be useful. And by describing it maybe a few contributors will step forward to help with the remaining pieces. :)
First off, you’ll need Jason’s KGDB tree with a few fixes from me on top. I’ve collected them all at git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/kgdb-2.6.git in the kdb-kms branch.
Go ahead and build that kernel, and make sure you have CONFIG_KGDB_KDB=y and CONFIG_KDB_KEYBOARD=y set in your kernel config. After installing the kernel, add “kgdb=kms,kdb” to your boot command line. This enables the KMS enter/exit hooks and allows KDB to be driven from the locally attached keyboard.
Once you’ve rebooted, you should be able to enter KDB using SysRq-G or “echo g > /proc/sysrq-trigger", or by hitting a bug or breakpoint. Resuming from where you left off is as simple as typing ‘go’ from the kdb prompt.
The above should work ok for simple cases today, but there are several outstanding issues:
- console unblank support - currently when you enter KDB it will try to unblank the console. Since this path takes locks in the console, fb and drm layers, it can cause problems. Fixing this shouldn’t be too hard though; the kdb enter hook should take care of actually unblanking the console (e.g. if it had been DPMS’d off before), so all KGDB needs to do is make sure console I/O is enabled, which is a smaller console and fb bookkeeping activity. So the console hook needs to be split and the fb enter hook needs to handle preparing fbcon for I/O.
- cursor save/restore - right now, when you enter KDB you’ll still see the cursor if it was enabled when you entered. Saving and restoring cursor state should be handled by the fb hooks, but the DRM hooks currently don’t bother.
- driver support - I’ve only tested on i915, but adding radeon and other KMS support should be fairly straightforward. Likewise, adding support for plain fb drivers should be pretty easy as well, they just need a small function to write the scanout base register, ideally to the previously allocated fbcon memory location.
- enhance the DRM KMS layer to allow the reservation of a dedicated debug crtc, encoder and connector tuple - this would allow keeping the kernel console active on e.g. the VGA port, making debugging of desktop applications and the graphics stack easier.
That’s it for now, hopefully we can get at least some of this merged for 2.6.36 (the fb and DRM changes in particular are very small).
Comments:
driver support - I’ve only tested on i915, but adding radeon and other KMS support should be fairly straightforward
FWIW, I've already posted patches for radeon to the kdb mailing list -- I've been waiting for the API to settle down before posting a final patch.
So what is still missing?
- gracefully resuming the keyboard
- Possibly some bugs if the display needs to be unblanked from DPMS
- More drivers (but I know Chris is already got some experimental patches in the hopper)
The keyboard patch is still an RFC. I hope that it can be accepted into the Input tree for 2.6.37 because it is annoying to try and figure out what keys were depressed and press them again after you resume the kernel.
Thanks for all the help Jesse!
Jason.
Leave a comment:
Trackback address for this post:
Trackbacks:
No Trackbacks for this post yet...
Pingbacks:
No Pingbacks for this post yet...
using kdb on KMS -
Categories: