> Just to make sure I'm not misunderstanding it. So, PDC202xx will lock
> up if you transfer allocation size, reset and then try to drain, but
> it's okay to keep draining as part of continued PIO transfer, right?
The following hang mine:
PIO transfer
Reset state machine
Alan Cox wrote:
> On Mon, 05 Nov 2007 09:05:48 +0900
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> Alan Cox wrote:
Maybe we could set a limit here. If the ATAPI device keeps DRQ=1 and
exceeds the limit, we consider it as HSM violation and have EH handle it.
>>> On a DMA transfer its
Alan Cox wrote:
On Mon, 05 Nov 2007 09:05:48 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Alan Cox wrote:
Maybe we could set a limit here. If the ATAPI device keeps DRQ=1 and
exceeds the limit, we consider it as HSM violation and have EH handle it.
On a DMA transfer its basically out of our
Just to make sure I'm not misunderstanding it. So, PDC202xx will lock
up if you transfer allocation size, reset and then try to drain, but
it's okay to keep draining as part of continued PIO transfer, right?
The following hang mine:
PIO transfer
Reset state machine
On Mon, 05 Nov 2007 09:05:48 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> >> Maybe we could set a limit here. If the ATAPI device keeps DRQ=1 and
> >> exceeds the limit, we consider it as HSM violation and have EH handle it.
> >
> > On a DMA transfer its basically out of our
On Mon, 05 Nov 2007 09:05:48 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Alan Cox wrote:
Maybe we could set a limit here. If the ATAPI device keeps DRQ=1 and
exceeds the limit, we consider it as HSM violation and have EH handle it.
On a DMA transfer its basically out of our control (and a
Tejun Heo wrote:
However, there's still remaining issues. What does happen if you raise
allocation length and buffersize of the test program to 16? ie. Change
0x0a in cmd[] to 0x10 and increase buffer[10] to buffer[16].
Eek. The process hangs in D state for a good 60 seconds or so.
Caught a
Alan Cox wrote:
>> Maybe we could set a limit here. If the ATAPI device keeps DRQ=1 and
>> exceeds the limit, we consider it as HSM violation and have EH handle it.
>
> On a DMA transfer its basically out of our control (and a PIO drain will
> lock some controllers solid until power cycle),
Do
> Maybe we could set a limit here. If the ATAPI device keeps DRQ=1 and
> exceeds the limit, we consider it as HSM violation and have EH handle it.
On a DMA transfer its basically out of our control (and a PIO drain will
lock some controllers solid until power cycle), but on PIO we know we
never
Maybe we could set a limit here. If the ATAPI device keeps DRQ=1 and
exceeds the limit, we consider it as HSM violation and have EH handle it.
On a DMA transfer its basically out of our control (and a PIO drain will
lock some controllers solid until power cycle), but on PIO we know we
never set
Alan Cox wrote:
Maybe we could set a limit here. If the ATAPI device keeps DRQ=1 and
exceeds the limit, we consider it as HSM violation and have EH handle it.
On a DMA transfer its basically out of our control (and a PIO drain will
lock some controllers solid until power cycle),
Do such
Tejun Heo wrote:
However, there's still remaining issues. What does happen if you raise
allocation length and buffersize of the test program to 16? ie. Change
0x0a in cmd[] to 0x10 and increase buffer[10] to buffer[16].
Eek. The process hangs in D state for a good 60 seconds or so.
Caught a
Tejun Heo wrote:
> Daniel Drake wrote:
>
>>Tejun Heo wrote:
>>
<4>ata2.00: HSM violation: eh_analyze_tf: BUSY|DRQ
<3>ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
<3>ata2.00: cmd a0/00:00:00:0a:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data
10 in
<4> res
Daniel Drake wrote:
> Tejun Heo wrote:
>>> <4>ata2.00: HSM violation: eh_analyze_tf: BUSY|DRQ
>>> <3>ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
>>> <3>ata2.00: cmd a0/00:00:00:0a:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data
>>> 10 in
>>> <4> res
Tejun Heo wrote:
<4>ata2.00: HSM violation: eh_analyze_tf: BUSY|DRQ
<3>ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
<3>ata2.00: cmd a0/00:00:00:0a:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data
10 in
<4> res 58/00:02:00:0a:00/00:00:00:00:00/a0 Emask 0x2 (HSM
violation)
Tejun Heo wrote:
Does this patch fix the problem?
[snip]
I hope it does... that patch removes a call to sg_last() and in general
cleans up the function a bit, which is nice.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Tejun Heo wrote:
Does this patch fix the problem?
[snip]
I hope it does... that patch removes a call to sg_last() and in general
cleans up the function a bit, which is nice.
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Tejun Heo wrote:
4ata2.00: HSM violation: eh_analyze_tf: BUSY|DRQ
3ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
3ata2.00: cmd a0/00:00:00:0a:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data
10 in
4 res 58/00:02:00:0a:00/00:00:00:00:00/a0 Emask 0x2 (HSM
violation)
3ata2.00:
Daniel Drake wrote:
Tejun Heo wrote:
4ata2.00: HSM violation: eh_analyze_tf: BUSY|DRQ
3ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
3ata2.00: cmd a0/00:00:00:0a:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data
10 in
4 res 58/00:02:00:0a:00/00:00:00:00:00/a0 Emask 0x2 (HSM
Tejun Heo wrote:
Daniel Drake wrote:
Tejun Heo wrote:
4ata2.00: HSM violation: eh_analyze_tf: BUSY|DRQ
3ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
3ata2.00: cmd a0/00:00:00:0a:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data
10 in
4 res 58/00:02:00:0a:00/00:00:00:00:00/a0
Daniel Drake wrote:
> Tejun Heo wrote:
>> Yeap, the SG command is fine. The drive is being weird tho. The
>> allocation length field says 10 bytes, so it should just have
>> transferred 10 bytes without causing HSM violation.
>>
>> Can you please apply the attached patch and report what the
Tejun Heo wrote:
Yeap, the SG command is fine. The drive is being weird tho. The
allocation length field says 10 bytes, so it should just have
transferred 10 bytes without causing HSM violation.
Can you please apply the attached patch and report what the kernel says
after triggering the error
Daniel Drake wrote:
Again, ignore me if I'm not contributing anything useful, but I'm
increasingly thinking that the SG_IO command block in question is
perfectly valid, and doing a short read of the mode page in question
(and probably others too) is in fact required before you can know its
Daniel Drake wrote:
Again, ignore me if I'm not contributing anything useful, but I'm
increasingly thinking that the SG_IO command block in question is
perfectly valid, and doing a short read of the mode page in question
(and probably others too) is in fact required before you can know its
Tejun Heo wrote:
Yeap, the SG command is fine. The drive is being weird tho. The
allocation length field says 10 bytes, so it should just have
transferred 10 bytes without causing HSM violation.
Can you please apply the attached patch and report what the kernel says
after triggering the error
Daniel Drake wrote:
Tejun Heo wrote:
Yeap, the SG command is fine. The drive is being weird tho. The
allocation length field says 10 bytes, so it should just have
transferred 10 bytes without causing HSM violation.
Can you please apply the attached patch and report what the kernel says
Alan Cox wrote:
>> "one size" that you can supply to the SG_IO command (unless you want to
>> use a stupidly large buffer) to retrieve all the data at once. Instead,
>> as Tejun describes, you put a short read request in first, look at byte
>> 1 of the page which tells you the length, and then
Daniel Drake wrote:
> Alan Cox wrote:
>> Lots of *other* problems occur instead. Daniel is reporting that if he
>> makes a stupid request to a buggy drive he gets a reset and the system
>> continues happily. Even that reset being a reset not a new command issue
>> is actually us being excessively
> "one size" that you can supply to the SG_IO command (unless you want to
> use a stupidly large buffer) to retrieve all the data at once. Instead,
> as Tejun describes, you put a short read request in first, look at byte
> 1 of the page which tells you the length, and then read the whole lot.
Alan Cox wrote:
Lots of *other* problems occur instead. Daniel is reporting that if he
makes a stupid request to a buggy drive he gets a reset and the system
continues happily. Even that reset being a reset not a new command issue
is actually us being excessively paranoid.
Sorry if I'm
> We are both half-right. I reverted my version of that completely,
> applied your version verbatim, and pushed it upstream. The result:
> atapi_xlat _did_ start programming lbam/lbah for DMA (another behavior
> change), but request-sense DMA path was not changed to program lba[mh]
> for
Alan Cox wrote:
demonstrated by (a) Alan's patch did not change DMA lbam/lbah
programming and (b) Daniel's report of the message "ata2.00: 66 bytes
(a) did. Well the original did, dunno about your version.
We are both half-right. I reverted my version of that completely,
applied your
> demonstrated by (a) Alan's patch did not change DMA lbam/lbah
> programming and (b) Daniel's report of the message "ata2.00: 66 bytes
(a) did. Well the original did, dunno about your version.
> I am not drawing any conclusions yet, but I'm thinking that blimit=8k
> may be a better choice
O> Hmmm reading ide-cd.c::cdrom_pc_intr(). OIC, ide-cd is dealing with
> this problem by draining PIO after BMDMA engine is done. This is
> possible for BMDMA engines as they simply step out when the SG entries
> are exhausted; then, the interrupt handler kicks in and drains the
> left-over
Ok, gave this a hard look.
This is basically a behavior change with regards to how we program the
bcount(low) and bcount(high) registers.
Issues about FIFO draining and devices returning too-much data are
ultimately tangential. Furthermore, this is an ATAPI PIO issue, as
demonstrated by
Tejun Heo wrote:
> Hello, Jeff.
>
> Jeff Garzik wrote:
>> That's easy for the PIO case. But CD writing is normally DMA, which
>> means you will get a DMA engine exception if the device wants to give
>> you more data than the scatter/gather entries permit.
>
> For sense data and mode pages, the
Tejun Heo wrote:
Hello, Jeff.
Jeff Garzik wrote:
That's easy for the PIO case. But CD writing is normally DMA, which
means you will get a DMA engine exception if the device wants to give
you more data than the scatter/gather entries permit.
For sense data and mode pages, the
Ok, gave this a hard look.
This is basically a behavior change with regards to how we program the
bcount(low) and bcount(high) registers.
Issues about FIFO draining and devices returning too-much data are
ultimately tangential. Furthermore, this is an ATAPI PIO issue, as
demonstrated by
O Hmmm reading ide-cd.c::cdrom_pc_intr(). OIC, ide-cd is dealing with
this problem by draining PIO after BMDMA engine is done. This is
possible for BMDMA engines as they simply step out when the SG entries
are exhausted; then, the interrupt handler kicks in and drains the
left-over using
demonstrated by (a) Alan's patch did not change DMA lbam/lbah
programming and (b) Daniel's report of the message ata2.00: 66 bytes
(a) did. Well the original did, dunno about your version.
I am not drawing any conclusions yet, but I'm thinking that blimit=8k
may be a better choice for
Alan Cox wrote:
demonstrated by (a) Alan's patch did not change DMA lbam/lbah
programming and (b) Daniel's report of the message ata2.00: 66 bytes
(a) did. Well the original did, dunno about your version.
We are both half-right. I reverted my version of that completely,
applied your
We are both half-right. I reverted my version of that completely,
applied your version verbatim, and pushed it upstream. The result:
atapi_xlat _did_ start programming lbam/lbah for DMA (another behavior
change), but request-sense DMA path was not changed to program lba[mh]
for DMA.
I
Alan Cox wrote:
Lots of *other* problems occur instead. Daniel is reporting that if he
makes a stupid request to a buggy drive he gets a reset and the system
continues happily. Even that reset being a reset not a new command issue
is actually us being excessively paranoid.
Sorry if I'm
one size that you can supply to the SG_IO command (unless you want to
use a stupidly large buffer) to retrieve all the data at once. Instead,
as Tejun describes, you put a short read request in first, look at byte
1 of the page which tells you the length, and then read the whole lot.
ATAPI
Daniel Drake wrote:
Alan Cox wrote:
Lots of *other* problems occur instead. Daniel is reporting that if he
makes a stupid request to a buggy drive he gets a reset and the system
continues happily. Even that reset being a reset not a new command issue
is actually us being excessively paranoid.
Alan Cox wrote:
one size that you can supply to the SG_IO command (unless you want to
use a stupidly large buffer) to retrieve all the data at once. Instead,
as Tejun describes, you put a short read request in first, look at byte
1 of the page which tells you the length, and then read the
Hello, Jeff.
Jeff Garzik wrote:
> That's easy for the PIO case. But CD writing is normally DMA, which
> means you will get a DMA engine exception if the device wants to give
> you more data than the scatter/gather entries permit.
For sense data and mode pages, the standard-sanctioned way to
On Wed, Oct 31 2007, Jeff Garzik wrote:
> Jens Axboe wrote:
> >Right, that's of course problematic... There has to be a way to recover
> >that situation though, or you can't export any user command issue
> >facility.
>
> You cannot hope to handle all possible effects arising from an app
>
Jeff Garzik wrote:
Jens Axboe wrote:
Right, that's of course problematic... There has to be a way to recover
that situation though, or you can't export any user command issue
facility.
You cannot hope to handle all possible effects arising from an app
providing an invalid sg header / cdb.
> If this is NOT a privileged app, we must update the command validation
> to ensure that invalid commands are not transported to the hardware.
We allow only a subset of standard commands to be issued by unprivileged
applications. We don't strictly enforce transfer sizes and its arguable
on SCSI
Jens Axboe wrote:
Right, that's of course problematic... There has to be a way to recover
that situation though, or you can't export any user command issue
facility.
You cannot hope to handle all possible effects arising from an app
providing an invalid sg header / cdb.
Once you start
On Wed, Oct 31 2007, Jeff Garzik wrote:
> Jens Axboe wrote:
>> On Wed, Oct 31 2007, Alan Cox wrote:
>>> On Tue, 30 Oct 2007 19:21:29 +
>>> Daniel Drake <[EMAIL PROTECTED]> wrote:
>>>
Alan Cox wrote:
> I would guess Brasero is issuing a command with the length of data
> wrongly
> > Would need to double check the SCSI specificatons to be sure but I think
> > you are asking for less data than the drive wishes to provide. You
> > aren't allowed to do that with ATA.
>
> ide-cd handles this by throwing the excess away, which I think is the
> sane way to do this.
It also
Jens Axboe wrote:
On Wed, Oct 31 2007, Alan Cox wrote:
On Tue, 30 Oct 2007 19:21:29 +
Daniel Drake <[EMAIL PROTECTED]> wrote:
Alan Cox wrote:
I would guess Brasero is issuing a command with the length of data
wrongly set. In the old code that might well just produce errors of the
"Umm
On Wed, Oct 31 2007, Alan Cox wrote:
> On Tue, 30 Oct 2007 19:21:29 +
> Daniel Drake <[EMAIL PROTECTED]> wrote:
>
> > Alan Cox wrote:
> > > I would guess Brasero is issuing a command with the length of data
> > > wrongly set. In the old code that might well just produce errors of the
> > >
On Tue, 30 Oct 2007 19:21:29 +
Daniel Drake <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> > I would guess Brasero is issuing a command with the length of data
> > wrongly set. In the old code that might well just produce errors of the
> > "Umm wtf is this data left over for ?", with the new
On Tue, 30 Oct 2007 19:21:29 +
Daniel Drake [EMAIL PROTECTED] wrote:
Alan Cox wrote:
I would guess Brasero is issuing a command with the length of data
wrongly set. In the old code that might well just produce errors of the
Umm wtf is this data left over for ?, with the new code the
On Wed, Oct 31 2007, Alan Cox wrote:
On Tue, 30 Oct 2007 19:21:29 +
Daniel Drake [EMAIL PROTECTED] wrote:
Alan Cox wrote:
I would guess Brasero is issuing a command with the length of data
wrongly set. In the old code that might well just produce errors of the
Umm wtf is this
Jens Axboe wrote:
On Wed, Oct 31 2007, Alan Cox wrote:
On Tue, 30 Oct 2007 19:21:29 +
Daniel Drake [EMAIL PROTECTED] wrote:
Alan Cox wrote:
I would guess Brasero is issuing a command with the length of data
wrongly set. In the old code that might well just produce errors of the
Umm wtf
Would need to double check the SCSI specificatons to be sure but I think
you are asking for less data than the drive wishes to provide. You
aren't allowed to do that with ATA.
ide-cd handles this by throwing the excess away, which I think is the
sane way to do this.
It also fails for
On Wed, Oct 31 2007, Jeff Garzik wrote:
Jens Axboe wrote:
On Wed, Oct 31 2007, Alan Cox wrote:
On Tue, 30 Oct 2007 19:21:29 +
Daniel Drake [EMAIL PROTECTED] wrote:
Alan Cox wrote:
I would guess Brasero is issuing a command with the length of data
wrongly set. In the old code that might
Jens Axboe wrote:
Right, that's of course problematic... There has to be a way to recover
that situation though, or you can't export any user command issue
facility.
You cannot hope to handle all possible effects arising from an app
providing an invalid sg header / cdb.
Once you start
Jeff Garzik wrote:
Jens Axboe wrote:
Right, that's of course problematic... There has to be a way to recover
that situation though, or you can't export any user command issue
facility.
You cannot hope to handle all possible effects arising from an app
providing an invalid sg header / cdb.
If this is NOT a privileged app, we must update the command validation
to ensure that invalid commands are not transported to the hardware.
We allow only a subset of standard commands to be issued by unprivileged
applications. We don't strictly enforce transfer sizes and its arguable
on SCSI
On Wed, Oct 31 2007, Jeff Garzik wrote:
Jens Axboe wrote:
Right, that's of course problematic... There has to be a way to recover
that situation though, or you can't export any user command issue
facility.
You cannot hope to handle all possible effects arising from an app
providing an
Hello, Jeff.
Jeff Garzik wrote:
That's easy for the PIO case. But CD writing is normally DMA, which
means you will get a DMA engine exception if the device wants to give
you more data than the scatter/gather entries permit.
For sense data and mode pages, the standard-sanctioned way to know
Alan Cox wrote:
I would guess Brasero is issuing a command with the length of data
wrongly set. In the old code that might well just produce errors of the
"Umm wtf is this data left over for ?", with the new code the drive is
likely to change state as it knows the transfer size and that will
> The nutty app I was using for burning is Brasero, a GNOME app which does
> some SG_IO directly with the drive. (I guess it has some bad error
> handling and doesn't realise when some I/O path has failed)
I would guess Brasero is issuing a command with the length of data
wrongly set. In the
Daniel Drake wrote:
> I have narrowed down the exact command submission which causes those
> nasty messages in dmesg. The function which submits this is named
> "brasero_medium_get_page_2A_write_speed_desc".
Just as an extra data point...
I've compiled the test program an ran it on my
Alan Cox wrote:
Not immediately - but if you've got wrong transfer lengths its a
candidate for this.
Ok lets start with the basics
If you mount a CD and use it does it work
Yep.
If you use cdrecord does it work ?
Yep (tested with wodim from debburn, effectively the same thing)
What
> > Any ideas?
>
> hrm
>
> we may need to make that controller-specific, given that the code prior
> to 2db78dd302d26d242d3e8e5c4c5024b6c3ea93c2 was working for most...
Removing it breaks some devices on any controller.
I don't think this one is a simple compatibility issue - its a behaviour
Daniel Drake wrote:
Hi Alan,
In 2.6.23 and previous, CD writing works fine on my system. I'm using
ata_piix on:
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA
IDE Controller (rev 01)
When I'm running CD writing utilities, I sometimes see this message in
the
Hi Alan,
In 2.6.23 and previous, CD writing works fine on my system. I'm using
ata_piix on:
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA
IDE Controller (rev 01)
When I'm running CD writing utilities, I sometimes see this message in
the kernel logs:
On Tue, 30 Oct 2007 15:14:39 +
Daniel Drake <[EMAIL PROTECTED]> wrote:
> Hi Alan,
>
> In 2.6.23 and previous, CD writing works fine on my system. I'm using
> ata_piix on:
>
> 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA
> IDE Controller (rev 01)
>
> When I'm
On Tue, 30 Oct 2007 15:14:39 +
Daniel Drake [EMAIL PROTECTED] wrote:
Hi Alan,
In 2.6.23 and previous, CD writing works fine on my system. I'm using
ata_piix on:
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA
IDE Controller (rev 01)
When I'm running CD
Hi Alan,
In 2.6.23 and previous, CD writing works fine on my system. I'm using
ata_piix on:
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA
IDE Controller (rev 01)
When I'm running CD writing utilities, I sometimes see this message in
the kernel logs:
Daniel Drake wrote:
Hi Alan,
In 2.6.23 and previous, CD writing works fine on my system. I'm using
ata_piix on:
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA
IDE Controller (rev 01)
When I'm running CD writing utilities, I sometimes see this message in
the
Any ideas?
hrm
we may need to make that controller-specific, given that the code prior
to 2db78dd302d26d242d3e8e5c4c5024b6c3ea93c2 was working for most...
Removing it breaks some devices on any controller.
I don't think this one is a simple compatibility issue - its a behaviour
we have
Alan Cox wrote:
Not immediately - but if you've got wrong transfer lengths its a
candidate for this.
Ok lets start with the basics
If you mount a CD and use it does it work
Yep.
If you use cdrecord does it work ?
Yep (tested with wodim from debburn, effectively the same thing)
What
Daniel Drake wrote:
I have narrowed down the exact command submission which causes those
nasty messages in dmesg. The function which submits this is named
brasero_medium_get_page_2A_write_speed_desc.
Just as an extra data point...
I've compiled the test program an ran it on my ICH7/Pentium D
The nutty app I was using for burning is Brasero, a GNOME app which does
some SG_IO directly with the drive. (I guess it has some bad error
handling and doesn't realise when some I/O path has failed)
I would guess Brasero is issuing a command with the length of data
wrongly set. In the old
Alan Cox wrote:
I would guess Brasero is issuing a command with the length of data
wrongly set. In the old code that might well just produce errors of the
Umm wtf is this data left over for ?, with the new code the drive is
likely to change state as it knows the transfer size and that will
82 matches
Mail list logo
