Description of problem:
From IT#50093:

I've reproduced this locally.  The crash is ultimately
due to an assumption in e100_free_tcb_pool() that the
pool is, indeed, allocated upon entry to the function.
 Or, it could be said that the calling function is at
fault for calling to free the pool when none is
allocated.  Either way, e100 tries to dereference a
NULL pointer, then Bad things happen.
[snip]
The ethtool implementation in this generation of
e100 has some problems dealing with failures.  The
e100_open() function can fail if one of its memory
allocations fails, and most ethtool commands that
change parameters will do a "down up" cycle to free
and reallocate the ethtool-modifiable parameters, in
this case, the tx ring.

I've generated a patch that eliminates the panic, and
adds some error returns for a few ethtool commands
(-G tx being one).  This is still not quite right,
though, as an "ethtool -g eth0" after such a failure
will claim that there are however many tx buffers
allocated as was requested in the previous (failing)
-G request.  The device also will not function,
even though it's nominally up and running.

This driver is outdated; the current driver from Intel is a complete
rewrite, so
I'm not sure how much effort we want to put into fixing this one.

The patch is for the RH 2.4.21-18.EL kernel.

(see the IT issue for a discussion of whether the current
Intel driver can be used to replace this older version.

Version-Release number of selected component (if applicable):
RH 2.4.21-18.EL

How reproducible:
Sometimes

Steps to Reproduce:
1.run "ethtool -G eth* tx 1024" on an e100 card
2.
3.
    

Actual Results:  Sometimes the kernel panics

Expected Results:  Should never panic

Additional info: