As luck would have it, it's not just an obscure Geode system which has a broken E820 implementation. Today I received a bug report about a Dell system (XPS M1330) with broken E820. Unfortunately, the workaround for the Geode breaks this system, because x86-64 doesn't fall back to the e801/88 information like the i386 kernel does. I wonder if the relevant people could test out this patch to see how it works on their respective system. This patch reverts to 2.6.23-rc8 behaviour of simply truncating the map, but still makes e801/88 info available to the kernel; this hopefully should match 2.6.22 behaviour. I want to emphasize that this is seriously broken. Using a partial e820 map could have disastrous results, since the kernel will have partial memory map information and not know about reserved areas, etc. Part of me feels that the right thing to do is what the current git kernel does -- either fall back to e801, or stop and error. (Andi: I would particularly appreciate your opinion on this issue.) -hpa
| Andrew Morton | 2.6.23-rc3-mm1 |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Yinghai Lu | Re: [PATCH RFC] x86: check for and defend against BIOS memory corruption |
| Frederik Deweerdt | [-mm patch] remove tcp header from tcp_v4_check (take #2) |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Herbert Xu | Re: [PATCH 2/3][NET_BATCH] net core use batching |
git: | |
