linux-kernel - Re: hwclock failure in x86.git

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4786AF4C.6050509@gmail.com>
Date:	Thu, 10 Jan 2008 19:50:36 -0400
From:	Kevin Winchester <kjwinchester@...il.com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: hwclock failure in x86.git

H. Peter Anvin wrote:
> Kevin Winchester wrote:
>> My first time building and booting the mm branch of x86.git was pretty
>> successful.  The only error I noticed was the following in my dmesg:
>>
>>  hwclock[622] general protection ip:804b226 sp:bff43e30 error:0
>>
>> I'm not sure exactly how to debug this.  I could bisect, but there seems
>> to be some useful debug information in there, so there might be
>> something better to try first.
>>
> 
> That's a userspace IP; it implies the userspace hwclock binary did 
> something bad, or the kernel didn't permit it to do something it should 
> have.  The best thing to do would probably to strace hwclock and see 
> what it did when it died.
> 

Unfortunately, but the time I can get a chance to run hwclock, the
problem seems to have fixed itself.  I tried booting into single user
mode, but `/etc/init.d/hwclock.sh restart` succeeds once I have my prompt.

A few other facts:

- This is an Athlon64 box running X83_32
- I use hpet=force for the Via chipset
- A little more of the demsg is:

[   17.511262] rtc_cmos 00:05: setting system clock to 2008-01-10
23:44:16 UTC (1200008656)
[   17.545948] EXT3-fs: mounted filesystem with ordered data mode.
[   17.545986] VFS: Mounted root (ext3 filesystem) readonly.
[   17.546142] Freeing unused kernel memory: 144k freed
[   17.546260] kjournald starting.  Commit interval 5 seconds
[   21.861249] hwclock[622] general protection ip:804b226 sp:bfd98480
error:0
[   22.416442] Velocity is AUTO mode
[   23.093416] Adding 1502036k swap on /dev/sda5.  Priority:-1 extents:1
across:1502036k
[   23.416756] EXT3 FS on sda1, internal journal
[   24.009669] kjournald starting.  Commit interval 5 seconds
[   24.009889] EXT3 FS on sda6, internal journal
[   24.009899] EXT3-fs: mounted filesystem with ordered data mode.
[   24.053164] eth0: Link auto-negotiation speed 100M bps full duplex
[   28.733360] agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
[   28.733872] agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
[   28.734354] agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
[   29.089412] [drm] Setting GART location based on new memory map
[   29.089842] [drm] Loading R200 Microcode
[   29.090172] [drm] writeback test succeeded in 1 usecs
[  143.076821] Marking TSC unstable due to: cpufreq changes.
[  143.084910] Time: hpet clocksource has been installed.
[  143.670905] Clocksource tsc unstable (delta = -231086796 ns)

So the TSC is being marked unstable because of cpufreq changes. I have
no idea when it comes to TSCs and HPETs and how the RTC works (other
than what the abbreviations stand for), so this all may be meaningless.
 I'll try disabling cpufreq to see if that has an effect.

-- 
Kevin Winchester

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/