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(&rtc_lock, flags);
> + /* Ensure that the RTC is accessible. Bit 0-6 must be 0! */
> + if (WARN
ard 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.
(si
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 bisec
> 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 rig
> - 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 be
> 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 drive
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 gener
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 su
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/processo
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 boun
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 misco
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
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 com
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 pa
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 (from
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 "unsubsc
22 matches
Mail list logo