> changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the
> following error from wodim:
> Errno: 0 (Success), write_g1 scsi sendcmd: no error
> CDB: 2A 00 00 00 00 00 00 00 1F 00
> status: 0x2 (CHECK CONDITION)
> Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> >This fragment is much too short to allow to judge on possible reasons.
> >There is a high probability that your problem is caused by the cdrecord
> >fork called "wodim".
> >
> [...]
> >
> >As a general advise: if you have problems, always first try rece
>From [EMAIL PROTECTED] Tue Oct 17 01:14:32 2000
>1.8.1. A ricoh 9060 on a machine running identical kernel build /
>cdrecord binary works fine>
>I just finished compiling cdrecord-1.8.1 with debug enabled. The two
>attached log files are from the hp7100i / smp / 2.2.18pre15, and the
>ricoh 90
Jens Axboe <[EMAIL PROTECTED]> wrote:
> > This will make it possible for cdrecord and related programs to
> > retrieve reliably the max_sectors value, regardless of whether the
> > user points it to an sr or an sg device. In particular, this will
> > resolve Bugzilla entry #7026.
>
> The block bi
Douglas Gilbert <[EMAIL PROTECTED]> wrote:
> Jens Axboe wrote:
> > On Fri, Feb 16 2007, Alan Stern wrote:
> >> From: James Bottomley <[EMAIL PROTECTED]>
> >>
> >> This patch (as854) separates out the two queue-oriented ioctls from
> >> the rest of the block-layer ioctls. The idea is that they sho
Alan Stern <[EMAIL PROTECTED]> wrote:
> > Alternatively the SG_GET_RESERVED_SIZE ioctl could be
> > modified to yield no more than max_sectors*512 .
>
> There should be one single ioctl which can be applied uniformly to all
> CD-type devices (in fact, to all devices using a request_queue) to learn
Alan Stern <[EMAIL PROTECTED]> wrote:
> Well, if Doug wants to reduce the value returned by SG_GET_RESERVED_SIZE,
> it's okay with me. An advantage of doing this is that older versions of
> cdrecord would then work correctly.
>
> However you don't seem to realize that people can use programs li
>CD recording : recorder no longer detected by "wodim" software set in
>2.6.19. I suspect it's a bug in the software... but don't know where
>to look for changes. 2.6.19-rc5 worked.
>hardware: IDE MATSHITADVD-RAM UJ-820S
>(2.6.19-git6 also fails with external LiteON USB DVD burner)
I recommen
Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 14 2006, Joerg Schilling wrote:
> > >CD recording : recorder no longer detected by "wodim" software set in
> > >2.6.19. I suspect it's a bug in the software... but don't know where
> > >
Hi all,
you might know that since ~ 2 years, the Sun Studio compilers
are available for Linux. Given the fact that they typically produce
faster code than GCC and that they offer more debug/optimizing features,
they are worth testing.
While it is no problem to use Sun Studio for non-Linux-specif
[EMAIL PROTECTED] wrote:
> On Fri, 22 Jun 2007, Joerg Schilling wrote:
>
> > Is there some hope that at least the Linux kernel interface definition
> > files and
> > everything recursively included from these files will be rewritten in
> > vanilla
> > ANSI
[EMAIL PROTECTED] wrote:
> On Fri, 22 Jun 2007, Joerg Schilling wrote:
>
> > Is there some hope that at least the Linux kernel interface definition
> > files and
> > everything recursively included from these files will be rewritten in
> > vanilla
> > ANSI
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> > Cdrtools ftp://ftp.berlios.de/pub/cdrecord/alpha/ offer support for an OS
> > dependent SCSI transport. Cdrtools cannot be compiled wihout support for
> > SCSI
> > transport, so it is impossible to use Sun Studio to compile cdrtools.
> >
> > Wh
Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> On Friday 22 June 2007, [EMAIL PROTECTED] wrote:
> > this has been discussed many times and the answer is that the kernel is
> > not gong to change it's side of things to ANSI C.
>
> I don't think that's entirely true with regard to the include files.
>
David Woodhouse <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-06-22 at 01:38 +0200, Joerg Schilling wrote:
> > The main problems are not really hard to fix..
> >
> > - Most problems eem to be related to the fact that Linux does not
> > use C-99 based ty
Harald Arnesen <[EMAIL PROTECTED]> wrote:
> David Woodhouse <[EMAIL PROTECTED]> writes:
>
> >> > Can you be more specific about why this is a problem? Don't
> >> > we mostly define those crappy types using arch-specific knowledge, as
> >> > 'int', 'long', etc?
> >>
> >> I recommend you to instal
Harald Arnesen <[EMAIL PROTECTED]> wrote:
> Harald Arnesen <[EMAIL PROTECTED]> writes:
>
> > [EMAIL PROTECTED] (Joerg Schilling) writes:
> >
> >>> If I actually install smake, as Jörg recommends, the message becomes:
> >>> smake: Can't f
Harald Arnesen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Joerg Schilling) writes:
>
> >> FYI, cdrtools also compile and link fine with Sun's C compiler.
> >
> > M, if you call "cdrecord -scanbus", what do you get?
>
> I may have mis
>> It is probably about time that cdparanoia was updated ...
>I think the same, but given that it works, Monty probably doesn't
>have much motivation to update it. I don't know if the problem resides
>in the cdparanoia program itself (so using the DAE problem from cdrkit
>will fix the issue) o
>It is probably about time that cdparanoia was updated ...
>Doug Gilbert
Cdparanoia was not updated since 2001. The here important low level code is
still the same as with cdda2wav from 1997.
For this reason, I did create a portable libparanoia from the assets of the
cdparanoia code and also
DervishD <[EMAIL PROTECTED]> wrote:
> Hi Joerg :)
> > Do not try to replace one dead program by another one
>
> Do you mean cdrkit?
Correct.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTE
Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 25, 2007 at 04:53:55PM +0200, Joerg Schilling wrote:
> >
> > star needs "ext2_fs.h". This file is not usable at all on many Linux
> > distributions, even with GCC.
>
> I was curious so I did:
Harald Arnesen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Joerg Schilling) writes:
>
> >> If I actually install smake, as Jörg recommends, the message becomes:
> >> smake: Can't find any source for 'CCOM_suncc'.
> >> smake: Couldn't
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > Personally, I think that's a load of bollocks. And it certainly doesn't
> > apply to Linux-specific files like , which are perfectly
> > entitled to use a C standard from last millennium, regardless of
> > namespace 'pollution' issues. That's why we conti
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> That's a good point I missed.
>
> What about:
>
> #if defined(__GNUC__) && __STDC_VERSION__ < 19901L
> __extension__ typedef signed long long __s64;
> __extension__ typedef unsigned long long __u64;
> #else
> typedef signed long long __s64;
> typedef un
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > On Suse Linux 10.0, I get e.g.:
> >
> > cat t.c
> > #include
> > #include
> >
> > gcc -c t.c
> > In file included from /usr/include/linux/ext2_fs.h:20,
> > from t.c:2:
> > /usr/include/linux/ext2_fs_sb.h:40: error: syntax error before
David Woodhouse <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-06-27 at 16:00 +0200, Joerg Schilling wrote:
> > Warning: *** linux/ext2_fs.h is not usable at all ***
> > Warning: *** This makes it impossible to support Linux file flags ***
> > You may try to compile usin
David Woodhouse <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote:
> > David Woodhouse <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, 2007-06-27 at 16:00 +0200, Joerg Schilling wrote:
> > > > Warning: *** linux/ex
Harald Arnesen <[EMAIL PROTECTED]> wrote:
> Adrian Bunk <[EMAIL PROTECTED]> writes:
>
> > Is there any userspace Linux compiler that does not support "long long"?
> > If yes, is there any other way to tell that something is a
> > 64bit int on 32bit architectures?
>
> TenDRA C:
>
> "test.c", line 6
Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > gcc -c t.c
> > In file included from /usr/include/linux/ext2_fs.h:20,
> > from t.c:2:
> > /usr/include/linux/ext2_fs_sb.h:40: error: syntax error before âuid_tâ
> > /usr/include/linux/ext2_fs_sb.h:49: error: syntax error before
> > âs_n
Willy Tarreau <[EMAIL PROTECTED]> wrote:
> Jörg,
>
> On Thu, Jun 28, 2007 at 12:39:57PM +0200, Joerg Schilling wrote:
> > David Woodhouse <[EMAIL PROTECTED]> wrote:
> >
> > > On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote:
> > > > D
Willy Tarreau <[EMAIL PROTECTED]> wrote:
>
> > Jörg
> [advertisements removed]
Please stop this kind of trolling, you did not remove anything here,
so do not claim to remove things
As you don't seem to know the nettiquette:
If you believe you have some kind of problems that was used by the
Any chance to that this bug will be fixed anytime soon?
The Bug has been reported February 2004 but is still not fixed in sg.c
Is Linux development really so slow?
Douglas Gilbert <[EMAIL PROTECTED]> wrote:
> Alan,
> The SG_GET_RESERVED_SIZE ioctl is also defined in
> the block layer, see b
Hi,
this is a repost as I like to know the current state of the problem...
The USB DMA size problem is known to exist on Linux since February 2004.
I am still in hope that there will be a fix soon.
/*--*/
Alan Stern <[EMAIL
> That's true now, but it wasn't always. Until the last year or so,
> cdrecord wouldn't work properly with USB CD drives having a 64-sector
> limit unless the user added a particular command-line argument.
This is a bug that is known since ~ 3 years and that has been fixed
_very_ recently. I
35 matches
Mail list logo
