[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

[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

[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

[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]

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

[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

[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]

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

[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

[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

[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]

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

[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

[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

[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

[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

[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

[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

[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

[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

[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:
> 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

[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

[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

[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

[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]

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

[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]

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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, 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

[Ric Wheeler]

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


Jeff Garzik wrote:

>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.
>
>
>  
>
I have been running a moderate write workload on this (built using 
linux-2.6.17-rc4 with your patch applied on top).  Last night, I ran on 
a set of clean AHCI based boxes (no bad drives) and got a serious of 
occasional spurious interrupts logged:


May 15 21:24:38 centera kernel: ReiserFS: sdd14: Using r5 hash to sort names
May 15 21:52:44 centera kernel: ata1: spurious interrupt (irq_stat 0x8 
active_tag -84148995 sactive 0x800)
May 15 22:00:02 centera run-crons[26837]: logrotate returned 1
May 15 22:16:00 centera kernel: ata1: spurious interrupt (irq_stat 0x8 
active_tag -84148995 sactive 0x4)
May 15 22:29:14 centera kernel: ata1: spurious interrupt (irq_stat 0x8 
active_tag -84148995 sactive 0x7e007fff)
May 15 22:35:04 centera kernel: ata3: spurious interrupt (irq_stat 0x8 
active_tag -84148995 sactive 0x4fffffff)

Full messages file and lspci below, but note that this hardware has been 
running ahci with this config in production for over a year now.

I have some bad disks that I will insert & try to get some testing on 
later today,

ric









[-- Attachment #2: messages --]
[-- Type: text/plain, Size: 15057 bytes --]

May 15 21:23:15 centera xinetd[5484]: xinetd Version 2.3.13 started with libwrap loadavg options compiled in.
May 15 21:23:15 centera xinetd[5484]: Started working: 1 available service
May 15 21:23:19 centera kernel: klogd 1.4.1, log source = /proc/kmsg started.
May 15 21:23:19 centera kernel: 
May 15 21:23:19 centera kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO
May 15 21:23:19 centera last message repeated 47 times
May 15 21:23:19 centera kernel: ReiserFS: sdb9: found reiserfs format "3.6" with standard journal
May 15 21:23:19 centera kernel: ReiserFS: sdb9: using journaled data mode
May 15 21:23:19 centera kernel: ReiserFS: sdb9: journal params: device sdb9, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:23:19 centera kernel: ReiserFS: sdb9: checking transaction log (sdb9)
May 15 21:23:19 centera kernel: ReiserFS: sdb9: Using r5 hash to sort names
May 15 21:23:19 centera kernel: ReiserFS: sdd9: found reiserfs format "3.6" with standard journal
May 15 21:23:19 centera kernel: ReiserFS: sdd9: using journaled data mode
May 15 21:23:19 centera kernel: ReiserFS: sdd9: journal params: device sdd9, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:23:19 centera kernel: ReiserFS: sdd9: checking transaction log (sdd9)
May 15 21:23:19 centera kernel: ReiserFS: sdd9: Using r5 hash to sort names
May 15 21:23:19 centera kernel: Adding 1004052k swap on /dev/cstardm9.  Priority:1 extents:1 across:1004052k
May 15 21:23:19 centera kernel: Adding 1004052k swap on /dev/cstardo9.  Priority:1 extents:1 across:1004052k
May 15 21:23:19 centera kernel: microcode: CPU0 updated from revision 0x9 to 0x12, date = 11222004 
May 15 21:23:19 centera kernel: e1000: eth0: e1000_set_tso: TSO is Enabled
May 15 21:23:21 centera kernel: e1000: eth0: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex
May 15 21:23:28 centera kernel: e1000: eth1: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex
May 15 21:23:28 centera kernel: NET: Registered protocol family 17
May 15 21:23:32 centera kernel: device eth0 entered promiscuous mode
May 15 21:23:37 centera kernel: device eth0 left promiscuous mode
May 15 21:23:37 centera kernel: e1000: eth1: e1000_set_tso: TSO is Enabled
May 15 21:23:40 centera kernel: e1000: eth1: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex
May 15 21:23:50 centera kernel: device eth0 entered promiscuous mode
May 15 21:23:55 centera kernel: device eth0 left promiscuous mode
May 15 21:23:55 centera ntpd[5715]: ntpd 4.1.1@1.786 Sat Sep 27 05:48:59 UTC 2003 (1)
May 15 21:23:55 centera ntpd[5715]: precision = 11 usec
May 15 21:23:55 centera ntpd[5715]: kernel time discipline status 0040
May 15 21:23:55 centera ntpd[5715]: Can't open /var/lib/ntp/var/run/ntp/ntpd.pid: No such file or directory
May 15 21:23:55 centera ntpd[5715]: Un-parsable frequency in /etc/ntp/drift
May 15 21:24:15 centera kernel: device eth0 entered promiscuous mode
May 15 21:24:20 centera kernel: device eth0 left promiscuous mode
May 15 21:24:22 centera kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO
May 15 21:24:22 centera last message repeated 47 times
May 15 21:24:22 centera kernel: ReiserFS: sdc10: found reiserfs format "3.6" with standard journal
May 15 21:24:22 centera kernel: ReiserFS: sdb10: found reiserfs format "3.6" with standard journal
May 15 21:24:22 centera kernel: ReiserFS: sdd10: found reiserfs format "3.6" with standard journal
May 15 21:24:22 centera kernel: ReiserFS: sda10: found reiserfs format "3.6" with standard journal
May 15 21:24:25 centera kernel: ReiserFS: sdc10: using ordered data mode
May 15 21:24:25 centera kernel: ReiserFS: sdc10: journal params: device sdc10, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:24:25 centera kernel: ReiserFS: sdc10: checking transaction log (sdc10)
May 15 21:24:25 centera kernel: ReiserFS: sdc10: Using r5 hash to sort names
May 15 21:24:25 centera kernel: ReiserFS: sdc11: found reiserfs format "3.6" with standard journal
May 15 21:24:27 centera kernel: ReiserFS: sdb10: using ordered data mode
May 15 21:24:27 centera kernel: ReiserFS: sdd10: using ordered data mode
May 15 21:24:27 centera kernel: ReiserFS: sdb10: journal params: device sdb10, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:24:27 centera kernel: ReiserFS: sdb10: checking transaction log (sdb10)
May 15 21:24:27 centera kernel: ReiserFS: sdd10: journal params: device sdd10, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:24:27 centera kernel: ReiserFS: sdd10: checking transaction log (sdd10)
May 15 21:24:27 centera kernel: ReiserFS: sdd10: Using r5 hash to sort names
May 15 21:24:27 centera kernel: ReiserFS: sdb10: Using r5 hash to sort names
May 15 21:24:27 centera kernel: ReiserFS: sda10: using ordered data mode
May 15 21:24:27 centera kernel: ReiserFS: sda10: journal params: device sda10, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:24:27 centera kernel: ReiserFS: sda10: checking transaction log (sda10)
May 15 21:24:27 centera kernel: ReiserFS: sda10: Using r5 hash to sort names
May 15 21:24:27 centera kernel: ReiserFS: sdc11: using ordered data mode
May 15 21:24:27 centera kernel: ReiserFS: sdc11: journal params: device sdc11, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:24:27 centera kernel: ReiserFS: sdc11: checking transaction log (sdc11)
May 15 21:24:27 centera kernel: ReiserFS: sdc11: Using r5 hash to sort names
May 15 21:24:27 centera kernel: ReiserFS: sdb11: found reiserfs format "3.6" with standard journal
May 15 21:24:27 centera kernel: ReiserFS: sda11: found reiserfs format "3.6" with standard journal
May 15 21:24:27 centera kernel: ReiserFS: sdd11: found reiserfs format "3.6" with standard journal
May 15 21:24:27 centera kernel: ReiserFS: sdc12: found reiserfs format "3.6" with standard journal
May 15 21:24:29 centera kernel: ReiserFS: sdb11: using ordered data mode
May 15 21:24:30 centera kernel: ReiserFS: sdd11: using ordered data mode
May 15 21:24:30 centera kernel: ReiserFS: sdb11: journal params: device sdb11, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:24:30 centera kernel: ReiserFS: sdb11: checking transaction log (sdb11)
May 15 21:24:30 centera kernel: ReiserFS: sdd11: journal params: device sdd11, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:24:30 centera kernel: ReiserFS: sdd11: checking transaction log (sdd11)
May 15 21:24:30 centera kernel: ReiserFS: sdd11: Using r5 hash to sort names
May 15 21:24:30 centera kernel: ReiserFS: sdb11: Using r5 hash to sort names
May 15 21:24:30 centera kernel: ReiserFS: sdc12: using ordered data mode
May 15 21:24:30 centera kernel: ReiserFS: sdc12: journal params: device sdc12, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:24:30 centera kernel: ReiserFS: sdc12: checking transaction log (sdc12)
May 15 21:24:30 centera kernel: ReiserFS: sdc12: Using r5 hash to sort names
May 15 21:24:30 centera kernel: ReiserFS: sda11: using ordered data mode
May 15 21:24:30 centera kernel: ReiserFS: sda11: journal params: device sda11, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:24:30 centera kernel: ReiserFS: sda11: checking transaction log (sda11)
May 15 21:24:30 centera kernel: ReiserFS: sda11: Using r5 hash to sort names
May 15 21:24:30 centera kernel: ReiserFS: sdb12: found reiserfs format "3.6" with standard journal
May 15 21:24:30 centera kernel: ReiserFS: sda12: found reiserfs format "3.6" with standard journal
May 15 21:24:30 centera kernel: ReiserFS: sdd12: found reiserfs format "3.6" with standard journal
May 15 21:24:30 centera kernel: ReiserFS: sdc13: found reiserfs format "3.6" with standard journal
May 15 21:24:32 centera kernel: ReiserFS: sdb12: using ordered data mode
May 15 21:24:32 centera kernel: ReiserFS: sdb12: journal params: device sdb12, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:24:32 centera kernel: ReiserFS: sdb12: checking transaction log (sdb12)
May 15 21:24:32 centera kernel: ReiserFS: sdb12: Using r5 hash to sort names
May 15 21:24:32 centera kernel: ReiserFS: sda12: using ordered data mode
May 15 21:24:32 centera kernel: ReiserFS: sda12: journal params: device sda12, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:24:32 centera kernel: ReiserFS: sda12: checking transaction log (sda12)
May 15 21:24:32 centera kernel: ReiserFS: sdd12: using ordered data mode
May 15 21:24:32 centera kernel: ReiserFS: sdd12: journal params: device sdd12, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:24:33 centera kernel: ReiserFS: sdd12: checking transaction log (sdd12)
May 15 21:24:33 centera kernel: ReiserFS: sda12: Using r5 hash to sort names
May 15 21:24:33 centera kernel: ReiserFS: sdd12: Using r5 hash to sort names
May 15 21:24:33 centera kernel: ReiserFS: sdc13: using ordered data mode
May 15 21:24:33 centera kernel: ReiserFS: sdc13: journal params: device sdc13, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:24:33 centera kernel: ReiserFS: sdc13: checking transaction log (sdc13)
May 15 21:24:33 centera kernel: ReiserFS: sdc13: Using r5 hash to sort names
May 15 21:24:33 centera kernel: ReiserFS: sdd13: found reiserfs format "3.6" with standard journal
May 15 21:24:33 centera kernel: ReiserFS: sda13: found reiserfs format "3.6" with standard journal
May 15 21:24:33 centera kernel: ReiserFS: sdc14: found reiserfs format "3.6" with standard journal
May 15 21:24:33 centera kernel: ReiserFS: sdb13: found reiserfs format "3.6" with standard journal
May 15 21:24:35 centera kernel: ReiserFS: sdc14: using ordered data mode
May 15 21:24:35 centera kernel: ReiserFS: sdc14: journal params: device sdc14, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:24:35 centera kernel: ReiserFS: sdc14: checking transaction log (sdc14)
May 15 21:24:36 centera kernel: ReiserFS: sdb13: using ordered data mode
May 15 21:24:36 centera kernel: ReiserFS: sdc14: Using r5 hash to sort names
May 15 21:24:36 centera kernel: ReiserFS: sdb13: journal params: device sdb13, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:24:36 centera kernel: ReiserFS: sdb13: checking transaction log (sdb13)
May 15 21:24:36 centera kernel: ReiserFS: sda13: using ordered data mode
May 15 21:24:36 centera kernel: ReiserFS: sdb13: Using r5 hash to sort names
May 15 21:24:36 centera kernel: ReiserFS: sda13: journal params: device sda13, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:24:36 centera kernel: ReiserFS: sda13: checking transaction log (sda13)
May 15 21:24:36 centera kernel: ReiserFS: sdd13: using ordered data mode
May 15 21:24:36 centera kernel: ReiserFS: sdd13: journal params: device sdd13, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:24:36 centera kernel: ReiserFS: sdd13: checking transaction log (sdd13)
May 15 21:24:36 centera kernel: ReiserFS: sda13: Using r5 hash to sort names
May 15 21:24:36 centera kernel: ReiserFS: sdd13: Using r5 hash to sort names
May 15 21:24:36 centera kernel: ReiserFS: sda14: found reiserfs format "3.6" with standard journal
May 15 21:24:36 centera kernel: ReiserFS: sdb14: found reiserfs format "3.6" with standard journal
May 15 21:24:36 centera kernel: ReiserFS: sdd14: found reiserfs format "3.6" with standard journal
May 15 21:24:38 centera kernel: ReiserFS: sdb14: using ordered data mode
May 15 21:24:38 centera kernel: ReiserFS: sdb14: journal params: device sdb14, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:24:38 centera kernel: ReiserFS: sdb14: checking transaction log (sdb14)
May 15 21:24:38 centera kernel: ReiserFS: sdd14: using ordered data mode
May 15 21:24:38 centera kernel: ReiserFS: sda14: using ordered data mode
May 15 21:24:38 centera kernel: ReiserFS: sdb14: Using r5 hash to sort names
May 15 21:24:38 centera kernel: ReiserFS: sda14: journal params: device sda14, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:24:38 centera kernel: ReiserFS: sda14: checking transaction log (sda14)
May 15 21:24:38 centera kernel: ReiserFS: sdd14: journal params: device sdd14, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 15 21:24:38 centera kernel: ReiserFS: sdd14: checking transaction log (sdd14)
May 15 21:24:38 centera kernel: ReiserFS: sda14: Using r5 hash to sort names
May 15 21:24:38 centera kernel: ReiserFS: sdd14: Using r5 hash to sort names
May 15 21:52:44 centera kernel: ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x800)
May 15 22:00:02 centera run-crons[26837]: logrotate returned 1
May 15 22:16:00 centera kernel: ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x4)
May 15 22:29:14 centera kernel: ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x7e007fff)
May 15 22:35:04 centera kernel: ata3: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x4fffffff)
May 15 23:00:01 centera run-crons[18123]: logrotate returned 1
May 16 00:00:01 centera run-crons[12217]: logrotate returned 1
May 16 01:00:01 centera run-crons[6356]: logrotate returned 1
May 16 02:00:02 centera run-crons[487]: logrotate returned 1
May 16 03:00:01 centera run-crons[27086]: logrotate returned 1
May 16 04:00:01 centera run-crons[21110]: logrotate returned 1
May 16 04:15:05 centera logrotate: ALERT exited abnormally with [1]
May 16 05:00:01 centera run-crons[15671]: logrotate returned 1
May 16 06:00:01 centera run-crons[9783]: logrotate returned 1
May 16 07:00:01 centera run-crons[3913]: logrotate returned 1
May 16 08:00:02 centera run-crons[30486]: logrotate returned 1
May 16 09:00:01 centera run-crons[24591]: logrotate returned 1
May 16 10:00:01 centera run-crons[18768]: logrotate returned 1
May 16 11:00:01 centera run-crons[12894]: logrotate returned 1
May 16 12:00:01 centera run-crons[6992]: logrotate returned 1

[-- Attachment #3: lspci.txt --]
[-- Type: text/plain, Size: 7225 bytes --]

0000:00:00.0 Host bridge: Intel Corporation E7220/E7221 Memory Controller Hub (rev 05)
	Subsystem: Intel Corporation E7220/E7221 Memory Controller Hub
	Flags: bus master, fast devsel, latency 0
	Capabilities: [e0] #09 [2109]

0000:00:01.0 PCI bridge: Intel Corporation E7220/E7221 PCI Express Root Port (rev 05) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=01, subordinate=03, sec-latency=0
	I/O behind bridge: 0000c000-0000dfff
	Memory behind bridge: d0000000-d02fffff
	Capabilities: [88] #0d [0000]
	Capabilities: [80] Power Management version 2
	Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
	Capabilities: [a0] #10 [0141]

0000:00:02.0 VGA compatible controller: Intel Corporation E7221 Integrated Graphics Controller (rev 05) (prog-if 00 [VGA])
	Subsystem: Tyan Computer: Unknown device 5150
	Flags: bus master, fast devsel, latency 0, IRQ 12
	Memory at d0300000 (32-bit, non-prefetchable) [size=512K]
	I/O ports at e000 [size=8]
	Memory at c0000000 (32-bit, prefetchable) [size=256M]
	Memory at d0380000 (32-bit, non-prefetchable) [size=256K]
	Capabilities: [d0] Power Management version 2

0000:00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) (prog-if 00 [UHCI])
	Subsystem: Tyan Computer: Unknown device 5150
	Flags: bus master, medium devsel, latency 0, IRQ 3
	I/O ports at e100 [size=32]

0000:00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) (prog-if 00 [UHCI])
	Subsystem: Tyan Computer: Unknown device 5150
	Flags: bus master, medium devsel, latency 0, IRQ 10
	I/O ports at e200 [size=32]

0000:00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) (prog-if 00 [UHCI])
	Subsystem: Tyan Computer: Unknown device 5150
	Flags: bus master, medium devsel, latency 0, IRQ 7
	I/O ports at e300 [size=32]

0000:00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) (prog-if 00 [UHCI])
	Subsystem: Tyan Computer: Unknown device 5150
	Flags: bus master, medium devsel, latency 0, IRQ 12
	I/O ports at e400 [size=32]

0000:00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) (prog-if 20 [EHCI])
	Subsystem: Tyan Computer: Unknown device 5150
	Flags: bus master, medium devsel, latency 0, IRQ 3
	Memory at d03c0000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2

0000:00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3) (prog-if 01 [Subtractive decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=04, subordinate=04, sec-latency=32
	Capabilities: [50] #0d [0000]

0000:00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge (rev 03)
	Subsystem: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge
	Flags: bus master, medium devsel, latency 0

0000:00:1f.2 IDE interface: Intel Corporation 82801FR/FRW (ICH6R/ICH6RW) SATA Controller (rev 03) (prog-if 8f [Master SecP SecO PriP PriO])
	Subsystem: Tyan Computer: Unknown device 5150
	Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 17
	I/O ports at e900 [size=8]
	I/O ports at ea00 [size=4]
	I/O ports at eb00 [size=8]
	I/O ports at ec00 [size=4]
	I/O ports at ed00 [size=16]
	Memory at d03c3000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [70] Power Management version 2

0000:00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03)
	Subsystem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller
	Flags: medium devsel, IRQ 10
	I/O ports at 0500 [size=32]

0000:01:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge A (rev 09) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=01, secondary=02, subordinate=02, sec-latency=64
	I/O behind bridge: 0000c000-0000cfff
	Memory behind bridge: d0000000-d00fffff
	Capabilities: [44] #10 [0071]
	Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
	Capabilities: [6c] Power Management version 2
	Capabilities: [d8] PCI-X bridge device.

0000:01:00.1 PIC: Intel Corporation 6700/6702PXH I/OxAPIC Interrupt Controller A (rev 09) (prog-if 20 [IO(X)-APIC])
	Flags: bus master, fast devsel, latency 0
	Memory at d0200000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] #10 [0001]
	Capabilities: [6c] Power Management version 2

0000:01:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B (rev 09) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=01, secondary=03, subordinate=03, sec-latency=64
	I/O behind bridge: 0000d000-0000dfff
	Memory behind bridge: d0100000-d01fffff
	Capabilities: [44] #10 [0071]
	Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
	Capabilities: [6c] Power Management version 2
	Capabilities: [d8] PCI-X bridge device.

0000:01:00.3 PIC: Intel Corporation 6700PXH I/OxAPIC Interrupt Controller B (rev 09) (prog-if 20 [IO(X)-APIC])
	Flags: bus master, fast devsel, latency 0
	Memory at d0201000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] #10 [0001]
	Capabilities: [6c] Power Management version 2

0000:02:06.0 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
	Subsystem: Intel Corporation PRO/1000 MT Dual Port Network Connection
	Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 17
	Memory at d0000000 (64-bit, non-prefetchable) [size=128K]
	I/O ports at c000 [size=64]
	Capabilities: [dc] Power Management version 2
	Capabilities: [e4] PCI-X non-bridge device.
	Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-

0000:02:06.1 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
	Subsystem: Intel Corporation: Unknown device 1179
	Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 18
	Memory at d0020000 (64-bit, non-prefetchable) [size=128K]
	I/O ports at c100 [size=64]
	Capabilities: [dc] Power Management version 2
	Capabilities: [e4] PCI-X non-bridge device.
	Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-

0000:03:07.0 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
	Subsystem: Intel Corporation PRO/1000 MT Dual Port Network Connection
	Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 19
	Memory at d0100000 (64-bit, non-prefetchable) [size=128K]
	I/O ports at d000 [size=64]
	Capabilities: [dc] Power Management version 2
	Capabilities: [e4] PCI-X non-bridge device.
	Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-

0000:03:07.1 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
	Subsystem: Intel Corporation PRO/1000 MT Dual Port Network Connection
	Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 16
	Memory at d0120000 (64-bit, non-prefetchable) [size=128K]
	I/O ports at d100 [size=64]
	Capabilities: [dc] Power Management version 2
	Capabilities: [e4] PCI-X non-bridge device.
	Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-

Re: [RFT] major libata update

[Jeff Garzik]

Ric Wheeler wrote:
> 
> Jeff Garzik wrote:
> 
>> 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.
>>
>>
>>  
>>
> I have been running a moderate write workload on this (built using 
> linux-2.6.17-rc4 with your patch applied on top).  Last night, I ran on 
> a set of clean AHCI based boxes (no bad drives) and got a serious of 
> occasional spurious interrupts logged:
> 
> 
> May 15 21:24:38 centera kernel: ReiserFS: sdd14: Using r5 hash to sort 
> names
> May 15 21:52:44 centera kernel: ata1: spurious interrupt (irq_stat 0x8 
> active_tag -84148995 sactive 0x800)
> May 15 22:00:02 centera run-crons[26837]: logrotate returned 1
> May 15 22:16:00 centera kernel: ata1: spurious interrupt (irq_stat 0x8 
> active_tag -84148995 sactive 0x4)
> May 15 22:29:14 centera kernel: ata1: spurious interrupt (irq_stat 0x8 
> active_tag -84148995 sactive 0x7e007fff)
> May 15 22:35:04 centera kernel: ata3: spurious interrupt (irq_stat 0x8 
> active_tag -84148995 sactive 0x4fffffff)
> 
> Full messages file and lspci below, but note that this hardware has been 
> running ahci with this config in production for over a year now.

Definitely new behavior.  In each case you have irq_stat == 0x8, which 
indicates a Set Device Bits FIS has been received.

	Jeff

Re: [RFT] major libata update

[Tejun Heo]

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

Jeff Garzik wrote:
> Ric Wheeler wrote:
>>
>> Jeff Garzik wrote:
>>
>>> 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.
>>>
>>>
>>>  
>>>
>> I have been running a moderate write workload on this (built using 
>> linux-2.6.17-rc4 with your patch applied on top).  Last night, I ran 
>> on a set of clean AHCI based boxes (no bad drives) and got a serious 
>> of occasional spurious interrupts logged:
>>
>>
>> May 15 21:24:38 centera kernel: ReiserFS: sdd14: Using r5 hash to sort 
>> names
>> May 15 21:52:44 centera kernel: ata1: spurious interrupt (irq_stat 0x8 
>> active_tag -84148995 sactive 0x800)
>> May 15 22:00:02 centera run-crons[26837]: logrotate returned 1
>> May 15 22:16:00 centera kernel: ata1: spurious interrupt (irq_stat 0x8 
>> active_tag -84148995 sactive 0x4)
>> May 15 22:29:14 centera kernel: ata1: spurious interrupt (irq_stat 0x8 
>> active_tag -84148995 sactive 0x7e007fff)
>> May 15 22:35:04 centera kernel: ata3: spurious interrupt (irq_stat 0x8 
>> active_tag -84148995 sactive 0x4fffffff)
>>
>> Full messages file and lspci below, but note that this hardware has 
>> been running ahci with this config in production for over a year now.
> 
> Definitely new behavior.  In each case you have irq_stat == 0x8, which 
> indicates a Set Device Bits FIS has been received.
> 

Yeap, new behavior.  Though, one thing to note is that the original 
ahci_host_intr() never bothered to report spurious interrupt.  It always 
returned 1 telling ahci_interrupt() that the interrupt is handled.  But 
as this is SDB instead of D2H, my guess is that the drive is sending 
spurious NCQ completions with no new command completed.

Hmm.. Can you try the attached patch and report what the kernel says?

The message reminds me of several things...

* can we make tags int and use -1 for invalid tag?  ATA_TAG_POISON looks 
horrible when printed.

* it would be nice to have some framework to determine whether the 
controller is receiving too many consecutive spurious interrupts.  Say, 
32 irqs in a row without intervening valid interrupts is a good reason 
to be suspicious about stuck IRQ.  Freezing & resetting will resolve the 
situation in most cases.

* With NCQ, some drives generate spurious D2H FISes with I bit set as if 
it were executing non-NCQ commands.  So, regardless of controller, we're 
likely to see similar problems (but sil24 does all the protocol handling 
and ignores such FISes by itself).  This can be combined with the above 
freeze on too many spurious, I guess.

-- 
tejun

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 772 bytes --]

diff --git a/drivers/scsi/ahci.c b/drivers/scsi/ahci.c
index 45fd71d..506f0df 100644
--- a/drivers/scsi/ahci.c
+++ b/drivers/scsi/ahci.c
@@ -916,10 +916,19 @@ static void ahci_host_intr(struct ata_po
 			return;
 	}
 
-	if (ata_ratelimit())
+	if (ata_ratelimit()) {
 		ata_port_printk(ap, KERN_INFO, "spurious interrupt "
 				"(irq_stat 0x%x active_tag %d sactive 0x%x)\n",
 				status, ap->active_tag, ap->sactive);
+		if (status & PORT_IRQ_SDB_FIS) {
+			struct ahci_port_priv *pp = ap->private_data;
+			u32 *sdb_fis = pp->rx_fis + 0x58;
+
+			ata_port_printk(ap, KERN_INFO, "spurious SDB FIS "
+				"%08x:%08x ap->qc_active=%08x qc_active=%08x\n",
+				sdb_fis[0], sdb_fis[1], ap->qc_active, qc_active);
+		}
+	}
 }
 
 static void ahci_irq_clear(struct ata_port *ap)

Re: [RFT] major libata update

[Ric Wheeler]

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

Tejun Heo wrote:

> J
>
>>
>> Definitely new behavior.  In each case you have irq_stat == 0x8, 
>> which indicates a Set Device Bits FIS has been received.
>>
>
> Yeap, new behavior.  Though, one thing to note is that the original 
> ahci_host_intr() never bothered to report spurious interrupt.  It 
> always returned 1 telling ahci_interrupt() that the interrupt is 
> handled.  But as this is SDB instead of D2H, my guess is that the 
> drive is sending spurious NCQ completions with no new command completed.
>
> Hmm.. Can you try the attached patch and report what the kernel says?
>
> The message reminds me of several things...
>
> * can we make tags int and use -1 for invalid tag?  ATA_TAG_POISON 
> looks horrible when printed.
>
> * it would be nice to have some framework to determine whether the 
> controller is receiving too many consecutive spurious interrupts.  
> Say, 32 irqs in a row without intervening valid interrupts is a good 
> reason to be suspicious about stuck IRQ.  Freezing & resetting will 
> resolve the situation in most cases.
>
> * With NCQ, some drives generate spurious D2H FISes with I bit set as 
> if it were executing non-NCQ commands.  So, regardless of controller, 
> we're likely to see similar problems (but sil24 does all the protocol 
> handling and ignores such FISes by itself).  This can be combined with 
> the above freeze on too many spurious, I guess.

Here is the result of running with your patch applied (on a set of nodes):

c001n01: 0: [  OK  ]
ata3: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
0x2000000f)
ata3: spurious SDB FIS 004040a1:10000000 ap->qc_active=2000000f 
qc_active=2000000f
ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0xfffc0)
ata1: spurious SDB FIS 004040a1:00000020 ap->qc_active=000fffc0 
qc_active=000fffc0
ata2: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
0x7fffff3f)
ata2: spurious SDB FIS 004040a1:00000080 ap->qc_active=7fffff3f 
qc_active=7fffff3f
ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
0x7fffff9f)
ata1: spurious SDB FIS 004040a1:00000040 ap->qc_active=7fffff9f 
qc_active=7fffff9f
c001n03: 0: [  OK  ]
ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
0x7ffe7fff)
ata1: spurious SDB FIS 004040a1:00010000 ap->qc_active=7ffe7fff 
qc_active=7ffe7fff
c001n04: 0: [  OK  ]
ata3: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x31)
ata3: spurious SDB FIS 004040a1:00000008 ap->qc_active=00000031 
qc_active=00000031
ata3: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
0x7fff800f)
ata3: spurious SDB FIS 004040a1:00004000 ap->qc_active=7fff800f 
qc_active=7fff800f
c001n06: 1: [ FAIL ]
c001n07: 0: [  OK  ]
ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
0x7ffffcff)
ata1: spurious SDB FIS 004040a1:00000200 ap->qc_active=7ffffcff 
qc_active=7ffffcff
c001n08: 0: [  OK  ]
ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
0x4fffffff)
ata1: spurious SDB FIS 004040a1:20000000 ap->qc_active=4fffffff 
qc_active=4fffffff


Attached is one (pretty uninteresting) whole log,

ric








[-- Attachment #2: messages --]
[-- Type: text/plain, Size: 14818 bytes --]

May 16 16:27:10 centera exiting on signal 15
May 16 16:28:55 centera syslogd 1.4.1: restart.
May 16 16:28:55 centera xinetd[5605]: xinetd Version 2.3.13 started with libwrap loadavg options compiled in.
May 16 16:28:55 centera xinetd[5605]: Started working: 1 available service
May 16 16:29:00 centera kernel: klogd 1.4.1, log source = /proc/kmsg started.
May 16 16:29:00 centera kernel: 
May 16 16:29:00 centera kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO
May 16 16:29:00 centera last message repeated 47 times
May 16 16:29:00 centera kernel: ReiserFS: sdb9: found reiserfs format "3.6" with standard journal
May 16 16:29:00 centera kernel: ReiserFS: sdb9: using journaled data mode
May 16 16:29:00 centera kernel: ReiserFS: sdb9: journal params: device sdb9, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:29:00 centera kernel: ReiserFS: sdb9: checking transaction log (sdb9)
May 16 16:29:00 centera kernel: ReiserFS: sdb9: Using r5 hash to sort names
May 16 16:29:00 centera kernel: ReiserFS: sdd9: found reiserfs format "3.6" with standard journal
May 16 16:29:00 centera kernel: ReiserFS: sdd9: using journaled data mode
May 16 16:29:00 centera kernel: ReiserFS: sdd9: journal params: device sdd9, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:29:00 centera kernel: ReiserFS: sdd9: checking transaction log (sdd9)
May 16 16:29:00 centera kernel: ReiserFS: sdd9: Using r5 hash to sort names
May 16 16:29:00 centera kernel: Adding 1004052k swap on /dev/cstardm9.  Priority:1 extents:1 across:1004052k
May 16 16:29:00 centera kernel: Adding 1004052k swap on /dev/cstardo9.  Priority:1 extents:1 across:1004052k
May 16 16:29:00 centera kernel: e1000: eth2: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex
May 16 16:29:00 centera kernel: e1000: eth2: e1000_set_tso: TSO is Enabled
May 16 16:29:00 centera kernel: microcode: CPU0 updated from revision 0x9 to 0x12, date = 11222004 
May 16 16:29:00 centera kernel: e1000: eth2: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex
May 16 16:29:00 centera kernel: e1000: eth0: e1000_set_tso: TSO is Enabled
May 16 16:29:01 centera kernel: e1000: eth0: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex
May 16 16:29:08 centera kernel: e1000: eth1: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex
May 16 16:29:08 centera kernel: NET: Registered protocol family 17
May 16 16:29:11 centera kernel: device eth0 entered promiscuous mode
May 16 16:29:16 centera kernel: device eth0 left promiscuous mode
May 16 16:29:16 centera kernel: e1000: eth1: e1000_set_tso: TSO is Enabled
May 16 16:29:19 centera kernel: e1000: eth1: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex
May 16 16:29:30 centera ntpd[5859]: ntpd 4.1.1@1.786 Sat Sep 27 05:48:59 UTC 2003 (1)
May 16 16:29:30 centera ntpd[5859]: precision = 8 usec
May 16 16:29:30 centera ntpd[5859]: kernel time discipline status 0040
May 16 16:29:30 centera ntpd[5859]: Can't open /var/lib/ntp/var/run/ntp/ntpd.pid: No such file or directory
May 16 16:29:30 centera ntpd[5859]: frequency initialized 2.597 from /etc/ntp/drift
May 16 16:30:01 centera kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO
May 16 16:30:01 centera last message repeated 47 times
May 16 16:30:01 centera kernel: ReiserFS: sdb10: found reiserfs format "3.6" with standard journal
May 16 16:30:01 centera kernel: ReiserFS: sdc10: found reiserfs format "3.6" with standard journal
May 16 16:30:01 centera kernel: ReiserFS: sdd10: found reiserfs format "3.6" with standard journal
May 16 16:30:01 centera kernel: ReiserFS: sda10: found reiserfs format "3.6" with standard journal
May 16 16:30:03 centera kernel: ReiserFS: sdd10: using ordered data mode
May 16 16:30:03 centera kernel: ReiserFS: sdd10: journal params: device sdd10, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:30:03 centera kernel: ReiserFS: sdd10: checking transaction log (sdd10)
May 16 16:30:03 centera kernel: ReiserFS: sdd10: Using r5 hash to sort names
May 16 16:30:03 centera kernel: ReiserFS: sda10: using ordered data mode
May 16 16:30:04 centera kernel: ReiserFS: sda10: journal params: device sda10, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:30:04 centera kernel: ReiserFS: sda10: checking transaction log (sda10)
May 16 16:30:04 centera kernel: ReiserFS: sda10: Using r5 hash to sort names
May 16 16:30:04 centera kernel: ReiserFS: sdb10: using ordered data mode
May 16 16:30:04 centera kernel: ReiserFS: sdb10: journal params: device sdb10, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:30:04 centera kernel: ReiserFS: sdb10: checking transaction log (sdb10)
May 16 16:30:04 centera kernel: ReiserFS: sdb10: Using r5 hash to sort names
May 16 16:30:04 centera kernel: ReiserFS: sdc10: using ordered data mode
May 16 16:30:04 centera kernel: ReiserFS: sdc10: journal params: device sdc10, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:30:04 centera kernel: ReiserFS: sdc10: checking transaction log (sdc10)
May 16 16:30:04 centera kernel: ReiserFS: sdc10: Using r5 hash to sort names
May 16 16:30:04 centera kernel: ReiserFS: sda11: found reiserfs format "3.6" with standard journal
May 16 16:30:04 centera kernel: ReiserFS: sdb11: found reiserfs format "3.6" with standard journal
May 16 16:30:04 centera kernel: ReiserFS: sdc11: found reiserfs format "3.6" with standard journal
May 16 16:30:04 centera kernel: ReiserFS: sdd11: found reiserfs format "3.6" with standard journal
May 16 16:30:06 centera kernel: ReiserFS: sda11: using ordered data mode
May 16 16:30:06 centera kernel: ReiserFS: sda11: journal params: device sda11, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:30:06 centera kernel: ReiserFS: sda11: checking transaction log (sda11)
May 16 16:30:06 centera kernel: ReiserFS: sdc11: using ordered data mode
May 16 16:30:06 centera kernel: ReiserFS: sda11: Using r5 hash to sort names
May 16 16:30:06 centera kernel: ReiserFS: sdc11: journal params: device sdc11, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:30:06 centera kernel: ReiserFS: sdc11: checking transaction log (sdc11)
May 16 16:30:06 centera kernel: ReiserFS: sdb11: using ordered data mode
May 16 16:30:06 centera kernel: ReiserFS: sdc11: Using r5 hash to sort names
May 16 16:30:06 centera kernel: ReiserFS: sdb11: journal params: device sdb11, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:30:06 centera kernel: ReiserFS: sdb11: checking transaction log (sdb11)
May 16 16:30:06 centera kernel: ReiserFS: sdb11: Using r5 hash to sort names
May 16 16:30:06 centera kernel: ReiserFS: sdd11: using ordered data mode
May 16 16:30:06 centera kernel: ReiserFS: sdd11: journal params: device sdd11, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:30:06 centera kernel: ReiserFS: sdd11: checking transaction log (sdd11)
May 16 16:30:07 centera kernel: ReiserFS: sdc12: found reiserfs format "3.6" with standard journal
May 16 16:30:07 centera kernel: ReiserFS: sdb12: found reiserfs format "3.6" with standard journal
May 16 16:30:07 centera kernel: ReiserFS: sda12: found reiserfs format "3.6" with standard journal
May 16 16:30:07 centera kernel: ReiserFS: sdd11: Using r5 hash to sort names
May 16 16:30:09 centera kernel: ReiserFS: sda12: using ordered data mode
May 16 16:30:09 centera kernel: ReiserFS: sda12: journal params: device sda12, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:30:09 centera kernel: ReiserFS: sda12: checking transaction log (sda12)
May 16 16:30:09 centera kernel: ReiserFS: sda12: Using r5 hash to sort names
May 16 16:30:09 centera kernel: ReiserFS: sdb12: using ordered data mode
May 16 16:30:09 centera kernel: ReiserFS: sdb12: journal params: device sdb12, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:30:09 centera kernel: ReiserFS: sdb12: checking transaction log (sdb12)
May 16 16:30:09 centera kernel: ReiserFS: sdc12: using ordered data mode
May 16 16:30:09 centera kernel: ReiserFS: sdc12: journal params: device sdc12, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:30:09 centera kernel: ReiserFS: sdc12: checking transaction log (sdc12)
May 16 16:30:09 centera kernel: ReiserFS: sdb12: Using r5 hash to sort names
May 16 16:30:09 centera kernel: ReiserFS: sdc12: Using r5 hash to sort names
May 16 16:30:09 centera kernel: ReiserFS: sdd12: found reiserfs format "3.6" with standard journal
May 16 16:30:09 centera kernel: ReiserFS: sda13: found reiserfs format "3.6" with standard journal
May 16 16:30:09 centera kernel: ReiserFS: sdc13: found reiserfs format "3.6" with standard journal
May 16 16:30:09 centera kernel: ReiserFS: sdb13: found reiserfs format "3.6" with standard journal
May 16 16:30:11 centera kernel: ReiserFS: sdd12: using ordered data mode
May 16 16:30:11 centera kernel: ReiserFS: sdd12: journal params: device sdd12, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:30:11 centera kernel: ReiserFS: sdd12: checking transaction log (sdd12)
May 16 16:30:11 centera kernel: ReiserFS: sdd12: Using r5 hash to sort names
May 16 16:30:11 centera kernel: ReiserFS: sdb13: using ordered data mode
May 16 16:30:12 centera kernel: ReiserFS: sdb13: journal params: device sdb13, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:30:12 centera kernel: ReiserFS: sdb13: checking transaction log (sdb13)
May 16 16:30:12 centera kernel: ReiserFS: sdb13: Using r5 hash to sort names
May 16 16:30:12 centera kernel: ReiserFS: sda13: using ordered data mode
May 16 16:30:12 centera kernel: ReiserFS: sda13: journal params: device sda13, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:30:12 centera kernel: ReiserFS: sda13: checking transaction log (sda13)
May 16 16:30:12 centera kernel: ReiserFS: sda13: Using r5 hash to sort names
May 16 16:30:12 centera kernel: ReiserFS: sdc13: using ordered data mode
May 16 16:30:12 centera kernel: ReiserFS: sdc13: journal params: device sdc13, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:30:12 centera kernel: ReiserFS: sdc13: checking transaction log (sdc13)
May 16 16:30:12 centera kernel: ReiserFS: sdc13: Using r5 hash to sort names
May 16 16:30:12 centera kernel: ReiserFS: sdd13: found reiserfs format "3.6" with standard journal
May 16 16:30:12 centera kernel: ReiserFS: sdb14: found reiserfs format "3.6" with standard journal
May 16 16:30:12 centera kernel: ReiserFS: sda14: found reiserfs format "3.6" with standard journal
May 16 16:30:12 centera kernel: ReiserFS: sdc14: found reiserfs format "3.6" with standard journal
May 16 16:30:15 centera kernel: ReiserFS: sdb14: using ordered data mode
May 16 16:30:15 centera kernel: ReiserFS: sdd13: using ordered data mode
May 16 16:30:15 centera kernel: ReiserFS: sdd13: journal params: device sdd13, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:30:15 centera kernel: ReiserFS: sdd13: checking transaction log (sdd13)
May 16 16:30:15 centera kernel: ReiserFS: sdb14: journal params: device sdb14, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:30:15 centera kernel: ReiserFS: sdb14: checking transaction log (sdb14)
May 16 16:30:15 centera kernel: ReiserFS: sdd13: Using r5 hash to sort names
May 16 16:30:15 centera kernel: ReiserFS: sdb14: Using r5 hash to sort names
May 16 16:30:15 centera kernel: ReiserFS: sda14: using ordered data mode
May 16 16:30:15 centera kernel: ReiserFS: sda14: journal params: device sda14, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:30:15 centera kernel: ReiserFS: sda14: checking transaction log (sda14)
May 16 16:30:15 centera kernel: ReiserFS: sda14: Using r5 hash to sort names
May 16 16:30:15 centera kernel: ReiserFS: sdc14: using ordered data mode
May 16 16:30:15 centera kernel: ReiserFS: sdc14: journal params: device sdc14, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:30:15 centera kernel: ReiserFS: sdc14: checking transaction log (sdc14)
May 16 16:30:15 centera kernel: ReiserFS: sdc14: Using r5 hash to sort names
May 16 16:30:15 centera kernel: ReiserFS: sdd14: found reiserfs format "3.6" with standard journal
May 16 16:30:17 centera kernel: ReiserFS: sdd14: using ordered data mode
May 16 16:30:17 centera kernel: ReiserFS: sdd14: journal params: device sdd14, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
May 16 16:30:17 centera kernel: ReiserFS: sdd14: checking transaction log (sdd14)
May 16 16:30:17 centera kernel: ReiserFS: sdd14: Using r5 hash to sort names
May 16 17:00:02 centera run-crons[19634]: logrotate returned 1
May 16 17:16:57 centera kernel: ata3: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x2000000f)
May 16 17:16:57 centera kernel: ata3: spurious SDB FIS 004040a1:10000000 ap->qc_active=2000000f qc_active=2000000f
May 16 17:21:36 centera kernel: ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0xfffc0)
May 16 17:21:36 centera kernel: ata1: spurious SDB FIS 004040a1:00000020 ap->qc_active=000fffc0 qc_active=000fffc0
May 16 17:38:45 centera kernel: ata2: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x7fffff3f)
May 16 17:38:45 centera kernel: ata2: spurious SDB FIS 004040a1:00000080 ap->qc_active=7fffff3f qc_active=7fffff3f
May 16 17:59:52 centera kernel: ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x7fffff9f)
May 16 17:59:52 centera kernel: ata1: spurious SDB FIS 004040a1:00000040 ap->qc_active=7fffff9f qc_active=7fffff9f
May 16 18:00:04 centera run-crons[10734]: logrotate returned 1
May 16 19:00:02 centera run-crons[5306]: logrotate returned 1

Re: [RFT] major libata update

[Ric Wheeler]

One other note, it seems like this patch set has broken the write 
barrier support - is that a side effect of enabling NCQ still?

I see messages that claim flush barriers are enabled:

[root@c001n01 root]# mount -o 
barrier=flush,rw,noatime,nodiratime,data=ordered,notail /dev/sda10 /mnt/1
May 16 22:21:56 centera kernel: ReiserFS: sda10: found reiserfs format 
"3.6" with standard journal
[root@c001n01 root]# May 16 22:21:58 centera kernel: ReiserFS: sda10: 
using ordered data mode
May 16 22:21:58 centera kernel: reiserfs: using flush barriers
May 16 22:21:58 centera kernel: ReiserFS: sda10: journal params: device 
sda10, size 8192, journal first block 18, max trans len 1024, max batch 
900, max commit age 30, max trans age 30
May 16 22:21:58 centera kernel: ReiserFS: sda10: checking transaction 
log (sda10)
May 16 22:21:58 centera kernel: ReiserFS: sda10: Using r5 hash to sort names

But when I test with my synchronous write load, I am going at 6 times 
the normal rate (i.e., the rate I see with barriers disabled) ;-)

ric

Re: [RFT] major libata update

[Jeff Garzik]

Ric Wheeler wrote:
> 
> One other note, it seems like this patch set has broken the write 
> barrier support - is that a side effect of enabling NCQ still?
> 
> I see messages that claim flush barriers are enabled:
> 
> [root@c001n01 root]# mount -o 
> barrier=flush,rw,noatime,nodiratime,data=ordered,notail /dev/sda10 /mnt/1
> May 16 22:21:56 centera kernel: ReiserFS: sda10: found reiserfs format 
> "3.6" with standard journal
> [root@c001n01 root]# May 16 22:21:58 centera kernel: ReiserFS: sda10: 
> using ordered data mode
> May 16 22:21:58 centera kernel: reiserfs: using flush barriers
> May 16 22:21:58 centera kernel: ReiserFS: sda10: journal params: device 
> sda10, size 8192, journal first block 18, max trans len 1024, max batch 
> 900, max commit age 30, max trans age 30
> May 16 22:21:58 centera kernel: ReiserFS: sda10: checking transaction 
> log (sda10)
> May 16 22:21:58 centera kernel: ReiserFS: sda10: Using r5 hash to sort 
> names
> 
> But when I test with my synchronous write load, I am going at 6 times 
> the normal rate (i.e., the rate I see with barriers disabled) ;-)

Well, NCQ read/write commands have a 'FUA' bit...  though maybe the NCQ 
code forgot to check the global libata_fua.

	Jeff

Re: [RFT] major libata update

[Eric D. Mudama]

On 5/16/06, Jeff Garzik <jeff@garzik.org> wrote:
> Ric Wheeler wrote:
> > But when I test with my synchronous write load, I am going at 6 times
> > the normal rate (i.e., the rate I see with barriers disabled) ;-)
>
> Well, NCQ read/write commands have a 'FUA' bit...  though maybe the NCQ
> code forgot to check the global libata_fua.
>
>         Jeff

Is the workload a sequential write?  SATA drives should be able to
keep up with the media if they use FUA for their consistency when
using NCQ.

Flush cache as a barrier mechanism will blow revs in sequential
workloads, especially using a write/flush write/flush technique.

Re: [RFT] major libata update

[Ric Wheeler]

Eric D. Mudama wrote:

> On 5/16/06, Jeff Garzik <jeff@garzik.org> wrote:
>
>> Ric Wheeler wrote:
>> > But when I test with my synchronous write load, I am going at 6 times
>> > the normal rate (i.e., the rate I see with barriers disabled) ;-)
>>
>> Well, NCQ read/write commands have a 'FUA' bit...  though maybe the NCQ
>> code forgot to check the global libata_fua.
>>
>>         Jeff
>
>
> Is the workload a sequential write?  SATA drives should be able to
> keep up with the media if they use FUA for their consistency when
> using NCQ.
>
> Flush cache as a barrier mechanism will blow revs in sequential
> workloads, especially using a write/flush write/flush technique.


That would be a huge win for us, but this instance I mounted with 
barrier=flush (and that is the logged message in messages).  I suspect 
that our boot with write cache disabled + flip of the write cache to on 
during boot is the culprit...

Once we get past the basic working/not working barriers, I will retest 
the FUA vs flush barriers and post some results ;-)

ric

Re: [RFT] major libata update

[Tejun Heo]

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

Jeff Garzik wrote:
> Ric Wheeler wrote:
>>
>> One other note, it seems like this patch set has broken the write 
>> barrier support - is that a side effect of enabling NCQ still?
>>
>> I see messages that claim flush barriers are enabled:
>>
>> [root@c001n01 root]# mount -o 
>> barrier=flush,rw,noatime,nodiratime,data=ordered,notail /dev/sda10 /mnt/1
>> May 16 22:21:56 centera kernel: ReiserFS: sda10: found reiserfs format 
>> "3.6" with standard journal
>> [root@c001n01 root]# May 16 22:21:58 centera kernel: ReiserFS: sda10: 
>> using ordered data mode
>> May 16 22:21:58 centera kernel: reiserfs: using flush barriers
>> May 16 22:21:58 centera kernel: ReiserFS: sda10: journal params: 
>> device sda10, size 8192, journal first block 18, max trans len 1024, 
>> max batch 900, max commit age 30, max trans age 30
>> May 16 22:21:58 centera kernel: ReiserFS: sda10: checking transaction 
>> log (sda10)
>> May 16 22:21:58 centera kernel: ReiserFS: sda10: Using r5 hash to sort 
>> names
>>
>> But when I test with my synchronous write load, I am going at 6 times 
>> the normal rate (i.e., the rate I see with barriers disabled) ;-)
> 
> Well, NCQ read/write commands have a 'FUA' bit...  though maybe the NCQ 
> code forgot to check the global libata_fua.
> 

Hmmm.. The only place FUA is checked is ata_dev_supports_fua() 
regardless of NCQ, but I've seen FUA enabled with NCQ in another bug 
report, so I might have screwed up.  Ric, can you post the boot dmesg 
such that we know whether FUA is enabled or not?

I'm attaching a patch to print the progress of ordered sequence.  I've 
just tested with a NCQ drive loaded with 20 IO requests and it works. 
All requests are drained, preflush, barrier, then postflush.  Running 
the same test with the attached patch will tell us how barrier is working.

@ I can't believe this.  Last night two disks failed - one testing, one 
production.  Man, my harddrives are falling like flies.  Four test 
drives and one production drive failed during last two months.  Maybe 
they are striking back at me.  :-(

-- 
tejun

[-- Attachment #2: ordered_debug.patch --]
[-- Type: text/x-patch, Size: 3643 bytes --]

diff --git a/block/elevator.c b/block/elevator.c
index 8768a36..5cbd2b3 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -40,6 +40,8 @@ #include <asm/uaccess.h>
 static DEFINE_SPINLOCK(elv_list_lock);
 static LIST_HEAD(elv_list);
 
+#define pd(fmt, args...) 	printk("[%-24s]: " fmt, __FUNCTION__ , ##args);
+
 /*
  * can we safely merge with this request?
  */
@@ -548,6 +550,11 @@ struct request *elv_next_request(request
 		}
 	}
 
+	if (rq && (rq == &q->pre_flush_rq || rq == &q->post_flush_rq ||
+		   rq == &q->bar_rq))
+		pd("%p (%s)\n", rq,
+		   rq == &q->pre_flush_rq ?
+			"pre" : (rq == &q->post_flush_rq ? "post" : "bar"));
 	return rq;
 }
 
diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index eac48be..eb1325c 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -30,6 +30,8 @@ #include <linux/interrupt.h>
 #include <linux/cpu.h>
 #include <linux/blktrace_api.h>
 
+#define pd(fmt, args...) 	printk("[%-24s]: " fmt, __FUNCTION__ , ##args);
+
 /*
  * for max sense size
  */
@@ -395,6 +397,9 @@ void blk_ordered_complete_seq(request_qu
 	struct request *rq;
 	int uptodate;
 
+	pd("ordseq=%02x seq=%02x orderr=%d error=%d\n",
+	   q->ordseq, seq, q->orderr, error);
+
 	if (error && !q->orderr)
 		q->orderr = error;
 
@@ -407,6 +412,7 @@ void blk_ordered_complete_seq(request_qu
 	/*
 	 * Okay, sequence complete.
 	 */
+	pd("sequence complete\n");
 	rq = q->orig_bar_rq;
 	uptodate = q->orderr ? q->orderr : 1;
 
@@ -461,6 +467,17 @@ static void queue_flush(request_queue_t 
 static inline struct request *start_ordered(request_queue_t *q,
 					    struct request *rq)
 {
+	struct bio *bio;
+	pd("%p -> %p,%p,%p infl=%u\n",
+	   rq, &q->pre_flush_rq, &q->bar_rq, &q->post_flush_rq, q->in_flight);
+	pd("%p %d %llu %lu %u %u %u %p\n", rq->bio, rq->errors,
+	   (unsigned long long)rq->hard_sector, rq->hard_nr_sectors,
+	   rq->current_nr_sectors, rq->nr_phys_segments, rq->nr_hw_segments,
+	   rq->buffer);
+	for (bio = rq->bio; bio; bio = bio->bi_next)
+		pd("BIO %p %llu %u\n",
+		   bio, (unsigned long long)bio->bi_sector, bio->bi_size);
+
 	q->bi_size = 0;
 	q->orderr = 0;
 	q->ordered = q->next_ordered;
@@ -499,6 +516,7 @@ static inline struct request *start_orde
 	} else
 		q->ordseq |= QUEUE_ORDSEQ_PREFLUSH;
 
+	pd("ordered=%x in_flight=%u\n", q->ordered, q->in_flight);
 	if ((q->ordered & QUEUE_ORDERED_TAG) || q->in_flight == 0)
 		q->ordseq |= QUEUE_ORDSEQ_DRAIN;
 	else
@@ -518,8 +536,10 @@ int blk_do_ordered(request_queue_t *q, s
 
 		if (q->next_ordered != QUEUE_ORDERED_NONE) {
 			*rqp = start_ordered(q, rq);
+			pd("start_ordered %p->%p\n", rq, *rqp);
 			return 1;
 		} else {
+			pd("ORDERED_NONE, seen barrier\n");
 			/*
 			 * This can happen when the queue switches to
 			 * ORDERED_NONE while this request is on it.
@@ -553,6 +573,7 @@ int blk_do_ordered(request_queue_t *q, s
 			*rqp = NULL;
 	}
 
+	pd("seq=%02x %p->%p\n", blk_ordered_cur_seq(q), rq, *rqp);
 	return 1;
 }
 
@@ -585,6 +606,9 @@ static int flush_dry_bio_endio(struct bi
 	bio->bi_sector -= (q->bi_size >> 9);
 	q->bi_size = 0;
 
+	pd("BIO %p %llu %u\n",
+	   bio, (unsigned long long)bio->bi_sector, bio->bi_size);
+
 	return 0;
 }
 
@@ -598,6 +622,7 @@ static inline int ordered_bio_endio(stru
 	if (&q->bar_rq != rq)
 		return 0;
 
+	pd("q->orderr=%d error=%d\n", q->orderr, error);
 	/*
 	 * Okay, this is the barrier request in progress, dry finish it.
 	 */
@@ -2864,6 +2889,7 @@ static int __make_request(request_queue_
 
 	barrier = bio_barrier(bio);
 	if (unlikely(barrier) && (q->next_ordered == QUEUE_ORDERED_NONE)) {
+		pd("ORDERED_NONE, seen barrier\n");
 		err = -EOPNOTSUPP;
 		goto end_io;
 	}

Re: [RFT] major libata update

[Ric Wheeler]

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


Tejun Heo wrote:

> Jeff Garzik wrote:
>
>> Ric Wheeler wrote:
>>
>>>
>>> One other note, it seems like this patch set has broken the write 
>>> barrier support - is that a side effect of enabling NCQ still?
>>>
>>> I see messages that claim flush barriers are enabled:
>>>
>>> [root@c001n01 root]# mount -o 
>>> barrier=flush,rw,noatime,nodiratime,data=ordered,notail /dev/sda10 
>>> /mnt/1
>>> May 16 22:21:56 centera kernel: ReiserFS: sda10: found reiserfs 
>>> format "3.6" with standard journal
>>> [root@c001n01 root]# May 16 22:21:58 centera kernel: ReiserFS: 
>>> sda10: using ordered data mode
>>> May 16 22:21:58 centera kernel: reiserfs: using flush barriers
>>> May 16 22:21:58 centera kernel: ReiserFS: sda10: journal params: 
>>> device sda10, size 8192, journal first block 18, max trans len 1024, 
>>> max batch 900, max commit age 30, max trans age 30
>>> May 16 22:21:58 centera kernel: ReiserFS: sda10: checking 
>>> transaction log (sda10)
>>> May 16 22:21:58 centera kernel: ReiserFS: sda10: Using r5 hash to 
>>> sort names
>>>
>>> But when I test with my synchronous write load, I am going at 6 
>>> times the normal rate (i.e., the rate I see with barriers disabled) ;-)
>>
>>
>> Well, NCQ read/write commands have a 'FUA' bit...  though maybe the 
>> NCQ code forgot to check the global libata_fua.
>>
>
> Hmmm.. The only place FUA is checked is ata_dev_supports_fua() 
> regardless of NCQ, but I've seen FUA enabled with NCQ in another bug 
> report, so I might have screwed up.  Ric, can you post the boot dmesg 
> such that we know whether FUA is enabled or not?
>
> I'm attaching a patch to print the progress of ordered sequence.  I've 
> just tested with a NCQ drive loaded with 20 IO requests and it works. 
> All requests are drained, preflush, barrier, then postflush.  Running 
> the same test with the attached patch will tell us how barrier is 
> working.
>
> @ I can't believe this.  Last night two disks failed - one testing, 
> one production.  Man, my harddrives are falling like flies.  Four test 
> drives and one production drive failed during last two months.  Maybe 
> they are striking back at me.  :-(
>
Attached is the boot.msg file - one important note is that we (EMC) have 
the unusual habit of using drives with write cache off & turning them on 
during boot up.  Could be that the answer is a simple enabling write 
cache does not properly toggle the barrier support (although I thought 
that we had patches from Jens ? that fixed this).

ric


[-- Attachment #2: boot.msg --]
[-- Type: text/plain, Size: 52682 bytes --]

Cannot find map file.
No module symbols loaded - kernel modules not enabled.

Cannot build symbol table - disabling symbol lookups
klogd 1.4.1, log source = ksyslog started.
00000, GSI 0-23
<6>ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
<6>ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
<7>ACPI: IRQ0 used by override.
<7>ACPI: IRQ2 used by override.
<7>ACPI: IRQ9 used by override.
<4>Enabling APIC mode:  Flat.  Using 1 I/O APICs
<6>Using ACPI (MADT) for SMP configuration information
<4>Allocating PCI resources starting at 40000000 (gap: 3f700000:a0900000)
<4>Built 1 zonelists
<5>Kernel command line: root=/dev/md3 elevator=as console=ttyS0,9600,8n1 console=tty0 apic BOOT_IMAGE=production-m
<7>mapped APIC to ffffd000 (fee00000)
<7>mapped IOAPIC to ffffc000 (fec00000)
<6>Enabling fast FPU save and restore... done.
<6>Enabling unmasked SIMD FPU exception support... done.
<6>Initializing CPU#0
<4>PID hash table entries: 4096 (order: 12, 16384 bytes)
<4>Detected 2800.792 MHz processor.
<6>Using pmtmr for high-res timesource
<4>Console: colour VGA+ 80x25
<4>Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
<4>Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
<6>Memory: 898240k/917504k available (2014k kernel code, 18720k reserved, 632k data, 184k init, 0k highmem)
<4>Checking if this processor honours the WP bit even in supervisor mode... Ok.
<4>Calibrating delay using timer specific routine.. 5607.13 BogoMIPS (lpj=11214265)
<4>Mount-cache hash table entries: 512
<7>CPU: After generic identify, caps: bfebfbff 00100000 00000000 00000000 0000441d 00000000 00000000
<7>CPU: After vendor identify, caps: bfebfbff 00100000 00000000 00000000 0000441d 00000000 00000000
<4>monitor/mwait feature present.
<4>using mwait in idle threads.
<6>CPU: Trace cache: 12K uops, L1 D cache: 16K
<6>CPU: L2 cache: 1024K
<7>CPU: After all inits, caps: bfebfbff 00100000 00000000 00000180 0000441d 00000000 00000000
<4>CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 01
<6>Checking 'hlt' instruction... OK.
<6>SMP alternatives: switching to UP code
<6>Freeing SMP alternatives: 0k freed
<4>ENABLING IO-APIC IRQs
<6>..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
<6>checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
<6>Freeing initrd memory: 7738k freed
<6>NET: Registered protocol family 16
<6>ACPI: bus type pci registered
<6>PCI: Using MMCONFIG
<4>Setting up standard PCI resources
<6>ACPI: Subsystem revision 20060127
<6>ACPI: Interpreter enabled
<6>ACPI: Using IOAPIC for interrupt routing
<6>ACPI: PCI Root Bridge [PCI0] (0000:00)
<7>PCI: Probing PCI hardware (bus 00)
<7>Boot video device is 0000:00:02.0
<4>PCI: PXH quirk detected, disabling MSI for SHPC device
<4>PCI: PXH quirk detected, disabling MSI for SHPC device
<6>PCI: Transparent bridge - 0000:00:1e.0
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P1AB.PXHA._PRT]
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P1AB.PXHB._PRT]
<4>ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 10 *12 14 15)
<4>ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 7 9 10 12 14 15)
<4>ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 *7 9 10 12 14 15)
<4>ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 *10 12 14 15)
<4>ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 10 12 14 15) *0, disabled.
<4>ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 10 12 14 15) *0, disabled.
<4>ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 7 9 10 12 14 15) *0, disabled.
<4>ACPI: PCI Interrupt Link [LNK1] (IRQs *3 4 5 7 9 10 12 14 15)
<5>SCSI subsystem initialized
<6>PCI: Using ACPI for IRQ routing
<6>PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
<4>PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
<6>PCI: Bridge: 0000:01:00.0
<6>  IO window: c000-cfff
<6>  MEM window: d0000000-d00fffff
<6>  PREFETCH window: disabled.
<6>PCI: Bridge: 0000:01:00.2
<6>  IO window: d000-dfff
<6>  MEM window: d0100000-d01fffff
<6>  PREFETCH window: disabled.
<6>PCI: Bridge: 0000:00:01.0
<6>  IO window: c000-dfff
<6>  MEM window: d0000000-d02fffff
<6>  PREFETCH window: disabled.
<6>PCI: Bridge: 0000:00:1e.0
<6>  IO window: disabled.
<6>  MEM window: disabled.
<6>  PREFETCH window: disabled.
<6>ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
<7>PCI: Setting latency timer of device 0000:00:01.0 to 64
<7>PCI: Setting latency timer of device 0000:01:00.0 to 64
<7>PCI: Setting latency timer of device 0000:01:00.2 to 64
<7>PCI: Setting latency timer of device 0000:00:1e.0 to 64
<6>NET: Registered protocol family 2
<4>IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
<4>TCP established hash table entries: 131072 (order: 7, 524288 bytes)
<4>TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
<6>TCP: Hash tables configured (established 131072 bind 65536)
<6>TCP reno registered
<6>IA-32 Microcode Update Driver: v1.14 <tigran@veritas.com>
<6>io scheduler noop registered
<6>io scheduler anticipatory registered (default)
<6>io scheduler deadline registered
<6>io scheduler cfq registered
<6>Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
<6>serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
<4>RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
<6>Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
<6>ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
<7>Probing IDE interface ide0...
<7>Probing IDE interface ide1...
<7>libata version 1.30 loaded.
<7>ahci 0000:00:1f.2: version 1.3
<6>ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 17
<7>PCI: Setting latency timer of device 0000:00:1f.2 to 64
<6>ahci 0000:00:1f.2: AHCI 0001.0000 32 slots 4 ports 1.5 Gbps 0xf impl IDE mode
<6>ahci 0000:00:1f.2: flags: 64bit ncq pm led 
<6>ata1: SATA max UDMA/133 cmd 0xF8802100 ctl 0x0 bmdma 0x0 irq 17
<6>ata2: SATA max UDMA/133 cmd 0xF8802180 ctl 0x0 bmdma 0x0 irq 17
<6>ata3: SATA max UDMA/133 cmd 0xF8802200 ctl 0x0 bmdma 0x0 irq 17
<6>ata4: SATA max UDMA/133 cmd 0xF8802280 ctl 0x0 bmdma 0x0 irq 17
<6>ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
<7>ata1.00: cfg 49:2f00 82:7c6b 83:7f09 84:4063 85:7c49 86:3e01 87:4063 88:007f
<6>ata1.00: ATA-7, max UDMA/133, 625142448 sectors: LBA48 NCQ (depth 31/32)
<6>ata1.00: configured for UDMA/133
<6>scsi0 : ahci
<6>ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
<7>ata2.00: cfg 49:2f00 82:7c6b 83:7f09 84:4063 85:7c49 86:3e01 87:4063 88:007f
<6>ata2.00: ATA-7, max UDMA/133, 625142448 sectors: LBA48 NCQ (depth 31/32)
<6>ata2.00: configured for UDMA/133
<6>scsi1 : ahci
<6>ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
<7>ata3.00: cfg 49:2f00 82:7c6b 83:7f09 84:4063 85:7c49 86:3e01 87:4063 88:007f
<6>ata3.00: ATA-7, max UDMA/133, 625142448 sectors: LBA48 NCQ (depth 31/32)
<6>ata3.00: configured for UDMA/133
<6>scsi2 : ahci
<6>ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
<7>ata4.00: cfg 49:2f00 82:7c6b 83:7f09 84:4063 85:7c49 86:3e01 87:4063 88:007f
<6>ata4.00: ATA-7, max UDMA/133, 625142448 sectors: LBA48 NCQ (depth 31/32)
<6>ata4.00: configured for UDMA/133
<6>scsi3 : ahci
<5>  Vendor: ATA       Model: Maxtor 7B320S0    Rev: BANC
<5>  Type:   Direct-Access                      ANSI SCSI revision: 05
<5>  Vendor: ATA       Model: Maxtor 7B320S0    Rev: BANC
<5>  Type:   Direct-Access                      ANSI SCSI revision: 05
<5>  Vendor: ATA       Model: Maxtor 7B320S0    Rev: BANC
<5>  Type:   Direct-Access                      ANSI SCSI revision: 05
<5>  Vendor: ATA       Model: Maxtor 7B320S0    Rev: BANC
<5>  Type:   Direct-Access                      ANSI SCSI revision: 05
<5>SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
<5>sda: Write Protect is off
<7>sda: Mode Sense: 00 3a 00 00
<5>SCSI device sda: drive cache: write through
<5>SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
<5>sda: Write Protect is off
<7>sda: Mode Sense: 00 3a 00 00
<5>SCSI device sda: drive cache: write through
<6> sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 sda13 sda14 >
<5>sd 0:0:0:0: Attached scsi disk sda
<5>SCSI device sdb: 625142448 512-byte hdwr sectors (320073 MB)
<5>sdb: Write Protect is off
<7>sdb: Mode Sense: 00 3a 00 00
<5>SCSI device sdb: drive cache: write through
<5>SCSI device sdb: 625142448 512-byte hdwr sectors (320073 MB)
<5>sdb: Write Protect is off
<7>sdb: Mode Sense: 00 3a 00 00
<5>SCSI device sdb: drive cache: write through
<6> sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12 sdb13 sdb14 >
<5>sd 1:0:0:0: Attached scsi disk sdb
<5>SCSI device sdc: 625142448 512-byte hdwr sectors (320073 MB)
<5>sdc: Write Protect is off
<7>sdc: Mode Sense: 00 3a 00 00
<5>SCSI device sdc: drive cache: write through
<5>SCSI device sdc: 625142448 512-byte hdwr sectors (320073 MB)
<5>sdc: Write Protect is off
<7>sdc: Mode Sense: 00 3a 00 00
<5>SCSI device sdc: drive cache: write through
<6> sdc: sdc1 sdc2 sdc3 sdc4 < sdc5 sdc6 sdc7 sdc8 sdc9 sdc10 sdc11 sdc12 sdc13 sdc14 >
<5>sd 2:0:0:0: Attached scsi disk sdc
<5>SCSI device sdd: 625142448 512-byte hdwr sectors (320073 MB)
<5>sdd: Write Protect is off
<7>sdd: Mode Sense: 00 3a 00 00
<5>SCSI device sdd: drive cache: write through
<5>SCSI device sdd: 625142448 512-byte hdwr sectors (320073 MB)
<5>sdd: Write Protect is off
<7>sdd: Mode Sense: 00 3a 00 00
<5>SCSI device sdd: drive cache: write through
<6> sdd: sdd1 sdd2 sdd3 sdd4 < sdd5 sdd6 sdd7 sdd8 sdd9 sdd10 sdd11 sdd12 sdd13 sdd14 >
<5>sd 3:0:0:0: Attached scsi disk sdd
<6>serio: i8042 AUX port at 0x60,0x64 irq 12
<6>serio: i8042 KBD port at 0x60,0x64 irq 1
<6>mice: PS/2 mouse device common for all mice
<6>i2c /dev entries driver
<6>md: raid1 personality registered for level 1
<6>md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
<6>md: bitmap version 4.39
<6>TCP bic registered
<6>NET: Registered protocol family 1
<4>Using IPI Shortcut mode
<4>ACPI wakeup devices: 
<4>PCI0 PEX0 PEX1 PEX2 PEX3 HUB0 PXHA PXHB UAR1 USB0 USB1 USB2 USB3 USBE AC97 AZAL 
<6>ACPI: (supports S0 S1 S4 S5)
<6>md: Autodetecting RAID arrays.
<6>md: autorun ...
<6>md: considering sdd8 ...
<6>md:  adding sdd8 ...
<4>md: sdd7 has different UUID to sdd8
<4>md: sdd6 has different UUID to sdd8
<4>md: sdd5 has different UUID to sdd8
<4>md: sdd3 has different UUID to sdd8
<6>md:  adding sdc8 ...
<4>md: sdc7 has different UUID to sdd8
<4>md: sdc6 has different UUID to sdd8
<4>md: sdc5 has different UUID to sdd8
<4>md: sdc3 has different UUID to sdd8
<6>md:  adding sdb8 ...
<4>md: sdb7 has different UUID to sdd8
<4>md: sdb6 has different UUID to sdd8
<4>md: sdb5 has different UUID to sdd8
<4>md: sdb3 has different UUID to sdd8
<6>md:  adding sda8 ...
<4>md: sda7 has different UUID to sdd8
<4>md: sda6 has different UUID to sdd8
<4>md: sda5 has different UUID to sdd8
<4>md: sda3 has different UUID to sdd8
<6>md: created md8
<6>md: bind<sda8>
<6>md: bind<sdb8>
<6>md: bind<sdc8>
<6>md: bind<sdd8>
<6>md: running: <sdd8><sdc8><sdb8><sda8>
<6>raid1: raid set md8 active with 4 out of 4 mirrors
<6>md: considering sdd7 ...
<6>md:  adding sdd7 ...
<4>md: sdd6 has different UUID to sdd7
<4>md: sdd5 has different UUID to sdd7
<4>md: sdd3 has different UUID to sdd7
<6>md:  adding sdc7 ...
<4>md: sdc6 has different UUID to sdd7
<4>md: sdc5 has different UUID to sdd7
<4>md: sdc3 has different UUID to sdd7
<6>md:  adding sdb7 ...
<4>md: sdb6 has different UUID to sdd7
<4>md: sdb5 has different UUID to sdd7
<4>md: sdb3 has different UUID to sdd7
<6>md:  adding sda7 ...
<4>md: sda6 has different UUID to sdd7
<4>md: sda5 has different UUID to sdd7
<4>md: sda3 has different UUID to sdd7
<6>md: created md7
<6>md: bind<sda7>
<6>md: bind<sdb7>
<6>md: bind<sdc7>
<6>md: bind<sdd7>
<6>md: running: <sdd7><sdc7><sdb7><sda7>
<6>raid1: raid set md7 active with 4 out of 4 mirrors
<6>md: considering sdd6 ...
<6>md:  adding sdd6 ...
<4>md: sdd5 has different UUID to sdd6
<4>md: sdd3 has different UUID to sdd6
<6>md:  adding sdc6 ...
<4>md: sdc5 has different UUID to sdd6
<4>md: sdc3 has different UUID to sdd6
<6>md:  adding sdb6 ...
<4>md: sdb5 has different UUID to sdd6
<4>md: sdb3 has different UUID to sdd6
<6>md:  adding sda6 ...
<4>md: sda5 has different UUID to sdd6
<4>md: sda3 has different UUID to sdd6
<6>md: created md6
<6>md: bind<sda6>
<6>md: bind<sdb6>
<6>md: bind<sdc6>
<6>md: bind<sdd6>
<6>md: running: <sdd6><sdc6><sdb6><sda6>
<6>raid1: raid set md6 active with 4 out of 4 mirrors
<6>md: considering sdd5 ...
<6>md:  adding sdd5 ...
<4>md: sdd3 has different UUID to sdd5
<6>md:  adding sdc5 ...
<4>md: sdc3 has different UUID to sdd5
<6>md:  adding sdb5 ...
<4>md: sdb3 has different UUID to sdd5
<6>md:  adding sda5 ...
<4>md: sda3 has different UUID to sdd5
<6>md: created md5
<6>md: bind<sda5>
<6>md: bind<sdb5>
<6>md: bind<sdc5>
<6>md: bind<sdd5>
<6>md: running: <sdd5><sdc5><sdb5><sda5>
<6>raid1: raid set md5 active with 4 out of 4 mirrors
<6>md: considering sdd3 ...
<6>md:  adding sdd3 ...
<6>md:  adding sdc3 ...
<6>md:  adding sdb3 ...
<6>md:  adding sda3 ...
<6>md: created md3
<6>md: bind<sda3>
<6>md: bind<sdb3>
<6>md: bind<sdc3>
<6>md: bind<sdd3>
<6>md: running: <sdd3><sdc3><sdb3><sda3>
<6>raid1: raid set md3 active with 4 out of 4 mirrors
<6>md: ... autorun DONE.
<5>RAMDISK: Compressed image found at block 0
<4>VFS: Mounted root (ext2 filesystem).
<6>ipmi message handler version 39.0
<6>IPMI System Interface driver.
<6>ipmi: Found new BMC (man_id: 0x0019fd,  prod_id: 0x1426, dev_id: 0x00)
<4> IPMI KCS interface initialized
<6>ipmi_si: Found default KCS state machine at I/O address 0xca2
<6>ipmi device interface
<6>e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
<6>e100: Copyright(c) 1999-2005 Intel Corporation
<6>Intel(R) PRO/1000 Network Driver - version 7.0.33-k2
<6>Copyright (c) 1999-2005 Intel Corporation.
<6>ACPI: PCI Interrupt 0000:02:06.0[A] -> GSI 19 (level, low) -> IRQ 17
<6>e1000: 0000:02:06.0: e1000_probe: (PCI-X:133MHz:64-bit) 00:e0:81:64:5f:de
<6>e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
<6>ACPI: PCI Interrupt 0000:02:06.1[B] -> GSI 18 (level, low) -> IRQ 18
<6>e1000: 0000:02:06.1: e1000_probe: (PCI-X:133MHz:64-bit) 00:e0:81:64:5f:df
<6>e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
<6>ACPI: PCI Interrupt 0000:03:07.0[A] -> GSI 17 (level, low) -> IRQ 19
<6>e1000: 0000:03:07.0: e1000_probe: (PCI-X:133MHz:64-bit) 00:e0:81:64:5f:e0
<6>e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
<6>ACPI: PCI Interrupt 0000:03:07.1[B] -> GSI 16 (level, low) -> IRQ 16
<6>e1000: 0000:03:07.1: e1000_probe: (PCI-X:133MHz:64-bit) 00:e0:81:64:5f:e1
<6>e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection
<5>ReiserFS: md8: found reiserfs format "3.6" with standard journal
<5>ReiserFS: md8: using ordered data mode
<5>ReiserFS: md8: journal params: device md8, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
<5>ReiserFS: md8: checking transaction log (md8)
<5>ReiserFS: md8: Using r5 hash to sort names
<5>ReiserFS: md3: found reiserfs format "3.6" with standard journal
<5>ReiserFS: md3: using ordered data mode
<5>ReiserFS: md3: journal params: device md3, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
<5>ReiserFS: md3: checking transaction log (md3)
<5>ReiserFS: md3: Using r5 hash to sort names
<4>VFS: Mounted root (reiserfs filesystem) readonly.
<5>Trying to move old root to /initrd ... /initrd does not exist. Ignored.
<5>Unmounting old root
<5>Trying to free ramdisk memory ... okay
<6>Freeing unused kernel memory: 184k freed
<6>md: Autodetecting RAID arrays.
<6>md: autorun ...
<6>md: ... autorun DONE.
<5>ReiserFS: md7: found reiserfs format "3.6" with standard journal
<5>ReiserFS: md7: using ordered data mode
<5>ReiserFS: md7: journal params: device md7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
<5>ReiserFS: md7: checking transaction log (md7)
<5>ReiserFS: md7: Using r5 hash to sort names
<5>ReiserFS: md8: found reiserfs format "3.6" with standard journal
<5>ReiserFS: md8: using ordered data mode
<5>ReiserFS: md8: journal params: device md8, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
<5>ReiserFS: md8: checking transaction log (md8)
<5>ReiserFS: md8: Using r5 hash to sort names
Kernel logging (ksyslog) stopped.
Kernel log daemon terminating.

Boot logging started on /dev/tty1(/dev/console) at Tue May 16 16:28:51 2006

Master Resource Control: previous runlevel: N, switching to runlevel: 3
<notice>start services (starting_services random iterator firewall)
Logging the start of the bootdone
Initializing random number generatordone
<notice>startproc: execve (/usr/bin/IterServ) [ /usr/bin/IterServ ], [ CONSOLE=/dev/console TERM=linux SHELL=/bin/sh progress=20 INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/tty1 COLUMNS=80 PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin RUNLEVEL=3 PWD=/ PREVLEVEL=N LINES=25 HOME=/ SHLVL=2 BOOT_IMAGE=production-m sscripts=38 _=/sbin/startproc DAEMON=/usr/bin/IterServ ]
Starting iterator daemondone
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
<notice>exit status of (starting_services random iterator firewall) is (0 0 0 0)
<notice>start services (network)
Setting up network interfaces:
    lo       
    lo        IP address: 127.0.0.1/8   
done    eth0      device: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
    eth0      Startmode is 'manual'
skipped    eth1      device: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
    eth1      Startmode is 'manual'
skipped    eth2      device: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
    eth2      IP address: 10.241.28.82/29   
Shutting down external SSH daemondone
Starting external SSH daemon<notice>startproc: execve (/usr/sbin/sshd_external) [ /usr/sbin/sshd_external -f /etc/ssh/sshd_config_external -o PidFile=/var/run/sshd_external.init.pid ], [ HWD_INTERFACE_0=eth2 CONSOLE=/dev/console HWD_HWDESC=eth2 TERM=linux SHELL=/bin/sh HWD_BUSID_0=0000:00:01.0 HWD_BUSNAME_2=pci HWD_BUSID_1=0000:01:00.0 HWD_BUSNAME_0=pci HWD_BUSID_2=0000:02:06.0 HWD_BUSNAME_1=pci HWD_VENDORID=0x8086 HWD_BUSID=0000:02:06.0 HWD_PRODUCTSUBID=0x1179 progress=24 HWD_CONFIG_N=1 INIT_VERSION=sysvinit-2.85 RUN_FROM_RC=yes REDIRECT=/dev/tty1 HWD_INTERFACEPATH=/sys/class/net/eth2 COLUMNS=80 HWD_DEVTYPE=eth HWD_ID=00:e0:81:64:5f:de HWD_BUSNAME=pci PATH=/sbin:/usr/sbin:/bin:/usr/bin:/etc/sysconfig/network/scripts RUNLEVEL=3 PWD=/etc/sysconfig/network PREVLEVEL=N LINES=25 HWD_HWDESCTYPE=interface HOME=/ SHLVL=6 BOOT_IMAGE=production-m HWD_CONFIG_0=eth2 HWD_BUS_N=3 sscripts=38 HWD_VENDORSUBID=0x8086 HWD_PRODUCTID=0x1079 HWD_INTERFACE_N=1 HWD_DEVICEPATH=/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:06.0 _=/sbin/startproc DAEMON=/usr/sbin/sshd_external ]
done
Shutting down external SSH daemon<notice>killproc: kill(5452,15)
done
Starting external SSH daemon<notice>startproc: execve (/usr/sbin/sshd_external) [ /usr/sbin/sshd_external -f /etc/ssh/sshd_config_external -o PidFile=/var/run/sshd_external.init.pid ], [ HWD_INTERFACE_0=eth2 CONSOLE=/dev/console HWD_HWDESC=eth2 TERM=linux SHELL=/bin/sh HWD_BUSID_0=0000:00:01.0 HWD_BUSNAME_2=pci HWD_BUSID_1=0000:01:00.0 HWD_BUSNAME_0=pci HWD_BUSID_2=0000:02:06.0 HWD_BUSNAME_1=pci HWD_VENDORID=0x8086 HWD_BUSID=0000:02:06.0 HWD_PRODUCTSUBID=0x1179 progress=24 HWD_CONFIG_N=1 INIT_VERSION=sysvinit-2.85 RUN_FROM_RC=yes REDIRECT=/dev/tty1 HWD_INTERFACEPATH=/sys/class/net/eth2 COLUMNS=80 HWD_DEVTYPE=eth HWD_ID=00:e0:81:64:5f:de HWD_BUSNAME=pci PATH=/sbin:/usr/sbin:/bin:/usr/bin:/etc/sysconfig/network/scripts RUNLEVEL=3 PWD=/etc/sysconfig/network PREVLEVEL=N LINES=25 HWD_HWDESCTYPE=interface HOME=/ SHLVL=6 BOOT_IMAGE=production-m HWD_CONFIG_0=eth2 HWD_BUS_N=3 sscripts=38 HWD_VENDORSUBID=0x8086 HWD_PRODUCTID=0x1079 HWD_INTERFACE_N=1 HWD_DEVICEPATH=/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:06.0 _=/sbin/startproc DAEMON=/usr/sbin/sshd_external ]
done
WARNING: pinging broadcast address
PING 10.241.28.87 (10.241.28.87) from 10.241.28.82 eth2: 56(84) bytes of data.

--- 10.241.28.87 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

grep: /etc/resolv.conf: No such file or directory
unix dgram connect: No such file or directory at /usr/lib/perl5/site_perl/5.8.3/Log/Agent/Channel/Syslog.pm line 119
no connection to syslog available at /usr/lib/perl5/site_perl/5.8.3/Log/Agent/Channel/Syslog.pm line 119
done    eth3      device: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
    eth3      No configuration found for eth3
unusedSetting up service network  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .done
<notice>exit status of (network) is (0)
<notice>start services (syslog)
Starting syslog services<notice>startproc: execve (/sbin/syslogd) [ /sbin/syslogd -a /var/lib/dhcp/dev/log ], [ CONSOLE=/dev/console TERM=linux SHELL=/bin/sh progress=25 INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/tty1 COLUMNS=80 PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin RUNLEVEL=3 PWD=/ PREVLEVEL=N LINES=25 HOME=/ SHLVL=2 BOOT_IMAGE=production-m sscripts=38 _=/sbin/startproc DAEMON=/sbin/syslogd ]
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@  syslogd: Can't bind unix unix socket to name: Address already in use

<notice>startproc: execve (/sbin/klogd) [ /sbin/klogd -c 1 -2 -x ], [ CONSOLE=/dev/console TERM=linux SHELL=/bin/sh progress=25 INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/tty1 COLUMNS=80 PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin RUNLEVEL=3 PWD=/ PREVLEVEL=N LINES=25 HOME=/ SHLVL=2 BOOT_IMAGE=production-m sscripts=38 _=/sbin/startproc DAEMON=/sbin/klogd ]
done
<notice>exit status of (syslog) is (0)
<notice>start services (smartd)
Generating /etc/smartd.conf: Disabling SMART on this node.
done<notice>exit status of (smartd) is (0)
<notice>start services (xinetd microcode_ctl microcode)
<notice>startproc: execve (/usr/sbin/xinetd) [ /usr/sbin/xinetd ], [ CONSOLE=/dev/console TERM=linux SHELL=/bin/sh progress=27 INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/tty1 COLUMNS=80 PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin RUNLEVEL=3 PWD=/ PREVLEVEL=N LINES=25 HOME=/ SHLVL=2 BOOT_IMAGE=production-m sscripts=38 _=/sbin/startproc DAEMON=/usr/sbin/xinetd ]
Checking/updating CPU microcodedone
Applying Intel IA32 Microcode update... 
done

Starting INET services. (xinetd)done
<notice>exit status of (xinetd microcode_ctl microcode) is (0 0 0)
<notice>start services (clusternet)
Starting cluster networking backgrounding
<notice>exit status of (clusternet) is (0)
<notice>start services (clusternetwait)
Waiting for clusternet IP detection to finish: waiting 1swaiting 2swaiting 3swaiting 4swaiting 5swaiting 6swaiting 7swaiting 8swaiting 9swaiting 10swaiting 11swaiting 12swaiting 13swaiting 14swaiting 15swaiting 16swaiting 17swaiting 18swaiting 19swaiting 20swaiting 21swaiting 22swaiting 23swaiting 24swaiting 25swaiting 26swaiting 27swaiting 28swaiting 29swaiting 30swaiting 31swaiting 32swaiting 33s<notice>startproc: execve (/usr/sbin/sshd) [ /usr/sbin/sshd -o PidFile=/var/run/sshd.init.pid ], [ CONSOLE=/dev/console TERM=linux SHELL=/bin/sh progress=30 INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/tty1 COLUMNS=80 PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin RUNLEVEL=3 PWD=/ PREVLEVEL=N LINES=25 HOME=/ SHLVL=4 BOOT_IMAGE=production-m sscripts=38 _=/sbin/startproc DAEMON=/usr/sbin/sshd ]
<notice>startproc: execve (/usr/sbin/ntpd) [ /usr/sbin/ntpd -p /var/lib/ntp/var/run/ntp/ntpd.pid -U ntp ], [ CONSOLE=/dev/console TERM=linux SHELL=/bin/sh progress=30 INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/tty1 COLUMNS=80 PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin RUNLEVEL=3 PWD=/ PREVLEVEL=N LINES=25 HOME=/ SHLVL=4 BOOT_IMAGE=production-m sscripts=38 OLDPWD=/var/local/bootstat _=/sbin/startproc DAEMON=/usr/sbin/ntpd ]
<notice>checkproc: /usr/sbin/ntpd 5859
waiting 34swaiting 35swaiting 36swaiting 37swaiting 38swaiting 39swaiting 40swaiting 41swaiting 42swaiting 43swaiting 44swaiting 45swaiting 46swaiting 47swaiting 48swaiting 49swaiting 50swaiting 51swaiting 52swaiting 53swaiting 54swaiting 55swaiting 56swaiting 57swaiting 58swaiting 59swaiting 60swaiting 61swaiting 62s<notice>killproc: kill(5813,15)
waiting 63s<notice>startproc: execve (/usr/sbin/sshd) [ /usr/sbin/sshd -o PidFile=/var/run/sshd.init.pid ], [ CONSOLE=/dev/console TERM=linux SHELL=/bin/sh progress=30 INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/tty1 COLUMNS=80 PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin RUNLEVEL=3 PWD=/ PREVLEVEL=N LINES=25 HOME=/ SHLVL=4 BOOT_IMAGE=production-m sscripts=38 _=/sbin/startproc DAEMON=/usr/sbin/sshd ]
Started cluster networking done
waiting 64s                               done
Change hostname to c001n01 done
<notice>exit status of (clusternetwait) is (0)
<notice>start services (connectemc)
Starting ConnectEMC <notice>startproc: execve (/opt/connectemc/connectemc) [ /opt/connectemc/connectemc ], [ CONSOLE=/dev/console TERM=linux SHELL=/bin/sh progress=32 INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/tty1 COLUMNS=80 PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin RUNLEVEL=3 PWD=/ PREVLEVEL=N LINES=25 HOME=/ SHLVL=2 BOOT_IMAGE=production-m sscripts=38 _=/sbin/startproc DAEMON=/opt/connectemc/connectemc ]
done
<notice>exit status of (connectemc) is (0)
<notice>start services (cron blobpartitions)
<notice>startproc: execve (/usr/sbin/cron) [ /usr/sbin/cron ], [ CONSOLE=/dev/console TERM=linux SHELL=/bin/sh progress=33 INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/tty1 COLUMNS=80 PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin RUNLEVEL=3 PWD=/ PREVLEVEL=N LINES=25 HOME=/ SHLVL=2 BOOT_IMAGE=production-m sscripts=38 _=/sbin/startproc DAEMON=/usr/sbin/cron ]
Starting CRON daemondone
Start activating blob partition /dev/cstardn10
Start activating blob partition /dev/cstardo10
Start activating blob partition /dev/cstardp10
Start activating blob partition /dev/cstardm10
Finish mounting blob partition /dev/cstardp10:done
Finish mounting blob partition /dev/cstardm10:done
Start activating blob partition /dev/cstardm11
Finish mounting blob partition /dev/cstardn10:done
Start activating blob partition /dev/cstardn11
Finish mounting blob partition /dev/cstardo10:done
Start activating blob partition /dev/cstardo11
Start activating blob partition /dev/cstardp11
Finish mounting blob partition /dev/cstardm11:done
Start activating blob partition /dev/cstardm12
Finish mounting blob partition /dev/cstardo11:done
Start activating blob partition /dev/cstardo12
Finish mounting blob partition /dev/cstardn11:done
Start activating blob partition /dev/cstardn12
Finish mounting blob partition /dev/cstardp11:done
Finish mounting blob partition /dev/cstardm12:done
Finish mounting blob partition /dev/cstardo12:done
Start activating blob partition /dev/cstardo13
Finish mounting blob partition /dev/cstardn12:done
Start activating blob partition /dev/cstardn13
Start activating blob partition /dev/cstardp12
Start activating blob partition /dev/cstardm13
Finish mounting blob partition /dev/cstardn13:done
Start activating blob partition /dev/cstardn14
Finish mounting blob partition /dev/cstardp12:done
Start activating blob partition /dev/cstardp13
Finish mounting blob partition /dev/cstardm13:done
Start activating blob partition /dev/cstardm14
Finish mounting blob partition /dev/cstardo13:done
Start activating blob partition /dev/cstardo14
Finish mounting blob partition /dev/cstardp13:done
Start activating blob partition /dev/cstardp14
Finish mounting blob partition /dev/cstardm14:done
Finish mounting blob partition /dev/cstardn14:done
Finish mounting blob partition /dev/cstardo14:done
Finish mounting blob partition /dev/cstardp14:done
<notice>exit status of (cron blobpartitions) is (0 0)
<notice>start services (inventory fragmentcounter)
Removing old imagesStarting fragment counter: done
<notice>exit status of (inventory fragmentcounter) is (0 0)
<notice>start services (filepool)
Starting FilePool software FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
done
<notice>exit status of (filepool) is (0)
<notice>start services (successful_boot)
Setting GRUB for a production boot on disks:
    /dev/cstardm;/dev/cstardn;/dev/cstardo;/dev/cstardpdone
<notice>exit status of (successful_boot) is (0)
Master Resource Control: runlevel 3 has been reached
<notice>killproc: kill(4858,3)

Re: [RFT] major libata update

[Tejun Heo]

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

Ric Wheeler wrote:
> c001n01: 0: [  OK  ]
> ata3: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
> 0x2000000f)
> ata3: spurious SDB FIS 004040a1:10000000 ap->qc_active=2000000f 
> qc_active=2000000f
> ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
> 0xfffc0)
> ata1: spurious SDB FIS 004040a1:00000020 ap->qc_active=000fffc0 
> qc_active=000fffc0
> ata2: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
> 0x7fffff3f)
> ata2: spurious SDB FIS 004040a1:00000080 ap->qc_active=7fffff3f 
> qc_active=7fffff3f
> ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
> 0x7fffff9f)
> ata1: spurious SDB FIS 004040a1:00000040 ap->qc_active=7fffff9f 
> qc_active=7fffff9f
> c001n03: 0: [  OK  ]
> ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
> 0x7ffe7fff)
> ata1: spurious SDB FIS 004040a1:00010000 ap->qc_active=7ffe7fff 
> qc_active=7ffe7fff
> c001n04: 0: [  OK  ]
> ata3: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x31)
> ata3: spurious SDB FIS 004040a1:00000008 ap->qc_active=00000031 
> qc_active=00000031
> ata3: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
> 0x7fff800f)
> ata3: spurious SDB FIS 004040a1:00004000 ap->qc_active=7fff800f 
> qc_active=7fff800f
> c001n06: 1: [ FAIL ]
> c001n07: 0: [  OK  ]
> ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
> 0x7ffffcff)
> ata1: spurious SDB FIS 004040a1:00000200 ap->qc_active=7ffffcff 
> qc_active=7ffffcff
> c001n08: 0: [  OK  ]
> ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
> 0x4fffffff)
> ata1: spurious SDB FIS 004040a1:20000000 ap->qc_active=4fffffff 
> qc_active=4fffffff

Hmmm.. The drive is issuing SDB FIS which completes already completed 
tags.  This could be dangerous.  Depending on timing, it might end up 
finishing a command which occupied the slot which hasn't been processed 
yet.  If a drive does this, NCQ shouldn't be enabled for it.  Can you 
post full boot dmesg?

I'm attaching slightly modified version of the debug patch just in case. 
  It will probably show the same thing.

-- 
tejun

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 1042 bytes --]

diff --git a/drivers/scsi/ahci.c b/drivers/scsi/ahci.c
index 45fd71d..f9eeb15 100644
--- a/drivers/scsi/ahci.c
+++ b/drivers/scsi/ahci.c
@@ -876,6 +876,7 @@ static void ahci_host_intr(struct ata_po
 	struct ata_eh_info *ehi = &ap->eh_info;
 	u32 status, qc_active;
 	int rc;
+	u32 orig_qc_active = ap->qc_active;
 
 	status = readl(port_mmio + PORT_IRQ_STAT);
 	writel(status, port_mmio + PORT_IRQ_STAT);
@@ -916,10 +917,19 @@ static void ahci_host_intr(struct ata_po
 			return;
 	}
 
-	if (ata_ratelimit())
+	if (ata_ratelimit()) {
 		ata_port_printk(ap, KERN_INFO, "spurious interrupt "
 				"(irq_stat 0x%x active_tag %d sactive 0x%x)\n",
 				status, ap->active_tag, ap->sactive);
+		if (status & PORT_IRQ_SDB_FIS) {
+			struct ahci_port_priv *pp = ap->private_data;
+			u32 *sdb_fis = pp->rx_fis + 0x58;
+
+			ata_port_printk(ap, KERN_INFO, "spurious SDB FIS "
+				"%08x:%08x orig_qc_active=%08x qc_active=%08x\n",
+				sdb_fis[0], sdb_fis[1], orig_qc_active, qc_active);
+		}
+	}
 }
 
 static void ahci_irq_clear(struct ata_port *ap)

Re: [RFT] major libata update

[Jeff Garzik]

Tejun Heo wrote:
> Hmmm.. The drive is issuing SDB FIS which completes already completed 
> tags.  This could be dangerous.  Depending on timing, it might end up 
> finishing a command which occupied the slot which hasn't been processed 
> yet.  If a drive does this, NCQ shouldn't be enabled for it.  Can you 
> post full boot dmesg?

I'm not sure the data supports that conclusion?  PORT_IRQ_SDB_FIS is 
quite normal and expected during NCQ operation, if that interrupt is 
enabled.  Just normal SDB:Entry and SDB:SetIntr states.

Side note:  looking at those states reminds me that ATAPI devices that 
support Asynchronous Notification (an end to CD-ROM polling) will soon 
be appearing on the market.  We'll need to make note of the Notification 
bit, if present...

	Jeff

Re: [RFT] major libata update

[Jeff Garzik]

Jeff Garzik wrote:
> Tejun Heo wrote:
>> Hmmm.. The drive is issuing SDB FIS which completes already completed 
>> tags.  This could be dangerous.  Depending on timing, it might end up 
>> finishing a command which occupied the slot which hasn't been 
>> processed yet.  If a drive does this, NCQ shouldn't be enabled for 
>> it.  Can you post full boot dmesg?
> 
> I'm not sure the data supports that conclusion?  PORT_IRQ_SDB_FIS is 
> quite normal and expected during NCQ operation, if that interrupt is 
> enabled.  Just normal SDB:Entry and SDB:SetIntr states.

Strike that last part:  PORT_IRQ_SDB_FIS will appear, as with other 
status bits, even if the enable bit is not set.

So, you'll see that whenever you get an SDB FIS during normal operation.

	Jeff

Re: [RFT] major libata update

[Tejun Heo]

Jeff Garzik wrote:
> Jeff Garzik wrote:
>> Tejun Heo wrote:
>>> Hmmm.. The drive is issuing SDB FIS which completes already completed 
>>> tags.  This could be dangerous.  Depending on timing, it might end up 
>>> finishing a command which occupied the slot which hasn't been 
>>> processed yet.  If a drive does this, NCQ shouldn't be enabled for 
>>> it.  Can you post full boot dmesg?
>>
>> I'm not sure the data supports that conclusion?  PORT_IRQ_SDB_FIS is 
>> quite normal and expected during NCQ operation, if that interrupt is 
>> enabled.  Just normal SDB:Entry and SDB:SetIntr states.
> 
> Strike that last part:  PORT_IRQ_SDB_FIS will appear, as with other 
> status bits, even if the enable bit is not set.
> 
> So, you'll see that whenever you get an SDB FIS during normal operation.

The problem is with the second dword.  Here are some of spurious SDB 
FISes Ric's AHCI was receiving.

004040a1:10000000
004040a1:00000020
004040a1:00000080

If the second dword were all zero, it's simply SDB FIS turning on IRQ 
(bit 14 of the first dword) and there's nothing to worry about. 
However, all those spurious SDBs have one bit set in the second dword - 
meaning the SDB completes the corresponding tag, but the tag isn't 
active when those SDBs are received.

This is okay as long as the controller thinks the tags are unoccupied 
when those SDBs are received, but it's not something which can be 
guaranteed.  NCQ command synchronization depends on devices not 
completing the same commands more than once.

The duplicate completions might be okay if the drive guarantees it 
doesn't send it if it loses to command issuance.  e.g.

1. drive sends completion for tag x
2. drive shortly schedules another completion for tag x (spurious)
3. ahci/driver complete tag x
4. ahci/driver issues tag x
5. drive receives command for tag x before sending the spurious 
completion and determines not to send the spurious completion. (not very 
likely)

If above is true, the drive might be okay, but nobody can guarantee how 
  various controllers react.  It depends on how controllers manage 
SActive (when to turn bits on).  At any rate, it's dangerous IMHO.

-- 
tejun

Re: [RFT] major libata update

[Jeff Garzik]

Tejun Heo wrote:
> Jeff Garzik wrote:
>> Jeff Garzik wrote:
>>> Tejun Heo wrote:
>>>> Hmmm.. The drive is issuing SDB FIS which completes already 
>>>> completed tags.  This could be dangerous.  Depending on timing, it 
>>>> might end up finishing a command which occupied the slot which 
>>>> hasn't been processed yet.  If a drive does this, NCQ shouldn't be 
>>>> enabled for it.  Can you post full boot dmesg?
>>>
>>> I'm not sure the data supports that conclusion?  PORT_IRQ_SDB_FIS is 
>>> quite normal and expected during NCQ operation, if that interrupt is 
>>> enabled.  Just normal SDB:Entry and SDB:SetIntr states.
>>
>> Strike that last part:  PORT_IRQ_SDB_FIS will appear, as with other 
>> status bits, even if the enable bit is not set.
>>
>> So, you'll see that whenever you get an SDB FIS during normal operation.
> 
> The problem is with the second dword.  Here are some of spurious SDB 
> FISes Ric's AHCI was receiving.
> 
> 004040a1:10000000
> 004040a1:00000020
> 004040a1:00000080
> 
> If the second dword were all zero, it's simply SDB FIS turning on IRQ 
> (bit 14 of the first dword) and there's nothing to worry about. However, 
> all those spurious SDBs have one bit set in the second dword - meaning 
> the SDB completes the corresponding tag, but the tag isn't active when 
> those SDBs are received.
> 
> This is okay as long as the controller thinks the tags are unoccupied 
> when those SDBs are received, but it's not something which can be 
> guaranteed.  NCQ command synchronization depends on devices not 
> completing the same commands more than once.
> 
> The duplicate completions might be okay if the drive guarantees it 
> doesn't send it if it loses to command issuance.  e.g.
> 
> 1. drive sends completion for tag x
> 2. drive shortly schedules another completion for tag x (spurious)
> 3. ahci/driver complete tag x
> 4. ahci/driver issues tag x
> 5. drive receives command for tag x before sending the spurious 
> completion and determines not to send the spurious completion. (not very 
> likely)
> 
> If above is true, the drive might be okay, but nobody can guarantee how 
>  various controllers react.  It depends on how controllers manage 
> SActive (when to turn bits on).  At any rate, it's dangerous IMHO.

If the silicon is screwing up SActive bits, then we have bigger problems 
than spurious interrupts.

So, the typical policy of Internet servers applies here:  "be liberal in 
what you accept."  For smart controllers like AHCI, we will simply set 
the desired IRQ mask, then happily receive and ack events anytime the 
controller decides to raise them.  If the controller decides to send us 
a no-op, don't worry about it.  This is particularly true when we turn 
on Command Coalescing, where we'll have a run of work initiated 
[sometimes] by an internal timer, rather than an actual FIS reception.

Side note:  remember that !BSY denotes that the device may accept 
another [NCQ] command (something AHCI doesn't appear to check...).  The 
device is free within NCQ rules to give itself some breathing room, and 
not indicate its ready for new commands immediately.

Currently it appears to be a bug in ahci that we do not check for !BSY, 
but simply assume the device is ready if queue is not full.

	Jeff

Re: [RFT] major libata update

[Tejun Heo]

Jeff Garzik wrote:
> Tejun Heo wrote:
>> Jeff Garzik wrote:
>>> Jeff Garzik wrote:
>>>> Tejun Heo wrote:
>>>>> Hmmm.. The drive is issuing SDB FIS which completes already 
>>>>> completed tags.  This could be dangerous.  Depending on timing, it 
>>>>> might end up finishing a command which occupied the slot which 
>>>>> hasn't been processed yet.  If a drive does this, NCQ shouldn't be 
>>>>> enabled for it.  Can you post full boot dmesg?
>>>>
>>>> I'm not sure the data supports that conclusion?  PORT_IRQ_SDB_FIS is 
>>>> quite normal and expected during NCQ operation, if that interrupt is 
>>>> enabled.  Just normal SDB:Entry and SDB:SetIntr states.
>>>
>>> Strike that last part:  PORT_IRQ_SDB_FIS will appear, as with other 
>>> status bits, even if the enable bit is not set.
>>>
>>> So, you'll see that whenever you get an SDB FIS during normal operation.
>>
>> The problem is with the second dword.  Here are some of spurious SDB 
>> FISes Ric's AHCI was receiving.
>>
>> 004040a1:10000000
>> 004040a1:00000020
>> 004040a1:00000080
>>
>> If the second dword were all zero, it's simply SDB FIS turning on IRQ 
>> (bit 14 of the first dword) and there's nothing to worry about. 
>> However, all those spurious SDBs have one bit set in the second dword 
>> - meaning the SDB completes the corresponding tag, but the tag isn't 
>> active when those SDBs are received.
>>
>> This is okay as long as the controller thinks the tags are unoccupied 
>> when those SDBs are received, but it's not something which can be 
>> guaranteed.  NCQ command synchronization depends on devices not 
>> completing the same commands more than once.
>>
>> The duplicate completions might be okay if the drive guarantees it 
>> doesn't send it if it loses to command issuance.  e.g.
>>
>> 1. drive sends completion for tag x
>> 2. drive shortly schedules another completion for tag x (spurious)
>> 3. ahci/driver complete tag x
>> 4. ahci/driver issues tag x
>> 5. drive receives command for tag x before sending the spurious 
>> completion and determines not to send the spurious completion. (not 
>> very likely)
>>
>> If above is true, the drive might be okay, but nobody can guarantee 
>> how  various controllers react.  It depends on how controllers manage 
>> SActive (when to turn bits on).  At any rate, it's dangerous IMHO.
> 
> If the silicon is screwing up SActive bits, then we have bigger problems 
> than spurious interrupts.
> 
> So, the typical policy of Internet servers applies here:  "be liberal in 
> what you accept."  For smart controllers like AHCI, we will simply set 
> the desired IRQ mask, then happily receive and ack events anytime the 
> controller decides to raise them.  If the controller decides to send us 
> a no-op, don't worry about it.  This is particularly true when we turn 
> on Command Coalescing, where we'll have a run of work initiated 
> [sometimes] by an internal timer, rather than an actual FIS reception.

I wish I could explain it better.  This is a clear protocol violation 
from the drive.  Depending on specific implementation of the drive and 
the controller, it can result in completion of command which is not 
processed yet (data corruption!).

If I'm misunderstanding something, please point out.

> Side note:  remember that !BSY denotes that the device may accept 
> another [NCQ] command (something AHCI doesn't appear to check...).  The 
> device is free within NCQ rules to give itself some breathing room, and 
> not indicate its ready for new commands immediately.
> 
> Currently it appears to be a bug in ahci that we do not check for !BSY, 
> but simply assume the device is ready if queue is not full.

AFAIK, unless we do CLO explicitly, AHCI takes care of BSY waiting, NCQ 
or not.

-- 
tejun

Re: [RFT] major libata update

[Jeff Garzik]

Tejun Heo wrote:
> Jeff Garzik wrote:
>> Tejun Heo wrote:
>>> Jeff Garzik wrote:
>>>> Jeff Garzik wrote:
>>>>> Tejun Heo wrote:
>>>>>> Hmmm.. The drive is issuing SDB FIS which completes already 
>>>>>> completed tags.  This could be dangerous.  Depending on timing, it 
>>>>>> might end up finishing a command which occupied the slot which 
>>>>>> hasn't been processed yet.  If a drive does this, NCQ shouldn't be 
>>>>>> enabled for it.  Can you post full boot dmesg?
>>>>>
>>>>> I'm not sure the data supports that conclusion?  PORT_IRQ_SDB_FIS 
>>>>> is quite normal and expected during NCQ operation, if that 
>>>>> interrupt is enabled.  Just normal SDB:Entry and SDB:SetIntr states.
>>>>
>>>> Strike that last part:  PORT_IRQ_SDB_FIS will appear, as with other 
>>>> status bits, even if the enable bit is not set.
>>>>
>>>> So, you'll see that whenever you get an SDB FIS during normal 
>>>> operation.
>>>
>>> The problem is with the second dword.  Here are some of spurious SDB 
>>> FISes Ric's AHCI was receiving.
>>>
>>> 004040a1:10000000
>>> 004040a1:00000020
>>> 004040a1:00000080
>>>
>>> If the second dword were all zero, it's simply SDB FIS turning on IRQ 
>>> (bit 14 of the first dword) and there's nothing to worry about. 
>>> However, all those spurious SDBs have one bit set in the second dword 
>>> - meaning the SDB completes the corresponding tag, but the tag isn't 
>>> active when those SDBs are received.
>>>
>>> This is okay as long as the controller thinks the tags are unoccupied 
>>> when those SDBs are received, but it's not something which can be 
>>> guaranteed.  NCQ command synchronization depends on devices not 
>>> completing the same commands more than once.
>>>
>>> The duplicate completions might be okay if the drive guarantees it 
>>> doesn't send it if it loses to command issuance.  e.g.
>>>
>>> 1. drive sends completion for tag x
>>> 2. drive shortly schedules another completion for tag x (spurious)
>>> 3. ahci/driver complete tag x
>>> 4. ahci/driver issues tag x
>>> 5. drive receives command for tag x before sending the spurious 
>>> completion and determines not to send the spurious completion. (not 
>>> very likely)
>>>
>>> If above is true, the drive might be okay, but nobody can guarantee 
>>> how  various controllers react.  It depends on how controllers manage 
>>> SActive (when to turn bits on).  At any rate, it's dangerous IMHO.
>>
>> If the silicon is screwing up SActive bits, then we have bigger 
>> problems than spurious interrupts.
>>
>> So, the typical policy of Internet servers applies here:  "be liberal 
>> in what you accept."  For smart controllers like AHCI, we will simply 
>> set the desired IRQ mask, then happily receive and ack events anytime 
>> the controller decides to raise them.  If the controller decides to 
>> send us a no-op, don't worry about it.  This is particularly true when 
>> we turn on Command Coalescing, where we'll have a run of work 
>> initiated [sometimes] by an internal timer, rather than an actual FIS 
>> reception.
> 
> I wish I could explain it better.  This is a clear protocol violation 
> from the drive.  Depending on specific implementation of the drive and 
> the controller, it can result in completion of command which is not 
> processed yet (data corruption!).

A spurious SDB FIS updating SActive is bad news, yes.  But with a busy 
AHCI controller, perhaps sharing PCI interrupts, I think there is 
distinct potential to be flagged as a spurious interrupt, when not.

But I'm taking a higher level view than that, from two angles:

1) I think its a waste of time to even worry about this.  We should just 
program AHCI to spec, and  let the controller and devices talk to each 
other as they will.  If there are spurious completions, that should show 
up elsewhere via tag poisoning and/or tag rotation.  Or data corruption, 
if nothing else.  We'll know, even without the potentially-questionable 
spurious interrupt detection code.

2) Given the factors mentioned above -- shared irq and busy 
multi-controller controller -- highly asynchronous conditions combine to 
create a higher probability of seeing events arrive while you're 
processing other events.  Overall, I feel that trying to accurately 
account for everything going on in silicon leads to madness and 
complexity :)  Just hand things to silicon, and trust that it either 
accurately accounts SDB FISs, or will be quite obviously broken under 
stress.


>> Side note:  remember that !BSY denotes that the device may accept 
>> another [NCQ] command (something AHCI doesn't appear to check...).  
>> The device is free within NCQ rules to give itself some breathing 
>> room, and not indicate its ready for new commands immediately.
>>
>> Currently it appears to be a bug in ahci that we do not check for 
>> !BSY, but simply assume the device is ready if queue is not full.
> 
> AFAIK, unless we do CLO explicitly, AHCI takes care of BSY waiting, NCQ 
> or not.

True, indeed.

	Jeff

Re: [RFT] major libata update

[Tejun Heo]

Jeff Garzik wrote:
> A spurious SDB FIS updating SActive is bad news, yes.  But with a busy 
> AHCI controller, perhaps sharing PCI interrupts, I think there is 
> distinct potential to be flagged as a spurious interrupt, when not.

You are talking about cases where the controller raises SDB IRQ without 
actually receiving one, right?  That is certainly possible and if this 
is the case, I'm very okay with eating the IRQ.

> But I'm taking a higher level view than that, from two angles:
> 
> 1) I think its a waste of time to even worry about this.  We should just 
> program AHCI to spec, and  let the controller and devices talk to each 
> other as they will.  If there are spurious completions, that should show 
> up elsewhere via tag poisoning and/or tag rotation.  Or data corruption, 
> if nothing else.  We'll know, even without the potentially-questionable 
> spurious interrupt detection code.
> 
> 2) Given the factors mentioned above -- shared irq and busy 
> multi-controller controller -- highly asynchronous conditions combine to 
> create a higher probability of seeing events arrive while you're 
> processing other events.  Overall, I feel that trying to accurately 
> account for everything going on in silicon leads to madness and 
> complexity :)  Just hand things to silicon, and trust that it either 
> accurately accounts SDB FISs, or will be quite obviously broken under 
> stress.

I see your point.  But I'm quite worried about this one, because

* This won't occur often and even when it occurs at the hardware level, 
it might be masked by processing delays in the kernel.  But when it 
blows, it will corrupt data silently.  We might not see such a report 
for months and even when it strikes pinpointing the origin will be 
extremely difficult.

* The danger of the race condition is not theoretical.  I think I can 
trigger it with AHCI.  AHCI delegates management of SActive register to 
the driver.

Remember the lost command completion bug in very early AHCI NCQ 
implementation?  It was caused by setting SActive after issuing the 
command.  Command completion SDB was received before SActive was cleared 
and when the IRQ handler kicks in afterward, it saw the bit which was 
set after completion and thus couldn't complete the command resulting in 
timeout.

This problem is similar except that it's the other way around.  From 
ahci_qc_issue()...

	if (qc->tf.protocol == ATA_PROT_NCQ)
		writel(1 << qc->tag, port_mmio + PORT_SCR_ACT);
	writel(1 << qc->tag, port_mmio + PORT_CMD_ISSUE);

Let's say we insert mdelay(10) between SActive setting and actual 
command issuance.  It will drastically increase the chance of receiving 
the spurious SDB FISes inbetween.  The following sequence is likely when 
such event occurs.

1. driver sets SActive bit for tag x
2. disk issues spurious SDB completion for tag x
3. ahci receives the SDB FIS, clears the corresponding SActive bit and 
raises interrupt
4. driver issues command for tag x and complete command issuance
5. IRQ handler kicks in sees that SActive for tag x is clear and 
completes the corresponding qc.
6. we now have data corruption.

I want to emphasize that SActive manipulation correctness is highly 
critical for NCQ integrity.  It's the thin thread the whole NCQ protocol 
hangs on.  Spurious SDB FIS amounts to random command completion without 
synchronization.  This is a serious problem which requires handling and 
I'm pretty sure I'm not being paranoid here.

I think detection of this problem proves the necessity for spurious 
interrupt reporting, at least until NCQ driver and hardware mature.  We 
still don't know how drives act with NCQ commands and definitely need to 
learn what sorts of culprits they have and how to work around them.  The 
spurious interrupt handling allows us to detect and diagnose such 
problems much better.

Am I making any sense?  I really wish I could write better.  Please give 
it some thoughts even if my writing sucks.  :-)

-- 
tejun

Re: [RFT] major libata update

[Jeff Garzik]

Tejun Heo wrote:
> Jeff Garzik wrote:
>> Tejun Heo wrote:
>>> Jeff Garzik wrote:
>>>> Jeff Garzik wrote:
>>>>> Tejun Heo wrote:
>>>>>> Hmmm.. The drive is issuing SDB FIS which completes already 
>>>>>> completed tags.  This could be dangerous.  Depending on timing, it 
>>>>>> might end up finishing a command which occupied the slot which 
>>>>>> hasn't been processed yet.  If a drive does this, NCQ shouldn't be 
>>>>>> enabled for it.  Can you post full boot dmesg?
>>>>>
>>>>> I'm not sure the data supports that conclusion?  PORT_IRQ_SDB_FIS 
>>>>> is quite normal and expected during NCQ operation, if that 
>>>>> interrupt is enabled.  Just normal SDB:Entry and SDB:SetIntr states.
>>>>
>>>> Strike that last part:  PORT_IRQ_SDB_FIS will appear, as with other 
>>>> status bits, even if the enable bit is not set.
>>>>
>>>> So, you'll see that whenever you get an SDB FIS during normal 
>>>> operation.
>>>
>>> The problem is with the second dword.  Here are some of spurious SDB 
>>> FISes Ric's AHCI was receiving.
>>>
>>> 004040a1:10000000
>>> 004040a1:00000020
>>> 004040a1:00000080
>>>
>>> If the second dword were all zero, it's simply SDB FIS turning on IRQ 
>>> (bit 14 of the first dword) and there's nothing to worry about. 
>>> However, all those spurious SDBs have one bit set in the second dword 
>>> - meaning the SDB completes the corresponding tag, but the tag isn't 
>>> active when those SDBs are received.
>>>
>>> This is okay as long as the controller thinks the tags are unoccupied 
>>> when those SDBs are received, but it's not something which can be 
>>> guaranteed.  NCQ command synchronization depends on devices not 
>>> completing the same commands more than once.
>>>
>>> The duplicate completions might be okay if the drive guarantees it 
>>> doesn't send it if it loses to command issuance.  e.g.
>>>
>>> 1. drive sends completion for tag x
>>> 2. drive shortly schedules another completion for tag x (spurious)
>>> 3. ahci/driver complete tag x
>>> 4. ahci/driver issues tag x
>>> 5. drive receives command for tag x before sending the spurious 
>>> completion and determines not to send the spurious completion. (not 
>>> very likely)
>>>
>>> If above is true, the drive might be okay, but nobody can guarantee 
>>> how  various controllers react.  It depends on how controllers manage 
>>> SActive (when to turn bits on).  At any rate, it's dangerous IMHO.
>>
>> If the silicon is screwing up SActive bits, then we have bigger 
>> problems than spurious interrupts.
>>
>> So, the typical policy of Internet servers applies here:  "be liberal 
>> in what you accept."  For smart controllers like AHCI, we will simply 
>> set the desired IRQ mask, then happily receive and ack events anytime 
>> the controller decides to raise them.  If the controller decides to 
>> send us a no-op, don't worry about it.  This is particularly true when 
>> we turn on Command Coalescing, where we'll have a run of work 
>> initiated [sometimes] by an internal timer, rather than an actual FIS 
>> reception.
> 
> I wish I could explain it better.  This is a clear protocol violation 
> from the drive.  Depending on specific implementation of the drive and 
> the controller, it can result in completion of command which is not 
> processed yet (data corruption!).

I quite understand the implications.  My argument comes from a different 
angle:  I don't feel we should be adding tons of code that essentially 
validates the silicon.  There are plenty of chances for the hardware to 
fuck up in a way that corrupts data, and is also difficult to detect. 
Pre-production BIOS have even done silly things like turn off data 
verification (checksum) by default.  Talk about subtle corruption...

So I feel the best path is to use the hardware programming sequences 
described in the spec, because that's what the chip designers and Q/A 
engineers validate with (read: the Windows driver).

Once we have deployed drivers with the standard programming sequences, 
_then_ we can consider looking into proper spurious interrupt 
accounting.  The current AHCI interrupt accounting stuff is not nearly 
as accurate as it should be, which implies that the code simply should 
not exist at the present time.

	Jeff

Re: [RFT] major libata update

[Tejun Heo]

Jeff Garzik wrote:
> I quite understand the implications.  My argument comes from a different 
> angle:  I don't feel we should be adding tons of code that essentially 
> validates the silicon.

Actually, I think libata-core can/should implement helper function to 
handle ATA device malfunctions in controller-independent way.  Most 
FIS-based controllers provide some level of information about the most 
recent FIS.  The helper function can figure out what's going on and 
required action with info available in the libata-core level and the FIS 
info from LLD irq handler.

> There are plenty of chances for the hardware to 
> fuck up in a way that corrupts data, and is also difficult to detect. 
> Pre-production BIOS have even done silly things like turn off data 
> verification (checksum) by default.  Talk about subtle corruption...
> 
> So I feel the best path is to use the hardware programming sequences 
> described in the spec, because that's what the chip designers and Q/A 
> engineers validate with (read: the Windows driver).

I understand your concern about bloating LLDs with special case handling 
coes but I don't really follow the above logic.  Vendors include every 
possible workaround in their proprietary drivers to make things work 
smoothly.  They don't stick to datasheets in the face existing problems.

> Once we have deployed drivers with the standard programming sequences, 
> _then_ we can consider looking into proper spurious interrupt 
> accounting.  The current AHCI interrupt accounting stuff is not nearly 
> as accurate as it should be, which implies that the code simply should 
> not exist at the present time.

I think it's okay to remove spurious interrupt accounting until AHCI irq 
handling is in better shape as long as we plan to implement proper 
handling in not too distant future.  Also, please note that without code 
that reporting such events, it would be difficult to learn what kind of 
weird things happen.

Thanks.

-- 
tejun

Re: [RFT] major libata update

[Jeff Garzik]

Actually, looking even more at the code, I think the entire "spurious 
interrupt" code block is bogus.

The device is free to send D2H or SDB FIS to clear Status bits, as well 
as SDB FIS's to update SActive.  The ata_qc_complete_multiple() call 
will do the right thing, even if there is no work to do.

As another side note, command coalescing is worth experimenting with.

	Jeff

Re: [RFT] major libata update

[Tejun Heo]

Jeff Garzik wrote:
> Actually, looking even more at the code, I think the entire "spurious 
> interrupt" code block is bogus.
> 
> The device is free to send D2H or SDB FIS to clear Status bits, as well 
> as SDB FIS's to update SActive.  The ata_qc_complete_multiple() call 
> will do the right thing, even if there is no work to do.

Yes, they are, but...

* Please note that SActive update via SDB FIS is edge-triggered.  It 
doesn't send the whole image of the register.  The SActive bits in SDB 
FIS indicate W1C (this is inevitable because controller and device 
cannot be in full synchronization regarding SActive).  So, they have can 
have dangerous side effects.

* Those spurious FISes are actively setting the I bit requesting 
interrupt explicitly.  Those are not innocent status update FISes.  And 
the spec state machines don't allow D2H FISes during NCQ command phase. 
  I seem to recollect it's actually forbidden explicitly but currently 
cannot find where.  I'll keep looking.

> As another side note, command coalescing is worth experimenting with.

Might be, but I'm a bit skeptical.  We might lose more to added latency.

-- 
tejun

Re: [RFT] major libata update

[Tejun Heo]

Tejun Heo wrote:
> Jeff Garzik wrote:
>> Actually, looking even more at the code, I think the entire "spurious 
>> interrupt" code block is bogus.
>>
>> The device is free to send D2H or SDB FIS to clear Status bits, as 
>> well as SDB FIS's to update SActive.  The ata_qc_complete_multiple() 
>> call will do the right thing, even if there is no work to do.
> 
> Yes, they are, but...
> 
> * Please note that SActive update via SDB FIS is edge-triggered.  It 
> doesn't send the whole image of the register.  The SActive bits in SDB 
> FIS indicate W1C (this is inevitable because controller and device 
> cannot be in full synchronization regarding SActive).  So, they have can 
> have dangerous side effects.
> 
> * Those spurious FISes are actively setting the I bit requesting 
> interrupt explicitly.  Those are not innocent status update FISes.  And 
> the spec state machines don't allow D2H FISes during NCQ command phase. 
>  I seem to recollect it's actually forbidden explicitly but currently 
> cannot find where.  I'll keep looking.

Oops, strike out the part about D2H not allowed.  It certainly is 
allowed to clear BSY.  Sorry.

-- 
tejun

Re: [RFT] major libata update

[Ric Wheeler]

Tejun Heo wrote:

> Tejun Heo wrote:
>
>> Jeff Garzik wrote:
>>
>>> Actually, looking even more at the code, I think the entire 
>>> "spurious interrupt" code block is bogus.
>>>
>>> The device is free to send D2H or SDB FIS to clear Status bits, as 
>>> well as SDB FIS's to update SActive.  The ata_qc_complete_multiple() 
>>> call will do the right thing, even if there is no work to do.
>>
>>
>> Yes, they are, but...
>>
>> * Please note that SActive update via SDB FIS is edge-triggered.  It 
>> doesn't send the whole image of the register.  The SActive bits in 
>> SDB FIS indicate W1C (this is inevitable because controller and 
>> device cannot be in full synchronization regarding SActive).  So, 
>> they have can have dangerous side effects.
>>
>> * Those spurious FISes are actively setting the I bit requesting 
>> interrupt explicitly.  Those are not innocent status update FISes.  
>> And the spec state machines don't allow D2H FISes during NCQ command 
>> phase.  I seem to recollect it's actually forbidden explicitly but 
>> currently cannot find where.  I'll keep looking.
>
>
> Oops, strike out the part about D2H not allowed.  It certainly is 
> allowed to clear BSY.  Sorry.

(Trying to keep up ;-))

Is there still value in testing your last patch?

ric

Re: [RFT] major libata update

[Tejun Heo]

Ric Wheeler wrote:
> 
> (Trying to keep up ;-))
> 
> Is there still value in testing your last patch?
> 

The result should be the same, so it's not really necessary.  But, just 
in case, sticking that patch when you test the barrier would be nice so 
that things can be verified again.

Thanks for testing.

-- 
tejun

Re: [RFT] major libata update

[Ric Wheeler]

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


Tejun Heo wrote:

> Ric Wheeler wrote:
>
>>
>> (Trying to keep up ;-))
>>
>> Is there still value in testing your last patch?
>>
>
> The result should be the same, so it's not really necessary.  But, 
> just in case, sticking that patch when you test the barrier would be 
> nice so that things can be verified again.

I applied both patches and rebooted - many minutes later & 94MB of log 
file, I ran my synchronous file write test (the last 200 lines of the 
log file is attached). Is more useful?

>
> Thanks for testing.
>
thanks for the code - this is great!

ric


[-- Attachment #2: messages_tail --]
[-- Type: text/plain, Size: 8696 bytes --]

May 17 03:30:54 centera kernel: [start_ordered           ]: BIO d08998c0 3357330 4096
May 17 03:30:54 centera kernel: [start_ordered           ]: ordered=1 in_flight=0
May 17 03:30:54 centera kernel: [blk_do_ordered          ]: start_ordered ed3553c0->dfe2bd28
May 17 03:30:54 centera kernel: [elv_next_request        ]: dfe2bd28 (bar)
May 17 03:30:54 centera kernel: [ordered_bio_endio       ]: q->orderr=0 error=0
May 17 03:30:54 centera kernel: [flush_dry_bio_endio     ]: BIO f18ffa00 3357330 4096
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: ordseq=17 seq=08 orderr=0 error=0
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: sequence complete
May 17 03:30:54 centera kernel: [ordered_bio_endio       ]: q->orderr=0 error=0
May 17 03:30:54 centera kernel: [flush_dry_bio_endio     ]: BIO f18ff300 3357330 4096
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: ordseq=17 seq=08 orderr=0 error=0
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: sequence complete
May 17 03:30:54 centera kernel: [ordered_bio_endio       ]: q->orderr=0 error=0
May 17 03:30:54 centera kernel: [flush_dry_bio_endio     ]: BIO d0899600 3357330 4096
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: ordseq=17 seq=08 orderr=0 error=0
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: sequence complete
May 17 03:30:54 centera kernel: [ordered_bio_endio       ]: q->orderr=0 error=0
May 17 03:30:54 centera kernel: [flush_dry_bio_endio     ]: BIO d08998c0 3357330 4096
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: ordseq=17 seq=08 orderr=0 error=0
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: sequence complete
May 17 03:30:54 centera kernel: [start_ordered           ]: ed3551c8 -> dfe2b1b8,dfe2b260,dfe2b308 infl=0
May 17 03:30:54 centera kernel: [start_ordered           ]: f18ff4c0 0 3357330 8 8 1 1 dfdd9000
May 17 03:30:54 centera kernel: [start_ordered           ]: BIO f18ff4c0 3357330 4096
May 17 03:30:54 centera kernel: [start_ordered           ]: ordered=1 in_flight=0
May 17 03:30:54 centera kernel: [blk_do_ordered          ]: start_ordered ed3551c8->dfe2b260
May 17 03:30:54 centera kernel: [elv_next_request        ]: dfe2b260 (bar)
May 17 03:30:54 centera kernel: [start_ordered           ]: ed355ba0 -> dfe2b550,dfe2b5f8,dfe2b6a0 infl=0
May 17 03:30:54 centera kernel: [start_ordered           ]: f18ffcc0 0 3357330 8 8 1 1 dff0b000
May 17 03:30:54 centera kernel: [start_ordered           ]: BIO f18ffcc0 3357330 4096
May 17 03:30:54 centera kernel: [start_ordered           ]: ordered=1 in_flight=0
May 17 03:30:54 centera kernel: [blk_do_ordered          ]: start_ordered ed355ba0->dfe2b5f8
May 17 03:30:54 centera kernel: [elv_next_request        ]: dfe2b5f8 (bar)
May 17 03:30:54 centera kernel: [start_ordered           ]: ed341318 -> dfe2b8e8,dfe2b990,dfe2ba38 infl=0
May 17 03:30:54 centera kernel: [start_ordered           ]: e413bf00 0 3357330 8 8 1 1 f7b57000
May 17 03:30:54 centera kernel: [start_ordered           ]: BIO e413bf00 3357330 4096
May 17 03:30:54 centera kernel: [start_ordered           ]: ordered=1 in_flight=0
May 17 03:30:54 centera kernel: [blk_do_ordered          ]: start_ordered ed341318->dfe2b990
May 17 03:30:54 centera kernel: [elv_next_request        ]: dfe2b990 (bar)
May 17 03:30:54 centera kernel: [start_ordered           ]: ed3553c0 -> dfe2bc80,dfe2bd28,dfe2bdd0 infl=0
May 17 03:30:54 centera kernel: [start_ordered           ]: d08993c0 0 3357330 8 8 1 1 df937000
May 17 03:30:54 centera kernel: [start_ordered           ]: BIO d08993c0 3357330 4096
May 17 03:30:54 centera kernel: [start_ordered           ]: ordered=1 in_flight=0
May 17 03:30:54 centera kernel: [blk_do_ordered          ]: start_ordered ed3553c0->dfe2bd28
May 17 03:30:54 centera kernel: [elv_next_request        ]: dfe2bd28 (bar)
May 17 03:30:54 centera kernel: [ordered_bio_endio       ]: q->orderr=0 error=0
May 17 03:30:54 centera kernel: [flush_dry_bio_endio     ]: BIO f18ff4c0 3357330 4096
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: ordseq=17 seq=08 orderr=0 error=0
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: sequence complete
May 17 03:30:54 centera kernel: [ordered_bio_endio       ]: q->orderr=0 error=0
May 17 03:30:54 centera kernel: [flush_dry_bio_endio     ]: BIO f18ffcc0 3357330 4096
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: ordseq=17 seq=08 orderr=0 error=0
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: sequence complete
May 17 03:30:54 centera kernel: [ordered_bio_endio       ]: q->orderr=0 error=0
May 17 03:30:54 centera kernel: [flush_dry_bio_endio     ]: BIO e413bf00 3357330 4096
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: ordseq=17 seq=08 orderr=0 error=0
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: sequence complete
May 17 03:30:54 centera kernel: [ordered_bio_endio       ]: q->orderr=0 error=0
May 17 03:30:54 centera kernel: [flush_dry_bio_endio     ]: BIO d08993c0 3357330 4096
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: ordseq=17 seq=08 orderr=0 error=0
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: sequence complete
May 17 03:30:54 centera kernel: [start_ordered           ]: ed3553c0 -> dfe2b1b8,dfe2b260,dfe2b308 infl=0
May 17 03:30:54 centera kernel: [start_ordered           ]: e413bf00 0 3357330 8 8 1 1 dfdd9000
May 17 03:30:54 centera kernel: [start_ordered           ]: BIO e413bf00 3357330 4096
May 17 03:30:54 centera kernel: [start_ordered           ]: ordered=1 in_flight=0
May 17 03:30:54 centera kernel: [blk_do_ordered          ]: start_ordered ed3553c0->dfe2b260
May 17 03:30:54 centera kernel: [elv_next_request        ]: dfe2b260 (bar)
May 17 03:30:54 centera kernel: [start_ordered           ]: ed341318 -> dfe2b550,dfe2b5f8,dfe2b6a0 infl=0
May 17 03:30:54 centera kernel: [start_ordered           ]: f18ffcc0 0 3357330 8 8 1 1 dff0b000
May 17 03:30:54 centera kernel: [start_ordered           ]: BIO f18ffcc0 3357330 4096
May 17 03:30:54 centera kernel: [start_ordered           ]: ordered=1 in_flight=0
May 17 03:30:54 centera kernel: [blk_do_ordered          ]: start_ordered ed341318->dfe2b5f8
May 17 03:30:54 centera kernel: [elv_next_request        ]: dfe2b5f8 (bar)
May 17 03:30:54 centera kernel: [start_ordered           ]: ed355ba0 -> dfe2b8e8,dfe2b990,dfe2ba38 infl=0
May 17 03:30:54 centera kernel: [start_ordered           ]: f18ff4c0 0 3357330 8 8 1 1 f7b57000
May 17 03:30:54 centera kernel: [start_ordered           ]: BIO f18ff4c0 3357330 4096
May 17 03:30:54 centera kernel: [start_ordered           ]: ordered=1 in_flight=0
May 17 03:30:54 centera kernel: [blk_do_ordered          ]: start_ordered ed355ba0->dfe2b990
May 17 03:30:54 centera kernel: [elv_next_request        ]: dfe2b990 (bar)
May 17 03:30:54 centera kernel: [start_ordered           ]: ed3551c8 -> dfe2bc80,dfe2bd28,dfe2bdd0 infl=0
May 17 03:30:54 centera kernel: [start_ordered           ]: d0899800 0 3357330 8 8 1 1 df937000
May 17 03:30:54 centera kernel: [start_ordered           ]: BIO d0899800 3357330 4096
May 17 03:30:54 centera kernel: [start_ordered           ]: ordered=1 in_flight=0
May 17 03:30:54 centera kernel: [blk_do_ordered          ]: start_ordered ed3551c8->dfe2bd28
May 17 03:30:54 centera kernel: [elv_next_request        ]: dfe2bd28 (bar)
May 17 03:30:54 centera kernel: [ordered_bio_endio       ]: q->orderr=0 error=0
May 17 03:30:54 centera kernel: [flush_dry_bio_endio     ]: BIO e413bf00 3357330 4096
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: ordseq=17 seq=08 orderr=0 error=0
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: sequence complete
May 17 03:30:54 centera kernel: [ordered_bio_endio       ]: q->orderr=0 error=0
May 17 03:30:54 centera kernel: [flush_dry_bio_endio     ]: BIO f18ffcc0 3357330 4096
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: ordseq=17 seq=08 orderr=0 error=0
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: sequence complete
May 17 03:30:54 centera kernel: [ordered_bio_endio       ]: q->orderr=0 error=0
May 17 03:30:54 centera kernel: [flush_dry_bio_endio     ]: BIO f18ff4c0 3357330 4096
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: ordseq=17 seq=08 orderr=0 error=0
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: sequence complete
May 17 03:30:54 centera kernel: [ordered_bio_endio       ]: q->orderr=0 error=0
May 17 03:30:54 centera kernel: [flush_dry_bio_endio     ]: BIO d0899800 3357330 4096
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: ordseq=17 seq=08 orderr=0 error=0
May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: sequence complete

Re: [RFT] major libata update

[Tejun Heo]

Ric Wheeler wrote:
> May 17 03:30:54 centera kernel: [start_ordered           ]: BIO d08998c0 3357330 4096
> May 17 03:30:54 centera kernel: [start_ordered           ]: ordered=1 in_flight=0
> May 17 03:30:54 centera kernel: [blk_do_ordered          ]: start_ordered ed3553c0->dfe2bd28
> May 17 03:30:54 centera kernel: [elv_next_request        ]: dfe2bd28 (bar)
> May 17 03:30:54 centera kernel: [ordered_bio_endio       ]: q->orderr=0 error=0
> May 17 03:30:54 centera kernel: [flush_dry_bio_endio     ]: BIO f18ffa00 3357330 4096
> May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: ordseq=17 seq=08 orderr=0 error=0
> May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: sequence complete
> May 17 03:30:54 centera kernel: [ordered_bio_endio       ]: q->orderr=0 error=0
> May 17 03:30:54 centera kernel: [flush_dry_bio_endio     ]: BIO f18ff300 3357330 4096
> May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: ordseq=17 seq=08 orderr=0 error=0
> May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: sequence complete
[--snip--]

Combined with your boot log, everything seems as expected.  Write cache 
is disabled, so the chosen ordered mode is 0x1 - DRAIN only.  In the log 
you've posted, there are no pending IOs on barrier issue, so the barrier 
is executed directly and then the sequence is complete.  If there were 
other requests pending, all that happens would be waiting for them to 
finish before issuing the barrier.

If you turned on write cache after the machine booted, what method did 
you use to turn on write cache?  If you issued the command directly 
using sg to an active device (usage count >= 1), SCSI doesn't snoop such 
commands and thus it won't adjust ordered mode automatically.  However, 
sd forces disk revalidation (and thus ordered reconfiguration) if you 
change cache mode via /sys/class/scsi_disk/X\:0\:0\:0/cache_type.

-- 
tejun

Re: [RFT] major libata update

[Ric Wheeler]

Tejun Heo wrote:

> Ric Wheeler wrote:
>
>> May 17 03:30:54 centera kernel: [start_ordered           ]: BIO 
>> d08998c0 3357330 4096
>> May 17 03:30:54 centera kernel: [start_ordered           ]: ordered=1 
>> in_flight=0
>> May 17 03:30:54 centera kernel: [blk_do_ordered          ]: 
>> start_ordered ed3553c0->dfe2bd28
>> May 17 03:30:54 centera kernel: [elv_next_request        ]: dfe2bd28 
>> (bar)
>> May 17 03:30:54 centera kernel: [ordered_bio_endio       ]: 
>> q->orderr=0 error=0
>> May 17 03:30:54 centera kernel: [flush_dry_bio_endio     ]: BIO 
>> f18ffa00 3357330 4096
>> May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: ordseq=17 
>> seq=08 orderr=0 error=0
>> May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: sequence 
>> complete
>> May 17 03:30:54 centera kernel: [ordered_bio_endio       ]: 
>> q->orderr=0 error=0
>> May 17 03:30:54 centera kernel: [flush_dry_bio_endio     ]: BIO 
>> f18ff300 3357330 4096
>> May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: ordseq=17 
>> seq=08 orderr=0 error=0
>> May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: sequence 
>> complete
>
> [--snip--]
>
> Combined with your boot log, everything seems as expected.  Write 
> cache is disabled, so the chosen ordered mode is 0x1 - DRAIN only.  In 
> the log you've posted, there are no pending IOs on barrier issue, so 
> the barrier is executed directly and then the sequence is complete.  
> If there were other requests pending, all that happens would be 
> waiting for them to finish before issuing the barrier.
>
> If you turned on write cache after the machine booted, what method did 
> you use to turn on write cache?  If you issued the command directly 
> using sg to an active device (usage count >= 1), SCSI doesn't snoop 
> such commands and thus it won't adjust ordered mode automatically.  
> However, sd forces disk revalidation (and thus ordered 
> reconfiguration) if you change cache mode via 
> /sys/class/scsi_disk/X\:0\:0\:0/cache_type.
>
That is what I suspected...

The write cache gets set via hdparm (in the previous kernel we had just 
hacked the sd code to always assume write back/barriers until this /sys 
control came along ;-)).

What is the magic sequence to get the cache type to flip? My first tries 
to poke cache type leave it firmly in write through...

ric

Re: [RFT] major libata update

[Ric Wheeler]

One other area that I would be interested in helping to test is the 
hotplug support (for ahci or Marvell when Mark adds it to sata_mv). 

Any pending patches based on Jeff's update for hotplug ;-) ?

ric

Re: [RFT] major libata update

[Mark Lord]

Tejun Heo wrote:
..
> sd forces disk revalidation (and thus ordered reconfiguration) if you 
> change cache mode via /sys/class/scsi_disk/X\:0\:0\:0/cache_type.

That's not implemented for libata --> the emulation in libata-scsi
rejects any attempt at a MODE_SELECT command, which is what the sysfs
attr triggers.

Wasn't there a patch to implement MODE_SELECT in libata once upon a time?

Cheers
-- 
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

Re: [RFT] major libata update

[Jeff Garzik]

Mark Lord wrote:
> Tejun Heo wrote:
> ..
>> sd forces disk revalidation (and thus ordered reconfiguration) if you 
>> change cache mode via /sys/class/scsi_disk/X\:0\:0\:0/cache_type.
> 
> That's not implemented for libata --> the emulation in libata-scsi
> rejects any attempt at a MODE_SELECT command, which is what the sysfs
> attr triggers.
> 
> Wasn't there a patch to implement MODE_SELECT in libata once upon a time?

A couple iterations from Douglas Gilbert, probably in linux-scsi archives...

BTW, libata needs to trap IDENTIFY*DEVICE and update its cached copy of 
the identify page, whenever MODE SELECT or another independent entity 
issues IDENTIFY*DEVICE.

	Jeff

Re: [RFT] major libata update

[Tejun Heo]

Jeff Garzik wrote:
> Mark Lord wrote:
>> Tejun Heo wrote:
>> ..
>>> sd forces disk revalidation (and thus ordered reconfiguration) if you 
>>> change cache mode via /sys/class/scsi_disk/X\:0\:0\:0/cache_type.
>>
>> That's not implemented for libata --> the emulation in libata-scsi
>> rejects any attempt at a MODE_SELECT command, which is what the sysfs
>> attr triggers.

I see.  I was just grepping for revalidation call.  It seems we're stuck 
then.

>> Wasn't there a patch to implement MODE_SELECT in libata once upon a time?
> 
> A couple iterations from Douglas Gilbert, probably in linux-scsi 
> archives...
> 
> BTW, libata needs to trap IDENTIFY*DEVICE and update its cached copy of 
> the identify page, whenever MODE SELECT or another independent entity 
> issues IDENTIFY*DEVICE.

Right.  Also, we need to snoop some passthrough commands and 
revalidate/reconfigure when configuration is explicitly changed.

-- 
tejun

Re: [RFT] major libata update

[Mark Lord]

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

Tejun Heo wrote:
> ..
> Right.  Also, we need to snoop some passthrough commands and 
> revalidate/reconfigure when configuration is explicitly changed.

Once the sysfs attr's actually work, I'll probably re-do my hdparm
stuff to detect use them when available, avoiding the need for libata
to snoop passthrough commands.  But Jeff may (or not) want to snoop anyway.

As a workaround for now, Ric is using the ugly hack attached here.

Cheers

[-- Attachment #2: wce_change_detect.patch --]
[-- Type: text/x-patch, Size: 1147 bytes --]

--- linux/drivers/scsi/libata-scsi.c.orig	2006-05-15 14:20:27.000000000 -0400
+++ linux/drivers/scsi/libata-scsi.c	2006-05-17 17:50:11.000000000 -0400
@@ -2479,6 +2479,18 @@
 		goto invalid_fld;
 
 	/*
+	 * Filter: detect changes to WCE on the drive
+	 */
+	if (tf->command == ATA_CMD_SET_FEATURES && (tf->feature & 0x7f) == 2) {
+		extern void sd_set_WCE(struct device *, int);
+		struct scsi_device *sdev = qc->scsicmd->device;
+		struct device *dev = &sdev->sdev_gendev;
+		unsigned int wce = tf->feature == 2 ? 1 : 0;
+		qc->dev->id[85] = (qc->dev->id[85] & ~(1 << 5)) | (wce << 5);
+		sd_set_WCE(dev, wce);
+	}
+
+	/*
 	 * Set flags so that all registers will be written,
 	 * and pass on write indication (used for PIO/DMA
 	 * setup.)
--- linux/drivers/scsi/sd.c.orig	2005-12-12 18:50:34.000000000 -0500
+++ linux/drivers/scsi/sd.c	2006-03-06 15:09:44.000000000 -0500
@@ -1828,5 +1828,12 @@
 		unregister_blkdev(sd_major(i), "sd");
 }
 
+void sd_set_WCE (struct device *dev, int off_on)
+{
+	struct scsi_disk *sdkp = dev_get_drvdata(dev);
+	sdkp->WCE = off_on;
+}
+EXPORT_SYMBOL(sd_set_WCE);
+
 module_init(init_sd);
 module_exit(exit_sd);

Re: [RFT] major libata update

[Jeff Garzik]

Mark Lord wrote:
> Tejun Heo wrote:
>> ..
>> Right.  Also, we need to snoop some passthrough commands and 
>> revalidate/reconfigure when configuration is explicitly changed.
> 
> Once the sysfs attr's actually work, I'll probably re-do my hdparm
> stuff to detect use them when available, avoiding the need for libata
> to snoop passthrough commands.  But Jeff may (or not) want to snoop anyway.

We _have_ to snoop some commands, like SET FEATURES - XFER MODE.

Its just a given... you gotta either maintain cached state, or you gotta 
notice when its stale.

	Jeff

Re: [RFT] major libata update

[Mark Lord]

Jeff Garzik wrote:
>
>> Once the sysfs attr's actually work, I'll probably re-do my hdparm
>> stuff to detect use them when available, avoiding the need for libata
>> to snoop passthrough commands.  But Jeff may (or not) want to snoop 
>> anyway.
> 
> We _have_ to snoop some commands, like SET FEATURES - XFER MODE.
> 
> Its just a given... you gotta either maintain cached state, or you gotta 
> notice when its stale.

Ah then, I suppose libata might as well snoop the write-cache on/off
(SET FEATURES) command as well.  We need some kind of API or something
to avoid the nasty layering violation that my hack uses.. I wonder if
we can just do a revalidate disk or something?

Cheers

Re: [RFT] major libata update

[Jeff Garzik]

Mark Lord wrote:
> Jeff Garzik wrote:
>>
>>> Once the sysfs attr's actually work, I'll probably re-do my hdparm
>>> stuff to detect use them when available, avoiding the need for libata
>>> to snoop passthrough commands.  But Jeff may (or not) want to snoop 
>>> anyway.
>>
>> We _have_ to snoop some commands, like SET FEATURES - XFER MODE.
>>
>> Its just a given... you gotta either maintain cached state, or you 
>> gotta notice when its stale.
> 
> Ah then, I suppose libata might as well snoop the write-cache on/off
> (SET FEATURES) command as well.  We need some kind of API or something
> to avoid the nasty layering violation that my hack uses.. I wonder if
> we can just do a revalidate disk or something?

Either way.  Revalidation falls under the "notice when its stale" 
category above, certainly a viable solution.

	Jeff

Re: [RFT] major libata update

[Ric Wheeler]

Mark Lord wrote:

> Tejun Heo wrote:
>
>> ..
>> Right.  Also, we need to snoop some passthrough commands and 
>> revalidate/reconfigure when configuration is explicitly changed.
>
>
> Once the sysfs attr's actually work, I'll probably re-do my hdparm
> stuff to detect use them when available, avoiding the need for libata
> to snoop passthrough commands.  But Jeff may (or not) want to snoop 
> anyway.
>
> As a workaround for now, Ric is using the ugly hack attached here.
>
> Cheers


With this patch, I can get the write cache to change properly, but I 
still see rates that are "too fast" until I disable the queuing as 
well.  I think that the barriers are supposed to work with NCQ enabled, 
but might there be a trace of the old "disable" barrier support if 
queuing is on left somewhere?

Also, disabling the queue via setting 
/sys/class/scsi_disk/4\:0\:0\:0/device/queue_depth does not seem to take 
effect unless I unmount the file system & remount.  I will  poke around 
to see if reiserfs is disabling with queuing enabled & only reenables on 
a fresh mount...

ric

Re: [RFT] major libata update

[Tejun Heo]

Ric Wheeler wrote:
> 
> Mark Lord wrote:
> 
>> Tejun Heo wrote:
>>
>>> ..
>>> Right.  Also, we need to snoop some passthrough commands and 
>>> revalidate/reconfigure when configuration is explicitly changed.
>>
>>
>> Once the sysfs attr's actually work, I'll probably re-do my hdparm
>> stuff to detect use them when available, avoiding the need for libata
>> to snoop passthrough commands.  But Jeff may (or not) want to snoop 
>> anyway.
>>
>> As a workaround for now, Ric is using the ugly hack attached here.
>>
>> Cheers
> 
> 
> With this patch, I can get the write cache to change properly, but I 
> still see rates that are "too fast" until I disable the queuing as 
> well.  I think that the barriers are supposed to work with NCQ enabled, 
> but might there be a trace of the old "disable" barrier support if 
> queuing is on left somewhere?

I think the easiest way to verify basic things are working is by booting 
the machine with write cache enabled.

> Also, disabling the queue via setting 
> /sys/class/scsi_disk/4\:0\:0\:0/device/queue_depth does not seem to take 
> effect unless I unmount the file system & remount.  I will  poke around 
> to see if reiserfs is disabling with queuing enabled & only reenables on 
> a fresh mount...

I don't think you're supposed to change cache setting underneath a live FS.

-- 
tejun

Re: [RFT] major libata update

[Ric Wheeler]

Tejun Heo wrote:

>>> Once the sysfs attr's actually work, I'll probably re-do my hdparm
>>> stuff to detect use them when available, avoiding the need for libata
>>> to snoop passthrough commands.  But Jeff may (or not) want to snoop 
>>> anyway.
>>>
>>> As a workaround for now, Ric is using the ugly hack attached here.
>>>
>>> Cheers
>>
>>
>>
>> With this patch, I can get the write cache to change properly, but I 
>> still see rates that are "too fast" until I disable the queuing as 
>> well.  I think that the barriers are supposed to work with NCQ 
>> enabled, but might there be a trace of the old "disable" barrier 
>> support if queuing is on left somewhere?
>
>
> I think the easiest way to verify basic things are working is by 
> booting the machine with write cache enabled.

You can measure the rate with barriers enabled or not on a per file 
system instance (ie, mount barrier=none) to get a quick baseline. This 
rate has been an extremely accurate way for us to diagnose big issues 
(like the barrier is just not working - you get hundreds of files/sec 
instead of tens of files/sec ;-)) or subtle ones like regressions in 
disk firmware.

For us, the broader issue is that the rest of the company only uses 
drives with write cache disabled & as the small group, we have to dip 
into their manufacturing stream and use the parts as the rest of the 
company dictates.  Being able to toggle the write cache (before mounting 
a file system) is one of the weird edge cases that few others care about ;-)

>
>> Also, disabling the queue via setting 
>> /sys/class/scsi_disk/4\:0\:0\:0/device/queue_depth does not seem to 
>> take effect unless I unmount the file system & remount.  I will  poke 
>> around to see if reiserfs is disabling with queuing enabled & only 
>> reenables on a fresh mount...
>
>
> I don't think you're supposed to change cache setting underneath a 
> live FS.


Makes sense - I don't see logic in reiserfs at least that looks at (or 
knows) about anything other than "did my barrier op" fail.  When that 
happens, it should log a "disabling barriers for /dev/sdX" and leave 
them disabled.  I did not see that message so I suspect that we still 
have some lower level mechanism. 

A different discussion is what we should do or log when we detect this - 
i.e., write cache enabled and barrier ops not supported (disable write 
cache?  log a scarier message? ignore it?).  Today's behavior is 
probably what most home users want (run as fast as I can, absolute data 
integrity over power failures not a big deal) but not the right behavior 
for critical data (i.e., forget performance, make sure my data is always 
safe ).

I will keep poking at this today to try and clarify things.

Re: [RFT] major libata update

[Mark Lord]

> 
> A different discussion is what we should do or log when we detect this - i.e., write cache enabled and barrier ops not supported (disable write cache?  log a scarier message? ignore it?).  Today's behavior is probably what most home users want (run as fast as I can, absolute data integrity over power failures not a big deal) but not the right behavior for critical data (i.e., forget performance, make sure my data is always safe ). 

Yes, 99.99% of Linux users would really complain like mad
if the *kernel* took over the *policy* decision of disabling
write-caching.  The long-term kernel rule has always been,
leave *policy* to user-space.

Cheers
-- 
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

Re: [RFT] major libata update

[Ric Wheeler]

Mark Lord wrote:
>>
>> A different discussion is what we should do or log when we detect this 
>> - i.e., write cache enabled and barrier ops not supported (disable 
>> write cache?  log a scarier message? ignore it?).  Today's behavior is 
>> probably what most home users want (run as fast as I can, absolute 
>> data integrity over power failures not a big deal) but not the right 
>> behavior for critical data (i.e., forget performance, make sure my 
>> data is always safe ). 
> 
> Yes, 99.99% of Linux users would really complain like mad
> if the *kernel* took over the *policy* decision of disabling
> write-caching.  The long-term kernel rule has always been,
> leave *policy* to user-space.
> 
> Cheers

Agreed - I think that only challenge is for us to make sure that the messages in 
the upstream kernel are informative enough to let people know what this means 
and some level of their exposure.

Maybe the "enterprise" distro install programs would want to treat write barrier 
  like we do support for 3D video card acceleration with a good overview & let 
the user configure the system as best suits their needs.  I think that it is 
still quite difficult to get right today for most casual users...

ric

Re: [RFT] major libata update

[Jens Axboe]

On Thu, May 18 2006, Ric Wheeler wrote:
> 
> Mark Lord wrote:
> >>
> >>A different discussion is what we should do or log when we detect this 
> >>- i.e., write cache enabled and barrier ops not supported (disable 
> >>write cache?  log a scarier message? ignore it?).  Today's behavior is 
> >>probably what most home users want (run as fast as I can, absolute 
> >>data integrity over power failures not a big deal) but not the right 
> >>behavior for critical data (i.e., forget performance, make sure my 
> >>data is always safe ). 
> >
> >Yes, 99.99% of Linux users would really complain like mad
> >if the *kernel* took over the *policy* decision of disabling
> >write-caching.  The long-term kernel rule has always been,
> >leave *policy* to user-space.
> >
> >Cheers
> 
> Agreed - I think that only challenge is for us to make sure that the 
> messages in the upstream kernel are informative enough to let people know 
> what this means and some level of their exposure.
> 
> Maybe the "enterprise" distro install programs would want to treat write 
> barrier like we do support for 3D video card acceleration with a good 
>  overview & let the user configure the system as best suits their needs.  I 
> think that it is still quite difficult to get right today for most casual 
> users...

Yep certainly something needs to be done, it's currently far too
unlikely that:

a) the user even sees the barrier message from the file system, telling
   them that the fs turned it off

and

b) he/she knows the implications of such a message.

This is data integrity after all, we probably should be a little more
careful.

-- 
Jens Axboe

Re: [RFT] major libata update

[Jeff Garzik]

Tejun Heo wrote:
> * Those spurious FISes are actively setting the I bit requesting 
> interrupt explicitly.  Those are not innocent status update FISes.  And 

FWIW, most firmwares probably derive the value of 'I' directly from the 
nIEN bit.  In our situation, it would be unusual for 'I' to be cleared. 
  'I' is really irrelevant for advanced, FIS-based controllers in any case.

	Jeff

Re: [RFT] major libata update

[Jeff Garzik]

Tejun Heo wrote:
> Jeff Garzik wrote:
>> As another side note, command coalescing is worth experimenting with.
> 
> Might be, but I'm a bit skeptical.  We might lose more to added latency.

Yes, that's the biggest item of note.

Still, it would be worth turning on if interrupts exceed a certain 
threshold, such as 1000/second.  Each interrupt handler setup and call, 
even with PCI MSI, has a certain fixed amount overhead.  Command 
coalescing can mitigate that overhead.

	Jeff

Re: [RFT] major libata update

[Ric Wheeler]

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



Tejun Heo wrote:

> Ric Wheeler wrote:
>
>> c001n01: 0: [  OK  ]
>> ata3: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
>> 0x2000000f)
>> ata3: spurious SDB FIS 004040a1:10000000 ap->qc_active=2000000f 
>> qc_active=2000000f
>> ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
>> 0xfffc0)
>> ata1: spurious SDB FIS 004040a1:00000020 ap->qc_active=000fffc0 
>> qc_active=000fffc0
>> ata2: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
>> 0x7fffff3f)
>> ata2: spurious SDB FIS 004040a1:00000080 ap->qc_active=7fffff3f 
>> qc_active=7fffff3f
>> ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
>> 0x7fffff9f)
>> ata1: spurious SDB FIS 004040a1:00000040 ap->qc_active=7fffff9f 
>> qc_active=7fffff9f
>> c001n03: 0: [  OK  ]
>> ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
>> 0x7ffe7fff)
>> ata1: spurious SDB FIS 004040a1:00010000 ap->qc_active=7ffe7fff 
>> qc_active=7ffe7fff
>> c001n04: 0: [  OK  ]
>> ata3: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
>> 0x31)
>> ata3: spurious SDB FIS 004040a1:00000008 ap->qc_active=00000031 
>> qc_active=00000031
>> ata3: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
>> 0x7fff800f)
>> ata3: spurious SDB FIS 004040a1:00004000 ap->qc_active=7fff800f 
>> qc_active=7fff800f
>> c001n06: 1: [ FAIL ]
>> c001n07: 0: [  OK  ]
>> ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
>> 0x7ffffcff)
>> ata1: spurious SDB FIS 004040a1:00000200 ap->qc_active=7ffffcff 
>> qc_active=7ffffcff
>> c001n08: 0: [  OK  ]
>> ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 
>> 0x4fffffff)
>> ata1: spurious SDB FIS 004040a1:20000000 ap->qc_active=4fffffff 
>> qc_active=4fffffff
>
>
> Hmmm.. The drive is issuing SDB FIS which completes already completed 
> tags.  This could be dangerous.  Depending on timing, it might end up 
> finishing a command which occupied the slot which hasn't been 
> processed yet.  If a drive does this, NCQ shouldn't be enabled for 
> it.  Can you post full boot dmesg?
>
> I'm attaching slightly modified version of the debug patch just in 
> case.  It will probably show the same thing.
>
>  
>
This is the same box that had the barrier issue, but I will repost the 
boot.msg for anyone paying attention just to one thread ;-)

ric


[-- Attachment #2: boot.msg --]
[-- Type: text/plain, Size: 52682 bytes --]

Cannot find map file.
No module symbols loaded - kernel modules not enabled.

Cannot build symbol table - disabling symbol lookups
klogd 1.4.1, log source = ksyslog started.
00000, GSI 0-23
<6>ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
<6>ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
<7>ACPI: IRQ0 used by override.
<7>ACPI: IRQ2 used by override.
<7>ACPI: IRQ9 used by override.
<4>Enabling APIC mode:  Flat.  Using 1 I/O APICs
<6>Using ACPI (MADT) for SMP configuration information
<4>Allocating PCI resources starting at 40000000 (gap: 3f700000:a0900000)
<4>Built 1 zonelists
<5>Kernel command line: root=/dev/md3 elevator=as console=ttyS0,9600,8n1 console=tty0 apic BOOT_IMAGE=production-m
<7>mapped APIC to ffffd000 (fee00000)
<7>mapped IOAPIC to ffffc000 (fec00000)
<6>Enabling fast FPU save and restore... done.
<6>Enabling unmasked SIMD FPU exception support... done.
<6>Initializing CPU#0
<4>PID hash table entries: 4096 (order: 12, 16384 bytes)
<4>Detected 2800.792 MHz processor.
<6>Using pmtmr for high-res timesource
<4>Console: colour VGA+ 80x25
<4>Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
<4>Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
<6>Memory: 898240k/917504k available (2014k kernel code, 18720k reserved, 632k data, 184k init, 0k highmem)
<4>Checking if this processor honours the WP bit even in supervisor mode... Ok.
<4>Calibrating delay using timer specific routine.. 5607.13 BogoMIPS (lpj=11214265)
<4>Mount-cache hash table entries: 512
<7>CPU: After generic identify, caps: bfebfbff 00100000 00000000 00000000 0000441d 00000000 00000000
<7>CPU: After vendor identify, caps: bfebfbff 00100000 00000000 00000000 0000441d 00000000 00000000
<4>monitor/mwait feature present.
<4>using mwait in idle threads.
<6>CPU: Trace cache: 12K uops, L1 D cache: 16K
<6>CPU: L2 cache: 1024K
<7>CPU: After all inits, caps: bfebfbff 00100000 00000000 00000180 0000441d 00000000 00000000
<4>CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 01
<6>Checking 'hlt' instruction... OK.
<6>SMP alternatives: switching to UP code
<6>Freeing SMP alternatives: 0k freed
<4>ENABLING IO-APIC IRQs
<6>..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
<6>checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
<6>Freeing initrd memory: 7738k freed
<6>NET: Registered protocol family 16
<6>ACPI: bus type pci registered
<6>PCI: Using MMCONFIG
<4>Setting up standard PCI resources
<6>ACPI: Subsystem revision 20060127
<6>ACPI: Interpreter enabled
<6>ACPI: Using IOAPIC for interrupt routing
<6>ACPI: PCI Root Bridge [PCI0] (0000:00)
<7>PCI: Probing PCI hardware (bus 00)
<7>Boot video device is 0000:00:02.0
<4>PCI: PXH quirk detected, disabling MSI for SHPC device
<4>PCI: PXH quirk detected, disabling MSI for SHPC device
<6>PCI: Transparent bridge - 0000:00:1e.0
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P1AB.PXHA._PRT]
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P1AB.PXHB._PRT]
<4>ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 10 *12 14 15)
<4>ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 7 9 10 12 14 15)
<4>ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 *7 9 10 12 14 15)
<4>ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 *10 12 14 15)
<4>ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 10 12 14 15) *0, disabled.
<4>ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 10 12 14 15) *0, disabled.
<4>ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 7 9 10 12 14 15) *0, disabled.
<4>ACPI: PCI Interrupt Link [LNK1] (IRQs *3 4 5 7 9 10 12 14 15)
<5>SCSI subsystem initialized
<6>PCI: Using ACPI for IRQ routing
<6>PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
<4>PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
<6>PCI: Bridge: 0000:01:00.0
<6>  IO window: c000-cfff
<6>  MEM window: d0000000-d00fffff
<6>  PREFETCH window: disabled.
<6>PCI: Bridge: 0000:01:00.2
<6>  IO window: d000-dfff
<6>  MEM window: d0100000-d01fffff
<6>  PREFETCH window: disabled.
<6>PCI: Bridge: 0000:00:01.0
<6>  IO window: c000-dfff
<6>  MEM window: d0000000-d02fffff
<6>  PREFETCH window: disabled.
<6>PCI: Bridge: 0000:00:1e.0
<6>  IO window: disabled.
<6>  MEM window: disabled.
<6>  PREFETCH window: disabled.
<6>ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
<7>PCI: Setting latency timer of device 0000:00:01.0 to 64
<7>PCI: Setting latency timer of device 0000:01:00.0 to 64
<7>PCI: Setting latency timer of device 0000:01:00.2 to 64
<7>PCI: Setting latency timer of device 0000:00:1e.0 to 64
<6>NET: Registered protocol family 2
<4>IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
<4>TCP established hash table entries: 131072 (order: 7, 524288 bytes)
<4>TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
<6>TCP: Hash tables configured (established 131072 bind 65536)
<6>TCP reno registered
<6>IA-32 Microcode Update Driver: v1.14 <tigran@veritas.com>
<6>io scheduler noop registered
<6>io scheduler anticipatory registered (default)
<6>io scheduler deadline registered
<6>io scheduler cfq registered
<6>Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
<6>serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
<4>RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
<6>Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
<6>ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
<7>Probing IDE interface ide0...
<7>Probing IDE interface ide1...
<7>libata version 1.30 loaded.
<7>ahci 0000:00:1f.2: version 1.3
<6>ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 17
<7>PCI: Setting latency timer of device 0000:00:1f.2 to 64
<6>ahci 0000:00:1f.2: AHCI 0001.0000 32 slots 4 ports 1.5 Gbps 0xf impl IDE mode
<6>ahci 0000:00:1f.2: flags: 64bit ncq pm led 
<6>ata1: SATA max UDMA/133 cmd 0xF8802100 ctl 0x0 bmdma 0x0 irq 17
<6>ata2: SATA max UDMA/133 cmd 0xF8802180 ctl 0x0 bmdma 0x0 irq 17
<6>ata3: SATA max UDMA/133 cmd 0xF8802200 ctl 0x0 bmdma 0x0 irq 17
<6>ata4: SATA max UDMA/133 cmd 0xF8802280 ctl 0x0 bmdma 0x0 irq 17
<6>ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
<7>ata1.00: cfg 49:2f00 82:7c6b 83:7f09 84:4063 85:7c49 86:3e01 87:4063 88:007f
<6>ata1.00: ATA-7, max UDMA/133, 625142448 sectors: LBA48 NCQ (depth 31/32)
<6>ata1.00: configured for UDMA/133
<6>scsi0 : ahci
<6>ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
<7>ata2.00: cfg 49:2f00 82:7c6b 83:7f09 84:4063 85:7c49 86:3e01 87:4063 88:007f
<6>ata2.00: ATA-7, max UDMA/133, 625142448 sectors: LBA48 NCQ (depth 31/32)
<6>ata2.00: configured for UDMA/133
<6>scsi1 : ahci
<6>ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
<7>ata3.00: cfg 49:2f00 82:7c6b 83:7f09 84:4063 85:7c49 86:3e01 87:4063 88:007f
<6>ata3.00: ATA-7, max UDMA/133, 625142448 sectors: LBA48 NCQ (depth 31/32)
<6>ata3.00: configured for UDMA/133
<6>scsi2 : ahci
<6>ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
<7>ata4.00: cfg 49:2f00 82:7c6b 83:7f09 84:4063 85:7c49 86:3e01 87:4063 88:007f
<6>ata4.00: ATA-7, max UDMA/133, 625142448 sectors: LBA48 NCQ (depth 31/32)
<6>ata4.00: configured for UDMA/133
<6>scsi3 : ahci
<5>  Vendor: ATA       Model: Maxtor 7B320S0    Rev: BANC
<5>  Type:   Direct-Access                      ANSI SCSI revision: 05
<5>  Vendor: ATA       Model: Maxtor 7B320S0    Rev: BANC
<5>  Type:   Direct-Access                      ANSI SCSI revision: 05
<5>  Vendor: ATA       Model: Maxtor 7B320S0    Rev: BANC
<5>  Type:   Direct-Access                      ANSI SCSI revision: 05
<5>  Vendor: ATA       Model: Maxtor 7B320S0    Rev: BANC
<5>  Type:   Direct-Access                      ANSI SCSI revision: 05
<5>SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
<5>sda: Write Protect is off
<7>sda: Mode Sense: 00 3a 00 00
<5>SCSI device sda: drive cache: write through
<5>SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
<5>sda: Write Protect is off
<7>sda: Mode Sense: 00 3a 00 00
<5>SCSI device sda: drive cache: write through
<6> sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 sda13 sda14 >
<5>sd 0:0:0:0: Attached scsi disk sda
<5>SCSI device sdb: 625142448 512-byte hdwr sectors (320073 MB)
<5>sdb: Write Protect is off
<7>sdb: Mode Sense: 00 3a 00 00
<5>SCSI device sdb: drive cache: write through
<5>SCSI device sdb: 625142448 512-byte hdwr sectors (320073 MB)
<5>sdb: Write Protect is off
<7>sdb: Mode Sense: 00 3a 00 00
<5>SCSI device sdb: drive cache: write through
<6> sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12 sdb13 sdb14 >
<5>sd 1:0:0:0: Attached scsi disk sdb
<5>SCSI device sdc: 625142448 512-byte hdwr sectors (320073 MB)
<5>sdc: Write Protect is off
<7>sdc: Mode Sense: 00 3a 00 00
<5>SCSI device sdc: drive cache: write through
<5>SCSI device sdc: 625142448 512-byte hdwr sectors (320073 MB)
<5>sdc: Write Protect is off
<7>sdc: Mode Sense: 00 3a 00 00
<5>SCSI device sdc: drive cache: write through
<6> sdc: sdc1 sdc2 sdc3 sdc4 < sdc5 sdc6 sdc7 sdc8 sdc9 sdc10 sdc11 sdc12 sdc13 sdc14 >
<5>sd 2:0:0:0: Attached scsi disk sdc
<5>SCSI device sdd: 625142448 512-byte hdwr sectors (320073 MB)
<5>sdd: Write Protect is off
<7>sdd: Mode Sense: 00 3a 00 00
<5>SCSI device sdd: drive cache: write through
<5>SCSI device sdd: 625142448 512-byte hdwr sectors (320073 MB)
<5>sdd: Write Protect is off
<7>sdd: Mode Sense: 00 3a 00 00
<5>SCSI device sdd: drive cache: write through
<6> sdd: sdd1 sdd2 sdd3 sdd4 < sdd5 sdd6 sdd7 sdd8 sdd9 sdd10 sdd11 sdd12 sdd13 sdd14 >
<5>sd 3:0:0:0: Attached scsi disk sdd
<6>serio: i8042 AUX port at 0x60,0x64 irq 12
<6>serio: i8042 KBD port at 0x60,0x64 irq 1
<6>mice: PS/2 mouse device common for all mice
<6>i2c /dev entries driver
<6>md: raid1 personality registered for level 1
<6>md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
<6>md: bitmap version 4.39
<6>TCP bic registered
<6>NET: Registered protocol family 1
<4>Using IPI Shortcut mode
<4>ACPI wakeup devices: 
<4>PCI0 PEX0 PEX1 PEX2 PEX3 HUB0 PXHA PXHB UAR1 USB0 USB1 USB2 USB3 USBE AC97 AZAL 
<6>ACPI: (supports S0 S1 S4 S5)
<6>md: Autodetecting RAID arrays.
<6>md: autorun ...
<6>md: considering sdd8 ...
<6>md:  adding sdd8 ...
<4>md: sdd7 has different UUID to sdd8
<4>md: sdd6 has different UUID to sdd8
<4>md: sdd5 has different UUID to sdd8
<4>md: sdd3 has different UUID to sdd8
<6>md:  adding sdc8 ...
<4>md: sdc7 has different UUID to sdd8
<4>md: sdc6 has different UUID to sdd8
<4>md: sdc5 has different UUID to sdd8
<4>md: sdc3 has different UUID to sdd8
<6>md:  adding sdb8 ...
<4>md: sdb7 has different UUID to sdd8
<4>md: sdb6 has different UUID to sdd8
<4>md: sdb5 has different UUID to sdd8
<4>md: sdb3 has different UUID to sdd8
<6>md:  adding sda8 ...
<4>md: sda7 has different UUID to sdd8
<4>md: sda6 has different UUID to sdd8
<4>md: sda5 has different UUID to sdd8
<4>md: sda3 has different UUID to sdd8
<6>md: created md8
<6>md: bind<sda8>
<6>md: bind<sdb8>
<6>md: bind<sdc8>
<6>md: bind<sdd8>
<6>md: running: <sdd8><sdc8><sdb8><sda8>
<6>raid1: raid set md8 active with 4 out of 4 mirrors
<6>md: considering sdd7 ...
<6>md:  adding sdd7 ...
<4>md: sdd6 has different UUID to sdd7
<4>md: sdd5 has different UUID to sdd7
<4>md: sdd3 has different UUID to sdd7
<6>md:  adding sdc7 ...
<4>md: sdc6 has different UUID to sdd7
<4>md: sdc5 has different UUID to sdd7
<4>md: sdc3 has different UUID to sdd7
<6>md:  adding sdb7 ...
<4>md: sdb6 has different UUID to sdd7
<4>md: sdb5 has different UUID to sdd7
<4>md: sdb3 has different UUID to sdd7
<6>md:  adding sda7 ...
<4>md: sda6 has different UUID to sdd7
<4>md: sda5 has different UUID to sdd7
<4>md: sda3 has different UUID to sdd7
<6>md: created md7
<6>md: bind<sda7>
<6>md: bind<sdb7>
<6>md: bind<sdc7>
<6>md: bind<sdd7>
<6>md: running: <sdd7><sdc7><sdb7><sda7>
<6>raid1: raid set md7 active with 4 out of 4 mirrors
<6>md: considering sdd6 ...
<6>md:  adding sdd6 ...
<4>md: sdd5 has different UUID to sdd6
<4>md: sdd3 has different UUID to sdd6
<6>md:  adding sdc6 ...
<4>md: sdc5 has different UUID to sdd6
<4>md: sdc3 has different UUID to sdd6
<6>md:  adding sdb6 ...
<4>md: sdb5 has different UUID to sdd6
<4>md: sdb3 has different UUID to sdd6
<6>md:  adding sda6 ...
<4>md: sda5 has different UUID to sdd6
<4>md: sda3 has different UUID to sdd6
<6>md: created md6
<6>md: bind<sda6>
<6>md: bind<sdb6>
<6>md: bind<sdc6>
<6>md: bind<sdd6>
<6>md: running: <sdd6><sdc6><sdb6><sda6>
<6>raid1: raid set md6 active with 4 out of 4 mirrors
<6>md: considering sdd5 ...
<6>md:  adding sdd5 ...
<4>md: sdd3 has different UUID to sdd5
<6>md:  adding sdc5 ...
<4>md: sdc3 has different UUID to sdd5
<6>md:  adding sdb5 ...
<4>md: sdb3 has different UUID to sdd5
<6>md:  adding sda5 ...
<4>md: sda3 has different UUID to sdd5
<6>md: created md5
<6>md: bind<sda5>
<6>md: bind<sdb5>
<6>md: bind<sdc5>
<6>md: bind<sdd5>
<6>md: running: <sdd5><sdc5><sdb5><sda5>
<6>raid1: raid set md5 active with 4 out of 4 mirrors
<6>md: considering sdd3 ...
<6>md:  adding sdd3 ...
<6>md:  adding sdc3 ...
<6>md:  adding sdb3 ...
<6>md:  adding sda3 ...
<6>md: created md3
<6>md: bind<sda3>
<6>md: bind<sdb3>
<6>md: bind<sdc3>
<6>md: bind<sdd3>
<6>md: running: <sdd3><sdc3><sdb3><sda3>
<6>raid1: raid set md3 active with 4 out of 4 mirrors
<6>md: ... autorun DONE.
<5>RAMDISK: Compressed image found at block 0
<4>VFS: Mounted root (ext2 filesystem).
<6>ipmi message handler version 39.0
<6>IPMI System Interface driver.
<6>ipmi: Found new BMC (man_id: 0x0019fd,  prod_id: 0x1426, dev_id: 0x00)
<4> IPMI KCS interface initialized
<6>ipmi_si: Found default KCS state machine at I/O address 0xca2
<6>ipmi device interface
<6>e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
<6>e100: Copyright(c) 1999-2005 Intel Corporation
<6>Intel(R) PRO/1000 Network Driver - version 7.0.33-k2
<6>Copyright (c) 1999-2005 Intel Corporation.
<6>ACPI: PCI Interrupt 0000:02:06.0[A] -> GSI 19 (level, low) -> IRQ 17
<6>e1000: 0000:02:06.0: e1000_probe: (PCI-X:133MHz:64-bit) 00:e0:81:64:5f:de
<6>e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
<6>ACPI: PCI Interrupt 0000:02:06.1[B] -> GSI 18 (level, low) -> IRQ 18
<6>e1000: 0000:02:06.1: e1000_probe: (PCI-X:133MHz:64-bit) 00:e0:81:64:5f:df
<6>e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
<6>ACPI: PCI Interrupt 0000:03:07.0[A] -> GSI 17 (level, low) -> IRQ 19
<6>e1000: 0000:03:07.0: e1000_probe: (PCI-X:133MHz:64-bit) 00:e0:81:64:5f:e0
<6>e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
<6>ACPI: PCI Interrupt 0000:03:07.1[B] -> GSI 16 (level, low) -> IRQ 16
<6>e1000: 0000:03:07.1: e1000_probe: (PCI-X:133MHz:64-bit) 00:e0:81:64:5f:e1
<6>e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection
<5>ReiserFS: md8: found reiserfs format "3.6" with standard journal
<5>ReiserFS: md8: using ordered data mode
<5>ReiserFS: md8: journal params: device md8, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
<5>ReiserFS: md8: checking transaction log (md8)
<5>ReiserFS: md8: Using r5 hash to sort names
<5>ReiserFS: md3: found reiserfs format "3.6" with standard journal
<5>ReiserFS: md3: using ordered data mode
<5>ReiserFS: md3: journal params: device md3, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
<5>ReiserFS: md3: checking transaction log (md3)
<5>ReiserFS: md3: Using r5 hash to sort names
<4>VFS: Mounted root (reiserfs filesystem) readonly.
<5>Trying to move old root to /initrd ... /initrd does not exist. Ignored.
<5>Unmounting old root
<5>Trying to free ramdisk memory ... okay
<6>Freeing unused kernel memory: 184k freed
<6>md: Autodetecting RAID arrays.
<6>md: autorun ...
<6>md: ... autorun DONE.
<5>ReiserFS: md7: found reiserfs format "3.6" with standard journal
<5>ReiserFS: md7: using ordered data mode
<5>ReiserFS: md7: journal params: device md7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
<5>ReiserFS: md7: checking transaction log (md7)
<5>ReiserFS: md7: Using r5 hash to sort names
<5>ReiserFS: md8: found reiserfs format "3.6" with standard journal
<5>ReiserFS: md8: using ordered data mode
<5>ReiserFS: md8: journal params: device md8, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
<5>ReiserFS: md8: checking transaction log (md8)
<5>ReiserFS: md8: Using r5 hash to sort names
Kernel logging (ksyslog) stopped.
Kernel log daemon terminating.

Boot logging started on /dev/tty1(/dev/console) at Tue May 16 16:28:51 2006

Master Resource Control: previous runlevel: N, switching to runlevel: 3
<notice>start services (starting_services random iterator firewall)
Logging the start of the bootdone
Initializing random number generatordone
<notice>startproc: execve (/usr/bin/IterServ) [ /usr/bin/IterServ ], [ CONSOLE=/dev/console TERM=linux SHELL=/bin/sh progress=20 INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/tty1 COLUMNS=80 PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin RUNLEVEL=3 PWD=/ PREVLEVEL=N LINES=25 HOME=/ SHLVL=2 BOOT_IMAGE=production-m sscripts=38 _=/sbin/startproc DAEMON=/usr/bin/IterServ ]
Starting iterator daemondone
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
<notice>exit status of (starting_services random iterator firewall) is (0 0 0 0)
<notice>start services (network)
Setting up network interfaces:
    lo       
    lo        IP address: 127.0.0.1/8   
done    eth0      device: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
    eth0      Startmode is 'manual'
skipped    eth1      device: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
    eth1      Startmode is 'manual'
skipped    eth2      device: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
    eth2      IP address: 10.241.28.82/29   
Shutting down external SSH daemondone
Starting external SSH daemon<notice>startproc: execve (/usr/sbin/sshd_external) [ /usr/sbin/sshd_external -f /etc/ssh/sshd_config_external -o PidFile=/var/run/sshd_external.init.pid ], [ HWD_INTERFACE_0=eth2 CONSOLE=/dev/console HWD_HWDESC=eth2 TERM=linux SHELL=/bin/sh HWD_BUSID_0=0000:00:01.0 HWD_BUSNAME_2=pci HWD_BUSID_1=0000:01:00.0 HWD_BUSNAME_0=pci HWD_BUSID_2=0000:02:06.0 HWD_BUSNAME_1=pci HWD_VENDORID=0x8086 HWD_BUSID=0000:02:06.0 HWD_PRODUCTSUBID=0x1179 progress=24 HWD_CONFIG_N=1 INIT_VERSION=sysvinit-2.85 RUN_FROM_RC=yes REDIRECT=/dev/tty1 HWD_INTERFACEPATH=/sys/class/net/eth2 COLUMNS=80 HWD_DEVTYPE=eth HWD_ID=00:e0:81:64:5f:de HWD_BUSNAME=pci PATH=/sbin:/usr/sbin:/bin:/usr/bin:/etc/sysconfig/network/scripts RUNLEVEL=3 PWD=/etc/sysconfig/network PREVLEVEL=N LINES=25 HWD_HWDESCTYPE=interface HOME=/ SHLVL=6 BOOT_IMAGE=production-m HWD_CONFIG_0=eth2 HWD_BUS_N=3 sscripts=38 HWD_VENDORSUBID=0x8086 HWD_PRODUCTID=0x1079 HWD_INTERFACE_N=1 HWD_DEVICEPATH=/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:06.0 _=/sbin/startproc DAEMON=/usr/sbin/sshd_external ]
done
Shutting down external SSH daemon<notice>killproc: kill(5452,15)
done
Starting external SSH daemon<notice>startproc: execve (/usr/sbin/sshd_external) [ /usr/sbin/sshd_external -f /etc/ssh/sshd_config_external -o PidFile=/var/run/sshd_external.init.pid ], [ HWD_INTERFACE_0=eth2 CONSOLE=/dev/console HWD_HWDESC=eth2 TERM=linux SHELL=/bin/sh HWD_BUSID_0=0000:00:01.0 HWD_BUSNAME_2=pci HWD_BUSID_1=0000:01:00.0 HWD_BUSNAME_0=pci HWD_BUSID_2=0000:02:06.0 HWD_BUSNAME_1=pci HWD_VENDORID=0x8086 HWD_BUSID=0000:02:06.0 HWD_PRODUCTSUBID=0x1179 progress=24 HWD_CONFIG_N=1 INIT_VERSION=sysvinit-2.85 RUN_FROM_RC=yes REDIRECT=/dev/tty1 HWD_INTERFACEPATH=/sys/class/net/eth2 COLUMNS=80 HWD_DEVTYPE=eth HWD_ID=00:e0:81:64:5f:de HWD_BUSNAME=pci PATH=/sbin:/usr/sbin:/bin:/usr/bin:/etc/sysconfig/network/scripts RUNLEVEL=3 PWD=/etc/sysconfig/network PREVLEVEL=N LINES=25 HWD_HWDESCTYPE=interface HOME=/ SHLVL=6 BOOT_IMAGE=production-m HWD_CONFIG_0=eth2 HWD_BUS_N=3 sscripts=38 HWD_VENDORSUBID=0x8086 HWD_PRODUCTID=0x1079 HWD_INTERFACE_N=1 HWD_DEVICEPATH=/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:06.0 _=/sbin/startproc DAEMON=/usr/sbin/sshd_external ]
done
WARNING: pinging broadcast address
PING 10.241.28.87 (10.241.28.87) from 10.241.28.82 eth2: 56(84) bytes of data.

--- 10.241.28.87 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

grep: /etc/resolv.conf: No such file or directory
unix dgram connect: No such file or directory at /usr/lib/perl5/site_perl/5.8.3/Log/Agent/Channel/Syslog.pm line 119
no connection to syslog available at /usr/lib/perl5/site_perl/5.8.3/Log/Agent/Channel/Syslog.pm line 119
done    eth3      device: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
    eth3      No configuration found for eth3
unusedSetting up service network  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .done
<notice>exit status of (network) is (0)
<notice>start services (syslog)
Starting syslog services<notice>startproc: execve (/sbin/syslogd) [ /sbin/syslogd -a /var/lib/dhcp/dev/log ], [ CONSOLE=/dev/console TERM=linux SHELL=/bin/sh progress=25 INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/tty1 COLUMNS=80 PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin RUNLEVEL=3 PWD=/ PREVLEVEL=N LINES=25 HOME=/ SHLVL=2 BOOT_IMAGE=production-m sscripts=38 _=/sbin/startproc DAEMON=/sbin/syslogd ]
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@  syslogd: Can't bind unix unix socket to name: Address already in use

<notice>startproc: execve (/sbin/klogd) [ /sbin/klogd -c 1 -2 -x ], [ CONSOLE=/dev/console TERM=linux SHELL=/bin/sh progress=25 INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/tty1 COLUMNS=80 PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin RUNLEVEL=3 PWD=/ PREVLEVEL=N LINES=25 HOME=/ SHLVL=2 BOOT_IMAGE=production-m sscripts=38 _=/sbin/startproc DAEMON=/sbin/klogd ]
done
<notice>exit status of (syslog) is (0)
<notice>start services (smartd)
Generating /etc/smartd.conf: Disabling SMART on this node.
done<notice>exit status of (smartd) is (0)
<notice>start services (xinetd microcode_ctl microcode)
<notice>startproc: execve (/usr/sbin/xinetd) [ /usr/sbin/xinetd ], [ CONSOLE=/dev/console TERM=linux SHELL=/bin/sh progress=27 INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/tty1 COLUMNS=80 PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin RUNLEVEL=3 PWD=/ PREVLEVEL=N LINES=25 HOME=/ SHLVL=2 BOOT_IMAGE=production-m sscripts=38 _=/sbin/startproc DAEMON=/usr/sbin/xinetd ]
Checking/updating CPU microcodedone
Applying Intel IA32 Microcode update... 
done

Starting INET services. (xinetd)done
<notice>exit status of (xinetd microcode_ctl microcode) is (0 0 0)
<notice>start services (clusternet)
Starting cluster networking backgrounding
<notice>exit status of (clusternet) is (0)
<notice>start services (clusternetwait)
Waiting for clusternet IP detection to finish: waiting 1swaiting 2swaiting 3swaiting 4swaiting 5swaiting 6swaiting 7swaiting 8swaiting 9swaiting 10swaiting 11swaiting 12swaiting 13swaiting 14swaiting 15swaiting 16swaiting 17swaiting 18swaiting 19swaiting 20swaiting 21swaiting 22swaiting 23swaiting 24swaiting 25swaiting 26swaiting 27swaiting 28swaiting 29swaiting 30swaiting 31swaiting 32swaiting 33s<notice>startproc: execve (/usr/sbin/sshd) [ /usr/sbin/sshd -o PidFile=/var/run/sshd.init.pid ], [ CONSOLE=/dev/console TERM=linux SHELL=/bin/sh progress=30 INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/tty1 COLUMNS=80 PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin RUNLEVEL=3 PWD=/ PREVLEVEL=N LINES=25 HOME=/ SHLVL=4 BOOT_IMAGE=production-m sscripts=38 _=/sbin/startproc DAEMON=/usr/sbin/sshd ]
<notice>startproc: execve (/usr/sbin/ntpd) [ /usr/sbin/ntpd -p /var/lib/ntp/var/run/ntp/ntpd.pid -U ntp ], [ CONSOLE=/dev/console TERM=linux SHELL=/bin/sh progress=30 INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/tty1 COLUMNS=80 PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin RUNLEVEL=3 PWD=/ PREVLEVEL=N LINES=25 HOME=/ SHLVL=4 BOOT_IMAGE=production-m sscripts=38 OLDPWD=/var/local/bootstat _=/sbin/startproc DAEMON=/usr/sbin/ntpd ]
<notice>checkproc: /usr/sbin/ntpd 5859
waiting 34swaiting 35swaiting 36swaiting 37swaiting 38swaiting 39swaiting 40swaiting 41swaiting 42swaiting 43swaiting 44swaiting 45swaiting 46swaiting 47swaiting 48swaiting 49swaiting 50swaiting 51swaiting 52swaiting 53swaiting 54swaiting 55swaiting 56swaiting 57swaiting 58swaiting 59swaiting 60swaiting 61swaiting 62s<notice>killproc: kill(5813,15)
waiting 63s<notice>startproc: execve (/usr/sbin/sshd) [ /usr/sbin/sshd -o PidFile=/var/run/sshd.init.pid ], [ CONSOLE=/dev/console TERM=linux SHELL=/bin/sh progress=30 INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/tty1 COLUMNS=80 PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin RUNLEVEL=3 PWD=/ PREVLEVEL=N LINES=25 HOME=/ SHLVL=4 BOOT_IMAGE=production-m sscripts=38 _=/sbin/startproc DAEMON=/usr/sbin/sshd ]
Started cluster networking done
waiting 64s                               done
Change hostname to c001n01 done
<notice>exit status of (clusternetwait) is (0)
<notice>start services (connectemc)
Starting ConnectEMC <notice>startproc: execve (/opt/connectemc/connectemc) [ /opt/connectemc/connectemc ], [ CONSOLE=/dev/console TERM=linux SHELL=/bin/sh progress=32 INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/tty1 COLUMNS=80 PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin RUNLEVEL=3 PWD=/ PREVLEVEL=N LINES=25 HOME=/ SHLVL=2 BOOT_IMAGE=production-m sscripts=38 _=/sbin/startproc DAEMON=/opt/connectemc/connectemc ]
done
<notice>exit status of (connectemc) is (0)
<notice>start services (cron blobpartitions)
<notice>startproc: execve (/usr/sbin/cron) [ /usr/sbin/cron ], [ CONSOLE=/dev/console TERM=linux SHELL=/bin/sh progress=33 INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/tty1 COLUMNS=80 PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin RUNLEVEL=3 PWD=/ PREVLEVEL=N LINES=25 HOME=/ SHLVL=2 BOOT_IMAGE=production-m sscripts=38 _=/sbin/startproc DAEMON=/usr/sbin/cron ]
Starting CRON daemondone
Start activating blob partition /dev/cstardn10
Start activating blob partition /dev/cstardo10
Start activating blob partition /dev/cstardp10
Start activating blob partition /dev/cstardm10
Finish mounting blob partition /dev/cstardp10:done
Finish mounting blob partition /dev/cstardm10:done
Start activating blob partition /dev/cstardm11
Finish mounting blob partition /dev/cstardn10:done
Start activating blob partition /dev/cstardn11
Finish mounting blob partition /dev/cstardo10:done
Start activating blob partition /dev/cstardo11
Start activating blob partition /dev/cstardp11
Finish mounting blob partition /dev/cstardm11:done
Start activating blob partition /dev/cstardm12
Finish mounting blob partition /dev/cstardo11:done
Start activating blob partition /dev/cstardo12
Finish mounting blob partition /dev/cstardn11:done
Start activating blob partition /dev/cstardn12
Finish mounting blob partition /dev/cstardp11:done
Finish mounting blob partition /dev/cstardm12:done
Finish mounting blob partition /dev/cstardo12:done
Start activating blob partition /dev/cstardo13
Finish mounting blob partition /dev/cstardn12:done
Start activating blob partition /dev/cstardn13
Start activating blob partition /dev/cstardp12
Start activating blob partition /dev/cstardm13
Finish mounting blob partition /dev/cstardn13:done
Start activating blob partition /dev/cstardn14
Finish mounting blob partition /dev/cstardp12:done
Start activating blob partition /dev/cstardp13
Finish mounting blob partition /dev/cstardm13:done
Start activating blob partition /dev/cstardm14
Finish mounting blob partition /dev/cstardo13:done
Start activating blob partition /dev/cstardo14
Finish mounting blob partition /dev/cstardp13:done
Start activating blob partition /dev/cstardp14
Finish mounting blob partition /dev/cstardm14:done
Finish mounting blob partition /dev/cstardn14:done
Finish mounting blob partition /dev/cstardo14:done
Finish mounting blob partition /dev/cstardp14:done
<notice>exit status of (cron blobpartitions) is (0 0)
<notice>start services (inventory fragmentcounter)
Removing old imagesStarting fragment counter: done
<notice>exit status of (inventory fragmentcounter) is (0 0)
<notice>start services (filepool)
Starting FilePool software FATAL: Module ip_tables not found.
iptables v1.2.9: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
done
<notice>exit status of (filepool) is (0)
<notice>start services (successful_boot)
Setting GRUB for a production boot on disks:
    /dev/cstardm;/dev/cstardn;/dev/cstardo;/dev/cstardpdone
<notice>exit status of (successful_boot) is (0)
Master Resource Control: runlevel 3 has been reached
<notice>killproc: kill(4858,3)

Re: [RFT] major libata update

[Jeff Garzik]

Tejun Heo wrote:
> * can we make tags int and use -1 for invalid tag?  ATA_TAG_POISON looks 
> horrible when printed.

print with %x :)


> * it would be nice to have some framework to determine whether the 
> controller is receiving too many consecutive spurious interrupts.  Say, 
> 32 irqs in a row without intervening valid interrupts is a good reason 
> to be suspicious about stuck IRQ.  Freezing & resetting will resolve the 
> situation in most cases.

well, there is a screaming interrupt detector in the kernel...  Ideally 
  we should strive to make sure that only happens in debug scenarios :)


> * With NCQ, some drives generate spurious D2H FISes with I bit set as if 
> it were executing non-NCQ commands.  So, regardless of controller, we're 
> likely to see similar problems (but sil24 does all the protocol handling 
> and ignores such FISes by itself).  This can be combined with the above 
> freeze on too many spurious, I guess.

Interesting

	Jeff

Re: [RFT] major libata update

[Tejun Heo]

Jeff Garzik wrote:
> Tejun Heo wrote:
>> * can we make tags int and use -1 for invalid tag?  ATA_TAG_POISON 
>> looks horrible when printed.
> 
> print with %x :)
> 
> 
>> * it would be nice to have some framework to determine whether the 
>> controller is receiving too many consecutive spurious interrupts.  
>> Say, 32 irqs in a row without intervening valid interrupts is a good 
>> reason to be suspicious about stuck IRQ.  Freezing & resetting will 
>> resolve the situation in most cases.
> 
> well, there is a screaming interrupt detector in the kernel...  Ideally 
>  we should strive to make sure that only happens in debug scenarios :)

AFAIK, it disables the IRQ when triggered.  As stuck IRQ is something we 
see not so rarely with ATA devices, it would be better to deal with them 
more intelligently in libata, IMHO.  libata has ways to recover from 
most of those situations.

>> * With NCQ, some drives generate spurious D2H FISes with I bit set as 
>> if it were executing non-NCQ commands.  So, regardless of controller, 
>> we're likely to see similar problems (but sil24 does all the protocol 
>> handling and ignores such FISes by itself).  This can be combined with 
>> the above freeze on too many spurious, I guess.
> 
> Interesting

D2H is interesting but the spurious SDB FIS Ric is reporting is scary. 
I hope something else is wrong.  :(

-- 
tejun

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

[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

[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

[PATCH 1/1] libata: use polling pio for identify device

[Albert Lee]

Use polling pio for identify device.
This can save some time to detect the phantom device 1 during boot.

Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
---
For the phantom slave device (found with some IBM DVD-RAM drive and
Intel ICHx chip), irq-pio has to wait 30 seconds timeout to detect them.

Use polling pio can detect the phantom slave quicker. (Verified ok by Tejun.)

Patch again the current upstream branch (b74ba22f030eb7ab88f7d8954ad18ecc0ac5ce3c).
For your review, thanks.

--- upstream/drivers/scsi/libata-core.c	2006-05-22 10:04:12.000000000 +0800
+++ polling_identify/drivers/scsi/libata-core.c	2006-05-22 11:07:02.000000000 +0800
@@ -1196,6 +1196,8 @@ static int ata_dev_read_id(struct ata_de
 	}
 
 	tf.protocol = ATA_PROT_PIO;
+	/* Use polling for early detection of phantom dev 1 */
+	tf.flags |= ATA_TFLAG_POLLING;
 
 	err_mask = ata_exec_internal(dev, &tf, NULL, DMA_FROM_DEVICE,
 				     id, sizeof(id[0]) * ATA_ID_WORDS);

Re: [PATCH 1/1] libata: use polling pio for identify device

[Jeff Garzik]

Albert Lee wrote:
> Use polling pio for identify device.
> This can save some time to detect the phantom device 1 during boot.
> 
> Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
> ---
> For the phantom slave device (found with some IBM DVD-RAM drive and
> Intel ICHx chip), irq-pio has to wait 30 seconds timeout to detect them.
> 
> Use polling pio can detect the phantom slave quicker. (Verified ok by Tejun.)
> 
> Patch again the current upstream branch (b74ba22f030eb7ab88f7d8954ad18ecc0ac5ce3c).
> For your review, thanks.
> 
> --- upstream/drivers/scsi/libata-core.c	2006-05-22 10:04:12.000000000 +0800
> +++ polling_identify/drivers/scsi/libata-core.c	2006-05-22 11:07:02.000000000 +0800
> @@ -1196,6 +1196,8 @@ static int ata_dev_read_id(struct ata_de
>  	}
>  
>  	tf.protocol = ATA_PROT_PIO;
> +	/* Use polling for early detection of phantom dev 1 */
> +	tf.flags |= ATA_TFLAG_POLLING;

Sorry I didn't jump into the thread earlier.  I'm trying out this new 
no-work-on-weekends thing, which is a change from my usual 
working-7-days-a-week thing.  :)

NAK.  The above change is going backwards from the direction we took by 
merging irq-pio, and it reintroduces problems that irq-pio solved. 
Additionally, for irq problems unrelated to libata (we will continue to 
see such problems FOREVER), this simply shifts the I-notice-a-problem 
moment from IDENTIFY DEVICE to SET FEATURES, or perhaps the first READ 
or WRITE.

SATA is inherently event driven (read: irq-driven), and PATA has 
traditionally been irq-driven in the Linux drivers/ide code.  Using 
polling for solving this specific problem just isn't enough 
justification.  We should be able to fix this elsewhere.  Take a look at 
the drivers/ide "bang at the door w/ IDENTIFY" probing method.  We took 
a different approach (device signature, etc.) but its still a useful 
working case to examine.

As an aside, phantom devices make me think that somewhere we might be 
getting device-select wrong, or accidentally skipping it entirely.

	Jeff

Re: [PATCH 1/1] libata: use polling pio for identify device

[Albert Lee]

Jeff Garzik wrote:
> Albert Lee wrote:
> 
>> Use polling pio for identify device.
>> This can save some time to detect the phantom device 1 during boot.
>>
>> Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
>> ---
>> For the phantom slave device (found with some IBM DVD-RAM drive and
>> Intel ICHx chip), irq-pio has to wait 30 seconds timeout to detect them.
>>
>> Use polling pio can detect the phantom slave quicker. (Verified ok by
>> Tejun.)
>>
>> Patch again the current upstream branch
>> (b74ba22f030eb7ab88f7d8954ad18ecc0ac5ce3c).
>> For your review, thanks.
>>
>> --- upstream/drivers/scsi/libata-core.c    2006-05-22
>> 10:04:12.000000000 +0800
>> +++ polling_identify/drivers/scsi/libata-core.c    2006-05-22
>> 11:07:02.000000000 +0800
>> @@ -1196,6 +1196,8 @@ static int ata_dev_read_id(struct ata_de
>>      }
>>  
>>      tf.protocol = ATA_PROT_PIO;
>> +    /* Use polling for early detection of phantom dev 1 */
>> +    tf.flags |= ATA_TFLAG_POLLING;
> 
> 
> Sorry I didn't jump into the thread earlier.  I'm trying out this new
> no-work-on-weekends thing, which is a change from my usual
> working-7-days-a-week thing.  :)
> 
> NAK.  The above change is going backwards from the direction we took by
> merging irq-pio, and it reintroduces problems that irq-pio solved.
> Additionally, for irq problems unrelated to libata (we will continue to
> see such problems FOREVER), this simply shifts the I-notice-a-problem
> moment from IDENTIFY DEVICE to SET FEATURES, or perhaps the first READ
> or WRITE.

Currently if the device fails to IDENTIFY DEVICE, new EH will retry
for 3 times and offline it. So, the faulty/phantom device won't
cause trouble to SET FEATURES and normal operation of libata.

(The impact is, 90 seconds boot time for irq-pio and 15 seconds
boot time for polling-pio to IDENTIFY DEVICE and EH recovery.)

> 
> SATA is inherently event driven (read: irq-driven), and PATA has
> traditionally been irq-driven in the Linux drivers/ide code.  Using
> polling for solving this specific problem just isn't enough
> justification.  We should be able to fix this elsewhere.  Take a look at
> the drivers/ide "bang at the door w/ IDENTIFY" probing method.  We took
> a different approach (device signature, etc.) but its still a useful
> working case to examine.

Agree. We need better way to identify the phantom slave.
Will check if any clue we can use, before banging the door by IDENTIFY.

--
albert

> 
> As an aside, phantom devices make me think that somewhere we might be
> getting device-select wrong, or accidentally skipping it entirely.
> 
>     Jeff
> 

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

[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

Re: [RFT] major libata update

[Michael Sterrett -Mr. Bones.-]

Was having trouble getting a new Seagate drive to show up at all with
2.6.16.* so I went ahead and stepped up to .17_rc4 with this patch.
Still no go.  It looks like it's not even seeing the drive at all.
I hope I'm just missing something obvious.

dmesg after boot at:

http://dev.gentoo.org/~mr_bones_/

There's one with routeirq and one without.  The config file is there as
well as 2.6.17-rc4-dot-config.gz (from /proc/config.gz). lspci -v output is
in lspci-dash-v.  You can see that system is really (ab)using the pci bus.

This is the drive:
http://www.newegg.com/Product/Product.asp?Item=N82E16822148131

I don't think it's in sil_blacklist but I don't think it's even getting
that far.  Any tips on what to try next would be great.

Michael Sterrett
   -Mr. Bones.-
michael.sterrett@coat.com

On Mon, 15 May 2006, 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

<chop>

> * 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)

<chop>

Re: [RFT] major libata update

[Tejun Heo]

Michael Sterrett -Mr. Bones.- wrote:
> Was having trouble getting a new Seagate drive to show up at all with
> 2.6.16.* so I went ahead and stepped up to .17_rc4 with this patch.
> Still no go.  It looks like it's not even seeing the drive at all.
> I hope I'm just missing something obvious.
> 
> dmesg after boot at:
> 
> http://dev.gentoo.org/~mr_bones_/
> 
> There's one with routeirq and one without.  The config file is there as
> well as 2.6.17-rc4-dot-config.gz (from /proc/config.gz). lspci -v output is
> in lspci-dash-v.  You can see that system is really (ab)using the pci bus.
> 
> This is the drive:
> http://www.newegg.com/Product/Product.asp?Item=N82E16822148131
> 
> I don't think it's in sil_blacklist but I don't think it's even getting
> that far.  Any tips on what to try next would be great.
> 

At the first glance, it seems like a faulty drive.  Have you tried the 
drive on different hardware?  Has it ever worked?

-- 
tejun

Re: [RFT] major libata update

[Michael Sterrett -Mr. Bones.-]

On Mon, 22 May 2006, Tejun Heo wrote:

> At the first glance, it seems like a faulty drive.  Have you tried the drive 
> on different hardware?  Has it ever worked?

No, I don't have any other SATA hardware to try it with.  It is a new
drive so I suppose it's possible it's just DOA.  I'll see if I can work
out a way to try it on a friend's hardware or something.

Michael Sterrett
   -Mr. Bones.-
michael.sterrett@coat.com

Re: [RFT] major libata update

[Michael Sterrett -Mr. Bones.-]

On Mon, 22 May 2006, Tejun Heo wrote:

> At the first glance, it seems like a faulty drive.  Have you tried the drive 
> on different hardware?  Has it ever worked?

Yep, it's a brick.  Was able to try it on a friend's box with different
controller and cable and still a no-go.  It's going back to newegg.
Sorry for the noise.

Michael Sterrett
   -Mr. Bones.-
mr_bones_@gentoo.org

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

[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