Re: [Fwd: problem involving wait_on_bh]

Jason Bratton (jbratton@usa.net)
Sun, 19 Dec 1999 14:08:19 -0600


> 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/