linux-kernel - Re: qstor driver -> irq 193: nobody cared

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45588132.9090200@rtr.ca>
Date:	Mon, 13 Nov 2006 09:29:06 -0500
From:	Mark Lord <lkml@....ca>
To:	Alberto Alonso <alberto@...ys.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: qstor driver -> irq 193: nobody cared

Alberto Alonso wrote:
> OK, after adding the printk line I can start seeing
> results.
> 
> I guess it has been close to 10 on quite a few
> occasions.
..
> # grep qstor /var/log/messages
> Nov 12 07:00:53 w100 kernel: sata_qstor: spurious=0
> Nov 12 07:00:53 w100 kernel: sata_qstor: spurious=1
> Nov 12 07:00:53 w100 kernel: sata_qstor: spurious=0
> Nov 12 07:00:56 w100 kernel: sata_qstor: spurious=1
> Nov 12 07:00:56 w100 kernel: sata_qstor: spurious=2
..
> On Sun, 2006-11-12 at 00:09 -0500, Mark Lord wrote:
>> Alberto Alonso wrote:
>>> The saga continues. It happened again this morning even with the
>>> patch:
>> ..
>>>> Mmm.. We could apply a bit of fuzzy tolerance for the odd glitch.
>>>> Try this patch (attached) and report back.
>> Did you add the printk() to the patch, as suggested?
..

Excellent!

So, either we have a very noisy bit of hardware in there,
or something is wrong with sata_qstor.c.

The device has two methods for dealing with commands.
Regular R/W uses the driver's host queue "packet" interface,
and all other commands pass through the legacy MMIO mechanism.

I'm betting on some bug/interaction with the latter.

Try this patch and see what happens, on top of the printk patch.

Thanks




View attachment "qstor_check_status.patch" of type "text/x-patch" (704 bytes)