Paul Durrant wrote: > Christian Kaiser wrote: >> >> But in the syslog I see two calls to my attach function for the same >> instance #0. What other place may store the information about the >> second (although non-existent) instance #0 then? >> > > Did you rebuild your boot archive? /etc/path_to_inst is included in the > boot archive. To clean up I'd recommend you simply delete > /etc/path_to_inst unless you have drivers loaded where you'd rather the > instances didn't move. Once you've deleted, make sure that 'bootadm > update-archive' is run (reboot should do that) and that your grub entry > is set to boot from the standard archive and not a backup. > Since I'm moving cards around all the time and loading experimental > drivers that sometimes crash, what I do is: > > - remove /etc/path_to_inst > - edit /lib/svc/method/boot_archive to remove the echit > $SMF_EXIT_FATAL_ERR and replace it with $SMF_EXIT_OK
That is $SMF_EXIT_ERR_FATAL for me (snv_84). > - make sure my driver is removed > - run bootadm update-archive > - copy /platform/i86pc/boot_archive to /platform/i86pc/boot_archive.good > (and similar in the amd64 subdir.) > - edit /boot/grub/menu.lst to add an extra entry to boot from > boot_archive.good and set this to be the default. > > Having done this I can always reboot my machive after a driver crash > (without having to clean up the boot archive) and whenever I move or > swap a card and reboot it will always end up as instance #0. Yes! That is exactly what I was looking for. Thank you very much! That helps avoiding these annoying reboots into failsafe after every crash during add_drv. But... unfortunately I still see the two attach calls for instance #0. Any idea how to debug this? Christian -- Christian Kaiser, Software Engineer, Dolphin Interconnect Solutions http//www.dolphinics.com _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
