headers
Jeff Garzik | 1 Jun 2007 01:26
Favicon

Re: Compact Flash performance...

Mark Lord wrote:
> To maximize throughput, some kind of host-queuing would be needed,
> or just have the driver sit in a tight loop, starting the next I/O
> immediately when the previous one finishes.  Linux isn't that quick (yet).

I was talking on IRC with Tejun just recently.  There are several 
controllers (and/or "situations") like this, where some amount of host 
queueing would permit greater throughput, even when NCQ is not 
supported.  sata_sx4 is the most dramatic example, where host queueing 
could potentially increase speed by a factor of 10 or more, since it is 
penalized by an awful two-irq-per-command (w/ a per-host bottleneck to 
boot) setup.  Silicon Image has a "command buffer".  And overall, I 
designed ->qc_prep() hook separate from ->qc_issue() to enable the 
prepartion of multiple commands such that it only takes a simple "go" 
I/O to start a transaction, immediately after the previous one ends.

	Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Daniel J Blueman | 1 Jun 2007 01:47
Picon

Re: Compact Flash performance...

Hi Mark,

On 31/05/07, Mark Lord <liml <at> rtr.ca> wrote:
> Daniel J Blueman wrote:
> > On 31/05/07, Mark Lord <liml <at> rtr.ca> wrote:
> >> Daniel J Blueman wrote:
> >> > Whoops, yes. Here is the expected data:
> > [snip]
> >>
> >> Thanks.  I'll use that data to update/validate future versions of hdparm.
> >> At UDMA66, it *should* be capable of the 40MByte/sec realm of readback
> >> perf,
> >> assuming the card itself is really that fast.
> >
> > hdparm in the other identify mode does list the UDMA3/4 modes twice
> > [1], which looks odd.
> >
> >> I don't know too much about the specifics, though, but perhaps the
> >> card is only capable of full speed in PIO6, which requires special
> >> cabling
> >> and is currently unsupported in libata (?).
> >
> > Seems less likely, as the Extreme IV reader (and another) supports
> > UDMA mode 4; in PIO mode 6, they apparently top out at 17MB/s [2],
> > which seems reasonable.
> >
> >> Another factor, is that hdparm performs discrete, non-overlapping,
> >> reads of 1MByte chunks for its timing test.  Some drives cannot achieve
> >> full performance with such (relatively) large gaps between IO's.
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Hancock | 1 Jun 2007 02:00
Picon
Favicon

Re: Compact Flash performance...

Jeff Garzik wrote:
> Mark Lord wrote:
>> To maximize throughput, some kind of host-queuing would be needed,
>> or just have the driver sit in a tight loop, starting the next I/O
>> immediately when the previous one finishes.  Linux isn't that quick 
>> (yet).
> 
> 
> I was talking on IRC with Tejun just recently.  There are several 
> controllers (and/or "situations") like this, where some amount of host 
> queueing would permit greater throughput, even when NCQ is not 
> supported.  sata_sx4 is the most dramatic example, where host queueing 
> could potentially increase speed by a factor of 10 or more, since it is 
> penalized by an awful two-irq-per-command (w/ a per-host bottleneck to 
> boot) setup.  Silicon Image has a "command buffer".  And overall, I 
> designed ->qc_prep() hook separate from ->qc_issue() to enable the 
> prepartion of multiple commands such that it only takes a simple "go" 
> I/O to start a transaction, immediately after the previous one ends.
> 
>     Jeff

Theoretically NVIDIA nForce4 ADMA could likely do this as well, as it 
seems to allow chaining up multiple commands to execute in succession 
(assuming they're not NCQ)..

--

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr <at> nospamshaw.ca
Home Page: http://www.roberthancock.com/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tejun Heo | 1 Jun 2007 02:58
Picon

Re: Linux v2.6.22-rc3

Hello, Linus.  Sorry about late response.  I'm still recovering from jet
lag.

Linus Torvalds wrote:
> On Tue, 29 May 2007, Tejun Heo wrote:
>> Aieee, so the drive doesn't like the new SRST sequence.
> 
> It would appear that the old code largely ignored the SRST error entirely, 
> no?

Yes, we used to ignore some error conditions, which sometimes led to
very long timeout sequence after hotplugging under certain circumstances
- a few 30sec timeouts for the reset and another 30sec for the following
IDENTIFY (because reset didn't fail after the timeouts).

> If we *used* to do (in ata_bus_post_reset()):
> 
> 	if (dev0)
> 		ata_busy_sleep(ap, ATA_TMOUT_BOOT_QUICK, ATA_TMOUT_BOOT);
> 
> and you changed that to actually care about the return value:
> 
> 	if (dev0) {
> 		rc = ata_wait_ready(ap, deadline);
> 		if (rc && rc != -ENODEV)
> 			return rc;
> 	}
> 
> (in _two_ places). That change also changed the same "post_reset" handling 
> in a totally _different_ way: it used to do ata_busy_sleep() twice, now it
(Continue reading)

Permalink | Reply | 24 comments |
headers
Linus Torvalds | 1 Jun 2007 03:37
Gravatar

Re: Linux v2.6.22-rc3


On Fri, 1 Jun 2007, Tejun Heo wrote:
>
> Gregor's cdrom has broken SRST support which is extremely rare and
> broken.

Well, the concept is neither rare nor arguably all that broken. 

The paper standards floating around in the industry are so much toilet 
paper. The only standard that seems to really matter is what Windows has 
traditionally done. We may not like it, but there it is...

This bites us more when it comes to the real el-cheapo stuff, notably when 
it comes to various USB mass storage things (which have some random 
USB->flash controller cobbled together by a senile llama on crack), and is 
almost unheard of for anythign that is "server-grade", but when it comes 
to no-brand random devices, it really does tend to be the case that the 
only testing they ever had was using Windows.

And hardware is seldom any different from software: if it wasn't tested, 
it probably doesn't work.

So it would be good if somebody knew what the Windows ID/startup sequence 
was/is. I think we figured it out by trial-and-error for the USB mass 
storage stuff. But it tends to boil down to: don't do things that aren't 
absolutely required (for SCSI, it was things like not asking for mode 
pages that weren't absolutely required, because some devices wouldn't 
support it, and would simply lock up if you did so!)

			Linus
(Continue reading)

Permalink | Reply | 22 comments |
headers
Tejun Heo | 1 Jun 2007 04:19
Picon

Re: Linux v2.6.22-rc3

Hello,

Linus Torvalds wrote:
> On Fri, 1 Jun 2007, Tejun Heo wrote:
>> Gregor's cdrom has broken SRST support which is extremely rare and
>> broken.
> 
> Well, the concept is neither rare nor arguably all that broken. 
> 
> The paper standards floating around in the industry are so much toilet 
> paper. The only standard that seems to really matter is what Windows has 
> traditionally done. We may not like it, but there it is...
> 
> This bites us more when it comes to the real el-cheapo stuff, notably when 
> it comes to various USB mass storage things (which have some random 
> USB->flash controller cobbled together by a senile llama on crack), and is 
> almost unheard of for anythign that is "server-grade", but when it comes 
> to no-brand random devices, it really does tend to be the case that the 
> only testing they ever had was using Windows.
> 
> And hardware is seldom any different from software: if it wasn't tested, 
> it probably doesn't work.

Yeap, agreed.  SRST on PATA works on most devices tho.  This device is
the first reported one which genuinely doesn't like SRST itself but we
also had a case where a device doesn't report proper diagnostic code and
another one which reports incorrect device class code.

Hardreset on SATA works better because it's much more integral part of
the protocol.  SRST also seems to work better but there is an emulated
(Continue reading)

Permalink | Reply | 20 comments |
headers
俞琳 | 1 Jun 2007 04:20

Re: YuLin: Where can I get the newest source of sata_sis?

Uwe Koziolek 写道:
>> hi,
>>
>> When we used 2.6.18 and 2.6.20 on ASUS sis-671 motherboard, We have some
>> problem: cannot find the harddisk controller.
>> In BIOS, the SATA mode is 2P+2IDE.
>>
>> The official kernel 2.6.18, 2.6.20 and new 2.6.21 does not work, i get
>> some information about sata_sis 0.7.1 from you, may I get it ?
>>
>> We are so urgent, please help me.
>>
>> Thank you very much!!!!
>>     
> Asus is selling a P5X-MX SE motherboard with a SiS968
> southbridge. The SiS671 Northbridge is not intresting for the SATA-support.
> Currently it is only planned to support this chipset in
> AHCI-mode. You should select the AHCI mode for the SATA-ports in the
> BIOS. The ahci driver should support your board.
> kernel 2.6.20 should be sufficient.
> If this does not work, please provide the output of
> lspci -vvxxx and the selected mode for the SATA-port.
>
> regards
> Uwe Koziolek
>
>
>
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
俞琳 | 1 Jun 2007 06:26

Re: YuLin: Where can I get the newest source of sata_sis?

Uwe Koziolek 写道:
>> hi,
>>
>> When we used 2.6.18 and 2.6.20 on ASUS sis-671 motherboard, We have some
>> problem: cannot find the harddisk controller.
>> In BIOS, the SATA mode is 2P+2IDE.
>>
>> The official kernel 2.6.18, 2.6.20 and new 2.6.21 does not work, i get
>> some information about sata_sis 0.7.1 from you, may I get it ?
>>
>> We are so urgent, please help me.
>>
>> Thank you very much!!!!
>>     
> Asus is selling a P5X-MX SE motherboard with a SiS968
> southbridge. The SiS671 Northbridge is not intresting for the SATA-support.
> Currently it is only planned to support this chipset in
> AHCI-mode. You should select the AHCI mode for the SATA-ports in the
> BIOS. The ahci driver should support your board.
> kernel 2.6.20 should be sufficient.
> If this does not work, please provide the output of
> lspci -vvxxx and the selected mode for the SATA-port.
>
> regards
> Uwe Koziolek
>
>
>
>
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michal Piotrowski | 1 Jun 2007 14:20
Picon

Re: [2/3] 2.6.22-rc3: known regressions v2

Hi all,

Here is a list of some known regressions in 2.6.22-rc3.

Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions

PCMCIA

Subject    : libata and legacy ide pcmcia failure
References : http://lkml.org/lkml/2007/5/17/305
Submitter  : Robert de Rooy <robert.de.rooy <at> gmail.com>
Status     : Unknown

SATA/PATA

Subject    : 22-rc3 broke the CDROM in Dell notebook
References : http://lkml.org/lkml/2007/5/27/63
Submitter  : Gregor Jasny <gjasny <at> googlemail.com>
Handled-By : Tejun Heo <htejun <at> gmail.com>
             Jeff Garzik <jeff <at> garzik.org>
Caused-By  : Tejun Heo <htejun <at> gmail.com>
             commit d4b2bab4f26345ea1803feb23ea92fbe3f6b77bc
Status     : problem is being debugged

SCSI

Subject    : aacraid: adapter kernel panic'd fffffffd (kexec)
References : http://lkml.org/lkml/2007/5/29/491
Submitter  : Yinghai Lu <yhlu.kernel <at> gmail.com>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michal Piotrowski | 1 Jun 2007 14:20
Picon

Re: [2/3] 2.6.22-rc3: known regressions v2

Hi all,

Here is a list of some known regressions in 2.6.22-rc3.

Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions

PCMCIA

Subject    : libata and legacy ide pcmcia failure
References : http://lkml.org/lkml/2007/5/17/305
Submitter  : Robert de Rooy <robert.de.rooy <at> gmail.com>
Status     : Unknown

SATA/PATA

Subject    : 22-rc3 broke the CDROM in Dell notebook
References : http://lkml.org/lkml/2007/5/27/63
Submitter  : Gregor Jasny <gjasny <at> googlemail.com>
Handled-By : Tejun Heo <htejun <at> gmail.com>
             Jeff Garzik <jeff <at> garzik.org>
Caused-By  : Tejun Heo <htejun <at> gmail.com>
             commit d4b2bab4f26345ea1803feb23ea92fbe3f6b77bc
Status     : problem is being debugged

SCSI

Subject    : aacraid: adapter kernel panic'd fffffffd (kexec)
References : http://lkml.org/lkml/2007/5/29/491
Submitter  : Yinghai Lu <yhlu.kernel <at> gmail.com>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane