[RFT] major libata update

[RFT] major libata update

[Jeff Garzik]

After much development and review, I merged a massive pile of libata
patches from Tejun Heo and Albert Lee.  This update contains the
following major libata

CHANGES:
* Rewritten error handling. This is a major piece of work, even
  though it will be rarely seen.  The new libata EH provides the
  foundation for not only improved error handling, but also new features
  such as device hotplug or command queueing. (Tejun Heo)

* PIO-based I/O is now IRQ-driven by default, rather than polled
  in a kernel thread.  The polling path will continue to exist for
  controllers that need it, and other special cases. (Albert Lee)

* Core support for command queueing (Jens Axboe, Tejun Heo)

* Support for NCQ-style command queueing (Jens Axboe, Tejun Heo)

* Increase max-sectors dramatically, for LBA48 devices (Tejun Heo?)

* Other minor changes, from myself and others.

IMPACT:
* If all goes well, this update should improve error handling,
  solve several outstanding, difficult-to-solve bugs, and provide a good
  foundation for adding some nifty features in the future.

TESTING:
* Although most drivers by count received few operational changes, the
common probe path was updated, so all drivers need fresh "yes, it sees
all my disks" regression testing.

* ahci and sata_sil24 were touched a lot, and so need additional
testing.

* sata_sil and ata_piix also need healthy re-testing of all basic
functionality.

FEEDBACK:
* Please CC linux-ide@vger.kernel.org on all emails and bug reports.

MERGE STATUS:
* Barring major problems in testing, will submit during 2.6.18 merge window.


Patch:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.6.17-rc4-git2-libata1.patch.bz2
(diff'd against 2.6.17-rc4-git2, but should apply to most recent
2.6.17-rcX[-gitY] kernels)

The 'upstream' branch of

	git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

contains the following updates:

 drivers/scsi/Makefile       |    2 
 drivers/scsi/ahci.c         |  436 ++++---
 drivers/scsi/ata_piix.c     |   16 
 drivers/scsi/libata-bmdma.c |  143 ++
 drivers/scsi/libata-core.c  | 2437 +++++++++++++++++++++++++++++---------------
 drivers/scsi/libata-eh.c    | 1558 ++++++++++++++++++++++++++++
 drivers/scsi/libata-scsi.c  |  423 ++++---
 drivers/scsi/libata.h       |   24 
 drivers/scsi/pdc_adma.c     |   10 
 drivers/scsi/sata_mv.c      |   30 
 drivers/scsi/sata_nv.c      |    6 
 drivers/scsi/sata_promise.c |   18 
 drivers/scsi/sata_qstor.c   |   13 
 drivers/scsi/sata_sil.c     |   65 -
 drivers/scsi/sata_sil24.c   |  615 ++++++-----
 drivers/scsi/sata_sis.c     |    2 
 drivers/scsi/sata_svw.c     |    4 
 drivers/scsi/sata_sx4.c     |   19 
 drivers/scsi/sata_uli.c     |    2 
 drivers/scsi/sata_via.c     |    2 
 drivers/scsi/sata_vsc.c     |   15 
 drivers/scsi/scsi.c         |   18 
 drivers/scsi/scsi_error.c   |    3 
 drivers/scsi/scsi_lib.c     |    2 
 drivers/scsi/scsi_priv.h    |    1 
 include/linux/ata.h         |   34 
 include/linux/libata.h      |  379 ++++--
 include/scsi/scsi_cmnd.h    |    1 
 include/scsi/scsi_eh.h      |    1 
 include/scsi/scsi_host.h    |    1 
 30 files changed, 4634 insertions(+), 1646 deletions(-)

Albert Lee:
      libata: interrupt driven pio for libata-core
      libata: interrupt driven pio for LLD
      libata irq-pio: add comments and cleanup
      libata irq-pio: rename atapi_packet_task() and comments
      libata irq-pio: simplify if condition in ata_dataout_task()
      libata irq-pio: cleanup ata_qc_issue_prot()
      libata: move atapi_send_cdb() and ata_dataout_task()
      [libata irq-pio] reorganize ata_pio_sector() and __atapi_pio_bytes()
      [libata irq-pio] reorganize "buf + offset" in ata_pio_sector()
      [libata irq-pio] use PageHighMem() to optimize the kmap_atomic() usage
      libata irq-pio: misc fixes
      libata irq-pio: merge the ata_dataout_task workqueue with ata_pio_task workqueue
      libata irq-pio: eliminate unnecessary queuing in ata_pio_first_block()
      libata irq-pio: add read/write multiple support
      libata-dev: determine err_mask when error is found
      libata-dev: filter out noisy ATAPI error messages
      libata-dev: Fix array index value in ata_rwcmd_protocol()
      libata-dev: Use new ata_queue_pio_task() for PIO polling task
      libata-dev: Use new AC_ERR_* flags
      libata-dev: Minor comment fix
      libata-dev: recognize WRITE_MULTI_FUA_EXT for r/w multiple
      libata-dev: Remove trailing whitespaces
      libata-dev: Fix merge problem with upstream
      libata-dev: Remove atapi_packet_task()
      libata-dev: Move out the HSM code from ata_host_intr()
      libata-dev: Minor fix for ata_hsm_move() to work with ata_host_intr()
      libata-dev: Let ata_hsm_move() work with both irq-pio and polling pio
      libata-dev: Convert ata_pio_task() to use the new ata_hsm_move()
      libata-dev: Cleanup unused enums/functions
      libata-dev: ata_check_atapi_dma() fix for ATA_FLAG_PIO_POLLING LLDDs
      libata-dev: Make the the in_wq check as an inline function
      libata-dev: irq-pio minor fixes (respin)
      libata-dev: fix the device err check sequence (respin)
      libata-dev: wait idle after reading the last data block
      libata-dev: print out information for ATAPI devices with CDB interrupts
      libata-dev: handle DRQ=1 ERR=1 (revised)
      libata-dev: irq-pio minor fix
      libata-dev: irq-pio minor fix 2
      libata: convert ATAPI_ENABLE_DMADIR to module parameter

Bastiaan Jacques:
      ahci: add support for VIA VT8251

Jeff Garzik:
      [libata irq-pio] build fix
      [libata pdc_adma] update for removal of ATA_FLAG_NOINTR
      [libata pdc_adma] fix for new irq-driven PIO code
      [libata sata_mv] IRQ PIO build fix
      [libata] irq-pio: fix breakage related to err_mask merge
      [libata sata_promise] irq_pio: fix merge bug
      [libata] build fix after merging some pre-packet_task-removal code
      [libata irq-pio] s/assert/WARN_ON/
      [libata] build fix after cdb_len move
      sata_vsc build fix
      libata: irq-pio build fixes
      [libata] irq-pio: fix build breakage
      [libata] irq-pio: Fix merge mistake
      [libata] kill bogus cut-n-pasted comments in three drivers
      [libata] bump versions
      libata: Fix EH merge difference between this branch and upstream.
      libata: Add helper ata_shost_to_port()

Luben Tuikov:
      SCSI: Introduce scsi_req_abort_cmd (REPOST)

Tejun Heo:
      libata: increase LBA48 max sectors to 65535
      libata: fix ata_set_mode() return value
      libata: make ata_bus_probe() return negative errno on failure
      libata: separate out ata_spd_string()
      libata: convert do_probe_reset() to ata_do_reset()
      libata: implement ata_dev_enabled and disabled()
      libata: make ata_set_mode() handle no-device case properly
      libata: reorganize ata_set_mode()
      libata: don't disable devices from ata_set_mode()
      libata: preserve SATA SPD setting over hard resets
      libata: implement ata_dev_absent()
      libata: implement ap->sata_spd_limit and helpers
      libata: use SATA speed down in ata_drive_probe_reset()
      libata: add 5s sleep between resets
      libata: implement ata_down_xfermask_limit()
      libata: improve ata_bus_probe()
      libata: consider disabled devices in ata_dev_xfermask()
      libata: report device number when PIO fails
      libata: ata_dev_revalidate() printk update
      libata: ATA_FLAG_IN_EH is not used, kill it
      libata: clean up constants
      libata: rename ATA_FLAG_PORT_DISABLED to ATA_FLAG_DISABLED
      libata: clear only affected flags during ata_dev_configure()
      libata: clear ATA_DFLAG_PIO before setting it
      libata: add ATA_QCFLAG_IO
      libata: pass qc around intead of ap during PIO
      libata: always generate sense if qc->err_mask is non-zero
      libata: don't read TF directly from sense generation functions
      libata: add @cdb to ata_exec_internal()
      libata: dec scmd->retries for qcs with zero err_mask
      libata: separate out libata-eh.c
      libata: make some libata-core routines extern
      libata: print SControl in SATA link status info message
      ahci: do not fail softreset if PHY reports no device
      libata: set default cbl in probeinit
      libata: kill @verbose from ata_reset_fn_t
      libata: make reset methods complain when they fail
      sata_sil24: fix timeout calculation in sil24_softreset
      sata_sil24: better error message from softreset
      libata: implement ata_wait_register()
      ahci: use ata_wait_register()
      sata_sil24: use ata_wait_register()
      libata: disable failed devices only once in ata_bus_probe()
      libata: cosmetic update to ata_bus_probe()
      libata: export ata_set_sata_spd()
      sata_sil24: typo fix
      sata_sil24: rename PORT_IRQ_SDB_FIS to PORT_IRQ_SDB_NOTIFY
      sata_sil24: add more constants
      sata_sil24: consolidate host flags into SIL24_COMMON_FLAGS
      sata_sil24: implement loss of completion interrupt on PCI-X errta fix
      sata_sil24: implement sil24_init_port()
      sata_sil24: put port into known state before softresetting
      sata_sil24: kill 10ms sleep in softreset
      sata_sil24: reimplement hardreset
      sata_sil24: don't do hardreset during driver initialization
      sata_sil24: fix on-memory structure byteorder
      sata_sil24: enable 64bit
      SCSI: implement shost->host_eh_scheduled
      libata: silly fix in ata_scsi_start_stop_xlat()
      libata: rename ata_down_sata_spd_limit() and friends
      ahci: hardreset classification fix
      libata: unexport ata_scsi_error()
      libata: kill duplicate prototypes
      libata: fix ->phy_reset class code handling in ata_bus_probe()
      libata: clear ap->active_tag atomically w.r.t. command completion
      libata: hold host_set lock while finishing internal qc
      libata: use preallocated buffers
      libata: move ->set_mode() handling into ata_set_mode()
      libata: remove postreset handling from ata_do_reset()
      libata: implement qc->result_tf
      sata_sil24: update TF image only when necessary
      libata: init ap->cbl to ATA_CBL_SATA early
      libata: implement new SCR handling and port on/offline functions
      libata: use new SCR and on/offline functions
      libata: kill old SCR functions and sata_dev_present()
      libata: add dev->ap
      libata: use dev->ap
      libata: implement ATA printk helpers
      libata: use ATA printk helpers
      libata-eh-fw: add flags and operations for new EH
      libata-eh-fw: clear SError in ata_std_postreset()
      libata-eh-fw: use special reserved tag and qc for internal commands
      libata-eh-fw: update ata_qc_from_tag() to enforce normal/EH qc ownership
      libata-eh-fw: implement new EH scheduling via error completion
      libata-eh-fw: implement ata_port_schedule_eh() and ata_port_abort()
      libata-eh-fw: implement freeze/thaw
      libata-eh-fw: implement new EH scheduling from PIO
      libata-eh-fw: update ata_scsi_error() for new EH
      libata-eh-fw: update ata_exec_internal() for new EH
      libata-eh-fw: update SCSI command completion path for new EH
      libata-eh: add ATA and libata flags for new EH
      libata-eh: implement dev->ering
      libata-eh: implement ata_eh_info and ata_eh_context
      libata-eh: implement new EH
      libata-eh: implement BMDMA EH
      ata_piix: convert to new EH
      sata_sil: convert to new EH
      ahci: convert to new EH
      ahci: add PIOS interim interrupt handling
      sata_sil24: convert to new EH
      libata: fix irq-pio merge
      libata-ncq: add NCQ related ATA/libata constants and macros
      libata-ncq: pass ata_scsi_translate() return value to SCSI midlayer
      libata-ncq: rename ap->qactive to ap->qc_allocated
      libata-ncq: implement ap->qc_active, ap->sactive and complete helper
      libata-ncq: implement NCQ command translation and exclusion
      libata-ncq: update EH to handle NCQ
      libata-ncq: implement NCQ device configuration
      ahci: clean up AHCI constants in preparation for NCQ
      ahci: add HOST_CAP_NCQ constant
      ahci: kill pp->cmd_tbl_sg
      ahci: implement NCQ suppport
      sata_sil24: implement NCQ support

Re: [RFT] major libata update

[Jeff Garzik]

Alan Cox wrote:
> On Llu, 2006-05-15 at 13:00 -0400, Jeff Garzik wrote:
>> * PIO-based I/O is now IRQ-driven by default, rather than polled
>>   in a kernel thread.  The polling path will continue to exist for
>>   controllers that need it, and other special cases. (Albert Lee)
> 
> How will this be selected ? Passing ->irq = 0 ?

It is selected at runtime by passing a polling flag to ata_taskfile.

That flag, in turn can be set by anything -- driver flags (for 
controllers that always require polling), user variable requested at 
runtime, whatever.


> For ata_piix given you've destabilized it a bit would now be a good time
> to submit the patches to fix the timing, register scribble and incorrect
> ATAPI caching ?

Sure.

	Jeff

Re: [RFT] major libata update

[Andrew Morton]

Jeff Garzik <jeff@garzik.org> wrote:
>
> 
> After much development and review, I merged a massive pile of libata
> patches from Tejun Heo and Albert Lee.  This update contains the
> following major libata
> 
> CHANGES:
> * Rewritten error handling. This is a major piece of work, even
>   though it will be rarely seen.  The new libata EH provides the
>   foundation for not only improved error handling, but also new features
>   such as device hotplug or command queueing. (Tejun Heo)
> 
> * PIO-based I/O is now IRQ-driven by default, rather than polled
>   in a kernel thread.  The polling path will continue to exist for
>   controllers that need it, and other special cases. (Albert Lee)
> 
> * Core support for command queueing (Jens Axboe, Tejun Heo)
> 
> * Support for NCQ-style command queueing (Jens Axboe, Tejun Heo)
> 
> * Increase max-sectors dramatically, for LBA48 devices (Tejun Heo?)
> 
> * Other minor changes, from myself and others.
> 
> IMPACT:
> * If all goes well, this update should improve error handling,
>   solve several outstanding, difficult-to-solve bugs, and provide a good
>   foundation for adding some nifty features in the future.
> 
> TESTING:
> * Although most drivers by count received few operational changes, the
> common probe path was updated, so all drivers need fresh "yes, it sees
> all my disks" regression testing.
> 
> * ahci and sata_sil24 were touched a lot, and so need additional
> testing.
> 
> * sata_sil and ata_piix also need healthy re-testing of all basic
> functionality.

Lots of goodies.

> FEEDBACK:
> * Please CC linux-ide@vger.kernel.org on all emails and bug reports.
> 
> MERGE STATUS:
> * Barring major problems in testing, will submit during 2.6.18 merge window.

I'd be a little concerned with that merge plan at this time - we have a lot
of sata bug reports banked up and afaict a pretty low fixup rate.  Then
again, these patches might fix some of those bugs...

I guess if we can get it all in early (which is only a couple of weeks
away!) and you and Tejun will have time set aside to work on problems then
OK.  But....

http://bugzilla.kernel.org/show_bug.cgi?id=4920
http://bugzilla.kernel.org/show_bug.cgi?id=5533
http://bugzilla.kernel.org/show_bug.cgi?id=5586
http://bugzilla.kernel.org/show_bug.cgi?id=5589
http://bugzilla.kernel.org/show_bug.cgi?id=5798
http://bugzilla.kernel.org/show_bug.cgi?id=5863
http://bugzilla.kernel.org/show_bug.cgi?id=4968
http://bugzilla.kernel.org/show_bug.cgi?id=5047
http://bugzilla.kernel.org/show_bug.cgi?id=5905
http://bugzilla.kernel.org/show_bug.cgi?id=5596
http://bugzilla.kernel.org/show_bug.cgi?id=5654
http://bugzilla.kernel.org/show_bug.cgi?id=5664
http://bugzilla.kernel.org/show_bug.cgi?id=5700
http://bugzilla.kernel.org/show_bug.cgi?id=5709
http://bugzilla.kernel.org/show_bug.cgi?id=5721
http://bugzilla.kernel.org/show_bug.cgi?id=5722
http://bugzilla.kernel.org/show_bug.cgi?id=5922
http://bugzilla.kernel.org/show_bug.cgi?id=5789
http://bugzilla.kernel.org/show_bug.cgi?id=5931
http://bugzilla.kernel.org/show_bug.cgi?id=5969
http://bugzilla.kernel.org/show_bug.cgi?id=5948
http://bugzilla.kernel.org/show_bug.cgi?id=5987
http://bugzilla.kernel.org/show_bug.cgi?id=5995
http://bugzilla.kernel.org/show_bug.cgi?id=6173
http://bugzilla.kernel.org/show_bug.cgi?id=6207
http://bugzilla.kernel.org/show_bug.cgi?id=6240
http://bugzilla.kernel.org/show_bug.cgi?id=6253
http://bugzilla.kernel.org/show_bug.cgi?id=6260
http://bugzilla.kernel.org/show_bug.cgi?id=6272
http://bugzilla.kernel.org/show_bug.cgi?id=6283
http://bugzilla.kernel.org/show_bug.cgi?id=6311
http://bugzilla.kernel.org/show_bug.cgi?id=6317
http://bugzilla.kernel.org/show_bug.cgi?id=6346
http://bugzilla.kernel.org/show_bug.cgi?id=6470
http://bugzilla.kernel.org/show_bug.cgi?id=6056
http://bugzilla.kernel.org/show_bug.cgi?id=6494
http://bugzilla.kernel.org/show_bug.cgi?id=6516
http://bugzilla.kernel.org/show_bug.cgi?id=6521

Re: [RFT] major libata update

[Alan Cox]

On Llu, 2006-05-15 at 13:00 -0400, Jeff Garzik wrote:
> * PIO-based I/O is now IRQ-driven by default, rather than polled
>   in a kernel thread.  The polling path will continue to exist for
>   controllers that need it, and other special cases. (Albert Lee)

How will this be selected ? Passing ->irq = 0 ?

For ata_piix given you've destabilized it a bit would now be a good time
to submit the patches to fix the timing, register scribble and incorrect
ATAPI caching ?

Re: [RFT] major libata update

[Jeff Garzik]

Andrew Morton wrote:

We watch the bug reports, but try to get an overall picture rather than 
being good about updating each bugzilla tracker promptly :/  The 
tracking is quite useful though.


> http://bugzilla.kernel.org/show_bug.cgi?id=4920

not us

> http://bugzilla.kernel.org/show_bug.cgi?id=5533

addressed here

> http://bugzilla.kernel.org/show_bug.cgi?id=5586

sata_mv still considered highly experimental, as noted in Kconfig.  Bugs 
deferred to Mark Lord.

> http://bugzilla.kernel.org/show_bug.cgi?id=5589

funny looking backtrace, according to you

> http://bugzilla.kernel.org/show_bug.cgi?id=5798

worth looking into

> http://bugzilla.kernel.org/show_bug.cgi?id=5863

worth looking into, also worth testing with big update.

probable cause, the most recent ata_piix map value stuff.


> http://bugzilla.kernel.org/show_bug.cgi?id=4968

big update should help diagnose.  might need 'nv-adma' branch to fix.

> http://bugzilla.kernel.org/show_bug.cgi?id=5047

big update should help.

> http://bugzilla.kernel.org/show_bug.cgi?id=5905

big update should help, or at least help diagnose.

> http://bugzilla.kernel.org/show_bug.cgi?id=5596

ditto sata_mv info above.

> http://bugzilla.kernel.org/show_bug.cgi?id=5654

big update should help.

> http://bugzilla.kernel.org/show_bug.cgi?id=5664

should forward to NVIDIA for help debugging.  nv-adma branch may help 
diagnose.

> http://bugzilla.kernel.org/show_bug.cgi?id=5700

big update should help

> http://bugzilla.kernel.org/show_bug.cgi?id=5709

trivial patch submission

> http://bugzilla.kernel.org/show_bug.cgi?id=5721

dont care

> http://bugzilla.kernel.org/show_bug.cgi?id=5722

maybe a bug, probably weird drive or media, worth looking into

> http://bugzilla.kernel.org/show_bug.cgi?id=5922

should be using ahci driver

> http://bugzilla.kernel.org/show_bug.cgi?id=5789

include in the "atapi + via problems" bucket; bucket should be looked 
into... some people it works great, others not.  may need 
motherboard-specific (southbridge) tuning.

> http://bugzilla.kernel.org/show_bug.cgi?id=5931

big update will help

> http://bugzilla.kernel.org/show_bug.cgi?id=5969

probably just needs PCI IDs

> http://bugzilla.kernel.org/show_bug.cgi?id=5948

not libata?

> http://bugzilla.kernel.org/show_bug.cgi?id=5987

not libata

> http://bugzilla.kernel.org/show_bug.cgi?id=5995

big update + upcoming hotplug will fix.  until then, don't expect 
unplugging a drive to DTRT.

> http://bugzilla.kernel.org/show_bug.cgi?id=6173

need NVIDIA help.  maybe nv-adma branch will help diagnose.

> http://bugzilla.kernel.org/show_bug.cgi?id=6207

ditto

> http://bugzilla.kernel.org/show_bug.cgi?id=6240

investigate.  big update will help diagnose.

> http://bugzilla.kernel.org/show_bug.cgi?id=6253

big update should fix.

> http://bugzilla.kernel.org/show_bug.cgi?id=6260

waiting on SATA ACPI merge.

> http://bugzilla.kernel.org/show_bug.cgi?id=6272

big update should fix.

> http://bugzilla.kernel.org/show_bug.cgi?id=6283

investigate.  big update will help.

> http://bugzilla.kernel.org/show_bug.cgi?id=6311

big update should fix.

> http://bugzilla.kernel.org/show_bug.cgi?id=6317

big update may fix.

> http://bugzilla.kernel.org/show_bug.cgi?id=6346

not libata?

> http://bugzilla.kernel.org/show_bug.cgi?id=6470

new hardware, needs driver.

> http://bugzilla.kernel.org/show_bug.cgi?id=6056

bounce to NV

> http://bugzilla.kernel.org/show_bug.cgi?id=6494

waiting on SATA ACPI

> http://bugzilla.kernel.org/show_bug.cgi?id=6516

investigate, low priority

> http://bugzilla.kernel.org/show_bug.cgi?id=6521

big update should fix

Re: [RFT] major libata update

[Jeff Garzik]

Andrew Morton wrote:
> I'd be a little concerned with that merge plan at this time - we have a lot
> of sata bug reports banked up and afaict a pretty low fixup rate.  Then
> again, these patches might fix some of those bugs...
> 
> I guess if we can get it all in early (which is only a couple of weeks
> away!) and you and Tejun will have time set aside to work on problems then
> OK.  But....


As you can see from the list just sent, the improved error handling will 
give libata much greater ability to diagnose "controller is being weird" 
type situations, which is a lot of what the relevant bug reports need.

After reviewing those bug reports, I see a couple oopses -- caused by 
BUG()-style code, and fixed in this update -- and one data corruption 
which persists on Sil 311x on rare motherboards.  The rest are either 
addressed with the improved error handling, or are ATAPI + VIA AFAICS.

	Jeff

Re: [RFT] major libata update

[Andrew Morton]

Jeff Garzik <jeff@garzik.org> wrote:
>
> Andrew Morton wrote:
> > I'd be a little concerned with that merge plan at this time - we have a lot
> > of sata bug reports banked up and afaict a pretty low fixup rate.  Then
> > again, these patches might fix some of those bugs...
> > 
> > I guess if we can get it all in early (which is only a couple of weeks
> > away!) and you and Tejun will have time set aside to work on problems then
> > OK.  But....
> 
> 
> As you can see from the list just sent, the improved error handling will 
> give libata much greater ability to diagnose "controller is being weird" 
> type situations, which is a lot of what the relevant bug reports need.
> 
> After reviewing those bug reports, I see a couple oopses -- caused by 
> BUG()-style code, and fixed in this update -- and one data corruption 
> which persists on Sil 311x on rare motherboards.  The rest are either 
> addressed with the improved error handling, or are ATAPI + VIA AFAICS.
> 

ok, thanks.

Next -mm I'll suck up the libata changes, drop a pile of the hairier stuff
and I'll ask each originator to test that patchset.

Re: [RFT] major libata update

[Tomasz Torcz]

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

On Mon, May 15, 2006 at 01:00:06PM -0400, Jeff Garzik wrote:
> 
> After much development and review, I merged a massive pile of libata
> patches from Tejun Heo and Albert Lee.  This update contains the
> following major libata

  Any plans to merge http://home-tj.org/wiki/index.php/Sil_m15w ? Or
maybe it's merged already?
  Seagate firmware update seems to be available only for OEMs, so this
quirk is pretty helpful for end users.

-- 
Tomasz Torcz                        To co nierealne - tutaj jest normalne.
zdzichu@irc.-nie.spam-.pl          Ziomale na życie mają tu patenty specjalne.


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

Re: [RFT] major libata update

[Alan Cox]

On Llu, 2006-05-15 at 14:15 -0400, Jeff Garzik wrote:
> which persists on Sil 311x on rare motherboards.  The rest are either 
> addressed with the improved error handling, or are ATAPI + VIA AFAICS.

ATAPI + VIA to that pattern is also showing up on pata_via cases as
well, but only on via so far. Its as if there is a case where the IRQ of
the first command is lost sometimes.

Re: [RFT] major libata update

[Jeff Garzik]

Tomasz Torcz wrote:
> On Mon, May 15, 2006 at 01:00:06PM -0400, Jeff Garzik wrote:
>> After much development and review, I merged a massive pile of libata
>> patches from Tejun Heo and Albert Lee.  This update contains the
>> following major libata
> 
>   Any plans to merge http://home-tj.org/wiki/index.php/Sil_m15w ? Or
> maybe it's merged already?
>   Seagate firmware update seems to be available only for OEMs, so this
> quirk is pretty helpful for end users.

Its a question of staging.  This still lives in the 'sii-m15w' branch of 
libata-dev.git, but if we throw too many _classes_ of changes into the 
same big lump, then it becomes much more difficult to discern which 
changes caused which failures.

Since sata_sil has seen several changes, and since the sii-m15w problems 
are so difficult to diagnose properly, its easier to separate that out.

	Jeff

Re: [RFT] major libata update

[Jeff Garzik]

Andrew Morton wrote:
> ok, thanks.
> 
> Next -mm I'll suck up the libata changes, drop a pile of the hairier stuff
> and I'll ask each originator to test that patchset.

Cool.  FWIW this stuff can be found in libata-dev.git#ALL as usual.

	Jeff

Re: [RFT] major libata update

[Arkadiusz Miskiewicz]

On Monday 15 May 2006 20:06, Jeff Garzik wrote:

> > http://bugzilla.kernel.org/show_bug.cgi?id=6260
>
> waiting on SATA ACPI merge.
Is this really a case?

The one (layering breaking; discussed already) patch cures the problem and 
nothing sata acpi related is needed, so something else is problematic here I 
guess.

--- 2.6.17-rc2/drivers/scsi/libata-core.c       2006-04-19 09:14:11.000000000 
+0100 
+++ linux/drivers/scsi/libata-core.c    2006-04-21 20:55:48.000000000 +0100 
@@ -4288,6 +4288,7 @@ int ata_device_resume(struct ata_port *a 
 { 
        if (ap->flags & ATA_FLAG_SUSPENDED) { 
                ap->flags &= ~ATA_FLAG_SUSPENDED; 
+               ata_busy_sleep(ap, ATA_TMOUT_BOOT_QUICK, ATA_TMOUT_BOOT); 
                ata_set_mode(ap); 
        } 
        if (!ata_dev_present(dev))

-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

Re: [RFT] major libata update

[Jeff Garzik]

Also, a re-reminder:

At some convenient point, I'm going to move libata core and drivers to 
new directory drivers/ata.

The other noticeable change coming down the pipe is iomap support, which 
will kill those annoying warnings you see on every build (in addition to 
shrinking the driver a bit).

Speak up now if there are complaints...

	Jeff

Re: [RFT] major libata update

[Mark Lord]

Jeff Garzik wrote:
> Andrew Morton wrote:
..
>> http://bugzilla.kernel.org/show_bug.cgi?id=5586
> 
> sata_mv still considered highly experimental, as noted in Kconfig.  Bugs 
> deferred to Mark Lord.
..
I think that particular bug has gone away with my internal sata_mv.c version.
I'm updating it for release on top of Jeff/Tejun's patch set, and will likely
backport the bugfixes to 2.6.16.xx as well.  Timeline, this week or next.

Cheers 

Re: [RFT] major libata update

[Jeff Garzik]

Arkadiusz Miskiewicz wrote:
> On Monday 15 May 2006 20:06, Jeff Garzik wrote:
> 
>>> http://bugzilla.kernel.org/show_bug.cgi?id=6260
>> waiting on SATA ACPI merge.
> Is this really a case?
> 
> The one (layering breaking; discussed already) patch cures the problem and 
> nothing sata acpi related is needed, so something else is problematic here I 
> guess.
> 
> --- 2.6.17-rc2/drivers/scsi/libata-core.c       2006-04-19 09:14:11.000000000 
> +0100 
> +++ linux/drivers/scsi/libata-core.c    2006-04-21 20:55:48.000000000 +0100 
> @@ -4288,6 +4288,7 @@ int ata_device_resume(struct ata_port *a 
>  { 
>         if (ap->flags & ATA_FLAG_SUSPENDED) { 
>                 ap->flags &= ~ATA_FLAG_SUSPENDED; 
> +               ata_busy_sleep(ap, ATA_TMOUT_BOOT_QUICK, ATA_TMOUT_BOOT); 
>                 ata_set_mode(ap); 

This libata update should address issues that the above patch also 
addresses.  It will be interesting to hear feedback in the coming days 
on what issues remain after this big lump.

	Jeff

Re: [RFT] major libata update

[Tejun Heo]

Mark Lord wrote:
> Jeff Garzik wrote:
>> Andrew Morton wrote:
> ..
>>> http://bugzilla.kernel.org/show_bug.cgi?id=5586
>>
>> sata_mv still considered highly experimental, as noted in Kconfig.  
>> Bugs deferred to Mark Lord.
> ..
> I think that particular bug has gone away with my internal sata_mv.c 
> version.
> I'm updating it for release on top of Jeff/Tejun's patch set, and will 
> likely
> backport the bugfixes to 2.6.16.xx as well.  Timeline, this week or next.

The hotplug patches will change probing once more.  So, I recommend 
staying with legacy ->phy_reset mechanism for the time being unless you 
are using ->probe_reset() already.  However, converting from 
->probe_reset() to hotplug should be very easy.

-- 
tejun

Re: [RFT] major libata update

[Jeff Garzik]

Wakko Warner wrote:
> Jeff Garzik wrote:
>> After much development and review, I merged a massive pile of libata
>> patches from Tejun Heo and Albert Lee.  This update contains the
>> following major libata
>>
>> CHANGES:
>> * Rewritten error handling. This is a major piece of work, even
>>   though it will be rarely seen.  The new libata EH provides the
>>   foundation for not only improved error handling, but also new features
>>   such as device hotplug or command queueing. (Tejun Heo)
>>
>> * PIO-based I/O is now IRQ-driven by default, rather than polled
>>   in a kernel thread.  The polling path will continue to exist for
>>   controllers that need it, and other special cases. (Albert Lee)
>>
>> * Core support for command queueing (Jens Axboe, Tejun Heo)
>>
>> * Support for NCQ-style command queueing (Jens Axboe, Tejun Heo)
>>
>> * Increase max-sectors dramatically, for LBA48 devices (Tejun Heo?)
>>
>> * Other minor changes, from myself and others.
> 
> How about PATA?  Specifically intel's IDE chip.  I have a machine that I can
> blow the hard drive away if I want to.

Always helpful.  ata_piix should support Intel PATA controllers, modulo 
some bugs that Alan is fixing / has fixed.  If your PCI ID isn't listed, 
you will have to add it, and an associated info entry.  Again, take a 
look at Alan's libata PATA patches for guidance.

	Jeff

Re: [RFT] major libata update

[Wakko Warner]

Jeff Garzik wrote:
> 
> After much development and review, I merged a massive pile of libata
> patches from Tejun Heo and Albert Lee.  This update contains the
> following major libata
> 
> CHANGES:
> * Rewritten error handling. This is a major piece of work, even
>   though it will be rarely seen.  The new libata EH provides the
>   foundation for not only improved error handling, but also new features
>   such as device hotplug or command queueing. (Tejun Heo)
> 
> * PIO-based I/O is now IRQ-driven by default, rather than polled
>   in a kernel thread.  The polling path will continue to exist for
>   controllers that need it, and other special cases. (Albert Lee)
> 
> * Core support for command queueing (Jens Axboe, Tejun Heo)
> 
> * Support for NCQ-style command queueing (Jens Axboe, Tejun Heo)
> 
> * Increase max-sectors dramatically, for LBA48 devices (Tejun Heo?)
> 
> * Other minor changes, from myself and others.

How about PATA?  Specifically intel's IDE chip.  I have a machine that I can
blow the hard drive away if I want to.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
 Got Gas???

Re: [RFT] major libata update

[Wakko Warner]

Jeff Garzik wrote:
> Wakko Warner wrote:
> >How about PATA?  Specifically intel's IDE chip.  I have a machine that I 
> >can
> >blow the hard drive away if I want to.
> 
> Always helpful.  ata_piix should support Intel PATA controllers, modulo 
> some bugs that Alan is fixing / has fixed.  If your PCI ID isn't listed, 
> you will have to add it, and an associated info entry.  Again, take a 
> look at Alan's libata PATA patches for guidance.

Do I need his patches as well?  If so, where do I retrieve them?  I lost the
url for it.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
 Got Gas???

Re: [RFT] major libata update

[Jeff Garzik]

Wakko Warner wrote:
> Jeff Garzik wrote:
>> Wakko Warner wrote:
>>> How about PATA?  Specifically intel's IDE chip.  I have a machine that I 
>>> can
>>> blow the hard drive away if I want to.
>> Always helpful.  ata_piix should support Intel PATA controllers, modulo 
>> some bugs that Alan is fixing / has fixed.  If your PCI ID isn't listed, 
>> you will have to add it, and an associated info entry.  Again, take a 
>> look at Alan's libata PATA patches for guidance.
> 
> Do I need his patches as well?  If so, where do I retrieve them?  I lost the
> url for it.

Me too, hopefully he'll chime in.  In any case, it's highly likely that 
things will work out of the box.

	Jeff

Re: [RFT] major libata update

[Avuton Olrich]

On 5/15/06, Jeff Garzik <jeff@garzik.org> wrote:
> * sata_sil and ata_piix also need healthy re-testing of all basic
> functionality.

I'm testing it right now, but with 2.6.17-rc4-git2 I was getting:

May 15 15:42:57 shapeshifter ata2: command 0x25 timeout, stat 0x58 host_stat 0x1
May 15 15:42:57 shapeshifter ata2: translated ATA stat/err 0x58/00 to
SCSI SK/ASC/ASCQ 0xb/47/00
May 15 15:42:57 shapeshifter ata2: status=0x58 { DriveReady
SeekComplete DataRequest }
May 15 15:42:57 shapeshifter sd 1:0:0:0: SCSI error: return code = 0x8000002
May 15 15:42:57 shapeshifter sda: Current: sense key=0xb
May 15 15:42:57 shapeshifter ASC=0x47 ASCQ=0x0
May 15 15:42:57 shapeshifter end_request: I/O error, dev sda, sector 974708575

(sector varies)

After large ssh transfers. I moved to 2.6.17-rc4-git2 because
2.6.16.16 was doing the same. This is a new 500gb sata2 drive on
sata_sil so I guess this could be hardware, but I wanted to make sure
before I go returning this thing. After this obviously I have to sysrq
sync, ro and reboot. This also causes(?) a NETDEV WATCHDOG: eth2:
transmit timed out, sometimes this ata timeout doesn't yet occur and I
just get the netdev watchdog. This has not yet happened with the new
patch, though I'm only 1 hr into testing with it.


If you want to take a peek at my config:
http://olricha.homelinux.net:8080/ss.config
-- 
avuton
--
 Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [RFT] major libata update

[Tejun Heo]

Jeff Garzik wrote:
> Tomasz Torcz wrote:
>> On Mon, May 15, 2006 at 01:00:06PM -0400, Jeff Garzik wrote:
>>> After much development and review, I merged a massive pile of libata
>>> patches from Tejun Heo and Albert Lee.  This update contains the
>>> following major libata
>>
>>   Any plans to merge http://home-tj.org/wiki/index.php/Sil_m15w ? Or
>> maybe it's merged already?
>>   Seagate firmware update seems to be available only for OEMs, so this
>> quirk is pretty helpful for end users.
> 
> Its a question of staging.  This still lives in the 'sii-m15w' branch of 
> libata-dev.git, but if we throw too many _classes_ of changes into the 
> same big lump, then it becomes much more difficult to discern which 
> changes caused which failures.
> 
> Since sata_sil has seen several changes, and since the sii-m15w problems 
> are so difficult to diagnose properly, its easier to separate that out.

Are you planning on merging sil_m15w workaround?

FYI, from the first time it was submitted (last summer) till 2.6.16, it 
took very little effort to maintain it.  The current big update would 
necessitate some changes to it but I don't think it will be too much 
work.  My experience says m15w doesn't add too much maintenance overhead.

Also, what's the merge plan for hotplug/PM?  Together into 2.6.18?  Or 
are we looking further down?

-- 
tejun

Re: [RFT] major libata update

[Tejun Heo]

Avuton Olrich wrote:
> On 5/15/06, Jeff Garzik <jeff@garzik.org> wrote:
>> * sata_sil and ata_piix also need healthy re-testing of all basic
>> functionality.
> 
> I'm testing it right now, but with 2.6.17-rc4-git2 I was getting:
> 
> May 15 15:42:57 shapeshifter ata2: command 0x25 timeout, stat 0x58 
> host_stat 0x1
> May 15 15:42:57 shapeshifter ata2: translated ATA stat/err 0x58/00 to
> SCSI SK/ASC/ASCQ 0xb/47/00
> May 15 15:42:57 shapeshifter ata2: status=0x58 { DriveReady
> SeekComplete DataRequest }
> May 15 15:42:57 shapeshifter sd 1:0:0:0: SCSI error: return code = 
> 0x8000002
> May 15 15:42:57 shapeshifter sda: Current: sense key=0xb
> May 15 15:42:57 shapeshifter ASC=0x47 ASCQ=0x0
> May 15 15:42:57 shapeshifter end_request: I/O error, dev sda, sector 
> 974708575

2.6.17-rc4-git2 doesn't contain the changes.  You're still using old EH. 
  To test the updates, pull #upstream from libata-dev git tree which can 
be found on http://kernel.org/git.  Otherwise, you can try 
libata-tj-stable patch over 2.6.16.16 located at

http://home-tj.org/wiki/index.php/Libata-tj-stable.

-- 
tejun

Re: [RFT] major libata update

[Alan Cox]

On Llu, 2006-05-15 at 19:02 -0400, Wakko Warner wrote:
> How about PATA?  Specifically intel's IDE chip.  I have a machine that I can
> blow the hard drive away if I want to.

Give the patch on zeniv.linux.org.uk/~alan/IDE a go in that case and let
me know how it behaves.

Alan

Re: [RFT] major libata update

[Alan Cox]

On Llu, 2006-05-15 at 19:00 -0400, Jeff Garzik wrote:
> Always helpful.  ata_piix should support Intel PATA controllers, modulo 
> some bugs that Alan is fixing / has fixed.  If your PCI ID isn't listed, 
> you will have to add it, and an associated info entry.  Again, take a 
> look at Alan's libata PATA patches for guidance.

Without the patches I've got everything non ATAPI should work (ATAPI
will I think 99% work) and anything that is ICH or later (UDMA66 or
higher) should behave correctly.

PIIX/MPIIX won't work with it, and UDMA33 chips may work providing the
scribbles to the wrong register happen to be harmless.

Alan

Re: [RFT] major libata update

[Jeff Garzik]

Wakko Warner wrote:
> Alan Cox wrote:
>> On Llu, 2006-05-15 at 19:02 -0400, Wakko Warner wrote:
>>> How about PATA?  Specifically intel's IDE chip.  I have a machine that I can
>>> blow the hard drive away if I want to.
>> Give the patch on zeniv.linux.org.uk/~alan/IDE a go in that case and let
>> me know how it behaves.
> 
> I noticed one hunk failed with 2.6.17-rc4 when using
> patch-2.6.17-rc3-ide2.gz
> 
> It was only the version string so I should be ok.  As I said, if it blows up
> on me, that's ok.
> 
> I attempted to patch Jeff's libata1 over top of this, it failed miserably.
> 
> When I patched Jeff's libata1 over 2.6.17-rc4, it was ok, except for 2
> files:

oh, its almost certain the patches will conflict.  My suggestion was 
more of a reference-<here>-if-things-break.

	Jeff

Re: [RFT] major libata update

[Wakko Warner]

Alan Cox wrote:
> On Llu, 2006-05-15 at 19:02 -0400, Wakko Warner wrote:
> > How about PATA?  Specifically intel's IDE chip.  I have a machine that I can
> > blow the hard drive away if I want to.
> 
> Give the patch on zeniv.linux.org.uk/~alan/IDE a go in that case and let
> me know how it behaves.

I noticed one hunk failed with 2.6.17-rc4 when using
patch-2.6.17-rc3-ide2.gz

It was only the version string so I should be ok.  As I said, if it blows up
on me, that's ok.

I attempted to patch Jeff's libata1 over top of this, it failed miserably.

When I patched Jeff's libata1 over 2.6.17-rc4, it was ok, except for 2
files:
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
32 out of 32 hunks ignored -- saving rejects to file drivers/scsi/ahci.c.rej
patching file drivers/scsi/ata_piix.c
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
5 out of 5 hunks ignored -- saving rejects to file
drivers/scsi/ata_piix.c.rej




If you're curious, alan's patch + jeff's patch:
patching file drivers/scsi/Makefile
Hunk #1 succeeded at 201 (offset 37 lines).
patching file drivers/scsi/ahci.c
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
32 out of 32 hunks ignored -- saving rejects to file drivers/scsi/ahci.c.rej
patching file drivers/scsi/ata_piix.c
Hunk #1 FAILED at 93.
Hunk #2 succeeded at 299 with fuzz 2 (offset 56 lines).
Hunk #3 succeeded at 335 with fuzz 2 (offset 61 lines).
Hunk #4 succeeded at 700 (offset 210 lines).
Hunk #5 succeeded at 805 (offset 234 lines).
1 out of 5 hunks FAILED -- saving rejects to file drivers/scsi/ata_piix.c.rej
patching file drivers/scsi/libata-bmdma.c
patching file drivers/scsi/libata-core.c
Hunk #23 succeeded at 1503 (offset 6 lines).
Hunk #24 succeeded at 1573 (offset 6 lines).
Hunk #25 succeeded at 1587 (offset 6 lines).
Hunk #26 succeeded at 1624 (offset 6 lines).
Hunk #27 succeeded at 1644 (offset 6 lines).
Hunk #28 succeeded at 1674 (offset 6 lines).
Hunk #29 succeeded at 1713 (offset 6 lines).
Hunk #30 succeeded at 1979 (offset 6 lines).
Hunk #31 succeeded at 2218 (offset 6 lines).
Hunk #32 succeeded at 2228 (offset 6 lines).
Hunk #33 succeeded at 2321 (offset 6 lines).
Hunk #34 succeeded at 2348 (offset 6 lines).
Hunk #35 succeeded at 2416 (offset 6 lines).
Hunk #36 succeeded at 2425 (offset 6 lines).
Hunk #37 succeeded at 2463 (offset 6 lines).
Hunk #38 succeeded at 2493 (offset 6 lines).
Hunk #39 succeeded at 2501 (offset 6 lines).
Hunk #40 succeeded at 2519 (offset 6 lines).
Hunk #41 succeeded at 2537 (offset 6 lines).
Hunk #42 succeeded at 2549 (offset 6 lines).
Hunk #43 succeeded at 2628 (offset 6 lines).
Hunk #44 succeeded at 2687 (offset 6 lines).
Hunk #45 succeeded at 2695 (offset 6 lines).
Hunk #46 succeeded at 2720 (offset 6 lines).
Hunk #47 succeeded at 2744 (offset 6 lines).
Hunk #48 succeeded at 2759 (offset 6 lines).
Hunk #49 succeeded at 2830 (offset 6 lines).
Hunk #50 succeeded at 2850 (offset 6 lines).
Hunk #51 succeeded at 2874 (offset 6 lines).
Hunk #52 succeeded at 2886 (offset 6 lines).
Hunk #53 succeeded at 2992 (offset 6 lines).
Hunk #54 FAILED at 3006.
Hunk #55 succeeded at 3068 (offset 1 line).
Hunk #56 succeeded at 3076 (offset 1 line).
Hunk #57 succeeded at 3091 (offset 1 line).
Hunk #58 succeeded at 3101 (offset 1 line).
Hunk #59 succeeded at 3114 (offset 1 line).
Hunk #60 succeeded at 3259 (offset 1 line).
Hunk #61 succeeded at 3496 (offset 1 line).
Hunk #62 succeeded at 3634 (offset -28 lines).
Hunk #63 FAILED at 3659.
Hunk #64 succeeded at 3761 with fuzz 1 (offset -28 lines).
Hunk #65 succeeded at 3786 (offset -28 lines).
Hunk #66 FAILED at 3813.
Hunk #67 FAILED at 3849.
Hunk #68 succeeded at 4207 (offset -27 lines).
Hunk #69 succeeded at 4226 (offset -27 lines).
Hunk #70 succeeded at 4269 (offset -27 lines).
Hunk #71 succeeded at 4450 (offset -27 lines).
Hunk #72 succeeded at 4515 (offset -27 lines).
Hunk #73 succeeded at 4643 (offset -27 lines).
Hunk #74 succeeded at 4711 (offset -27 lines).
Hunk #75 succeeded at 4749 (offset -27 lines).
Hunk #76 succeeded at 4764 (offset -27 lines).
Hunk #77 succeeded at 4937 (offset -27 lines).
Hunk #78 succeeded at 4959 (offset -27 lines).
Hunk #79 succeeded at 5112 (offset -23 lines).
Hunk #80 succeeded at 5126 (offset -23 lines).
Hunk #81 succeeded at 5193 (offset -23 lines).
Hunk #82 succeeded at 5266 (offset -21 lines).
Hunk #83 succeeded at 5318 (offset -15 lines).
Hunk #84 succeeded at 5413 (offset -15 lines).
Hunk #85 succeeded at 5577 (offset -15 lines).
Hunk #86 succeeded at 5636 (offset -15 lines).
Hunk #87 succeeded at 5661 (offset -13 lines).
Hunk #88 succeeded at 5682 (offset -13 lines).
Hunk #89 succeeded at 5721 (offset -13 lines).
4 out of 89 hunks FAILED -- saving rejects to file drivers/scsi/libata-core.c.rej
patching file drivers/scsi/libata-eh.c
patching file drivers/scsi/libata-scsi.c
patching file drivers/scsi/libata.h
patching file drivers/scsi/pdc_adma.c
patching file drivers/scsi/sata_mv.c
Hunk #2 succeeded at 682 (offset 2 lines).
Hunk #3 succeeded at 1311 (offset 2 lines).
Hunk #4 succeeded at 1398 (offset 2 lines).
Hunk #5 succeeded at 1419 (offset 2 lines).
Hunk #6 succeeded at 1936 (offset 2 lines).
Hunk #7 succeeded at 1962 (offset 2 lines).
Hunk #8 succeeded at 1994 (offset 2 lines).
Hunk #9 succeeded at 2025 (offset 2 lines).
patching file drivers/scsi/sata_nv.c
Hunk #2 succeeded at 280 (offset 1 line).
patching file drivers/scsi/sata_promise.c
Hunk #2 succeeded at 438 (offset 2 lines).
Hunk #3 succeeded at 446 (offset 2 lines).
Hunk #4 succeeded at 537 (offset 2 lines).
Hunk #5 succeeded at 680 (offset 2 lines).
patching file drivers/scsi/sata_qstor.c
Hunk #2 succeeded at 176 (offset 1 line).
Hunk #3 succeeded at 395 (offset 1 line).
Hunk #4 succeeded at 428 (offset 1 line).
patching file drivers/scsi/sata_sil.c
Hunk #3 FAILED at 176.
Hunk #4 succeeded at 269 (offset 1 line).
Hunk #5 succeeded at 320 (offset 1 line).
Hunk #6 succeeded at 393 (offset 1 line).
Hunk #7 succeeded at 417 (offset 1 line).
Hunk #8 succeeded at 507 (offset 1 line).
1 out of 8 hunks FAILED -- saving rejects to file drivers/scsi/sata_sil.c.rej
patching file drivers/scsi/sata_sil24.c
Hunk #9 succeeded at 388 with fuzz 2 (offset 1 line).
Hunk #10 succeeded at 415 (offset 1 line).
Hunk #11 succeeded at 425 (offset 1 line).
Hunk #12 succeeded at 434 (offset 1 line).
Hunk #13 succeeded at 442 (offset 1 line).
Hunk #14 succeeded at 510 (offset 1 line).
Hunk #15 succeeded at 580 (offset 1 line).
Hunk #16 succeeded at 661 (offset 1 line).
Hunk #17 succeeded at 687 (offset 1 line).
Hunk #18 succeeded at 699 (offset 1 line).
Hunk #19 succeeded at 709 (offset 1 line).
Hunk #20 succeeded at 729 (offset 1 line).
Hunk #21 succeeded at 890 (offset 1 line).
Hunk #22 succeeded at 903 (offset 1 line).
Hunk #23 succeeded at 940 (offset 1 line).
Hunk #24 succeeded at 1004 (offset 1 line).
Hunk #25 succeeded at 1057 (offset 1 line).
Hunk #26 succeeded at 1115 (offset 1 line).
Hunk #27 succeeded at 1137 (offset 1 line).
patching file drivers/scsi/sata_sis.c
patching file drivers/scsi/sata_svw.c
patching file drivers/scsi/sata_sx4.c
Hunk #2 succeeded at 219 (offset 1 line).
Hunk #3 succeeded at 834 (offset 1 line).
Hunk #4 succeeded at 869 (offset 1 line).
Hunk #5 succeeded at 1377 (offset 1 line).
patching file drivers/scsi/sata_uli.c
patching file drivers/scsi/sata_via.c
patching file drivers/scsi/sata_vsc.c
patching file drivers/scsi/scsi.c
patching file drivers/scsi/scsi_error.c
patching file drivers/scsi/scsi_lib.c
patching file drivers/scsi/scsi_priv.h
patching file include/linux/ata.h
patching file include/linux/libata.h
Hunk #2 succeeded at 45 with fuzz 2.
Hunk #4 FAILED at 123.
Hunk #5 succeeded at 140 (offset 1 line).
Hunk #6 succeeded at 223 (offset 1 line).
Hunk #7 succeeded at 284 (offset 1 line).
Hunk #8 succeeded at 375 (offset 1 line).
Hunk #9 succeeded at 387 (offset 1 line).
Hunk #10 succeeded at 424 (offset 1 line).
Hunk #11 succeeded at 466 (offset 1 line).
Hunk #12 succeeded at 489 (offset 1 line).
Hunk #13 succeeded at 531 (offset 3 lines).
Hunk #14 succeeded at 585 (offset 3 lines).
Hunk #15 succeeded at 610 (offset 3 lines).
Hunk #16 FAILED at 666.
Hunk #17 succeeded at 735 (offset 7 lines).
Hunk #18 succeeded at 821 (offset 7 lines).
Hunk #19 succeeded at 934 (offset 7 lines).
Hunk #20 succeeded at 977 (offset 7 lines).
Hunk #21 succeeded at 1060 (offset 7 lines).
Hunk #22 succeeded at 1097 (offset 7 lines).
2 out of 22 hunks FAILED -- saving rejects to file include/linux/libata.h.rej
patching file include/scsi/scsi_cmnd.h
patching file include/scsi/scsi_eh.h
patching file include/scsi/scsi_host.h


-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
 Got Gas???

Re: [RFT] major libata update

[Jeff Garzik]

Tejun Heo wrote:
> Jeff Garzik wrote:
>> Tomasz Torcz wrote:
>>> On Mon, May 15, 2006 at 01:00:06PM -0400, Jeff Garzik wrote:
>>>> After much development and review, I merged a massive pile of libata
>>>> patches from Tejun Heo and Albert Lee.  This update contains the
>>>> following major libata
>>>
>>>   Any plans to merge http://home-tj.org/wiki/index.php/Sil_m15w ? Or
>>> maybe it's merged already?
>>>   Seagate firmware update seems to be available only for OEMs, so this
>>> quirk is pretty helpful for end users.
>>
>> Its a question of staging.  This still lives in the 'sii-m15w' branch 
>> of libata-dev.git, but if we throw too many _classes_ of changes into 
>> the same big lump, then it becomes much more difficult to discern 
>> which changes caused which failures.
>>
>> Since sata_sil has seen several changes, and since the sii-m15w 
>> problems are so difficult to diagnose properly, its easier to separate 
>> that out.
> 
> Are you planning on merging sil_m15w workaround?

Yes, but after 2.6.18.


> FYI, from the first time it was submitted (last summer) till 2.6.16, it 
> took very little effort to maintain it.  The current big update would 
> necessitate some changes to it but I don't think it will be too much 
> work.  My experience says m15w doesn't add too much maintenance overhead.

Its actively maintained in the 'sii-m15w' branch of libata-dev.git.


> Also, what's the merge plan for hotplug/PM?  Together into 2.6.18?  Or 
> are we looking further down?

Hotplug is reasonable for 2.6.18, but after that its getting a bit much. 
  We need to have some reasonable testing points in the midst of all 
this development :)  I'm happy to maintain an upstream-2.6.19 branch for 
such things, though.  I use tiered branches anyway.

	Jeff

Re: [RFT] major libata update

[Wakko Warner]

Alan Cox wrote:
> On Llu, 2006-05-15 at 19:00 -0400, Jeff Garzik wrote:
> > Always helpful.  ata_piix should support Intel PATA controllers, modulo 
> > some bugs that Alan is fixing / has fixed.  If your PCI ID isn't listed, 
> > you will have to add it, and an associated info entry.  Again, take a 
> > look at Alan's libata PATA patches for guidance.
> 
> Without the patches I've got everything non ATAPI should work (ATAPI
> will I think 99% work) and anything that is ICH or later (UDMA66 or
> higher) should behave correctly.
> 
> PIIX/MPIIX won't work with it, and UDMA33 chips may work providing the
> scribbles to the wrong register happen to be harmless.

The test machine I have is this:
# lspci -v -s 7.1
0000:00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master])
        Flags: bus master, medium devsel, latency 64
        I/O ports at 10a0 [size=16]

# lspci -v -s 7.1 -n
0000:00:07.1 0101: 8086:7111 (rev 01) (prog-if 80 [Master])
        Flags: bus master, medium devsel, latency 64
        I/O ports at 10a0 [size=16]

#

If this won't work, let me know.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
 Got Gas???

Re: [RFT] major libata update

[Jeff Garzik]

Avuton Olrich wrote:
> On 5/15/06, Jeff Garzik <jeff@garzik.org> wrote:
>> * sata_sil and ata_piix also need healthy re-testing of all basic
>> functionality.
> 
> I'm testing it right now, but with 2.6.17-rc4-git2 I was getting:

Testing what?  sata_sil?  Please provide full dmesg, there's a lot of 
missing information.


> May 15 15:42:57 shapeshifter ata2: command 0x25 timeout, stat 0x58 
> host_stat 0x1
> May 15 15:42:57 shapeshifter ata2: translated ATA stat/err 0x58/00 to
> SCSI SK/ASC/ASCQ 0xb/47/00
> May 15 15:42:57 shapeshifter ata2: status=0x58 { DriveReady
> SeekComplete DataRequest }
> May 15 15:42:57 shapeshifter sd 1:0:0:0: SCSI error: return code = 
> 0x8000002
> May 15 15:42:57 shapeshifter sda: Current: sense key=0xb
> May 15 15:42:57 shapeshifter ASC=0x47 ASCQ=0x0
> May 15 15:42:57 shapeshifter end_request: I/O error, dev sda, sector 
> 974708575
> 
> (sector varies)
> 
> After large ssh transfers. I moved to 2.6.17-rc4-git2 because
> 2.6.16.16 was doing the same. This is a new 500gb sata2 drive on
> sata_sil so I guess this could be hardware, but I wanted to make sure
> before I go returning this thing. After this obviously I have to sysrq
> sync, ro and reboot. This also causes(?) a NETDEV WATCHDOG: eth2:
> transmit timed out, sometimes this ata timeout doesn't yet occur and I
> just get the netdev watchdog. This has not yet happened with the new
> patch, though I'm only 1 hr into testing with it.

Yes, its entirely possible that the new patch will address this.  Please 
do keep us posted.

Thanks,

	Jeff

Re: [RFT] major libata update

[Tejun Heo]

Jeff Garzik wrote:
> Tejun Heo wrote:
>> Jeff Garzik wrote:
>>> Tomasz Torcz wrote:
>>>> On Mon, May 15, 2006 at 01:00:06PM -0400, Jeff Garzik wrote:
>>>>> After much development and review, I merged a massive pile of libata
>>>>> patches from Tejun Heo and Albert Lee.  This update contains the
>>>>> following major libata
>>>>
>>>>   Any plans to merge http://home-tj.org/wiki/index.php/Sil_m15w ? Or
>>>> maybe it's merged already?
>>>>   Seagate firmware update seems to be available only for OEMs, so this
>>>> quirk is pretty helpful for end users.
>>>
>>> Its a question of staging.  This still lives in the 'sii-m15w' branch 
>>> of libata-dev.git, but if we throw too many _classes_ of changes into 
>>> the same big lump, then it becomes much more difficult to discern 
>>> which changes caused which failures.
>>>
>>> Since sata_sil has seen several changes, and since the sii-m15w 
>>> problems are so difficult to diagnose properly, its easier to 
>>> separate that out.
>>
>> Are you planning on merging sil_m15w workaround?
> 
> Yes, but after 2.6.18.

Cool.

>> FYI, from the first time it was submitted (last summer) till 2.6.16, 
>> it took very little effort to maintain it.  The current big update 
>> would necessitate some changes to it but I don't think it will be too 
>> much work.  My experience says m15w doesn't add too much maintenance 
>> overhead.
> 
> Its actively maintained in the 'sii-m15w' branch of libata-dev.git.
> 

I have been maintaining my own.  :)  BTW, with 2.6.16, m15_cxt has to 
move from qc->private_data to ap->private_data.

> 
>> Also, what's the merge plan for hotplug/PM?  Together into 2.6.18?  Or 
>> are we looking further down?
> 
> Hotplug is reasonable for 2.6.18, but after that its getting a bit much. 
>  We need to have some reasonable testing points in the midst of all this 
> development :)  I'm happy to maintain an upstream-2.6.19 branch for such 
> things, though.  I use tiered branches anyway.

Good enough for me.  I want to see hotplug in 2.6.18 but link/PM stuff 
can definitely wait for 2.6.19.

-- 
tejun

Re: [RFT] major libata update

[Avuton Olrich]

On 5/15/06, Jeff Garzik <jeff@garzik.org> wrote:
> Avuton Olrich wrote:
> > On 5/15/06, Jeff Garzik <jeff@garzik.org> wrote:
> >> * sata_sil and ata_piix also need healthy re-testing of all basic
> >> functionality.
> >
> > I'm testing it right now, but with 2.6.17-rc4-git2 I was getting:
>
> Testing what?  sata_sil?  Please provide full dmesg, there's a lot of
> missing information.

sata_sil, sorry, I thought I provided a good subset of the timeout message:

May 15 15:41:27 shapeshifter ata2: command 0x25 timeout, stat 0x58 host_stat 0x1
May 15 15:41:27 shapeshifter ata2: translated ATA stat/err 0x58/00 to
SCSI SK/ASC/ASCQ 0xb/47/00
May 15 15:41:27 shapeshifter ata2: status=0x58 { DriveReady
SeekComplete DataRequest }
May 15 15:41:27 shapeshifter sd 1:0:0:0: SCSI error: return code = 0x8000002
May 15 15:41:27 shapeshifter sda: Current: sense key=0xb
May 15 15:41:27 shapeshifter ASC=0x47 ASCQ=0x0
May 15 15:41:27 shapeshifter end_request: I/O error, dev sda, sector 974708551
May 15 15:41:57 shapeshifter ata2: command 0x25 timeout, stat 0x58 host_stat 0x1
May 15 15:41:57 shapeshifter ata2: translated ATA stat/err 0x58/00 to
SCSI SK/ASC/ASCQ 0xb/47/00
May 15 15:41:57 shapeshifter ata2: status=0x58 { DriveReady
SeekComplete DataRequest }
May 15 15:41:57 shapeshifter sd 1:0:0:0: SCSI error: return code = 0x8000002
May 15 15:41:57 shapeshifter sda: Current: sense key=0xb
May 15 15:41:57 shapeshifter ASC=0x47 ASCQ=0x0
May 15 15:41:57 shapeshifter end_request: I/O error, dev sda, sector 974708559
May 15 15:42:27 shapeshifter ata2: command 0x25 timeout, stat 0x58 host_stat 0x1
May 15 15:42:27 shapeshifter ata2: translated ATA stat/err 0x58/00 to
SCSI SK/ASC/ASCQ 0xb/47/00
May 15 15:42:27 shapeshifter ata2: status=0x58 { DriveReady
SeekComplete DataRequest }
May 15 15:42:27 shapeshifter sd 1:0:0:0: SCSI error: return code = 0x8000002
May 15 15:42:27 shapeshifter sda: Current: sense key=0xb
May 15 15:42:27 shapeshifter ASC=0x47 ASCQ=0x0
May 15 15:42:27 shapeshifter end_request: I/O error, dev sda, sector 974708567
May 15 15:42:57 shapeshifter ata2: command 0x25 timeout, stat 0x58 host_stat 0x1
May 15 15:42:57 shapeshifter ata2: translated ATA stat/err 0x58/00 to
SCSI SK/ASC/ASCQ 0xb/47/00
May 15 15:42:57 shapeshifter ata2: status=0x58 { DriveReady
SeekComplete DataRequest }
May 15 15:42:57 shapeshifter sd 1:0:0:0: SCSI error: return code = 0x8000002
May 15 15:42:57 shapeshifter sda: Current: sense key=0xb
May 15 15:42:57 shapeshifter ASC=0x47 ASCQ=0x0
May 15 15:42:57 shapeshifter end_request: I/O error, dev sda, sector 974708575
May 15 15:43:27 shapeshifter ata2: command 0x25 timeout, stat 0x58 host_stat 0x1
May 15 15:43:27 shapeshifter ata2: translated ATA stat/err 0x58/00 to
SCSI SK/ASC/ASCQ 0xb/47/00
May 15 15:43:27 shapeshifter ata2: status=0x58 { DriveReady
SeekComplete DataRequest }
May 15 15:43:27 shapeshifter sd 1:0:0:0: SCSI error: return code = 0x8000002
May 15 15:43:27 shapeshifter sda: Current: sense key=0xb
May 15 15:43:27 shapeshifter ASC=0x47 ASCQ=0x0
May 15 15:43:27 shapeshifter end_request: I/O error, dev sda, sector 974708583
May 15 15:43:57 shapeshifter ata2: command 0x25 timeout, stat 0x58 host_stat 0x1
May 15 15:43:57 shapeshifter ata2: translated ATA stat/err 0x58/00 to
SCSI SK/ASC/ASCQ 0xb/47/00
May 15 15:43:57 shapeshifter ata2: status=0x58 { DriveReady
SeekComplete DataRequest }
May 15 15:43:57 shapeshifter sd 1:0:0:0: SCSI error: return code = 0x8000002
May 15 15:43:57 shapeshifter sda: Current: sense key=0xb
May 15 15:43:57 shapeshifter ASC=0x47 ASCQ=0x0
May 15 15:43:57 shapeshifter end_request: I/O error, dev sda, sector 974708591
May 15 15:44:02 shapeshifter SysRq : Emergency Sync
May 15 15:44:02 shapeshifter Emergency Sync complete
May 15 15:44:27 shapeshifter ata2: command 0x25 timeout, stat 0x58 host_stat 0x1
May 15 15:44:27 shapeshifter ata2: translated ATA stat/err 0x58/00 to
SCSI SK/ASC/ASCQ 0xb/47/00
May 15 15:44:27 shapeshifter ata2: status=0x58 { DriveReady
SeekComplete DataRequest }
May 15 15:44:27 shapeshifter sd 1:0:0:0: SCSI error: return code = 0x8000002
May 15 15:44:27 shapeshifter sda: Current: sense key=0xb
May 15 15:44:27 shapeshifter ASC=0x47 ASCQ=0x0
May 15 15:44:27 shapeshifter end_request: I/O error, dev sda, sector 974708599
May 15 15:44:35 shapeshifter NETDEV WATCHDOG: eth2: transmit timed out

> > After large ssh transfers. I moved to 2.6.17-rc4-git2 because
> > 2.6.16.16 was doing the same. This is a new 500gb sata2 drive on
> > sata_sil so I guess this could be hardware, but I wanted to make sure
> > before I go returning this thing. After this obviously I have to sysrq
> > sync, ro and reboot. This also causes(?) a NETDEV WATCHDOG: eth2:
> > transmit timed out, sometimes this ata timeout doesn't yet occur and I
> > just get the netdev watchdog. This has not yet happened with the new
> > patch, though I'm only 1 hr into testing with it.
>
> Yes, its entirely possible that the new patch will address this.  Please
> do keep us posted.
>
> Thanks,
>
>         Jeff

OK, upon further testing I believe the patch helps out tremendously, I
don't get the timeout message (yet), though I still get a netdev
watchdog. I've gotten this with two different ethernet ports/drivers
so I believe this not to be due to the ethernet driver.

Sample dmesg output:
NETDEV WATCHDOG: eth2: transmit timed out

The time that it actually takes to happen is variable, though it
hasn't happened to me in under 20 minutes yet.

-- 
avuton
--
 Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [RFT] major libata update

[Tejun Heo]

Tejun Heo wrote:
> Jeff Garzik wrote:
>> Tejun Heo wrote:
>>> Jeff Garzik wrote:
>>>> Tomasz Torcz wrote:
>>>>> On Mon, May 15, 2006 at 01:00:06PM -0400, Jeff Garzik wrote:
>>>>>> After much development and review, I merged a massive pile of libata
>>>>>> patches from Tejun Heo and Albert Lee.  This update contains the
>>>>>> following major libata
>>>>>
>>>>>   Any plans to merge http://home-tj.org/wiki/index.php/Sil_m15w ? Or
>>>>> maybe it's merged already?
>>>>>   Seagate firmware update seems to be available only for OEMs, so this
>>>>> quirk is pretty helpful for end users.
>>>>
>>>> Its a question of staging.  This still lives in the 'sii-m15w' 
>>>> branch of libata-dev.git, but if we throw too many _classes_ of 
>>>> changes into the same big lump, then it becomes much more difficult 
>>>> to discern which changes caused which failures.
>>>>
>>>> Since sata_sil has seen several changes, and since the sii-m15w 
>>>> problems are so difficult to diagnose properly, its easier to 
>>>> separate that out.
>>>
>>> Are you planning on merging sil_m15w workaround?
>>
>> Yes, but after 2.6.18.
> 
> Cool.
> 
>>> FYI, from the first time it was submitted (last summer) till 2.6.16, 
>>> it took very little effort to maintain it.  The current big update 
>>> would necessitate some changes to it but I don't think it will be too 
>>> much work.  My experience says m15w doesn't add too much maintenance 
>>> overhead.
>>
>> Its actively maintained in the 'sii-m15w' branch of libata-dev.git.
>>
> 
> I have been maintaining my own.  :)  BTW, with 2.6.16, m15_cxt has to 
> move from qc->private_data to ap->private_data.

Okay, we've been talking about different things.  You're talking about 
excluding non-affected drives from m15w blacklist while I'm talking 
about the handle-large-writes-by-qc-rewrite m15w workaround.  The URL 
Tomasz Torcz wrote contains the workaround.

-- 
tejun

Re: [RFT] major libata update

[Avuton Olrich]

On 5/15/06, Jeff Garzik <jeff@garzik.org> wrote:
> Avuton Olrich wrote:
> > On 5/15/06, Jeff Garzik <jeff@garzik.org> wrote:
> >> * sata_sil and ata_piix also need healthy re-testing of all basic
> >> functionality.
> >
> > I'm testing it right now, but with 2.6.17-rc4-git2 I was getting:
>
> Testing what?  sata_sil?  Please provide full dmesg, there's a lot of
> missing information.

More followup, it did finally error out on me:

Not sure if it helps any, but this is a sata2 disk with a sata
interface. This is rc4-git2 with the libata patch from the beginning
of this thread, using sata_sil.

dmesg:
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x3 frozen
ata1.00: (BMDMA stat 0x1)
ata1.00: tag 0 cmd 0x25 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata1: soft resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: configured for UDMA/100
ata1: EH complete
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x3 frozen
ata1.00: (BMDMA stat 0x1)
ata1.00: tag 0 cmd 0x25 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata1: soft resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: configured for UDMA/100
ata1: EH complete
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x3 frozen
ata1.00: (BMDMA stat 0x1)
ata1.00: tag 0 cmd 0x25 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata1: soft resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: configured for UDMA/100
ata1: EH complete
ata1.00: limiting speed to UDMA/66
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x3 frozen
ata1.00: (BMDMA stat 0x1)
ata1.00: tag 0 cmd 0x25 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata1: soft resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: configured for UDMA/66
ata1: EH complete
ata1.00: limiting speed to UDMA/44
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x3 frozen
ata1.00: (BMDMA stat 0x1)
ata1.00: tag 0 cmd 0x25 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata1: soft resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: configured for UDMA/44
ata1: EH complete
ata1.00: limiting speed to UDMA/33
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x3 frozen
ata1.00: (BMDMA stat 0x1)
ata1.00: tag 0 cmd 0x25 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata1: soft resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: configured for UDMA/33
sd 0:0:0:0: SCSI error: return code = 0x8000002
sda: Current: sense key=0xb
    ASC=0x0 ASCQ=0x0
end_request: I/O error, dev sda, sector 703661647
ata1: EH complete
ata1.00: limiting speed to UDMA/25
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x3 frozen
ata1.00: (BMDMA stat 0x1)
ata1.00: tag 0 cmd 0x25 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata1: soft resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: configured for UDMA/25
ata1: EH complete
NETDEV WATCHDOG: eth2: transmit timed out
ata1.00: limiting speed to UDMA/16
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x3 frozen
ata1.00: (BMDMA stat 0x1)
ata1.00: tag 0 cmd 0x25 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata1: soft resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: configured for UDMA/16
ata1: EH complete
ata1.00: limiting speed to PIO4
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x3 frozen
ata1.00: (BMDMA stat 0x1)
ata1.00: tag 0 cmd 0x25 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata1: soft resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: configured for PIO4
ata1: EH complete
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out, tx_status 00 status e000.
  diagnostics: net 0cc0 media 8080 dma 000000a0 fifo 8800
  Flags; bus-master 1, dirty 18790(6) current 18806(6)
  Transmit list 37e3c5c0 vs. f7e3c5c0.
  0: @f7e3c200  length 8000002a status 0000002a
  1: @f7e3c2a0  length 8000002a status 0000002a
  2: @f7e3c340  length 8000002a status 0000002a
  3: @f7e3c3e0  length 8000002a status 0000002a
  4: @f7e3c480  length 8000002a status 8000002a
  5: @f7e3c520  length 8000002a status 8000002a
  6: @f7e3c5c0  length 8000005f status 0000005f
  7: @f7e3c660  length 8000005f status 0000005f
  8: @f7e3c700  length 8000002a status 0000002a
  9: @f7e3c7a0  length 8000002a status 0000002a
  10: @f7e3c840  length 8000002a status 0000002a
  11: @f7e3c8e0  length 8000002a status 0000002a
  12: @f7e3c980  length 8000002a status 0000002a
  13: @f7e3ca20  length 8000002a status 0000002a
  14: @f7e3cac0  length 8000002a status 0000002a
  15: @f7e3cb60  length 8000002a status 0000002a
eth0: Resetting the Tx ring pointer.
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out, tx_status 00 status e000.
  diagnostics: net 0cc0 media 8080 dma 000000a0 fifo 8800
  Flags; bus-master 1, dirty 18790(6) current 18806(6)
  Transmit list 37e3c5c0 vs. f7e3c5c0.
  0: @f7e3c200  length 8000002a status 0000002a
  1: @f7e3c2a0  length 8000002a status 0000002a
  2: @f7e3c340  length 8000002a status 0000002a
  3: @f7e3c3e0  length 8000002a status 0000002a
  4: @f7e3c480  length 8000002a status 8000002a
  5: @f7e3c520  length 8000002a status 8000002a
  6: @f7e3c5c0  length 8000005f status 0000005f
  7: @f7e3c660  length 8000005f status 0000005f
  8: @f7e3c700  length 8000002a status 0000002a
  9: @f7e3c7a0  length 8000002a status 0000002a
  10: @f7e3c840  length 8000002a status 0000002a
  11: @f7e3c8e0  length 8000002a status 0000002a
  12: @f7e3c980  length 8000002a status 0000002a
  13: @f7e3ca20  length 8000002a status 0000002a
  14: @f7e3cac0  length 8000002a status 0000002a
  15: @f7e3cb60  length 8000002a status 0000002a
eth0: Resetting the Tx ring pointer.
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out, tx_status 00 status e000.
  diagnostics: net 0cc0 media 8080 dma 000000a0 fifo 8800
  Flags; bus-master 1, dirty 18790(6) current 18806(6)
  Transmit list 37e3c5c0 vs. f7e3c5c0.
  0: @f7e3c200  length 8000002a status 0000002a
  1: @f7e3c2a0  length 8000002a status 0000002a
  2: @f7e3c340  length 8000002a status 0000002a
  3: @f7e3c3e0  length 8000002a status 0000002a
  4: @f7e3c480  length 8000002a status 8000002a
  5: @f7e3c520  length 8000002a status 8000002a
  6: @f7e3c5c0  length 8000005f status 0000005f
  7: @f7e3c660  length 8000005f status 0000005f
  8: @f7e3c700  length 8000002a status 0000002a
  9: @f7e3c7a0  length 8000002a status 0000002a
  10: @f7e3c840  length 8000002a status 0000002a
  11: @f7e3c8e0  length 8000002a status 0000002a
  12: @f7e3c980  length 8000002a status 0000002a
  13: @f7e3ca20  length 8000002a status 0000002a
  14: @f7e3cac0  length 8000002a status 0000002a
  15: @f7e3cb60  length 8000002a status 0000002a
eth0: Resetting the Tx ring pointer.
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out, tx_status 00 status e000.
  diagnostics: net 0cc0 media 8080 dma 000000a0 fifo 8800
  Flags; bus-master 1, dirty 18790(6) current 18806(6)
  Transmit list 37e3c5c0 vs. f7e3c5c0.
  0: @f7e3c200  length 8000002a status 0000002a
  1: @f7e3c2a0  length 8000002a status 0000002a
  2: @f7e3c340  length 8000002a status 0000002a
  3: @f7e3c3e0  length 8000002a status 0000002a
  4: @f7e3c480  length 8000002a status 8000002a
  5: @f7e3c520  length 8000002a status 8000002a
  6: @f7e3c5c0  length 8000005f status 0000005f
  7: @f7e3c660  length 8000005f status 0000005f
  8: @f7e3c700  length 8000002a status 0000002a
  9: @f7e3c7a0  length 8000002a status 0000002a
  10: @f7e3c840  length 8000002a status 0000002a
  11: @f7e3c8e0  length 8000002a status 0000002a
  12: @f7e3c980  length 8000002a status 0000002a
  13: @f7e3ca20  length 8000002a status 0000002a
  14: @f7e3cac0  length 8000002a status 0000002a
  15: @f7e3cb60  length 8000002a status 0000002a
eth0: Resetting the Tx ring pointer.
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out, tx_status 00 status e000.
  diagnostics: net 0cc0 media 8080 dma 000000a0 fifo 8800
  Flags; bus-master 1, dirty 18790(6) current 18806(6)
  Transmit list 37e3c5c0 vs. f7e3c5c0.
  0: @f7e3c200  length 8000002a status 0000002a
  1: @f7e3c2a0  length 8000002a status 0000002a
  2: @f7e3c340  length 8000002a status 0000002a
  3: @f7e3c3e0  length 8000002a status 0000002a
  4: @f7e3c480  length 8000002a status 8000002a
  5: @f7e3c520  length 8000002a status 8000002a
  6: @f7e3c5c0  length 8000005f status 0000005f
  7: @f7e3c660  length 8000005f status 0000005f
  8: @f7e3c700  length 8000002a status 0000002a
  9: @f7e3c7a0  length 8000002a status 0000002a
  10: @f7e3c840  length 8000002a status 0000002a
  11: @f7e3c8e0  length 8000002a status 0000002a
  12: @f7e3c980  length 8000002a status 0000002a
  13: @f7e3ca20  length 8000002a status 0000002a
  14: @f7e3cac0  length 8000002a status 0000002a
  15: @f7e3cb60  length 8000002a status 0000002a
eth0: Resetting the Tx ring pointer.
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out, tx_status 00 status e000.
  diagnostics: net 0cc0 media 8080 dma 000000a0 fifo 8800
  Flags; bus-master 1, dirty 18790(6) current 18806(6)
  Transmit list 37e3c5c0 vs. f7e3c5c0.
  0: @f7e3c200  length 8000002a status 0000002a
  1: @f7e3c2a0  length 8000002a status 0000002a
  2: @f7e3c340  length 8000002a status 0000002a
  3: @f7e3c3e0  length 8000002a status 0000002a
  4: @f7e3c480  length 8000002a status 8000002a
  5: @f7e3c520  length 8000002a status 8000002a
  6: @f7e3c5c0  length 8000005f status 0000005f
  7: @f7e3c660  length 8000005f status 0000005f
  8: @f7e3c700  length 8000002a status 0000002a
  9: @f7e3c7a0  length 8000002a status 0000002a
  10: @f7e3c840  length 8000002a status 0000002a
  11: @f7e3c8e0  length 8000002a status 0000002a
  12: @f7e3c980  length 8000002a status 0000002a
  13: @f7e3ca20  length 8000002a status 0000002a
  14: @f7e3cac0  length 8000002a status 0000002a
  15: @f7e3cb60  length 8000002a status 0000002a
eth0: Resetting the Tx ring pointer.

lspci -vvv:
01:0b.0 RAID bus controller: Silicon Image, Inc. SiI 3112
[SATALink/SATARaid] Serial ATA Controller (rev 01)
        Subsystem: Silicon Image, Inc. SiI 3112 SATARaid Controller
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32, Cache Line Size 08
        Interrupt: pin A routed to IRQ 19
        Region 0: I/O ports at 9c00 [size=8]
        Region 1: I/O ports at a000 [size=4]
        Region 2: I/O ports at a400 [size=8]
        Region 3: I/O ports at a800 [size=4]
        Region 4: I/O ports at ac00 [size=16]
        Region 5: Memory at e5006000 (32-bit, non-prefetchable)
[size=512]
        [virtual] Expansion ROM at e6800000 [disabled] [size=512K]
        Capabilities: [60] Power Management version 2
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-

-- 
avuton
--
 Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [RFT] major libata update

[Jeff Garzik]

Avuton Olrich wrote:
> On 5/15/06, Jeff Garzik <jeff@garzik.org> wrote:
>> Avuton Olrich wrote:
>> > On 5/15/06, Jeff Garzik <jeff@garzik.org> wrote:
>> >> * sata_sil and ata_piix also need healthy re-testing of all basic
>> >> functionality.
>> >
>> > I'm testing it right now, but with 2.6.17-rc4-git2 I was getting:
>>
>> Testing what?  sata_sil?  Please provide full dmesg, there's a lot of
>> missing information.
> 
> More followup, it did finally error out on me:
> 
> Not sure if it helps any, but this is a sata2 disk with a sata
> interface. This is rc4-git2 with the libata patch from the beginning
> of this thread, using sata_sil.

Can you configure your interrupts so that ethernet and SATA are not on 
the same irq?

Also, please provide _full_ dmesg and _full_ lspci, not just the 
SATA-related stuff.  This looks motherboard- or hardware-related.

	Jeff

Re: [RFT] major libata update

[Tejun Heo]

Avuton Olrich wrote:
[--snip--]
> ata1.00: tag 0 cmd 0x25 Emask 0x4 stat 0x40 err 0x0 (timeout)
> ata1: soft resetting port
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> ata1.00: configured for UDMA/25
> ata1: EH complete
> NETDEV WATCHDOG: eth2: transmit timed out
> ata1.00: limiting speed to UDMA/16
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x3 frozen
> ata1.00: (BMDMA stat 0x1)
> ata1.00: tag 0 cmd 0x25 Emask 0x4 stat 0x40 err 0x0 (timeout)
> ata1: soft resetting port
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> ata1.00: configured for UDMA/16
> ata1: EH complete
> ata1.00: limiting speed to PIO4
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x3 frozen
> ata1.00: (BMDMA stat 0x1)
> ata1.00: tag 0 cmd 0x25 Emask 0x4 stat 0x40 err 0x0 (timeout)
> ata1: soft resetting port
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> ata1.00: configured for PIO4
> ata1: EH complete

Are those timeouts back-to-back?  Can you post dmesg w/ timestamp 
(either turn on kernel message timestamping or simply post relevant part 
from /var/log/kern.log).  The drive thinks the command is complete.  You 
might be losing interrupts (you might want to diddle with acpi/irq 
routing stuff) or it could be some other hardware problem.

Does the drive + controller work okay on Windows?  I know people don't 
like this question so much but it's a great way to isolate hardware 
problems as they use completely different driver stack.

And, as show above, currently implemented speed down is way to 
simplistic.  We need a better speed-down sequence, but I guess that can 
wait for a bit.

> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: transmit timed out, tx_status 00 status e000.
>  diagnostics: net 0cc0 media 8080 dma 000000a0 fifo 8800
>  Flags; bus-master 1, dirty 18790(6) current 18806(6)
>  Transmit list 37e3c5c0 vs. f7e3c5c0.
>  0: @f7e3c200  length 8000002a status 0000002a
>  1: @f7e3c2a0  length 8000002a status 0000002a
>  2: @f7e3c340  length 8000002a status 0000002a
>  3: @f7e3c3e0  length 8000002a status 0000002a
>  4: @f7e3c480  length 8000002a status 8000002a
>  5: @f7e3c520  length 8000002a status 8000002a
>  6: @f7e3c5c0  length 8000005f status 0000005f
>  7: @f7e3c660  length 8000005f status 0000005f
>  8: @f7e3c700  length 8000002a status 0000002a
>  9: @f7e3c7a0  length 8000002a status 0000002a
>  10: @f7e3c840  length 8000002a status 0000002a
>  11: @f7e3c8e0  length 8000002a status 0000002a
>  12: @f7e3c980  length 8000002a status 0000002a
>  13: @f7e3ca20  length 8000002a status 0000002a
>  14: @f7e3cac0  length 8000002a status 0000002a
>  15: @f7e3cb60  length 8000002a status 0000002a
> eth0: Resetting the Tx ring pointer.
> NETDEV WATCHDOG: eth0: transmit timed out

Increased transmit timeout is probably because the CPU is locked up 
performing PIOs.  I worry about this.  With irq-pio, the system stutters 
much more.  It might be better to perform the actual PIO part from a 
workqueue.  But then there are controllers which can't stand when CPU 
leaves it unattended while PIO is in progress...

-- 
tejun

Re: [RFT] major libata update

[Avuton Olrich]

On 5/15/06, Jeff Garzik <jeff@garzik.org> wrote:


> Can you configure your interrupts so that ethernet and SATA are not on
> the same irq?

Sorry, need a little hand holding here. I'm unsure how to do such a
thing, and can't really google that.

> Also, please provide _full_ dmesg and _full_ lspci, not just the
> SATA-related stuff.  This looks motherboard- or hardware-related.

kern.log is my last 24 hrs, contains everything that came into the kern.log
http://olricha.homelinux.net:8080/dump/kern.log
http://olricha.homelinux.net:8080/dump/lspci-vvv

If there's anything else I can do please let me know
-- 
avuton
--
 Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [RFT] major libata update

[Avuton Olrich]

On 5/15/06, Tejun Heo <htejun@gmail.com> wrote:
> Avuton Olrich wrote:

> Are those timeouts back-to-back?  Can you post dmesg w/ timestamp
> (either turn on kernel message timestamping or simply post relevant part
> from /var/log/kern.log).  The drive thinks the command is complete.  You
> might be losing interrupts (you might want to diddle with acpi/irq
> routing stuff) or it could be some other hardware problem.

here's the kern log for the last 24 hours or so:
http://olricha.homelinux.net:8080/dump/kern.log

As I told Jeff, I'm not sure how to diddle with the irq stuff, pointers?

> Does the drive + controller work okay on Windows?  I know people don't
> like this question so much but it's a great way to isolate hardware
> problems as they use completely different driver stack.

Sorry, I haven't owned a copy of Windows in >5 yrs, I would be willing
to try otherwise. This computer worked with a 2 160gb sata drives,
when I traded 2 160gb drives with 2 500gb sata2 drives and started
making heavy use of them this happened, although I haven't had any
issue with the other hard drive yet (I don't think, I need to look
over the logs again to make sure I'm not saying that in err).

...snipped more stuff way above my head...
-- 
avuton
--
 Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [RFT] major libata update

[Robert Hancock]

Avuton Olrich wrote:
> On 5/15/06, Jeff Garzik <jeff@garzik.org> wrote:
> 
>> Can you configure your interrupts so that ethernet and SATA are not on
>> the same irq?
> 
> Sorry, need a little hand holding here. I'm unsure how to do such a
> thing, and can't really google that.

If they are both onboard devices, there is probably no way to do this. 
However, from the lspci output it doesn't appear they are on the same 
IRQ anyway.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: [RFT] major libata update

[Linus Torvalds]

On Mon, 15 May 2006, Avuton Olrich wrote:
> On 5/15/06, Jeff Garzik <jeff@garzik.org> wrote:
>
> > Can you configure your interrupts so that ethernet and SATA are not on
> > the same irq?
> 
> Sorry, need a little hand holding here. I'm unsure how to do such a
> thing, and can't really google that.

Before you do that, try this patch (that I suggested to Neil Brown in a 
totally unrelated thread) just for fun.

		Linus

----
diff --git a/arch/i386/pci/irq.c b/arch/i386/pci/irq.c
index 06dab00..49b9fea 100644
--- a/arch/i386/pci/irq.c
+++ b/arch/i386/pci/irq.c
@@ -880,6 +880,7 @@ static int pcibios_lookup_irq(struct pci
 	((!(pci_probe & PCI_USE_PIRQ_MASK)) || ((1 << irq) & mask)) ) {
 		DBG(" -> got IRQ %d\n", irq);
 		msg = "Found";
+		eisa_set_level_irq(irq);
 	} else if (newirq && r->set && (dev->class >> 8) != PCI_CLASS_DISPLAY_VGA) {
 		DBG(" -> assigning IRQ %d", newirq);
 		if (r->set(pirq_router_dev, dev, pirq, newirq)) {

Re: [RFT] major libata update

[Jeff Garzik]

Avuton Olrich wrote:
> On 5/15/06, Jeff Garzik <jeff@garzik.org> wrote:
> 
> 
>> Can you configure your interrupts so that ethernet and SATA are not on
>> the same irq?
> 
> Sorry, need a little hand holding here. I'm unsure how to do such a
> thing, and can't really google that.

It will be in your BIOS setup somewhere.  Hopefully.

	Jeff

Re: [RFT] major libata update

[Andrew Morton]

Jeff Garzik <jeff@garzik.org> wrote:
>
>  	git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

This adds a minute and a half to my bootup times :(


[   43.275044] SCSI subsystem initialized
[   43.335092] libata version 1.30 loaded.
[   43.336142] ata_piix 0000:00:1f.2: version 1.10
[   43.336146] ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
[   43.426691] ACPI (acpi_bus-0191): Device is not power manageable [20060310]
[   43.559872] ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 19 (level, low) -> IRQ 19
[   43.681530] PCI: Setting latency timer of device 0000:00:1f.2 to 64
[   43.681564] ata1: SATA max UDMA/133 cmd 0x2148 ctl 0x217E bmdma 0x2110 irq 19
[   43.777123] ata2: SATA max UDMA/133 cmd 0x2140 ctl 0x217A bmdma 0x2118 irq 19
[   44.123919] ata1.00: cfg 49:2f00 82:346b 83:7fe9 84:4773 85:3469 86:3c01 87:4763 88:407f
[   44.123924] ata1.00: ATA-7, max UDMA/133, 321672960 sectors: LBA48 NCQ (depth 0/32)
[   44.216325] ata1.00: configured for UDMA/133
[   44.267296] scsi0 : ata_piix
[   44.301660] PM: Adding info for No Bus:host0
[   44.719422] ata2.00: cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:101f
[   44.719425] ata2.00: ATAPI, max UDMA/66
[   44.765263] ata2.00: applying bridge limits
[   74.928836] ata2.01: qc timeout (cmd 0xa1)
[   74.977811] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
[   75.468853] ata2.00: cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:101f
[   75.468856] ata2.00: ATAPI, max UDMA/66
[   75.514678] ata2.00: applying bridge limits
[  105.674130] ata2.01: qc timeout (cmd 0xa1)
[  105.723044] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
[  106.210113] ata2.00: cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:101f
[  106.210117] ata2.00: ATAPI, max UDMA/66
[  106.255906] ata2.00: applying bridge limits
[  136.415532] ata2.01: qc timeout (cmd 0xa1)
[  136.464452] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
[  136.537214] ata2.01: limiting speed to PIO0
[  136.587141] ata2.01: disabled
[  137.039723] ata2.00: cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:101f
[  137.039726] ata2.00: ATAPI, max UDMA/66
[  137.085492] ata2.00: applying bridge limits
[  137.292543] ata2.00: configured for UDMA/66
[  137.342488] scsi1 : ata_piix
[  137.376847] PM: Adding info for No Bus:host1
[  137.376892] PM: Adding info for No Bus:target0:0:0
[  137.376948]   Vendor: ATA       Model: HDT722516DLA380   Rev: V43O
[  137.453962]   Type:   Direct-Access                      ANSI SCSI revision: 05
[  137.541468] PM: Adding info for scsi:0:0:0:0
[  137.541547] SCSI device sda: 321672960 512-byte hdwr sectors (164697 MB)
[  137.621598] sda: Write Protect is off
[  137.665289] sda: Mode Sense: 00 3a 00 00
[  137.665306] SCSI device sda: drive cache: write back
[  137.724592] SCSI device sda: 321672960 512-byte hdwr sectors (164697 MB)
[  137.804697] sda: Write Protect is off
[  137.848386] sda: Mode Sense: 00 3a 00 00
[  137.848398] SCSI device sda: drive cache: write back
[  137.907659]  sda: sda1 sda2 sda3
[  137.957184] sd 0:0:0:0: Attached scsi disk sda
[  138.010252] PM: Adding info for No Bus:target1:0:0
[  138.010869]   Vendor: PLEXTOR   Model: DVDR   PX-716A    Rev: 1.09
[  138.087949]   Type:   CD-ROM                             ANSI SCSI revision: 05
[  138.175466] PM: Adding info for scsi:1:0:0:0
[  138.175531] ata_piix 0000:00:1f.5: MAP [ P0 P2 P1 P3 ]
[  138.237446] ACPI (acpi_bus-0191): Device is not power manageable [20060310]
[  138.320799] ACPI: PCI Interrupt 0000:00:1f.5[A] -> GSI 19 (level, low) -> IRQ 19
[  138.409254] PCI: Setting latency timer of device 0000:00:1f.5 to 64
[  138.409276] ata3: SATA max UDMA/133 cmd 0x2138 ctl 0x2176 bmdma 0x20F0 irq 19
[  138.494586] ata4: SATA max UDMA/133 cmd 0x2130 ctl 0x2172 bmdma 0x20F8 irq 19
[  139.899612] scsi2 : ata_piix
[  139.933979] PM: Adding info for No Bus:host2
[  141.251424] scsi3 : ata_piix
[  141.285781] PM: Adding info for No Bus:host3
[  141.366280] EXT3-fs: INFO: recovery required on readonly filesystem.

Re: [RFT] major libata update

[Tejun Heo]

Hello, Andrew.

Andrew Morton wrote:
[--snip--]
> [   44.719422] ata2.00: cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:101f
> [   44.719425] ata2.00: ATAPI, max UDMA/66
> [   44.765263] ata2.00: applying bridge limits
> [   74.928836] ata2.01: qc timeout (cmd 0xa1)
> [   74.977811] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
> [   75.468853] ata2.00: cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:101f
> [   75.468856] ata2.00: ATAPI, max UDMA/66
> [   75.514678] ata2.00: applying bridge limits
> [  105.674130] ata2.01: qc timeout (cmd 0xa1)

Did this device work with previous versions of kernel?

libata used to give up on the first failure during probe, so the boot 
time would have been shorter in failure cases.  I think controlled 
retries during boot probe is a good thing, but the timeout of 30s for 
IDENTIFY commands can be shortened, I guess.

-- 
tejun

Re: [RFT] major libata update

[Andrew Morton]

Tejun Heo <htejun@gmail.com> wrote:
>
> Hello, Andrew.
> 
> Andrew Morton wrote:
> [--snip--]
> > [   44.719422] ata2.00: cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:101f
> > [   44.719425] ata2.00: ATAPI, max UDMA/66
> > [   44.765263] ata2.00: applying bridge limits
> > [   74.928836] ata2.01: qc timeout (cmd 0xa1)
> > [   74.977811] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
> > [   75.468853] ata2.00: cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:101f
> > [   75.468856] ata2.00: ATAPI, max UDMA/66
> > [   75.514678] ata2.00: applying bridge limits
> > [  105.674130] ata2.01: qc timeout (cmd 0xa1)
> 
> Did this device work with previous versions of kernel?

No.  In fact, it doesn't even work with the 2.6.17-rc4-mm1 lineup plus the
latest git-libata-all.  It needs this tweak:

--- devel/drivers/scsi/ata_piix.c~2.6.17-rc4-mm1-ich8-fix	2006-05-16 18:36:12.000000000 -0700
+++ devel-akpm/drivers/scsi/ata_piix.c	2006-05-16 18:36:12.000000000 -0700
@@ -542,6 +542,14 @@ static unsigned int piix_sata_probe (str
 		port = map[base + i];
 		if (port < 0)
 			continue;
+		if (ap->flags & PIIX_FLAG_AHCI) {
+			/* FIXME: Port status of AHCI controllers
+			 * should be accessed in AHCI memory space.  */
+			if (pcs & 1 << port)
+				present_mask |= 1 << i;
+			else
+				pcs &= ~(1 << port);
+		}
 		if (ap->flags & PIIX_FLAG_IGNORE_PCS || pcs & 1 << (4 + port))
 			present_mask |= 1 << i;
 		else
_


> libata used to give up on the first failure during probe, so the boot 
> time would have been shorter in failure cases.

I don't recall anyone complaining?

>  I think controlled 
> retries during boot probe is a good thing, but the timeout of 30s for 
> IDENTIFY commands can be shortened, I guess.

We should do something, please.  It'll hurt kernel developers the most.

Re: [RFT] major libata update

[Tejun Heo]

Andrew Morton wrote:
> Tejun Heo <htejun@gmail.com> wrote:
>> Hello, Andrew.
>>
>> Andrew Morton wrote:
>> [--snip--]
>>> [   44.719422] ata2.00: cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:101f
>>> [   44.719425] ata2.00: ATAPI, max UDMA/66
>>> [   44.765263] ata2.00: applying bridge limits
>>> [   74.928836] ata2.01: qc timeout (cmd 0xa1)
>>> [   74.977811] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
>>> [   75.468853] ata2.00: cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:101f
>>> [   75.468856] ata2.00: ATAPI, max UDMA/66
>>> [   75.514678] ata2.00: applying bridge limits
>>> [  105.674130] ata2.01: qc timeout (cmd 0xa1)
>> Did this device work with previous versions of kernel?
> 
> No.  In fact, it doesn't even work with the 2.6.17-rc4-mm1 lineup plus the
> latest git-libata-all.  It needs this tweak:
> 
> --- devel/drivers/scsi/ata_piix.c~2.6.17-rc4-mm1-ich8-fix	2006-05-16 18:36:12.000000000 -0700
> +++ devel-akpm/drivers/scsi/ata_piix.c	2006-05-16 18:36:12.000000000 -0700
> @@ -542,6 +542,14 @@ static unsigned int piix_sata_probe (str
>  		port = map[base + i];
>  		if (port < 0)
>  			continue;
> +		if (ap->flags & PIIX_FLAG_AHCI) {
> +			/* FIXME: Port status of AHCI controllers
> +			 * should be accessed in AHCI memory space.  */
> +			if (pcs & 1 << port)
> +				present_mask |= 1 << i;
> +			else
> +				pcs &= ~(1 << port);
> +		}
>  		if (ap->flags & PIIX_FLAG_IGNORE_PCS || pcs & 1 << (4 + port))
>  			present_mask |= 1 << i;
>  		else
> _

Ah.. I see.  This is the ata_piix ghosting problem where signature of 
the first device is duplicated in the second device causing libata to 
probe the second non-existent device.

>> libata used to give up on the first failure during probe, so the boot 
>> time would have been shorter in failure cases.
> 
> I don't recall anyone complaining?

One of sata_via + ATAPI probing problem might have been fixed by this. 
It still needs to be investigated further though.

>>  I think controlled 
>> retries during boot probe is a good thing, but the timeout of 30s for 
>> IDENTIFY commands can be shortened, I guess.
> 
> We should do something, please.  It'll hurt kernel developers the most.

I think the correct solution would be fixing the ghosting problem of the 
controller.  I'll look into it.

-- 
tejun

Re: [RFT] major libata update

[Tejun Heo]

Tejun Heo wrote:
> Andrew Morton wrote:
>> No.  In fact, it doesn't even work with the 2.6.17-rc4-mm1 lineup plus 
>> the
>> latest git-libata-all.  It needs this tweak:
>>
>> --- devel/drivers/scsi/ata_piix.c~2.6.17-rc4-mm1-ich8-fix    
>> 2006-05-16 18:36:12.000000000 -0700
>> +++ devel-akpm/drivers/scsi/ata_piix.c    2006-05-16 
>> 18:36:12.000000000 -0700
>> @@ -542,6 +542,14 @@ static unsigned int piix_sata_probe (str
>>          port = map[base + i];
>>          if (port < 0)
>>              continue;
>> +        if (ap->flags & PIIX_FLAG_AHCI) {
>> +            /* FIXME: Port status of AHCI controllers
>> +             * should be accessed in AHCI memory space.  */
>> +            if (pcs & 1 << port)
>> +                present_mask |= 1 << i;
>> +            else
>> +                pcs &= ~(1 << port);
>> +        }
>>          if (ap->flags & PIIX_FLAG_IGNORE_PCS || pcs & 1 << (4 + port))
>>              present_mask |= 1 << i;
>>          else

The above patch doesn't do anything.  The only effect it has is setting 
present_mask according to enabled bits instead of present bits.  I think 
this patch might have helped with probing before the MAP tables for 
ICH6/7 are fixed.

I've done further testing.

* Symptom

ata_piix tries to probe non-existing slave device resulting in timeouts 
during boot probing.  This problem is aggravated by new probing updates 
as it retries two more times before giving up.

* Test results

PATA never has any problem with device detection via signature.  Only 
SATA is affected and interestingly only ATAPI device.  The following is 
the test result on my machine (ICH7R + PX716SA).

   1. combined mode : MAP [IDE IDE P1 P3]

	P1		P3
	-----------------------------
	PX716-SA	empty		P3 ghosted as ATAPI device
	empty		PX716-SA	okay
	PX716-SA	HDD		okay
	HDD		PX716-SA	okay

   2. SATA-only mode : MAP [P0 P2 P1 P3]

	P0		P2
	-----------------------------
	PX716-SA	empty		P2 ghosted as ATAPI device
	empty		PX716-SA	okay
	PX716-SA	HDD		okay
	HDD		PX716-SA	okay

	P1		P3
	-----------------------------
	Identical to #1.

To sum up, it happens when the master slot is occupied by an ATAPI 
device and the corresponding slave slot is empty.  The slave slot 
reports ATAPI signature (probably duplicated from the master) and passes 
all legacy presence test thus resulting in timeout on IDENTIFY.

In all above cases, the PCS register reported correct presence masks.

* Proposed solution

It seems that the only solution is to make use of the PCS presence bits 
somehow.  It is know that 6300ESB family of controllers have flaky 
presence bits (ata_piix marks them with PIIX_FLAG_IGNORE_PCS), but I 
couldn't find any document/errata for PCS bits for any other 
controllers.  So, we can use PCS for all !PIIX_FLAG_IGNORE_PCS 
controllers or take a conservative approach and make use of it only on 
cases where ghosting problem is reported (ICH7 and 8, I guess.  Can 
anyone test 6?).

Please note that we already use some use of the PCS value when probing 
SATA port.  If its value is zero, we skip the port.  It's done this way 
mainly due to historical reasons - until recently ata_piix didn't have 
MAP tables to map PM/PS/SM/SS to specific ports thus used the PCS values 
in rougher form.

Jeff, what do you think?

-- 
tejun

Re: [RFT] major libata update

[Matthieu CASTET]

On Llu, 2006-05-15 at 14:15 -0400, Jeff Garzik wrote:
> > which persists on Sil 311x on rare motherboards.  The rest are either 
> > addressed with the improved error handling, or are ATAPI + VIA AFAICS.

> ATAPI + VIA to that pattern is also showing up on pata_via cases as
> well, but only on via so far. Its as if there is a case where the IRQ of
> the first command is lost sometimes.
I investigated further the problem. For my pata case the interrupt go 
through idle_irq in ata_host_intr.
If I put a printk before ata_host_intr in ata_interrupt there no problem.

I bet "altstatus" or "main status" return ATA_BUSY and are not cleared 
enough fast by the hardware.

I will try others tests this evening.


Matthieu

Re: [RFT] major libata update

[OGAWA Hirofumi]

Linus Torvalds <torvalds@osdl.org> writes:

> On Mon, 15 May 2006, Avuton Olrich wrote:
>
> diff --git a/arch/i386/pci/irq.c b/arch/i386/pci/irq.c
> index 06dab00..49b9fea 100644
> --- a/arch/i386/pci/irq.c
> +++ b/arch/i386/pci/irq.c
> @@ -880,6 +880,7 @@ static int pcibios_lookup_irq(struct pci
>  	((!(pci_probe & PCI_USE_PIRQ_MASK)) || ((1 << irq) & mask)) ) {
>  		DBG(" -> got IRQ %d\n", irq);
>  		msg = "Found";
> +		eisa_set_level_irq(irq);
>  	} else if (newirq && r->set && (dev->class >> 8) != PCI_CLASS_DISPLAY_VGA) {
>  		DBG(" -> assigning IRQ %d", newirq);
>  		if (r->set(pirq_router_dev, dev, pirq, newirq)) {

I like it. I'd like to put this type stuff (fixes setting of 8259,
APIC, chipset, etc.) into pci...
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [RFT] major libata update

[Linus Torvalds]

On Thu, 18 May 2006, OGAWA Hirofumi wrote:

> Linus Torvalds <torvalds@osdl.org> writes:
> 
> > On Mon, 15 May 2006, Avuton Olrich wrote:
> >
> > diff --git a/arch/i386/pci/irq.c b/arch/i386/pci/irq.c
> > index 06dab00..49b9fea 100644
> > --- a/arch/i386/pci/irq.c
> > +++ b/arch/i386/pci/irq.c
> > @@ -880,6 +880,7 @@ static int pcibios_lookup_irq(struct pci
> >  	((!(pci_probe & PCI_USE_PIRQ_MASK)) || ((1 << irq) & mask)) ) {
> >  		DBG(" -> got IRQ %d\n", irq);
> >  		msg = "Found";
> > +		eisa_set_level_irq(irq);
> >  	} else if (newirq && r->set && (dev->class >> 8) != PCI_CLASS_DISPLAY_VGA) {
> >  		DBG(" -> assigning IRQ %d", newirq);
> >  		if (r->set(pirq_router_dev, dev, pirq, newirq)) {
> 
> I like it. I'd like to put this type stuff (fixes setting of 8259,
> APIC, chipset, etc.) into pci...

Andrew, can you put the one-liner into -mm and see if it gathers any 
reports? 

I think Neil already reported that it fixed a lost interrupt problem for 
him, but I'm worried that it might result in interrupt storms for others. 

In particular, I have this pretty strong memory that we tried to do 
something like this a long time ago, and it caused problems at least 
with the legacy ISA/ATA interrupts (irq 14/15).

On the other hand, my memory is pretty damn bad at times, and besides, I 
hope that that "hardcoded" case just above it is the one that takes care 
of the old ATA interrupts. This is one of those times when the only 
guaranteed right thing to do would be to be bug-for-bug compatible with 
whatever crud MS-Win does..

		Linus

Re: [RFT] major libata update

[Jeff Garzik]

Linus Torvalds wrote:
> In particular, I have this pretty strong memory that we tried to do 
> something like this a long time ago, and it caused problems at least 
> with the legacy ISA/ATA interrupts (irq 14/15).
> 
> On the other hand, my memory is pretty damn bad at times, and besides, I 
> hope that that "hardcoded" case just above it is the one that takes care 
> of the old ATA interrupts. This is one of those times when the only 
> guaranteed right thing to do would be to be bug-for-bug compatible with 
> whatever crud MS-Win does..

Many BIOS ACPI tables from years ago simply _assumed_ that you have 
hardcoded irq 14/15, even...  Their irq descriptors for 14/15 would be 
absent or completely non-functional.

Or maybe its the $pirq table I'm recalling.  One of the two, anyway.

	Jeff

Re: [RFT] major libata update

[Linus Torvalds]

On Wed, 17 May 2006, Linus Torvalds wrote:
> 
> I think Neil already reported that it fixed a lost interrupt problem for 
> him, but I'm worried that it might result in interrupt storms for others. 

Of course, we could just decide to try to switch from level to 
edge-triggered if the irq storm thing ever triggers. Right now we disable 
the irq entirely, which means that _if_ it was just due to a polarity 
error, we're screwed even if it should have been easy to fix by just 
turning it into edge-high.

The code to do that should be trivial: make __report_bad_irq() try to 
switch to edge mode if it's not edge already. Hmm?

		Linus

RE: [RFT] major libata update

[Brown, Len]

>Many BIOS ACPI tables from years ago simply _assumed_ that you have 
>hardcoded irq 14/15, even...  Their irq descriptors for 14/15 would be 
>absent or completely non-functional.
>
>Or maybe its the $pirq table I'm recalling.  One of the two, anyway.

For x86, the ACPI interrupt configuration process is to identity-map
the IOAPIC entries below 16 1:1 PIC:IOAPIC,
unless there are interrupt source overrides
(such as commonly done to swizzle IRQ0 from a different pin)

This makes legacy-mode ATA happy.  Hard code ATA to 14/15 and
off you go.

But there is a gray area where the ATA controller registers
as a PCI device, but Linux goes off and looks in the ACPI PRT
for that PCI-dev and finds no entry.  So if you didn't
have the hard-coded 14/15, you'd be dead.

Then there are cases where the PRT specifies something
_other_ than 14/15 for ATA, and in that cases the hard-coded
default is the wrong thing to do; and the workaround is
to use BIOS SETUP options to be sure that ATA is set up
in legacy mode.

I suspect Linux could be smarter here.  The 14/15 should be
the backup default for when the tables
don't give us anything else; not the only option.

-Len

Re: [RFT] major libata update

[Alan Cox]

On Mer, 2006-05-17 at 19:48 -0400, Jeff Garzik wrote:
> Many BIOS ACPI tables from years ago simply _assumed_ that you have 
> hardcoded irq 14/15, even...  Their irq descriptors for 14/15 would be 
> absent or completely non-functional.

For $PIR this is correct the IRQ 14/15 from the IDE controllers in
legacy mode is an ISA IRQ not a PCI one. Welcome to the happy fun
compatibility factory.

Re: [RFT] major libata update

[Albert Lee]

Tejun Heo wrote:
> Tejun Heo wrote:
> 
>> Andrew Morton wrote:
>>
>>> No.  In fact, it doesn't even work with the 2.6.17-rc4-mm1 lineup
>>> plus the
>>> latest git-libata-all.  It needs this tweak:
>>>
>>> --- devel/drivers/scsi/ata_piix.c~2.6.17-rc4-mm1-ich8-fix   
>>> 2006-05-16 18:36:12.000000000 -0700
>>> +++ devel-akpm/drivers/scsi/ata_piix.c    2006-05-16
>>> 18:36:12.000000000 -0700
>>> @@ -542,6 +542,14 @@ static unsigned int piix_sata_probe (str
>>>          port = map[base + i];
>>>          if (port < 0)
>>>              continue;
>>> +        if (ap->flags & PIIX_FLAG_AHCI) {
>>> +            /* FIXME: Port status of AHCI controllers
>>> +             * should be accessed in AHCI memory space.  */
>>> +            if (pcs & 1 << port)
>>> +                present_mask |= 1 << i;
>>> +            else
>>> +                pcs &= ~(1 << port);
>>> +        }
>>>          if (ap->flags & PIIX_FLAG_IGNORE_PCS || pcs & 1 << (4 + port))
>>>              present_mask |= 1 << i;
>>>          else
> 
> 
> The above patch doesn't do anything.  The only effect it has is setting
> present_mask according to enabled bits instead of present bits.  I think
> this patch might have helped with probing before the MAP tables for
> ICH6/7 are fixed.
> 
> I've done further testing.
> 
> * Symptom
> 
> ata_piix tries to probe non-existing slave device resulting in timeouts
> during boot probing.  This problem is aggravated by new probing updates
> as it retries two more times before giving up.
> 
> * Test results
> 
> PATA never has any problem with device detection via signature.  Only
> SATA is affected and interestingly only ATAPI device.  The following is
> the test result on my machine (ICH7R + PX716SA).
> 
>   1. combined mode : MAP [IDE IDE P1 P3]
> 
>     P1        P3
>     -----------------------------
>     PX716-SA    empty        P3 ghosted as ATAPI device
>     empty        PX716-SA    okay
>     PX716-SA    HDD        okay
>     HDD        PX716-SA    okay
> 
>   2. SATA-only mode : MAP [P0 P2 P1 P3]
> 
>     P0        P2
>     -----------------------------
>     PX716-SA    empty        P2 ghosted as ATAPI device
>     empty        PX716-SA    okay
>     PX716-SA    HDD        okay
>     HDD        PX716-SA    okay
> 
>     P1        P3
>     -----------------------------
>     Identical to #1.
> 
> To sum up, it happens when the master slot is occupied by an ATAPI
> device and the corresponding slave slot is empty.  The slave slot
> reports ATAPI signature (probably duplicated from the master) and passes
> all legacy presence test thus resulting in timeout on IDENTIFY.
> 

This problem was seen with PATA Promise 20275 adapter + IBM DVD-RAM drive.
Single master device configuration, no slave device.
The master device acts as slave and creates a phantom slave device.
(http://marc.theaimsgroup.com/?l=linux-ide&m=113151315602979&w=2)

The problem was later fixed by Tejun's ata_exec_internal() patch:
(http://marc.theaimsgroup.com/?l=linux-ide&m=113455450809405&w=2)
After the patch, the phantom device is finally detected by ata_dev_identify().

Libata uses polling PIO for IDENTIFY DEVICE before this major update.
The polling PIO finds something wrong when it reads a 0x00 device status.
So, the phantom device is detected quite quickly.

With irq-driven PIO, maybe the phantom device is only detected after time-out.
So it takes longer (30 secs) to detect the phantom device.

No good idea how to fix this. Maybe read more registers to see whether the
phantom device can be detected early before the IDENTIFY DEVICE.

--
albert


> In all above cases, the PCS register reported correct presence masks.
> 
> * Proposed solution
> 
> It seems that the only solution is to make use of the PCS presence bits
> somehow.  It is know that 6300ESB family of controllers have flaky
> presence bits (ata_piix marks them with PIIX_FLAG_IGNORE_PCS), but I
> couldn't find any document/errata for PCS bits for any other
> controllers.  So, we can use PCS for all !PIIX_FLAG_IGNORE_PCS
> controllers or take a conservative approach and make use of it only on
> cases where ghosting problem is reported (ICH7 and 8, I guess.  Can
> anyone test 6?).
> 
> Please note that we already use some use of the PCS value when probing
> SATA port.  If its value is zero, we skip the port.  It's done this way
> mainly due to historical reasons - until recently ata_piix didn't have
> MAP tables to map PM/PS/SM/SS to specific ports thus used the PCS values
> in rougher form.
> 
> Jeff, what do you think?
> 

Re: [RFT] major libata update

[Tejun Heo]

Albert Lee wrote:
>> To sum up, it happens when the master slot is occupied by an ATAPI
>> device and the corresponding slave slot is empty.  The slave slot
>> reports ATAPI signature (probably duplicated from the master) and passes
>> all legacy presence test thus resulting in timeout on IDENTIFY.
>>
> 
> This problem was seen with PATA Promise 20275 adapter + IBM DVD-RAM drive.
> Single master device configuration, no slave device.
> The master device acts as slave and creates a phantom slave device.
> (http://marc.theaimsgroup.com/?l=linux-ide&m=113151315602979&w=2)
> 
> The problem was later fixed by Tejun's ata_exec_internal() patch:
> (http://marc.theaimsgroup.com/?l=linux-ide&m=113455450809405&w=2)
> After the patch, the phantom device is finally detected by ata_dev_identify().
> 
> Libata uses polling PIO for IDENTIFY DEVICE before this major update.
> The polling PIO finds something wrong when it reads a 0x00 device status.
> So, the phantom device is detected quite quickly.
> 
> With irq-driven PIO, maybe the phantom device is only detected after time-out.
> So it takes longer (30 secs) to detect the phantom device.
> 
> No good idea how to fix this. Maybe read more registers to see whether the
> phantom device can be detected early before the IDENTIFY DEVICE.
> 

Does the Promise controller show the ghosting problem again with the 
recent updates?  ata_piix can be fixed by using PCS present bits.  I 
don't know about Promise though.

-- 
tejun

Re: [RFT] major libata update

[Andrew Morton]

Tejun Heo <htejun@gmail.com> wrote:
>
> Tejun Heo wrote:
>  > Andrew Morton wrote:
>  >> No.  In fact, it doesn't even work with the 2.6.17-rc4-mm1 lineup plus 
>  >> the
>  >> latest git-libata-all.  It needs this tweak:
>  >>
>  >> --- devel/drivers/scsi/ata_piix.c~2.6.17-rc4-mm1-ich8-fix    
>  >> 2006-05-16 18:36:12.000000000 -0700
>  >> +++ devel-akpm/drivers/scsi/ata_piix.c    2006-05-16 
>  >> 18:36:12.000000000 -0700
>  >> @@ -542,6 +542,14 @@ static unsigned int piix_sata_probe (str
>  >>          port = map[base + i];
>  >>          if (port < 0)
>  >>              continue;
>  >> +        if (ap->flags & PIIX_FLAG_AHCI) {
>  >> +            /* FIXME: Port status of AHCI controllers
>  >> +             * should be accessed in AHCI memory space.  */
>  >> +            if (pcs & 1 << port)
>  >> +                present_mask |= 1 << i;
>  >> +            else
>  >> +                pcs &= ~(1 << port);
>  >> +        }
>  >>          if (ap->flags & PIIX_FLAG_IGNORE_PCS || pcs & 1 << (4 + port))
>  >>              present_mask |= 1 << i;
>  >>          else
> 
>  The above patch doesn't do anything.

Yes it does.  I dropped it and got

SCSI subsystem initialized
ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
ACPI (acpi_bus-0191): Device is not power manageable [20060310]
ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 19 (level, low) -> IRQ 19
ata1: SATA max UDMA/133 cmd 0x2148 ctl 0x217E bmdma 0x2110 irq 19
ata2: SATA max UDMA/133 cmd 0x2140 ctl 0x217A bmdma 0x2118 irq 19
ata1: SATA port has no device.

Then I undropped it and got

SCSI subsystem initialized
ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
ACPI (acpi_bus-0191): Device is not power manageable [20060310]
ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 19 (level, low) -> IRQ 19
ata1: SATA max UDMA/133 cmd 0x2148 ctl 0x217E bmdma 0x2110 irq 19
ata2: SATA max UDMA/133 cmd 0x2140 ctl 0x217A bmdma 0x2118 irq 19
ata1.00: ATA-7, max UDMA/133, 321672960 sectors: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/133
scsi0 : ata_piix

and a computer which boots.

Look closer, please ;)

Re: [RFT] major libata update

[Tejun Heo]

On Thu, May 18, 2006 at 04:07:58PM -0700, Andrew Morton wrote:
> 
> Yes it does.  I dropped it and got
> 
> SCSI subsystem initialized
> ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
> ACPI (acpi_bus-0191): Device is not power manageable [20060310]
> ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 19 (level, low) -> IRQ 19
> ata1: SATA max UDMA/133 cmd 0x2148 ctl 0x217E bmdma 0x2110 irq 19
> ata2: SATA max UDMA/133 cmd 0x2140 ctl 0x217A bmdma 0x2118 irq 19
> ata1: SATA port has no device.
> 
> Then I undropped it and got
> 
> SCSI subsystem initialized
> ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
> ACPI (acpi_bus-0191): Device is not power manageable [20060310]
> ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 19 (level, low) -> IRQ 19
> ata1: SATA max UDMA/133 cmd 0x2148 ctl 0x217E bmdma 0x2110 irq 19
> ata2: SATA max UDMA/133 cmd 0x2140 ctl 0x217A bmdma 0x2118 irq 19
> ata1.00: ATA-7, max UDMA/133, 321672960 sectors: LBA48 NCQ (depth 0/32)
> ata1.00: configured for UDMA/133
> scsi0 : ata_piix
> 
> and a computer which boots.
> 
> Look closer, please ;)

Hello, Andrew.

I see.  It seems that you're reporting two separate problems - your
PCS register doesn't report presence properly && the TF registers
report ghost device if the first device is ATAPI.  I can reproduce the
second here, but AFAIK the only controller which had problem with PCS
persence bits was ESB6300 until now.

Can you post the result of 'lspci -n' and ata_piix boot probing
messages with the following patch applied?  It would be helpful if you
tell us how devices are actually connected.  Also, where did the patch
come from?  With what comment?

Thanks.

diff --git a/drivers/scsi/ata_piix.c b/drivers/scsi/ata_piix.c
index e3184a7..4ba943e 100644
--- a/drivers/scsi/ata_piix.c
+++ b/drivers/scsi/ata_piix.c
@@ -523,7 +523,7 @@ static unsigned int piix_sata_probe (str
 	u8 pcs;
 
 	pci_read_config_byte(pdev, ICH5_PCS, &pcs);
-	DPRINTK("ata%u: ENTER, pcs=0x%x base=%d\n", ap->id, pcs, base);
+	printk("ata%u: ENTER, pcs=0x%x base=%d\n", ap->id, pcs, base);
 
 	/* enable all ports on this ap and wait for them to settle */
 	for (i = 0; i < 2; i++) {
@@ -552,7 +552,7 @@ static unsigned int piix_sata_probe (str
 	if (!(ap->flags & PIIX_FLAG_AHCI))
 		pci_write_config_byte(pdev, ICH5_PCS, pcs);
 
-	DPRINTK("ata%u: LEAVE, pcs=0x%x present_mask=0x%x\n",
+	printk("ata%u: LEAVE, pcs=0x%x present_mask=0x%x\n",
 		ap->id, pcs, present_mask);
 
 	return present_mask;

Re: [RFT] major libata update

[Jeff Garzik]

Tejun Heo wrote:
> On Thu, May 18, 2006 at 04:07:58PM -0700, Andrew Morton wrote:
>> Yes it does.  I dropped it and got
>>
>> SCSI subsystem initialized
>> ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
>> ACPI (acpi_bus-0191): Device is not power manageable [20060310]
>> ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 19 (level, low) -> IRQ 19
>> ata1: SATA max UDMA/133 cmd 0x2148 ctl 0x217E bmdma 0x2110 irq 19
>> ata2: SATA max UDMA/133 cmd 0x2140 ctl 0x217A bmdma 0x2118 irq 19
>> ata1: SATA port has no device.
>>
>> Then I undropped it and got
>>
>> SCSI subsystem initialized
>> ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
>> ACPI (acpi_bus-0191): Device is not power manageable [20060310]
>> ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 19 (level, low) -> IRQ 19
>> ata1: SATA max UDMA/133 cmd 0x2148 ctl 0x217E bmdma 0x2110 irq 19
>> ata2: SATA max UDMA/133 cmd 0x2140 ctl 0x217A bmdma 0x2118 irq 19
>> ata1.00: ATA-7, max UDMA/133, 321672960 sectors: LBA48 NCQ (depth 0/32)
>> ata1.00: configured for UDMA/133
>> scsi0 : ata_piix
>>
>> and a computer which boots.
>>
>> Look closer, please ;)
> 
> Hello, Andrew.
> 
> I see.  It seems that you're reporting two separate problems - your
> PCS register doesn't report presence properly && the TF registers
> report ghost device if the first device is ATAPI.  I can reproduce the
> second here, but AFAIK the only controller which had problem with PCS
> persence bits was ESB6300 until now.
> 
> Can you post the result of 'lspci -n' and ata_piix boot probing
> messages with the following patch applied?  It would be helpful if you
> tell us how devices are actually connected.  Also, where did the patch
> come from?  With what comment?

At this point it may be relevant to note that Intel tells me that PCS 
has changed on -every- chip.  So, ICH8 PCS register behaves differently 
from ICH7 and prior.

	Jeff

Re: [RFT] major libata update

[Tejun Heo]

Jeff Garzik wrote:
> Tejun Heo wrote:
>> On Thu, May 18, 2006 at 04:07:58PM -0700, Andrew Morton wrote:
>>> Yes it does.  I dropped it and got
>>>
>>> SCSI subsystem initialized
>>> ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
>>> ACPI (acpi_bus-0191): Device is not power manageable [20060310]
>>> ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 19 (level, low) -> IRQ 19
>>> ata1: SATA max UDMA/133 cmd 0x2148 ctl 0x217E bmdma 0x2110 irq 19
>>> ata2: SATA max UDMA/133 cmd 0x2140 ctl 0x217A bmdma 0x2118 irq 19
>>> ata1: SATA port has no device.
>>>
>>> Then I undropped it and got
>>>
>>> SCSI subsystem initialized
>>> ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
>>> ACPI (acpi_bus-0191): Device is not power manageable [20060310]
>>> ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 19 (level, low) -> IRQ 19
>>> ata1: SATA max UDMA/133 cmd 0x2148 ctl 0x217E bmdma 0x2110 irq 19
>>> ata2: SATA max UDMA/133 cmd 0x2140 ctl 0x217A bmdma 0x2118 irq 19
>>> ata1.00: ATA-7, max UDMA/133, 321672960 sectors: LBA48 NCQ (depth 0/32)
>>> ata1.00: configured for UDMA/133
>>> scsi0 : ata_piix
>>>
>>> and a computer which boots.
>>>
>>> Look closer, please ;)
>>
>> Hello, Andrew.
>>
>> I see.  It seems that you're reporting two separate problems - your
>> PCS register doesn't report presence properly && the TF registers
>> report ghost device if the first device is ATAPI.  I can reproduce the
>> second here, but AFAIK the only controller which had problem with PCS
>> persence bits was ESB6300 until now.
>>
>> Can you post the result of 'lspci -n' and ata_piix boot probing
>> messages with the following patch applied?  It would be helpful if you
>> tell us how devices are actually connected.  Also, where did the patch
>> come from?  With what comment?
> 
> At this point it may be relevant to note that Intel tells me that PCS 
> has changed on -every- chip.  So, ICH8 PCS register behaves differently 
> from ICH7 and prior.

Yeah, the PCS bit is sad to look at.  From ICH6, the docs say that the 
AHCI SStatus should be used for presence detection but that cannot be 
done without AHCI BAR mapped.

ICH7 (or 6 was it?) added a window register into AHCI area, which 
weirdly cannot be used without actually enabling AHCI BAR - what's the 
point?  My suspicion is that they designed it to work without AHCI BAR 
enabled but maybe some revisions screwed up and ICH7 still had PCS 
presence bits working, so the weird result.

I don't have ICH8 docs but, again, my guess is that they've got the 
window register correct this time and determined to screw PCS presence 
bits.  All these suspicions and guesses need verification, but if my 
guesses are right, the solution would be...

* leave anything order than ICH6 as it is now
* trust PCS presence bits for ICH6/7
* use AHCI window register to access SStatus on ICH8

-- 
tejun

Re: [RFT] major libata update

[Albert Lee]

Tejun Heo wrote:
> Albert Lee wrote:
> 
>>> To sum up, it happens when the master slot is occupied by an ATAPI
>>> device and the corresponding slave slot is empty.  The slave slot
>>> reports ATAPI signature (probably duplicated from the master) and passes
>>> all legacy presence test thus resulting in timeout on IDENTIFY.
>>>
>>
>> This problem was seen with PATA Promise 20275 adapter + IBM DVD-RAM
>> drive.
>> Single master device configuration, no slave device.
>> The master device acts as slave and creates a phantom slave device.
>> (http://marc.theaimsgroup.com/?l=linux-ide&m=113151315602979&w=2)
>>
>> The problem was later fixed by Tejun's ata_exec_internal() patch:
>> (http://marc.theaimsgroup.com/?l=linux-ide&m=113455450809405&w=2)
>> After the patch, the phantom device is finally detected by
>> ata_dev_identify().
>>
>> Libata uses polling PIO for IDENTIFY DEVICE before this major update.
>> The polling PIO finds something wrong when it reads a 0x00 device status.
>> So, the phantom device is detected quite quickly.
>>
>> With irq-driven PIO, maybe the phantom device is only detected after
>> time-out.
>> So it takes longer (30 secs) to detect the phantom device.
>>
>> No good idea how to fix this. Maybe read more registers to see whether
>> the
>> phantom device can be detected early before the IDENTIFY DEVICE.
>>
> 
> Does the Promise controller show the ghosting problem again with the
> recent updates?  ata_piix can be fixed by using PCS present bits.  I
> don't know about Promise though.
> 

Checked the Promise 20275 manual, no device present bits.

It seems we still need IDENTIFY DEVICE to identify the phantom slave.
The IDE code uses polling for IDENTIFY DEVICE. (libata did the same.)
Maybe we can also use polling for IDENTIFY DEVICE?

Could you try the attached patch to see if polling helps
to reduce the boot time? Thanks.

--
albert
(Need some time to find the specific IBM DVD-RAM drive for bug verification...)

--- upstream0/drivers/scsi/libata-core.c	2006-05-16 11:08:49.000000000 +0800
+++ 300_phantom_device/drivers/scsi/libata-core.c	2006-05-19 17:37:23.000000000 +0800
@@ -1194,6 +1194,9 @@ static int ata_dev_read_id(struct ata_de
 
 	tf.protocol = ATA_PROT_PIO;
 
+	/* Use polling for early detection of phantom device 1 */
+	tf.flags |= ATA_TFLAG_POLLING;
+
 	err_mask = ata_exec_internal(dev, &tf, NULL, DMA_FROM_DEVICE,
 				     id, sizeof(id[0]) * ATA_ID_WORDS);
 	if (err_mask) {

Re: [RFT] major libata update

[Tejun Heo]

Albert Lee wrote:
> Checked the Promise 20275 manual, no device present bits.
> 
> It seems we still need IDENTIFY DEVICE to identify the phantom slave.
> The IDE code uses polling for IDENTIFY DEVICE. (libata did the same.)
> Maybe we can also use polling for IDENTIFY DEVICE?
> 
> Could you try the attached patch to see if polling helps
> to reduce the boot time? Thanks.
> 
> --
> albert
> (Need some time to find the specific IBM DVD-RAM drive for bug verification...)
> 
> --- upstream0/drivers/scsi/libata-core.c	2006-05-16 11:08:49.000000000 +0800
> +++ 300_phantom_device/drivers/scsi/libata-core.c	2006-05-19 17:37:23.000000000 +0800
> @@ -1194,6 +1194,9 @@ static int ata_dev_read_id(struct ata_de
>  
>  	tf.protocol = ATA_PROT_PIO;
>  
> +	/* Use polling for early detection of phantom device 1 */
> +	tf.flags |= ATA_TFLAG_POLLING;
> +
>  	err_mask = ata_exec_internal(dev, &tf, NULL, DMA_FROM_DEVICE,
>  				     id, sizeof(id[0]) * ATA_ID_WORDS);
>  	if (err_mask) {
> 

Great, it worked.  Here's the relevant part of log w/ both ATA_DEBUG and 
ATA_VERBOSE_DEBUG on.  Although it tries several times but all those are 
slightly over 15secs, so it's quite usable.

[ata_eh_recover      ] ENTER
[__ata_port_freeze   ] ata1 port frozen
[piix_sata_prereset  ] ata1: ENTER, pcs=0x1f base=0
[piix_sata_prereset  ] ata1: LEAVE, pcs=0x1b present_mask=0x1
[ata_std_softreset   ] ENTER
[ata_std_softreset   ] about to softreset, devmask=3
[ata_bus_softreset   ] ata1: bus reset via SRST
[ata_dev_classify    ] found ATAPI device by sig
[ata_dev_classify    ] found ATAPI device by sig
[ata_std_softreset   ] EXIT, classes[0]=3 [1]=3
[ata_std_postreset   ] ENTER
[ata_std_postreset   ] EXIT
[ata_eh_thaw_port    ] ata1 port thawed
[ata_eh_revalidate_and_attach] ENTER
[ata_dev_read_id     ] ENTER, host 1, dev 0
[ata_dev_select      ] ENTER, ata1: device 0, wait 1
[ata_dev_select      ] ENTER, ata1: device 0, wait 1
[ata_exec_command_pio] ata1: cmd 0xA1
[ata_hsm_move        ] ata1: protocol 2 task_state 2 (dev_stat 0x5A)
[ata_pio_sector      ] data read
[ata_hsm_move        ] ata1: protocol 2 task_state 3 (dev_stat 0x50)
[ata_hsm_move        ] ata1: dev 0 command complete, drv_stat 0x50
[ata_port_flush_task ] ENTER
[ata_port_flush_task ] flush #1
[ata_port_flush_task ] flush #2
[ata_port_flush_task ] EXIT
[ata_dev_configure   ] ENTER, host 1, dev 0
[ata_dump_id         ] 49==0x0f00  53==0x0006  63==0x0007  64==0x0003 
75==0x0000
[ata_dump_id         ] 80==0x0078  81==0x0000  82==0x0000  83==0x0000 
84==0x0000
[ata_dump_id         ] 88==0x101f  93==0x4101
ata1.00: ATAPI, max UDMA/66
ata1.00: applying bridge limits
[ata_dev_configure   ] EXIT, drv_stat = 0x50
[ata_dev_read_id     ] ENTER, host 1, dev 1
[ata_dev_select      ] ENTER, ata1: device 1, wait 1
[ata_dev_select      ] ENTER, ata1: device 1, wait 1
[ata_exec_command_pio] ata1: cmd 0xA1
[ata_hsm_move        ] ata1: protocol 2 task_state 2 (dev_stat 0x0)
[ata_hsm_move        ] ata1: protocol 2 task_state 4 (dev_stat 0x0)
[__ata_port_freeze   ] ata1 port frozen
[ata_port_flush_task ] ENTER
[ata_port_flush_task ] flush #1
[ata_port_flush_task ] flush #2
[ata_port_flush_task ] EXIT
ata1.01: failed to IDENTIFY (I/O error, err_mask=0x2)
[ata_eh_revalidate_and_attach] EXIT
ata1: failed to recover some devices, retrying in 5 secs

-- 
tejun

Re: [RFT] major libata update

[Jeff Garzik]

Tejun Heo wrote:
> * Proposed solution
> 
> It seems that the only solution is to make use of the PCS presence bits 
> somehow.  It is know that 6300ESB family of controllers have flaky 
> presence bits (ata_piix marks them with PIIX_FLAG_IGNORE_PCS), but I 
> couldn't find any document/errata for PCS bits for any other 
> controllers.  So, we can use PCS for all !PIIX_FLAG_IGNORE_PCS 
> controllers or take a conservative approach and make use of it only on 
> cases where ghosting problem is reported (ICH7 and 8, I guess.  Can 
> anyone test 6?).
> 
> Please note that we already use some use of the PCS value when probing 
> SATA port.  If its value is zero, we skip the port.  It's done this way 
> mainly due to historical reasons - until recently ata_piix didn't have 
> MAP tables to map PM/PS/SM/SS to specific ports thus used the PCS values 
> in rougher form.
> 
> Jeff, what do you think?


Sounds sane...

	Jeff