On Sun, Jan 25, 2009 at 11:50 PM, David VomLehn (dvomlehn) <dvomlehn@xxxxxxxxx> wrote: >> From: Kevin D. Kissell [mailto:kevink@xxxxxxxxxxxxx] >> Sent: Sunday, January 25, 2009 2:18 AM >> To: David VomLehn (dvomlehn) >> Cc: linux-mips@xxxxxxxxxxxxxx; Dezhong Diao (dediao); Victor >> Williams Jr (williavi); Michael Sundius -X (msundius - Yoh >> Services LLC at Cisco) >> Subject: Re: 2.6.28 will not boot on 24K processor, ebase >> incorrectly modified in set_uncached_handler >> >> David VomLehn (dvomlehn) wrote: >> > The 2.6.28 kernel dies in memcpy when called from >> set_vi_srs_handler on >> > a >> > 24K processor. The problem is that ebase has an invalid value. The >> > original >> > value of ebase comes from a bootmem allocation, but the >> following code >> > in >> > set_uncached_handler takes a perfectly good kseg0 address >> and turns it >> > into >> > an invalid kseg1 address. >> > >> > if (cpu_has_mips_r2) >> > ebase += (read_c0_ebase() & 0x3ffff000); >> > >> > This code was added in commit >> 566f74f6b2f8b85d5b8d6caaf97e5672cecd3e3e. >> > >> I remember worrying about why it was "+=" and not "=" when others had >> problems with that patch. See the thread "NXP STB225 board >> support" from >> January 8 or so. When I asked about that, I got a comment >> that the add >> operation was correct, but that patch *should* have said >> "uncached_ebase >> += (read_c0_ebase() & 0x3ffff000);" I guess uncache_ebase is >> assumed to >> contain something interesting in some non-address bits. Try >> pre-pending >> "uncached_" to that "ebase"... > > Just adding uncached_ to the ebase doesn't appear to work. Looking at > the git > log makes it a bit unclear as to exactly who made this change, but it > would > be helpful to know what was intended. > > If the patch invoked broke lots of subarchs why should we have it in the first place? Can't we just revert it until we have a fix for this bug?
