[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87haqcddks.fsf@lant.ki.iif.hu>
Date: Tue, 02 Oct 2012 18:49:07 +0200
From: Ferenc Wagner <wferi@...f.hu>
To: "Michael Chan" <mchan@...adcom.com>
Cc: netdev@...r.kernel.org, "Matt Carlson" <mcarlson@...adcom.com>,
"Grant Likely" <grant.likely@...retlab.ca>,
"Rob Herring" <rob.herring@...xeda.com>,
linux-kernel@...r.kernel.org, wferi@...f.hu
Subject: Re: tg3 driver upgrade (Linux 2.6.32 -> 3.2) breaks IBM Bladecenter SoL
"Michael Chan" <mchan@...adcom.com> writes:
> On Tue, 2012-10-02 at 14:07 +0200, Ferenc Wagner wrote:
>
>> I'm done with bisecting it: the first bad commit is:
>>
>> commit dabc5c670d3f86d15ee4f42ab38ec5bd2682487d
>> Author: Matt Carlson <mcarlson@...adcom.com>
>> Date: Thu May 19 12:12:52 2011 +0000
>>
>> tg3: Move TSO_CAPABLE assignment
>>
>> This patch moves the code that asserts the TSO_CAPABLE flag closer to
>> where the TSO capabilities flags are set. There isn't a good enough
>> reason for the code to be separated.
>>
>> Signed-off-by: Matt Carlson <mcarlson@...adcom.com>
>> Reviewed-by: Michael Chan <mchan@...adcom.com>
>> Signed-off-by: David S. Miller <davem@...emloft.net>
>
> Thanks, I'll look into this.
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.
>> On the other hand, losing the SoL console even temporarily during boot
>> (as it happens with a minimal kernel before this commit) isn't nice
>> either. I'll try to look after that, too, just mentioning it here...
>
> This is expected as the driver has to reset the link and you'll lose SoL
> for a few seconds until link comes back up. We can look into an
> enhancement to not touch the link if it is already in a good state when
> the driver comes up.
This looks more complicated here. In our production setup under 2.6.32
(stock Debian squeeze system) the SoL console is not broken during boot
at all. I don't say there are no dropouts at all, but the management
system does not detach the console, like it promptly did during the
bisection in every case. I could not reproduce this (preferred)
behavior with self-built kernels yet (not even with 2.6.18, which also
worked fine when built by Debian, if I remember correctly. I'll
continue investigating this issue.
--
Thanks,
Feri.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists