Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
Thomas, I haven't found a good way to capture the SysRq output for this. I found that when it locks up at boot time, even SysRq is unresponsive. I don't have another way of getting console on the machine right now to get the output off of it. I have since upgraded to 2.6.24 and the problem still persists. Another interesting twist though.. I just rebuilt my kernel with ARCH=x86_64 and HPET works perfectly. So this only appears to break when in 32-bit mode. For some reason it picks tsc at boot time, but if I install hpet afterwards under x86_64 it no longer hangs when I run 'sleep 1'. Does that shed any more light on the problem? Thanks, -Andrew # uname -a Linux am2 2.6.24 #7 Sat Feb 9 18:06:50 EST 2008 x86_64 GNU/Linux # dmesg | egrep -i clock\|hpet ACPI: HPET 3DFE7780, 0038 (r1 RS690 AWRDACPI 42302E31 AWRD 98) ACPI: HPET id: 0x10b9a201 base: 0xfed0 hpet clockevent registered TSC calibrated against HPET hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0 hpet0: 4 32-bit timers, 14318180 Hz Time: tsc clocksource has been installed. Real Time Clock Driver v1.12ac hpet_resources: 0xfed0 is busy # echo -n hpet > /sys/devices/system/clocksource/clocksource0/current_clocksource # dmesg | tail -1 Time: hpet clocksource has been installed. # time sleep 1 real0m1.001s user0m0.000s sys 0m0.000s On Jan 18, 2008 5:26 AM, Thomas Gleixner <[EMAIL PROTECTED]> wrote: > On Wed, 16 Jan 2008, Andrew Paprocki wrote: > > > I applied the patch and I am still locking up after > > Time: hpet clocksource has been installed. > > That was expected :) > > > I rebooted with "clocksource=tsc" to get the logs of the trace which > > was added. I'm assuming the grep below gets all the interesting parts. > > I enabled the HPET character device as mentioned before, which is why > > the hpet0 lines appear now. > > > > # dmesg | egrep -i "(hpet|time|clock)" > > ACPI: HPET 37FE7400, 0038 (r1 RS690 AWRDACPI 42302E31 AWRD 98) > > ATI board detected. Disabling timer routing over 8254. > > ACPI: PM-Timer IO Port: 0x4008 > > ACPI: HPET id: 0x10b9a201 base: 0xfed0 > > Kernel command line: vga=0x31a root=/dev/sda1 ro clocksource=tsc > > HPET check: t1=5 t2=1139 s=56226339975 n=56226539985 > > Ok, the counter works when we initialize the HPET. > > t2-t1 = 1134 ticks ~= 79us > s-n = 200010 ~= 2525MHz --> That should be the frequency of your CPU. > > > Jan 16 14:44:43 am2 kernel: Call Trace: > > Jan 16 14:44:48 am2 kernel: [] enqueue_hrtimer+0xd7/0xe2 > > Jan 16 14:44:48 am2 kernel: [] hrtimer_start+0xe8/0xf4 > > Jan 16 14:44:48 am2 kernel: [] do_nanosleep+0x48/0x73 > > Jan 16 14:44:48 am2 kernel: [] > > hrtimer_nanosleep_restart+0x34/0xa1 > > Jan 16 14:44:48 am2 kernel: [] hrtimer_wakeup+0x0/0x18 > > Jan 16 14:44:48 am2 kernel: [] sys_restart_syscall+0xe/0xf > > Jan 16 14:44:48 am2 kernel: [] sysenter_past_esp+0x5f/0x85 > > When the system is hung, can you please hit SysRq-Q wait a bit and hit > SysRq-Q again. Please provide the output. > > Thanks, > tglx > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
Thomas, I haven't found a good way to capture the SysRq output for this. I found that when it locks up at boot time, even SysRq is unresponsive. I don't have another way of getting console on the machine right now to get the output off of it. I have since upgraded to 2.6.24 and the problem still persists. Another interesting twist though.. I just rebuilt my kernel with ARCH=x86_64 and HPET works perfectly. So this only appears to break when in 32-bit mode. For some reason it picks tsc at boot time, but if I install hpet afterwards under x86_64 it no longer hangs when I run 'sleep 1'. Does that shed any more light on the problem? Thanks, -Andrew # uname -a Linux am2 2.6.24 #7 Sat Feb 9 18:06:50 EST 2008 x86_64 GNU/Linux # dmesg | egrep -i clock\|hpet ACPI: HPET 3DFE7780, 0038 (r1 RS690 AWRDACPI 42302E31 AWRD 98) ACPI: HPET id: 0x10b9a201 base: 0xfed0 hpet clockevent registered TSC calibrated against HPET hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0 hpet0: 4 32-bit timers, 14318180 Hz Time: tsc clocksource has been installed. Real Time Clock Driver v1.12ac hpet_resources: 0xfed0 is busy # echo -n hpet /sys/devices/system/clocksource/clocksource0/current_clocksource # dmesg | tail -1 Time: hpet clocksource has been installed. # time sleep 1 real0m1.001s user0m0.000s sys 0m0.000s On Jan 18, 2008 5:26 AM, Thomas Gleixner [EMAIL PROTECTED] wrote: On Wed, 16 Jan 2008, Andrew Paprocki wrote: I applied the patch and I am still locking up after Time: hpet clocksource has been installed. That was expected :) I rebooted with clocksource=tsc to get the logs of the trace which was added. I'm assuming the grep below gets all the interesting parts. I enabled the HPET character device as mentioned before, which is why the hpet0 lines appear now. # dmesg | egrep -i (hpet|time|clock) ACPI: HPET 37FE7400, 0038 (r1 RS690 AWRDACPI 42302E31 AWRD 98) ATI board detected. Disabling timer routing over 8254. ACPI: PM-Timer IO Port: 0x4008 ACPI: HPET id: 0x10b9a201 base: 0xfed0 Kernel command line: vga=0x31a root=/dev/sda1 ro clocksource=tsc HPET check: t1=5 t2=1139 s=56226339975 n=56226539985 Ok, the counter works when we initialize the HPET. t2-t1 = 1134 ticks ~= 79us s-n = 200010 ~= 2525MHz -- That should be the frequency of your CPU. Jan 16 14:44:43 am2 kernel: Call Trace: Jan 16 14:44:48 am2 kernel: [c01371be] enqueue_hrtimer+0xd7/0xe2 Jan 16 14:44:48 am2 kernel: [c0137803] hrtimer_start+0xe8/0xf4 Jan 16 14:44:48 am2 kernel: [c03ac8d3] do_nanosleep+0x48/0x73 Jan 16 14:44:48 am2 kernel: [c03ac932] hrtimer_nanosleep_restart+0x34/0xa1 Jan 16 14:44:48 am2 kernel: [c013735d] hrtimer_wakeup+0x0/0x18 Jan 16 14:44:48 am2 kernel: [c012e837] sys_restart_syscall+0xe/0xf Jan 16 14:44:48 am2 kernel: [c0103d0a] sysenter_past_esp+0x5f/0x85 When the system is hung, can you please hit SysRq-Q wait a bit and hit SysRq-Q again. Please provide the output. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
On Wed, 16 Jan 2008, Andrew Paprocki wrote: > I applied the patch and I am still locking up after > Time: hpet clocksource has been installed. That was expected :) > I rebooted with "clocksource=tsc" to get the logs of the trace which > was added. I'm assuming the grep below gets all the interesting parts. > I enabled the HPET character device as mentioned before, which is why > the hpet0 lines appear now. > > # dmesg | egrep -i "(hpet|time|clock)" > ACPI: HPET 37FE7400, 0038 (r1 RS690 AWRDACPI 42302E31 AWRD 98) > ATI board detected. Disabling timer routing over 8254. > ACPI: PM-Timer IO Port: 0x4008 > ACPI: HPET id: 0x10b9a201 base: 0xfed0 > Kernel command line: vga=0x31a root=/dev/sda1 ro clocksource=tsc > HPET check: t1=5 t2=1139 s=56226339975 n=56226539985 Ok, the counter works when we initialize the HPET. t2-t1 = 1134 ticks ~= 79us s-n = 200010 ~= 2525MHz --> That should be the frequency of your CPU. > Jan 16 14:44:43 am2 kernel: Call Trace: > Jan 16 14:44:48 am2 kernel: [] enqueue_hrtimer+0xd7/0xe2 > Jan 16 14:44:48 am2 kernel: [] hrtimer_start+0xe8/0xf4 > Jan 16 14:44:48 am2 kernel: [] do_nanosleep+0x48/0x73 > Jan 16 14:44:48 am2 kernel: [] hrtimer_nanosleep_restart+0x34/0xa1 > Jan 16 14:44:48 am2 kernel: [] hrtimer_wakeup+0x0/0x18 > Jan 16 14:44:48 am2 kernel: [] sys_restart_syscall+0xe/0xf > Jan 16 14:44:48 am2 kernel: [] sysenter_past_esp+0x5f/0x85 When the system is hung, can you please hit SysRq-Q wait a bit and hit SysRq-Q again. Please provide the output. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
On Wed, 16 Jan 2008, Andrew Paprocki wrote: I applied the patch and I am still locking up after Time: hpet clocksource has been installed. That was expected :) I rebooted with clocksource=tsc to get the logs of the trace which was added. I'm assuming the grep below gets all the interesting parts. I enabled the HPET character device as mentioned before, which is why the hpet0 lines appear now. # dmesg | egrep -i (hpet|time|clock) ACPI: HPET 37FE7400, 0038 (r1 RS690 AWRDACPI 42302E31 AWRD 98) ATI board detected. Disabling timer routing over 8254. ACPI: PM-Timer IO Port: 0x4008 ACPI: HPET id: 0x10b9a201 base: 0xfed0 Kernel command line: vga=0x31a root=/dev/sda1 ro clocksource=tsc HPET check: t1=5 t2=1139 s=56226339975 n=56226539985 Ok, the counter works when we initialize the HPET. t2-t1 = 1134 ticks ~= 79us s-n = 200010 ~= 2525MHz -- That should be the frequency of your CPU. Jan 16 14:44:43 am2 kernel: Call Trace: Jan 16 14:44:48 am2 kernel: [c01371be] enqueue_hrtimer+0xd7/0xe2 Jan 16 14:44:48 am2 kernel: [c0137803] hrtimer_start+0xe8/0xf4 Jan 16 14:44:48 am2 kernel: [c03ac8d3] do_nanosleep+0x48/0x73 Jan 16 14:44:48 am2 kernel: [c03ac932] hrtimer_nanosleep_restart+0x34/0xa1 Jan 16 14:44:48 am2 kernel: [c013735d] hrtimer_wakeup+0x0/0x18 Jan 16 14:44:48 am2 kernel: [c012e837] sys_restart_syscall+0xe/0xf Jan 16 14:44:48 am2 kernel: [c0103d0a] sysenter_past_esp+0x5f/0x85 When the system is hung, can you please hit SysRq-Q wait a bit and hit SysRq-Q again. Please provide the output. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
I applied the patch and I am still locking up after Time: hpet clocksource has been installed. I rebooted with "clocksource=tsc" to get the logs of the trace which was added. I'm assuming the grep below gets all the interesting parts. I enabled the HPET character device as mentioned before, which is why the hpet0 lines appear now. # dmesg | egrep -i "(hpet|time|clock)" ACPI: HPET 37FE7400, 0038 (r1 RS690 AWRDACPI 42302E31 AWRD 98) ATI board detected. Disabling timer routing over 8254. ACPI: PM-Timer IO Port: 0x4008 ACPI: HPET id: 0x10b9a201 base: 0xfed0 Kernel command line: vga=0x31a root=/dev/sda1 ro clocksource=tsc HPET check: t1=5 t2=1139 s=56226339975 n=56226539985 hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0 hpet0: 4 32-bit timers, 14318180 Hz Calibrating delay using timer specific routine.. 4927.58 BogoMIPS (lpj=9855168) ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 Time: tsc clocksource has been installed. PCI: Setting latency timer of device :00:06.0 to 64 Real Time Clock Driver v1.12ac hpet_resources: 0xfed0 is busy Clocksource tsc unstable (delta = 459979812 ns) Software Watchdog Timer: 0.07 initialized. soft_noboot=0 soft_margin=60 sec (nowayout= 0) PCI: Setting latency timer of device :02:00.0 to 64 I ran a 'sleep 1', which hung as expected when I installed hpet as the clocksource via /sys. I dumped the sysrq trace showing where it was hung: Jan 16 14:44:48 am2 kernel: sleep S f582df68 0 2205 2155 Jan 16 14:44:48 am2 kernel:f582df50 0086 c1706e80 f582df68 c1706f04 c1706e78 c01371be Jan 16 14:44:48 am2 kernel:c17f8ab0 c17f8bf4 c1709a40 f7077200 0286 c0137803 0001 Jan 16 14:44:43 am2 kernel:c1706e78 0286 f582df68 f582c020 f582c000 c03ac8d3 Jan 16 14:44:43 am2 kernel: Call Trace: Jan 16 14:44:48 am2 kernel: [] enqueue_hrtimer+0xd7/0xe2 Jan 16 14:44:48 am2 kernel: [] hrtimer_start+0xe8/0xf4 Jan 16 14:44:48 am2 kernel: [] do_nanosleep+0x48/0x73 Jan 16 14:44:48 am2 kernel: [] hrtimer_nanosleep_restart+0x34/0xa1 Jan 16 14:44:48 am2 kernel: [] hrtimer_wakeup+0x0/0x18 Jan 16 14:44:48 am2 kernel: [] sys_restart_syscall+0xe/0xf Jan 16 14:44:48 am2 kernel: [] sysenter_past_esp+0x5f/0x85 My 'cron' and 'atd' processes were also hung with this exact stack in 'enqueue_hrtimer'. Thanks, -Andrew On Jan 16, 2008 10:21 AM, Thomas Gleixner <[EMAIL PROTECTED]> wrote: > > > The hint is in the original report: > > > > > > Clocksource tsc unstable (delta = 500013666 ns) > > > > > > That means, that the TSC was counting, but HPET not. So it looks like > > > the HPET readout is stale. Which explains, why after switching to HPET > > > clocksource the time system gets hosed. > > > > > > I wonder why the HPET counter works check did not catch this. > > > > > > Can you please apply the path below and provide the output ? > > This time against 2.6.23 > > Thanks, > tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
On Wed, 16 Jan 2008, Thomas Gleixner wrote:
> On Wed, 16 Jan 2008, Thomas Gleixner wrote:
>
> > On Sun, 13 Jan 2008, Dhaval Giani wrote:
> > > On Sun, Jan 13, 2008 at 08:10:46AM -0500, Andrew Paprocki wrote:
> > > > I applied the patch to my 2.6.23.13 tree and upon reboot it stopped
> > > > right after:
> > > >
> > > > Clocksource tsc unstable (delta = ... ns)
> > > > Time: hpet clocksource has been installed.
> > > >
> > > > It locked up hard.. cursor stopped blinking and SysRq isn't working
> > > > either.
> >
> > The hint is in the original report:
> >
> > Clocksource tsc unstable (delta = 500013666 ns)
> >
> > That means, that the TSC was counting, but HPET not. So it looks like
> > the HPET readout is stale. Which explains, why after switching to HPET
> > clocksource the time system gets hosed.
> >
> > I wonder why the HPET counter works check did not catch this.
> >
> > Can you please apply the path below and provide the output ?
This time against 2.6.23
Thanks,
tglx
--- a/arch/i386/kernel/hpet.c
+++ b/arch/i386/kernel/hpet.c
@@ -233,7 +233,7 @@ int __init hpet_enable(void)
unsigned long id;
uint64_t hpet_freq;
u64 tmp, start, now;
- cycle_t t1;
+ cycle_t t1, t2;
if (!is_hpet_capable())
return 0;
@@ -295,12 +295,17 @@ int __init hpet_enable(void)
rdtscll(now);
} while ((now - start) < 20UL);
- if (t1 == read_hpet()) {
+ t2 = read_hpet();
+ if (t1 == t2) {
printk(KERN_WARNING
"HPET counter not counting. HPET disabled\n");
goto out_nohpet;
}
+ printk(KERN_INFO "HPET check: t1=%llu t2=%llu s=%llu n=%llu\n",
+ (unsigned long long) t1, (unsigned long long) t2,
+ (unsigned long long) start, (unsigned long long) now);
+
/* Initialize and register HPET clocksource
*
* hpet period is in femto seconds per cycle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
On Wed, 16 Jan 2008, Thomas Gleixner wrote: > On Sun, 13 Jan 2008, Dhaval Giani wrote: > > On Sun, Jan 13, 2008 at 08:10:46AM -0500, Andrew Paprocki wrote: > > > I applied the patch to my 2.6.23.13 tree and upon reboot it stopped right > > > after: > > > > > > Clocksource tsc unstable (delta = ... ns) > > > Time: hpet clocksource has been installed. > > > > > > It locked up hard.. cursor stopped blinking and SysRq isn't working > > > either. > > The hint is in the original report: > > Clocksource tsc unstable (delta = 500013666 ns) > > That means, that the TSC was counting, but HPET not. So it looks like > the HPET readout is stale. Which explains, why after switching to HPET > clocksource the time system gets hosed. > > I wonder why the HPET counter works check did not catch this. > > Can you please apply the path below and provide the output ? Oh. Stupid me. This is 2.6.23. So the patch won't apply. Andrew, can you please check, whether 2.6.24-rc8 works on your machine ? I look into a backport fix for 2.6.23 later. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
On Sun, 13 Jan 2008, Dhaval Giani wrote:
> On Sun, Jan 13, 2008 at 08:10:46AM -0500, Andrew Paprocki wrote:
> > I applied the patch to my 2.6.23.13 tree and upon reboot it stopped right
> > after:
> >
> > Clocksource tsc unstable (delta = ... ns)
> > Time: hpet clocksource has been installed.
> >
> > It locked up hard.. cursor stopped blinking and SysRq isn't working either.
The hint is in the original report:
Clocksource tsc unstable (delta = 500013666 ns)
That means, that the TSC was counting, but HPET not. So it looks like
the HPET readout is stale. Which explains, why after switching to HPET
clocksource the time system gets hosed.
I wonder why the HPET counter works check did not catch this.
Can you please apply the path below and provide the output ?
Thanks,
tglx
Index: linux-2.6/arch/x86/kernel/hpet.c
===
--- linux-2.6.orig/arch/x86/kernel/hpet.c 2008-01-16 08:29:28.0
+0100
+++ linux-2.6/arch/x86/kernel/hpet.c2008-01-16 15:13:19.0 +0100
@@ -323,7 +323,7 @@ static struct clocksource clocksource_hp
static int hpet_clocksource_register(void)
{
u64 tmp, start, now;
- cycle_t t1;
+ cycle_t t1, t2;
/* Start the counter */
hpet_start_counter();
@@ -343,12 +343,17 @@ static int hpet_clocksource_register(voi
rdtscll(now);
} while ((now - start) < 20UL);
- if (t1 == read_hpet()) {
+ t2 = read_hpet();
+ if (t1 == t2) {
printk(KERN_WARNING
"HPET counter not counting. HPET disabled\n");
return -ENODEV;
}
+ printk(KERN_INFO "HPET check: t1=%lu t2=%lu s=%lu n=%lu\n",
+ (unsigned long) t1, (unsigned long) t2,
+ (unsigned long) start, (unsigned long) now);
+
/* Initialize and register HPET clocksource
*
* hpet period is in femto seconds per cycle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
On Sun, 13 Jan 2008, Dhaval Giani wrote:
On Sun, Jan 13, 2008 at 08:10:46AM -0500, Andrew Paprocki wrote:
I applied the patch to my 2.6.23.13 tree and upon reboot it stopped right
after:
Clocksource tsc unstable (delta = ... ns)
Time: hpet clocksource has been installed.
It locked up hard.. cursor stopped blinking and SysRq isn't working either.
The hint is in the original report:
Clocksource tsc unstable (delta = 500013666 ns)
That means, that the TSC was counting, but HPET not. So it looks like
the HPET readout is stale. Which explains, why after switching to HPET
clocksource the time system gets hosed.
I wonder why the HPET counter works check did not catch this.
Can you please apply the path below and provide the output ?
Thanks,
tglx
Index: linux-2.6/arch/x86/kernel/hpet.c
===
--- linux-2.6.orig/arch/x86/kernel/hpet.c 2008-01-16 08:29:28.0
+0100
+++ linux-2.6/arch/x86/kernel/hpet.c2008-01-16 15:13:19.0 +0100
@@ -323,7 +323,7 @@ static struct clocksource clocksource_hp
static int hpet_clocksource_register(void)
{
u64 tmp, start, now;
- cycle_t t1;
+ cycle_t t1, t2;
/* Start the counter */
hpet_start_counter();
@@ -343,12 +343,17 @@ static int hpet_clocksource_register(voi
rdtscll(now);
} while ((now - start) 20UL);
- if (t1 == read_hpet()) {
+ t2 = read_hpet();
+ if (t1 == t2) {
printk(KERN_WARNING
HPET counter not counting. HPET disabled\n);
return -ENODEV;
}
+ printk(KERN_INFO HPET check: t1=%lu t2=%lu s=%lu n=%lu\n,
+ (unsigned long) t1, (unsigned long) t2,
+ (unsigned long) start, (unsigned long) now);
+
/* Initialize and register HPET clocksource
*
* hpet period is in femto seconds per cycle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
On Wed, 16 Jan 2008, Thomas Gleixner wrote: On Sun, 13 Jan 2008, Dhaval Giani wrote: On Sun, Jan 13, 2008 at 08:10:46AM -0500, Andrew Paprocki wrote: I applied the patch to my 2.6.23.13 tree and upon reboot it stopped right after: Clocksource tsc unstable (delta = ... ns) Time: hpet clocksource has been installed. It locked up hard.. cursor stopped blinking and SysRq isn't working either. The hint is in the original report: Clocksource tsc unstable (delta = 500013666 ns) That means, that the TSC was counting, but HPET not. So it looks like the HPET readout is stale. Which explains, why after switching to HPET clocksource the time system gets hosed. I wonder why the HPET counter works check did not catch this. Can you please apply the path below and provide the output ? Oh. Stupid me. This is 2.6.23. So the patch won't apply. Andrew, can you please check, whether 2.6.24-rc8 works on your machine ? I look into a backport fix for 2.6.23 later. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
On Wed, 16 Jan 2008, Thomas Gleixner wrote:
On Wed, 16 Jan 2008, Thomas Gleixner wrote:
On Sun, 13 Jan 2008, Dhaval Giani wrote:
On Sun, Jan 13, 2008 at 08:10:46AM -0500, Andrew Paprocki wrote:
I applied the patch to my 2.6.23.13 tree and upon reboot it stopped
right after:
Clocksource tsc unstable (delta = ... ns)
Time: hpet clocksource has been installed.
It locked up hard.. cursor stopped blinking and SysRq isn't working
either.
The hint is in the original report:
Clocksource tsc unstable (delta = 500013666 ns)
That means, that the TSC was counting, but HPET not. So it looks like
the HPET readout is stale. Which explains, why after switching to HPET
clocksource the time system gets hosed.
I wonder why the HPET counter works check did not catch this.
Can you please apply the path below and provide the output ?
This time against 2.6.23
Thanks,
tglx
--- a/arch/i386/kernel/hpet.c
+++ b/arch/i386/kernel/hpet.c
@@ -233,7 +233,7 @@ int __init hpet_enable(void)
unsigned long id;
uint64_t hpet_freq;
u64 tmp, start, now;
- cycle_t t1;
+ cycle_t t1, t2;
if (!is_hpet_capable())
return 0;
@@ -295,12 +295,17 @@ int __init hpet_enable(void)
rdtscll(now);
} while ((now - start) 20UL);
- if (t1 == read_hpet()) {
+ t2 = read_hpet();
+ if (t1 == t2) {
printk(KERN_WARNING
HPET counter not counting. HPET disabled\n);
goto out_nohpet;
}
+ printk(KERN_INFO HPET check: t1=%llu t2=%llu s=%llu n=%llu\n,
+ (unsigned long long) t1, (unsigned long long) t2,
+ (unsigned long long) start, (unsigned long long) now);
+
/* Initialize and register HPET clocksource
*
* hpet period is in femto seconds per cycle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
I applied the patch and I am still locking up after Time: hpet clocksource has been installed. I rebooted with clocksource=tsc to get the logs of the trace which was added. I'm assuming the grep below gets all the interesting parts. I enabled the HPET character device as mentioned before, which is why the hpet0 lines appear now. # dmesg | egrep -i (hpet|time|clock) ACPI: HPET 37FE7400, 0038 (r1 RS690 AWRDACPI 42302E31 AWRD 98) ATI board detected. Disabling timer routing over 8254. ACPI: PM-Timer IO Port: 0x4008 ACPI: HPET id: 0x10b9a201 base: 0xfed0 Kernel command line: vga=0x31a root=/dev/sda1 ro clocksource=tsc HPET check: t1=5 t2=1139 s=56226339975 n=56226539985 hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0 hpet0: 4 32-bit timers, 14318180 Hz Calibrating delay using timer specific routine.. 4927.58 BogoMIPS (lpj=9855168) ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 Time: tsc clocksource has been installed. PCI: Setting latency timer of device :00:06.0 to 64 Real Time Clock Driver v1.12ac hpet_resources: 0xfed0 is busy Clocksource tsc unstable (delta = 459979812 ns) Software Watchdog Timer: 0.07 initialized. soft_noboot=0 soft_margin=60 sec (nowayout= 0) PCI: Setting latency timer of device :02:00.0 to 64 I ran a 'sleep 1', which hung as expected when I installed hpet as the clocksource via /sys. I dumped the sysrq trace showing where it was hung: Jan 16 14:44:48 am2 kernel: sleep S f582df68 0 2205 2155 Jan 16 14:44:48 am2 kernel:f582df50 0086 c1706e80 f582df68 c1706f04 c1706e78 c01371be Jan 16 14:44:48 am2 kernel:c17f8ab0 c17f8bf4 c1709a40 f7077200 0286 c0137803 0001 Jan 16 14:44:43 am2 kernel:c1706e78 0286 f582df68 f582c020 f582c000 c03ac8d3 Jan 16 14:44:43 am2 kernel: Call Trace: Jan 16 14:44:48 am2 kernel: [c01371be] enqueue_hrtimer+0xd7/0xe2 Jan 16 14:44:48 am2 kernel: [c0137803] hrtimer_start+0xe8/0xf4 Jan 16 14:44:48 am2 kernel: [c03ac8d3] do_nanosleep+0x48/0x73 Jan 16 14:44:48 am2 kernel: [c03ac932] hrtimer_nanosleep_restart+0x34/0xa1 Jan 16 14:44:48 am2 kernel: [c013735d] hrtimer_wakeup+0x0/0x18 Jan 16 14:44:48 am2 kernel: [c012e837] sys_restart_syscall+0xe/0xf Jan 16 14:44:48 am2 kernel: [c0103d0a] sysenter_past_esp+0x5f/0x85 My 'cron' and 'atd' processes were also hung with this exact stack in 'enqueue_hrtimer'. Thanks, -Andrew On Jan 16, 2008 10:21 AM, Thomas Gleixner [EMAIL PROTECTED] wrote: The hint is in the original report: Clocksource tsc unstable (delta = 500013666 ns) That means, that the TSC was counting, but HPET not. So it looks like the HPET readout is stale. Which explains, why after switching to HPET clocksource the time system gets hosed. I wonder why the HPET counter works check did not catch this. Can you please apply the path below and provide the output ? This time against 2.6.23 Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
On Monday 14 January 2008 06:29:27 pm Clemens Ladisch wrote: > Andrew Paprocki wrote: > > I started debugging a problem I was having with my sky2 network driver > > under 2.6.23.13. The investigation led me to find that the HPET timer > > wasn't working at all, causing the sky2 driver to not work properly. > > Simple example: > > > > am2:/sys/devices/system/clocksource/clocksource0# echo hpet > > > current_clocksource am2:/sys/devices/system/clocksource/clocksource0# > > time sleep 1 > > > > > > Running strace shows it blocked on nanosleep(). I'm building the > > kernel with the processor type set to Athalon64. I've built it with > > and without SMP and high-res timers enabled and I get the same result. > > My previous 2.6.18-4 kernel works because it does not install HPET as > > the default timer. The same behavior occurs in 2.6.24-rc7 git head. > > I've attached the config/dmesg below. > > > > Under 2.6.18-4 (Debian stock kernel): > > > > ACPI: HPET id: 0x10b9a201 base: 0xfed0 > > hpet0: at MMIO 0xfed0 (virtual 0xf880), IRQs 2, 8, 0, 0 > > hpet0: 4 32-bit timers, 14318180 Hz > > Using HPET for base-timer > > hpet_resources: 0xfed0 is busy > > Time: tsc clocksource has been installed. > > > > Under 2.6.23.13 w/ SMP: > > > > ACPI: HPET 37FE7400, 0038 (r1 RS690 AWRDACPI 42302E31 AWRD 98) > > ACPI: HPET id: 0x10b9a201 base: 0xfed0 > > Time: tsc clocksource has been installed. > > Clocksource tsc unstable (delta = 500013666 ns) > > Time: hpet clocksource has been installed. > > The lines prefixed with "hpet0:" are missing; apparently, hpet_alloc() > was never called because hpet_reserve_platform_timers() is disabled > because CONFIG_HPET is not set. Try enabling this option. (CONFIG_HPET > is in the "Character Devices" kernel config menu.) > > That this option would be required to get the platform HPET code to work > seems like a bug. > This doesn't seem to be the issue, as I have not been able to reproduce the bug on my Core 2 system with the same config. HPET clocksource works fine with only CONFIG_HPET_TIMER. > > Regards, > Clemens > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
Andrew Paprocki wrote: > I started debugging a problem I was having with my sky2 network driver > under 2.6.23.13. The investigation led me to find that the HPET timer > wasn't working at all, causing the sky2 driver to not work properly. > Simple example: > > am2:/sys/devices/system/clocksource/clocksource0# echo hpet > > current_clocksource > am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 > > > Running strace shows it blocked on nanosleep(). I'm building the > kernel with the processor type set to Athalon64. I've built it with > and without SMP and high-res timers enabled and I get the same result. > My previous 2.6.18-4 kernel works because it does not install HPET as > the default timer. The same behavior occurs in 2.6.24-rc7 git head. > I've attached the config/dmesg below. > > Under 2.6.18-4 (Debian stock kernel): > > ACPI: HPET id: 0x10b9a201 base: 0xfed0 > hpet0: at MMIO 0xfed0 (virtual 0xf880), IRQs 2, 8, 0, 0 > hpet0: 4 32-bit timers, 14318180 Hz > Using HPET for base-timer > hpet_resources: 0xfed0 is busy > Time: tsc clocksource has been installed. > > Under 2.6.23.13 w/ SMP: > > ACPI: HPET 37FE7400, 0038 (r1 RS690 AWRDACPI 42302E31 AWRD 98) > ACPI: HPET id: 0x10b9a201 base: 0xfed0 > Time: tsc clocksource has been installed. > Clocksource tsc unstable (delta = 500013666 ns) > Time: hpet clocksource has been installed. The lines prefixed with "hpet0:" are missing; apparently, hpet_alloc() was never called because hpet_reserve_platform_timers() is disabled because CONFIG_HPET is not set. Try enabling this option. (CONFIG_HPET is in the "Character Devices" kernel config menu.) That this option would be required to get the platform HPET code to work seems like a bug. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
Andrew Paprocki wrote: I started debugging a problem I was having with my sky2 network driver under 2.6.23.13. The investigation led me to find that the HPET timer wasn't working at all, causing the sky2 driver to not work properly. Simple example: am2:/sys/devices/system/clocksource/clocksource0# echo hpet current_clocksource am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 hangs indefinetly... Running strace shows it blocked on nanosleep(). I'm building the kernel with the processor type set to Athalon64. I've built it with and without SMP and high-res timers enabled and I get the same result. My previous 2.6.18-4 kernel works because it does not install HPET as the default timer. The same behavior occurs in 2.6.24-rc7 git head. I've attached the config/dmesg below. Under 2.6.18-4 (Debian stock kernel): ACPI: HPET id: 0x10b9a201 base: 0xfed0 hpet0: at MMIO 0xfed0 (virtual 0xf880), IRQs 2, 8, 0, 0 hpet0: 4 32-bit timers, 14318180 Hz Using HPET for base-timer hpet_resources: 0xfed0 is busy Time: tsc clocksource has been installed. Under 2.6.23.13 w/ SMP: ACPI: HPET 37FE7400, 0038 (r1 RS690 AWRDACPI 42302E31 AWRD 98) ACPI: HPET id: 0x10b9a201 base: 0xfed0 Time: tsc clocksource has been installed. Clocksource tsc unstable (delta = 500013666 ns) Time: hpet clocksource has been installed. The lines prefixed with hpet0: are missing; apparently, hpet_alloc() was never called because hpet_reserve_platform_timers() is disabled because CONFIG_HPET is not set. Try enabling this option. (CONFIG_HPET is in the Character Devices kernel config menu.) That this option would be required to get the platform HPET code to work seems like a bug. Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
On Monday 14 January 2008 06:29:27 pm Clemens Ladisch wrote: Andrew Paprocki wrote: I started debugging a problem I was having with my sky2 network driver under 2.6.23.13. The investigation led me to find that the HPET timer wasn't working at all, causing the sky2 driver to not work properly. Simple example: am2:/sys/devices/system/clocksource/clocksource0# echo hpet current_clocksource am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 hangs indefinetly... Running strace shows it blocked on nanosleep(). I'm building the kernel with the processor type set to Athalon64. I've built it with and without SMP and high-res timers enabled and I get the same result. My previous 2.6.18-4 kernel works because it does not install HPET as the default timer. The same behavior occurs in 2.6.24-rc7 git head. I've attached the config/dmesg below. Under 2.6.18-4 (Debian stock kernel): ACPI: HPET id: 0x10b9a201 base: 0xfed0 hpet0: at MMIO 0xfed0 (virtual 0xf880), IRQs 2, 8, 0, 0 hpet0: 4 32-bit timers, 14318180 Hz Using HPET for base-timer hpet_resources: 0xfed0 is busy Time: tsc clocksource has been installed. Under 2.6.23.13 w/ SMP: ACPI: HPET 37FE7400, 0038 (r1 RS690 AWRDACPI 42302E31 AWRD 98) ACPI: HPET id: 0x10b9a201 base: 0xfed0 Time: tsc clocksource has been installed. Clocksource tsc unstable (delta = 500013666 ns) Time: hpet clocksource has been installed. The lines prefixed with hpet0: are missing; apparently, hpet_alloc() was never called because hpet_reserve_platform_timers() is disabled because CONFIG_HPET is not set. Try enabling this option. (CONFIG_HPET is in the Character Devices kernel config menu.) That this option would be required to get the platform HPET code to work seems like a bug. This doesn't seem to be the issue, as I have not been able to reproduce the bug on my Core 2 system with the same config. HPET clocksource works fine with only CONFIG_HPET_TIMER. Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
On Sun, Jan 13, 2008 at 08:10:46AM -0500, Andrew Paprocki wrote: > I applied the patch to my 2.6.23.13 tree and upon reboot it stopped right > after: > > Clocksource tsc unstable (delta = ... ns) > Time: hpet clocksource has been installed. > > It locked up hard.. cursor stopped blinking and SysRq isn't working either. > It obviously is the wrong fix then :). Adding a few cc's. Hopefully they will know what to do better than me. > -Andrew > > On Jan 13, 2008 7:03 AM, Dhaval Giani <[EMAIL PROTECTED]> wrote: > > > > On Sun, Jan 13, 2008 at 06:10:52AM -0500, Andrew Paprocki wrote: > > > I started debugging a problem I was having with my sky2 network driver > > > under 2.6.23.13. The investigation led me to find that the HPET timer > > > wasn't working at all, causing the sky2 driver to not work properly. > > > Simple example: > > > > > > am2:/sys/devices/system/clocksource/clocksource0# cat current_clocksource > > > jiffies > > > am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 > > > real0m1.000s > > > user0m0.000s > > > sys 0m0.000s > > > am2:/sys/devices/system/clocksource/clocksource0# echo tsc > > > > current_clocksource > > > am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 > > > real0m1.005s > > > user0m0.004s > > > sys 0m0.000s > > > am2:/sys/devices/system/clocksource/clocksource0# echo hpet > > > > current_clocksource > > > am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 > > > > > > > > > Running strace shows it blocked on nanosleep(). I'm building the > > > kernel with the processor type set to Athalon64. I've built it with > > > and without SMP and high-res timers enabled and I get the same result. > > > My previous 2.6.18-4 kernel works because it does not install HPET as > > > the default timer. The same behavior occurs in 2.6.24-rc7 git head. > > > I've attached the config/dmesg below. > > > > > > > It seems the HPET timer was not being assigned any IRQs at all. Can you > > try the patch at http://lkml.org/lkml/2008/1/12/128 ? > > > > Thanks, > > -- > > regards, > > Dhaval > > > > -- regards, Dhaval -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
I applied the patch to my 2.6.23.13 tree and upon reboot it stopped right after: Clocksource tsc unstable (delta = ... ns) Time: hpet clocksource has been installed. It locked up hard.. cursor stopped blinking and SysRq isn't working either. -Andrew On Jan 13, 2008 7:03 AM, Dhaval Giani <[EMAIL PROTECTED]> wrote: > > On Sun, Jan 13, 2008 at 06:10:52AM -0500, Andrew Paprocki wrote: > > I started debugging a problem I was having with my sky2 network driver > > under 2.6.23.13. The investigation led me to find that the HPET timer > > wasn't working at all, causing the sky2 driver to not work properly. > > Simple example: > > > > am2:/sys/devices/system/clocksource/clocksource0# cat current_clocksource > > jiffies > > am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 > > real0m1.000s > > user0m0.000s > > sys 0m0.000s > > am2:/sys/devices/system/clocksource/clocksource0# echo tsc > > > current_clocksource > > am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 > > real0m1.005s > > user0m0.004s > > sys 0m0.000s > > am2:/sys/devices/system/clocksource/clocksource0# echo hpet > > > current_clocksource > > am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 > > > > > > Running strace shows it blocked on nanosleep(). I'm building the > > kernel with the processor type set to Athalon64. I've built it with > > and without SMP and high-res timers enabled and I get the same result. > > My previous 2.6.18-4 kernel works because it does not install HPET as > > the default timer. The same behavior occurs in 2.6.24-rc7 git head. > > I've attached the config/dmesg below. > > > > It seems the HPET timer was not being assigned any IRQs at all. Can you > try the patch at http://lkml.org/lkml/2008/1/12/128 ? > > Thanks, > -- > regards, > Dhaval > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
On Sun, Jan 13, 2008 at 06:10:52AM -0500, Andrew Paprocki wrote: > I started debugging a problem I was having with my sky2 network driver > under 2.6.23.13. The investigation led me to find that the HPET timer > wasn't working at all, causing the sky2 driver to not work properly. > Simple example: > > am2:/sys/devices/system/clocksource/clocksource0# cat current_clocksource > jiffies > am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 > real0m1.000s > user0m0.000s > sys 0m0.000s > am2:/sys/devices/system/clocksource/clocksource0# echo tsc > > current_clocksource > am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 > real0m1.005s > user0m0.004s > sys 0m0.000s > am2:/sys/devices/system/clocksource/clocksource0# echo hpet > > current_clocksource > am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 > > > Running strace shows it blocked on nanosleep(). I'm building the > kernel with the processor type set to Athalon64. I've built it with > and without SMP and high-res timers enabled and I get the same result. > My previous 2.6.18-4 kernel works because it does not install HPET as > the default timer. The same behavior occurs in 2.6.24-rc7 git head. > I've attached the config/dmesg below. > It seems the HPET timer was not being assigned any IRQs at all. Can you try the patch at http://lkml.org/lkml/2008/1/12/128 ? Thanks, -- regards, Dhaval -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
On Sun, Jan 13, 2008 at 06:10:52AM -0500, Andrew Paprocki wrote: I started debugging a problem I was having with my sky2 network driver under 2.6.23.13. The investigation led me to find that the HPET timer wasn't working at all, causing the sky2 driver to not work properly. Simple example: am2:/sys/devices/system/clocksource/clocksource0# cat current_clocksource jiffies am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 real0m1.000s user0m0.000s sys 0m0.000s am2:/sys/devices/system/clocksource/clocksource0# echo tsc current_clocksource am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 real0m1.005s user0m0.004s sys 0m0.000s am2:/sys/devices/system/clocksource/clocksource0# echo hpet current_clocksource am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 hangs indefinetly... Running strace shows it blocked on nanosleep(). I'm building the kernel with the processor type set to Athalon64. I've built it with and without SMP and high-res timers enabled and I get the same result. My previous 2.6.18-4 kernel works because it does not install HPET as the default timer. The same behavior occurs in 2.6.24-rc7 git head. I've attached the config/dmesg below. It seems the HPET timer was not being assigned any IRQs at all. Can you try the patch at http://lkml.org/lkml/2008/1/12/128 ? Thanks, -- regards, Dhaval -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
I applied the patch to my 2.6.23.13 tree and upon reboot it stopped right after: Clocksource tsc unstable (delta = ... ns) Time: hpet clocksource has been installed. It locked up hard.. cursor stopped blinking and SysRq isn't working either. -Andrew On Jan 13, 2008 7:03 AM, Dhaval Giani [EMAIL PROTECTED] wrote: On Sun, Jan 13, 2008 at 06:10:52AM -0500, Andrew Paprocki wrote: I started debugging a problem I was having with my sky2 network driver under 2.6.23.13. The investigation led me to find that the HPET timer wasn't working at all, causing the sky2 driver to not work properly. Simple example: am2:/sys/devices/system/clocksource/clocksource0# cat current_clocksource jiffies am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 real0m1.000s user0m0.000s sys 0m0.000s am2:/sys/devices/system/clocksource/clocksource0# echo tsc current_clocksource am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 real0m1.005s user0m0.004s sys 0m0.000s am2:/sys/devices/system/clocksource/clocksource0# echo hpet current_clocksource am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 hangs indefinetly... Running strace shows it blocked on nanosleep(). I'm building the kernel with the processor type set to Athalon64. I've built it with and without SMP and high-res timers enabled and I get the same result. My previous 2.6.18-4 kernel works because it does not install HPET as the default timer. The same behavior occurs in 2.6.24-rc7 git head. I've attached the config/dmesg below. It seems the HPET timer was not being assigned any IRQs at all. Can you try the patch at http://lkml.org/lkml/2008/1/12/128 ? Thanks, -- regards, Dhaval -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs
On Sun, Jan 13, 2008 at 08:10:46AM -0500, Andrew Paprocki wrote: I applied the patch to my 2.6.23.13 tree and upon reboot it stopped right after: Clocksource tsc unstable (delta = ... ns) Time: hpet clocksource has been installed. It locked up hard.. cursor stopped blinking and SysRq isn't working either. It obviously is the wrong fix then :). Adding a few cc's. Hopefully they will know what to do better than me. -Andrew On Jan 13, 2008 7:03 AM, Dhaval Giani [EMAIL PROTECTED] wrote: On Sun, Jan 13, 2008 at 06:10:52AM -0500, Andrew Paprocki wrote: I started debugging a problem I was having with my sky2 network driver under 2.6.23.13. The investigation led me to find that the HPET timer wasn't working at all, causing the sky2 driver to not work properly. Simple example: am2:/sys/devices/system/clocksource/clocksource0# cat current_clocksource jiffies am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 real0m1.000s user0m0.000s sys 0m0.000s am2:/sys/devices/system/clocksource/clocksource0# echo tsc current_clocksource am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 real0m1.005s user0m0.004s sys 0m0.000s am2:/sys/devices/system/clocksource/clocksource0# echo hpet current_clocksource am2:/sys/devices/system/clocksource/clocksource0# time sleep 1 hangs indefinetly... Running strace shows it blocked on nanosleep(). I'm building the kernel with the processor type set to Athalon64. I've built it with and without SMP and high-res timers enabled and I get the same result. My previous 2.6.18-4 kernel works because it does not install HPET as the default timer. The same behavior occurs in 2.6.24-rc7 git head. I've attached the config/dmesg below. It seems the HPET timer was not being assigned any IRQs at all. Can you try the patch at http://lkml.org/lkml/2008/1/12/128 ? Thanks, -- regards, Dhaval -- regards, Dhaval -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
