[EMAIL PROTECTED] said:
> Ah. No, I don't think it would be polite to cause TTY hangup
> processing to be deferred for this long. I'd suggest that the policy
> be "scheduled tasks can't sleep". I guess kmalloc(GFP_KERNEL) is
> acceptable because the system is already running like a dog if thi
David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > Nothing which sleeps for very long - mainly serial drivers which
> > queue a call to tty_hangup(), which immediately queues _another_
> > tq_scheduler call to do_tty_hangup (Why? Heaven knows).
>
> Not so much worried about that. More abou
[EMAIL PROTECTED] said:
> Nothing which sleeps for very long - mainly serial drivers which
> queue a call to tty_hangup(), which immediately queues _another_
> tq_scheduler call to do_tty_hangup (Why? Heaven knows).
Not so much worried about that. More about how sensitive they would be to
so
David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > Multiple seconds in the worst case.
>
> Well, I think the PCMCIA socket drivers would be happy with that. Depends
> what akpm also added to the list of tasks,
Nothing which sleeps for very long - mainly serial drivers which queue
a call to
[EMAIL PROTECTED] said:
> Multiple seconds in the worst case.
Well, I think the PCMCIA socket drivers would be happy with that. Depends
what akpm also added to the list of tasks, and whether Linus actually puts
that patch into test12.
Probably best to leave it for now and think about it in
On Tue, Nov 21, 2000, David Woodhouse <[EMAIL PROTECTED]> wrote:
> On Tue, 21 Nov 2000, Johannes Erdfelt wrote:
>
> > That that possible? usb_hub_events can block for a long time. That is why
> > the kernel thread was needed. I'm not familiar with schedule_task enough
> > to know if it can be use
On Tue, 21 Nov 2000, Johannes Erdfelt wrote:
> That that possible? usb_hub_events can block for a long time. That is why
> the kernel thread was needed. I'm not familiar with schedule_task enough
> to know if it can be used.
Ah. How long? At first glance, it didn't look to me as if it would slee
On Tue, Nov 21, 2000, David Woodhouse <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] said:
> > We applied a slightly different patch which is would not remove the
> > pages out from under the thread, using semaphores instead.
>
> > This patch isn't needed anymore. Thanks anyway.
>
> Actually
[EMAIL PROTECTED] said:
> We applied a slightly different patch which is would not remove the
> pages out from under the thread, using semaphores instead.
> This patch isn't needed anymore. Thanks anyway.
Actually, the best fix is probably to get rid of the thread entirely and use
schedule_tas
On Fri, Nov 17, 2000, Oleg Drokin <[EMAIL PROTECTED]> wrote:
> hub.c in 2.4.0-test10 and above contains hardcoded HZ value,
> which is wrong. Here is the patch:
>
>
> --- drivers/usb/hub.c.origFri Nov 17 12:51:34 2000
> +++ drivers/usb/hub.c Fri Nov 17 12:51:59 2000
> @@ -813,7 +813,
Hello!
hub.c in 2.4.0-test10 and above contains hardcoded HZ value,
which is wrong. Here is the patch:
--- drivers/usb/hub.c.orig Fri Nov 17 12:51:34 2000
+++ drivers/usb/hub.c Fri Nov 17 12:51:59 2000
@@ -813,7 +813,7 @@
ret = kill_proc(khubd_pid, SIGTERM, 1);
if
11 matches
Mail list logo
