size of git repository (was Re: [BUG] New Kernel Bugs)
On Tue 2007-11-13 12:50:08, Mark Lord wrote: Ingo Molnar wrote: for example git-bisect was godsent. I remember that years ago bisection of a bug was a very laborous task so that it was only used as a final, last-ditch approach for really nasty bugs. Today we can autonomouly bisect build bugs via a simple shell command around git-bisect run, without any human interaction! This freed up testing resources .. It's only a godsend for the few people who happen to be kernel developers and who happen to already use git. It's a 540MByte download over a slow link for everyone else. Hmmm, clean-cg is 7.7G on my machine, and yes I tried git-prune-packed. What am I doing wrong? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [BUG] New Kernel Bugs
Hi! Suspend to RAM resume hangs on a tickless (NO_HZ) kernel http://bugzilla.kernel.org/show_bug.cgi?id=9275 Kernel: 2.6.23 This is HP notebook nc6320 T2400 945GM No response from developers Maybe I'm optimistic, but I expected Ingo/Thomas to look after nohz problems. nohz=off highres=off fixes more than one suspend problem... ...stuff I've seen with NOHZ even without suspend (cursor blinking irregulary) make me think that nohz perhaps should not be used in production just yet... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH] Console keyboard events and accessibility
Hi! Because userland only begins quite late in the boot process, and userland may hang. Initrd means userland is started very early on most machines these days, and kernel may hang, too. Very early is not so early, and loading initrd itself may actually fail. The kernel may indeed hang, but there are more chances to get some messages before the hang. Don't _you_ have a VGA screen for getting earliest failure messages from the kernel? No. I'm using framebuffer, that's initialized quite late in boot process. Plus many users just use bootsplash. I do use vga mode for heavy debugging, but that's quite unusual. So... you actually have speech-enabled grub/lilo/something? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [2/6] 2.6.21-rc2: known regressions
Hi! You're better off using the VGA console, and lettign X re-initialize the graphics device. That generally at least has a reasonably good chance of working. Re-initializing graphics modes really is very hard. You can try with the BIOS video hack (I forget the kernel command line to turn it on), but we really do end up depending on X doing it better. acpi_sleep=s3_bios has always worked for me on my ThinkPad T42p. Even if one doesn't use the fb console at all, radeonfb apparently is still required on some ThinkPad models to work around BIOS bugs: http://www.thinkwiki.org/wiki/Problem_with_high_power_drain_in_ACPI_sleep#Radeon_GPU_not_powered_off s2ram should be able to work around this, it has parts from radeontool. (suspend.sf.net). -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
