Hi everyone,
I've been running into a problem while installing Debian Wheezy on a bunch
of 6-year old machines which have been running Squeeze happily for years.
They are SuperMicro-based (H8SSL opteron board), with two BCM95704A6 (Tigon3)
interfaces, and a BMC/IPMI card (SuperMicro 1U) which shares eth0.
With a 2.6.32 kernel (and the 3.102 version of the tg3 driver) everything is fine.
With Debian's 3.2 (and tg3 3.121) I lose access to the IPMI LAN (or LANplus)
interface as soon as the tg3 module has been loaded. Even shutting down doesn't
give the interface back - I've got to pull the power plug.
Trying to git bisect the corresponding changes to the tg3 driver, I'm running
against a wall at the point where the source code has been moved to another
subtree back in 2011 (still a long time past Squeeze). I appear to be unable
to go back beyond that.
Can you advise how to find out when IPMI access got lost, and how to re-enable
it? Any suggestion is appreciated.
I suppose it wouldn't be as easy as "get the old source from 2.6.32, and plug
it into drivers/net/ethernet/broadcom, then rebuild the kernel" -?
Please keep me on CC, thanks.
Regards,
Steffen
2012/11/7 Steffen Grunewald <[email protected]>:
> Hi everyone,
>
> I've been running into a problem while installing Debian Wheezy on a bunch
> of 6-year old machines which have been running Squeeze happily for years.
>
> They are SuperMicro-based (H8SSL opteron board), with two BCM95704A6 (Tigon3)
> interfaces, and a BMC/IPMI card (SuperMicro 1U) which shares eth0.
>
> With a 2.6.32 kernel (and the 3.102 version of the tg3 driver) everything is fine.
>
> With Debian's 3.2 (and tg3 3.121) I lose access to the IPMI LAN (or LANplus)
> interface as soon as the tg3 module has been loaded. Even shutting down doesn't
> give the interface back - I've got to pull the power plug.
>
> Trying to git bisect the corresponding changes to the tg3 driver, I'm running
> against a wall at the point where the source code has been moved to another
> subtree back in 2011 (still a long time past Squeeze). I appear to be unable
> to go back beyond that.
>
> Can you advise how to find out when IPMI access got lost, and how to re-enable
> it? Any suggestion is appreciated.
> I suppose it wouldn't be as easy as "get the old source from 2.6.32, and plug
> it into drivers/net/ethernet/broadcom, then rebuild the kernel" -?
>
> Please keep me on CC, thanks.
>
> Regards,
> Steffen
> --
Ferenc met samilar problem :
"Michael Chan" <[email protected]> writes:
> On Tue, 2012-10-02 at 18:49 +0200, Ferenc Wagner wrote:
>
>> Going into the opposite direction: I found that Linux 3.6 does not
>> permanently break the SoL console on upping eth0! I'll try to find
>> the commit which (sort of) fixed it.
>
> These are the likely fixes:
>
> commit cf9ecf4b631f649a964fa611f1a5e8874f2a76db
> Author: Matt Carlson <[email protected]>
> Date: Mon Nov 28 09:41:03 2011 +0000
>
> tg3: Fix TSO CAP for 5704 devs w / ASF enabled
You are exactly right: cf9ecf4b fixed the premanent SoL breakage
introduced by dabc5c67. Looks like ASF utilizes similar technology to
that of the HS20 BMC. Thanks for the tip, it greatly reduced our CPU
wear. :) It's a pity ethtool -k did not give a hint. Do you think it's
possible to work around in 3.2 by eg. fiddling some ethtool setting?
the fix already go into Precise update to 3.2.31 stable release
So update your kernel should fix your problem.
Jack
On Wed, Nov 07, 2012 at 05:40:19PM +0800, 王金浦 wrote:
> Ferenc met samilar problem :
>
> "Michael Chan" <[email protected]> writes:
>
> > On Tue, 2012-10-02 at 18:49 +0200, Ferenc Wagner wrote:
> >
> >> Going into the opposite direction: I found that Linux 3.6 does not
> >> permanently break the SoL console on upping eth0! I'll try to find
> >> the commit which (sort of) fixed it.
> >
> > These are the likely fixes:
> >
> > commit cf9ecf4b631f649a964fa611f1a5e8874f2a76db
> > Author: Matt Carlson <[email protected]>
> > Date: Mon Nov 28 09:41:03 2011 +0000
> >
> > tg3: Fix TSO CAP for 5704 devs w / ASF enabled
>
> You are exactly right: cf9ecf4b fixed the premanent SoL breakage
> introduced by dabc5c67. Looks like ASF utilizes similar technology to
> that of the HS20 BMC. Thanks for the tip, it greatly reduced our CPU
> wear. :) It's a pity ethtool -k did not give a hint. Do you think it's
> possible to work around in 3.2 by eg. fiddling some ethtool setting?
>
> the fix already go into Precise update to 3.2.31 stable release
>
> So update your kernel should fix your problem.
Indeed, only a few days ago, 3.2.32 migrated into Wheezy - which cures
the problem.
Issue resolved (for now).
Thanks a lot to everyone,
S
--
Steffen Grunewald * MPI Grav.Phys.(AEI) * Am Mühlenberg 1, D-14476 Potsdam
Cluster Admin * --------------------------------- * http://www.aei.mpg.de/
* e-mail: steffen.grunewald(*)aei.mpg.de * +49-331-567-{fon:7274,fax:7298}