to write or not to write a BLASTED device driver

to write or not to write a BLASTED device driver

Post by samue » Sat, 12 Jun 2004 04:06:35



I have read the Solaris DDI/DDK manual cover to cover more than once,
and I am following the example source provided (pio.c to keep it
simple) win sun_device_drivers.tar.

I am at a point where my driver appears to be added but fails to attach.
Now the part that has me irked is - I CANT see any error messages I have
written out through "cmn_err()"

man syslog
man syslog.conf allowed me to reconfigure my /etc/syslog.conf as
follows:

*.alert;*.crit;*.emerg;*.err;*.warning          *
*.notice;*.debug                                *

Technically all error messages /notices should appear in any users
console - (not a problem since root is the only user on the spare
Ultra Sparc 5 development system I have set aside for this project).

ANy one know why I cant get any output - (dmesg - has nothing here
as well) from my driver routine calls to "cmn_err()"? I am pretty
certain that i am getting passed the probe() routine because if I
insert a statement that triggers a segmentation fault - the system
dumps core ... but this is no way to debug a driver ;)

Furthermore, what is exit code 11 - from below?

make install
cp bt878drv /usr/kernel/drv/sparcv9
add_drv -v -i "pci109e,878" bt878drv
exit status = 0
devfsadm: driver failed to attach: bt878drv
exit status = 11
Warning: Driver (bt878drv) successfully added to system but failed to attach
Driver (bt878drv) installed.

Thanks

 
 
 

to write or not to write a BLASTED device driver

Post by Gavin Maltb » Sat, 12 Jun 2004 05:22:44



> I have read the Solaris DDI/DDK manual cover to cover more than once,
> and I am following the example source provided (pio.c to keep it
> simple) win sun_device_drivers.tar.

> I am at a point where my driver appears to be added but fails to attach.
> Now the part that has me irked is - I CANT see any error messages I have
> written out through "cmn_err()"
[cut]
> make install
> cp bt878drv /usr/kernel/drv/sparcv9

I think this can happen if your driver needs a .conf file and none
is provided or it's in the wrong place (like the sparcv9 subdir
instead of drv itself).

Gavin

 
 
 

to write or not to write a BLASTED device driver

Post by samue » Sat, 12 Jun 2004 06:18:37


Quote:> I think this can happen if your driver needs a .conf file and none
> is provided or it's in the wrong place (like the sparcv9 subdir
> instead of drv itself).

I compiled it with the -m64 flag (gcc) which necessitates placing
it in the sparcv9 subdirectory.

I also remember reading that there is NO need for the *.conf file if
your driver is supporting a Self Identifying device.

Is this not the case?

 
 
 

to write or not to write a BLASTED device driver

Post by McBof » Sun, 13 Jun 2004 20:09:15



>> I think this can happen if your driver needs a .conf file and none
>> is provided or it's in the wrong place (like the sparcv9 subdir
>> instead of drv itself).
> I compiled it with the -m64 flag (gcc) which necessitates placing
> it in the sparcv9 subdirectory.
> I also remember reading that there is NO need for the *.conf file if
> your driver is supporting a Self Identifying device.
> Is this not the case?

No, it is not the case. You still need the driver.conf file.

I'm not sure offhand whether a zero-length .conf will work, but
it might. A better idea is to try something like this in /kernel/drv:

# begin driver.conf
name="mydriver" parent="pseudo" instance=0;
# end driver.conf

mcbofh

 
 
 

to write or not to write a BLASTED device driver

Post by James Carlso » Tue, 15 Jun 2004 20:40:17



> I compiled it with the -m64 flag (gcc) which necessitates placing
> it in the sparcv9 subdirectory.

By default, gcc produces binaries that don't work in the kernel
because they refer to gcc-specific user-space library bits.

To build a 64-bit binary, you should have these options:

        -mcpu=v9 -m64 -mcmodel=medlow -mstack-bias -fno-builtin

... and link with /usr/bin/ld -r.  You can also get more detail from
the module loading process by tweaking the 'moddebug' kernel variable
(see sys/modctl.h).

--

Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

 
 
 

to write or not to write a BLASTED device driver

Post by samue » Wed, 16 Jun 2004 03:33:21


Quote:> To build a 64-bit binary, you should have these options:

>         -mcpu=v9 -m64 -mcmodel=medlow -mstack-bias -fno-builtin

> ... and link with /usr/bin/ld -r.  You can also get more detail from
> the module loading process by tweaking the 'moddebug' kernel variable
> (see sys/modctl.h).

Thanks
I modified the "moddebug" variable to give me more error messages:
echo moddebug/W0xe0000000 |adb -kw

Heres some relevant output that I am trying to analze:
1.
 >exit status = 0
 >devfsadm: driver failed to attach: bt878
 >exit status = 11
 >Warning: Driver (bt878) successfully added to system but failed to >attach
 >Driver (bt878) installed.

Problem is I am not getting ANY messages to indicate that I entered the
attach routine - and I am using "cmn_err("\nI am in Attach\n"); its not
in dmesg and its not in /var/adm/messages or /var/log/syslog

2.
 >Jun 14 14:20:56 devel krtld: kobj_open: '/usr/kernel/drv/bt878.conf'
 >Jun 14 14:20:56 devel krtld:  vp = 30002232310
 >
 >Jun 14 14:20:56 devel krtld: kobj_open: '/usr/kernel/drv/sparcv9/bt878'
 >Jun 14 14:20:56 devel krtld:  vp = 300022326e0
 >Jun 14 14:20:56 devel krtld: kobj_close: 0x300022326e0
 >Jun 14 14:20:56 devel genunix: Holding drv/bt878
 >Jun 14 14:20:56 devel genunix: loading 'drv/bt878' id 246

bt878.conf contains:
name="bt878"    parent="pseudo" vendor-id="109e" instance=0;

following the instructions in man pseudo ... and the solaris ddi/ddk manual

3.
 >Jun 14 14:20:56 devel pseudo: pseudo0: invalid op (8) from bt8780
 >Jun 14 14:20:56 devel genunix: Holding drv/bt878
 >Jun 14 14:20:56 devel genunix: uninstalling bt878

invalid op -
op =  ???
operand/opcode ???

What does this mean and which support routine is generating it?
(devsfadm or add_drv ???)

By the way - on other unixes I could go the mknod route and create
the major and minor device nodes myself ... is there a way under Solaris
to BYPASS add_drv and devsfadm ???

I am trying to figure out WHERE the problem lies and WHY I am unable
to get output from my drivers attach routine ...

Thanks

 
 
 

to write or not to write a BLASTED device driver

Post by James Carlso » Thu, 17 Jun 2004 02:51:09



> > To build a 64-bit binary, you should have these options:
> >         -mcpu=v9 -m64 -mcmodel=medlow -mstack-bias -fno-builtin
> > ... and link with /usr/bin/ld -r.  You can also get more detail from
> > the module loading process by tweaking the 'moddebug' kernel variable
> > (see sys/modctl.h).

> Thanks
> I modified the "moddebug" variable to give me more error messages:
> echo moddebug/W0xe0000000 |adb -kw

OK.

Quote:> Problem is I am not getting ANY messages to indicate that I entered the
> attach routine - and I am using "cmn_err("\nI am in Attach\n"); its not
> in dmesg and its not in /var/adm/messages or /var/log/syslog

That's actually cmn_err(CE_CONT, "I am in attach"), right?

Quote:>  >Jun 14 14:20:56 devel pseudo: pseudo0: invalid op (8) from bt8780
>  >Jun 14 14:20:56 devel genunix: Holding drv/bt878
>  >Jun 14 14:20:56 devel genunix: uninstalling bt878

> invalid op -
> op =  ???
> operand/opcode ???

> What does this mean and which support routine is generating it?
> (devsfadm or add_drv ???)

No expert in this area, but I believe it means that something from
this driver called ddi_dev_is_sid(9F) and then failed.

(If this were Solaris 10, it'd be easy to find with dtrace ...)

Quote:> By the way - on other unixes I could go the mknod route and create
> the major and minor device nodes myself ... is there a way under Solaris
> to BYPASS add_drv and devsfadm ???

Nothing supported that I know of.

Quote:> I am trying to figure out WHERE the problem lies and WHY I am unable
> to get output from my drivers attach routine ...

At a guess, if it's not getting to attach, then either the _init(9E) is
failing or the module has a probe(9E) entry point, and that's failing.

--

Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

 
 
 

to write or not to write a BLASTED device driver

Post by samue » Thu, 17 Jun 2004 06:10:04


Quote:> That's actually cmn_err(CE_CONT, "I am in attach"), right?

YEP

James, I found my problem (well besides not having my head screwed on
straight) ...

My probe routine wasnt being called. When I added -i "pci109e,878" or
-i "video" I got the expected response. After making a few
changes/rereading parts of the Solaris Manual I finally got it to
attach sans error.

Now, the real fun begins!

Quote:> No expert in this area, but I believe it means that something from
> this driver called ddi_dev_is_sid(9F) and then failed.

actually I placed a call to that function in my probe routine, to be
certain I will only deal with Self Identifying devices as they are
called ...

thanks

 
 
 

to write or not to write a BLASTED device driver

Post by James Carlso » Thu, 17 Jun 2004 22:52:05



> James, I found my problem (well besides not having my head screwed on
> straight) ...

> My probe routine wasnt being called. When I added -i "pci109e,878" or
> -i "video" I got the expected response. After making a few
> changes/rereading parts of the Solaris Manual I finally got it to
> attach sans error.

Ah, bingo.  That'd do it.

Quote:> > No expert in this area, but I believe it means that something from
> > this driver called ddi_dev_is_sid(9F) and then failed.

> actually I placed a call to that function in my probe routine, to be
> certain I will only deal with Self Identifying devices as they are
> called ...

Yep, that was a red herring.  Sorry about that; it just looked like it
was _near_ the problem.

(I do suggest debugging on S10 if you can ... the tools are much nicer
there.)

--

Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

 
 
 

to write or not to write a BLASTED device driver

Post by samue » Fri, 18 Jun 2004 00:21:54


Quote:>(I do suggest debugging on S10 if you can ... the tools are much nicer
>there.)

James I wouldnt mind debugging Solaris 10 but then I wouldnt be able to
use my SUNPCI card I - which was last supported on Solaris 8 and I had
to hack to get to work on Solaris 9 ... (barely)

Hey you work at sun right?
Do you know of any plans to release the register level specifications to
the SUNPCI card (I NOT II or III) ??? or at least to continue supporting
it past Solaris 8

Thanks - I know this is a bit offtopic ;)

 
 
 

to write or not to write a BLASTED device driver

Post by James Carlso » Sat, 19 Jun 2004 00:02:37



> Hey you work at sun right?

That's what they tell me.  ;-}

Quote:> Do you know of any plans to release the register level specifications to
> the SUNPCI card (I NOT II or III) ??? or at least to continue supporting
> it past Solaris 8

Not that I know of, though it's certainly fair to ask someone in
support or sales.  (I'm pretty sure that SunPCi I isn't supported past
Solaris 8 and that there are no plans to support it because the
upgrade path is through the newer cards.)

I'm sure you know that there are newer cards that work on the newer
systems (and are _much_ nicer).

--

Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

 
 
 

to write or not to write a BLASTED device driver

Post by samue » Sat, 19 Jun 2004 05:50:03


Quote:> Not that I know of, though it's certainly fair to ask someone in
> support or sales.  (I'm pretty sure that SunPCi I isn't supported past
> Solaris 8 and that there are no plans to support it because the
> upgrade path is through the newer cards.)

Whats the big deal with releasing the register level specs so that the
FREEBSD, NETBSD or OPENBSD group can continue to support sparc related
hardware once Solaris X has dropped support for it.

By the way I prefer the initial sunpci I - it does what I need it to
and I rarely use it - but when i do its nice to be able to avoid having
to dedicate a section of my desktop to a wintel pc.

 
 
 

to write or not to write a BLASTED device driver

Post by James Carlso » Sat, 19 Jun 2004 06:01:13



> Whats the big deal with releasing the register level specs so that the
> FREEBSD, NETBSD or OPENBSD group can continue to support sparc related
> hardware once Solaris X has dropped support for it.

You'd have to ask the people in marketing or support.  I'm in
development (see the signature ;-}).

It's possible that the specs are under some sort of licensing
agreement.  Or that they contain things that are encumbered by some
sort of IPR.  Or just that nobody has thought to do it yet.  I really
don't know one way or the other, nor am I in a position to know.

Quote:> By the way I prefer the initial sunpci I - it does what I need it to
> and I rarely use it - but when i do its nice to be able to avoid having
> to dedicate a section of my desktop to a wintel pc.

OK ...

--

Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677