On Fri, Mar 04, 2005 at 03:47:56PM +0000, john heasley wrote:
> Fri, Mar 04, 2005 at 10:25:45AM +0100, Lukas Diduch:
> > > > > i've installed a (probably newer model of) a Promise SATA TX2Plus
> > > > > controller
> > > > > on a u60/sparc64. The system does not recognize the device. (maybe
> > > because
> > > > > of the fancy id ?)
> > > > > 
> > > > > dmesg :
> > > > Promise Technology product 0x3d75 (miscellaneous mass storage, revision
> > > > 0x02) at pci0 dev 2 function 0 not configured
> > > > psycho1 at mainbus0 addr 0xfffc6000
> > > > 
> > > > here's a pcictl dump of the device :
> > > > 
> > > > PCI configuration registers:
> > > >   Common header:
> > > >     0x00: 0x3d75105a 0x02300007 0x01800002 0x00002040
> > > > 
> > > >     Vendor Name: Promise Technology (0x105a)
> > > >     Device ID: 0x3d75
> > > 
> > > For starters, Its probably showing up as 'not configured' because the
> > > device
> > > ID is not in pcidevs or in pdcide's table of devices to match.  You could
> > > add it and see if it is close enough to those supported by the pdcide
> > > driver.
> > > 
> > (Sorry for mailing 2x John.) I've altered (not added yet) pcidevs and
> > pcidevs.h respectively to know the id (3d75) of the pdcsata dev. (changed
> > the id's of 3318 then 3375 then 3379 to 3d75) The device IS recognized now,
> > but fails to initialize the hdd. It recognizes just 65gb out of 160gb and
> > hangs up in a loop then : bogus int (reg 0x2)....
> > I will run more tests given the time, and if you need someone testing new
> > code on this new piece of hw., here i am :>
> 
> yesterday Mathias Scheler suggested that this card ought to use the pdcsata
> driver, rather than the pdcide driver.  Perhaps you could try that.

The line

pdcsata* at pci? dev ? function ?       # Promise SATA150 controllers

is in GENERIC32 which is included by default in GENERIC kernels on sparc64.
Sorry for misleading you maybe, but i am using the pdcsata driver (see below)
with a sata card connected to a 160gb sata hdd.  

Unfortunately just adding the device to pcidevs and pcidevs.h doesn't help.
Those promise cards have some specific code in sys/dev/pci/pdcsata.c which
checks for the id. If you take a short look at that code you'll see that the
driver uses a special handling of those promise cards.  (i refer to $NetBSD:
pdcsata.c,v 1.2 2004/11/28 14:34:31 bouyer Exp $ written by Manuel Bouyer.)

> 
> I'm not sure what you mean by 'change the IDs'.  It should not be necessary
> to use a variation of the ID for a given card.

So i thought it would be a good idea to 'mimic' the 0x3d75 card as a 0x3318
card instead of hacking the pdcsata.c code.  For testing purpose i've altered the
pcidevs line :

product PROMISE PDC20318        0x3318  PDC20318 SATA/150 IDE controller

to

product PROMISE PDC20318        0x3d75  PDC20318 SATA/150 IDE controller

to see if the card is maybe recognized (and compatible with my new model). At
least the kernel recognizes the card and tries to analyze the hdd (which fails
an brings the kernel in a infinte loop i wrote of before).

Should i try the other id's the same way to check wether maybe the code of one
of the eight cards listed in pcidevs is compatible ? Or is this just a waste of
time ?

Kind regards
Lukas