libata update posted

libata update posted

[Jeff Garzik]

Well, I was hoping to complete another low-level driver (Silicon Image) 
out there, but I would rather get bug fixes out first :)

libata driver architecture version 0.70 (helper library)
Intel ICH5 SATA driver version 0.93

Patch for 2.4.21:
ftp://ftp.??.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.4/2.4.21-libata5.patch.bz2

Patch for 2.6.0-test3:
ftp://ftp.??.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-test3-bk1-libata1.patch.bz2

Stressed on both 2.4 and 2.6, SMP and UP, lba2[48] and lba48.

Changes:
* lba48 fix
* SMP fixes
* locking sanitization
* locking documentation ("make pdfdocs")
* more infrastructure for command queueing and async taskfiles

Notes:
* Parallel ATA limited to UDMA/33 (SATA is full speed)
* ATAPI not ready for prime time

Still no data-corrupting bugs, knock on wood.

libata update posted

[Jeff Garzik]

Just some minor updates.  The main one is that ATA software reset is now 
considered reliable, so it is now the default. 
Execute-Device-Diagnostic bus reset method remains in place and can be 
easily re-enabled with a flag.

libata has also moved (slightly) to a new home:
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/

The latest libata patches for 2.4.x and 2.6.x were uploaded to this URL, 
and future patches will appear in the same location.

Look for more updates this weekend, including bug fixes from Dell and 
Red Hat, and better MMIO support.  And maybe a special surprise.  :)

	Jeff

Re: libata update posted

[J.A. Magallon]

On 09.13, Jeff Garzik wrote:
> Just some minor updates.  The main one is that ATA software reset is now 
> considered reliable, so it is now the default. 
> Execute-Device-Diagnostic bus reset method remains in place and can be 
> easily re-enabled with a flag.
> 
> libata has also moved (slightly) to a new home:
> ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/
> 
> The latest libata patches for 2.4.x and 2.6.x were uploaded to this URL, 
> and future patches will appear in the same location.
> 

The patch for 2.4 kills drivers/char/defkeymap.c.
Is this in on purpose ? I think this is autogenerated but not killed
in mrproper.

-- 
J.A. Magallon <jamagallon@able.es>      \                 Software is like sex:
werewolf.able.es                         \           It's better when it's free
Mandrake Linux release 9.2 (Cooker) for i586
Linux 2.4.23-pre4-jam1 (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk))

Re: libata update posted

[Jeff Garzik]

On Sat, Sep 13, 2003 at 10:56:52PM +0200, J.A. Magallon wrote:
> 
> On 09.13, Jeff Garzik wrote:
> > Just some minor updates.  The main one is that ATA software reset is now 
> > considered reliable, so it is now the default. 
> > Execute-Device-Diagnostic bus reset method remains in place and can be 
> > easily re-enabled with a flag.
> > 
> > libata has also moved (slightly) to a new home:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/
> > 
> > The latest libata patches for 2.4.x and 2.6.x were uploaded to this URL, 
> > and future patches will appear in the same location.
> > 
> 
> The patch for 2.4 kills drivers/char/defkeymap.c.
> Is this in on purpose ? I think this is autogenerated but not killed
> in mrproper.

Yep, that's an autogenerated file.  I nudge Marcelo to "bk rm" it every now
and then :)  Just remove it from the patch and you'll be ok.

I have to "rm -f drivers/char/defkeymap.c" on occasion, in order to do
some bk stuff, too.

	Jeff

Re: libata update posted

[Andries Brouwer]

On Sat, Sep 13, 2003 at 05:28:49PM -0400, Jeff Garzik wrote:
> On Sat, Sep 13, 2003 at 10:56:52PM +0200, J.A. Magallon wrote:

> > The patch for 2.4 kills drivers/char/defkeymap.c.
> > Is this in on purpose ? I think this is autogenerated but not killed
> > in mrproper.
> 
> Yep, that's an autogenerated file.  I nudge Marcelo to "bk rm" it every now
> and then :)  Just remove it from the patch and you'll be ok.
> 
> I have to "rm -f drivers/char/defkeymap.c" on occasion, in order to do
> some bk stuff, too.

Long ago it happened every once in a while that I added a key type.
In such a case one got new kernel keyboard headers, had to recompile
loadkeys with the new headers, use that new loadkeys to regenerate
defkeymap.c, and then recompile the kernel.

This shows why defkeymap.c is not generated in the kernel build
but distributed.

Andries

Re: libata update posted

[Jeff Garzik]

Andries Brouwer wrote:
> This shows why defkeymap.c is not generated in the kernel build
> but distributed.

There is a difference between distributed generating files, and checking 
generated files into a repository...  I do not advocate changing the 
tarball, just the BK repo behind it.

	Jeff

Re: libata update posted

[Andries Brouwer]

On Sun, Sep 14, 2003 at 01:26:21PM -0400, Jeff Garzik wrote:

> > This shows why defkeymap.c is not generated in the kernel build
> > but distributed.
> 
> There is a difference between distributing generated files, and checking 
> generated files into a repository...  I do not advocate changing the 
> tarball, just the BK repo behind it.

So you would like to remove defkeymap.c from the bitkeeper repository.
Can you briefly explain why?
I am not a bk user so have no feeling for what one would like bk to do.

But it seems to me that if defkeymap.c is only a generated file when
no kbd headers have changed, while in the opposite case one needs a
private version of loadkeys until the next version of kbd has been
distributed, it is easier to regard it as part of the kernel source.

Andries

Re: libata update posted

[Jeff Garzik]

Andries Brouwer wrote:
> On Sun, Sep 14, 2003 at 01:26:21PM -0400, Jeff Garzik wrote:
> 
> 
>>>This shows why defkeymap.c is not generated in the kernel build
>>>but distributed.
>>
>>There is a difference between distributing generated files, and checking 
>>generated files into a repository...  I do not advocate changing the 
>>tarball, just the BK repo behind it.
> 
> 
> So you would like to remove defkeymap.c from the bitkeeper repository.
> Can you briefly explain why?
> I am not a bk user so have no feeling for what one would like bk to do.
> 
> But it seems to me that if defkeymap.c is only a generated file when
> no kbd headers have changed, while in the opposite case one needs a
> private version of loadkeys until the next version of kbd has been
> distributed, it is easier to regard it as part of the kernel source.

defkeymap.c is _always_ a generated file.  However, some environments 
lack the capability to generate it (properly).

My motivation is not bitkeeper-specific:  I dislike the practice of 
checking build-generated files into an SCM of any sort.  That sort of 
stuff should be handled by the maintainer, when generating the release 
patches and tarballs.  aic7xxx is another example

Package developers (read: kernel hackers) are expected to have a correct 
environment to rebuild generated files properly.  Package builders are 
only expected to have a minimal build environment, with stuff like 
configure scripts, yacc/lex output, defkeymap, and similar things 
pre-generated from a canonical source (the maintainer).

The GNOME guys recognized this distinction between hackers and builders 
a long time ago.  When you check things out of GNOME cvs, you get _just_ 
the sources.  One must run ./autogen.sh to generate the 
autoconf/automake/libtool junk needed to actually build successfully.

	Jeff

Re: libata update posted

[Andries Brouwer]

On Sun, Sep 14, 2003 at 04:09:44PM -0400, Jeff Garzik wrote:

> My motivation is not bitkeeper-specific:  I dislike the practice of 
> checking build-generated files into an SCM of any sort.

OK


(Up to a point I can agree with you. On the other hand..

I am a mathematician, and some of my generated files take weeks
of computation. Maybe once they are available one no longer
wants to regard them as generated files. Something similar holds
for files generated by software that is not widely available.
Maybe the software is commercial. Maybe it only runs on a
different architecture. Or maybe it was a specially patched version.
In the case of defkeymap.c (where nothing has changed for
over five years), when a key type is added, it is generated
by a private version that is not widely available.
For Linus or whoever makes distributions, who does not possess
the software required to generate defkeymap.c, it is just a
source file.)

Re: libata update posted

[Jeff Garzik]

Andries Brouwer wrote:
> I am a mathematician, and some of my generated files take weeks
> of computation. Maybe once they are available one no longer
> wants to regard them as generated files. Something similar holds
> for files generated by software that is not widely available.
> Maybe the software is commercial. Maybe it only runs on a
> different architecture. Or maybe it was a specially patched version.
> In the case of defkeymap.c (where nothing has changed for
> over five years), when a key type is added, it is generated
> by a private version that is not widely available.
> For Linus or whoever makes distributions, who does not possess
> the software required to generate defkeymap.c, it is just a
> source file.)


Well, if an auto-generated file in the kernel is not generated by a 
program that is itself open source, that's IMO a problem.  GPL's 
"preferred form" and all.

	Jeff

Re: libata update posted

[James Bottomley]

On Sun, 2003-09-14 at 16:36, Jeff Garzik wrote:
> Well, if an auto-generated file in the kernel is not generated by a 
> program that is itself open source, that's IMO a problem.  GPL's 
> "preferred form" and all.

OK, you two, this is way off topic for a SCSI list.

Since the issue was solved elegantly in 2.6 with the _shipped files, can
we agree to drop it (or at least trim back the cc list)?

Thanks,

James

Re: libata update posted

[Andries Brouwer]

On Sun, Sep 14, 2003 at 04:38:41PM -0500, James Bottomley wrote:

> OK, you two, this is way off topic for a SCSI list.

Thank you, James!

Re: libata update posted

[Pavel Machek]

Hi!

> >I am a mathematician, and some of my generated files take weeks
> >of computation. Maybe once they are available one no longer
> >wants to regard them as generated files. Something similar holds
> >for files generated by software that is not widely available.
> >Maybe the software is commercial. Maybe it only runs on a
> >different architecture. Or maybe it was a specially patched version.
> >In the case of defkeymap.c (where nothing has changed for
> >over five years), when a key type is added, it is generated
> >by a private version that is not widely available.
> >For Linus or whoever makes distributions, who does not possess
> >the software required to generate defkeymap.c, it is just a
> >source file.)
> 
> Well, if an auto-generated file in the kernel is not generated by a 
> program that is itself open source, that's IMO a problem.  GPL's 
> "preferred form" and all.

Actually, that's okay. Source code for proprietary compiler is *still*
prefered form for editing.
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: libata update posted

[J.A. Magallon]

On 09.13, Jeff Garzik wrote:
> Just some minor updates.  The main one is that ATA software reset is now 
> considered reliable, so it is now the default. 
> Execute-Device-Diagnostic bus reset method remains in place and can be 
> easily re-enabled with a flag.
> 
> libata has also moved (slightly) to a new home:
> ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/
> 
> The latest libata patches for 2.4.x and 2.6.x were uploaded to this URL, 
> and future patches will appear in the same location.
> 
> Look for more updates this weekend, including bug fixes from Dell and 
> Red Hat, and better MMIO support.  And maybe a special surprise.  :)
> 

Any user documentation, like modules names and how to make it work ?
I could write the Configure.help entries.
I suppose you load the PIIX/VIA modules and you have one other scsi
bus.

Any pointer ?

Just adding it to -jam before publishing pre4-jam1.

-- 
J.A. Magallon <jamagallon@able.es>      \                 Software is like sex:
werewolf.able.es                         \           It's better when it's free
Mandrake Linux release 9.2 (Cooker) for i586
Linux 2.4.23-pre4-jam1 (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk))

Re: libata update posted

[Jeff Garzik]

On Sat, Sep 13, 2003 at 11:13:32PM +0200, J.A. Magallon wrote:
> 
> On 09.13, Jeff Garzik wrote:
> > Just some minor updates.  The main one is that ATA software reset is now 
> > considered reliable, so it is now the default. 
> > Execute-Device-Diagnostic bus reset method remains in place and can be 
> > easily re-enabled with a flag.
> > 
> > libata has also moved (slightly) to a new home:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/
> > 
> > The latest libata patches for 2.4.x and 2.6.x were uploaded to this URL, 
> > and future patches will appear in the same location.
> > 
> > Look for more updates this weekend, including bug fixes from Dell and 
> > Red Hat, and better MMIO support.  And maybe a special surprise.  :)
> > 
> 
> Any user documentation, like modules names and how to make it work ?
> I could write the Configure.help entries.
> I suppose you load the PIIX/VIA modules and you have one other scsi
> bus.

The 2.5 patch should have Configure.help entries.  Any assistance in
writing documentation is greatly appreciated, though :)  I hope to get
much more than just a dry API reference in
Documentation/Docbook/libata.tmpl, so any added information should
probably be noted in there.

No user documentation, but feel free to ask me questions.  Here's a
quick overview:

ata_piix, ata_via -- low-level driver modules
libata -- shared code module for the above

modprobe ata_piix or ata_via, and it will make your SATA devices appear
as a new SCSI bus.  Each SATA port is represented by a separate SCSI
bus.

Currently in 2.4 and 2.6, both ATA and ATAPI devices appear as SCSI
devices.  However in 2.7, ATA devices (i.e. hard drives) will not go
through the SCSI layer.  ATAPI devices will continue to use some of the
SCSI layer code in 2.7.

Currently only Intel ICH5 SATA is well tested.  VIA SATA was just added,
and Intel PATA support exists, but it is recommended that you use
drivers/ide for PATA support.

Current -ac and -pac kernels #if-0 the ICH5 SATA pci id from
drivers/ide/pci/piix.c, preferring to let libata drive that.
That's done not only to expose libata to testing, but also for
pragmatic reasons:  drivers/ide will hang on many ICH5 SATA hosts,
when they are in "native mode"[1].

	Jeff


[1] native mode is when a PCI IDE device is configured to obtain
all its resources from the PCI io space, and use PCI interrupts.
The other side of the coin is legacy mode, which uses legacy IDE
ports 0x1f0/0x170 and legacy ISA irqs 14/15.

Re: libata update posted

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

On Sat, Sep 13, 2003 at 05:38:28PM -0400, Jeff Garzik wrote:
> No user documentation, but feel free to ask me questions.  Here's a
> quick overview:
> 
> ata_piix, ata_via -- low-level driver modules
> libata -- shared code module for the above

   Do you have any plans to support SiI3112 in libata? The current
SiI3112 drivers in the kernel just don't seem to work right on my
hardware. :(

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
  --- I am but mad north-north-west:  when the wind is southerly, I ---  
                       know a hawk from a handsaw.                       

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: libata update posted

[Jeff Garzik]

Hugo Mills wrote:
> On Sat, Sep 13, 2003 at 05:38:28PM -0400, Jeff Garzik wrote:
> 
>>No user documentation, but feel free to ask me questions.  Here's a
>>quick overview:
>>
>>ata_piix, ata_via -- low-level driver modules
>>libata -- shared code module for the above
> 
> 
>    Do you have any plans to support SiI3112 in libata? The current
> SiI3112 drivers in the kernel just don't seem to work right on my
> hardware. :(


Yes!  It should be fairly quick to add Silicon Image SATA support, too.

It's all about finding the time to do it ;-)  Hopefully some time in the 
next week or two...

	Jeff

libata update posted

[Jeff Garzik]

New version of my Serial ATA (SATA) driver posted.  Main change is 
better integration with the drivers/ide driver.

Current libata SATA hardware support status:
* Intel ICH5:			production
* ServerWorks / Apply K2:	production
* Silicon Image:		developers only.  known to lock up.
* VIA:				beta.  1 failure on 64-bit.

Patch for 2.4 (diff'd against latest 2.4.23-pre BK snapshot):
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.4.22-bk28-libata1.patch.bz2

Patch for 2.6.0-test (diff'd against latest 2.6.0-test6 BK snapshot):
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.6.0-test6-bk7-libata1.patch.bz2

BK repositories:
	http://gkernel.bkbits.net/libata-2.[45]
		or
	bk://kernel.bkbits.net/jgarzik/libata-2.[45]

Coming soon:
* Promise SATA support.
* Silicon Image fix (needs to ack some more interrupts)
* Hardware queueing (TCQ) support for Promise, ServerWorks

I wonder if there is a "linux-ide" mailing list somewhere......

	Jeff

Re: libata update posted

[Bartlomiej Zolnierkiewicz]

> I wonder if there is a "linux-ide" mailing list somewhere......

linux-ide@vger.kernel.org