Hello,
Good day to you.I have a lucrative business proposal, which I believe we
could mutually benefit from. Please contact me on my private email address:
leslieholt...@gmail.com
Sincerely,
L.D Holt.
On 04.01.2021 18:39, Lukas Wunner wrote:
> On Thu, Dec 31, 2020 at 10:38:12AM +0100, Heiner Kallweit wrote:
>> On 31.12.2020 05:07, Lukas Wunner wrote:
>>> FWIW, if platform_pci_power_manageable() returns true, it can probably
>>> be assumed that allowing runtime PM by default is okay. So as a fir
On Thu, Dec 31, 2020 at 10:38:12AM +0100, Heiner Kallweit wrote:
> On 31.12.2020 05:07, Lukas Wunner wrote:
> > FWIW, if platform_pci_power_manageable() returns true, it can probably
> > be assumed that allowing runtime PM by default is okay. So as a first
> > step, you may want to call that inste
On 31.12.2020 10:38, Heiner Kallweit wrote:
> On 31.12.2020 05:07, Lukas Wunner wrote:
>> On Wed, Dec 30, 2020 at 11:56:04PM +0100, Heiner Kallweit wrote:
>>> --- a/drivers/pci/pci.c
>>> +++ b/drivers/pci/pci.c
>>> @@ -3024,7 +3024,9 @@ void pci_pm_init(struct pci_dev *dev)
>>> u16 status;
>>>
On 31.12.2020 05:07, Lukas Wunner wrote:
> On Wed, Dec 30, 2020 at 11:56:04PM +0100, Heiner Kallweit wrote:
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -3024,7 +3024,9 @@ void pci_pm_init(struct pci_dev *dev)
>> u16 status;
>> u16 pmc;
>>
>> -pm_runtime_forbid(&dev->
On Wed, Dec 30, 2020 at 11:56:04PM +0100, Heiner Kallweit wrote:
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3024,7 +3024,9 @@ void pci_pm_init(struct pci_dev *dev)
> u16 status;
> u16 pmc;
>
> - pm_runtime_forbid(&dev->dev);
> + if (pci_acpi_forbid_runtime_pm())
On 17.11.2020 17:57, Rafael J. Wysocki wrote:
> On Tue, Nov 17, 2020 at 5:38 PM Bjorn Helgaas wrote:
>>
>> [+to Rafael, author of the commit you mentioned,
>> +cc Mika, Kai Heng, Lukas, linux-pm, linux-kernel]
>>
>> On Tue, Nov 17, 2020 at 04:56:09PM +0100, Heiner Kallweit wrote:
>>> More than 10
On 29.12.2020 12:56, Kai-Heng Feng wrote:
> On Sat, Dec 26, 2020 at 11:26 PM Heiner Kallweit wrote:
>>
>> On 17.11.2020 17:57, Rafael J. Wysocki wrote:
>>> On Tue, Nov 17, 2020 at 5:38 PM Bjorn Helgaas wrote:
[+to Rafael, author of the commit you mentioned,
+cc Mika, Kai Heng, Luka
On Sat, Dec 26, 2020 at 11:26 PM Heiner Kallweit wrote:
>
> On 17.11.2020 17:57, Rafael J. Wysocki wrote:
> > On Tue, Nov 17, 2020 at 5:38 PM Bjorn Helgaas wrote:
> >>
> >> [+to Rafael, author of the commit you mentioned,
> >> +cc Mika, Kai Heng, Lukas, linux-pm, linux-kernel]
> >>
> >> On Tue, N
> On Tue, Nov 17, 2020 at 04:56:09PM +0100, Heiner Kallweit wrote:
> > With Runtime PM disabled e.g. the PHY on network devices may remain
> > powered up even with no cable plugged in, affecting battery lifetime
> > on mobile devices. Currently we have to rely on the respective distro
> > or user t
On 17.11.2020 17:57, Rafael J. Wysocki wrote:
> On Tue, Nov 17, 2020 at 5:38 PM Bjorn Helgaas wrote:
>>
>> [+to Rafael, author of the commit you mentioned,
>> +cc Mika, Kai Heng, Lukas, linux-pm, linux-kernel]
>>
>> On Tue, Nov 17, 2020 at 04:56:09PM +0100, Heiner Kallweit wrote:
>>> More than 10
On Tue, Nov 17, 2020 at 5:38 PM Bjorn Helgaas wrote:
>
> [+to Rafael, author of the commit you mentioned,
> +cc Mika, Kai Heng, Lukas, linux-pm, linux-kernel]
>
> On Tue, Nov 17, 2020 at 04:56:09PM +0100, Heiner Kallweit wrote:
> > More than 10 yrs ago Runtime PM was disabled per default by bb910a
[+to Rafael, author of the commit you mentioned,
+cc Mika, Kai Heng, Lukas, linux-pm, linux-kernel]
On Tue, Nov 17, 2020 at 04:56:09PM +0100, Heiner Kallweit wrote:
> More than 10 yrs ago Runtime PM was disabled per default by bb910a7040
> ("PCI/PM Runtime: Make runtime PM of PCI devices inactive
On Mon 2019-09-30 06:33:42, Sodagudi Prasad wrote:
> Hi All,
>
> From Qualcomm side, we would like to check with upstream team about adding
> Raw time stamp value to printk records. On Qualcomm soc, there are various
> DSPs subsystems are there - for example audio, video and modem DSPs.
> Adding r
Hi,
On (09/30/19 06:33), Sodagudi Prasad wrote:
> From Qualcomm side, we would like to check with upstream team about adding
> Raw time stamp value to printk records. On Qualcomm soc, there are various
> DSPs subsystems are there - for example audio, video and modem DSPs.
> Adding raw timer value(
On Mon, 30 Sep 2019 06:33:42 -0700
Sodagudi Prasad wrote:
> Hi All,
>
> From Qualcomm side, we would like to check with upstream team about
> adding Raw time stamp value to printk records. On Qualcomm soc, there
> are various DSPs subsystems are there - for example audio, video and
> modem D
On Fri, 21 Apr 2017, Andrey Konovalov wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7).
>
> A reproducer and .config are attached.
>
> The program hangs the kernel.
> lock_acquire+0x2
On Fri, 21 Apr 2017, Thomas Gleixner wrote:
> On Fri, 21 Apr 2017, Andrey Konovalov wrote:
> > Hi,
> >
> > I've got the following error report while fuzzing the kernel with syzkaller.
> >
> > On commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7).
> >
> > A reproducer and .config are atta
On 12/04/2015 06:49 AM, Dmitry Vyukov wrote:
>> I'm not so sure. It finds real bugs, e.g. 32a8df4e0b33f ("sched: Fix odd
>> values in effective_load() calculations")
>> > was caught by UBSAN
>> > I guess that we could fix most signed overflows simply by casting to
>> > unsigned type.
>
> Yeah, o
On Fri, Dec 4, 2015 at 12:44 PM, Andrey Ryabinin wrote:
Hello,
UBSAN reports undefined behavior in ktime_add_safe:
UBSAN: Undefined behaviour in kernel/time/hrtimer.c:310:16
signed integer overflow:
9223372036854775807 + 1 cannot be represented in type 'l
On 12/04/2015 02:33 PM, Dmitry Vyukov wrote:
> On Fri, Dec 4, 2015 at 12:32 PM, Andrey Ryabinin
> wrote:
>> On 12/04/2015 02:05 PM, Dmitry Vyukov wrote:
>>> Hello,
>>>
>>> UBSAN reports undefined behavior in ktime_add_safe:
>>>
>>> UBSAN: Undefined behaviour in kernel/time/hrtimer.c:310:16
>>>
On Fri, Dec 4, 2015 at 12:32 PM, Andrey Ryabinin wrote:
> On 12/04/2015 02:05 PM, Dmitry Vyukov wrote:
>> Hello,
>>
>> UBSAN reports undefined behavior in ktime_add_safe:
>>
>> UBSAN: Undefined behaviour in kernel/time/hrtimer.c:310:16
>> signed integer overflow:
>> 9223372036854775807 + 1
On 12/04/2015 02:05 PM, Dmitry Vyukov wrote:
> Hello,
>
> UBSAN reports undefined behavior in ktime_add_safe:
>
> UBSAN: Undefined behaviour in kernel/time/hrtimer.c:310:16
> signed integer overflow:
> 9223372036854775807 + 1 cannot be represented in type 'long long int'
> CPU: 3 PID: 264
Hello,
On Fri, Dec 4, 2015, at 12:05, Dmitry Vyukov wrote:
> UBSAN reports undefined behavior in ktime_add_safe:
>
> UBSAN: Undefined behaviour in kernel/time/hrtimer.c:310:16
> signed integer overflow:
> 9223372036854775807 + 1 cannot be represented in type 'long long
> int'
> CPU: 3 PID
- Original Message -
> From: "Nishanth Aravamudan"
> To: "John Stultz"
> Cc: "Thomas Gleixner" , "lkml"
> , jstan...@redhat.com, "Ingo Molnar"
>
> Sent: Thursday, 19 February, 2015 8:28:40 PM
> Subject: Re: time
Hi John!
On 19.02.2015 [11:03:26 -0800], John Stultz wrote:
> Hey Nish! Long time!
yep :)
> On Thu, Feb 19, 2015 at 10:35 AM, Nishanth Aravamudan
> wrote:
> > Hi John,
> >
> > We're seeing an interesting issue with the openposix testcase
> > difftime/1-1, which basically calls gtod/time, sleeps
* John Stultz wrote:
> > [ 313.001823] NACC: timekeeping_get_ns = 1000121642
> > [ 314.001889] NACC: timekeeping_get_ns = 188401
> >
> > gtod correctly accumulates those nsecs into the secs value:
> >
> > ts->tv_sec = tk->xtime_sec;
> > nsecs = timekeeping_get_n
Hey Nish! Long time!
On Thu, Feb 19, 2015 at 10:35 AM, Nishanth Aravamudan
wrote:
> Hi John,
>
> We're seeing an interesting issue with the openposix testcase
> difftime/1-1, which basically calls gtod/time, sleeps, calls time/gtod,
I'm not familiar with the test... Do you have a link?
> then d
On Wed, Nov 26, 2014 at 12:00 PM, Fengguang Wu wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>
> commit 6067dc5a8c2b1b57e67eaf1125db1d63c1ed6361
> Author: pang.xunle
Hi Xunlei,
FYI, here is another bisect result.
https://git.linaro.org/people/john.stultz/linux.git fortglx/3.19/time
commit 59fa38d60ca4bc7a2efffae1b40aa7960374ef9d
Author: pang.xunlei
AuthorDate: Wed Oct 8 15:03:34 2014 +0800
Commit: John Stultz
CommitDate: Thu Oct 23 21:26:24 2014 -0
erproject.org;
> a...@canonical.com; jasow...@redhat.com; KY Srinivasan; Haiyang Zhang
> Subject: Re: Time keeps on slipping... on Hyper-V
>
> > We still recommend user to configure NTP in the guest VM. With the new
> > time sync feature in this patch, you could have one more option
> We still recommend user to configure NTP in the guest VM. With the new time
> sync feature in this patch,
> you could have one more option to enable the guest-host sync, if the NTP
> didn't work in the environment.
> For example the guest VM didn't have network connection.
Microsoft used to us
el@vger.kernel.org;
> driverdev-de...@linuxdriverproject.org; a...@canonical.com;
> jasow...@redhat.com; KY Srinivasan; Haiyang Zhang
> Subject: Re: Time keeps on slipping... on Hyper-V
>
> On Thu, Sep 25, 2014 at 09:40:42AM +, Thomas Shao wrote:
> > > > On Tue, Sep 23, Tho
On Thu, Sep 25, 2014 at 09:40:42AM +, Thomas Shao wrote:
> > > On Tue, Sep 23, Thomas Shao wrote:
> > >
> > > with the host clock using host time sample. By default it is
> > > disabled, because we still recommend user to configure NTP for time
> >
> > -Original Message-
> > From: Sitso
On 2014-05-19 18:28, Ming Lei wrote:
On Mon, May 19, 2014 at 10:14 PM, Jens Axboe wrote:
On 05/19/2014 08:13 AM, Christoph Hellwig wrote:
I recently saw patches to fs/bio.c that were sent to Al instead of Jens.
I think having bio.c in fs/ is rather confusing, so maybe it's time to
include the
On Mon, May 19, 2014 at 10:14 PM, Jens Axboe wrote:
> On 05/19/2014 08:13 AM, Christoph Hellwig wrote:
>> I recently saw patches to fs/bio.c that were sent to Al instead of Jens.
>> I think having bio.c in fs/ is rather confusing, so maybe it's time to
>> include the simple git-mv for it in the yo
On 05/19/2014 10:39 AM, Al Viro wrote:
> On Mon, May 19, 2014 at 07:34:16AM -0700, Christoph Hellwig wrote:
>> On Mon, May 19, 2014 at 08:31:21AM -0600, Jens Axboe wrote:
While you are at it, could you take bio-integrity.c with it? _That_
has zero excuse being anywhere in fs/* - not even
On Mon, May 19, 2014 at 05:39:42PM +0100, Al Viro wrote:
> ACK on ioprio.c (BTW, looking at block... WTF is the story with that
> pile of blk-* in there? IOW, why blk-exec.c is better than exec.c,
> etc.?)
>
> As for fs/no-block.c... IMO that's a bad idea - it makes sense only
> if we take fs/b
On Mon, May 19, 2014 at 07:34:16AM -0700, Christoph Hellwig wrote:
> On Mon, May 19, 2014 at 08:31:21AM -0600, Jens Axboe wrote:
> > > While you are at it, could you take bio-integrity.c with it? _That_
> > > has zero excuse being anywhere in fs/* - not even "filesystem code
> > > uses quite a few
On Mon, May 19, 2014 at 10:13 PM, Christoph Hellwig wrote:
> I recently saw patches to fs/bio.c that were sent to Al instead of Jens.
> I think having bio.c in fs/ is rather confusing, so maybe it's time to
> include the simple git-mv for it in the your for-next tree?
Hi, Christoph, Jens,
BTW, j
On 05/19/2014 08:34 AM, Christoph Hellwig wrote:
> On Mon, May 19, 2014 at 08:31:21AM -0600, Jens Axboe wrote:
>>> While you are at it, could you take bio-integrity.c with it? _That_
>>> has zero excuse being anywhere in fs/* - not even "filesystem code
>>> uses quite a few functions from that suc
On Mon, May 19, 2014 at 08:31:21AM -0600, Jens Axboe wrote:
> > While you are at it, could you take bio-integrity.c with it? _That_
> > has zero excuse being anywhere in fs/* - not even "filesystem code
> > uses quite a few functions from that sucker" as with bio.c.
> > FWIW, consider the move ACK
On Mon, May 19, 2014 at 10:28:16PM +0800, Jianyu Zhan wrote:
> Hi, Christoph, Jens,
>
> BTW, just out of curiosity, the VFS infrastructure code is just scatterd
> around the fs directory, which is quite suprised to a new comer that why
> there is "no" vfs stuff in fs directory. Does it make sens
On Mon, May 19, 2014 at 03:25:19PM +0100, Al Viro wrote:
> While you are at it, could you take bio-integrity.c with it? _That_
> has zero excuse being anywhere in fs/* - not even "filesystem code
> uses quite a few functions from that sucker" as with bio.c.
> FWIW, consider the move ACKed.
Variou
On 05/19/2014 08:25 AM, Al Viro wrote:
> On Mon, May 19, 2014 at 08:14:36AM -0600, Jens Axboe wrote:
>> On 05/19/2014 08:13 AM, Christoph Hellwig wrote:
>>> I recently saw patches to fs/bio.c that were sent to Al instead of Jens.
>>> I think having bio.c in fs/ is rather confusing, so maybe it's ti
On Mon, May 19, 2014 at 08:14:36AM -0600, Jens Axboe wrote:
> On 05/19/2014 08:13 AM, Christoph Hellwig wrote:
> > I recently saw patches to fs/bio.c that were sent to Al instead of Jens.
> > I think having bio.c in fs/ is rather confusing, so maybe it's time to
> > include the simple git-mv for it
On 05/19/2014 08:13 AM, Christoph Hellwig wrote:
> I recently saw patches to fs/bio.c that were sent to Al instead of Jens.
> I think having bio.c in fs/ is rather confusing, so maybe it's time to
> include the simple git-mv for it in the your for-next tree?
Sure, I've been thinking that too for a
On Tue, 2007-11-27 at 16:00 +1100, Tony Breeds wrote:
> On Mon, Nov 26, 2007 at 05:23:13PM +0100, Johannes Berg wrote:
> > Contrary to what I claimed later in the thread, my 64-bit powerpc box
> > (quad-core G5) doesn't suffer from this problem.
> >
> > Does anybody have any idea? I don't even kn
On Tue, 2007-11-27 at 20:57 +1100, Paul Mackerras wrote:
> Johannes Berg writes:
>
> > Contrary to what I claimed later in the thread, my 64-bit powerpc box
> > (quad-core G5) doesn't suffer from this problem.
> >
> > Does anybody have any idea? I don't even know how to debug it further.
>
> I
> On my powerbook, with NO_HZ and HIGH_RES_TIMERS, I observed recently
> that powernowd would not ever switch between CPU speeds.
Also happens without NO_HZ (with HIGH_RES_TIMERS).
johannes
signature.asc
Description: This is a digitally signed message part
Johannes Berg writes:
> Contrary to what I claimed later in the thread, my 64-bit powerpc box
> (quad-core G5) doesn't suffer from this problem.
>
> Does anybody have any idea? I don't even know how to debug it further.
I see it on my G4 powerbook. However, a compute-bound task runs just
as fas
On Mon, Nov 26, 2007 at 05:23:13PM +0100, Johannes Berg wrote:
> Contrary to what I claimed later in the thread, my 64-bit powerpc box
> (quad-core G5) doesn't suffer from this problem.
>
> Does anybody have any idea? I don't even know how to debug it further.
I'll see if I can grab an appropriat
Contrary to what I claimed later in the thread, my 64-bit powerpc box
(quad-core G5) doesn't suffer from this problem.
Does anybody have any idea? I don't even know how to debug it further.
johannes
signature.asc
Description: This is a digitally signed message part
* Venki Pallipadi ([EMAIL PROTECTED]) wrote:
> Can you check the test patch below (over latest git) and let me know whether
> it
> resolves the issue.
>
the patch fixes the issue for me,
thanks a lot.
Eric
> Enable C3 without bm control only for CST based C3.
>
> Signed-off-by: Venkatesh Pall
On Tue, Jul 31, 2007 at 05:38:08PM +0200, Eric Sesterhenn / Snakebyte wrote:
> * Pallipadi, Venkatesh ([EMAIL PROTECTED]) wrote:
> > This means things should work fine with processor.max_cstate=2 boot
> > option
> > as well. Can you please double check that.
>
> yes, system boots fine with this ke
* Pallipadi, Venkatesh ([EMAIL PROTECTED]) wrote:
> This means things should work fine with processor.max_cstate=2 boot
> option
> as well. Can you please double check that.
yes, system boots fine with this kernel parameter
> Also, please send in the acpidump from your system.
here we go, if you
olnierkiewicz; [EMAIL PROTECTED]; Ingo
>Molnar; Thomas Gleixner; Pallipadi, Venkatesh
>Subject: Re: Time Problems with 2.6.23-rc1-gf695baf2
>
>* Michal Piotrowski ([EMAIL PROTECTED]) wrote:
>> Hi Eric,
>>
>> On 26/07/07, Eric Sesterhenn / Snakebyte <[EMAIL PROTECT
* Michal Piotrowski ([EMAIL PROTECTED]) wrote:
> Hi Eric,
>
> On 26/07/07, Eric Sesterhenn / Snakebyte <[EMAIL PROTECTED]> wrote:
> > * Len Brown ([EMAIL PROTECTED]) wrote:
> > > > > > > [ 13.506890] ACPI Exception (processor_throttling-0084):
> > > > > > > AE_NOT_FOUND, Evaluating _PTC [200701
Hi Eric,
On 26/07/07, Eric Sesterhenn / Snakebyte <[EMAIL PROTECTED]> wrote:
> * Len Brown ([EMAIL PROTECTED]) wrote:
> > > > > > [ 13.506890] ACPI Exception (processor_throttling-0084):
> > > > > > AE_NOT_FOUND, Evaluating _PTC [20070126]
> > > > > > [ 13.507101] ACPI Exception (processor_th
* Len Brown ([EMAIL PROTECTED]) wrote:
> > > > > [ 13.506890] ACPI Exception (processor_throttling-0084):
> > > > > AE_NOT_FOUND, Evaluating _PTC [20070126]
> > > > > [ 13.507101] ACPI Exception (processor_throttling-0147):
> > > > > AE_NOT_FOUND, Evaluating _TSS [20070126]
>
> Note that the
On Wednesday 25 July 2007 07:33, Eric Sesterhenn / Snakebyte wrote:
> * Michal Piotrowski ([EMAIL PROTECTED]) wrote:
> > On 24/07/07, Eric Sesterhenn / Snakebyte <[EMAIL PROTECTED]> wrote:
> > > see second 13 to 510, after pressing it about ten
> > > times, it continues booting.
> >
> > Probing
* Michal Piotrowski ([EMAIL PROTECTED]) wrote:
> On 24/07/07, Eric Sesterhenn / Snakebyte <[EMAIL PROTECTED]> wrote:
> > see second 13 to 510, after pressing it about ten
> > times, it continues booting.
>
> Probing IDE interface...
>
> [ 13.867939] VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66
On Wednesday 25 July 2007, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday 25 July 2007, Michal Piotrowski wrote:
> > Hi,
> >
> > On 24/07/07, Eric Sesterhenn / Snakebyte <[EMAIL PROTECTED]> wrote:
> > > hi,
> > >
> > > seems like the clock got screwed or something similar. During boot
On Thu, 2005-08-25 at 09:54 +0530, raja wrote:
[...]
> Is There Any function in c to caliculate the exact time taken to
> execute block of code(in micro sec and milli sec and minuits and hours).
> thanking you,
Do you mean system-time, user-space-time or the time it took in the real
world?
On Fri, Jul 29, 2005 at 07:48:32AM +0200, Olivier Fourdan took 44 lines to
write:
>
> Kurt
>
> Did you try with the "no_timer_check" boot option?
Just did and it appears to work. Thanks Olivier!
Alas that this chipset seems to have, um, issues.
Kurt
--
Baker's First Law of Federal Geometry:
Kurt
Did you try with the "no_timer_check" boot option?
HTH
Olivier.
On Thu, 2005-07-28 at 22:03 -0400, Kurt Wall wrote:
> Hola,
>
> I have an eMachines T6212 Opteron system on which the system clock
> seems to run at ~twice the speed of the wall clock. The main board
> is an ASUS K8 of some d
On Thu, 07 Jul 2005 16:44:53 +0530
raja <[EMAIL PROTECTED]> wrote:
> would you please tell how to caliculate the time taken to execute a c
> program in unix environment.
raja, this has nothing to do with Linux Kernel.
PS: see "man time"
--
Paolo Ornati
Linux 2.6.12.2 on x86_64
Dror Cohen <[EMAIL PROTECTED]> writes:
> Hi all,
> While working on a Linux cluster with kernel version 2.4.27 we've
> encountered a consistent clock drift problem. We have devised a fix
The normal fix is to use NTP.
The clock drift problem on lost ticks is known, but I don't
think your change i
Dror Cohen wrote:
Hi all,
While working on a Linux cluster with kernel version 2.4.27 we've
encountered a consistent clock drift problem. We have devised a fix
for this problem which is based on the Pentium's TSC clock.
Any reason why you can't just use NTP?
Chris
-
To unsubscribe from this list: s
Dror Cohen wrote:
Hi all,
While working on a Linux cluster with kernel version 2.4.27 we've
encountered a consistent clock drift problem. We have devised a fix
for this problem which is based on the Pentium's TSC clock. We'd
appreciate any comments on the validity of the proposed solution and
on wh
} > } The fbdev console problem is too horrible to pretend to solve by resyncing
} > } on timer interrupts. At least for the x86 the fix is to sort out the fb
} > } locking properly
} >
} > How close is that?
}
} Its not in itself a big problem, but since it doesnt reformat your hard disk,
} exp
> We have the same trouble on PPC but we make sure to re-sync on each
> interrupt. We can see several lost timer interrupts after a ^L in emacs
> running on the fb console. The resync lets us catch up on those interrupts
> (and not lose time) but we still spend a lot of time not servicing
> inte
> } The fbdev console problem is too horrible to pretend to solve by resyncing
> } on timer interrupts. At least for the x86 the fix is to sort out the fb
> } locking properly
>
> How close is that?
Its not in itself a big problem, but since it doesnt reformat your hard disk,
explode randomly or
On 28 Feb 2001 23:37:40 +, Andrew Morton wrote:
> Eric Buddington wrote:
> >
> > I know this has been reported on the list recently, but I think I can
> > provide better detail. I'm running 2.4.2 with atyfb on a K6-2/266
> > running at 250. This system has no history of clock problems.
> >
>
} > We have the same trouble on PPC but we make sure to re-sync on each
} > interrupt. We can see several lost timer interrupts after a ^L in emacs
} > running on the fb console. The resync lets us catch up on those interrupts
} > (and not lose time) but we still spend a lot of time not servicin
We have the same trouble on PPC but we make sure to re-sync on each
interrupt. We can see several lost timer interrupts after a ^L in emacs
running on the fb console. The resync lets us catch up on those interrupts
(and not lose time) but we still spend a lot of time not servicing
interrupts.
D
Eric Buddington wrote:
>
> I know this has been reported on the list recently, but I think I can
> provide better detail. I'm running 2.4.2 with atyfb on a K6-2/266
> running at 250. This system has no history of clock problems.
>
> adjtimex-1.12 --compare gives me "2nd diff" readings of -0.01 i
On Sun, 28 Jan 2001 [EMAIL PROTECTED] wrote:
>
> I had this problem when I was upgrading my kernel, and happened to do
> it during the daylight savings time roll-back. Confused the heck out
> of me for a while. Anyways, you can try 'touching' all your files,
> and do a 'make clean' then try aga
I had this problem when I was upgrading my kernel, and happened to do
it during the daylight savings time roll-back. Confused the heck out
of me for a while. Anyways, you can try 'touching' all your files,
and do a 'make clean' then try again. If it doesn't complain about a
long arg list, you
On Sun, 28 Jan 2001 12:27:46 -0600 (CST), Thomas Molina wrote:
>I seem to recall a discussion on faster processors causing timing
>problems during a kernel make, but I'm unable to find it in the kernel
>archives. I've now upgraded to an Athlon 900 MHz processor and an ASUS
>A7V motherboard and h
On 19 Dec 00 at 10:37, Timothy A. DeWees wrote:
>
> I am having a weird time problem when mounting Novell 5.1 volumes with
> ncpmount. The Novell server is located in a different timezone, and once I
> mount the volume my system time gets set back 5 hours (to match the Novell
> server).
Y
81 matches
Mail list logo
