Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

						OLD REPLY =E2=80=A6 and =
Correcting . Suggesting of Corrections of LONG TERM embedded problems=20

Summary:

		Due to watermark awareness differences that is =
problematic in embedded systems, the GFP_ATOMIC which is not memory =
watermark aware is used in interrupt / atomic context.

		To properly monitor WATERMARK levels at suggested kernel =
locations, the =E2=80=9CPROPER=E2=80=9D GFP_FLAG SHOULD be GFP_NOWAIT. =
This is atomic/interupt friendly and is aware of memory watermarks, thus =
if memory is below the specified watermark level, it will then return a =
ENOMEM from that location.

					GFP_ATOMIC will not return =
ENOMEM and by the time the watermarks drop, ALL GFP_KERNEL callers are =
now SLEEPING.

					Please be embedded friendly with =
code patches=E2=80=A6

		FYI: Embedded system due to no 2ndary drive can not =
clean PTEs (page frames), thus callers need to be aware of low memory =
issues and be able to reduce their memory consumption based on receiving =
ENOMEMs. GFP_KERNEL callers will just sleep until memory is back above =
the watermarks.

Mitchell Erblich
[email protected]



> On Aug 31, 2010, at 12:26 PM, Jarek Poplawski <[email protected]> =
wrote:
>=20
> On Tue, Aug 31, 2010 at 08:58:10AM +0300, Plamen Petrov wrote:
>> Rafael J. Wysocki ????????????:
>>=20
>>> This message has been generated automatically as a part of a summary =
report
>>> of recent regressions.
>>>=20
>>> The following bug entry is on the current list of known regressions
>>> from 2.6.35.  Please verify if it still should be listed and let the =
tracking team
>>> know (either way).
>>>=20
>>>=20
>>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=3D16626
>>> Subject		: Machine hangs with EIP at =
skb_copy_and_csum_dev
>>> Submitter	: Plamen Petrov <[email protected]>
>>> Date		: 2010-08-19 09:57 (11 days old)
>>> Handled-By	:  Eric Dumazet <[email protected]>
>>>=20
>>>=20
>>=20
>> Should "generic receive offload" work on a forwarding setup?
>> If yes - then the bug should remain open.
>> If not - then it's my mistake.
>=20
> If/since it's on by default it should work and it definitely can't be
> your mistake. (Unless we can't find the real reason... ;-)
>=20
> Jarek P.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [email protected]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html