On Thu, 15 Nov 2018, Michael Schmitz wrote:
>
> Well, it sort of works - I've seen one login timeout on the console
> under load (less than 10 seconds after typing in the password), but most
> attempts went OK. Couldn't log in through SSH without increasing fatal:
> Timeout before
On Thu, 15 Nov 2018, Michael Schmitz wrote:
>
> Well, it sort of works - I've seen one login timeout on the console
> under load (less than 10 seconds after typing in the password), but most
> attempts went OK. Couldn't log in through SSH without increasing fatal:
> Timeout before
Hi Finn
Am 15.11.2018 um 12:54 schrieb Michael Schmitz:
That one does appear to work - different versions of ARAnyM, and
different userland versions though. I'll test that again with the setup
that saw c606b5cf902 fail.
Still fails on that emulator / userland.
Must be a quirk of ARAnyM
Hi Finn
Am 15.11.2018 um 12:54 schrieb Michael Schmitz:
That one does appear to work - different versions of ARAnyM, and
different userland versions though. I'll test that again with the setup
that saw c606b5cf902 fail.
Still fails on that emulator / userland.
Must be a quirk of ARAnyM
On Thu, 15 Nov 2018, Michael Schmitz wrote:
> Hi Finn,
>
> On 14/11/18 3:58 PM, Michael Schmitz wrote:
> > Hi Finn,
> >
> > Am 14.11.2018 um 14:08 schrieb Michael Schmitz:
> > > > Can you also test tree fbf8405cd982 please?
> > > >
> > > My tests were on c606b5cf902 in case it wasn't clear.
On Thu, 15 Nov 2018, Michael Schmitz wrote:
> Hi Finn,
>
> On 14/11/18 3:58 PM, Michael Schmitz wrote:
> > Hi Finn,
> >
> > Am 14.11.2018 um 14:08 schrieb Michael Schmitz:
> > > > Can you also test tree fbf8405cd982 please?
> > > >
> > > My tests were on c606b5cf902 in case it wasn't clear.
Hi Finn,
On 14/11/18 3:58 PM, Michael Schmitz wrote:
Hi Finn,
Am 14.11.2018 um 14:08 schrieb Michael Schmitz:
Can you also test tree fbf8405cd982 please?
My tests were on c606b5cf902 in case it wasn't clear. I've now seen
fbf8405cd982, one moment please ...
That one does appear to work -
Hi Finn,
On 14/11/18 3:58 PM, Michael Schmitz wrote:
Hi Finn,
Am 14.11.2018 um 14:08 schrieb Michael Schmitz:
Can you also test tree fbf8405cd982 please?
My tests were on c606b5cf902 in case it wasn't clear. I've now seen
fbf8405cd982, one moment please ...
That one does appear to work -
Hi Finn,
Am 14.11.2018 um 14:08 schrieb Michael Schmitz:
Can you also test tree fbf8405cd982 please?
My tests were on c606b5cf902 in case it wasn't clear. I've now seen
fbf8405cd982, one moment please ...
That one does appear to work - different versions of ARAnyM, and
different userland
Hi Finn,
Am 14.11.2018 um 14:08 schrieb Michael Schmitz:
Can you also test tree fbf8405cd982 please?
My tests were on c606b5cf902 in case it wasn't clear. I've now seen
fbf8405cd982, one moment please ...
That one does appear to work - different versions of ARAnyM, and
different userland
Hi Finn,
On 14/11/18 11:11 AM, Finn Thain wrote:
On Tue, 13 Nov 2018, Michael Schmitz wrote:
Running a recent kernel under ARAnyM shows 40 ns resolution so the Atari
hardware emulation is a little more complete.
You mean, 40 us resolution, right?
Sorry, typo. Should have been us of
Hi Finn,
On 14/11/18 11:11 AM, Finn Thain wrote:
On Tue, 13 Nov 2018, Michael Schmitz wrote:
Running a recent kernel under ARAnyM shows 40 ns resolution so the Atari
hardware emulation is a little more complete.
You mean, 40 us resolution, right?
Sorry, typo. Should have been us of
On Tue, 13 Nov 2018, Michael Schmitz wrote:
>
> Running a recent kernel under ARAnyM shows 40 ns resolution so the Atari
> hardware emulation is a little more complete.
>
You mean, 40 us resolution, right?
> Using that for initial tests, I can confirm that timer resolution is
> reduced to
On Tue, 13 Nov 2018, Michael Schmitz wrote:
>
> Running a recent kernel under ARAnyM shows 40 ns resolution so the Atari
> hardware emulation is a little more complete.
>
You mean, 40 us resolution, right?
> Using that for initial tests, I can confirm that timer resolution is
> reduced to
Hi Finn,
Am 13.11.2018 um 19:15 schrieb Finn Thain:
On Tue, 13 Nov 2018, Michael Schmitz wrote:
(It appears that a QEMU-emulated Mac does not benefit from having a
clocksource that's more accurate than the 'jiffies' clocksource, in
spite of "clocksource: Switched to clocksource via1".)
Hi Finn,
Am 13.11.2018 um 19:15 schrieb Finn Thain:
On Tue, 13 Nov 2018, Michael Schmitz wrote:
(It appears that a QEMU-emulated Mac does not benefit from having a
clocksource that's more accurate than the 'jiffies' clocksource, in
spite of "clocksource: Switched to clocksource via1".)
On Tue, 13 Nov 2018, Michael Schmitz wrote:
>
> > (It appears that a QEMU-emulated Mac does not benefit from having a
> > clocksource that's more accurate than the 'jiffies' clocksource, in
> > spite of "clocksource: Switched to clocksource via1".)
>
> With the current code, kernel log
On Tue, 13 Nov 2018, Michael Schmitz wrote:
>
> > (It appears that a QEMU-emulated Mac does not benefit from having a
> > clocksource that's more accurate than the 'jiffies' clocksource, in
> > spite of "clocksource: Switched to clocksource via1".)
>
> With the current code, kernel log
Hi Finn,
Am 13.11.2018 um 16:14 schrieb Finn Thain:
On Tue, 13 Nov 2018, Michael Schmitz wrote:
Hi Finn,
Am 12.11.2018 um 22:06 schrieb Finn Thain:
On Mon, 12 Nov 2018, Geert Uytterhoeven wrote:
Hi Finn,
Thanks for your patch!
On Mon, Nov 12, 2018 at 5:46 AM Finn Thain
wrote:
The
Hi Finn,
Am 13.11.2018 um 16:14 schrieb Finn Thain:
On Tue, 13 Nov 2018, Michael Schmitz wrote:
Hi Finn,
Am 12.11.2018 um 22:06 schrieb Finn Thain:
On Mon, 12 Nov 2018, Geert Uytterhoeven wrote:
Hi Finn,
Thanks for your patch!
On Mon, Nov 12, 2018 at 5:46 AM Finn Thain
wrote:
The
On Tue, 13 Nov 2018, Michael Schmitz wrote:
> Hi Finn,
>
> Am 12.11.2018 um 22:06 schrieb Finn Thain:
> > On Mon, 12 Nov 2018, Geert Uytterhoeven wrote:
> >
> > > Hi Finn,
> > >
> > > Thanks for your patch!
> > >
> > > On Mon, Nov 12, 2018 at 5:46 AM Finn Thain
> > > wrote:
> > > > The
On Tue, 13 Nov 2018, Michael Schmitz wrote:
> Hi Finn,
>
> Am 12.11.2018 um 22:06 schrieb Finn Thain:
> > On Mon, 12 Nov 2018, Geert Uytterhoeven wrote:
> >
> > > Hi Finn,
> > >
> > > Thanks for your patch!
> > >
> > > On Mon, Nov 12, 2018 at 5:46 AM Finn Thain
> > > wrote:
> > > > The
Hi Finn,
Am 12.11.2018 um 22:06 schrieb Finn Thain:
On Mon, 12 Nov 2018, Geert Uytterhoeven wrote:
Hi Finn,
Thanks for your patch!
On Mon, Nov 12, 2018 at 5:46 AM Finn Thain wrote:
The functions that implement arch_gettimeoffset are re-used by
new clocksource drivers in subsequent
Hi Finn,
Am 12.11.2018 um 22:06 schrieb Finn Thain:
On Mon, 12 Nov 2018, Geert Uytterhoeven wrote:
Hi Finn,
Thanks for your patch!
On Mon, Nov 12, 2018 at 5:46 AM Finn Thain wrote:
The functions that implement arch_gettimeoffset are re-used by
new clocksource drivers in subsequent
On Mon, 12 Nov 2018, Geert Uytterhoeven wrote:
> Hi Finn,
>
> Thanks for your patch!
>
> On Mon, Nov 12, 2018 at 5:46 AM Finn Thain wrote:
> > The functions that implement arch_gettimeoffset are re-used by
> > new clocksource drivers in subsequent patches.
>
> Disabling this first affects
On Mon, 12 Nov 2018, Geert Uytterhoeven wrote:
> Hi Finn,
>
> Thanks for your patch!
>
> On Mon, Nov 12, 2018 at 5:46 AM Finn Thain wrote:
> > The functions that implement arch_gettimeoffset are re-used by
> > new clocksource drivers in subsequent patches.
>
> Disabling this first affects
Hi Finn,
Thanks for your patch!
On Mon, Nov 12, 2018 at 5:46 AM Finn Thain wrote:
> The functions that implement arch_gettimeoffset are re-used by
> new clocksource drivers in subsequent patches.
Disabling this first affects functionality during bisection, right?
> ---
Hi Finn,
Thanks for your patch!
On Mon, Nov 12, 2018 at 5:46 AM Finn Thain wrote:
> The functions that implement arch_gettimeoffset are re-used by
> new clocksource drivers in subsequent patches.
Disabling this first affects functionality during bisection, right?
> ---
28 matches
Mail list logo
