On Sun, 10 Jan 2010, Rafael J. Wysocki wrote:
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14942
Subject : gkrellm no longer shows all the temperatures on
thinkpad x60
Submitter : Pavel Machek pa...@ucw.cz
Date: 2009-12-27 21:57 (15 days old)
On Sun, Jan 31, 2010 at 11:20:50PM -0800, David Miller wrote:
From: Xiaotian Feng xtf...@gmail.com
Date: Mon, 1 Feb 2010 11:30:02 +0800
On Mon, Feb 1, 2010 at 8:22 AM, Rafael J. Wysocki r...@sisk.pl wrote:
This message has been generated automatically as a part of a report
of recent
From: Neil Horman nhor...@tuxdriver.com
Date: Mon, 1 Feb 2010 06:55:18 -0500
He claims this dependency is deliberate and requires, to which I agree, but he
would seem to fix that by making the dccp_probe module error out in the event
that dccp wasn't loaded. Why bother with that?
Neil,
On Wed, Jan 27, 2010 at 11:35:20AM +0800, Feng Tang wrote:
Which only enforces the acpi_disabled check and should have no
logical problem.
And I guess your platform is blacklisted and acpi_disabled is set to 1,
while it still need parse ACPI tables to get SMP info. So I would suggest
to
Hi David,
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.31 and 2.6.32.
The following bug entry is on the current list of known regressions
introduced between 2.6.31 and 2.6.32. Please verify if it still should
be listed and
On 02/01/10 11:57, Stefan Richter wrote:
Justin P. Mattock wrote:
On 02/01/10 04:54, Dan Carpenter wrote:
On Sun, Jan 31, 2010 at 05:39:22PM -0800, Justin P. Mattock wrote:
On 01/31/10 16:43, Rafael J. Wysocki wrote:
This message has been generated automatically as a part of a report
of
Hi Rafael,
Sorry, I haven't had time to test newer kernels lately :(, but according to
changelogs, no related problems were fixed till 2.6.32.7...
I'll update problematic machine on wednesday though...
regards
nik
On Mon, Feb 01, 2010 at 01:43:18AM +0100, Rafael J. Wysocki wrote:
This message
Hi,
On Mon, Feb 1, 2010 at 11:14 AM, Marcel Holtmann mar...@holtmann.org wrote:
Hi David,
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.31 and 2.6.32.
The following bug entry is on the current list of known regressions
On 02/01/10 14:27, Stefan Richter wrote:
Justin P. Mattock wrote:
(as for yesterdays 0x(just experimenting)Google gives me
no info on the differences between 8f's to 16f's, I was under the
impression that it's x86_32 and x86_64 for the pci address).
As Dan noted,
On Mon, 2010-02-01 at 01:22 +0100, Rafael J. Wysocki wrote:
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.32. Please verify if it still should be listed and let me know
On 02/02/2010 12:44 AM, Marcel Holtmann wrote:
Hi David,
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.31 and 2.6.32.
The following bug entry is on the current list of known regressions
introduced between 2.6.31 and 2.6.32.
Hi David,
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.31 and 2.6.32.
The following bug entry is on the current list of known regressions
introduced between 2.6.31 and 2.6.32. Please verify if it still should
be listed and
Justin P. Mattock wrote:
So(correct me if I'm wrong), I'm generating a 64 bit register
and the kernel is looking for a 32 bit register causing the crash.
No, the class = read_pci_config(); if (class == ...) ... parts of the
code are entirely innocent as far as I can tell. This is just the
On 02/02/2010 11:11 AM, Marcel Holtmann wrote:
Hi David,
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.31 and 2.6.32.
The following bug entry is on the current list of known regressions
introduced between 2.6.31 and 2.6.32.
On 02/01/10 21:45, Stefan Richter wrote:
Justin P. Mattock wrote:
So(correct me if I'm wrong), I'm generating a 64 bit register
and the kernel is looking for a 32 bit register causing the crash.
No, the class = read_pci_config(); if (class == ...) ... parts of the
code are entirely innocent
Justin P. Mattock wrote:
As for anything changed in the kernel
(2.6.31 - present), tough to say
from what I remember I had created a new fresh
lfs system using these CFLAGS:
CFLAGS=-mtune=core2 -march=core2 -O2 -pipe -fomit-frame-pointer
CXXFLAGS=${CFLAGS} MAKEOPTS={-j3}
(without -m
Stefan Richter wrote:
Do I understand correctly that at this moment it is only known that the
bug could be
- *either* a 2.6.31 - 2.6.32 regression
- *or* an x86-64 specific bug that does not occur on x86-32,
right?
(OK, according to your other post it /is/ a regression, at least on
On 02/01/10 22:55, Stefan Richter wrote:
Justin P. Mattock wrote:
As for anything changed in the kernel
(2.6.31 - present), tough to say
from what I remember I had created a new fresh
lfs system using these CFLAGS:
CFLAGS=-mtune=core2 -march=core2 -O2 -pipe -fomit-frame-pointer
18 matches
Mail list logo
