In message [EMAIL PROTECTED], Christian T. Steigies writes:
On Tue, Oct 09, 2001 at 10:11:36PM +0100, [EMAIL PROTECTED] wrote:
Can you run it under gdb and see where it crashes? It would be
interesting to see the output of objdump -r on libbitmap.a and
libpcidata.a, too.
Sure, logfiles at:
In message [EMAIL PROTECTED], Christian T. Steigies writes:
On Tue, Oct 09, 2001 at 10:11:36PM +0100, [EMAIL PROTECTED] wrote:
Can you run it under gdb and see where it crashes? It would be
interesting to see the output of objdump -r on libbitmap.a and
libpcidata.a, too.
Sure, logfiles at:
On Sun, Oct 21, 2001 at 06:14:33PM +0100, Philip Blundell wrote:
In message [EMAIL PROTECTED], Christian T. Steigies writes:
On Tue, Oct 09, 2001 at 10:11:36PM +0100, [EMAIL PROTECTED] wrote:
Can you run it under gdb and see where it crashes? It would be
interesting to see the output of
Hmm. Must be an intermittent thing. I ran it in the debugger, and it
came up just fine!
Ah. That's a sure sign that it's missing some cache flushing operations.
But in the meantime... I can log in via gdm, and run GNOME and
Enlightenment, with ripples, and transparent gnome-terminal,
Hmm. Must be an intermittent thing. I ran it in the debugger, and it
came up just fine!
Ah. That's a sure sign that it's missing some cache flushing operations.
But in the meantime... I can log in via gdm, and run GNOME and
Enlightenment, with ripples, and transparent gnome-terminal, and
Guess what... it built! (Had to split it among the two local
partitions and put relatively inactive stuff on NFS.) So the patches
were successful that far; they're at:
Adam C Powell IV wrote:
Christian T. Steigies wrote:
On Tue, Oct 09, 2001 at 04:04:51PM -0400, Adam C Powell IV wrote:
FBIOPUT_VSCREENINFO: Invalid argument
That looks like a good error, in the sense that I don't think it's at all
related to the ELF loader. Instead you seem to have some kind of fbcon
problem. I think this can happen if you are trying to start up X in a
different colour depth to the one you
In message [EMAIL PROTECTED], Adam C Powell IV writes:
Next question: why can't I have 16-bit? fbset -depth 16 gives me the
same error.
I don't know. The kernel experts hang out on
[EMAIL PROTECTED]; try asking them there.
p.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
In message [EMAIL PROTECTED], Adam C Powell IV writes:
Ah, yes. You're right. If I tell it 8-bit, then it gets past that, and
gets signal 4 later, after setting up the mouse. Oh well. Config and
log at the same place as last time. But yes, the ELF loader might just
be working... :-)
[EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Adam C Powell IV writes:
Ah, yes. You're right. If I tell it 8-bit, then it gets past that, and
gets signal 4 later, after setting up the mouse. Oh well. Config and
log at the same place as last time. But yes, the ELF loader might
On Fri, 2001-10-12 at 00:48, Adam C Powell IV wrote:
Okay, out of six attempts, it has signal 4'd twice, one of those with
gpm off.
We used to get seemingly non-deterministic signal 4s on PPC when the
cache flushing code in the loader was broken.
--
Earthling Michel Dänzer (MrCooper)/
Guess what... it built! (Had to split it among the two local
partitions and put relatively inactive stuff on NFS.) So the patches
were successful that far; they're at:
Adam C Powell IV wrote:
Christian T. Steigies wrote:
On Tue, Oct 09, 2001 at 04:04:51PM -0400, Adam C Powell IV wrote:
FBIOPUT_VSCREENINFO: Invalid argument
That looks like a good error, in the sense that I don't think it's at all
related to the ELF loader. Instead you seem to have some kind of fbcon
problem. I think this can happen if you are trying to start up X in a
different colour depth to the one you
Philip Blundell wrote:
FBIOPUT_VSCREENINFO: Invalid argument
That looks like a good error, in the sense that I don't think it's at all
related to the ELF loader. Instead you seem to have some kind of fbcon
problem. I think this can happen if you are trying to start up X in a
different
In message [EMAIL PROTECTED], Adam C Powell IV writes:
Next question: why can't I have 16-bit? fbset -depth 16 gives me the
same error.
I don't know. The kernel experts hang out on
[EMAIL PROTECTED]; try asking them there.
p.
In message [EMAIL PROTECTED], Adam C Powell IV writes:
Ah, yes. You're right. If I tell it 8-bit, then it gets past that, and
gets signal 4 later, after setting up the mouse. Oh well. Config and
log at the same place as last time. But yes, the ELF loader might just
be working... :-)
[EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Adam C Powell IV writes:
Ah, yes. You're right. If I tell it 8-bit, then it gets past that, and
gets signal 4 later, after setting up the mouse. Oh well. Config and
log at the same place as last time. But yes, the ELF loader might
On Fri, 2001-10-12 at 00:48, Adam C Powell IV wrote:
Okay, out of six attempts, it has signal 4'd twice, one of those with
gpm off.
We used to get seemingly non-deterministic signal 4s on PPC when the
cache flushing code in the loader was broken.
--
Earthling Michel Dänzer (MrCooper)/
Okay, I give up. I've tried several times to build this package, and
each time it's failed, because of something having nothing to do with
the package itself. I got some patches together, and after a couple of
early mistakes they've built just fine -- and work with -7 too. But at
some
In message [EMAIL PROTECTED], Adam C Powell IV writes:
and 600a from debian/held-patches. No rocket science here, I just had
to tweak it a bit to use the inx/outx prototypes from libc, specifically
sys/io.h. The last two differ from what's there now only in line
Whoa, this is dangerous
In message [EMAIL PROTECTED], Christian T. Steigies writes:
Do you know if these patches could help makeing the m68k elfloader work?
What's the problem with the m68k elfloader, exactly? All the technology
you need should already exist in binutils and glibc, so it's just an
integration problem.
Christian T. Steigies wrote:
On Tue, Oct 09, 2001 at 04:04:51PM -0400, Adam C Powell IV wrote:
So, could someone else please take my patches and build and upload X for
us? They're at:
http://lyre.mit.edu/~powell/debs/311_arm_compiler_h.diff
In message [EMAIL PROTECTED], Christian T. Steigies writes:
No big problem, only that it does not work. Log follows (I know 4.0.2 is
old, but it hasn't changed since then)
XFree86 Version 4.0.2 / X Window System
(protocol Version 11, revision 0, vendor release 6400)
Release Date: 18 December
Okay, I give up. I've tried several times to build this package, and
each time it's failed, because of something having nothing to do with
the package itself. I got some patches together, and after a couple of
early mistakes they've built just fine -- and work with -7 too. But at
some
In message [EMAIL PROTECTED], Adam C Powell IV writes:
and 600a from debian/held-patches. No rocket science here, I just had
to tweak it a bit to use the inx/outx prototypes from libc, specifically
sys/io.h. The last two differ from what's there now only in line
Whoa, this is dangerous talk.
In message [EMAIL PROTECTED], Christian T. Steigies writes:
Do you know if these patches could help makeing the m68k elfloader work?
What's the problem with the m68k elfloader, exactly? All the technology
you need should already exist in binutils and glibc, so it's just an
integration problem.
On Tue, Oct 09, 2001 at 09:20:38PM +0100, [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Christian T. Steigies writes:
Do you know if these patches could help makeing the m68k elfloader work?
What's the problem with the m68k elfloader, exactly? All the technology
you need should
Christian T. Steigies wrote:
On Tue, Oct 09, 2001 at 04:04:51PM -0400, Adam C Powell IV wrote:
So, could someone else please take my patches and build and upload X for
us? They're at:
http://lyre.mit.edu/~powell/debs/311_arm_compiler_h.diff
In message [EMAIL PROTECTED], Christian T. Steigies writes:
No big problem, only that it does not work. Log follows (I know 4.0.2 is
old, but it hasn't changed since then)
XFree86 Version 4.0.2 / X Window System
(protocol Version 11, revision 0, vendor release 6400)
Release Date: 18 December 2000
[EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Adam C Powell IV writes:
and 600a from debian/held-patches. No rocket science here, I just had
to tweak it a bit to use the inx/outx prototypes from libc, specifically
sys/io.h. The last two differ from what's there now only in line
On Tue, Oct 09, 2001 at 04:04:51PM -0400, Adam C Powell IV wrote:
If I try to debian/rules build after it fails in the middle, it seems
to do a make clean or something similar which removes all of the
previously-built libraries and object files. So the previous progress
is lost.
In the
On Tue, Oct 09, 2001 at 10:11:36PM +0100, [EMAIL PROTECTED] wrote:
Can you run it under gdb and see where it crashes? It would be
interesting to see the output of objdump -r on libbitmap.a and
libpcidata.a, too.
Sure, logfiles at:
http://people.debian.org/~cts/x4.1/
Note, this version of
Adam C Powell IV wrote:
The new patch is at
http://lyre.mit.edu/~powell/debs/311_arm_elfloader.diff
D'oh! Forgot about patch application order, put in as number 311 it
interferes with other patches (#400 in particular) and causes the build
to fail due to patch offsets.
So, change of
Greetings,
I have made a new ARM elfloader patch based on held-patches/600 and
600a. So those held patches are obsolete. A thorough reading of
held-patch 612_arm_elfloader.diff indicates that too is obsolete.
The new patch is at http://lyre.mit.edu/~powell/debs/311_arm_elfloader.diff
Adam C Powell IV wrote:
The new patch is at
http://lyre.mit.edu/~powell/debs/311_arm_elfloader.diff
D'oh! Forgot about patch application order, put in as number 311 it
interferes with other patches (#400 in particular) and causes the build
to fail due to patch offsets.
So, change of
35 matches
Mail list logo
