Re: [cobalt-developers] PCI issues with RAQ3

[Dennis <dennis@xxxxxxxxx>]

right now my machine is all messed up and I cant restore it until I get
another machine in here (should be here Monday). I want to try it on a
fresh box as well. 

The ethernet is locking up in the self-test code...write after reporting
PHY#0. 

I do have a suggestion..when you put out a new kernel rpm DONT have it
delete the old kernel files....just load it into /usr/src/linux-version and
reset the /usr/src/linux link. I was surprised (and horrified) when the rpm
tried to delete the previous tree. One of the good things about linux is
that you can keep multiple kernels on the machine and just pop them in and
out.

Either that or use the method that kernels.org uses and just tarball up
/usr/src/linux-version. 

Dennis

At 03:27 PM 2/18/00 -0800, you wrote:
>Dennis wrote:
> 
>> 1) With our card in the box, the eepro100 driver locks the system on probe
>> using the C5 kernel or the C3 kernel (the original kernel in the box). With
>> the rom kernel it doesnt.
>
>Very odd, as they are essentially the same kernel.  Can you send me:
>1) the kernel boot messages (serial port, from ROM to prompt) when you
>boot normal
>2) the same, but when you boot from ROM
>
>> 2) with the ROM kernel an ioremap of our board's base[0] address returns a
>> NULL when loading the module. The address (e800) that we are trying to map
>> appears valid.
>
>is 0xe800 an IO region or a memory-mapped IO region?  Is it hardwired,
>or does PCI bios initialize it?
> 
>> I've noticed that board modules (include eepro100.o)  compiled on PCs dont
>> load on cobalt machines without recompiling them so obviously there is
>> something different. I'm going to have to hack the eepro100 driver to see
>> why it hangs, but if you can fill me in on the bus issues it might help.
>
>I'm not sure what you mean here - There isn't anything different - you
>can diff the kernels and see that.  In fact,I compile my test kernels on
>a PC, and load them onto a Raq3.  I've not tried doing eepro100.o, but
>please tell me what you mean by "dont load" - error message? system
>lock?  details... ;)
> 
>> Our cards are installed in hundreds of linux systems worldwide and there
>> hasnt been one MB that they havent worked with. The hang occurs with no
>> driver for the board present, so nothing *should* be accessing the card.
>
>If there is a conflict with the eepro100 driver, we can find it.  I'm
>curious as to why our PCI would be different on this card than any
>other.  Have you tried setting the IO range to a different area?  
>
>Lastly, There was a conflict that dealt with the Ethernet controller
>being in MMIO mode, but we now turn off MMIO mode in BIOS.  Besides
>that, it was affecting disk only.
>
>Really to help I need more details, error messages if any exist, perhaps
>the contents of /proc/pci, and the results of 
>
>"for a in /proc/bus/pci/00/*; do echo $a; hexdump $a; done"
>
>-- 
>Tim Hockin
>Software Engineer / OS Engineer
>Cobalt Networks
>thockin@xxxxxxxxxx
>
>_______________________________________________
>cobalt-developers mailing list
>cobalt-developers@xxxxxxxxxxxxxxx
>http://list.cobalt.com/mailman/listinfo/cobalt-developers
>