Date:	Mon, 22 Oct 2007 10:12:00 +0800
From:	Federico Sevilla III <jijo@....ph>
To:	linux-kernel@...r.kernel.org
Subject: Re: "spurious completions during NCQ" with 2.6.23.1 and DVD
	Multi-Recorder on Thinkpad T61

Hi,

Apologies for forgetting to attach the kernel configuration. It is
attached in this email.

Thank you very much.

On Mon, 2007-10-22 at 09:56 +0800, Federico Sevilla III wrote:
> Hi,
> 
> Using the 2.6.23.1 kernel and Debian Etch on a Lenovo Thinkpad T61
> 7659A21, I am getting two weird errors, as follows:
> 
>         ata1.00: exception Emask 0x2 SAct 0x1c SErr 0x0 action 0x2 frozen
>         ata1.00: spurious completions during NCQ issue=0x0 SAct=0x1c FIS=005040a1:00000002
>         ata1.00: cmd 60/17:10:28:01:00/00:00:00:00:00/40 tag 2 cdb 0x0 data 11776 in
>                  res 50/00:30:bf:01:00/00:00:00:00:00/40 Emask 0x2 (HSM violation)
>         ata1.00: cmd 60/80:18:3f:01:00/00:00:00:00:00/40 tag 3 cdb 0x0 data 65536 in
>                  res 50/00:30:bf:01:00/00:00:00:00:00/40 Emask 0x2 (HSM violation)
>         ata1.00: cmd 60/30:20:bf:01:00/00:00:00:00:00/40 tag 4 cdb 0x0 data 24576 in
>                  res 50/00:30:bf:01:00/00:00:00:00:00/40 Emask 0x2 (HSM violation)
>         
>         ...
> 
>         irq 19: nobody cared (try booting with the "irqpoll" option)
>         
>         Call Trace:
>          <IRQ>  [<ffffffff80269f4e>] __report_bad_irq+0x1e/0x80
>          [<ffffffff8026a24d>] note_interrupt+0x29d/0x2e0
>          [<ffffffff8026adbd>] handle_fasteoi_irq+0xdd/0x110
>          [<ffffffff8020d3cc>] call_softirq+0x1c/0x30
>          [<ffffffff8020f44b>] do_IRQ+0x7b/0x100
>          [<ffffffff8020c751>] ret_from_intr+0x0/0xa
>          <EOI> 
>         handlers:
>         [<ffffffff8049e5f0>] (usb_hcd_irq+0x0/0x60)
>         Disabling IRQ #19
> 
> I have tried booting with the irqpoll option, but this results in the
> automounter doing weird things with the optical drive. Specifically, it
> sporadically mounts an audio disc with weird negative-sized tracks, even
> if there is no disc inserted in the drive.
> 
> Also, regardless of whether I boot with irqpoll or not, chrony
> frequently uses up 100% of one CPU. The chrony measurements.log,
> statistics.log and tracking.log all show normal activity (ie: a "normal"
> volume of entries, vis a vis chrony on other machines where CPU usage is
> normal). I don't know if this is related.
> 
> Any clues? I have attached the following:
> 
> 1. Kernel configuration
> 2. dmesg output
> 3. lspci output
> 4. chrony.conf (if it matters)
> 
> Please cc me with replies, as I am not on the list. Thank you very much.
> 
> Cheers!
> 
> plain text document attachment (chrony.conf)
> #/etc/chrony/chrony.conf
> # Servers we query for time
> server 133.100.9.2
> server 133.100.11.8
> server 203.129.68.14
> 
> # Do rapid checks on start-up to synchronize the clock immediately on bootup
> initstepslew 5 133.100.9.2 133.100.11.8 203.129.68.14
> 
> # Look here for the admin password needed for chronyc.  The initial
> # password is generated by a random process at install time.  You may
> # change it if you wish.
> 
> keyfile /etc/chrony/chrony.keys
> 
> # Set runtime command key.  Note that if you change the key (not the
> # password) to anything other than 1 you will need to edit
> # /etc/ppp/ip-up.d/chrony, /etc/ppp/ip-down.d/chrony, and
> # /etc/cron.weekly/chrony as these scripts use it to get the password.
> 
> commandkey 1
> 
> # I moved the driftfile to /var/lib/chrony to comply with the Debian
> # filesystem standard.
> 
> driftfile /var/lib/chrony/chrony.drift
> 
> # Comment this line out to turn off logging.
> 
> log tracking measurements statistics
> logdir /var/log/chrony
> 
> # Stop bad estimates upsetting machine clock.
> 
> maxupdateskew 100.0
> 
> # Dump measurements when daemon exits.
> 
> dumponexit
> 
> # Specify directory for dumping measurements.
> 
> dumpdir /var/lib/chrony
> 
> # This directive forces `chronyd' to send a message to syslog if it
> # makes a system clock adjustment larger than a threshold value in seconds.
> 
> logchange 0.5
> 
> # This directive defines an email address to which mail should be sent
> # if chronyd applies a correction exceeding a particular threshold to the
> # system clock.
> 
> # mailonchange root@...alhost 0.5
> 
> # Specify the file where real-time clock data is stored.  To use this you
> # must have enhanced real-time clock support compiled into your kernel.
> # Comment out the next line if you do not.  Note: I have seen problems with
> # the rtc on some motherboards.  Please file a bug if this bites you.
> 
> rtcfile /var/lib/chrony/chrony.rtc
> 
> # If the last line of this file reads 'rtconutc' chrony will assume that
> # the CMOS clock is on UTC (GMT).  If it reads '# rtconutc' or is absent
> # chrony will assume local time.  The line (if any) was written by the
> # chrony postinst based on what it found in /etc/default/rcS.  You may
> # change it if necessary.  The next line is just a marker for the postinst.
> # You can delete it if you wish.
> # POSTINSTMARKER
> rtconutc
-- 
Federico Sevilla III
F S 3 Consulting Inc.
http://www.fs3.ph

View attachment "config-2.6.23.1" of type "text/plain" (50040 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)

Powered by blists - more mailing lists