This bug has been copied from bug #557380 and has been proposed to be backported to 4.8 z-stream (EUS).
A patch addressing this issue has been included in kernel-2.6.9-89.32.1.
In https://bugzilla.redhat.com/show_bug.cgi?id=557380#c19, (In reply to comment #3) > Vitaly, > What I think we can do is reserve host dell-pe650-02.rhts.bos.redhat.com. run > the /distribution/networking/ndnc test, This will configure netdump to dump > across the network. Than manually initiate a Alt+SysRq+C to crash the system. On dell-pe650-02.rhts.eng.bos.redhat.com, it's not easy to trigger this problem. It can pass through with following messages: ... CPU#0 is executing netdump. < netdump activated - performing handshake with the server. > NETDUMP START! < handshake completed - listening for dump requests. > 2(20000)|000)/ Pid: 4584, comm: bash EIP: 0060:[<c0242c8b>] CPU: 0 .... Instead of: ... CPU#0 is executing netdump. < netdump activated - performing handshake with the server. > <0>Kernel panic - not syncing: drivers/net/3c59x.c:2265: spin_lock(drivers/net/3c59x.c:dfe2b1f4) already locked by drivers/net/3c59x.c/2419 ------------[ cut here ]------------ <1>kernel BUG at kernel/panic.c:77! <1>invalid operand: 0000 [#2] ... Should I inject more net console pressure ? Any advices? Thanks Igor
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2010-0936.html