Re: [PATCH 01/10] alpha: use libata instead of the legacy ide driver
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
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 (WARN_ON_ONCE((CMOS_READ(RTC_VALID) & 0x7f) != 0)) {
> + spin_unlock_irqrestore(_lock, flags);
> + memset(time, 0xff, sizeof(*time));
> + return 0;
> + }
> +
... triggers here on a different box (Xiaomi mi notebook air 12.5):
[3.524002] [ cut here ]
[3.528317] WARNING: CPU: 3 PID: 273 at drivers/rtc/rtc-mc146818-lib.c:25
mc146818_get_time+0x1b6/0x210
[3.532558] CPU: 3 PID: 273 Comm: udevadm Not tainted 5.11.0-rc6 #760
[3.536748] Hardware name: Timi TM1612/TM1612, BIOS A04 08/06/2016
[3.540947] RIP: 0010:mc146818_get_time+0x1b6/0x210
[3.545103] Code: 76 0b 0f b6 d0 83 ea 13 6b d2 64 01 d5 83 fd 45 89 6b 14
7f 06 83 c5 64 89 6b 14 41 83 ed 01 b8 02 00 00 00 44 89 6b 10 eb 39 <0f> 0b 48
c7 c7 b4 e0 9e 82 48 89 ee e8 29 6b 34 00 48 c7 03 ff ff
[3.549883] RSP: :c900012efe30 EFLAGS: 00010002
[3.554387] RAX: 0081 RBX: c900012efe64 RCX: 0005b8d7
[3.558867] RDX: 0001 RSI: 8881000aa000 RDI: 000d
[3.56] RBP: 0046 R08: 0004 R09: fffe5e075ac6
[3.567748] iwlwifi :02:00.0: Applying debug destination EXTERNAL_DRAM
[3.567822] R10: R11: R12:
[3.567827] R13: c900012efedc R14: 0008 R15: 888100051200
[3.577223] FS: () GS:88816ad8()
knlGS:
[3.579870] CS: 0010 DS: ES: CR0: 80050033
[3.581947] CR2: 7fface455e28 CR3: 000103244005 CR4: 003706a0
[3.583836] Call Trace:
[3.585699] hpet_rtc_interrupt+0x1af/0x220
[3.587585] __handle_irq_event_percpu+0x5a/0xc0
[3.589230] handle_irq_event_percpu+0x1b/0x50
[3.590673] handle_irq_event+0x22/0x40
[3.592107] handle_edge_irq+0x6b/0x190
[3.593545] common_interrupt+0x67/0x130
[3.594983] ? asm_common_interrupt+0x8/0x40
[3.596432] asm_common_interrupt+0x1e/0x40
[3.597618] RIP: 0033:0x7ffaceac9b31
[3.598794] Code: 48 83 fe 0a 0f 87 f5 fe ff ff be 41 ff ff 6f 48 29 d6 48
89 04 f1 e9 e4 fe ff ff 48 85 ff 74 79 49 8b 44 24 60 48 85 c0 74 04 <48> 01 78
08 49 8b 44 24 58 48 85 c0 74 04 48 01 78 08 49 8b 44 24
[3.600048] RSP: 002b:7ffc12303b00 EFLAGS: 00010202
[3.601343] RAX: 7fface455e20 RBX: 6dff RCX: 7fface80c040
[3.602587] RDX: RSI: 0029 RDI: 7fface451000
[3.603809] RBP: 7ffc12303c50 R08: 6fff R09: eef5
[3.605015] R10: 7022 R11: 0032 R12: 7fface80c000
[3.606223] R13: 6eff R14: 6e35 R15: 7ffc12303ce0
[3.607421] ---[ end trace 5922ddf43b0f7b83 ]---
[3.608692] hpet: Lost 3 RTC interrupts
Re: [PATCH] powerpc/32s: Use relocation offset when setting early hash table
Christophe Leroy writes:
> When calling early_hash_table(), the kernel hasn't been yet
> relocated to its linking address, so data must be addressed
> with relocation offset.
>
> Add relocation offset to write into Hash in early_hash_table().
>
> Reported-by: Erhard 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.
>>> 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. > > (side note: I tried FB_OF=y instead of DRM_RADEON + DRM_FBDEV_* to speed > up bisection and it turns out in that configuration KASAN never worked, > down to commit 305d600123046, hanging right after bootloader or even > with invalid access in the bootloader itself). My bisection ended up nowhere (at net-next merge with 2k commits), and given the above failure with unrelated configuration change, I conclude that KASAN=y was always broken on this box.
Re: [PATCH] powerpc/32s: Setup the early hash table at all time.
>> 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. (side note: I tried FB_OF=y instead of DRM_RADEON + DRM_FBDEV_* to speed up bisection and it turns out in that configuration KASAN never worked, down to commit 305d600123046, hanging right after bootloader or even with invalid access in the bootloader itself).
Re: [PATCH] powerpc/32s: Setup the early hash table at all time.
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 bisecting now.
Re: [PATCH] powerpc/32s: Setup the early hash table at all time.
> 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 right after "Booting Linux via __start() @ 0x014 ..."
Re: Linux 5.3-rc8
> - 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 behavior. Just for the record because I did not see it mentioned in this thread, this patch by Andy Lutomirski, posted two weeks ago, adds GRND_INSECURE and makes GRND_RANDOM a no-op: https://lore.kernel.org/lkml/cover.1567126741.git.l...@kernel.org/
Re: PROBLEM: 5.3.0-rc* causes iwlwifi failure
> 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 driver. I am attaching the output to 'lspci -vv -s > 02:00.0' as the file device-info. > > All 5.3.0-rc* versions I have tried (including rc4) cause multiple > dmesg iwlwifi-related errors (dmesg attached). Examples: > > iwlwifi :02:00.0: Failed to get geographic profile info -5 > iwlwifi :02:00.0: Microcode SW error detected. Restarting 0x8200 > iwlwifi :02:00.0: 0x0038 | BAD_COMMAND > I have my logs filled with similar garbage throughout 5.3-rc*. Also since 5.3-rcsomething not only it WARNS in dmesg about firmware failure, but completely stops working after suspend/resume cycle. It looks like that: commit 4fd445a2c855bbcab81fbe06d110e78dbd974a5b Author: Haim Dreyfuss Date: Thu May 2 11:45:02 2019 +0300 iwlwifi: mvm: Add log information about SAR status Inform users when SAR status is changing. Signed-off-by: Haim Dreyfuss Signed-off-by: Luca Coelho is the culprit. (manually) reverting it on top of 5.3-rc4 makes everything work again.
Re: [PATCH]: x86_64: Remove unnecessary cast in prefetch()
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 incorrect code without it? See http://gcc.gnu.org/PR33294 for testcase which fails if compiled with gcc 4.2 and above. Yes, incorrect code can be generated without the patch as demonstrated by testcase, but i didn't analyze why kernel appears to work with 4.2 currently. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: x86_64: Remove unnecessary cast in prefetch()
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 patch for inclusion into 2.6.23? It is important 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). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: x86_64: Remove unnecessary cast in prefetch()
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 patch for inclusion into 2.6.23? It is important 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). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: x86_64: Remove unnecessary cast in prefetch()
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 incorrect code without it? See http://gcc.gnu.org/PR33294 for testcase which fails if compiled with gcc 4.2 and above. Yes, incorrect code can be generated without the patch as demonstrated by testcase, but i didn't analyze why kernel appears to work with 4.2 currently. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH]: x86_64: Remove unnecessary cast in prefetch()
It is ok to call prefetch() function with NULL argument, as specifically
commented in include/linux/prefetch.h. But in standard C, it is invalid to
dereference NULL pointer (see C99 standard 6.5.3.2 paragraph 4 and note #84).
Newer gcc versions (4.3 and above) will use that to conclude that "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 |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/include/asm-x86_64/processor.h
===
--- linux.orig/include/asm-x86_64/processor.h
+++ linux/include/asm-x86_64/processor.h
@@ -373,7 +373,7 @@ static inline void sync_core(void)
#define ARCH_HAS_PREFETCH
static inline void prefetch(void *x)
{
- asm volatile("prefetcht0 %0" :: "m" (*(unsigned long *)x));
+ asm volatile("prefetcht0 (%0)" :: "r" (x));
}
#define ARCH_HAS_PREFETCHW 1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH]: x86_64: Remove unnecessary cast in prefetch()
It is ok to call prefetch() function with NULL argument, as specifically
commented in include/linux/prefetch.h. But in standard C, it is invalid to
dereference NULL pointer (see C99 standard 6.5.3.2 paragraph 4 and note #84).
Newer gcc versions (4.3 and above) will use that to conclude that 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 |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/include/asm-x86_64/processor.h
===
--- linux.orig/include/asm-x86_64/processor.h
+++ linux/include/asm-x86_64/processor.h
@@ -373,7 +373,7 @@ static inline void sync_core(void)
#define ARCH_HAS_PREFETCH
static inline void prefetch(void *x)
{
- asm volatile(prefetcht0 %0 :: m (*(unsigned long *)x));
+ asm volatile(prefetcht0 (%0) :: r (x));
}
#define ARCH_HAS_PREFETCHW 1
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [2/58] x86_64: Tell gcc to only align stack to 8 bytes
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 aligned to a 2 raised to num byte boundary. If -mpreferred-stack-boundary is not specified, the default is 4 (16 bytes or 128 bits), except when optimizing for code size (-Os), in which case the default is the minimum correct alignment (4 bytes for x86, and 8 bytes for x86-64). So -mpreferred-stack-boundary=4 is the default and to align stack to 8 bytes you want -mpreferred-stack-boundary=3, not 4, IIUC. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [2/58] x86_64: Tell gcc to only align stack to 8 bytes
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 aligned to a 2 raised to num byte boundary. If -mpreferred-stack-boundary is not specified, the default is 4 (16 bytes or 128 bits), except when optimizing for code size (-Os), in which case the default is the minimum correct alignment (4 bytes for x86, and 8 bytes for x86-64). So -mpreferred-stack-boundary=4 is the default and to align stack to 8 bytes you want -mpreferred-stack-boundary=3, not 4, IIUC. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [announce] split-up -rt patch-queue, v2.6.22.1-rt2
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 download site: Better late than never. Thank You. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [announce] split-up -rt patch-queue, v2.6.22.1-rt2
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 download site: Better late than never. Thank You. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22 released
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 lot of other >> things too. > > I just checked with today's gcc 4.2 (070711) freshly compiled and from a > quick inspection > the code looks correct again. So perhaps it has been already fixed? No, debian's 4.2-20070707-1 is made from another branch (branches/ubuntu/gcc-4_2-branch) CC'ing Debian GCC Maintainer, he will be interested. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22 released
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 lot of other things too. I just checked with today's gcc 4.2 (070711) freshly compiled and from a quick inspection the code looks correct again. So perhaps it has been already fixed? No, debian's 4.2-20070707-1 is made from another branch (branches/ubuntu/gcc-4_2-branch) CC'ing Debian GCC Maintainer, he will be interested. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RSDL v0.31
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 tasks". And "in theory this should be fixed if X is > fixed" does not cut it. X is pretty much _the_ most important thing to > optimize the interactive behavior of a Linux scheduler for. Also, > paradoxically, it is precisely the improvement of _X_ workloads that > RSDL argues with. > > this regression has to be fixed before RSDL can be merged, [...] Let me restate the fact, if it wasn't obvious enough, that most people who tried RSDL (and most of them use desktop systems, me including) never see any regressions compared to mainline. Quite contrary -- their impressions were that with RSDL desktop system runs more smoothly, even under fierce load, which was never possible with mainline scheduler. (see http://article.gmane.org/gmane.linux.kernel/504068 for a list of references.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RSDL v0.31
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 tasks. And in theory this should be fixed if X is fixed does not cut it. X is pretty much _the_ most important thing to optimize the interactive behavior of a Linux scheduler for. Also, paradoxically, it is precisely the improvement of _X_ workloads that RSDL argues with. this regression has to be fixed before RSDL can be merged, [...] Let me restate the fact, if it wasn't obvious enough, that most people who tried RSDL (and most of them use desktop systems, me including) never see any regressions compared to mainline. Quite contrary -- their impressions were that with RSDL desktop system runs more smoothly, even under fierce load, which was never possible with mainline scheduler. (see http://article.gmane.org/gmane.linux.kernel/504068 for a list of references.) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rsdl 30 on 2.6.20.2 breaks user space usb
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). > > any idea why and what to do? might be related to a race condition. sounds like http://bugzilla.kernel.org/show_bug.cgi?id=8166#c32 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rsdl 30 on 2.6.20.2 breaks user space usb
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). any idea why and what to do? might be related to a race condition. sounds like http://bugzilla.kernel.org/show_bug.cgi?id=8166#c32 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2
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 completely useless. Please reconsider your statement. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2
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 completely useless. Please reconsider your statement. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2
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 > existing scheduler does well. If it sucked 95% of the time, it would > have been shredded a long time ago. > I tell you. http://article.gmane.org/gmane.linux.kernel/500027 http://article.gmane.org/gmane.linux.kernel/502996 http://article.gmane.org/gmane.linux.kernel/500119 http://article.gmane.org/gmane.linux.kernel/500784 http://article.gmane.org/gmane.linux.kernel/500768 http://article.gmane.org/gmane.linux.kernel/502255 http://article.gmane.org/gmane.linux.kernel/502282 http://article.gmane.org/gmane.linux.kernel/503650 http://article.gmane.org/gmane.linux.kernel/503695 http://article.gmane.org/gmane.linux.kernel.ck/6512 http://article.gmane.org/gmane.linux.kernel.ck/6539 http://article.gmane.org/gmane.linux.kernel.ck/6565 Also, count my email too. I'm using RSDL since day one on my laptop and my router/compute server and I wont come back to mainline, needless to say why. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2
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 existing scheduler does well. If it sucked 95% of the time, it would have been shredded a long time ago. I tell you. http://article.gmane.org/gmane.linux.kernel/500027 http://article.gmane.org/gmane.linux.kernel/502996 http://article.gmane.org/gmane.linux.kernel/500119 http://article.gmane.org/gmane.linux.kernel/500784 http://article.gmane.org/gmane.linux.kernel/500768 http://article.gmane.org/gmane.linux.kernel/502255 http://article.gmane.org/gmane.linux.kernel/502282 http://article.gmane.org/gmane.linux.kernel/503650 http://article.gmane.org/gmane.linux.kernel/503695 http://article.gmane.org/gmane.linux.kernel.ck/6512 http://article.gmane.org/gmane.linux.kernel.ck/6539 http://article.gmane.org/gmane.linux.kernel.ck/6565 Also, count my email too. I'm using RSDL since day one on my laptop and my router/compute server and I wont come back to mainline, needless to say why. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc3-mm1 RSDL results
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 of a library consisting of only a nopped
> sched_yield() function in userspace?
>
Sure. This is definitely clearer way to do. You just need to put
export LD_PRELOAD=/path/to/your/lib.so somewhere early enough.
cat > yield.c << EOF
int sched_yield (void)
{
return 0;
}
EOF
gcc yield.c -o yield.so -shared -O2 -fPIC -g
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc3-mm1 RSDL results
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 < 1fps).
>> Galeon scrolling pauses for as much as a second. Mouse movement pauses
>> for as much as a second. Typing in terminals lags noticeably.
>>
>> This is not the expected behavior of a fair, low-latency scheduler.
>
> No indeed it does not sound right at all to me either. Last time I
> encountered
> something like this we traced it and hit sched_yield calls somewhere in the
> graphic pipeline. So first question is, how does mainline perform with the
> same testcase, and second question is umm whatever it is that is slow is
> there a way to trace it to see if it yields?
Matt, some 3d drivers are known to do sched_yield() behind user's back,
(notably dri radeon ones, grep for sched_yield:
http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/drivers/dri/r200/r200_ioctl.c?revision=1.37=markup
http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/drivers/dri/r300/radeon_ioctl.c?revision=1.14=markup)
thus absolutely killing any desktop interactivity whatsoever.
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():
kernel/sched.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
Index: linux/kernel/sched.c
===
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -4285,7 +4285,7 @@ asmlinkage long sys_sched_getaffinity(pi
* This function yields the current CPU by dropping the priority of current
* to the lowest priority.
*/
-asmlinkage long sys_sched_yield(void)
+static long sys_sched_yield1(void)
{
struct rq *rq = this_rq_lock();
struct task_struct *p = current;
@@ -4312,6 +4312,11 @@ asmlinkage long sys_sched_yield(void)
return 0;
}
+asmlinkage long sys_sched_yield(void)
+{
+ return 0;
+}
+
static void __cond_resched(void)
{
#ifdef CONFIG_DEBUG_SPINLOCK_SLEEP
@@ -4395,7 +4400,7 @@ EXPORT_SYMBOL(cond_resched_softirq);
void __sched yield(void)
{
set_current_state(TASK_RUNNING);
- sys_sched_yield();
+ sys_sched_yield1();
}
EXPORT_SYMBOL(yield);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc3-mm1 RSDL results
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 1fps).
Galeon scrolling pauses for as much as a second. Mouse movement pauses
for as much as a second. Typing in terminals lags noticeably.
This is not the expected behavior of a fair, low-latency scheduler.
No indeed it does not sound right at all to me either. Last time I
encountered
something like this we traced it and hit sched_yield calls somewhere in the
graphic pipeline. So first question is, how does mainline perform with the
same testcase, and second question is umm whatever it is that is slow is
there a way to trace it to see if it yields?
Matt, some 3d drivers are known to do sched_yield() behind user's back,
(notably dri radeon ones, grep for sched_yield:
http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/drivers/dri/r200/r200_ioctl.c?revision=1.37view=markup
http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/drivers/dri/r300/radeon_ioctl.c?revision=1.14view=markup)
thus absolutely killing any desktop interactivity whatsoever.
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():
kernel/sched.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
Index: linux/kernel/sched.c
===
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -4285,7 +4285,7 @@ asmlinkage long sys_sched_getaffinity(pi
* This function yields the current CPU by dropping the priority of current
* to the lowest priority.
*/
-asmlinkage long sys_sched_yield(void)
+static long sys_sched_yield1(void)
{
struct rq *rq = this_rq_lock();
struct task_struct *p = current;
@@ -4312,6 +4312,11 @@ asmlinkage long sys_sched_yield(void)
return 0;
}
+asmlinkage long sys_sched_yield(void)
+{
+ return 0;
+}
+
static void __cond_resched(void)
{
#ifdef CONFIG_DEBUG_SPINLOCK_SLEEP
@@ -4395,7 +4400,7 @@ EXPORT_SYMBOL(cond_resched_softirq);
void __sched yield(void)
{
set_current_state(TASK_RUNNING);
- sys_sched_yield();
+ sys_sched_yield1();
}
EXPORT_SYMBOL(yield);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc3-mm1 RSDL results
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 of a library consisting of only a nopped
sched_yield() function in userspace?
Sure. This is definitely clearer way to do. You just need to put
export LD_PRELOAD=/path/to/your/lib.so somewhere early enough.
cat yield.c EOF
int sched_yield (void)
{
return 0;
}
EOF
gcc yield.c -o yield.so -shared -O2 -fPIC -g
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: v2.6.20-rt1, yum/rpm
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 linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v2.6.20-rt1, yum/rpm
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 linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
