On Wed, Mar 20, 2013 at 07:58:14PM +, Ben Hutchings wrote:
> I'm announcing the release of the 3.2.41 kernel.
>
> All users of the 3.2 kernel series should upgrade.
>
> The updated 3.2.y git tree can be found at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Forgive me for bothering you about this again, I know that -stable
has a policy of only accepting patches once Linus has accepted them
upstream, but I'm curious what's going on here. Is there something I could
help with to move this along? I haven't seen any discussion about it since
Feb 16
On Sat, Feb 16, 2013 at 06:02:22PM +, Ben Hutchings wrote:
> Move the calls to memcpy_fromio() up into the loop in
> dmi_scan_machine(), and move the signature checks back down into
> dmi_decode(). We need to check at 16-byte intervals but keep a
> 32-byte buffer for an SMBIOS entry, so shift
On Sat, Feb 16, 2013 at 06:02:22PM +, Ben Hutchings wrote:
> Tim, you might like to test that this doesn't cause a regression
> of the previous fix.
>
> Ben.
Ugh, I see what happened now. I only got one copy of this email which was
'helpfully' sorted into the linux kernel mailbox. gmail real
On Sat, Feb 16, 2013 at 06:35:04PM -0800, Zhenzhong Duan wrote:
>
> - b...@decadent.org.uk wrote???
>
> > Commit 9f9c9cbb6057 ('drivers/firmware/dmi_scan.c: fetch dmi version
> > from SMBIOS if it exists') hoisted the check for "_DMI_" into
> > dmi_scan_machine(), which means that we don't bo
On Sat, Feb 16, 2013 at 05:18:10AM +, Ben Hutchings wrote:
> Don't worry about it - I think the log messages are a pretty good clue.
>
> Does this patch fix the log messages and/or the other issues?
>
Yes! In fact after a quick reboot, the log lines look to me like they exist
properly, acpi
This is becoming irritating. Clearly bisect isn't capable of
figuring out the bad commit for me, so I'm going to have to walk the commits
myself. *sigh* (The commit it thinks is the one that's causing the problem
for me yet again is very obviously barking up the wrong tree)
git bisect star
I just wanted to give a heads up so you knew where I'm at and that I
haven't forgotten to do the bisection. Well, I'm doing the bisection - and
it's having me chase wild geese. This bug is apparently not always occuring
when it's possible for it to, confusing the issue.
Currently I
Hmm. I'm not sure what's going on here but ever since I upgraded to
this kernel my CPU use has always been at 100% - various apps (top, pidstat,
conky) give different reasons for this, conky&pidstat claims things like
X/the most active X application are cpu hogging, while top seems to think
9 matches
Mail list logo
