powerpc with gigabit card hanging

powerpc with gigabit card hanging

[David Gardiner]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

Hi,

Not sure that this really belongs here but since I've got an i386 - 
2.6.7 running with a e1000 fine I would assume, it's got something to do 
with the platform and I'm hoping someone has seen something similar. 
Anyway whenever I configure a gigabit ethernet card (bcm5700 or intel 
pro 1000) the system hangs and 100 base (e100) is fine.

What I've tried
bcm5700 - with bcm5700 versions 7.1.22 & 7.3.5 and the kernel module tg3
Intel pro 1000 - with the kernel modules

What I can do, insert the modules remove them, bring them down (ifconfig 
ethx down) although they aren't up.
What I can't do, bring them up (ifconfig ethx ....... up)

I've attached straces for bringing up an e100 and e1000, noting that 
after that is freezes/hangs while trying to configure the e1000, and the 
strace's for the bcm5700 looks exactly the same.

help,
dg

oh, kernel version 2.6.9-rc2 with these patches
http://www.ussg.iu.edu/hypermail/linux/kernel/0409.1/1192.html
http://ozlabs.org/pipermail/linuxppc-dev/2004-September/000068.html




[-- Attachment #2: strace.e100 --]
[-- Type: text/plain, Size: 2401 bytes --]

# strace ifconfig eth0 192.168.20.108 netmask 255.255.255.0 up

execve("/sbin/ifconfig", ["ifconfig", "eth0", "192.168.20.108", "netmask", "255.255.255.0", "up"], [/* 23 vars */]) = 0
uname({sys="Linux", node="arrgh", ...}) = 0
brk(0)                                  = 0x1001e000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30018000
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=13130, ...}) = 0
mmap(NULL, 13130, PROT_READ, MAP_PRIVATE, 3, 0) = 0x30019000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\1\312"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1256436, ...}) = 0
mmap(0xfeb5000, 1288532, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xfeb5000
mprotect(0, 117076, PROT_NONE)          = -1 ENOMEM (Cannot allocate memory)
mmap(0xffd5000, 102400, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x110000) = 0xffd5000
mmap(0xffee000, 6484, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffee000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3001d000
munmap(0x30019000, 13130)               = 0
uname({sys="Linux", node="arrgh", ...}) = 0
access("/proc/net", R_OK)               = 0
access("/proc/net/unix", R_OK)          = 0
socket(PF_UNIX, SOCK_DGRAM, 0)          = 3
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
access("/proc/net/if_inet6", R_OK)      = 0
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 5
access("/proc/net/ax25", R_OK)          = -1 ENOENT (No such file or directory)
access("/proc/net/nr", R_OK)            = -1 ENOENT (No such file or directory)
access("/proc/net/ipx", R_OK)           = -1 ENOENT (No such file or directory)
access("/proc/net/appletalk", R_OK)     = -1 ENOENT (No such file or directory)
access("/proc/net/x25", R_OK)           = -1 ENOENT (No such file or directory)
ioctl(4, 0x8916, 0x7ffff5d0)            = 0
ioctl(4, 0x8913, 0x7ffff4f0)            = 0
ioctl(4, 0x8914, 0x7ffff4f0)            = 0
ioctl(4, 0x891c, 0x7ffff5d0)            = 0
ioctl(4, 0x8913, 0x7ffff4f0)            = 0
ioctl(4, 0x8914, 0x7ffff4f0)            = 0
exit_group(0)                           = ?

[-- Attachment #3: strace.e1000 --]
[-- Type: text/plain, Size: 2196 bytes --]

# strace ifconfig eth2 192.168.22.108 netmask 255.255.255.0 up
execve("/sbin/ifconfig", ["ifconfig", "eth2", "192.168.22.108", "netmask", "255.255.255.0", "up"], [/* 23 vars */]) = 0
uname({sys="Linux", node="arrgh", ...}) = 0
brk(0)                                  = 0x1001e000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30018000
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=13130, ...}) = 0
mmap(NULL, 13130, PROT_READ, MAP_PRIVATE, 3, 0) = 0x30019000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\1\312"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1256436, ...}) = 0
mmap(0xfeb5000, 1288532, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xfeb5000
mprotect(0, 117076, PROT_NONE)          = -1 ENOMEM (Cannot allocate memory)
mmap(0xffd5000, 102400, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x110000) = 0xffd5000
mmap(0xffee000, 6484, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffee000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3001d000
munmap(0x30019000, 13130)               = 0
uname({sys="Linux", node="arrgh", ...}) = 0
access("/proc/net", R_OK)               = 0
access("/proc/net/unix", R_OK)          = 0
socket(PF_UNIX, SOCK_DGRAM, 0)          = 3
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
access("/proc/net/if_inet6", R_OK)      = 0
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 5
access("/proc/net/ax25", R_OK)          = -1 ENOENT (No such file or directory)
access("/proc/net/nr", R_OK)            = -1 ENOENT (No such file or directory)
access("/proc/net/ipx", R_OK)           = -1 ENOENT (No such file or directory)
access("/proc/net/appletalk", R_OK)     = -1 ENOENT (No such file or directory)
access("/proc/net/x25", R_OK)           = -1 ENOENT (No such file or directory)
ioctl(4, 0x8916, 0x7ffff5d0)            = 0
ioctl(4, 0x8913, 0x7ffff4f0)            = 0
ioctl(4, 0x8914

Re: powerpc with gigabit card hanging

[Segher Boessenkool]

> Not sure that this really belongs here but since I've got an i386 - 
> 2.6.7 running with a e1000 fine I would assume, it's got something to 
> do with the platform and I'm hoping someone has seen something 
> similar. Anyway whenever I configure a gigabit ethernet card (bcm5700 
> or intel pro 1000) the system hangs and 100 base (e100) is fine.

It's not the platform; I've run both e1000 and tg3 successfully
on PowerPC systems, no problems getting it to work at all.


Segher

Re: powerpc with gigabit card hanging

[David Gardiner]

> It's not the platform; I've run both e1000 and tg3 successfully
> on PowerPC systems, no problems getting it to work at all.
>
What kernel are you using? it's just that the irq's I'm getting for the 
gigabit devices are zero (dual gigabit ethernet card) for the 2.6.9-rc2 
plus patchs kernel but for the 2.4 series I was getting 12 and 9 as can 
be seen below and configuring the devices worked fine. I've also noticed 
that there have been recent changes made to the irq routing in the 
kernel so this may have something to do with it so I'll try one the 
i386's with gigabit with the 2.6.9-rc2 and see what I get!

dmesg from 2.6 series:
Broadcom Gigabit Ethernet Driver bcm5700 with Broadcom NIC Extension 
(NICE) ver. 7.3.5 (06/23/04)
eth2: Broadcom BCM5704 1000Base-SX found at mem f2ef0000, IRQ 0, node 
addr 0030f76e4eee
eth2: Broadcom BCM5704 Integrated SerDes transceiver found
eth2: Scatter-gather ON, 64-bit DMA ON, Tx Checksum ON, Rx Checksum ON, 
802.1Q VLAN ON, TSO ON
eth3: Broadcom BCM5704 1000Base-SX found at mem f2ed0000, IRQ 0, node 
addr 0030f76e4eef
eth3: Broadcom BCM5704 Integrated SerDes transceiver found
eth3: Scatter-gather ON, 64-bit DMA ON, Tx Checksum ON, Rx Checksum ON, 
802.1Q VLAN ON, TSO ON

dmesg from 2.4 series:
Broadcom Gigabit Ethernet Driver bcm5700 with Broadcom NIC Extension 
(NICE) ver. 7.1.22 (01/07/04)
eth2: Broadcom BCM5704 1000Base-T found at mem f2ef0000, IRQ 12, node 
addr 0030f74d479c
eth2: Broadcom BCM5704 Integrated Copper transceiver found
eth2: Scatter-gather ON, 64-bit DMA ON, Tx Checksum ON, Rx Checksum ON, 
802.1Q VLAN ON, NAPI ON
eth3: Broadcom BCM5704 1000Base-T found at mem f2ee0000, IRQ 9, node 
addr 0030f74d479d
eth3: Broadcom BCM5704 Integrated Copper transceiver found
eth3: Scatter-gather ON, 64-bit DMA ON, Tx Checksum ON, Rx Checksum ON, 
802.1Q VLAN ON, NAPI ON

Re: powerpc with gigabit card hanging

[Matt Porter]

[Followups to linuxppc-embedded, this is an embedded port question]

On Tue, Sep 28, 2004 at 01:41:28PM +1000, David Gardiner wrote:
> 
> > It's not the platform; I've run both e1000 and tg3 successfully
> > on PowerPC systems, no problems getting it to work at all.
> >
> What kernel are you using? it's just that the irq's I'm getting for the 
> gigabit devices are zero (dual gigabit ethernet card) for the 2.6.9-rc2 
> plus patchs kernel but for the 2.4 series I was getting 12 and 9 as can 
> be seen below and configuring the devices worked fine. I've also noticed 
> that there have been recent changes made to the irq routing in the 
> kernel so this may have something to do with it so I'll try one the 
> i386's with gigabit with the 2.6.9-rc2 and see what I get!

What "changes made to the irq routing" have you noticed? Hopefully
not the i386-specific ACPI ones...

irqs for PCI devices do not come from the driver, they are platform
specific.  If you are having problems with the interrupt reported
by xyz PCI driver then that is something wrong with your platform.
On pmac, interrupt routing is retrieved from OF. On prep, it's
retrieved from either residual data or in-kernel tables. If
embedded, then this is on the wrong list. Oops, looking at your
original message this appears to be the case (PowerPlus). Sounds
like the interrupt routing table for your board is wrong.

FWIW, e1000 works great here on my PowerPC platforms and 2.6.9-rc2

-Matt

Re: powerpc with gigabit card hanging

[Matt Porter]

On Tue, Sep 28, 2004 at 12:39:32AM -0500, Segher Boessenkool wrote:
> >> What kernel are you using?
> 
> 2.6.whatever, and I've used 2.4 in the past I believe.
> 
> >> it's just that the irq's I'm getting for the
> >> gigabit devices are zero (dual gigabit ethernet card) for the 
> >> 2.6.9-rc2
> >> plus patchs kernel but for the 2.4 series I was getting 12 and 9 as 
> >> can
> >> be seen below and configuring the devices worked fine.
> 
> PCI device IRQs are normally retrieved straight from the PCI device
> itself.  Sounds like a firmware problem (or the bootloader, if that
> sets up the PCI devices for you).

This assumes a world where everything is managed by magic BIOS/OF
initialization. That's not the case for this user's board port.
 
> > irqs for PCI devices do not come from the driver, they are platform
> > specific.  If you are having problems with the interrupt reported
> > by xyz PCI driver then that is something wrong with your platform.
> > On pmac, interrupt routing is retrieved from OF.
> 
> I believe Linux for PowerMac actually gets the IRQ number straight
> from the device.  Some other routing might be gotten out of the OF
> device-tree, yes.

The interrupt line register is always programmed by firmware, bios,
or an OS. It is a logical value that is dependent on the platform.

The only thing statically available on a PCI device is the interrupt
pin register value. That combined with the platform-specific routing
table is used to generate an arbitrary interrupt line value that
is programmed into the PCI interrupt line register.

-Matt

Re: powerpc with gigabit card hanging

[Segher Boessenkool]

>> PCI device IRQs are normally retrieved straight from the PCI device
>> itself.  Sounds like a firmware problem (or the bootloader, if that
>> sets up the PCI devices for you).
>
> This assumes a world where everything is managed by magic BIOS/OF
> initialization. That's not the case for this user's board port.

The OS (Linux, specifically) won't do it for you.  It has to be set up
beforehand.  Unless "embedded Linux" gets this the wrong way around
as well.

>> I believe Linux for PowerMac actually gets the IRQ number straight
>> from the device.  Some other routing might be gotten out of the OF
>> device-tree, yes.
>
> The interrupt line register is always programmed by firmware, bios,
> or an OS. It is a logical value that is dependent on the platform.

a) Don't pretend I don't know this; and b) it is wrong.  On the
majority of platforms, you can route any PCI IRQ to any number you want.
The firmware will tell you where it ends up (over PCI config space).

> The only thing statically available on a PCI device is the interrupt
> pin register value.

That only tells you whether the device has any IRQ at all.

> That combined with the platform-specific routing
> table is used to generate an arbitrary interrupt line value that
> is programmed into the PCI interrupt line register.

interrupt line == IRQ#?  That is set up _before_ Linux runs.


Segher

Re: powerpc with gigabit card hanging

[Matt Porter]

On Tue, Sep 28, 2004 at 12:58:57AM -0500, Segher Boessenkool wrote:
> >> PCI device IRQs are normally retrieved straight from the PCI device
> >> itself.  Sounds like a firmware problem (or the bootloader, if that
> >> sets up the PCI devices for you).
> >
> > This assumes a world where everything is managed by magic BIOS/OF
> > initialization. That's not the case for this user's board port.
> 
> The OS (Linux, specifically) won't do it for you.  It has to be set up
> beforehand.  Unless "embedded Linux" gets this the wrong way around
> as well.

This isn't an "embedded Linux" (whatever that is) thing. It is a
non-full-featured firmware thing.  If you take a look at MIPS, ARM,
SH, PPC embedded platforms you'll see a similar thing. But wait,
you'll even see interrupt routing tables in the decidedly not embedded
Alpha architecture. :) Linux does do it, and there is a very clear
infrastructure for managing routing tables and standard/non-standard
PCI swizzle mechanisms.
 
> >> I believe Linux for PowerMac actually gets the IRQ number straight
> >> from the device.  Some other routing might be gotten out of the OF
> >> device-tree, yes.
> >
> > The interrupt line register is always programmed by firmware, bios,
> > or an OS. It is a logical value that is dependent on the platform.
> 
> a) Don't pretend I don't know this; and b) it is wrong.  On the
> majority of platforms, you can route any PCI IRQ to any number you want.
> The firmware will tell you where it ends up (over PCI config space).

On commodity platforms that's true. But on just about every single
dedicated purpose platform (embedded systems), interrupt routing is
a static board layout/design decision.

> > The only thing statically available on a PCI device is the interrupt
> > pin register value.
> 
> That only tells you whether the device has any IRQ at all.

No, it also tells you which pin it is routed to (A-D). That's
an important piece of information when routing interrupts.

> > That combined with the platform-specific routing
> > table is used to generate an arbitrary interrupt line value that
> > is programmed into the PCI interrupt line register.
> 
> interrupt line == IRQ#?  That is set up _before_ Linux runs.

Again, on some platforms, not this one. Let's just agree that
not everything is a x86/BIOS or ppc64/pmac/OF machine that
has this done in some blackbox firmware.

-Matt

Re: powerpc with gigabit card hanging

[Segher Boessenkool]

>>> This assumes a world where everything is managed by magic BIOS/OF
>>> initialization. That's not the case for this user's board port.
>>
>> The OS (Linux, specifically) won't do it for you.  It has to be set up
>> beforehand.  Unless "embedded Linux" gets this the wrong way around
>> as well.
>
> This isn't an "embedded Linux" (whatever that is) thing.

That;s why I put quotes around it :-)

> It is a
> non-full-featured firmware thing.  If you take a look at MIPS, ARM,
> SH, PPC embedded platforms you'll see a similar thing. But wait,
> you'll even see interrupt routing tables in the decidedly not embedded
> Alpha architecture. :) Linux does do it, and there is a very clear
> infrastructure for managing routing tables and standard/non-standard
> PCI swizzle mechanisms.

Sure.  But the interrupt _assignment_ should be done by firmware.

>> and b) it is wrong.  On the
>> majority of platforms, you can route any PCI IRQ to any number you 
>> want.
>> The firmware will tell you where it ends up (over PCI config space).

> On commodity platforms that's true. But on just about every single
> dedicated purpose platform (embedded systems), interrupt routing is
> a static board layout/design decision.

And the firmware should still program the final interrupt number
into the PCI device's config space.

> No, it also tells you which pin it is routed to (A-D). That's
> an important piece of information when routing interrupts.

Sure.  The firmware is still *required* by the PCI spec to fill
the IRQ # config space field, though.

> Again, on some platforms, not this one. Let's just agree that
> not everything is a x86/BIOS or ppc64/pmac/OF machine that
> has this done in some blackbox firmware.

Oh, I believe that.  But the firmware should be fixed, not a
terrible hack added to Linux.


Segher

p.s.  And I know this isn't always practically possible; but why
then support a product like that at all, in the Open Source
community?

Re: powerpc with gigabit card hanging

[Matt Porter]

On Tue, Sep 28, 2004 at 01:23:53AM -0500, Segher Boessenkool wrote:
> > It is a
> > non-full-featured firmware thing.  If you take a look at MIPS, ARM,
> > SH, PPC embedded platforms you'll see a similar thing. But wait,
> > you'll even see interrupt routing tables in the decidedly not embedded
> > Alpha architecture. :) Linux does do it, and there is a very clear
> > infrastructure for managing routing tables and standard/non-standard
> > PCI swizzle mechanisms.
> 
> Sure.  But the interrupt _assignment_ should be done by firmware.

I can't argue with ideaology.
 
> > Again, on some platforms, not this one. Let's just agree that
> > not everything is a x86/BIOS or ppc64/pmac/OF machine that
> > has this done in some blackbox firmware.
> 
> Oh, I believe that.  But the firmware should be fixed, not a
> terrible hack added to Linux.
> 
> Segher
> 
> p.s.  And I know this isn't always practically possible; but why
> then support a product like that at all, in the Open Source
> community?

By this reasoning, we should also not support the many BIOS/OF
platforms that report incorrect data and have to have their
reported data fixed up by the kernel. That's gross too by the
same measure.

To answer your question, we support the products because other
than this one minor detail, the platforms generally have merits
that far outweigh the "horrors" of having a very concise interrupt
routing table in the kernel. The same reasoning is true in the case
of BIOS/OF bugs that are worked around. it's not practical to
fix that firmware, but we don't throw away those platforms in
defiance. Frankly, there wouldn't be much of anything in the
kernel (anything with a PCI quirk must go).

More importantly, the maintainers of the kernel, from Linus down
through each architecture have made this practice acceptable
policy for many many years.

-Matt

Re: powerpc with gigabit card hanging

[Segher Boessenkool]

>> Sure.  But the interrupt _assignment_ should be done by firmware.
>
> I can't argue with ideaology.

It's not ideology; it's what the PCI spec says.

>> p.s.  And I know this isn't always practically possible; but why
>> then support a product like that at all, in the Open Source
>> community?
>
> By this reasoning, we should also not support the many BIOS/OF
> platforms that report incorrect data and have to have their
> reported data fixed up by the kernel. That's gross too by the
> same measure.

There is a difference between patching some errors and doing
all the work yourself.

But hey, let not me stop you from doing this.

Re: powerpc with gigabit card hanging

[Matt Porter]

On Tue, Sep 28, 2004 at 01:45:27AM -0500, Segher Boessenkool wrote:
> >> Sure.  But the interrupt _assignment_ should be done by firmware.
> >
> > I can't argue with ideaology.
> 
> It's not ideology; it's what the PCI spec says.
> 
> >> p.s.  And I know this isn't always practically possible; but why
> >> then support a product like that at all, in the Open Source
> >> community?
> >
> > By this reasoning, we should also not support the many BIOS/OF
> > platforms that report incorrect data and have to have their
> > reported data fixed up by the kernel. That's gross too by the
> > same measure.
> 
> There is a difference between patching some errors and doing
> all the work yourself.

I see your point of view and disagree.

> But hey, let not me stop you from doing this.
 
Don't worry, you won't. :)

-Matt

Re: powerpc with gigabit card hanging

[Segher Boessenkool]

> I see your point of view and disagree.

Fine.

>> But hey, let not me stop you from doing this.
>
> Don't worry, you won't. :)

Good :-)


Segher

Re: powerpc with gigabit card hanging

[David Gardiner]

Matt Porter wrote:

Sorry about previously posting back to linuxppc-dev but this post, 
originally started on it :-\

>On Tue, Sep 28, 2004 at 12:58:57AM -0500, Segher Boessenkool wrote:
>  
>
>>>>PCI device IRQs are normally retrieved straight from the PCI device
>>>>itself.  Sounds like a firmware problem (or the bootloader, if that
>>>>sets up the PCI devices for you).
>>>>        
>>>>
>>>This assumes a world where everything is managed by magic BIOS/OF
>>>initialization. That's not the case for this user's board port.
>>>      
>>>
>>The OS (Linux, specifically) won't do it for you.  It has to be set up
>>beforehand.  Unless "embedded Linux" gets this the wrong way around
>>as well.
>>    
>>
>
>This isn't an "embedded Linux" (whatever that is) thing. It is a
>non-full-featured firmware thing.  If you take a look at MIPS, ARM,
>SH, PPC embedded platforms you'll see a similar thing. But wait,
>  
>
mvme5100 with ppcbug ( although I think all of the mvme's have ppcbug )

>you'll even see interrupt routing tables in the decidedly not embedded
>Alpha architecture. :) Linux does do it, and there is a very clear
>infrastructure for managing routing tables and standard/non-standard
>PCI swizzle mechanisms.
>  
>
> 
>  
>
>>>>I believe Linux for PowerMac actually gets the IRQ number straight
>>>>from the device.  Some other routing might be gotten out of the OF
>>>>device-tree, yes.
>>>>        
>>>>
>>>The interrupt line register is always programmed by firmware, bios,
>>>or an OS. It is a logical value that is dependent on the platform.
>>>      
>>>
>>a) Don't pretend I don't know this; and b) it is wrong.  On the
>>majority of platforms, you can route any PCI IRQ to any number you want.
>>The firmware will tell you where it ends up (over PCI config space).
>>    
>>
>
>On commodity platforms that's true. But on just about every single
>dedicated purpose platform (embedded systems), interrupt routing is
>a static board layout/design decision.
>
>  
>
The gigabit's are pmc's but ppcbug is still seeing them
i.e.
PPC6-Bug>ver
Debugger/Diagnostics Type/Revision..................=PPC6/2.2
Debugger/Diagnostics Revision Date..................=11/01/01 RM02
MicroProcessor Version/Revision.....................=800C/1104
MicroProcessor Internal Clock Speed (MHZ)...........=500
MicroProcessor External Clock Speed (MHZ)...........=100
PCI Bus Clock Speed (MHZ)...........................=33
Board Type Identifier...............................=MVME5110-2263
Board Assembly Number...............................=01-W3518F67D
Local Memory Size...................................=20000000 (512MB)
L2 Cache (External).................................=0KB
L2 Cache (P0-In-Line)...............................=2048KB
L2 Cache (P1-In-Line)...............................=0KB
Super I/O Device Offset/ID/Revision.................=UNKNOWN
PCI Function 00/00/0 (00000000) ID/Revision.........=48031057/03
PCI Function 00/0D/0 (00006800) ID/Revision.........=000010E3/02
PCI Function 00/0E/0 (00007000) ID/Revision.........=12098086/09
PCI Function 00/11/0 (00008800) ID/Revision.........=4D69105A/02
PCI Function 00/13/0 (00009800) ID/Revision.........=12098086/09
PCI Function 00/14/0 (0000A000) ID/Revision.........=00221011/04
PCI Function 01/02/0 (00011000) ID/Revision.........=44325354/04
PCI Function 01/03/0 (00011800) ID/Revision.........=16A814E4/02
PCI Function 01/03/1 (00011900) ID/Revision.........=16A814E4/02

and in linux

# lspci
00:00.0 Host bridge: Motorola Hawk (rev 03)
00:0d.0 Bridge: Tundra Semiconductor Corp. CA91C042 [Universe] (rev 02)
00:0e.0 Ethernet controller: Intel Corp. 82559ER (rev 09)
00:11.0 Unknown mass storage controller: Promise Technology, Inc. 20269 
(rev 02)
00:13.0 Ethernet controller: Intel Corp. 82559ER (rev 09)
00:14.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 04)
01:02.0 Sharc Processors: Sonartech Atlas SharcPmcII (rev 04)
01:03.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704S 
Gigabit Ethernet (rev 02)
01:03.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704S 
Gigabit Ethernet (rev 02)

>>>The only thing statically available on a PCI device is the interrupt
>>>pin register value.
>>>      
>>>
>>That only tells you whether the device has any IRQ at all.
>>    
>>
>
>No, it also tells you which pin it is routed to (A-D). That's
>an important piece of information when routing interrupts.
>
>  
>
My "challenge" seems to be that from the 2.4 series kernel to the 
2.6.9-rc2 (I haven't tried any others) the interrupt routing has changed
i.e. for a 2.4 series I get from lspci -v:
01:03.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704S 
Gigabit Ethernet (rev 02)
        Subsystem: Broadcom Corporation NetXtreme BCM5704S Gigabit Ethernet
        Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 9
        Memory at f2ed0000 (64-bit, non-prefetchable) [size=64K]
        Memory at f2ec0000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: [40] #07 [0000]
        Capabilities: [48] Power Management version 2
        Capabilities: [50] Vital Product Data
        Capabilities: [58] Message Signalled Interrupts: 64bit+ 
Queue=0/3 Enable-

and from 2.6.9-rc2:
01:03.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704S 
Gigabit Ethernet (rev 02)
        Subsystem: Broadcom Corporation NetXtreme BCM5704S Gigabit Ethernet
        Flags: bus master, 66Mhz, medium devsel, latency 128
        Memory at f2ed0000 (64-bit, non-prefetchable) [size=64K]
        Memory at f2ec0000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: [40] #07 [0002]
        Capabilities: [48] Power Management version 2
        Capabilities: [50] Vital Product Data
        Capabilities: [58] Message Signalled Interrupts: 64bit+ 
Queue=0/3 Enable-

so where do I look ??? I'm thinking it's in the mvme5100 platform setup, 
am I assuming right?

>>>That combined with the platform-specific routing
>>>table is used to generate an arbitrary interrupt line value that
>>>is programmed into the PCI interrupt line register.
>>>      
>>>
>>interrupt line == IRQ#?  That is set up _before_ Linux runs.
>>    
>>
>
>Again, on some platforms, not this one. Let's just agree that
>not everything is a x86/BIOS or ppc64/pmac/OF machine that
>has this done in some blackbox firmware.
>
>-Matt
>  
>

Re: powerpc with gigabit card hanging

[Matt Porter]

On Tue, Sep 28, 2004 at 04:46:52PM +1000, David Gardiner wrote:
> so where do I look ??? I'm thinking it's in the mvme5100 platform setup, 
> am I assuming right?
 
Yes, mvme5100_map_irq() is what you want. Comparing 2_4_devel to 2.6,
only the PMCSPAN IDSEL routing is missing. Don't know what your 2.4
kernel looks like or your current map in your 2.6 port.

-Matt

Re: powerpc with gigabit card hanging

[David Gardiner]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]


>only the PMCSPAN IDSEL routing is missing. Don't know what your 2.4
>  
>
linuxppc_2_4_devel

>kernel looks like or your current map in your 2.6 port.
>  
>
Thanks Matt, that was pretty easy once I knew where to look, being that 
the gigabit was on the span card and they were all set to zero and in 
the linuxppc_2_4_devel tree they weren't, anyway the patch is attatched. 
I don't want anything to be done with this patch as I still would like 
to "try" and fold the mvme5100 into pplus and I'm only attatching it in 
case I get hit by a bus.

dodah,
dlg
 

[-- Attachment #2: irq.patch --]
[-- Type: text/plain, Size: 586 bytes --]

--- play-2.6.9.patched.changed.compile/arch/ppc/platforms/mvme5100.c.orig	2004-09-29 08:25:47.549383101 +1000
+++ play-2.6.9.patched.changed.compile/arch/ppc/platforms/mvme5100.c	2004-09-29 08:25:54.199430187 +1000
@@ -81,7 +81,7 @@ mvme5100_map_irq(struct pci_dev *dev, un
 		{ 28, 25, 26, 27 },	/* IDSEL 17 - PMC Slot 2 */
 		{  0,  0,  0,  0 },	/* IDSEL 18 - unused */
 		{ 29,  0,  0,  0 },	/* IDSEL 19 - Enet 2 */
-		{  0,  0,  0,  0 },	/* IDSEL 20 - PMCSPAN */
+		{ 25, 26, 27, 28 }, /* IDSEL 20 - PMCSPAN */
 	};
 
 	const long min_idsel = 11, max_idsel = 20, irqs_per_slot = 4;