* Quel Qun | 2008-02-18 00:01:21 [+]:
Please send me your .config file and process list (ps uax > ps_list)
after the crash. I have a dongle with the same usb id as yours and I
can't reproduce the crash. So it is either some .config magic or one of
your programs is accessing the dongle.
Sebast
After umount of
/dev/md/1 on /mnt/sec type xfs (rw,nosuid,nodev,noatime,nodiratime)
I end up with [1] on v2.6.24-rc1. It worked fine with v2.6.23. Bisec
came to conclusion that
|fd5d806266935179deda1502101624832eacd01f is first bad commit
|commit fd5d806266935179deda1502101624832eacd01f
|Author
* Jens Axboe | 2007-10-26 11:32:42 [+0200]:
>On Fri, Oct 26 2007, Jens Axboe wrote:
>> >
>> > I hope this was usefull. Now, I'm going to rebuild my raid now
>> >
>> Thanks a lot, a full report on this issue. Will get this fixed up asap.
No problem, thanks for working on that :)
>
>Does this
* Jens Axboe | 2007-10-26 13:42:30 [+0200]:
>> [2] http://download.breakpoint.cc/bug/bug_rc1_patch_reboot.jpeg 171 KiB
>
>Ah, second BUG() for same issue. Try this one. This?
>
>diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>index 61fdaf0..57fde7b 100644
>--- a/drivers/scsi/scsi_l
* Jens Axboe | 2007-10-27 13:39:16 [+0200]:
>> [1] http://download.breakpoint.cc/bug/bug_patch2.jpeg 134 KiB
>
>OK, can you see what this produces?
>
>diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>index 61fdaf0..4042269 100644
>--- a/drivers/scsi/scsi_lib.c
>+++ b/drivers/scsi/sc
Got with randconfig
include/linux/loop.h:66: error: expected specifier-qualifier-list before
'request_queue_t'
make[1]: *** [fs/compat_ioctl.o] Error 1
parts of compat ioctl require CONFIG_BLOCK to be set.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
Index: b/f
Got with randconfig
drivers/message/i2o/exec-osm.c:539: warning: 'i2o_exec_lct_notify' defined but
not used
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
Index: b/drivers/message/i2o/exec-osm.c
===
--- a/dri
* Arnd Bergmann | 2007-07-21 01:08:57 [+0200]:
>On Saturday 21 July 2007, Sebastian Siewior wrote:
>>
>> Got with randconfig
>> include/linux/loop.h:66: error: expected specifier-qualifier-list before
>> 'request_queue_t'
>> make[1]: *** [fs/compat_io
* Andrew Morton | 2007-07-21 03:31:33 [-0700]:
>On Sat, 21 Jul 2007 00:58:01 +0200 Sebastian Siewior <[EMAIL PROTECTED]> wrote:
>
>> Got with randconfig
>
>randconfig apparently generates impossible configs. Please always
>run `make oldconfig' after the randcon
atomic_inlineasm/vmlinux
4003911 385936 474440 4864287 4a391f atomic_volatile/vmlinux
4003959 385936 474440 4864335 4a394f atomic_volatile_inline/vmlinux
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
--- a/include/asm-x86_64/atomic.h
+++ b/include/asm-x86_64/atomic.h
@@ -29,19
I converted i386+x86-64. Compiled, booted and played for a while. The
description of both patches contains the file size of four kernel builds:
- "normal" is 28e8351ac22de25034e048c680014ad824323c65 as it
- "inline asm" is with this patch
- "inline volatile" is *(volatile int *)&(v)->counter as a s
atomic_inlineasm/vmlinux
3436201 249176 176128 3861505 3aec01 atomic_inline_volatile/vmlinux
3436203 249176 176128 3861507 3aec03 atomic_volatile/vmlinux
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
--- a/include/asm-i386/atomic.h
+++ b/include/asm-i386/atomic.h
@@ -22,19
* Andi Kleen | 2007-08-15 02:20:35 [+0200]:
>> My config with march=pentium-m and gcc (GCC) 4.1.2 (Gentoo 4.1.2):
>> textdata bss dec hex filename
>> 3434150 249176 176128 3859454 3ae3fe atomic_normal/vmlinux
>> 3435308 249176 176128 3860612 3ae884 atomic_inlineasm/vmlinux
* Satyam Sharma | 2007-08-15 18:32:10 [+0530]:
>On Wed, 15 Aug 2007, Herbert Xu wrote:
>
>> Andi Kleen <[EMAIL PROTECTED]> wrote:
>> >> My config with march=pentium-m and gcc (GCC) 4.1.2 (Gentoo 4.1.2):
>> >> textdata bss dec hex filename
>> >> 3434150 249176 176128 3859454 3a
Diff to last post:
- no __*__ functions used.
- no white space fixes.
I converted i386+x86-64 arch. The description of both patches contains the
file size of four kernel builds:
- "normal" is 28e8351ac22de25034e048c680014ad824323c65 as it
- "inline asm" is with this patch
- "inline volatile" is *
3ae884 atomic_inlineasm/vmlinux
3436201 249176 176128 3861505 3aec01 atomic_inline_volatile/vmlinux
3436203 249176 176128 3861507 3aec03 atomic_volatile/vmlinux
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Chris Snook <[EMAIL PR
atomic_inlineasm/vmlinux
4003911 385936 474440 4864287 4a391f atomic_volatile/vmlinux
4003959 385936 474440 4864335 4a394f atomic_volatile_inline/vmlinux
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Chris Snook <[EMAIL PROTECTED]
drivers/mmc/core/host.c: In function 'mmc_remove_host':
drivers/mmc/core/host.c:146: error: implicit declaration of function
'led_trigger_unregister'
drivers/mmc/core/host.c:146: error: 'struct mmc_host' has no member named 'led'
Signed-off-by: Sebastian
know.
>
>Does this work for you?
Yes, it does. Thanks for working on that. Sorry for the late reply but I
run -ENOINET.
Acked-by: Sebastian Siewior <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On 2019-03-13 09:19:32 [+0100], John Ogness wrote:
> recursive situation. As you are pointing out, the notification/wake
> component of printk_safe will still be needed. I will leave that (small)
> part in printk_safe.c.
Does this mean we keep irq_work part or we bury it and solve it by other
mean
On 2021-01-07 11:45:39 [+0100], Peter Zijlstra wrote:
> On Thu, Jan 07, 2021 at 05:18:41PM +0800, Ran Wang wrote:
> > +
> > + if (IS_ENABLED(CONFIG_PREEMPT_RT) &&
> > + !strncmp(p->comm, "ksoftirqd/", 10))
> > + schedule_hrtimeout(&t
On 2021-01-08 08:45:14 [+], Ran Wang wrote:
> Hi Sebastian, Peter
Hi,
> > I had a similar patch in -RT and dropped it in v5.10-rc7-rt16.
> > It was added because RT couldn't boot since creating the boot-threads
> > didn't work before the ksoftirqd was up. This was fixed by commit
> >26c72
On 2021-01-08 10:32:36 [+0100], Peter Zijlstra wrote:
> It's a single task wakeup (the caller), doing that from hardirq context
> really should not be a problem, we do lots of that in RT already.
I'm not worry about that single wakeup but about an artificial case
where you manage to accumulate mul
From: Thomas Gleixner
Bit spinlocks are problematic if PREEMPT_RT is enabled, because they
disable preemption, which is undesired for latency reasons and breaks when
regular spinlocks are taken within the bit_spinlock locked region because
regular spinlocks are converted to 'sleeping spinlocks' o
On 2019-08-10 01:18:34 [-0700], Christoph Hellwig wrote:
> > > Does SLUB work on -rt at all?
> >
> > It's the only allocator we support with a few tweaks :)
>
> What do you do about this particular piece of code there?
This part remains untouched. This "lock" is acquired within ->list_lock
which
On 2019-08-20 20:01:14 [+0200], Thomas Gleixner wrote:
> On Tue, 20 Aug 2019, Matthew Wilcox wrote:
> > On Tue, Aug 20, 2019 at 07:08:18PM +0200, Sebastian Siewior wrote:
> > > Bit spinlocks are problematic if PREEMPT_RT is enabled, because they
> > > disable preempt
On 2020-09-18 10:22:32 [+0200], pet...@infradead.org wrote:
> > > One reason for not allowing migrate_disable() to sleep was: FPU code.
> > >
> > > Could it be it does something like:
> > >
> > > preempt_disable();
> > > spin_lock();
> > >
> > > spin_unlock();
> > > preempt_enable();
> >
On 2020-09-17 16:24:38 [+0200], pet...@infradead.org wrote:
> And if I'm not mistaken, the above migrate_enable() *does* require being
> able to schedule, and our favourite piece of futex:
>
> raw_spin_lock_irq(&q.pi_state->pi_mutex.wait_lock);
> spin_unlock(q.lock_ptr);
>
> is broken
On 2020-09-17 16:49:37 [+0200], pet...@infradead.org wrote:
> I'm aware of the duct-tape :-) But I was under the impression that we
> didn't want the duct-tape, and that there was lots of issues with the
> FPU code, or was that another issue?
Of course it would be better not to need the duct tape.
On 2020-09-17 17:54:10 [+0200], pet...@infradead.org wrote:
> I'm not sure what the problem with FPU was, I was throwing alternatives
> at tglx to see what would stick, in part to (re)discover the design
> constraints of this thing.
was this recent or distant in the time line?
> One reason for no
On 2017-04-25 17:10:37 [+0100], Mark Rutland wrote:
> Hi,
Hi,
> When we bring the secondary CPU online, we detect an erratum that wasn't
> present on the boot CPU, and try to enable a static branch we use to
> track the erratum. The call to static_branch_enable() blows up as above.
this (cpus_set
On 2017-04-26 11:32:36 [+0100], Mark Rutland wrote:
> > So we could end up calling static_branch_enable_cpuslocked()
> > without actually holding the lock. Should we do a cpu_hotplug_begin/done in
> > setup_cpu_feature_capabilities ? I agree it doesn't look that nice.
> > Thoughts ?
>
> I agree t
As trinity figured out, there is a recursive get_online_cpus() in
perf_event_open()'s error path:
| Call Trace:
| dump_stack+0x86/0xce
| __lock_acquire+0x2520/0x2cd0
| lock_acquire+0x27c/0x2f0
| get_online_cpus+0x3d/0x80
| static_key_slow_dec+0x5a/0x70
| sw_perf_event_destroy+0x8e/0x100
| _f
With the last patch on-top I trigger this now and then:
==
WARNING: possible circular locking dependency detected
4.11.0-rc8-00894-g8bd462ee4aac-dirty #84 Not tainted
--
trinity-subchil/496
On 2017-04-01 12:50:58 [+0200], Thomas Gleixner wrote:
> R/W semaphores in RT do not allow multiple readers because a writer
> blocking on the sempahore would have deal with all the readers in terms of
> priority or budget inheritance. While multi reader priority boosting would
> be possible (it ha
On 2017-04-13 22:02:53 [+0800], Alex Shi wrote:
> The rt_mutex_fastunlock() will deboost 'current' task when it should be.
without looking whether or not this patch makes sense those patches
won't apply. Please look at tip/master or tip's locking/core
https://git.kernel.org/pub/scm/linux/
On 2017-11-13 12:56:53 [-0500], Mikulas Patocka wrote:
> Hi
Hi,
> I'm submitting this patch for the CONFIG_PREEMPT_RT patch. It fixes
> deadlocks in device mapper when real time preemption is used.
applied, thank you.
> Mikulas
Sebastian
On 2017-11-21 22:20:51 [+0100], Mike Galbraith wrote:
> On Tue, 2017-11-21 at 14:56 -0500, Mikulas Patocka wrote:
> >
> > If we don't have any reason why it is needed to unplug block requests when
> > a spinlock is taken - so let's not do this.
>
> That's perfectly fine. I guess I shouldn't hav
On 2017-11-18 19:37:10 [+0100], Mike Galbraith wrote:
> Below is my 2012 3.0-rt version of that for reference; at that time we
> were using slab, and slab_lock referenced below was a local_lock. The
> comment came from crash analysis of a deadlock I met before adding the
> (yeah, hacky) __migrate_
39 matches
Mail list logo
