Bug#360561: [cl-debian] Bug#360561: cmucl: CMUCL does not run under kernel version 2.6.16
Don Geddis
I'm running Debian as a "testing" installation with the simple packages
linux-image-2.6-686-smp
cmucl
So for cmucl I get version 19c-release-20051115-2. But the linux image for
2.6 recently upgraded in testing to 2.6.16-2-686-smp. And of course cmucl
now fails to start with
Couldn't mmap at 0xbe000000, len 1048576; got mapping at 0xa7cfe000
insteadensure_space: Failed to validate 1048576 bytes at 0xbe000000
So what's the current status? CMUCL is WONTFIX, and the kernel folks claim
the same thing? Nobody cares that the application and the kernel are no
longer compatible?
At the very least, surely this means that the Debian CMUCL now needs some
kind of new "Required:" package, to document that it is not (and will not be)
compatible with the default 2.6 kernel.
-- Don
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Peter Van Eynde
Alle Monday 24 July 2006 19:27, Don Geddis ha scritto:
> So what's the current status? CMUCL is WONTFIX, and the kernel folks claim
> the same thing? Nobody cares that the application and the kernel are no
> longer compatible?
I'm not going to create a separate memory layout for debian just because a
non-standard kernel is used. The problem is still present the testing kernel
2.4.17-1-686, I updated to BTS entry of bug #360598 to this effect.
> At the very least, surely this means that the Debian CMUCL now needs some
> kind of new "Required:" package, to document that it is not (and will not
be)
> compatible with the default 2.6 kernel.
I'm open to suggestions on what I should 'require'. ;-)
Groetjes, Peter
--
signature -at- pvaneynd.mailworks.org
http://www.livejournal.com/users/pvaneynd/
"God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|
Don Geddis
> I'm not going to create a separate memory layout for debian just because a
> non-standard kernel is used.
I understand the conflict, that it appears the kernel guys did make an
unintentional error. Nevertheless, I find the phrase "non-standard kernel"
to be suspect. If a user tries to install the default linux-2.6 kernel in
Debian ("testing"), this is the "standard" kernel that they get.
This bug doesn't appear to bother most applications. Moreover, the kernel
guys (while admitting an error) seem to claim that this kind of change is
permitted by their API contract.
Finally, Carl Shapiro suggests that CMUCL's current memory layout is an odd
accident, and he has a simple patch to reorder the memory (on all platforms?)
which happens to solve this problem and also make CMUCL compatible with
Debian kernel 2.6.16.
Given all of that, it seems like the right solution is to change CMUCL to be
immune to these kinds of kernel changes. Although I can appreciate it if you
would prefer to wait until a new 19d release of CMUCL from upstream, rather
than making a Debian-specific patch to the CMUCL source.
> I'm open to suggestions on what I should 'require'. ;-)
Well, hopefull this is only a short-term issue. I don't really know the
Debian package syntax, but can't you can something like "requires
linux-image-2.4, or linux-image-2.6 with version <= 2.6.15"?
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
I don't use drugs; my dreams are frightening enough. -- M. C. Escher
Peter Van Eynde
> I understand the conflict, that it appears the kernel guys did make an
> unintentional error. Nevertheless, I find the phrase "non-standard kernel"
> to be suspect. If a user tries to install the default linux-2.6 kernel in
> Debian ("testing"), this is the "standard" kernel that they get.
I was unclear. I meant 'unmodified kernel from kernel.org with default
options'. We had a similar problem a few years back when redhat decided to go
for a 2/2 G split in memory. The cmucl maintainers ignored bugreports about
this and redhat reversed the patch in the end.
> This bug doesn't appear to bother most applications. Moreover, the kernel
> guys (while admitting an error) seem to claim that this kind of change is
> permitted by their API contract.
Could you point me to that contract so I can check other assumptions made. As
someone who got bitten numerous times by glibc's changing semantics I would
appreciate such a document and to my knowledge it does not exist.
> Finally, Carl Shapiro suggests that CMUCL's current memory layout is an odd
> accident, and he has a simple patch to reorder the memory (on all
platforms?)
> which happens to solve this problem and also make CMUCL compatible with
> Debian kernel 2.6.16.
I can see what the solution would be but there are technical and cultural
problems with it, basicly the debian package would be 'different' from a
normal cmucl and this is often enough reason to distrust bug reports from
debian users.
> > I'm open to suggestions on what I should 'require'. ;-)
>
> Well, hopefull this is only a short-term issue. I don't really know the
> Debian package syntax, but can't you can something like "requires
> linux-image-2.4, or linux-image-2.6 with version <= 2.6.15"?
This would only require a specific version of the kernel to be installed,
there is no general way to say 'this package only runs with kernels < 2.6.15
and > 2.7.17-5 (I hope).
Ralf Mattes
> [... schnip ...]
> I can see what the solution would be but there are technical and cultural
> problems with it, basicly the debian package would be 'different' from a
> normal cmucl and this is often enough reason to distrust bug reports from
> debian users.
>
This is a _very_ good point!
> > > I'm open to suggestions on what I should 'require'. ;-)
> >
> > Well, hopefull this is only a short-term issue. I don't really know the
> > Debian package syntax, but can't you can something like "requires
> > linux-image-2.4, or linux-image-2.6 with version <= 2.6.15"?
>
> This would only require a specific version of the kernel to be installed,
> there is no general way to say 'this package only runs with kernels < 2.6.15
> and > 2.7.17-5 (I hope).
Well, isn't this a job for the 'Conflicts' section. Of course this would
only protect the user from installing a not-working kernel image but
those who compile their own kernels should know what they do.
Cheers, Ralf Mattes
> Groetjes, Peter
Don Geddis
>> I can see what the solution would be but there are technical and cultural
>> problems with it, basicly the debian package would be 'different' from a
>> normal cmucl and this is often enough reason to distrust bug reports from
>> debian users.
Ralf Mattes <r...@seid-online.de> wrote on Wed, 26 Jul 2006:
> This is a _very_ good point!
In this case, upstream has fixed this bug (for all platforms). In a
(near-term) future release [19d?], the memory layout is more logical, and
cmucl should no longer have this conflict with the debian kernel.
In addition, since the change affects all platforms, there doesn't need to be
any fear that the debian package is "different" from a "normal" cmucl.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
I made dinner. We didn't have any Hamburger, so it's just Helper.
-- "Gabe", Penny Arcade