On Sat, Aug 02, 2003 at 01:53:31AM -0700, Terry Lambert wrote:
> Marcel Moolenaar wrote:
> > But if we only use the dynamic allocation then it can only fail for
> > a combination of 3rd party code.
>
> You meant to say static here, e.g. when there are two libraries
> linked into a single aplicatio
On Fri, 1 Aug 2003, Julian Elischer wrote:
> On Fri, 1 Aug 2003, Julian Elischer wrote:
> > I also noticed that if we disable the 'splat' mode, we'd break sysVR4
> > binary code as they do that.. (though it's #if 0'd out at the moment)
>
> not to mention linux (more important..) though I might add
On Fri, 1 Aug 2003, Julian Elischer wrote:
> looking at it further, it appears that NLDT is not really a
> 'reservation' as much as a description of how much space we may
> need to allocate initially.
Correct, except it seems that there are some bugs from the kernel using
the code and data select
Julian Elischer wrote:
> + if (ldt_warnings++ < NUM_LDT_WARNINGS) {
Still broken on rollover; use:
+ if (ldt_warnings < NUM_LDT_WARNINGS) {
+ ldt_warnings++;
-- Terry
___
[EMAIL PROTECTED] mailing list
Marcel Moolenaar wrote:
> But if we only use the dynamic allocation then it can only fail for
> a combination of 3rd party code.
You meant to say static here, e.g. when there are two libraries
linked into a single aplication, and both libraries want to get
entry #6, right?
In the dynamic case, th
Julian Elischer wrote:
It's not that likely to roll, but...
> static int complained = 6;
>
> if (complained-- ) {
if (complained) {
complained--;
> printf ("process (PID %d) Use static LDT allocation.\n",
> td->td_proc->p_pid);
> printf ("man i386_set_ldt for
On Fri, 1 Aug 2003, Julian Elischer wrote:
> >
> > Looks OK, but if we are doing a dynamic allocation, it might be
> > better to start at NLDT just to avoid the known problem of someone
> > using 6... Just a thought.
>
> sure.. (though we don't know how many they use we just saw the first
On Fri, 1 Aug 2003, Daniel Eischen wrote:
> On Fri, 1 Aug 2003, Julian Elischer wrote:
> >
> > Here's my first patch..
> > I'd suggest this (along with man page change) to go in first
> > for a while before we break people's code.
> >
> > cvs server: Diffing .
> > Index: sys_machdep.c
> >
On Fri, 1 Aug 2003, Julian Elischer wrote:
>
> Here's my first patch..
> I'd suggest this (along with man page change) to go in first
> for a while before we break people's code.
>
> cvs server: Diffing .
> Index: sys_machdep.c
> ===
On Fri, 1 Aug 2003, Daniel Eischen wrote:
> On Fri, 1 Aug 2003, Marcel Moolenaar wrote:
>
> OpenGL is the example that I was thinking about.
>
> > Having a way to disallow using the static allocation should be easy
> > if we use compiler magic to test that the LDT entry is constant and
> > 0.
On Fri, 1 Aug 2003, Marcel Moolenaar wrote:
> On Fri, Aug 01, 2003 at 07:18:11PM -0400, Daniel Eischen wrote:
> > On Fri, 1 Aug 2003, Marcel Moolenaar wrote:
> >
> > > On Fri, Aug 01, 2003 at 06:51:33PM -0400, Daniel Eischen wrote:
> > >
> > > > Perhaps we need to rethink the interface and disal
On Fri, 1 Aug 2003, Daniel Eischen wrote:
> On Fri, 1 Aug 2003, Julian Elischer wrote:
> >
> > How about we complain loudly on the console when it's done..
> > (for the first few times)
> > (with info on how to do it right)
>
> And make a new interface, changing the prototype in the
> header
On Fri, 1 Aug 2003, Marcel Moolenaar wrote:
>
> Having a way to disallow using the static allocation should be easy
> if we use compiler magic to test that the LDT entry is constant and
> 0. If it is, all is ok (assuming that I'm not mistaken that we use a
> 0 entry to indicate dynamic allocatio
On Fri, Aug 01, 2003 at 07:18:11PM -0400, Daniel Eischen wrote:
> On Fri, 1 Aug 2003, Marcel Moolenaar wrote:
>
> > On Fri, Aug 01, 2003 at 06:51:33PM -0400, Daniel Eischen wrote:
> >
> > > > LUCODE_SEL is used by kernel to load _ucodesel to user %cs
> > > > LUDATA_SEL is used by kernel to load _
On Fri, 1 Aug 2003, Julian Elischer wrote:
>
>
> >
> > I can see the need to keep the old behavoir for compatibility's
> > sake.
>
> How about we complain loudly on the console when it's done..
> (for the first few times)
> (with info on how to do it right)
>
static int complained = 6;
On Fri, 1 Aug 2003, Julian Elischer wrote:
>
> On Fri, 1 Aug 2003, Daniel Eischen wrote:
>
> >
> > That's what I was worried about. Once an application or
> > library is written to use specific LDTs, you never know
> > how it will be affected by the use of threading libraries
> > (or other libr
On Fri, 1 Aug 2003, Julian Elischer wrote:
>
> On Fri, 1 Aug 2003, Daniel Eischen wrote:
>
> >
> > Perhaps we need to rethink the interface and disallow specification
> > of any ldt; only allow dynamic. We would need a different method of
> > setting an array of them, though.
>
> I think that
On Fri, 1 Aug 2003, Daniel Eischen wrote:
> On Fri, 1 Aug 2003, Marcel Moolenaar wrote:
>
> > On Fri, Aug 01, 2003 at 06:51:33PM -0400, Daniel Eischen wrote:
> >
> > > > LUCODE_SEL is used by kernel to load _ucodesel to user %cs
> > > > LUDATA_SEL is used by kernel to load _udatasel to user %d
On Fri, 1 Aug 2003, Julian Elischer wrote:
>
> On Fri, 1 Aug 2003, Daniel Eischen wrote:
>
> >
> > Perhaps we need to rethink the interface and disallow specification
> > of any ldt; only allow dynamic. We would need a different method of
> > setting an array of them, though.
>
> I think th
On Fri, 1 Aug 2003, Marcel Moolenaar wrote:
> On Fri, Aug 01, 2003 at 06:51:33PM -0400, Daniel Eischen wrote:
>
> > > LUCODE_SEL is used by kernel to load _ucodesel to user %cs
> > > LUDATA_SEL is used by kernel to load _udatasel to user %ds, %es, %fs, %gs.
> > > I didn't check other ABIs, but se
On Fri, 1 Aug 2003, Daniel Eischen wrote:
>
> Perhaps we need to rethink the interface and disallow specification
> of any ldt; only allow dynamic. We would need a different method of
> setting an array of them, though.
I think that for now we can allow anything over 6 because we are not a
BSD
On Sat, 2 Aug 2003, David Xu wrote:
> On Saturday 02 August 2003 06:24, Munish Chopra wrote:
> > On 2003-08-02 00:20 +0200, Thorsten Greiner wrote:
> > > * Daniel Eischen <[EMAIL PROTECTED]> [2003-08-02 00:06]:
> > > > I think the bug was in the old code allowing this to
> > > > happen...
> > >
On Fri, Aug 01, 2003 at 06:51:33PM -0400, Daniel Eischen wrote:
> > LUCODE_SEL is used by kernel to load _ucodesel to user %cs
> > LUDATA_SEL is used by kernel to load _udatasel to user %ds, %es, %fs, %gs.
> > I didn't check other ABIs, but setting to a fixed location of LDT in userland
> > is als
On Sat, 2 Aug 2003, David Xu wrote:
> On Saturday 02 August 2003 06:24, Munish Chopra wrote:
> > On 2003-08-02 00:20 +0200, Thorsten Greiner wrote:
> > > * Daniel Eischen <[EMAIL PROTECTED]> [2003-08-02 00:06]:
> > > > I think the bug was in the old code allowing this to
> > > > happen...
> > >
>
On Saturday 02 August 2003 06:24, Munish Chopra wrote:
> On 2003-08-02 00:20 +0200, Thorsten Greiner wrote:
> > * Daniel Eischen <[EMAIL PROTECTED]> [2003-08-02 00:06]:
> > > I think the bug was in the old code allowing this to
> > > happen...
> >
> > Well, than someone should tell that to NVidia.
On Fri, 1 Aug 2003, Munish Chopra wrote:
> On 2003-08-02 00:20 +0200, Thorsten Greiner wrote:
> > * Daniel Eischen <[EMAIL PROTECTED]> [2003-08-02 00:06]:
> > > I think the bug was in the old code allowing this to
> > > happen...
> >
> > Well, than someone should tell that to NVidia. Their driv
On Fri, 1 Aug 2003, Julian Elischer wrote:
>
> On Fri, 1 Aug 2003, Daniel Eischen wrote:
>
> > On Fri, 1 Aug 2003, Thorsten Greiner wrote:
> >
> > > * Thorsten Greiner <[EMAIL PROTECTED]> [2003-08-01 23:47]:
> > > > I will test wether the problem still occurs with version 1.84 of
> > > > sys_mac
On Fri, 1 Aug 2003, Julian Elischer wrote:
>
>
> On Fri, 1 Aug 2003, Daniel Eischen wrote:
>
> > On Fri, 1 Aug 2003, Thorsten Greiner wrote:
> >
> > > * Thorsten Greiner <[EMAIL PROTECTED]> [2003-08-01 23:47]:
> > > > I will test wether the problem still occurs with version 1.84 of
> > > > s
On 2003-08-02 00:20 +0200, Thorsten Greiner wrote:
> * Daniel Eischen <[EMAIL PROTECTED]> [2003-08-02 00:06]:
> > I think the bug was in the old code allowing this to
> > happen...
>
> Well, than someone should tell that to NVidia. Their driver is
> closed source and comes without "user servicable
* Daniel Eischen <[EMAIL PROTECTED]> [2003-08-02 00:06]:
> I think the bug was in the old code allowing this to
> happen...
Well, than someone should tell that to NVidia. Their driver is
closed source and comes without "user servicable parts".
Regards
-Thorsten
--
There are 10 kinds of
On Fri, 1 Aug 2003, Daniel Eischen wrote:
> On Fri, 1 Aug 2003, Thorsten Greiner wrote:
>
> > * Thorsten Greiner <[EMAIL PROTECTED]> [2003-08-01 23:47]:
> > > I will test wether the problem still occurs with version 1.84 of
> > > sys_machdep.c and let you know.
> >
> > Yup, reverting to 1.84 u
On Fri, 1 Aug 2003, Thorsten Greiner wrote:
> * Thorsten Greiner <[EMAIL PROTECTED]> [2003-08-01 23:47]:
> > I will test wether the problem still occurs with version 1.84 of
> > sys_machdep.c and let you know.
>
> Yup, reverting to 1.84 unbreaks this for me. Looking at the changes
> made it appea
* Thorsten Greiner <[EMAIL PROTECTED]> [2003-08-01 23:47]:
> I will test wether the problem still occurs with version 1.84 of
> sys_machdep.c and let you know.
Yup, reverting to 1.84 unbreaks this for me. Looking at the changes
made it appears to me that the check
if (uap->start < NLDT ||
* Julian Elischer <[EMAIL PROTECTED]> [2003-08-01 23:44]:
> can you compile your sys_machdep.c with the option -DDEBUG?
>
> I noticed there is a debug printf that is enabled byu this and may show
> what request the NVIDIA people are making.
This is what gets logged:
Aug 1 23:42:43 tybalt kernel
On Fri, 1 Aug 2003, Thorsten Greiner wrote:
> Hi,
>
> after upgrading the Kernel I found that the glx-related programs of
> the NVidia graphics driver die in calls to sysarch. Here is a truss
> fragment of a 'glxinfo' run:
>
> sysarch(0x1,0xbfbffb14)ERR#22 'Inva
Hi,
after upgrading the Kernel I found that the glx-related programs of
the NVidia graphics driver die in calls to sysarch. Here is a truss
fragment of a 'glxinfo' run:
sysarch(0x1,0xbfbffb14) ERR#22 'Invalid argument'
SIGNAL 10
SIGNAL 10
Process stopped because of: 16
p
36 matches
Mail list logo
