John Martin wrote:
Bill Shannon wrote:
I just upgraded (using package manager "upgrade all") from snv_101a
to snv_111a. When I reboot in the new boot environment, it crashes
right away. Since it reboots after the crash, clearing the screen,
it's really hard to catch why it's failing. I resorted to taking a
picture of the screen before the reboot occurs. Surely there's a
better way?
Anyway, it dies with some sort of panic. The stack trace looks like:
unix:mutex_panic
unix:mutex_destroy
gfx_private:gfxp_vga...
atiatom:atiatom_detac...
atiatom:atiatom_attac...
genunix:devi_atach
genunix:attach_node
genunix:i_ndi_config_...
genunix:i_ddi_attachc...
genunix:i_ddi_attach_...
consconfig_dacf:plat_...
consconfig_dacf:consol...
It looks like gfxp_private::gfxp_vgatext_detatch() is being called twice,
once when gfx_private::gfxp_vgatext_attach() detects an error and cleans
up after itself and again after it returns the DDI_FAILURE error code
to the atiatom module and it calls gfxp_vgatext_detach() again from
atiatom_detach().
mutex_destroy() gets called twice for the same object.
File a bug. The gfx_private driver needs to keep state on whether the lock
needs to be destroyed in case its detach is called multiple times.
However, the bigger problem will eventually be why the attach function
failed since all it does is basic aperture mapping.
Filing a bug for this is a waste of my time. If no one else is running
into this, it's not going to be fixed anytime soon. And if other people
*are* running into it, it will be fixed without *me* filing a bug.
It's less frustrating to just hope that the next build will be better.
At least, that's been my experience so far.
What I'm hoping for is some sort of workaround...
It's an Ultra 20, with two screens.
Is this Ultra 20 or Ultra 20 M2? If M2, have you updated the most
recent SBIOS?
Not M2. I upgraded the BIOS anyway, just to avoid that excuse.
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
