Ok, this also confirms that the board had issues *before* any changes
were made to the RTC core. I'd push the board vendor to update the BIOS
to avoid this issue.
Even so, I'm curious as to what exactly trips it up. Maybe we can
provide a module option for the rtc-cmos driver to disable the
Using an older known-good kernel, could you build and run the test
case at the end of Documentation/rtc.txt a few times and see if it
triggers the same problem?
I'm suspicious that the setting the alarm is whats tripping the BIOS
into enabling the HT bit. Because with older kernels, we used
On Tue, 2011-11-29 at 13:26 +0100, Clarinet wrote:
Using an older known-good kernel, could you build and run the test
case at the end of Documentation/rtc.txt a few times and see if it
triggers the same problem?
I'm suspicious that the setting the alarm is whats tripping the BIOS
into
On Mon, 2011-11-21 at 22:31 +0100, Jiri Polach wrote:
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cb9a104..77b5273 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -640,7 +640,7 @@ config HPET_TIMER
Choose N to continue using the legacy 8254 timer.
config
Finally! After another 50+ compilations a have it! It took some time as
first I had to find a reason why some revisions did not boot (almost 2/3
were unbootable and the first bad commit was among them). Having this
solved I have been able to bisect without skipping. The result is
surprising (at
On Mon, 2011-11-21 at 14:27 +0100, Jiri Polach wrote:
Finally! After another 50+ compilations a have it! It took some time as
first I had to find a reason why some revisions did not boot (almost 2/3
were unbootable and the first bad commit was among them). Having this
solved I have been
Yea. My rough guess is that the BIOS is somehow sensitive to how the
CMOS RTC is touched.
Does disabling CONFIG_HPET_EMULATE_RTC change the behavior?
But how do I do it? :-)
I have not found a way to disable it in menuconfig. If I comment it
out manually in .config, it is automatically set
On Wed, 2011-11-16 at 23:49 +0100, Clarinet wrote:
Hi all,
Result of bisecting: v2.6.38-rc1 exhibits the problem. v2.6.37 and
many of the topic branches merged in the 2.6.38 merge window work ok.
Some other topic branches do not boot at all.
Jiri: if you have gitk installed, then git
On 11/17/2011 9:32 PM, John Stultz wrote:
On Wed, 2011-11-16 at 23:49 +0100, Clarinet wrote:
Hi all,
Result of bisecting: v2.6.38-rc1 exhibits the problem. v2.6.37 and
many of the topic branches merged in the 2.6.38 merge window work ok.
Some other topic branches do not boot at all.
Jiri: if
On Fri, 2011-11-18 at 00:42 +0100, Jiri Polach wrote:
On 11/17/2011 9:32 PM, John Stultz wrote:
On Wed, 2011-11-16 at 23:49 +0100, Clarinet wrote:
Hi all,
Result of bisecting: v2.6.38-rc1 exhibits the problem. v2.6.37 and
many of the topic branches merged in the 2.6.38 merge window work
Hi all,
Result of bisecting: v2.6.38-rc1 exhibits the problem. v2.6.37 and
many of the topic branches merged in the 2.6.38 merge window work ok.
Some other topic branches do not boot at all.
Jiri: if you have gitk installed, then git bisect visualize can help
get a sense of what's in the
Hi all,
Hi Jiri,
Jiri Polach wrote:
On Ben's advice I am trying to locate the commit that causes the problem to
appear more precisely using 'git bisect'. However, too many of generated
revisions are unbootable so I have to use 'bisect skip' frequently.
Ok, so I've looked over the log
Hi Jiri,
Jiri Polach wrote:
On Ben's advice I am trying to locate the commit that causes the problem to
appear more precisely using 'git bisect'. However, too many of generated
revisions are unbootable so I have to use 'bisect skip' frequently.
Ok, so I've looked over the log at
On 10/31/2011 2:06 PM, Clarinet wrote:
On 10/30/2011 4:25 PM, Ben Hutchings wrote:
On Sun, 2011-10-30 at 07:05 -0400, Jiri Polach wrote:
Package: linux-2.6
Version: 2.6.39-3~bpo60+1
Severity: normal
...
That might be too large a range for developers to consider. Can you
test some versions
On 10/30/2011 4:25 PM, Ben Hutchings wrote:
On Sun, 2011-10-30 at 07:05 -0400, Jiri Polach wrote:
Package: linux-2.6
Version: 2.6.39-3~bpo60+1
Severity: normal
When the computer is turned off using shutdown -h or halt command,
the hypertherading BIOS setting is changed - even if
On Sun, 2011-10-30 at 07:05 -0400, Jiri Polach wrote:
Package: linux-2.6
Version: 2.6.39-3~bpo60+1
Severity: normal
When the computer is turned off using shutdown -h or halt command,
the hypertherading BIOS setting is changed - even if hypertherading is
disabled in BIOS, the kernel
16 matches
Mail list logo
