Really - if you "can buy spare boxes for processor testing" - why not use one to debug the problem? If you can't - just roll back to the previous kernel where it works. Man - you get this all for free - but you rant and rave like a 5yr old... even when given simple tools to narrow down the problem. Jeez, no pleasing some ppl...
Yes - they will need more than "Tyan 2882 and UHCI no work." - in the case of kernel bugs stopping previously working functionality - you can use the excellent git bisect functionality to quickly (within a few reboots) narrow down exactly which patch broke the functionality.
For instructions - see http://www.kernel.org/pub/software/scm/git/docs/ho wto/isolate-bugs-with-bisect.txt
malc
Slashdot Mirror
And a new curses based option was developed with the help of Google's SoC project - conf-update http://sources.gentoo.org/viewcvs.py/gentoo-x86/ap p-portage/conf-update/
Really - if you "can buy spare boxes for processor testing" - why not use one to debug the problem? If you can't - just roll back to the previous kernel where it works. Man - you get this all for free - but you rant and rave like a 5yr old... even when given simple tools to narrow down the problem. Jeez, no pleasing some ppl...
Yes - they will need more than "Tyan 2882 and UHCI no work." - in the case of kernel bugs stopping previously working functionality - you can use the excellent git bisect functionality to quickly (within a few reboots) narrow down exactly which patch broke the functionality. For instructions - see http://www.kernel.org/pub/software/scm/git/docs/ho wto/isolate-bugs-with-bisect.txt
malc