> 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.
