Re: [PATCH 01/10] alpha: use libata instead of the legacy ide driver

2021-03-19 Thread Serge Belyshev
Al Viro writes: > ... > > Do you have reports of libata variants of drivers actually tested on > those? PATA_CMD64X works fine on my 164LX for many years, last tested with 5.12-rc3. (with a caveat: in my setup with CF card DMA is broken, but it is broken with BLK_DEV_CMD64X as well).

Re: [PATCH V2] rtc: mc146818: Detect and handle broken RTCs

2021-02-01 Thread Serge Belyshev
Hi! "Me too": > --- a/drivers/rtc/rtc-mc146818-lib.c > +++ b/drivers/rtc/rtc-mc146818-lib.c > @@ -21,6 +21,13 @@ unsigned int mc146818_get_time(struct rt > > again: > spin_lock_irqsave(_lock, flags); > + /* Ensure that the RTC is accessible. Bit 0-6 must be 0! */ > + if

Re: [PATCH] powerpc/32s: Use relocation offset when setting early hash table

2020-11-07 Thread Serge Belyshev
d Furtner > Reported-by: Andreas Schwab > Fixes: 69a1593abdbc ("powerpc/32s: Setup the early hash table at all time.") > Signed-off-by: Christophe Leroy Tested-by: Serge Belyshev

Re: [PATCH] powerpc/32s: Setup the early hash table at all time.

2020-11-04 Thread Serge Belyshev
>>> To be sure we are not in front of a long lasting bug, could you try >>> CONFIG_KASAN=y on v5.9 ? >> >> Indeed it started to fail somewhere between v5.6 and v5.7. >> >> v5.7 fails early with few messages on the console with reboot, v5.8 and >> later hang right at bootloader. >> >> I'm bisecting

Re: [PATCH] powerpc/32s: Setup the early hash table at all time.

2020-11-04 Thread Serge Belyshev
>> To be sure we are not in front of a long lasting bug, could you try >> CONFIG_KASAN=y on v5.9 ? > > Indeed it started to fail somewhere between v5.6 and v5.7. > > v5.7 fails early with few messages on the console with reboot, v5.8 and > later hang right at bootloader. > > I'm bisecting now.

Re: [PATCH] powerpc/32s: Setup the early hash table at all time.

2020-11-03 Thread Serge Belyshev
Christophe Leroy writes: > To be sure we are not in front of a long lasting bug, could you try > CONFIG_KASAN=y on v5.9 ? Indeed it started to fail somewhere between v5.6 and v5.7. v5.7 fails early with few messages on the console with reboot, v5.8 and later hang right at bootloader. I'm

Re: [PATCH] powerpc/32s: Setup the early hash table at all time.

2020-11-03 Thread Serge Belyshev
> Would you mind checking that with that patch reverted, you are able to > boot a kernel built with CONFIG_KASAN ? I can reproduce the same problem on a powerbook G4, and no, CONFIG_KASAN=y kernel with that patch reverted also does not boot with the same symptom: white screen at the bootloader

Re: Linux 5.3-rc8

2019-09-16 Thread Serge Belyshev
> - add new GRND_SECURE and GRND_INSECURE flags that have the actual > useful behaviors that we currently pretty much lack > > - consider the old 0-3 flag values legacy, deprecated, and unsafe > because they _will_ time out to fix the existing problem we have right > now because of their bad

Re: PROBLEM: 5.3.0-rc* causes iwlwifi failure

2019-08-17 Thread Serge Belyshev
> I am on an Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz running Linux > x86_64 (Slackware), with a custom-compiled 5.3.0-rc4 (.config > attached). > > I am using the Intel wifi adapter on this machine: > > 02:00.0 Network controller: Intel Corporation Device 24fb (rev 10) > > with the iwlwifi

Re: [PATCH]: x86_64: Remove unnecessary cast in prefetch()

2007-09-15 Thread Serge Belyshev
Andi Kleen <[EMAIL PROTECTED]> writes: ... >> to make kernel work with GCC 4.3 and above. (Also note that gcc 4.2 already >> smart enough to break that code, but kernel is just lucky currently). > > How would it break the code exactly? It more sounded like an optimization > to me. Would it

Re: [PATCH]: x86_64: Remove unnecessary cast in prefetch()

2007-09-15 Thread Serge Belyshev
Andi Kleen <[EMAIL PROTECTED]> writes: >> This can be fixed better by using gcc's __builtin_prefetch(). > > I changed it to just use that. Thanks. > > It seems like gcc 3.1/3.2 already supported it and that's the earliest gcc > still supported so it can be used unconditionally. > Hi! Will you

Re: [PATCH]: x86_64: Remove unnecessary cast in prefetch()

2007-09-15 Thread Serge Belyshev
Andi Kleen [EMAIL PROTECTED] writes: This can be fixed better by using gcc's __builtin_prefetch(). I changed it to just use that. Thanks. It seems like gcc 3.1/3.2 already supported it and that's the earliest gcc still supported so it can be used unconditionally. Hi! Will you submit this

Re: [PATCH]: x86_64: Remove unnecessary cast in prefetch()

2007-09-15 Thread Serge Belyshev
Andi Kleen [EMAIL PROTECTED] writes: ... to make kernel work with GCC 4.3 and above. (Also note that gcc 4.2 already smart enough to break that code, but kernel is just lucky currently). How would it break the code exactly? It more sounded like an optimization to me. Would it generate

[PATCH]: x86_64: Remove unnecessary cast in prefetch()

2007-09-06 Thread Serge Belyshev
uot;x" argument is non-null and thus wreaking havok everywhere prefetch() was inlined. Fixed by removing cast and changing asm constraint. This can be fixed better by using gcc's __builtin_prefetch(). Signed-off-by: Serge Belyshev <[EMAIL PROTECTED]> --- include/asm-x86_64/processor.h |

[PATCH]: x86_64: Remove unnecessary cast in prefetch()

2007-09-06 Thread Serge Belyshev
argument is non-null and thus wreaking havok everywhere prefetch() was inlined. Fixed by removing cast and changing asm constraint. This can be fixed better by using gcc's __builtin_prefetch(). Signed-off-by: Serge Belyshev [EMAIL PROTECTED] --- include/asm-x86_64/processor.h |2 +- 1 file

Re: [PATCH] [2/58] x86_64: Tell gcc to only align stack to 8 bytes

2007-07-19 Thread Serge Belyshev
Andi Kleen <[EMAIL PROTECTED]> writes: > Don't need 16 byte alignment because kernel doesn't use SSE2 > ... > cflags-y += -maccumulate-outgoing-args > +cflags-y += -mpreferred-stack-boundary=4 > >From gcc manpage: -mpreferred-stack-boundary=num Attempt to keep the stack

Re: [PATCH] [2/58] x86_64: Tell gcc to only align stack to 8 bytes

2007-07-19 Thread Serge Belyshev
Andi Kleen [EMAIL PROTECTED] writes: Don't need 16 byte alignment because kernel doesn't use SSE2 ... cflags-y += -maccumulate-outgoing-args +cflags-y += -mpreferred-stack-boundary=4 From gcc manpage: -mpreferred-stack-boundary=num Attempt to keep the stack boundary

Re: [announce] split-up -rt patch-queue, v2.6.22.1-rt2

2007-07-12 Thread Serge Belyshev
Ingo Molnar <[EMAIL PROTECTED]> writes: > We are pleased to announce something we've been working on for some > time: a finegrained, split-up patch queue of the -rt kernel patch. From > now on (as of 2.6.22.1-rt2) it will be part of every upstream -rt > release and it is available from the -rt

Re: [announce] split-up -rt patch-queue, v2.6.22.1-rt2

2007-07-12 Thread Serge Belyshev
Ingo Molnar [EMAIL PROTECTED] writes: We are pleased to announce something we've been working on for some time: a finegrained, split-up patch queue of the -rt kernel patch. From now on (as of 2.6.22.1-rt2) it will be part of every upstream -rt release and it is available from the -rt

Re: Linux 2.6.22 released

2007-07-11 Thread Serge Belyshev
Andi Kleen <[EMAIL PROTECTED]> writes: >> I don't think this is worth even trying to fix. This is terminal compiler >> breakage. Make a bug-report to the gcc people, the inline asm stuff has >> been totally buggered by that compiler version. >> >> If it mis-compiled that part, it probably

Re: Linux 2.6.22 released

2007-07-11 Thread Serge Belyshev
Andi Kleen [EMAIL PROTECTED] writes: I don't think this is worth even trying to fix. This is terminal compiler breakage. Make a bug-report to the gcc people, the inline asm stuff has been totally buggered by that compiler version. If it mis-compiled that part, it probably miscompiled a

Re: RSDL v0.31

2007-03-17 Thread Serge Belyshev
Ingo Molnar <[EMAIL PROTECTED]> writes: > * Nicholas Miell <[EMAIL PROTECTED]> wrote: > >> The X people have plans for how to go about fixing this, [...] > > [...] Or will X regress forever once we switch to RSDL?) > We cannot regress the scheduling of a workload as important as "X mixed > with

Re: RSDL v0.31

2007-03-17 Thread Serge Belyshev
Ingo Molnar [EMAIL PROTECTED] writes: * Nicholas Miell [EMAIL PROTECTED] wrote: The X people have plans for how to go about fixing this, [...] [...] Or will X regress forever once we switch to RSDL?) We cannot regress the scheduling of a workload as important as X mixed with CPU-intense

Re: rsdl 30 on 2.6.20.2 breaks user space usb

2007-03-15 Thread Serge Belyshev
Andreas Jellinghaus <[EMAIL PROTECTED]> writes: > with plain 2.6.20.2 I get events / called from udev for /proc/bus/usb devices. > with rsdl 0.30 added to the kernel I no longer get called for those devices > (but I do get called for the new /dev/usbdev devices - except that I can't > use >

Re: rsdl 30 on 2.6.20.2 breaks user space usb

2007-03-15 Thread Serge Belyshev
Andreas Jellinghaus [EMAIL PROTECTED] writes: with plain 2.6.20.2 I get events / called from udev for /proc/bus/usb devices. with rsdl 0.30 added to the kernel I no longer get called for those devices (but I do get called for the new /dev/usbdev devices - except that I can't use them).

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

2007-03-13 Thread Serge Belyshev
Mike Galbraith <[EMAIL PROTECTED]> writes: [snip] > It seems to be a plain linear slowdown. The lurchiness I'm experiencing > varies in intensity, and is impossible to quantify. I see neither > lurchiness nor slowdown in mainline through -j8. > Whaa? make -j8 on mainline makes my desktop box

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

2007-03-13 Thread Serge Belyshev
Mike Galbraith [EMAIL PROTECTED] writes: [snip] It seems to be a plain linear slowdown. The lurchiness I'm experiencing varies in intensity, and is impossible to quantify. I see neither lurchiness nor slowdown in mainline through -j8. Whaa? make -j8 on mainline makes my desktop box

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

2007-03-12 Thread Serge Belyshev
Mike Galbraith <[EMAIL PROTECTED]> writes: [snip] >> And let's not lose sight of things with this one testcase. >> >> RSDL fixes >> - every starvation case >> - all fairness isssues >> - is better 95% of the time on the desktop > > I don't know where you got that 95% number from. For the most

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

2007-03-12 Thread Serge Belyshev
Mike Galbraith [EMAIL PROTECTED] writes: [snip] And let's not lose sight of things with this one testcase. RSDL fixes - every starvation case - all fairness isssues - is better 95% of the time on the desktop I don't know where you got that 95% number from. For the most part, the

Re: 2.6.21-rc3-mm1 RSDL results

2007-03-09 Thread Serge Belyshev
William Lee Irwin III <[EMAIL PROTECTED]> writes: > On Fri, Mar 09, 2007 at 12:07:06PM +0300, Serge Belyshev wrote: >> If you see sched_yield() when stracing any 3d program, I suggest you >> to try this bruteforce workaround, which works fine for me, >> disable sched

Re: 2.6.21-rc3-mm1 RSDL results

2007-03-09 Thread Serge Belyshev
Con Kolivas <[EMAIL PROTECTED]> writes: > On Friday 09 March 2007 18:53, Matt Mackall wrote: ... >> >> With a single non-parallel make running (all in cache, mind you), the >> system kicks up into just about 100% CPU usage at full speed. Desktop >> spinning becomes between 10x to 100x slower

Re: 2.6.21-rc3-mm1 RSDL results

2007-03-09 Thread Serge Belyshev
Con Kolivas [EMAIL PROTECTED] writes: On Friday 09 March 2007 18:53, Matt Mackall wrote: ... With a single non-parallel make running (all in cache, mind you), the system kicks up into just about 100% CPU usage at full speed. Desktop spinning becomes between 10x to 100x slower (from ~30fps to

Re: 2.6.21-rc3-mm1 RSDL results

2007-03-09 Thread Serge Belyshev
William Lee Irwin III [EMAIL PROTECTED] writes: On Fri, Mar 09, 2007 at 12:07:06PM +0300, Serge Belyshev wrote: If you see sched_yield() when stracing any 3d program, I suggest you to try this bruteforce workaround, which works fine for me, disable sched_yield(): May I suggest LD_PRELOAD

Re: v2.6.20-rt1, yum/rpm

2007-02-05 Thread Serge Belyshev
Ingo Molnar <[EMAIL PROTECTED]> writes: > i have released the v2.6.20-rt1 kernel, which can be downloaded from the > usual place: I did not find tarball with split patches there. Could you please make it available somewhere via http or ftp? - To unsubscribe from this list: send the line

Re: v2.6.20-rt1, yum/rpm

2007-02-05 Thread Serge Belyshev
Ingo Molnar [EMAIL PROTECTED] writes: i have released the v2.6.20-rt1 kernel, which can be downloaded from the usual place: I did not find tarball with split patches there. Could you please make it available somewhere via http or ftp? - To unsubscribe from this list: send the line unsubscribe