7 Replies Latest reply: Jul 1, 2009 4:58 AM by PhHein RSS

    devfsadm: driver failed to attach

    807567
      Hi,

      I'm developing PCI-E network NIC driver for Solaris 10 on x86/amd64 and Sparc.
      Currently I'm in the very beginning having skeletone code implementing simple init fini and attach, detach and probe functions.

      I compile my skeletone driver using:
      CC=/opt/SUNWspro/bin/cc
      CFLAGS/sparc:
          -D_KERNEL -xarch=v9
      CFLAGS/amd64
          -D_KERNEL -xarch=amd64 -xmodel=kernel
      LD=/usr/ccs/bin/ld
      LDFLAGS=-dy -r -N "misc/gld"
      On Amd64 I copy the driver to
      /usr/kernel/drv/amd64
      and install driver using
      add_drv -i"pciXXXX,YYYY" zzz
      Everything works fine, operation successful, I see trace for all the callback functions.

      From other hand on Sparc it does not work: I copy the driver to
      /usr/kernel/drv/sparcv9
      and try to install it using the same
      add_drv
      command. I get:
      sparc-sol10 -> /usr/kernel/drv/sparcv9#add_drv -i"XXXX,YYYY" zzzz
      devfsadm: driver failed to attach: zzzz
      Warning: Driver (thtxg) successfully added to system but failed to attach
      When I check traces I see that neither attach nor probe callbacks were called at all !

      What am I doing wrong?

      Thank you,
      Alexander Indenbaum
        • 1. Re: devfsadm: driver failed to attach
          807567
          Warning: Driver (thtxg) successfully added to system but failed to attach
          Hello

          This message typically has one of the following reasons:
          1) The hardware has not been detected propperly (i.e. the system cannot find the device "pciXXXX,YYYY")

          2) The driver.conf file is missing. If your driver needs a driver.conf file it must be placed in /kernel/drv (or /usr/kernel/drv), not in /kernel/drv/sparcv9.

          3) Check if your attach() function is called at all (eg. using cmn_err()). If yes, your attach() function behaves differently on Sparc and on x86.

          Martin
          • 2. Re: devfsadm: driver failed to attach
            807567
            Martin,

            Thank you for your reply.

            I trace entering the interface function using cm_err().
            On i386 I see all info() init() probe() attach() functions being called by the kernel.
            On sparc while info() and init() are called and return success, probe() and attach() are not called.

            As far as I can tell the only difference between i386 and sparc driver versions is CFLAG definition. Other than that c source, Makefile, OS and compilation chain are identical.

            Alexander
            • 3. Re: devfsadm: driver failed to attach
              807567
              I have this annoying problem on a driver I'm working on for x86 32bit platform. Have you found out answers to why "attach()" is not called?
              • 4. Re: devfsadm: driver failed to attach
                807567
                Hi:

                I see the same problem. All traces in probe and attach get logged in /var/adm/messages when I add_drv in x86. Nothing when I add_drv on Sparc. I get the same message "failed to attach". But driver gets added and I see it associated with the device in prtconf.

                Anyone seen and figured this out?

                loth
                • 5. Re: devfsadm: driver failed to attach
                  807567
                  Martin,

                  Be sure to check this first. It's usually the problem.

                  The hardware has not been detected propperly.


                  [Dentist Manchester|http://www.yourmanchesterdentist.co.uk/]
                  • 6. Re: devfsadm: driver failed to attach
                    PhHein
                    Blocking link spam.
                    • 7. Re: devfsadm: driver failed to attach
                      807567
                      The two things i'd look for are 1) funky word ordering issues and 2) some conflicting class definition in /etc/driver_aliases. If you are really determined, you can use mdb and step through the kernel initialization and see why it isn't called....

                      -r