e100 schedule while atomic

e100 schedule while atomic

Post by Arnd Bergman » Sun, 29 Sep 2002 23:00:11



Running e100 on linux-2.5.39 showed that the driver incorrectly
holds a lock while calling request_irq(), which does kmalloc().

This patch appears to solve the problem. Not sure if it is correct,
but something like it has to be done.

        Arnd <><

===== drivers/net/e100/e100_main.c 1.25 vs edited =====
--- 1.25/drivers/net/e100/e100_main.c   Fri Sep 20 01:58:59 2002

        netif_start_queue(dev);

        e100_start_ru(bdp);
-       if ((rc = request_irq(dev->irq, &e100intr, SA_SHIRQ,
-                             dev->name, dev)) != 0) {
-               del_timer_sync(&bdp->watchdog_timer);
-               goto err_exit;
+
+       read_unlock(&(bdp->isolate_lock));
+       rc = request_irq(dev->irq, &e100intr, SA_SHIRQ, dev->name, dev);
+       read_lock(&(bdp->isolate_lock));
+
+       if (rc != 0)
+               goto err_exit2;
+
+       if (bdp->driver_isolated) {
+               free_irq(dev->irq, dev);
+               rc = -EBUSY;
+               goto err_exit2;
        }
+
        if (bdp->params.b_params & PRM_RX_CONG) {
                DECLARE_TASKLET(polling_tasklet,

        goto exit;

+err_exit2:
+       del_timer_sync(&bdp->watchdog_timer);
 err_exit:
        e100_clear_pools(bdp);
 exit:

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

e100 schedule while atomic

Post by Feldman, Scot » Wed, 02 Oct 2002 00:00:09



> Running e100 on linux-2.5.39 showed that the driver
> incorrectly holds a lock while calling request_irq(), which
> does kmalloc().

> This patch appears to solve the problem. Not sure if it is
> correct, but something like it has to be done.

Thanks for pointing this out.  I don't think the lock needs to be held at
all in e100_open, so we'll look into cleaning that up.  Regardless, we'll
included a fix for this problem in our next set of patches to Jeff.

-scott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. 2.5.53-mm3: bad: scheduling while atomic!

Running 2.5.53-mm3, I got the following:

bad: scheduling while atomic!
Call Trace:
 [<c0114381>] do_schedule+0x3d/0x2c8
 [<c011d9b0>] schedule_timeout+0x80/0xa0
 [<c011d924>] process_timeout+0x0/0xc
 [<c0115315>] io_schedule_timeout+0x11/0x1c
 [<c01de5de>] blk_congestion_wait+0x8a/0xa0
 [<c0115a54>] autoremove_wake_function+0x0/0x38
 [<c0115a54>] autoremove_wake_function+0x0/0x38
 [<c012fbb4>] try_to_free_pages+0x3c/0xbc
 [<c012a33c>] __alloc_pages+0x1b4/0x260
 [<c012a410>] __get_free_pages+0x28/0x64
 [<c012c7e6>] cache_grow+0xb6/0x20c
 [<c012c9cf>] __cache_alloc_refill+0x93/0x220
 [<c012cb96>] cache_alloc_refill+0x3a/0x58
 [<c012cf1d>] kmem_cache_alloc+0x45/0xc8
 [<c0136460>] pte_chain_alloc+0x38/0x68
 [<c0130eea>] copy_page_range+0x2be/0x3f0
 [<c0115f8b>] copy_mm+0x283/0x348
 [<c0116a4f>] copy_process+0x61b/0xb24
 [<c0116fd6>] do_fork+0x7e/0x134
 [<c0107478>] sys_fork+0x18/0x2c
 [<c01089af>] syscall_call+0x7/0xb

dpkg: page allocation failure. order:0, mode:0x20
dpkg: page allocation failure. order:0, mode:0x20
xmms: page allocation failure. order:5, mode:0x20
xmms: page allocation failure. order:4, mode:0x20
xmms: page allocation failure. order:3, mode:0x20

--
L1:     khromy          ;khromy(at)lnuxlab.ath.cx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. which Linux is better?

3. scheduling while atomic

4. Turn $20.00 into $50,000.00 (really this works!)

5. 2.5.73 Scheduling while atomic with taskfile IO and high memory

6. How to make new man page ???

7. 2.5.41 Autofs4: bad: scheduling while atomic!

8. Apps

9. Bug: swsusp in 2.5.42: "Scheduling while atomic"

10. 2.5 kernel + hostap_cs + X11 = scheduling while atomic

11. bad: scheduling while atomic!

12. bad: scheduling while atomic

13. 2.5.72 oops (scheduling while atomic)