Hmm, on my atom netbook, .37 is the last one without crippling power regressions. I just tried the 3.0 kernel a week ago and the nettop was running it's fan at max speed at idle and lost a couple hours of battery life compared to .37. Which is annoying since there are driver updates in the newer kernel that would actually make the bluetooth chip work. So it's the traditional, decide what you want to be broken since you can't update individual drivers issue. :-(
Strange coincidence : my desktop computer with an integrated Intel G33 GPU works fine with kernel 2.6.37, but with any more recent kernel, after some hours the same problems appear : colors are replaced with wrong colors one by one, and after a little time I have to reboot since I cannot read clearly what is on my screen.
kernel (2.6.35) on my Sandy Bridge notebook - seems ok
Originally Posted by pali
I have questions:
* Which Sandy Bridge notebook was tested in article?
* I have Sandy Bridge notebook with discreate Radeon card and I do not see integrated Radeon in lspci (module i915 is not loading). Should be problem on my notebook too?
* What Sandy Bridge functionaly was added to kernels 3.0 and 3.1? Can I use old kernel (2.6.35) on my Sandy Bridge notebook?
Have been doing this since it was released for notebooks. Numerous distros (RPM, DEB), many recent version numbers. Will now add on kernel 3.1 -- hoping & risky.
Luckily my top-of-the-line HP Pavilion notebook is setup, offering XP-64, W7-64 & 4 Linux distros to choose to boot from. Each boot option use the same NTFS-MS partitions for archival, data & program storage on the two 750 GB HDDs, plus the esata (RAID0) & usb off-line drives.
Hope to try Ubuntu software-raid0 with the 2 HDDs of the notebook. Again another risk, if W7, W-XP can also work with multi choice boot options, as exists now. Luckily my $(AUD)99.00 2TB USB2 offline drive can backup my 1.5TB HDD notebook.
Last edited by gregzeng; 11-14-2011 at 03:11 AM.
I'm sorry but the kernel developers do their own testing, if you find a bug and report it they will usually request you bi-sect it. It's a relatively easy process, saves the developer time (that won't be the only bug in their queue) and pin point the commit on your machine which is exhibiting the problem - it could be hardware or bios specific rather than a problem that affects everyone
Michael generates revenue from these articles, he makes a living from the opensource ecosystem, reporting these issues really aught to be his way of "paying back" the community.
I've reported quite a few problems in the past, both in the kernel and in user space. Git-bisect is a great tool for users to help developers fix issues. If you can't code or submit patches then it's one of the easiest ways to give back to the community
Oh dear now I sound like I'm ranting - oh well...
The real problem is that the Linux kernel code base is so big and complicated, its unlikely they know exactly what broke it. though many can speculate.