.. | .. |
---|
270 | 270 | } |
---|
271 | 271 | early_param("gart_fix_e820", parse_gart_mem); |
---|
272 | 272 | |
---|
| 273 | +/* |
---|
| 274 | + * With kexec/kdump, if the first kernel doesn't shut down the GART and the |
---|
| 275 | + * second kernel allocates a different GART region, there might be two |
---|
| 276 | + * overlapping GART regions present: |
---|
| 277 | + * |
---|
| 278 | + * - the first still used by the GART initialized in the first kernel. |
---|
| 279 | + * - (sub-)set of it used as normal RAM by the second kernel. |
---|
| 280 | + * |
---|
| 281 | + * which leads to memory corruptions and a kernel panic eventually. |
---|
| 282 | + * |
---|
| 283 | + * This can also happen if the BIOS has forgotten to mark the GART region |
---|
| 284 | + * as reserved. |
---|
| 285 | + * |
---|
| 286 | + * Try to update the e820 map to mark that new region as reserved. |
---|
| 287 | + */ |
---|
273 | 288 | void __init early_gart_iommu_check(void) |
---|
274 | 289 | { |
---|
275 | | - /* |
---|
276 | | - * in case it is enabled before, esp for kexec/kdump, |
---|
277 | | - * previous kernel already enable that. memset called |
---|
278 | | - * by allocate_aperture/__alloc_bootmem_nopanic cause restart. |
---|
279 | | - * or second kernel have different position for GART hole. and new |
---|
280 | | - * kernel could use hole as RAM that is still used by GART set by |
---|
281 | | - * first kernel |
---|
282 | | - * or BIOS forget to put that in reserved. |
---|
283 | | - * try to update e820 to make that region as reserved. |
---|
284 | | - */ |
---|
285 | 290 | u32 agp_aper_order = 0; |
---|
286 | 291 | int i, fix, slot, valid_agp = 0; |
---|
287 | 292 | u32 ctl; |
---|