lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 23 Aug 2010 14:47:23 +0300
From:	Plamen Petrov <pvp-lsts@...uni-ruse.bg>
To:	Jarek Poplawski <jarkao2@...il.com>
CC:	Eric Dumazet <eric.dumazet@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	netdev@...r.kernel.org, bugzilla-daemon@...zilla.kernel.org,
	bugme-daemon@...zilla.kernel.org
Subject: Re: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev

На 21.8.2010 г. 11:07, Jarek Poplawski написа:
> On Sat, Aug 21, 2010 at 09:50:58AM +0200, Eric Dumazet wrote:
>> Le samedi 21 août 2010 à 09:47 +0200, Jarek Poplawski a écrit :
>>> On Fri, Aug 20, 2010 at 09:38:35PM +0200, Jarek Poplawski wrote:
>>>> Plamen Petrov wrote, On 20.08.2010 12:53:
>>>>> So, I guess its David and Herbert's turn?...
>>>>
>>>> If you're bored in the meantime I'd suggest to do check the realtek
>>>> driver eg:
>>>> - for locking with the patch below,
>>>> - to turn off with ethtool its tx-checksumming and/or scatter-gather,
>>>
>>> After rethinking, it's almost impossible this patch could change
>>> anything here, so don't bother, but consider mainly the second
>>> proposal.
>>>
>>> Jarek P.
>>
>> Indeed ;)
>>
>> Its true that not many nics use the skb_copy_and_csum_dev() helper,
>> maybe this one must be updated somehow ?
>>
> Yes, it seems it should be possible at least to handle the bug with
> a warning and error return, considering Plamen's problems with getting
> the trace.
>
> Jarek P.

Well, here is the current status:

Last I promised I will stay on 2.6.36-rc1-git for as long as possible,
so here is what I achieved:

>
root@fs:/boot# w; uname -a
>  12:08:18 up 3 days, 24 min,  1 user,  load average: 1.21, 1.29, 1.17
> USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
> root     pts/0    192.168.10.159   12:04    0.00s  0.02s  0.00s w
> Linux fs 2.6.36-rc1-FS-00127-g763008c #1 SMP Thu Aug 19 07:10:57 UTC 2010 i686 Intel(R) Pentium(R) D CPU 3.00GHz GenuineIntel GNU/Linux

Yeah, 3 days and counting, right until I decided to try the freshly
announced 2.6.36-rc2.

So I upgraded the kernel, but left the scripts that turn GRO off for
the tg3 card still run at system startup. This way the system ran for
2 and a half hours, when I decided its time to try turning GRO on.

I first tried to turn GRO on for the tg3 nic, and the system oopsed
immediately (if the panic screen is necessary - please, ask for it).

After the system came back, I tried turning GRO on for the 2 RealTek
8139 nics, too, but ethtool only accepted turning GRO off.

And unfortunately, I can't test if other nics will fail the same way
as the motherboard integrated tg3 I have does, so for now, this is
only a tg3 + GRO on problem; I don't have any other hardware to test
with available.

Thanks,
Plamen
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ