Hmm... GPF seems to be related to unclean %rcx. Can you please
try the attached patch? Please note you have to rebuild kernel
from scratch because this is a header file change. It may not fix
"hang", though. Please let me know.
It is just committed at r223796.
JK
This issue is resolved
On Wednesday 29 June 2011 05:50 pm, Matt wrote:
> On 06/23/11 08:25, Jung-uk Kim wrote:
> > On Thursday 23 June 2011 04:21 am, Ian FREISLICH wrote:
> >> Jung-uk Kim wrote:
> >>> On Tuesday 21 June 2011 04:53 pm, Jung-uk Kim wrote:
> Can you please try the attached patch? It should disable
On 06/23/11 08:25, Jung-uk Kim wrote:
On Thursday 23 June 2011 04:21 am, Ian FREISLICH wrote:
Jung-uk Kim wrote:
On Tuesday 21 June 2011 04:53 pm, Jung-uk Kim wrote:
Can you please try the attached patch? It should disable
TSC/TSC-low timecounter for your CPU models, I think.
Sorry, I
On Thursday 23 June 2011 04:21 am, Ian FREISLICH wrote:
> Jung-uk Kim wrote:
> > On Tuesday 21 June 2011 04:53 pm, Jung-uk Kim wrote:
> > > Can you please try the attached patch? It should disable
> > > TSC/TSC-low timecounter for your CPU models, I think.
> >
> > Sorry, I attached a wrong patch.
Jung-uk Kim wrote:
> On Tuesday 21 June 2011 04:53 pm, Jung-uk Kim wrote:
> > Can you please try the attached patch? It should disable
> > TSC/TSC-low timecounter for your CPU models, I think.
>
> Sorry, I attached a wrong patch. Please ignore the previous one and
> try this, instead.
TSC-low
Jung-uk Kim wrote:
> On Tuesday 21 June 2011 04:53 pm, Jung-uk Kim wrote:
> > Can you please try the attached patch? It should disable
> > TSC/TSC-low timecounter for your CPU models, I think.
>
> Sorry, I attached a wrong patch. Please ignore the previous one and
> try this, instead.
Works
On Tuesday 21 June 2011 04:53 pm, Jung-uk Kim wrote:
> Can you please try the attached patch? It should disable
> TSC/TSC-low timecounter for your CPU models, I think.
Sorry, I attached a wrong patch. Please ignore the previous one and
try this, instead.
Jung-uk Kim
Index: sys/dev/acpica/acpi_
On Friday 17 June 2011 02:54 pm, Jung-uk Kim wrote:
> On Friday 17 June 2011 01:45 pm, Ian FREISLICH wrote:
> > Jung-uk Kim wrote:
> > > On Thursday 16 June 2011 03:10 am, Ian FREISLICH wrote:
> > > > Jung-uk Kim wrote:
> > > > > 1481522037144590601.0098392393
> > > > > 149596940414
On Friday 17 June 2011 01:45 pm, Ian FREISLICH wrote:
> Jung-uk Kim wrote:
> > On Thursday 16 June 2011 03:10 am, Ian FREISLICH wrote:
> > > Jung-uk Kim wrote:
> > > > 1481522037 144590601.0098392393
> > > > 1495969404 144473671.0090225853
> > > >
> > > > As you can see, H
Jung-uk Kim wrote:
> On Thursday 16 June 2011 03:10 am, Ian FREISLICH wrote:
> > Jung-uk Kim wrote:
> > > 1481522037144590601.0098392393
> > > 1495969404144473671.0090225853
> > >
> > > As you can see, HPET increases normally (within errors from
> > > sleep(3) accura
On Thursday 16 June 2011 03:10 am, Ian FREISLICH wrote:
> Jung-uk Kim wrote:
> > 1481522037 144590601.0098392393
> > 1495969404 144473671.0090225853
> >
> > As you can see, HPET increases normally (within errors from
> > sleep(3) accuracy, syscall overhead, etc.) but TSC-low is to
Jung-uk Kim wrote:
> On Wednesday 15 June 2011 06:19 pm, Jung-uk Kim wrote:
> > On Wednesday 15 June 2011 04:39 pm, Jung-uk Kim wrote:
> > > On Wednesday 15 June 2011 03:27 pm, Ian FREISLICH wrote:
> > > > > > The problem I noticed first is that it takes unusually long
> > > > > > until a key pre
Jung-uk Kim wrote:
> 1481522037144590601.0098392393
> 1495969404144473671.0090225853
>
> As you can see, HPET increases normally (within errors from sleep(3)
> accuracy, syscall overhead, etc.) but TSC-low is totally erratic (and
> too low). I don't know how this can hap
Jung-uk Kim wrote:
> On Wednesday 15 June 2011 03:27 pm, Ian FREISLICH wrote:
> > > Can you please show me verbose boot messages *without* your
> > > patch? Does "sysctl kern.timecounter.hardware=HPET" help
> > > *without* touching eventtimers?
> >
> > I have the same issue with my system (Atom N27
On Wednesday 15 June 2011 06:19 pm, Jung-uk Kim wrote:
> On Wednesday 15 June 2011 04:39 pm, Jung-uk Kim wrote:
> > On Wednesday 15 June 2011 03:27 pm, Ian FREISLICH wrote:
> > > > > The problem I noticed first is that it takes unusually long
> > > > > until a key press is repeated. With the defaul
On Wednesday 15 June 2011 04:39 pm, Jung-uk Kim wrote:
> On Wednesday 15 June 2011 03:27 pm, Ian FREISLICH wrote:
> > > > The problem I noticed first is that it takes unusually long
> > > > until a key press is repeated. With the default eventtimer
> > > > (HPET) it seems to take about 4s, which ca
On Wednesday 15 June 2011 03:27 pm, Ian FREISLICH wrote:
> > > The problem I noticed first is that it takes unusually long
> > > until a key press is repeated. With the default eventtimer
> > > (HPET) it seems to take about 4s, which can be slightly
> > > improved by switching to i8254.
> > >
> > >
> > The problem I noticed first is that it takes unusually long until a
> > key press is repeated. With the default eventtimer (HPET) it seems
> > to take about 4s, which can be slightly improved by switching to
> > i8254.
> >
> > The "error beep" seems to take longer than usual, too,
> > and the s
On Monday 13 June 2011 12:44 pm, Fabian Keil wrote:
> I'm experiencing time-related issues that seem to be caused by
> the low-resolution TSC timecounter (r222866).
>
> The problem I noticed first is that it takes unusually long until a
> key press is repeated. With the default eventtimer (HPET) it
19 matches
Mail list logo
