2.6.28 will not boot on 24K processor, ebase incorrectly modified in set_uncached_handler

2.6.28 will not boot on 24K processor, ebase incorrectly modified in set_uncached_handler

[David VomLehn (dvomlehn)]

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
have no idea why ebase needs to be modified at all, so I have no patch
to
offer. When I removed these two lines, my kernel booted to a shell
prompt.
--
David VomLehn, dvomlehn@cisco.com

2.6.28 will not boot on 24K processor, ebase incorrectly modified in set_uncached_handler

[David VomLehn (dvomlehn)]

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
have no idea why ebase needs to be modified at all, so I have no patch
to
offer. When I removed these two lines, my kernel booted to a shell
prompt.
--
David VomLehn, dvomlehn@cisco.com

Re: 2.6.28 will not boot on 24K processor, ebase incorrectly modified in set_uncached_handler

[Kevin D. Kissell]

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

          Regards,

          Kevin K.

RE: 2.6.28 will not boot on 24K processor, ebase incorrectly modified in set_uncached_handler

[David VomLehn (dvomlehn)]

> From: Kevin D. Kissell [mailto:kevink@paralogos.com] 
> Sent: Sunday, January 25, 2009 2:18 AM
> To: David VomLehn (dvomlehn)
> Cc: linux-mips@linux-mips.org; 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.

RE: 2.6.28 will not boot on 24K processor, ebase incorrectly modified in set_uncached_handler

[David VomLehn (dvomlehn)]

> From: Kevin D. Kissell [mailto:kevink@paralogos.com] 
> Sent: Sunday, January 25, 2009 2:18 AM
> To: David VomLehn (dvomlehn)
> Cc: linux-mips@linux-mips.org; 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.

Re: 2.6.28 will not boot on 24K processor, ebase incorrectly modified in set_uncached_handler

[Ihar Hrachyshka]

On Sun, Jan 25, 2009 at 11:50 PM, David VomLehn (dvomlehn)
<dvomlehn@cisco.com> wrote:
>> From: Kevin D. Kissell [mailto:kevink@paralogos.com]
>> Sent: Sunday, January 25, 2009 2:18 AM
>> To: David VomLehn (dvomlehn)
>> Cc: linux-mips@linux-mips.org; 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?

Re: 2.6.28 will not boot on 24K processor, ebase incorrectly modified in set_uncached_handler

[Ihar Hrachyshka]

On Sun, Jan 25, 2009 at 11:50 PM, David VomLehn (dvomlehn)
<dvomlehn@cisco.com> wrote:
>> From: Kevin D. Kissell [mailto:kevink@paralogos.com]
>> Sent: Sunday, January 25, 2009 2:18 AM
>> To: David VomLehn (dvomlehn)
>> Cc: linux-mips@linux-mips.org; 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?