Re: [Fwd: [AD] lsystem.c and the iopl call]

[Craig Matsuura <cmatsuura@xxxxxxxxxx>]

> Any ideas?

Allegro and RealAudio (rmacore.so.6) conflict:

> When I don't call allegro_init() my program runs fine.  I can connect to the
> site and play the streaming audio.  Not all sites seem to have this problem
> with allegro.
>
> I have been debugging inside the allegro startup code.  I have found myself
> in xsystem.c and xwin.c.  I worked my way down into (from the
> _sigalrm_init(_xwin_interrupts_handler) call from inside _xwin_sysdrv_init)
> _xwin_private_flush_buffers(), which calls an XSync().  I suspect that the
> XServer is dying for some reason and the XSync must fail.
>
> If I comment out the XSync and run my original program that calls
> allegro_init and displays an allegro dialog.  I get the following error:
>
> X Error of failed request:  BadIDChoice (invalid resource ID chosen for this
> connection)
>   Major opcode of failed request:  129 (MIT-SHM)
>   Minor opcode of failed request:  1 (X_ShmAttach)
>   Resource id in failed request:  0x4400007
>   Serial number of failed request:  199
>   Current serial number in output stream:  77
>
> However the streaming audio plays?
>
> My second test program is only calling allegro_init().  I have done nothing
> else with allegro.  I think that allegro must be hooking an interrupt such
> as SIGALRM and conflicting with the Real G2 SDK (which probable does the
> same).
>
> I think the _sigalrm_init call could be the culprit.
>
> SIDENOTE: Even running fullscreen using non X, like framebuffer, it appears
> to have an issue. (Still verifying).  I only get a few things displayed.
>
> >
> >
> > > So I decide to comment the line out with the iopl() call.  My
> > > application no longer crashes.  Is there a reason for setting the iopl
> > > to level 3?  Is it because of the 8514 X Server?
> >
> > No, but we need the privileges for the same reasons -- we need
> > access to the IO ports.  We can ask for specific ranges, using
> > `ioperm', but that only works for fairly low port numbers (I
> > don't remember exactly how low).  Using `iopl', we get access to
> > all ports, even ones we don't actually need.  This could be what
> > is causing your problem -- maybe some of the other code you're
> > using is writing to ports it shouldn't be touching.  That seems
> > unlikely though, because it would generally cause much more
> > severe problems than a simple SIGPIPE.
> >
> > Note that `iopl' only works at all if you have root privileges
> > at the time -- if your program wasn't run either by root or suid
> > root, then this call should just fail.  If you comment out the
> > line, it will cause various Linux console drivers to stop
> > working; the VGA driver needs these privileges, for instance.
> > It's possible that commenting out this line turned off some
> > Allegro drivers which would otherwise have interfered with the
> > other code in your program.
> >
> > It might help if you try running your program, including the
> > `iopl' call, without root privileges -- does it crash in this
> > case?
> >
> > I'm slightly confused by your references to the X server -- if
> > the code in `lsystem.c' is at all relevant to your program,
> > you're not using the X version of Allegro.  Perhaps you could
> > clarify exactly which version of Allegro is being used, and
> > whether the effects depend upon being run by root.
> >
>
> Yes, I have been using the X version of allegro.  My bad, I was looking at
> both lsystem.c and xsystem.c.  Because running fullscreen framebuffer
> appears to have a problem too.
>
> >
> > George
> >
> > --
> > Random project update:
> > 27/04/2000: AllegroGL alpha 7 released, fixing silly omission in alpha 6
> >         http://AllegroGL.sourceforge.net/