Messages in this thread | | | Date | Sun, 19 Dec 1999 14:08:19 -0600 | From | Jason Bratton <> | Subject | Re: [Fwd: problem involving wait_on_bh] |
| |
> folks. Also try the 3c59x.c driver in the standard 2.2.x kernel. If both > give the same hang its probably some general kernel bug you are hitting, if > the other 3c59x works or at least fails differently then the hang is > probably caused by the 3com driver, and my guess would be it doing a > disable_irq() while holding a lock used in the irq handler
I tried using the 3c59x.c driver in the kernel like you suggested, and I was able to shut down the ethernet using ifconfig just fine. Then I took a look at the source for the 3com driver that 3com released, and sure enough, it had a lock while doing a disable_irq. Thanks for the help.
To reply to a few other responses I received, it is very easy to reproduce through shutting down the ethernet with ifconfig. The kernel does print the wait_on_bh for both CPUs, however it was the exact same message and I just happened to pick one that was for CPU1. To the person who wanted the output from a ksymoops, here it is: Trace; c010b2ad <synchronize_bh+3d/4c> Trace; c017031e <ip_cmsg_recv+1186/cc0c> Trace; c0170399 <ip_cmsg_recv+1201/cc0c> Trace; c017fb35 <devinet_ioctl+1ce9/1f28> Trace; c015ccc7 <sock_recvmsg+2c3/3e8> Trace; c013258b <__pollwait+2c7/e68> Trace; c0132a76 <__pollwait+7b2/e68>
Once again, thanks for all the responses, and I'll forward the relevant emails to 3com.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |