Re: 2.4.10ac10, cdrecord 1.9-6, Mitsumi CR-4804TE: lock up burning too large image

[Ville Herva <vherva@niksula.hut.fi>]

On Sun, Oct 21, 2001 at 01:56:06PM +0200, you [Joerg Schilling] claimed:
> 
> >Hmm. It used to work with 2.2-kernel. With too large image, it just gave an
> >error.
> 
> I may only judge from information you provide, not from information you hide.

I did say that in the original report:

"It used to give a nice error when disk size was exceeded with 2.2.18pre19
and a tad older cdrecord..."

but I could have been clearer.
 
> 1.10 is outdated too, please read
> 
> http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/problems.html

Ok. I'll compile the newest from source.

But do you think the too-large-image lock up might be cured with a newer
cdrecord, or should is the kernel the prime suspect?

I will try anyway and report back to you.
 
> >with 2.2 ("failed to mmap /dev/null" or something) so I went back to 1.9. I
> 
> I cannot prevent you from broken Linux installations!
> 
> The linux kernel people still have propblems with interfaces and make
> thanges that break binary compatibility when going to more recent Linux
> versions. Why do you believe that a cdrecord that has been compiled on 2.4
> will run on 2.2?

Well, most software software seems to work with both 2.2 and 2.4. I didn't
think carefully enough to realize that some interfaces must have changed.
 
> Linux needed close to 10 years to finally support mmap() (ther OS like
> SunOS did this since 1987). Cdrecord's outoconf chooses the best
> interfaces of the OS. SVS shared mem is outdated and badly implemented on
> Linux (too many restrictions). mmap is the modern method to get shared
> memory but Linux didn't support is before November 2000.

I see. Thanks for the clarification.


-- v --

v@iki.fi