* Rawmidi and CONFIG_DEBUG_SPINLOCK_SLEEP @ 2004-01-29 20:27 Thomas Charbonnel 2004-01-31 8:44 ` Jaroslav Kysela 0 siblings, 1 reply; 5+ messages in thread From: Thomas Charbonnel @ 2004-01-29 20:27 UTC (permalink / raw) To: ALSA development Hi, I noticed this problem today using midi on my setup (alsa 1.0.1, kernel 2.6.1 with CONFIG_DEBUG_SPINLOCK_SLEEP) : Debug: sleeping function called from invalid context at include/asm/uaccess.h:473 in_atomic():1, irqs_disabled():1 Call Trace: [<c012139c>] __might_sleep+0xac/0xe0 [<c010b170>] handle_signal+0xd0/0x140 [<c03955ef>] snd_rawmidi_kernel_read1+0x10f/0x170 [<c03957e7>] snd_rawmidi_read+0x147/0x1b0 [<c01131cf>] restore_i387_fxsave+0x8f/0xa0 [<c015b2f3>] vfs_read+0xd3/0x140 [<c015b59f>] sys_read+0x3f/0x60 [<c010b4bb>] syscall_call+0x7/0xb I'm sorry I didn't check if this was fixed in 1.0.2, but though it was worth mentioning. This caused regular (~ 1/second) dropouts in pd while using midi. Thomas ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Rawmidi and CONFIG_DEBUG_SPINLOCK_SLEEP 2004-01-29 20:27 Rawmidi and CONFIG_DEBUG_SPINLOCK_SLEEP Thomas Charbonnel @ 2004-01-31 8:44 ` Jaroslav Kysela 2004-02-01 11:18 ` Thomas Charbonnel 0 siblings, 1 reply; 5+ messages in thread From: Jaroslav Kysela @ 2004-01-31 8:44 UTC (permalink / raw) To: Thomas Charbonnel; +Cc: ALSA development On Thu, 29 Jan 2004, Thomas Charbonnel wrote: > Hi, > > I noticed this problem today using midi on my setup (alsa 1.0.1, kernel > 2.6.1 with CONFIG_DEBUG_SPINLOCK_SLEEP) : > > Debug: sleeping function called from invalid context at > include/asm/uaccess.h:473 > in_atomic():1, irqs_disabled():1 > Call Trace: > [<c012139c>] __might_sleep+0xac/0xe0 > [<c010b170>] handle_signal+0xd0/0x140 > [<c03955ef>] snd_rawmidi_kernel_read1+0x10f/0x170 > [<c03957e7>] snd_rawmidi_read+0x147/0x1b0 > [<c01131cf>] restore_i387_fxsave+0x8f/0xa0 > [<c015b2f3>] vfs_read+0xd3/0x140 > [<c015b59f>] sys_read+0x3f/0x60 > [<c010b4bb>] syscall_call+0x7/0xb > > I'm sorry I didn't check if this was fixed in 1.0.2, but though it was > worth mentioning. This caused regular (~ 1/second) dropouts in pd while > using midi. I'm not sure, but it looks like kernel problem. We don't call handle_signal() function from snd_rawmidi_kernel_read1() - you may check this function - scheduling is not involved. I wonder why this function is called from in the spinlock context. Please, report this problem to LKML or try the latest 2.6 kernel. Jaroslav ----- Jaroslav Kysela <perex@suse.cz> Linux Kernel Sound Maintainer ALSA Project, SuSE Labs ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Rawmidi and CONFIG_DEBUG_SPINLOCK_SLEEP 2004-01-31 8:44 ` Jaroslav Kysela @ 2004-02-01 11:18 ` Thomas Charbonnel 2004-02-01 14:30 ` Thomas Charbonnel 0 siblings, 1 reply; 5+ messages in thread From: Thomas Charbonnel @ 2004-02-01 11:18 UTC (permalink / raw) To: Jaroslav Kysela, ALSA development Jaroslav Kysela a écrit : > On Thu, 29 Jan 2004, Thomas Charbonnel wrote: > > >>Hi, >> >>I noticed this problem today using midi on my setup (alsa 1.0.1, kernel >>2.6.1 with CONFIG_DEBUG_SPINLOCK_SLEEP) : >> >>Debug: sleeping function called from invalid context at >>include/asm/uaccess.h:473 >>in_atomic():1, irqs_disabled():1 >>Call Trace: >> [<c012139c>] __might_sleep+0xac/0xe0 >> [<c010b170>] handle_signal+0xd0/0x140 >> [<c03955ef>] snd_rawmidi_kernel_read1+0x10f/0x170 >> [<c03957e7>] snd_rawmidi_read+0x147/0x1b0 >> [<c01131cf>] restore_i387_fxsave+0x8f/0xa0 >> [<c015b2f3>] vfs_read+0xd3/0x140 >> [<c015b59f>] sys_read+0x3f/0x60 >> [<c010b4bb>] syscall_call+0x7/0xb >> >>I'm sorry I didn't check if this was fixed in 1.0.2, but though it was >>worth mentioning. This caused regular (~ 1/second) dropouts in pd while >>using midi. > > > I'm not sure, but it looks like kernel problem. We don't call > handle_signal() function from snd_rawmidi_kernel_read1() - you may check > this function - scheduling is not involved. I wonder why this function is > called from in the spinlock context. > > Please, report this problem to LKML or try the latest 2.6 kernel. > > Jaroslav > Hi Jaroslav, Doing some more tests I got also this message : Debug: sleeping function called from invalid context at include/asm/uaccess.h:498 in_atomic():1, irqs_disabled():1 Call Trace: [<c012139c>] __might_sleep+0xac/0xe0 [<c0395c2d>] snd_rawmidi_kernel_write1+0x16d/0x200 [<c0395ea4>] snd_rawmidi_write+0x1b4/0x300 [<c010b2c1>] do_signal+0xe1/0xf0 [<c01131cf>] restore_i387_fxsave+0x8f/0xa0 [<c015b4f3>] vfs_write+0xd3/0x140 [<c015b5ff>] sys_write+0x3f/0x60 [<c010b4bb>] syscall_call+0x7/0xb The kernel functions pointed to in include/asm/usaccess.h are copy_to_user and copy_from_user. They are indeed called from a spinlock context from both snd_rawmidi_kernel_write1 and snd_rawmidi_kernel_read1, and are flagged might_sleep. The strange thing is that they were already flagged might_sleep in 2.6.0, which I believe I compiled with CONFIG_DEBUG_SPINLOCK_SLEEP also, and I can't remember having the problem. On the other hand I only checked dmesg here because I could hear audio dropouts. Maybe the might_sleep detection code has been changed and is responsible for the dropouts ? Thomas ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Rawmidi and CONFIG_DEBUG_SPINLOCK_SLEEP 2004-02-01 11:18 ` Thomas Charbonnel @ 2004-02-01 14:30 ` Thomas Charbonnel 2004-02-01 16:37 ` Jaroslav Kysela 0 siblings, 1 reply; 5+ messages in thread From: Thomas Charbonnel @ 2004-02-01 14:30 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: ALSA development [-- Attachment #1: Type: text/plain, Size: 2678 bytes --] Thomas Charbonnel wrote : > Jaroslav Kysela a écrit : > >> On Thu, 29 Jan 2004, Thomas Charbonnel wrote: >> >> >>> Hi, >>> >>> I noticed this problem today using midi on my setup (alsa 1.0.1, >>> kernel 2.6.1 with CONFIG_DEBUG_SPINLOCK_SLEEP) : >>> >>> Debug: sleeping function called from invalid context at >>> include/asm/uaccess.h:473 >>> in_atomic():1, irqs_disabled():1 >>> Call Trace: >>> [<c012139c>] __might_sleep+0xac/0xe0 >>> [<c010b170>] handle_signal+0xd0/0x140 >>> [<c03955ef>] snd_rawmidi_kernel_read1+0x10f/0x170 >>> [<c03957e7>] snd_rawmidi_read+0x147/0x1b0 >>> [<c01131cf>] restore_i387_fxsave+0x8f/0xa0 >>> [<c015b2f3>] vfs_read+0xd3/0x140 >>> [<c015b59f>] sys_read+0x3f/0x60 >>> [<c010b4bb>] syscall_call+0x7/0xb >>> >>> I'm sorry I didn't check if this was fixed in 1.0.2, but though it >>> was worth mentioning. This caused regular (~ 1/second) dropouts in pd >>> while using midi. >> >> >> >> I'm not sure, but it looks like kernel problem. We don't call >> handle_signal() function from snd_rawmidi_kernel_read1() - you may check >> this function - scheduling is not involved. I wonder why this function is >> called from in the spinlock context. >> >> Please, report this problem to LKML or try the latest 2.6 kernel. >> >> Jaroslav >> > > Hi Jaroslav, > > Doing some more tests I got also this message : > > Debug: sleeping function called from invalid context at > include/asm/uaccess.h:498 > in_atomic():1, irqs_disabled():1 > Call Trace: > [<c012139c>] __might_sleep+0xac/0xe0 > [<c0395c2d>] snd_rawmidi_kernel_write1+0x16d/0x200 > [<c0395ea4>] snd_rawmidi_write+0x1b4/0x300 > [<c010b2c1>] do_signal+0xe1/0xf0 > [<c01131cf>] restore_i387_fxsave+0x8f/0xa0 > [<c015b4f3>] vfs_write+0xd3/0x140 > [<c015b5ff>] sys_write+0x3f/0x60 > [<c010b4bb>] syscall_call+0x7/0xb > > The kernel functions pointed to in include/asm/usaccess.h are > copy_to_user and copy_from_user. They are indeed called from a spinlock > context from both snd_rawmidi_kernel_write1 and > snd_rawmidi_kernel_read1, and are flagged might_sleep. The strange thing > is that they were already flagged might_sleep in 2.6.0, which I believe > I compiled with CONFIG_DEBUG_SPINLOCK_SLEEP also, and I can't remember > having the problem. On the other hand I only checked dmesg here because > I could hear audio dropouts. Maybe the might_sleep detection code has > been changed and is responsible for the dropouts ? > > Thomas > Hi Jaroslav, The attached patch fixes the problem for me, but I took the obvious and easy way - I may have missed something. Thomas [-- Attachment #2: rawmidi.patch --] [-- Type: text/plain, Size: 1076 bytes --] --- rawmidi.c.old 2003-10-23 16:34:52.000000000 +0200 +++ rawmidi.c 2004-02-01 15:04:15.000000000 +0100 @@ -909,10 +909,11 @@ if (kernel) { memcpy(buf + result, runtime->buffer + runtime->appl_ptr, count1); } else { + spin_unlock_irqrestore(&runtime->lock, flags); if (copy_to_user(buf + result, runtime->buffer + runtime->appl_ptr, count1)) { - spin_unlock_irqrestore(&runtime->lock, flags); return result > 0 ? result : -EFAULT; } + spin_lock_irqsave(&runtime->lock, flags); } runtime->appl_ptr += count1; runtime->appl_ptr %= runtime->buffer_size; @@ -1133,10 +1134,13 @@ if (kernel) { memcpy(runtime->buffer + runtime->appl_ptr, buf, count1); } else { + spin_unlock_irqrestore(&runtime->lock, flags); if (copy_from_user(runtime->buffer + runtime->appl_ptr, buf, count1)) { + spin_lock_irqsave(&runtime->lock, flags); result = result > 0 ? result : -EFAULT; goto __end; } + spin_lock_irqsave(&runtime->lock, flags); } runtime->appl_ptr += count1; runtime->appl_ptr %= runtime->buffer_size; ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Rawmidi and CONFIG_DEBUG_SPINLOCK_SLEEP 2004-02-01 14:30 ` Thomas Charbonnel @ 2004-02-01 16:37 ` Jaroslav Kysela 0 siblings, 0 replies; 5+ messages in thread From: Jaroslav Kysela @ 2004-02-01 16:37 UTC (permalink / raw) To: Thomas Charbonnel; +Cc: ALSA development On Sun, 1 Feb 2004, Thomas Charbonnel wrote: > The attached patch fixes the problem for me, but I took the obvious and > easy way - I may have missed something. Nope. It looks good. I've applied it to CVS. Thanks for analyze. Jaroslav ----- Jaroslav Kysela <perex@suse.cz> Linux Kernel Sound Maintainer ALSA Project, SuSE Labs ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-02-01 16:36 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-01-29 20:27 Rawmidi and CONFIG_DEBUG_SPINLOCK_SLEEP Thomas Charbonnel 2004-01-31 8:44 ` Jaroslav Kysela 2004-02-01 11:18 ` Thomas Charbonnel 2004-02-01 14:30 ` Thomas Charbonnel 2004-02-01 16:37 ` Jaroslav Kysela
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.