OLD REPLY … and Correcting . Suggesting of Corrections of LONG TERM embedded problems 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 “PROPER” 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… 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 erblichs@xxxxxxxxxxxxx > On Aug 31, 2010, at 12:26 PM, Jarek Poplawski <jarkao2@xxxxxxxxx> wrote: > > On Tue, Aug 31, 2010 at 08:58:10AM +0300, Plamen Petrov wrote: >> Rafael J. Wysocki ????????????: >> >>> This message has been generated automatically as a part of a summary report >>> of recent regressions. >>> >>> 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). >>> >>> >>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16626 >>> Subject : Machine hangs with EIP at skb_copy_and_csum_dev >>> Submitter : Plamen Petrov <pvp-lsts@xxxxxxxxxxxxxx> >>> Date : 2010-08-19 09:57 (11 days old) >>> Handled-By : Eric Dumazet <eric.dumazet@xxxxxxxxx> >>> >>> >> >> Should "generic receive offload" work on a forwarding setup? >> If yes - then the bug should remain open. >> If not - then it's my mistake. > > 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... ;-) > > Jarek P. > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html
