On Thu, 2007-04-26 at 11:04 -0400, Alan Stern wrote:
> On Thu, 26 Apr 2007, Joerg Schilling wrote:
>
> > 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?
>
>
On Thu, 26 Apr 2007, Joerg Schilling wrote:
> 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 has signed off on the patch. There doesn't appear to have
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
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
On Thu, 26 Apr 2007, Joerg Schilling wrote:
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 has signed off on the patch. There doesn't appear to have
On Thu, 2007-04-26 at 11:04 -0400, Alan Stern wrote:
On Thu, 26 Apr 2007, Joerg Schilling wrote:
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
On Mon, 2007-04-02 at 16:23 +0200, Jens Axboe wrote:
> FWIW, it had my ack, I think we were just waiting for Doug to ack the sg
> bits.
And there's really nothing I can do (well, except write the thing) since
the changes are not in any SCSI pieces I maintain directly ... they're
block and sg.
On Mon, Apr 02 2007, Alan Stern wrote:
> On Mon, 2 Apr 2007, Joerg Schilling wrote:
>
> > 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
On Mon, 2 Apr 2007, Joerg Schilling wrote:
> 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.
Me too. I submitted the most recent
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
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
On Mon, 2 Apr 2007, Joerg Schilling wrote:
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.
Me too. I submitted the most recent version of
On Mon, Apr 02 2007, Alan Stern wrote:
On Mon, 2 Apr 2007, Joerg Schilling wrote:
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.
On Mon, 2007-04-02 at 16:23 +0200, Jens Axboe wrote:
FWIW, it had my ack, I think we were just waiting for Doug to ack the sg
bits.
And there's really nothing I can do (well, except write the thing) since
the changes are not in any SCSI pieces I maintain directly ... they're
block and sg.
On Mon, 19 Feb 2007, Douglas Gilbert wrote:
> > Come to think of it, the reserved_size value used when a new sg device is
> > created should also be capped at max_sectors * 512. Agreed? I can't see
> > any reason for ever having a larger buffer -- it would be impossible to
> > make use of the
On Mon, 19 Feb 2007, Douglas Gilbert wrote:
Come to think of it, the reserved_size value used when a new sg device is
created should also be capped at max_sectors * 512. Agreed? I can't see
any reason for ever having a larger buffer -- it would be impossible to
make use of the extra
Alan Stern wrote:
> On Mon, 19 Feb 2007, Douglas Gilbert wrote:
>
>> Alan,
>> The SG_GET_RESERVED_SIZE ioctl is also defined in
>> the block layer, see block/scsi_ioctl.c .
>
> Ah, I didn't know that. (Or more likely, I used to know and have since
> forgotten.) Thanks for pointing it out.
>
On Mon, 19 Feb 2007, Douglas Gilbert wrote:
> Alan,
> The SG_GET_RESERVED_SIZE ioctl is also defined in
> the block layer, see block/scsi_ioctl.c .
Ah, I didn't know that. (Or more likely, I used to know and have since
forgotten.) Thanks for pointing it out.
> I suspect it is just a kludge
Alan Stern wrote:
> On Mon, 19 Feb 2007, Joerg Schilling wrote:
>
>> 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
On Mon, 19 Feb 2007, Joerg Schilling wrote:
> 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.
> >
> >
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
On Sun, 18 Feb 2007, Joerg Schilling wrote:
> 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
On Sun, 18 Feb 2007, Joerg Schilling wrote:
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
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 like
On Mon, 19 Feb 2007, Joerg Schilling wrote:
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
Alan Stern wrote:
On Mon, 19 Feb 2007, Joerg Schilling wrote:
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.
On Mon, 19 Feb 2007, Douglas Gilbert wrote:
Alan,
The SG_GET_RESERVED_SIZE ioctl is also defined in
the block layer, see block/scsi_ioctl.c .
Ah, I didn't know that. (Or more likely, I used to know and have since
forgotten.) Thanks for pointing it out.
I suspect it is just a kludge to
Alan Stern wrote:
On Mon, 19 Feb 2007, Douglas Gilbert wrote:
Alan,
The SG_GET_RESERVED_SIZE ioctl is also defined in
the block layer, see block/scsi_ioctl.c .
Ah, I didn't know that. (Or more likely, I used to know and have since
forgotten.) Thanks for pointing it out.
I suspect
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
On Sat, 17 Feb 2007, Douglas Gilbert 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
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
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 should
apply to any
On Sat, 17 Feb 2007, Douglas Gilbert 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 should
apply to
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
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 should
>> apply to any driver using a request_queue, even
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
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 bits are fine
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 should
apply to any driver using a request_queue, even if the driver
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 should
> apply to any driver using a request_queue, even if the driver doesn't
>
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 should
apply to any driver using a request_queue, even if the driver doesn't
implement a block-device interface. The
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 should
apply to any driver using a request_queue, even if the driver doesn't
implement a block-device interface. The prototypical
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 should
apply to any driver using a request_queue, even if the driver doesn't
42 matches
Mail list logo
