>cc -D_KERNEL -D_SYSCALL32 -xarch=v9 -c sst.c
>
>I did this because it's a 64-bit kernel running on a SUN Enterprise 3500.
>(Although I had errors during the compilation).
You know, it's really annoying to say something like that and then not
post what the errors were. Nobody is going to be able to respond to
such a statement without more information.
>So, I put the sst result from above into /usr/kernel/drv/sparcv9 ...
I assume you mean you also ran the "ld" step and put **that** result
down in /usr/kernel/drv/sparcv9, right?
>Added the following entry to the /etc/devlink.tab file:
>
>type=sample_driver;name=sst;minor=character rsst\A1
>...
>Then I rebooted to find no rsst0 in my /dev directory.
Is the changer SCSI address zero? My reading of the devlink.tab docs
and the sst.c source comments indicate the number will be the SCSI ID
(and target?) number, i.e. if the changer is ID 3, you should expect to
see /dev/rsst3 or maybe /dev/rsst3,0 (ID and target).
Did you do a reconfigure reboot? I think that's the only way these
device entries are going to show up (actually, you can run drvconfig,
devlinks, et al, but I'm not sure of the right sequence).
What happens if you run this (after a reconfigure reboot):
find /devices -name '*sst*' -print
>After running the add_drv command, a couple of errors popped up, but the syste
>m
>stated it was attached, but not working properly.
Again, telling us you saw errors without quoting the error messages
is useless.
>I added the entry into /etc/system:
>set sst:rsst=0
Why? My understanding is this tells the kernel to set the "rsst"
variable in the "sst" driver to zero, but there is no such variable,
so I don't know what the point of this setting would be. Did you find
this suggested in some documentation someplace? Where?
>Rhett Saunders
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
