I've been watching this for a while.
I think you're both barking up the wrong tree. /etc/path_to_inst
shouldn't matter.
The problem is most likely a process that is trying to actually *access*
the stale link. Perhaps a stale link in /dev?
I forgot what kind of device is at issue here, but I'd start looking for
things in userland that are opening up devices.
The kernel does *not* automatically call attach for all hardware
recorded in /etc/path_to_inst, *except* on a reconfiguration reboot.
And ultimately, /etc/path_to_inst is *only* used to match a device
instance to the instance number. What actually drives the attach during
a reconfiguration reboot is the entries in the actual device tree (i.e.
what you see with prtconf -vp).
-- Garrett
On 10/15/08 05:30, Cyril Plisko wrote:
On Wed, Oct 15, 2008 at 2:24 PM, James C. McPherson
<[EMAIL PROTECTED]> wrote:
Christian Kaiser wrote:
Christian Kaiser wrote:
Artem Kachitchkine wrote:
# prtconf | grep 9902,101
pci9902,101, instance #1 (driver not attached)
Everything looks good, except that I see another (failing) call to
attach for instance #0 in the log files.
Is it possible that you moved the card between PCI slots and there's a
stale entry in /etc/path_to_inst?
-Artem
Hit!
$ grep 9902,101 /etc/path_to_inst
"/[EMAIL PROTECTED],0/pci8086,[EMAIL PROTECTED]/pci9902,[EMAIL PROTECTED]" 1
"dis_dx"
"/[EMAIL PROTECTED],0/pci8086,[EMAIL PROTECTED]/pci9902,[EMAIL PROTECTED]" 0
"dis_dx"
Is it save to remove the line that refers to the non-existent instance #0?
Christian
OK... I answer myself. I removed the line and renamed instance #1 to #0
but I still get two calls to attach. The difference is that now both
calls try to attach instance #0.
In general, how can I clean this up properly?
Did you try either
(a) devfsadm -C
or
(b) a reconfigure reboot, by add "-r" to the end of your kernel$
line in grub
AFAIK, neither will clean up /etc/path_to_inst
Although "devfsadm -vC" is something I run routinely when playing with drivers.
Regards,
Cyril
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
