[parisc-linux] tulip driver

[parisc-linux] tulip driver

[Sonny Cook]

What is the state of the tulip driver currently?  I have been running 
2.4.9-pa45 for a few weeks with a tulip pci card in a b132L.  I decided to 
upgrade the system and kernel.  The kernel I used is 2.4.16-pa16.  During 
the boot process, the kernel just locks up after reporting that it has 
freed some memory.  Further investigation revealed that loading the tulip 
module locks it up.  It spewed out some debugging info, but I did not grab 
it.  I have the kernel module autoloader set and tulip compiled as a 
module.
Any advice, or hint as to where to start looking would be appreciated.

On a releated note, I have a tulip based 4-port ethernet card 
(AHA6944B/TX) that I have been playing with.  Loading the tulip module 
with this thing installed also locks the machine up nicely.  I do have the 
debugging information the kernel spit, but I'm not quite sure what to do 
with it.  Again, any advice would be appreciated.

Thanks,
Sonny

Re: [parisc-linux] tulip driver

[Grant Grundler]

Sonny Cook wrote:
> What is the state of the tulip driver currently?

Stable - I don't think tulip's your problem.

> The kernel I used is 2.4.16-pa16.  During 
> the boot process, the kernel just locks up after reporting that it has 
> freed some memory.

Helge enabled freeing bootmem and it was disabled again because of such
lock-ups. At least until all extra __init's get removed.
I think it's disabled since 2.4.16-pa18 or -pa19.
So tulip is just a victim here and not a culprit.

> Any advice, or hint as to where to start looking would be appreciated.

Pull newer kernel source or disable the #if 1 that was enabled in -pa14.
See parisc-linux-cvs archive for details.

grant

Re: [parisc-linux] tulip driver

[Sonny Cook]

I'm still suspicious.  If I boot with init=/bin/sh, then it boots to the 
shell.  When I do an insmod on the tulip module, then the kernel crashes 
and spits out the (I think its the stack) debugging info.  At any rate, 
I'll give the latest kernel a try and see what happens.
Thanks,
Sonny

On Wed, 12 Dec 2001, Grant Grundler wrote:

> Sonny Cook wrote:
> > What is the state of the tulip driver currently?
> 
> Stable - I don't think tulip's your problem.
> 
> > The kernel I used is 2.4.16-pa16.  During 
> > the boot process, the kernel just locks up after reporting that it has 
> > freed some memory.
> 
> Helge enabled freeing bootmem and it was disabled again because of such
> lock-ups. At least until all extra __init's get removed.
> I think it's disabled since 2.4.16-pa18 or -pa19.
> So tulip is just a victim here and not a culprit.
> 
> > Any advice, or hint as to where to start looking would be appreciated.
> 
> Pull newer kernel source or disable the #if 1 that was enabled in -pa14.
> See parisc-linux-cvs archive for details.
> 
> grant
> 

Re: [parisc-linux] tulip driver

[Matthew Wilcox]

On Thu, Dec 13, 2001 at 07:22:25AM +0000, Sonny Cook wrote:
> I'm still suspicious.  If I boot with init=/bin/sh, then it boots to the 
> shell.  When I do an insmod on the tulip module, then the kernel crashes 
> and spits out the (I think its the stack) debugging info.  At any rate, 
> I'll give the latest kernel a try and see what happens.

tulip isn't the problem.  tulip is calling some routine which is the
problem.  we just don't know which one.

-- 
Revolutions do not require corporate support.

[parisc-linux] Tulip driver

[Thomas Bogendoerfer]

Hi,

I've checked in a new tulip driver, which works for me on the onbard tulip
of the A180. I've tried to use Donald's latest driver (0.91x), but this
driver needs some pci infrastructure, which isn't available in our 2.3 tree,
yet. So I ported the 2.2.14 driver and added cache flushes. Before
that I've added the cache flushes to tulip 0.91x, so whenever we update
our tree, I should have an updated tulip very quick.

The 2.2.14 tulip didn't like the SROM provided by the onboard tulip,
because it didn't provide information about the attached phy (and the
default media is in the wrong endian, but that isn't a big problem).
I fixed that by just not allocating a media table, which works in
my case. It's possible that this may break later. The SROMs of the
tulips behind the card mode dino are looking stranger, they seem
to be from a time before Digital released a sane SROM documentation
and might confuse the driver as well. But since the machine hangs,
when the driver tries to probe the second tulip on the card, this
isn't an issue, yet.

I'm now looking into getting nfs root working.

Thomas.

-- 
   This device has completely bogus header. Compaq scores again :-|
It's a host bridge, but it should be called ghost bridge instead ;^)
                                        [Martin `MJ' Mares on linux-kernel]

Re: [parisc-linux] Tulip driver

[Grant Grundler]

Thomas Bogendoerfer wrote:
> ...The SROMs of the
> tulips behind the card mode dino are looking stranger, they seem
> to be from a time before Digital released a sane SROM documentation
> and might confuse the driver as well. But since the machine hangs,
> when the driver tries to probe the second tulip on the card, this
> isn't an issue, yet.

Thomas,
I looked at the console output you sent me and I saw several things
not correct (which I'm trying to fix) right away:
o I/O BAR's where not getting programmed correctly.
  (both tulips fighting for the same I/O Port address (0) caused the hang)
o command register was not set
o cacheline size and latency timer were not getting set.

Now I have the opposite problem: PCI code finds and initiliazes the
tulips behind card-mode Dino but tulip.c doesn't want to talk to them.
So I can't really say for sure my changes work.

I've committed my code anyway since the oboard tulip continues to work.
Perhaps you can take another look at this.

thanks
grant

Grant Grundler
Unix Development Lab
+1.408.447.7253

Re: [parisc-linux] Tulip driver

[Thomas Bogendoerfer]

On Sun, Feb 06, 2000 at 08:54:23AM -0800, Grant Grundler wrote:
> Now I have the opposite problem: PCI code finds and initiliazes the
> tulips behind card-mode Dino but tulip.c doesn't want to talk to them.
> So I can't really say for sure my changes work.

The checked in tulip version probes for only one tulip chip. If you
want to make the driver probe for all tulips, search for the second
FIXME in the driver and remove the break; after the comment.

> I've committed my code anyway since the oboard tulip continues to work.
> Perhaps you can take another look at this.

still no go, now it hangs while probing the first tulip on the card.

Thomas.

PS: Anybody who wants to play with the tulip driver, use revision 1.4
of arch/parisc/kernel/irq.c. Newer versions got cleaned up, so they
don't work anymore:-( But with the old irq.c bootp handshake works and
I don't have to use the hacked sash anymore.

-- 
   This device has completely bogus header. Compaq scores again :-|
It's a host bridge, but it should be called ghost bridge instead ;^)
                                        [Martin `MJ' Mares on linux-kernel]