Re: New thread -> X1 fun stuff
Hi Adam,
Sorry for the delay getting to look at these but can you try the
included patch.
Richard
Adam McKenna writes:
> On Thu, Aug 30, 2001 at 12:30:03AM +0100, Richard Mortimer wrote:
> > That looks similar to the errors that I first got when the csr0 values
> > were set wrongly. I wonder if a chip register is not getting setup
> > correctly in certain circumstances. The main thing that I did with
> > this was to have a look at the chip registers and looked at what was
> > different between working and non-working versions.
> >
> > Can you get the following information from situations where the system
> > is working and not-working. You need to drop into OBP and then use
> > these commands to dump the hardware registers for the device that is
> > not working (I think that it was eth1 in your case).
> >
> > eth1
> >
> > 1fe.02010000 100 piodump
> > 1fe.01006000 100 piodump
> >
> > eth0
> >
> > 1fe.02010100 100 piodump
> > 1fe.01002800 100 piodump
> Not working:
>
> ok 1fe.02010000 100 piodump
> 1fe \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef
> 2010000 00 50 00 fe ff ff ff ff ff ff ff ff ff ff ff ff .P.~............
CSR0 = 0xfe005000
> 2010010 ff ff ff ff ff ff ff ff 70 00 00 7f ff ff ff ff ........p.......
CSR3 = 0x7f000070
> 2010020 a0 80 00 7f ff ff ff ff 00 a8 12 fd ff ff ff ff ........(.}....
CSR4 = 0x7f0080a0
> 2010030 07 20 00 00 ff ff ff ff ef eb ff ff ff ff ff ff . ......ok......
These look massively different to a properly initialised one. Infact
they look very similar to my registers if I do a watch-net from OBP.
>
> working:
>
> ok 1fe.02010000 100 piodump
> 1fe \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef
> 2010000 00 90 80 fe ff ff ff ff ff ff ff ff ff ff ff ff ...~............
CSR0 = 0xfe809000
> 2010010 ff ff ff ff ff ff ff ff f0 80 ff 63 ff ff ff ff ........p..c....
CSR3 = 0x63ff80f0
> 2010020 10 82 ff 63 ff ff ff ff 40 00 75 fc ff ff ff ff ...c....@.u|....
CSR4 = 0x63ff8210
> 2010030 02 20 0e 02 ff ff ff ff ef eb ff ff ff ff ff ff . ......ok......
Looking at the evidence it seems that either
(a) the chip register setup has failed - maybe the I/O space is not enabled.
(b) the kernel pci subsystem allocated very different addresses (and
the CSR0 value is wrong)
(c) DMA was started before the initialisation was done.
I'm voting for (c) because the chip setup isn't done until the device
is opened (which is about where you were) and I cannot think that the
other things are plausible. More specifically pci_set_master is called
before the rx & tx engines are stopped. That means that if OBP left
the engines running then enabling the master bit would cause the
symptoms that we see.
The patch below should fix this...
--- drivers/net/tulip/tulip_core.c.orig Mon Sep 10 23:51:56 2001
+++ drivers/net/tulip/tulip_core.c Mon Sep 10 23:52:24 2001
@@ -1466,8 +1466,6 @@
goto err_out_free_res;
#endif
- pci_set_master(pdev);
-
pci_read_config_byte (pdev, PCI_REVISION_ID, &chip_rev);
/*
@@ -1507,6 +1505,8 @@
/* Stop the chip's Tx and Rx processes. */
tulip_stop_rxtx(tp);
+
+ pci_set_master(pdev);
/* Clear the missed-packet counter. */
inl(ioaddr + CSR8);
Reply to: