All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Kumlien <pomac@vapor.com>
To: Stephen Hemminger <shemminger@osdl.org>
Cc: woho@woho.de,
	Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>,
	Jeff Garzik <jeff@garzik.org>,
	netdev@vger.kernel.org, Pavel Volkovitskiy <int@mtx.ru>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Revert sky2 to 0.13a
Date: Mon, 27 Feb 2006 19:27:21 +0100	[thread overview]
Message-ID: <1141064841.23375.36.camel@localhost> (raw)
In-Reply-To: <20060227091837.3c214435@localhost.localdomain>

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

On Mon, 2006-02-27 at 09:18 -0800, Stephen Hemminger wrote:
> On Mon, 27 Feb 2006 17:38:38 +0100
> Wolfgang Hoffmann <woho@woho.de> wrote:
> > On Monday 27 February 2006 17:00, Stephen Hemminger wrote:
> > 2.6.16-rc5 with disable_msi=1 works for me, no hangs seen so far. I rsynced 80 
> > GB of data, thats about 5-10 times more than I typically need to reproduce a 
> > hang, so it seems to be solid. For the record: 2.6.16-rc5 with disable_msi=0 
> > does hang.
> > 
> > I have not seen the memory trashing others reported, with no version I tested 
> > so far. Maybe my scenario is not likely to trigger this, so I can't tell.
> > 
> > Unless a fix for msi is at hand, may I suggest for 2.6.16 to revert the msi 
> > commit or switch the default to disable_msi=1?
> > 
> > I've updated bugzilla #6084 accordingly.
> 
> Okay, then what I need is lspci -v of all systems that have the problem, I'll make
> a blacklist (or update PCI quirks). I suspect that MSI doesn't work for any devices
> on these systems, or MSI changes the timing enough to expose existing races.

Am i just tired from trying to make XSLT to do something unnatural or is
there something odd going on in msi.c?

static void msi_set_mask_bit(unsigned int vector, int flag)
{
        struct msi_desc *entry;

        entry = (struct msi_desc *)msi_desc[vector];
        if (!entry || !entry->dev || !entry->mask_base)
                return;
        switch (entry->msi_attrib.type) {
        case PCI_CAP_ID_MSI:
        {
                int             pos;		<==
                u32             mask_bits;

                pos = (long)entry->mask_base;	<==
...

Doesn't that mean that we, a: read 64 bit from memory. b: save it in a
32 bit area?

(esp since it seems to be a address pointer, which could also be using
higher memory areas... but then i dunno what a void __iomem * is, but i
assume that it will be 64 bits here =))

-- 
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 200 bytes --]

  parent reply	other threads:[~2006-02-27 18:27 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-26  0:54 [PATCH] Revert sky2 to 0.13a Carl-Daniel Hailfinger
2006-02-26  2:03 ` Stephen Hemminger
2006-02-26  2:42   ` Ian Kumlien
2006-02-26  8:57   ` Wolfgang Hoffmann
2006-02-26 15:00     ` Ian Kumlien
2006-02-26 15:47       ` Arjan van de Ven
2006-02-26 16:13         ` Ian Kumlien
2006-02-26 22:38           ` Carl-Daniel Hailfinger
2006-02-27  0:43             ` Ian Kumlien
2006-02-27 18:50               ` Carl-Daniel Hailfinger
2006-02-26 18:13       ` Wolfgang Hoffmann
2006-02-26 22:31         ` Wolfgang Hoffmann
2006-02-26 23:03           ` Wolfgang Hoffmann
2006-02-27 16:00             ` Stephen Hemminger
2006-02-27 16:38               ` Wolfgang Hoffmann
2006-02-27 17:18                 ` Stephen Hemminger
2006-02-27 17:48                   ` Wolfgang Hoffmann
2006-02-27 18:27                   ` Ian Kumlien [this message]
2006-02-27 18:38                     ` Jeff Garzik
2006-02-26 15:28   ` Ian Kumlien
2006-02-26  2:25 ` Ian Kumlien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1141064841.23375.36.camel@localhost \
    --to=pomac@vapor.com \
    --cc=c-d.hailfinger.devel.2006@gmx.net \
    --cc=int@mtx.ru \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@osdl.org \
    --cc=woho@woho.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.