Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On Wed, Nov 07, 2012 at 08:19:19PM +0100, Takashi Iwai wrote: > How about the patch below? (It's for 3.6, and won't be applied cleanly > to 3.7, but easy to adapt.) Thanks, that patch seems to fix the problem. Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On Wed, Nov 07, 2012 at 08:19:19PM +0100, Takashi Iwai wrote: How about the patch below? (It's for 3.6, and won't be applied cleanly to 3.7, but easy to adapt.) Thanks, that patch seems to fix the problem. Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On Sat, Nov 03, 2012 at 03:16:36PM +0100, Daniel Mack wrote: > On 03.11.2012 15:10, Christof Meerwald wrote: > > http://comments.gmane.org/gmane.comp.voip.twinkle/3052 and > > http://pastebin.com/aHGe1S1X for a self-contained C test. > Some questions: > > - Are you seeing the same issue with 3.6.x? I haven't tried it myself, but the other poster on http://comments.gmane.org/gmane.comp.voip.twinkle/3052 mentions 3.6.2 (and 3.6.3) > - If you can reproduce this issue, could you paste the messages in > dmesg when this happens? Do they resemble to the list corruption that > was reported? I am not seeing any kernel messages at all - the system just freezes and not even the SysRq stuff works after that. > - Do you see the same problem with 3.4? I upgraded from Ubuntu 12.04 (Linux 3.2) where I didn't see the problem. However, http://www.linuxquestions.org/questions/linux-desktop-74/twinkle-causes-linux-freeze-kernel-3-6-2-a-4175433799/ mentions 3.4.0 > - Are you able to apply the patch Alan Stern posted in this thread earlier? Unfortunately, I am not really in a position to apply kernel patches at the moment. > We should really sort this out, but I unfortunately lack a system or > setup that shows the bug. BTW, I have been able to reproduce the problem on a completely different machine (also running Ubuntu 12.10, but different hardware). The important thing appears to be that the USB audio device is connected via a USB 2.0 hub (and then using the test code posted in http://pastebin.com/aHGe1S1X specifying the audio device as "plughw:Set" (or whatever it's called) seems to trigger the freeze). So I guess another question is: do you have a USB headset connected via a USB 2.0 hub and not seeing the problem or is your USB headset not connected via a USB 2.0 hub? (of course, it would also be useful if others could comment if they are seeing the problem with that setup or not) Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On Sat, Nov 03, 2012 at 03:16:36PM +0100, Daniel Mack wrote: On 03.11.2012 15:10, Christof Meerwald wrote: http://comments.gmane.org/gmane.comp.voip.twinkle/3052 and http://pastebin.com/aHGe1S1X for a self-contained C test. Some questions: - Are you seeing the same issue with 3.6.x? I haven't tried it myself, but the other poster on http://comments.gmane.org/gmane.comp.voip.twinkle/3052 mentions 3.6.2 (and 3.6.3) - If you can reproduce this issue, could you paste the messages in dmesg when this happens? Do they resemble to the list corruption that was reported? I am not seeing any kernel messages at all - the system just freezes and not even the SysRq stuff works after that. - Do you see the same problem with 3.4? I upgraded from Ubuntu 12.04 (Linux 3.2) where I didn't see the problem. However, http://www.linuxquestions.org/questions/linux-desktop-74/twinkle-causes-linux-freeze-kernel-3-6-2-a-4175433799/ mentions 3.4.0 - Are you able to apply the patch Alan Stern posted in this thread earlier? Unfortunately, I am not really in a position to apply kernel patches at the moment. We should really sort this out, but I unfortunately lack a system or setup that shows the bug. BTW, I have been able to reproduce the problem on a completely different machine (also running Ubuntu 12.10, but different hardware). The important thing appears to be that the USB audio device is connected via a USB 2.0 hub (and then using the test code posted in http://pastebin.com/aHGe1S1X specifying the audio device as plughw:Set (or whatever it's called) seems to trigger the freeze). So I guess another question is: do you have a USB headset connected via a USB 2.0 hub and not seeing the problem or is your USB headset not connected via a USB 2.0 hub? (of course, it would also be useful if others could comment if they are seeing the problem with that setup or not) Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On Sat, 20 Oct 2012 23:15:17 + (GMT), Artem S. Tashkinov wrote: > It's almost definitely either a USB driver bug or video4linux driver bug: > > I'm CC'ing linux-media and linux-usb mailing lists, the problem is described > here: > https://lkml.org/lkml/2012/10/20/35 > https://lkml.org/lkml/2012/10/20/148 Not sure if it's related, but I am seeing a kernel freeze with a usb-audio headset (connected via an external USB hub) on Linux 3.5.0 (Ubuntu 12.10) - see http://comments.gmane.org/gmane.comp.voip.twinkle/3052 and http://pastebin.com/aHGe1S1X for a self-contained C test. Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On Sat, 20 Oct 2012 23:15:17 + (GMT), Artem S. Tashkinov wrote: It's almost definitely either a USB driver bug or video4linux driver bug: I'm CC'ing linux-media and linux-usb mailing lists, the problem is described here: https://lkml.org/lkml/2012/10/20/35 https://lkml.org/lkml/2012/10/20/148 Not sure if it's related, but I am seeing a kernel freeze with a usb-audio headset (connected via an external USB hub) on Linux 3.5.0 (Ubuntu 12.10) - see http://comments.gmane.org/gmane.comp.voip.twinkle/3052 and http://pastebin.com/aHGe1S1X for a self-contained C test. Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] epoll: replace EPOLL_CTL_DISABLE with EPOLL_CTL_POKE
On Fri, 2 Nov 2012 04:13:12 +, Eric Wong wrote: [...] > EPOLL_CTL_POKE may be used to force an item into the epoll > ready list. Instead of disabling an item asynchronously > via EPOLL_CTL_DISABLE, this forces the threads calling > epoll_wait() to handle the item in its normal loop. That was my initial suggestion as well - see https://lkml.org/lkml/2012/6/19/358 Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] epoll: replace EPOLL_CTL_DISABLE with EPOLL_CTL_POKE
On Fri, 2 Nov 2012 04:13:12 +, Eric Wong wrote: [...] EPOLL_CTL_POKE may be used to force an item into the epoll ready list. Instead of disabling an item asynchronously via EPOLL_CTL_DISABLE, this forces the threads calling epoll_wait() to handle the item in its normal loop. That was my initial suggestion as well - see https://lkml.org/lkml/2012/6/19/358 Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] epoll: Improved support for multi-threaded clients
Hi Paton, On Thu, Aug 02, 2012 at 06:37:06PM -0700, Paton J. Lewis wrote: [...] > My first concern is about code clarity. Using a custom event to > delete an event type (either EPOLLIN or EPOLLOUT) from an epoll item > requires that functionality to be split across two areas of code: > the code that requests the deletion (via the call to epoll_ctl), and > the code that responds to it (via epoll_wait). But don't you have a similar problem in your proposal as well as you might get an EBUSY when trying to disabling the item - in which case you would have to do the deletion in the epoll_wait loop. > However, my main concern is about performance. Handling a custom > event means that each return from epoll_wait requires the responding > thread to check for possible custom events, which in the case of > deletion is going to be relatively rare. Thus code which was once > purely concerned with responding to I/O events must now spend a > fraction of its time testing for exceptional conditions. In > addition, handling deletion in this manner now requires a thread or > context switch. But in your initial proposal you also had the code checking for deletion in the epoll_wait loop. > Given the drawbacks listed above, and the kernel design philosophy > of only implementing what is actually needed, I would argue for > sticking with the original EPOLL_CTL_DISABLE proposal for now. I have finally had some chance to play around with your patch a bit and I really think that you don't want to check for ep_is_linked(>rdllink) in ep_disable as I don't see that this would provide any useful semantics with respect to race-conditions. I.e. consider the point in the epoll_wait loop just after you have re-enabled to item - in this case ep_disable would (almost certainly) return EBUSY, but there is no guarantee that epoll_wait will be woken up on the next iteration. As I mentioned, I think it would be much more useful to check for "epi->event.events & ~EP_PRIVATE_BITS" instead which I believe would provide more useful semantics. Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] epoll: Improved support for multi-threaded clients
Hi Paton, On Thu, Aug 02, 2012 at 06:37:06PM -0700, Paton J. Lewis wrote: [...] My first concern is about code clarity. Using a custom event to delete an event type (either EPOLLIN or EPOLLOUT) from an epoll item requires that functionality to be split across two areas of code: the code that requests the deletion (via the call to epoll_ctl), and the code that responds to it (via epoll_wait). But don't you have a similar problem in your proposal as well as you might get an EBUSY when trying to disabling the item - in which case you would have to do the deletion in the epoll_wait loop. However, my main concern is about performance. Handling a custom event means that each return from epoll_wait requires the responding thread to check for possible custom events, which in the case of deletion is going to be relatively rare. Thus code which was once purely concerned with responding to I/O events must now spend a fraction of its time testing for exceptional conditions. In addition, handling deletion in this manner now requires a thread or context switch. But in your initial proposal you also had the code checking for deletion in the epoll_wait loop. Given the drawbacks listed above, and the kernel design philosophy of only implementing what is actually needed, I would argue for sticking with the original EPOLL_CTL_DISABLE proposal for now. I have finally had some chance to play around with your patch a bit and I really think that you don't want to check for ep_is_linked(epi-rdllink) in ep_disable as I don't see that this would provide any useful semantics with respect to race-conditions. I.e. consider the point in the epoll_wait loop just after you have re-enabled to item - in this case ep_disable would (almost certainly) return EBUSY, but there is no guarantee that epoll_wait will be woken up on the next iteration. As I mentioned, I think it would be much more useful to check for epi-event.events ~EP_PRIVATE_BITS instead which I believe would provide more useful semantics. Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] epoll: Improved support for multi-threaded clients
On Fri, Jun 29, 2012 at 02:43:06PM -0700, Paton J. Lewis wrote: > At 6/19/2012 11:17 AM, Christof Meerwald wrote: > >But, taking one step back - wouldn't an alternative approach be to add > >some mechanism to allow a thread to post a user-event for an fd? So in > >delete_epoll_item you would post a user event (e.g. EPOLLUSER) for the > >fd which you can then handle in your epoll_wait processing thread - > >with no additional synchronisation necessary. > I think this is an excellent suggestion, and in fact your proposal > is more similar to what Windows provides when solving this problem. > I'll test this idea out with our code and get back to you. Is there > an existing kernel technique that you would recommend for posting a > user event for an fd, or should I explore using epoll_ctl with > EPOLL_CTL_MOD? I don't know about any existing kernel technique for this, but my gut feeling would be a new op value for epoll_ctl, maybe something like EPOLL_CTL_TRIGGER. Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] epoll: Improved support for multi-threaded clients
On Fri, Jun 29, 2012 at 02:43:06PM -0700, Paton J. Lewis wrote: At 6/19/2012 11:17 AM, Christof Meerwald wrote: But, taking one step back - wouldn't an alternative approach be to add some mechanism to allow a thread to post a user-event for an fd? So in delete_epoll_item you would post a user event (e.g. EPOLLUSER) for the fd which you can then handle in your epoll_wait processing thread - with no additional synchronisation necessary. I think this is an excellent suggestion, and in fact your proposal is more similar to what Windows provides when solving this problem. I'll test this idea out with our code and get back to you. Is there an existing kernel technique that you would recommend for posting a user event for an fd, or should I explore using epoll_ctl with EPOLL_CTL_MOD? I don't know about any existing kernel technique for this, but my gut feeling would be a new op value for epoll_ctl, maybe something like EPOLL_CTL_TRIGGER. Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
