[panic] "Cheetah error trap taken" with Debian 2.6.24 kernel

[panic] "Cheetah error trap taken" with Debian 2.6.24 kernel

[Frans Pop]

Hi sparclinux devs (AKA David),

We got a report on the Debian Sparc list of an installation issue 
involving a kernel panic. The thread so far is here:
- http://lists.debian.org/debian-sparc/2008/05/msg00020.html
- http://lists.debian.org/debian-sparc/2008/06/msg00000.html
  (month split; both have follow-ups)

Alexander Vlasov wrote:
> Frans Pop <elendil <at> planet.nl> writes:
>> You could also try booting with BOOT_DEBUG=3. That will give you a
>> debug shell at the earliest possible point. If the crash still happens,
>> it's definitely a kernel or hardware issue.
> 
> Haven't tried BOOT_DEBUG=3, but finally screenshoted the problem via KVM
> Here is it: http://zulu.in.ua/screenshot.png

OK, that seems pretty clear. This is still with the daily installer image, 
correct?

Let's ask the kernel developers for advice as this panic comes from there 
(arch/sparc64/kernel/traps.c).

First lines of the trap (see screenshot linked above for rest!):

Cheetah error trap taken afsr[0010080005000000] afar [000007f900800000]
TPC[553f94] TNPC[553f98] O7[554274] TSTATE[9980001606]
TPC<pci_get_rom_size+0x18/0xc4>

The kernel is either Debian kernel based on 2.6.24.4 (if the installer 
image is an older daily build) or 2.6.24.7 (if it is a current daily).
Exact version can be checked if needed.

I've added the original reporter in CC for easier follow-up.

Cheers,
FJP

Re: [panic] "Cheetah error trap taken" with Debian 2.6.24 kernel

[David Miller]

From: Frans Pop <elendil@planet.nl>
Date: Tue, 10 Jun 2008 00:03:53 +0200

> Cheetah error trap taken afsr[0010080005000000] afar [000007f900800000]
> TPC[553f94] TNPC[553f98] O7[554274] TSTATE[9980001606]
> TPC<pci_get_rom_size+0x18/0xc4>

pci_get_rom_size() is being called with an I/O address that
isn't responding.  It is being called via pci_map_rom() because
I see no drivers directly calling pci_get_rom_size().

Find out what device driver is calling this routine.

Re: [panic] "Cheetah error trap taken" with Debian 2.6.24 kernel

[Frans Pop]

On Tuesday 10 June 2008, David Miller wrote:
> From: Frans Pop <elendil@planet.nl>
> Date: Tue, 10 Jun 2008 00:03:53 +0200
>
> > Cheetah error trap taken afsr[0010080005000000] afar
> > [000007f900800000] TPC[553f94] TNPC[553f98] O7[554274]
> > TSTATE[9980001606]
> > TPC<pci_get_rom_size+0x18/0xc4>
>
> pci_get_rom_size() is being called with an I/O address that
> isn't responding.  It is being called via pci_map_rom() because
> I see no drivers directly calling pci_get_rom_size().
>
> Find out what device driver is calling this routine.

Given that the screenshot shows that the line just before the crash 
is "radeonfb (0001:02:00.0): ATI Radeon [d" which looks truncated the 
most likely candidate looks to be drivers/video/aty/radeon_base.c (in 
__devinit radeon_map_ROM).
That function even has some suspicious looking comments immediately above 
the call.

Finding out for sure would probably require building a custom installer 
using a kernel with some added debugging statements. Is that needed?

Cheers,
FJP

Re: [panic] "Cheetah error trap taken" with Debian 2.6.24 kernel

[David Miller]

From: Frans Pop <elendil@planet.nl>
Date: Tue, 10 Jun 2008 01:03:48 +0200

> Given that the screenshot shows that the line just before the crash 
> is "radeonfb (0001:02:00.0): ATI Radeon [d" which looks truncated the 
> most likely candidate looks to be drivers/video/aty/radeon_base.c (in 
> __devinit radeon_map_ROM).
> That function even has some suspicious looking comments immediately above 
> the call.
> 
> Finding out for sure would probably require building a custom installer 
> using a kernel with some added debugging statements. Is that needed?

Since the pci_map_rom() call done by the Radeon driver will be done
long before it registers itself as a console framebuffer device, we
would not see the penguin on the screen and the framebuffer console
output if it's invocation of pci_map_rom() were the cause.

Re: [panic] "Cheetah error trap taken" with Debian 2.6.24 kernel

[David Miller]

From: "Alexander Vlasov" <alexander.vlasov@gmail.com>
Date: Tue, 10 Jun 2008 14:02:50 +0200

> I have to confirm that problem is somehow related to radeonfb.
> This problem happens only with TWO Sun XVR-300 videocards installed; when
> I'm pulling one card out, kernel boots fine.

Now that's a good clue.

I wonder if the firmware mis-sizes one of the ROM resource
properties in cases like this.

Re: [panic] "Cheetah error trap taken" with Debian 2.6.24 kernel

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Tue, 10 Jun 2008 11:59:01 -0700 (PDT)

> From: "Alexander Vlasov" <alexander.vlasov@gmail.com>
> Date: Tue, 10 Jun 2008 14:02:50 +0200
> 
> > I have to confirm that problem is somehow related to radeonfb.
> > This problem happens only with TWO Sun XVR-300 videocards installed; when
> > I'm pulling one card out, kernel boots fine.
> 
> Now that's a good clue.
> 
> I wonder if the firmware mis-sizes one of the ROM resource
> properties in cases like this.

As an aside, I have one of these XVR-300 cards in my Ultra45
and I'm planing to fix up several other problems I've
seen.

For example, with acceleration enabled, the card locks up
shortly after starting to bootup with current kernels.
After talking with the radeon fb driver maintainers, the
thinking is that the card initialization code in the kernel
fb driver is simply out of date and needs to be made more
in sync with what the XORG driver uses.

That's a lot of work, so don't expect any progress in this
area for several weeks.

So, for now, put only one card into the machine and disable
console output acceleration on the kernel command line.