Frank Wille | 5 Nov 2010 09:39
Picon

Re: prep machine kernel PGM trap by cpu_get_dfs()

On Fri, 05 Nov 2010 14:29:58 +0900 (JST)
KIYOHARA Takashi <kiyohara <at> kk.iij4u.or.jp> wrote:

> My prep machine(RS/6000 43P 7248-133) panics by kernel PGM trap.
> [...]
>   00000030 <cpu_get_dfs>:
>       30:       94 21 ff f0     stwu    r1,-16(r1)
>       34:       7d 7f 42 a6     mfpvr   r11
>       38:       7d 51 fa a6     mfspr   r10,1009
> 
> 
> hmm...
> I know such a function did not exist until last month.  Does 604
> support mfspr(SPR_HID1)?

Sorry, that's my fault! cpu_get_dfs() is called from cpu_probe_speed(),
and I was missing that it also happens for 604 CPUs.

Fixed. Please update cpu_subr.c.

--

-- 
Frank Wille

Mr. Frank Wong | 9 Nov 2010 15:17
Picon

Attention: Beneficiary,

Attention: Beneficiary,

I hereby inform you that Your suspended parcel of 250,000.00 pounds which
you have meet with all delivery requirement have been retrieved by world
Economic And Financial Crimes Commission Associated with Federal Bureau
Investigation.

We discovered that there are some unscrupulous Internet scammers trying to
temper with your suspend price demanding for huge money to bring the price
to you. And on the long run they will end up playing with you after
payment. I want to let you know that at the moment we have three of them in
our investigating custody for interrogation. You are require to contact
Mr.Larry Peterson via email address: larrypeterson20 <at> w.cn for more
information
to bring the retrieved suspend fund of 250,000.00 pounds sterling to you
with immediate effect.

Anticipate your prompt response.

Mr.Larry Peterson

Mr. Frank Wong | 9 Nov 2010 15:22
Picon

Attention: Beneficiary,

Attention: Beneficiary,

I hereby inform you that Your suspended parcel of 250,000.00 pounds which
you have meet with all delivery requirement have been retrieved by world
Economic And Financial Crimes Commission Associated with Federal Bureau
Investigation.

We discovered that there are some unscrupulous Internet scammers trying to
temper with your suspend price demanding for huge money to bring the price
to you. And on the long run they will end up playing with you after
payment. I want to let you know that at the moment we have three of them in
our investigating custody for interrogation. You are require to contact
Mr.Larry Peterson via email address: larrypeterson20 <at> w.cn for more
information
to bring the retrieved suspend fund of 250,000.00 pounds sterling to you
with immediate effect.

Anticipate your prompt response.

Mr.Larry Peterson

Caledonia Investments Plc | 9 Nov 2010 18:53
Picon

Christmas Loan Offer!

We are a seeking for financial assistance to promote/expand your business Or you
 need a personal loan all types of loan. apply now.

Mr. Frank Wong | 9 Nov 2010 15:32
Picon

Attention: Beneficiary,

Attention: Beneficiary,

I hereby inform you that Your suspended parcel of 250,000.00 pounds which
you have meet with all delivery requirement have been retrieved by world
Economic And Financial Crimes Commission Associated with Federal Bureau
Investigation.

We discovered that there are some unscrupulous Internet scammers trying to
temper with your suspend price demanding for huge money to bring the price
to you. And on the long run they will end up playing with you after
payment. I want to let you know that at the moment we have three of them in
our investigating custody for interrogation. You are require to contact
Mr.Larry Peterson via email address: larrypeterson20 <at> w.cn for more
information
to bring the retrieved suspend fund of 250,000.00 pounds sterling to you
with immediate effect.

Anticipate your prompt response.

Mr.Larry Peterson

Frank Wille | 1 Dec 2010 21:29
Picon

Re: pegasosII crash at boot with -current

matthew green wrote:

>   makeoptions    CPUFLAGS="-O2 -mcpu=7400"
>
> dunno what, but it breaks now.

I can reproduce it! I get exactly the same performance monitor trap with
NetBSD/macppc on my PowerBook G4 as you did with ofppc on a Pegasos2. I'm
crossposting to port-powerpc. Maybe somebody there has an idea.

Seems the crash happens while executing the first AltiVec instruction at
pool_cache_bootstrap() + 0xe0. It's a
    vxor    v0,v0,v0

The -mcpu=7400 flag lets gcc insert AltiVec code for the memset() in
pool_cache_bootstrap().

But our G4s should be able to execute AltiVec code (I have a 7447A) - maybe
something is not correctly set up at this early point in main()?

Do you still have your old working kernel, so you might disassemble
pool_cache_bootstrap() there and compare?

--

-- 
Frank Wille

Allen Briggs | 1 Dec 2010 21:35
Picon

Re: pegasosII crash at boot with -current

On Wed, Dec 01, 2010 at 09:29:03PM +0100, Frank Wille wrote:
> But our G4s should be able to execute AltiVec code (I have a 7447A) - maybe
> something is not correctly set up at this early point in main()?

Should the kernel be able to execute AltiVec code?  Or should it be
treated like the FPU?

-allen

--

-- 
Allen Briggs  -  briggs <at> ninthwonder.com

Michael | 1 Dec 2010 21:45
Picon

Re: pegasosII crash at boot with -current


Hello,

On Dec 1, 2010, at 3:35 PM, Allen Briggs wrote:

> On Wed, Dec 01, 2010 at 09:29:03PM +0100, Frank Wille wrote:
>> But our G4s should be able to execute AltiVec code (I have a 7447A)  
>> - maybe
>> something is not correctly set up at this early point in main()?
>
> Should the kernel be able to execute AltiVec code?  Or should it be
> treated like the FPU?

I dimly remember running into the same problem years ago when gcc3  
( or was it 4 ? ) started to emit altivec instructions if the CPU  
flags allowed it to. The solution was to build all kernels with -mno- 
altivec when using -mcpu=74xx.
IIRC the consensus back then was to treat altivec like the FPU and  
don't use it in the kernel.

have fun
Michael

Matt Thomas | 1 Dec 2010 22:17

Re: pegasosII crash at boot with -current


On Dec 1, 2010, at 12:45 PM, Michael wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
> On Dec 1, 2010, at 3:35 PM, Allen Briggs wrote:
> 
>> On Wed, Dec 01, 2010 at 09:29:03PM +0100, Frank Wille wrote:
>>> But our G4s should be able to execute AltiVec code (I have a 7447A) - maybe
>>> something is not correctly set up at this early point in main()?
>> 
>> Should the kernel be able to execute AltiVec code?  Or should it be
>> treated like the FPU?
> 
> I dimly remember running into the same problem years ago when gcc3 ( or was it 4 ? ) started to emit altivec
instructions if the CPU flags allowed it to. The solution was to build all kernels with -mno-altivec when
using -mcpu=74xx.
> IIRC the consensus back then was to treat altivec like the FPU and don't use it in the kernel.

You can use it, but only if treated carefully (save/restore explicitly, etc.)
Some of the pmap routines use altivec for copies.

Gmane