http://bugzilla.kernel.org/show_bug.cgi?id=5918





------- Additional Comments From [EMAIL PROTECTED]  2006-02-15 11:48 -------

(Re-added bugzilla to cc)

Nils Rennebarth <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
> > Gee.  I guess it'd be useful to identify whic two subsystems have to be
> > initialised in which order for the problem to occur.
> Turned out now, that the problem appears to be somewhere else.
> 
> To recall: the problem was:
> "irq 11: nobody cared", and later: "Disabling IRQ" during booting, which 
> stops 
> my network adapters from getting any irqs, rendering them quasi dead.
> 
> - I can reliably trigger the problem now, by creating traffic on any of the 
> interfaces of the machine during boot. If on the other hand I power the 
> machine 
> down, unplug both cables and power on again, I reliably get a working machine.
> - Testing with vanilla 2.4.14 exhibits the same problem
> 
> Does that mean, e100 is the culprit?
> Should I try to go back to see where the problem starts?
> 
> I won't be available for replys/further examination before Mo 20.2. though.

Seems that your USB host controller and both e100's are all sharing the
IRQ11 line.  Somehow, an e100 is asserting that line before it has
registered its interrupt handler.  I can't see how that can happen from the
driver...

Could you please test 2.6.16-rc3, or whatever's the latest released kernel?

Also, this patch might help:


diff -puN drivers/net/e100.c~a drivers/net/e100.c
--- devel/drivers/net/e100.c~a  2006-02-15 11:44:09.000000000 -0800
+++ devel-akpm/drivers/net/e100.c       2006-02-15 11:44:49.000000000 -0800
@@ -2055,6 +2055,10 @@ static int e100_up(struct nic *nic)
 {
        int err;
 
+       printk("%s\n", __FUNCTION__);
+       if((err = request_irq(nic->pdev->irq, e100_intr, SA_SHIRQ,
+               nic->netdev->name, nic->netdev)))
+               goto err_no_irq;
        if((err = e100_rx_alloc_list(nic)))
                return err;
        if((err = e100_alloc_cbs(nic)))
@@ -2064,9 +2068,6 @@ static int e100_up(struct nic *nic)
        e100_set_multicast_list(nic->netdev);
        e100_start_receiver(nic, NULL);
        mod_timer(&nic->watchdog, jiffies);
-       if((err = request_irq(nic->pdev->irq, e100_intr, SA_SHIRQ,
-               nic->netdev->name, nic->netdev)))
-               goto err_no_irq;
        netif_wake_queue(nic->netdev);
        netif_poll_enable(nic->netdev);
        /* enable ints _after_ enabling poll, preventing a race between
_



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
acpi-bugzilla mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla

Reply via email to