Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 authenticationthe LoginGraceTime parameter though. > > I usually get reliable login using ssh key files with the default > setting of 120 seconds (takes around 90 to 100 seconds to complete). > With your patch, even increasing this to 4800 doesn't result in reliable > login. > > The error I see in the logs is 'fatal: Timeout before authentication'. > Weird. Let's try 2942e9fd3e57. Please send me your .config so I can send you a kernel binary. (I don't trust gcc 4.6 on m68k...) -- > Cheers, > > Michael > >
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 authenticationthe LoginGraceTime parameter though. > > I usually get reliable login using ssh key files with the default > setting of 120 seconds (takes around 90 to 100 seconds to complete). > With your patch, even increasing this to 4800 doesn't result in reliable > login. > > The error I see in the logs is 'fatal: Timeout before authentication'. > Weird. Let's try 2942e9fd3e57. Please send me your .config so I can send you a kernel binary. (I don't trust gcc 4.6 on m68k...) -- > Cheers, > > Michael > >
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 1.0.2 (or powerpc). With 0.9.15 on x86_64, it's fine. I'm sufficiently convinced to try this on actual hardware now. 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 authenticationthe LoginGraceTime parameter though. I usually get reliable login using ssh key files with the default setting of 120 seconds (takes around 90 to 100 seconds to complete). With your patch, even increasing this to 4800 doesn't result in reliable login. The error I see in the logs is 'fatal: Timeout before authentication'. Cheers, Michael
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 1.0.2 (or powerpc). With 0.9.15 on x86_64, it's fine. I'm sufficiently convinced to try this on actual hardware now. 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 authenticationthe LoginGraceTime parameter though. I usually get reliable login using ssh key files with the default setting of 120 seconds (takes around 90 to 100 seconds to complete). With your patch, even increasing this to 4800 doesn't result in reliable login. The error I see in the logs is 'fatal: Timeout before authentication'. Cheers, Michael
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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. I've now seen > > > fbf8405cd982, one moment please ... > > > > > > 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 1.0.2 (or powerpc). With 0.9.15 on x86_64, it's > fine. > Could be a regression in aranym? Maybe it's worth trying 0.9.15 on the powerpc host? > I'm sufficiently convinced to try this on actual hardware now. > Thanks! -- > Cheers, > > ??? Michael > > >
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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. I've now seen > > > fbf8405cd982, one moment please ... > > > > > > 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 1.0.2 (or powerpc). With 0.9.15 on x86_64, it's > fine. > Could be a regression in aranym? Maybe it's worth trying 0.9.15 on the powerpc host? > I'm sufficiently convinced to try this on actual hardware now. > Thanks! -- > Cheers, > > ??? Michael > > >
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 - 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 1.0.2 (or powerpc). With 0.9.15 on x86_64, it's fine. I'm sufficiently convinced to try this on actual hardware now. Cheers, Michael
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 - 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 1.0.2 (or powerpc). With 0.9.15 on x86_64, it's fine. I'm sufficiently convinced to try this on actual hardware now. Cheers, Michael
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 versions though. I'll test that again with the setup that saw c606b5cf902 fail. Still fails on that emulator / userland. Cheers, Michael Cheers, Michael
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 versions though. I'll test that again with the setup that saw c606b5cf902 fail. Still fails on that emulator / userland. Cheers, Michael Cheers, Michael
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 course. Using that for initial tests, I can confirm that timer resolution is reduced to 10ms after patch 6, and gets restored to 40ns after applying the full series Thanks for testing! (once clocksource_init runs, that is - the first part of the boot is at 10ms resolution only, a regression compared to with use of arch_gettimeoffset). Sounds like a theoretical regression (?) Is there any need for more precise timers (I mean, better than 40 us) before clocksource_init runs? I don't think so, given that we can run just fine with 10 ms resolution. Unfortunately, I can't log in at the console with all patches applied. I immediately get the 'login timeout exceeded' message. Weird... I didn't see that in my tests... Was this aranym or real hardware or both? ARAnyM only so far. 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 versions though. I'll test that again with the setup that saw c606b5cf902 fail. Cheers, Michael
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 course. Using that for initial tests, I can confirm that timer resolution is reduced to 10ms after patch 6, and gets restored to 40ns after applying the full series Thanks for testing! (once clocksource_init runs, that is - the first part of the boot is at 10ms resolution only, a regression compared to with use of arch_gettimeoffset). Sounds like a theoretical regression (?) Is there any need for more precise timers (I mean, better than 40 us) before clocksource_init runs? I don't think so, given that we can run just fine with 10 ms resolution. Unfortunately, I can't log in at the console with all patches applied. I immediately get the 'login timeout exceeded' message. Weird... I didn't see that in my tests... Was this aranym or real hardware or both? ARAnyM only so far. 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 versions though. I'll test that again with the setup that saw c606b5cf902 fail. Cheers, Michael
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 10ms after patch 6, and gets restored to 40ns after applying > the full series Thanks for testing! > (once clocksource_init runs, that is - the first part of the boot is at > 10ms resolution only, a regression compared to with use of > arch_gettimeoffset). > Sounds like a theoretical regression (?) Is there any need for more precise timers (I mean, better than 40 us) before clocksource_init runs? > Unfortunately, I can't log in at the console with all patches applied. I > immediately get the 'login timeout exceeded' message. Weird... > I didn't see that in my tests... Was this aranym or real hardware or both? Can you also test tree fbf8405cd982 please? -- > Cheers, > > Michael > >
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 10ms after patch 6, and gets restored to 40ns after applying > the full series Thanks for testing! > (once clocksource_init runs, that is - the first part of the boot is at > 10ms resolution only, a regression compared to with use of > arch_gettimeoffset). > Sounds like a theoretical regression (?) Is there any need for more precise timers (I mean, better than 40 us) before clocksource_init runs? > Unfortunately, I can't log in at the console with all patches applied. I > immediately get the 'login timeout exceeded' message. Weird... > I didn't see that in my tests... Was this aranym or real hardware or both? Can you also test tree fbf8405cd982 please? -- > Cheers, > > Michael > >
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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".) With the current code, kernel log timestamps have 10 ms resolution on Atari. Time resolution of times reported by initcall_debug is roughly 40 us. I'd expect that changes with falling back to jiffies only. Might be worth a try on QEMU Mac. The initcall debug output shows the same precision as my earlier tests with userland. The VIA timer only gets updated when QEMU wants to update it, which seems to be about every 9765 us. Hence, using the 'jiffies' clocksource would be effectively no regression for a virtual Mac. Running a recent kernel under ARAnyM shows 40 ns resolution so the Atari hardware emulation is a little more complete. Using that for initial tests, I can confirm that timer resolution is reduced to 10ms after patch 6, and gets restored to 40ns after applying the full series (once clocksource_init runs, that is - the first part of the boot is at 10ms resolution only, a regression compared to with use of arch_gettimeoffset). Unfortunately, I can't log in at the console with all patches applied. I immediately get the 'login timeout exceeded' message. Weird... Cheers, Michael
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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".) With the current code, kernel log timestamps have 10 ms resolution on Atari. Time resolution of times reported by initcall_debug is roughly 40 us. I'd expect that changes with falling back to jiffies only. Might be worth a try on QEMU Mac. The initcall debug output shows the same precision as my earlier tests with userland. The VIA timer only gets updated when QEMU wants to update it, which seems to be about every 9765 us. Hence, using the 'jiffies' clocksource would be effectively no regression for a virtual Mac. Running a recent kernel under ARAnyM shows 40 ns resolution so the Atari hardware emulation is a little more complete. Using that for initial tests, I can confirm that timer resolution is reduced to 10ms after patch 6, and gets restored to 40ns after applying the full series (once clocksource_init runs, that is - the first part of the boot is at 10ms resolution only, a regression compared to with use of arch_gettimeoffset). Unfortunately, I can't log in at the console with all patches applied. I immediately get the 'login timeout exceeded' message. Weird... Cheers, Michael
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 timestamps have 10 ms resolution on > Atari. Time resolution of times reported by initcall_debug is roughly 40 > us. I'd expect that changes with falling back to jiffies only. Might be > worth a try on QEMU Mac. The initcall debug output shows the same precision as my earlier tests with userland. The VIA timer only gets updated when QEMU wants to update it, which seems to be about every 9765 us. Hence, using the 'jiffies' clocksource would be effectively no regression for a virtual Mac. --
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 timestamps have 10 ms resolution on > Atari. Time resolution of times reported by initcall_debug is roughly 40 > us. I'd expect that changes with falling back to jiffies only. Might be > worth a try on QEMU Mac. The initcall debug output shows the same precision as my earlier tests with userland. The VIA timer only gets updated when QEMU wants to update it, which seems to be about every 9765 us. Hence, using the 'jiffies' clocksource would be effectively no regression for a virtual Mac. --
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 functions that implement arch_gettimeoffset are re-used by new clocksource drivers in subsequent patches. Disabling this first affects functionality during bisection, right? It means that all platforms have to use the 'jiffies' clocksource. So all that happens is timer granularity drops to 10ms, then gets restored by the later patches? Yes, that was the plan, but I can't confirm that it worked out as I don't have any physical 68k hardware in front of me right now. If you can confirm this on your Atari Falcon, that would be great. Will do. (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 timestamps have 10 ms resolution on Atari. Time resolution of times reported by initcall_debug is roughly 40 us. I'd expect that changes with falling back to jiffies only. Might be worth a try on QEMU Mac. Cheers, Michael The latest patches can be found at https://github.com/fthain/linux/commits/mac68k-queue/
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 functions that implement arch_gettimeoffset are re-used by new clocksource drivers in subsequent patches. Disabling this first affects functionality during bisection, right? It means that all platforms have to use the 'jiffies' clocksource. So all that happens is timer granularity drops to 10ms, then gets restored by the later patches? Yes, that was the plan, but I can't confirm that it worked out as I don't have any physical 68k hardware in front of me right now. If you can confirm this on your Atari Falcon, that would be great. Will do. (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 timestamps have 10 ms resolution on Atari. Time resolution of times reported by initcall_debug is roughly 40 us. I'd expect that changes with falling back to jiffies only. Might be worth a try on QEMU Mac. Cheers, Michael The latest patches can be found at https://github.com/fthain/linux/commits/mac68k-queue/
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 functions that implement arch_gettimeoffset are re-used by > > > > new clocksource drivers in subsequent patches. > > > > > > Disabling this first affects functionality during bisection, right? > > > > > > > It means that all platforms have to use the 'jiffies' clocksource. > > So all that happens is timer granularity drops to 10ms, then gets restored by > the later patches? > Yes, that was the plan, but I can't confirm that it worked out as I don't have any physical 68k hardware in front of me right now. If you can confirm this on your Atari Falcon, that would be great. (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".) The latest patches can be found at https://github.com/fthain/linux/commits/mac68k-queue/ -- > I doubt that would be a large enough regression to matter for bisection, but > the way you reuse the arch_gettimeoffset() code for the new read_clock() > functions makes reordering of this patch to the end of the series impossible. > > Best you can don, under the circumstances. > > Cheers, > > Michael > >
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 functions that implement arch_gettimeoffset are re-used by > > > > new clocksource drivers in subsequent patches. > > > > > > Disabling this first affects functionality during bisection, right? > > > > > > > It means that all platforms have to use the 'jiffies' clocksource. > > So all that happens is timer granularity drops to 10ms, then gets restored by > the later patches? > Yes, that was the plan, but I can't confirm that it worked out as I don't have any physical 68k hardware in front of me right now. If you can confirm this on your Atari Falcon, that would be great. (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".) The latest patches can be found at https://github.com/fthain/linux/commits/mac68k-queue/ -- > I doubt that would be a large enough regression to matter for bisection, but > the way you reuse the arch_gettimeoffset() code for the new read_clock() > functions makes reordering of this patch to the end of the series impossible. > > Best you can don, under the circumstances. > > Cheers, > > Michael > >
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 patches. Disabling this first affects functionality during bisection, right? It means that all platforms have to use the 'jiffies' clocksource. So all that happens is timer granularity drops to 10ms, then gets restored by the later patches? I doubt that would be a large enough regression to matter for bisection, but the way you reuse the arch_gettimeoffset() code for the new read_clock() functions makes reordering of this patch to the end of the series impossible. Best you can don, under the circumstances. Cheers, Michael
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 patches. Disabling this first affects functionality during bisection, right? It means that all platforms have to use the 'jiffies' clocksource. So all that happens is timer granularity drops to 10ms, then gets restored by the later patches? I doubt that would be a large enough regression to matter for bisection, but the way you reuse the arch_gettimeoffset() code for the new read_clock() functions makes reordering of this patch to the end of the series impossible. Best you can don, under the circumstances. Cheers, Michael
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 functionality during bisection, right?
>
It means that all platforms have to use the 'jiffies' clocksource.
At the end of the series, only apollo, q40, sun3 & sun3x continue to use
that clocksource.
> > --- a/arch/m68k/amiga/config.c
> > +++ b/arch/m68k/amiga/config.c
> > @@ -95,8 +95,6 @@ static char amiga_model_name[13] = "Amiga ";
> > static void amiga_sched_init(irq_handler_t handler);
> > static void amiga_get_model(char *model);
> > static void amiga_get_hardware_list(struct seq_file *m);
> > -/* amiga specific timer functions */
> > -static u32 amiga_gettimeoffset(void);
> > extern void amiga_mksound(unsigned int count, unsigned int ticks);
> > static void amiga_reset(void);
> > extern void amiga_init_sound(void);
> > @@ -386,7 +384,6 @@ void __init config_amiga(void)
> > mach_init_IRQ= amiga_init_IRQ;
> > mach_get_model = amiga_get_model;
> > mach_get_hardware_list = amiga_get_hardware_list;
> > - arch_gettimeoffset = amiga_gettimeoffset;
>
> In addition, won't this lead to "function defined statically but not
> called' warnings?
>
I expect so. I haven't compile-tested each step in the series; but I'll do
that before I send v2. Thanks for the reminder.
There are no new warnings at the end of the series.
--
> Gr{oetje,eeting}s,
>
> Geert
>
>
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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 functionality during bisection, right?
>
It means that all platforms have to use the 'jiffies' clocksource.
At the end of the series, only apollo, q40, sun3 & sun3x continue to use
that clocksource.
> > --- a/arch/m68k/amiga/config.c
> > +++ b/arch/m68k/amiga/config.c
> > @@ -95,8 +95,6 @@ static char amiga_model_name[13] = "Amiga ";
> > static void amiga_sched_init(irq_handler_t handler);
> > static void amiga_get_model(char *model);
> > static void amiga_get_hardware_list(struct seq_file *m);
> > -/* amiga specific timer functions */
> > -static u32 amiga_gettimeoffset(void);
> > extern void amiga_mksound(unsigned int count, unsigned int ticks);
> > static void amiga_reset(void);
> > extern void amiga_init_sound(void);
> > @@ -386,7 +384,6 @@ void __init config_amiga(void)
> > mach_init_IRQ= amiga_init_IRQ;
> > mach_get_model = amiga_get_model;
> > mach_get_hardware_list = amiga_get_hardware_list;
> > - arch_gettimeoffset = amiga_gettimeoffset;
>
> In addition, won't this lead to "function defined statically but not
> called' warnings?
>
I expect so. I haven't compile-tested each step in the series; but I'll do
that before I send v2. Thanks for the reminder.
There are no new warnings at the end of the series.
--
> Gr{oetje,eeting}s,
>
> Geert
>
>
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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?
> --- a/arch/m68k/amiga/config.c
> +++ b/arch/m68k/amiga/config.c
> @@ -95,8 +95,6 @@ static char amiga_model_name[13] = "Amiga ";
> static void amiga_sched_init(irq_handler_t handler);
> static void amiga_get_model(char *model);
> static void amiga_get_hardware_list(struct seq_file *m);
> -/* amiga specific timer functions */
> -static u32 amiga_gettimeoffset(void);
> extern void amiga_mksound(unsigned int count, unsigned int ticks);
> static void amiga_reset(void);
> extern void amiga_init_sound(void);
> @@ -386,7 +384,6 @@ void __init config_amiga(void)
> mach_init_IRQ= amiga_init_IRQ;
> mach_get_model = amiga_get_model;
> mach_get_hardware_list = amiga_get_hardware_list;
> - arch_gettimeoffset = amiga_gettimeoffset;
In addition, won't this lead to "function defined statically but not called'
warnings?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
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?
> --- a/arch/m68k/amiga/config.c
> +++ b/arch/m68k/amiga/config.c
> @@ -95,8 +95,6 @@ static char amiga_model_name[13] = "Amiga ";
> static void amiga_sched_init(irq_handler_t handler);
> static void amiga_get_model(char *model);
> static void amiga_get_hardware_list(struct seq_file *m);
> -/* amiga specific timer functions */
> -static u32 amiga_gettimeoffset(void);
> extern void amiga_mksound(unsigned int count, unsigned int ticks);
> static void amiga_reset(void);
> extern void amiga_init_sound(void);
> @@ -386,7 +384,6 @@ void __init config_amiga(void)
> mach_init_IRQ= amiga_init_IRQ;
> mach_get_model = amiga_get_model;
> mach_get_hardware_list = amiga_get_hardware_list;
> - arch_gettimeoffset = amiga_gettimeoffset;
In addition, won't this lead to "function defined statically but not called'
warnings?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
