Hello.
Could you help me with such a question.
A have sis180 and raid0 on two sata disks. In windows all works: simply give it
a driver and I have access to the raid like to an ordinary disk (nothing to
think about). But when I try linux, I obtain two disks (sdb and sdc, for
exaple) and interest
On Mon, 1 Jan 2007 18:36:24 -0800
Jeremy Higdon <[EMAIL PROTECTED]> wrote:
> I have a DVD combo drive and a CD in which the
> "READ TRACK INFORMATION" command (implemented in the
> cdrom_get_track_info() function) takes about 7 seconds to run.
> The current implementation of cdrom_get_track_info()
* Kill _OFS suffixes in ATA_ID_{SERNO|FW_REV|PROD}_OFS for consistency
with other ATA_ID_* constants.
* Kill ATA_SERNO_LEN
* Add and use ATA_ID_SERNO_LEN, ATA_ID_FW_REV_LEN and ATA_ID_PROD_LEN.
This change also makes ata_device_blacklisted() use proper length
for fwrev.
Signed-off-by: Teju
There were several places where ATA ID strings are manually terminated
and in some places possibly unterminated strings were passed to string
functions which don't limit length like strstr(). This patch converts
all of them over to ata_id_c_string().
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
-
'hdparm -I' doesn't work with ATAPI devices and sg_sat is not widely
spread yet leaving no easy way to access ATAPI IDENTIFY data.
Implement HDIO_GET_IDENTITY such that at least 'hdparm -i' works.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/libata-scsi.c | 43 ++
The last one was 3/3 of course.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jan 02 2007, Alan wrote:
> On Mon, 1 Jan 2007 18:36:24 -0800
> Jeremy Higdon <[EMAIL PROTECTED]> wrote:
>
> > I have a DVD combo drive and a CD in which the
> > "READ TRACK INFORMATION" command (implemented in the
> > cdrom_get_track_info() function) takes about 7 seconds to run.
> > The c
On Tue, 2 Jan 2007 08:01:45 +0100
Herbert Poetzl <[EMAIL PROTECTED]> wrote:
> if you are interested in investigating this, please
> let me know what kind of data you would like to see
> and/or what kind of tests would be appreciated.
I reviewed the 374 code a bit further to see what might be caus
When the old IDE layer calls into methods in the driver during error
handling it is essentially random whether ide_lock is already held. This
causes a deadlock in the atiixp driver which also uses ide_lock internally
for locking.
Switch to a private lock instead.
Signed-off-by: Alan Cox <[EMAIL
Tejun Heo wrote:
'hdparm -I' doesn't work with ATAPI devices and sg_sat is not widely
spread yet leaving no easy way to access ATAPI IDENTIFY data.
Implement HDIO_GET_IDENTITY such that at least 'hdparm -i' works.
Mmm.. I still think this old ioctl is ugly, and I'd rather
have things fixed so t
Mark Lord wrote:
> Tejun Heo wrote:
>> 'hdparm -I' doesn't work with ATAPI devices and sg_sat is not widely
>> spread yet leaving no easy way to access ATAPI IDENTIFY data.
>> Implement HDIO_GET_IDENTITY such that at least 'hdparm -i' works.
>
> Mmm.. I still think this old ioctl is ugly, and I'd
Tejun Heo wrote:
Mark Lord wrote:
..
hdparm *does* try to issue the PACKET IDENTIFY whenever
a regular IDENTIFY fails. Currently these all go through
the HDIO_DRIVE_CMD ioctl(). I don't have a system set up
here that has any ATAPI over libata to test with.
Could you perhaps try and see where
On 12/30/06, Sergei Shtylyov <[EMAIL PROTECTED]> wrote:
Fix minor coding mistake in the HPT36x PCI clock detection code noticed by
Bartlomiej Zolnierkiewicz -- it always reported 33 MHz due to the missing
'break' statements. This, however, most probably never mattered -- in fact,
I was thinking
Hi.
I wanted to try the two patches you've sent against the current
2.6.20-rc3, but there have been numerous changes to the files
so neither patch can apply cleanly. I'm not familiar enough
with the libata to try and make similar changes to the current
files to match your patch. :-(
Any possiblit
(pardon the duplicate posting -- just trying to get it into the correct thread).
Tejun Heo wrote:
Mark Lord wrote:
Tejun Heo wrote:
..
Support for IDENTIFY PACKET DEVICE would be nice too.
It already does that, using HDIO_DRIVE_CMD to retrieve it
in the same way as for regular IDENTIFY DEVIC
Tejun Heo wrote:
Mark Lord wrote:
Tejun Heo wrote:
..
Support for IDENTIFY PACKET DEVICE would be nice too.
It already does that, using HDIO_DRIVE_CMD to retrieve it
in the same way as for regular IDENTIFY DEVICE commands.
Hmmm... My hdparm doesn't seem to do that.
# hdparm -V
hdparm v6.9
This patch adds support for passing ATA_12 and ATA_16 commands
through to ATAPI devices in libata. In practice, the upper layers will
still currently prevent ATA_16 commands, as no (?) ATAPI drives support
them yet. But it will work if such a drive is ever encountered.
This patch is necessary fo
Resending with fixed Subject line:
On Tuesday 02 January 2007 17:30, Mark Lord wrote:
> This patch adds support for passing ATA_12 and ATA_16 commands
> through to ATAPI devices in libata. In practice, the upper layers will
> still currently prevent ATA_16 commands, as no (?) ATAPI drives support
Hello.
Could you help me with such a question.
A have sis180 and raid0 on two sata disks. In windows all works: simply give it a driver
and I have access to the raid like to an ordinary disk (nothing to think about). But when
I try linux, I obtain two disks (sdb and sdc, for exaple) and interes
Existing ATAPI devices do not support 16-byte commands,
so issuing ATA_16 against them gets rejected by the upper layers.
This patch updates the libata implementations of HDIO_DRIVE_CMD
and HDIO_DRIVE_TASK to use ATA_12 (rather than ATA_16) so that
they can now also be used for ATAPI devices.
Sig
Mark Lord wrote:
This patch adds support for passing ATA_12 and ATA_16 commands
through to ATAPI devices in libata. In practice, the upper layers will
still currently prevent ATA_16 commands, as no (?) ATAPI drives support
them yet. But it will work if such a drive is ever encountered.
This pa
Jeff Garzik wrote:
Mark Lord wrote:
..
Allow ATA_12 / ATA_16 passthru commands to be issued for ATAPI devices
Douglas Gilbert noticed this a while ago.
The patch's technical content is fine, but there is an open policy
question: For some devices, there is an opcode overlap (BLANK? Doug
p
Mark Lord wrote:
Jeff Garzik wrote:
Mark Lord wrote:
..
Allow ATA_12 / ATA_16 passthru commands to be issued for ATAPI devices
..
Mmmm.. yes, the "BLANK" opcode is indeed the same as ATA_12.
Yup, BLANK is commonly used with CD-RW software (cdrecord, k3b, ..),
so we cannot translate ATA_12
Mark Lord wrote:
Existing ATAPI devices do not support 16-byte commands,
so issuing ATA_16 against them gets rejected by the upper layers.
This patch updates the libata implementations of HDIO_DRIVE_CMD
and HDIO_DRIVE_TASK to use ATA_12 (rather than ATA_16) so that
they can now also be used for
This patch adds support for passing ATA_16 commands
through to ATAPI devices in libata. In practice, the upper layers will
still currently prevent ATA_16 commands, as no (?) ATAPI drives support
them yet. But it will work if such a drive is ever encountered.
Support for ATA_16 is necessary for u
On Tuesday 02 January 2007 19:39, Mark Lord wrote:
> This patch adds support for passing ATA_16 commands
> through to ATAPI devices in libata. In practice, the upper layers will
> still currently prevent ATA_16 commands, as no (?) ATAPI drives support
> them yet. But it will work if such a drive
With recent kernels (and possibly much older ones, too),
ioctl() calls for ATAPI devices never make it to the driver layers.
The reason for this is a borked return code test in drivers/scsi/sr.c.
This patch fixes it.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- old/drivers/scsi/sr.c
Mark Lord wrote:
With recent kernels (and possibly much older ones, too),
ioctl() calls for ATAPI devices never make it to the driver layers.
The reason for this is a borked return code test in drivers/scsi/sr.c.
This patch fixes it.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- old/dr
Jeff Garzik wrote:
Mark Lord wrote:
...
ret = cdrom_ioctl(file, &cd->cdi, inode, cmd, arg);
-if (ret != ENOSYS)
+if (ret != -ENOSYS)
I think Tejun posted the same patch earlier today.
Ahh.. missed it -- could have saved me an hour or two of debugging!
Cheers!
-
To unsubscribe
In an ideal world, we would use the existing ATA_12 opcode
to issue 12-byte ATA passthrough commands for libata ATAPI drives
from userspace.
But ATA_12 happens to have the same SCSI opcode value as the older
CD/RW "BLANK" command, widely used by cdrecord and friends.
So, to achieve ATA passthru c
Mark Lord wrote:
This patch adds support for passing ATA_16 commands
through to ATAPI devices in libata. In practice, the upper layers will
still currently prevent ATA_16 commands, as no (?) ATAPI drives support
them yet. But it will work if such a drive is ever encountered.
Support for ATA_16
> I do not wish to completely eliminate the current behavior, which passes
> through all opcodes to the ATAPI device. You cannot guarantee that
> ATA_16 is never used for a vendor-reserved opcode, for example.
For 16 byte commands via SG_IO you know the command is 16 bytes long as
the command l
Alan wrote:
I do not wish to completely eliminate the current behavior, which passes
through all opcodes to the ATAPI device. You cannot guarantee that
ATA_16 is never used for a vendor-reserved opcode, for example.
For 16 byte commands via SG_IO you know the command is 16 bytes long as
the c
Tejun Heo wrote:
> Please apply the attached patch over 2.6.19 and report what the kernel says.
>
> Thanks.
>
I got the following errors during the timeout when running hald:
ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.01: cmd a0/00:00:00:00:20/00:00:00:00:00/b0 tag 0
Art Haas wrote:
> Hi.
>
> I wanted to try the two patches you've sent against the current
> 2.6.20-rc3, but there have been numerous changes to the files
> so neither patch can apply cleanly. I'm not familiar enough
> with the libata to try and make similar changes to the current
> files to match
Mark Lord wrote:
> Mark Lord wrote:
>> Jeff Garzik wrote:
>>> Mark Lord wrote:
>> ..
Allow ATA_12 / ATA_16 passthru commands to be issued for ATAPI devices
> ..
>> Mmmm.. yes, the "BLANK" opcode is indeed the same as ATA_12.
>
> Yup, BLANK is commonly used with CD-RW software (cdrecord, k3b,
Matthew Stapleton wrote:
> Tejun Heo wrote:
>> Please apply the attached patch over 2.6.19 and report what the kernel says.
>>
>> Thanks.
>>
>
> I got the following errors during the timeout when running hald:
>
> ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> ata1.01: cmd a0/
On Tue, 2007-01-02 at 19:35 -0500, Mark Lord wrote:
> In an ideal world, we would use the existing ATA_12 opcode
> to issue 12-byte ATA passthrough commands for libata ATAPI drives
> from userspace.
>
> But ATA_12 happens to have the same SCSI opcode value as the older
> CD/RW "BLANK" command, wid
James Bottomley wrote:
..
I don't think I quite understand what you're trying to do here. My
understanding is that ATA_12 and ATA_16 are part of the SAT layer. i.e.
they're used when we're speaking SCSI to an underlying ATA device to
send taskfiles. However, ATAPI devices don't use SAT ... ever
Alan wrote:
I do not wish to completely eliminate the current behavior, which passes
through all opcodes to the ATAPI device. You cannot guarantee that
ATA_16 is never used for a vendor-reserved opcode, for example.
For 16 byte commands via SG_IO you know the command is 16 bytes long as
the c
Jeff Garzik wrote:
Mark Lord wrote:
This patch adds support for passing ATA_16 commands
through to ATAPI devices in libata. In practice, the upper layers will
still currently prevent ATA_16 commands, as no (?) ATAPI drives support
them yet. But it will work if such a drive is ever encountered.
On Wednesday 03 January 2007 00:47, Mark Lord wrote:
> Jeff Garzik wrote:
> > As I said, provide some avenue for the user to choose.
This patch isn't really needed, but it might provide an "out"
just in case somebody has some really non-compliant hardware
out there someday.
Add a boot/module para
On Wednesday 03 January 2007 01:01, Mark Lord wrote:
>..
> This patch isn't really needed, but it might provide an "out"
> just in case somebody has some really non-compliant hardware
> out there someday.
>
> Add a boot/module parameter for libata to force the ATA_16
> SCSI opcode to not be interp
On 1/2/07, Alan <[EMAIL PROTECTED]> wrote:
When the old IDE layer calls into methods in the driver during error
handling it is essentially random whether ide_lock is already held. This
causes a deadlock in the atiixp driver which also uses ide_lock internally
for locking.
Switch to a private loc
On Tue, Jan 02, 2007 at 02:50:53PM +0100, Jens Axboe wrote:
> Yep, I suspect this patch is long overdue. Jeremy, is this enough to fix
> it for you?
Yes, the 7 second timeout is fine. It actually takes about 6.7 seconds.
I guess if "another popular OS" has a 7 second timeout that we won't find
mu
[cc'ing linux-ide]
bbee wrote:
> Tejun Heo gmail.com> writes:
>> Andrew Lyon wrote:
>>> My system is gigabyte ds3 motherboard with onboard SATA JMicron
>>> 20360/20363 AHCI Controller (rev 02), drive connected is WDC
>>> WD740ADFD-00 20.0, I am running 2.6.18.6 32 bit, under heavy i/o I get
>>> t
On Wed, 3 Jan 2007, Tejun Heo wrote:
bbee wrote:
Tejun Heo gmail.com> writes:
Andrew Lyon wrote:
ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0)
Is this condition dangerous?
Not usually. Might indicate something is going wrong in some really
rare cases. I think ve
bbee wrote:
>> Yeap, I have major issues with SDB FISes which contains spurious
>> completions but most other spurious interrupts shouldn't be dangerous
>> and I haven't seen spurious completions for quite some time, so I was
>> thinking either removing the message or printing it only on SDB FIS
>>
This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19
with patches available
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any othe
49 matches
Mail list logo
