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).
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
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
>>> 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
>> 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.
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
> 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
> - 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
> 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
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
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
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
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
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 |
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
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
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
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
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
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
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
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
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
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
>
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).
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
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
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
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
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
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
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
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
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
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
35 matches
Mail list logo
