Tests of 2.6.23-rc8 on SGI O2

Tests of 2.6.23-rc8 on SGI O2

[Giuseppe Sacco]

Hi all,
I compiled and tested the latest kernel (from git) for mips on an SGI
O2, in order to check if it fixes a few problems my current kernel has.

The first problem is that a PCI board with a PCI-to-PCI bridge is not
correctly managed. The second problem is the CONFIG_BUILD_ELF64 options
that made all new kernels since 2.6.20 unbootable.

Of course unsetting CONFIG_BUILD_ELF64 worked, and the new kernel booted
correctly.

About the first problem, once the machine booted, the lspci command stil
does not list the available devices on the board. The only listed device
is the PCI bridge.

The relevant parts in syslog are these lines

[...]
Sep 29 00:42:49 sgi kernel: SCSI subsystem initialized
Sep 29 00:42:49 sgi kernel: PCI: Bridge: 0000:00:03.0
Sep 29 00:42:49 sgi kernel:   IO window: disabled.
Sep 29 00:42:49 sgi kernel:   MEM window: disabled.
Sep 29 00:42:49 sgi kernel:   PREFETCH window: disabled.
Sep 29 00:42:49 sgi kernel: PCI: Setting latency timer of device 0000:00:03.0 to 64
Sep 29 00:42:49 sgi kernel: Time: MIPS clocksource has been installed.
Sep 29 00:42:49 sgi kernel: NET: Registered protocol family 2
[...]

Is this a normal behaviour? Should/can I "enable" these windows in any
way?

I also noticed two new problems in this kernel:
A. the connection via an e100 network board is *really* slow: an ssh
connection with public keys take about 40 seconds before the prompt
appear.
B. recompiling with 8mb of frame buffer give an unusable display and
fill my syslog of these messages:
[...]
Sep 27 08:59:18 sgi kernel: CRIME memory error at 0x1800ace0 ST 0x02010000<INV,GBE,NONFATAL>
Sep 27 08:59:18 sgi kernel: CRIME memory error at 0x1800c8e0 ST 0x02010000<INV,GBE,NONFATAL>
Sep 27 08:59:18 sgi kernel: CRIME memory error at 0x1800e4e0 ST 0x02010000<INV,GBE,NONFATAL>
[...]

Thanks a lot,
Giuseppe

Re: Tests of 2.6.23-rc8 on SGI O2

[Kaj-Michael Lang]

> B. recompiling with 8mb of frame buffer give an unusable display and
> fill my syslog of these messages:

This is nothing new, use 4mb.

-- 
Kaj-Michael Lang

Re: Tests of 2.6.23-rc8 on SGI O2

[Kaj-Michael Lang]

> B. recompiling with 8mb of frame buffer give an unusable display and
> fill my syslog of these messages:

This is nothing new, use 4mb.

-- 
Kaj-Michael Lang

Using PCI bridges on sgi-ip32 [was: Re: Tests of 2.6.23-rc8 on SGI O2]

[Giuseppe Sacco]

Il giorno ven, 28/09/2007 alle 11.57 +0200, Giuseppe Sacco ha scritto:
[...]
> About the first problem, once the machine booted, the lspci command stil
> does not list the available devices on the board. The only listed device
> is the PCI bridge.
> 
> The relevant parts in syslog are these lines
> 
> [...]
> Sep 29 00:42:49 sgi kernel: SCSI subsystem initialized
> Sep 29 00:42:49 sgi kernel: PCI: Bridge: 0000:00:03.0
> Sep 29 00:42:49 sgi kernel:   IO window: disabled.
> Sep 29 00:42:49 sgi kernel:   MEM window: disabled.
> Sep 29 00:42:49 sgi kernel:   PREFETCH window: disabled.
> Sep 29 00:42:49 sgi kernel: PCI: Setting latency timer of device 0000:00:03.0 to 64
> Sep 29 00:42:49 sgi kernel: Time: MIPS clocksource has been installed.
> Sep 29 00:42:49 sgi kernel: NET: Registered protocol family 2
> [...]

The same board on i386, is recognised this way:

Sep 29 10:15:44 casa kernel: PCI: Bridge: 0000:00:09.0
Sep 29 10:15:44 casa kernel:   IO window: d000-dfff
Sep 29 10:15:44 casa kernel:   MEM window: fb700000-fbcfffff
Sep 29 10:15:44 casa kernel:   PREFETCH window: disabled.
Sep 29 10:15:44 casa kernel: PCI: Setting latency timer of device 0000:00:01.0 to 6

And then, lspci, display all devices:

00:09.0 0604: 9710:9250 (rev 01)
00:09.0 PCI bridge: NetMos Technology Unknown device 9250 (rev 01)
01:08.0 0c03: 1033:0035 (rev 43)
01:08.0 USB Controller: NEC Corporation USB (rev 43)
01:08.1 0c03: 1033:0035 (rev 43)
01:08.1 USB Controller: NEC Corporation USB (rev 43)
01:08.2 0c03: 1033:00e0 (rev 04)
01:08.2 USB Controller: NEC Corporation USB 2.0 (rev 04)
01:09.0 0c00: 11c1:5811 (rev 61)
01:09.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 61)
01:0a.0 0200: 10ec:8169 (rev 10)
01:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10

So, should I debug the PCI controller for ip32 (MACE)? What could be the
problem here? Should I report this kind of problem to a different
mailing list?

Thanks,
Giuseppe

Re: Using PCI bridges on sgi-ip32 [was: Re: Tests of 2.6.23-rc8 on SGI O2]

[Maciej W. Rozycki]

On Sun, 30 Sep 2007, Giuseppe Sacco wrote:

> So, should I debug the PCI controller for ip32 (MACE)? What could be the
> problem here? Should I report this kind of problem to a different
> mailing list?

 I suggest you rebuild with CONFIG_PCI_DEBUG enabled and if you are unable 
to deduce the reason from the resulting verbose bootstrap log, then send 
it here so that others may have a look.

  Maciej

Re: Using PCI bridges on sgi-ip32: CONFIG_PCI_DEBUG

[Giuseppe Sacco]

Hi Maciej,

On Mon, 1 Oct 2007 16:05:11 +0100 (BST) "Maciej W. Rozycki" <macro@linux-mips.org> wrote:
[...]
>  I suggest you rebuild with CONFIG_PCI_DEBUG enabled and if you are unable 
> to deduce the reason from the resulting verbose bootstrap log, then send 
> it here so that others may have a look.

Thanks for this suggestion. Here is the relevant log:

[...]
MACE PCI rev 1
registering PCI controller with io_map_base unset
SCSI subsystem initialized
PCI: Scanning bus 0000:00
PCI: Found 0000:00:01.0 [9004/8078] 000100 00
PCI: Found 0000:00:02.0 [9004/8078] 000100 00
PCI: Found 0000:00:03.0 [9710/9250] 000604 01
PCI: Calling quirk ffffffff801da1e0 for 0000:00:03.0
PCI: Fixups for bus 0000:00
PCI: Scanning behind PCI bridge 0000:00:03.0, config ffffff, pass 0
PCI: Scanning behind PCI bridge 0000:00:03.0, config 000000, pass 1
PCI: Scanning bus 0000:01
PCI: Fixups for bus 0000:01
PCI: Bus scan for 0000:01 returning with max=01
PCI: Bus scan for 0000:00 returning with max=01
  got res [280000000:28000ffff] bus [80000000:8000ffff] flags 7200 for BAR 6 of 0000:00:01.0
  got res [280010000:28001ffff] bus [80010000:8001ffff] flags 7200 for BAR 6 of 0000:00:02.0
  got res [280020000:280020fff] bus [80020000:80020fff] flags 200 for BAR 1 of 0000:00:01.0
PCI: moved device 0000:00:01.0 resource 1 (200) to 80020000
  got res [280021000:280021fff] bus [80021000:80021fff] flags 200 for BAR 1 of 0000:00:02.0
PCI: moved device 0000:00:02.0 resource 1 (200) to 80021000
  got res [1000:10ff] bus [1000:10ff] flags 101 for BAR 0 of 0000:00:01.0
PCI: moved device 0000:00:01.0 resource 0 (101) to 1000
  got res [1400:14ff] bus [1400:14ff] flags 101 for BAR 0 of 0000:00:02.0
PCI: moved device 0000:00:02.0 resource 0 (101) to 1400
PCI: Bridge: 0000:00:03.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Enabling bus mastering for device 0000:00:03.0
PCI: Setting latency timer of device 0000:00:03.0 to 64
PCI: fixup irq: (0000:00:01.0) got 9
PCI: fixup irq: (0000:00:02.0) got 10
PCI: fixup irq: (0000:00:03.0) got 0
[...]
PCI: Calling quirk ffffffff801db928 for 0000:00:01.0
PCI: Calling quirk ffffffff80262f70 for 0000:00:01.0
PCI: Calling quirk ffffffff801db928 for 0000:00:02.0
PCI: Calling quirk ffffffff80262f70 for 0000:00:02.0
PCI: Calling quirk ffffffff801db928 for 0000:00:03.0
PCI: Calling quirk ffffffff80262f70 for 0000:00:03.0
[...]
PCI: Enabling device 0000:00:01.0 (0046 -> 0047)
[...]
PCI: Enabling device 0000:00:02.0 (0046 -> 0047)
[...]

Re: Using PCI bridges on sgi-ip32: CONFIG_PCI_DEBUG

[Maciej W. Rozycki]

On Tue, 2 Oct 2007, Giuseppe Sacco wrote:

> PCI: Fixups for bus 0000:00
> PCI: Scanning behind PCI bridge 0000:00:03.0, config ffffff, pass 0
> PCI: Scanning behind PCI bridge 0000:00:03.0, config 000000, pass 1
> PCI: Scanning bus 0000:01
> PCI: Fixups for bus 0000:01
> PCI: Bus scan for 0000:01 returning with max=01
> PCI: Bus scan for 0000:00 returning with max=01

 So it looks like the generic PCI code does scan behind the bridge at 
0000:00:03.0, but nothing is found.  So the first obvious question is: 
"Does your host bridge (or actually code that handles it) correctly 
generate type 1 PCI configuration cycles?"  It looks like 
arch/mips/pci/ops-mace.c is the place to look for possible breakage.

 Well, actually chkslot() there is the obvious answer.  It is probably 
easy to fix, but for somebody with documentation or at least the right 
piece of hardware, so I do not qualify, I am afraid.  Sorry.

 Failing anybody else, you may be able to figure it out yourself -- you 
probably need to stick bus->number into mace->pci.config_addr somewhere.  
Try bits 23:16 as the obvious first guess.

  Maciej