All of lore.kernel.org
 help / color / mirror / Atom feed
From: Norbert Kiesel <nkiesel@tbdnetworks.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: chrisw@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: 2.6.13.1 locks machine after some time, 2.6.12.5 work fine
Date: Tue, 13 Sep 2005 14:23:25 -0700	[thread overview]
Message-ID: <1126646605.4555.26.camel@defiant> (raw)
In-Reply-To: <Pine.LNX.4.58.0509131016110.3351@g5.osdl.org>

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

On Tue, 2005-09-13 at 10:23 -0700, Linus Torvalds wrote:
> 
> On Tue, 13 Sep 2005, Norbert Kiesel wrote:
> > 
> > Ok, I applied the patch and I'm running it right now, so far so good.
> > Here is the the output of lspci from the patched 2.6.13.1 (not sure if a
> > diff to the unpatched 2.6.13.1 or the 2.6.12.5 would be more useful, so
> > I settled for no diff :-).
> 
> Yes, now it looks better, except for a lspci quirk. You have:
> 
> > 0000:00:10.0 RAID bus controller: Silicon Image, Inc. SiI 0649
> >		Ultra ATA/100 PCI to ATA Host Controller (rev 01)
> 
> and lspci reports:
> 
> > 	Expansion ROM at 40000000 [disabled] [size=512K]
> 
> where the "disabled" comes from the fact that it looks at the sysfs data 
> structures, and the resource is indeed marked as disabled there (because 
> nothing enabled it explicitly).
> 
> But then reading the HW registers, we see:
> 
> > 30: 01 00 00 40 60 00 00 00 00 00 00 00 0c 01 02 04
> 
> Ie now the ROM address value is 0x40000001, which means that as far as the 
> _hardware_ is concerned, the ROM is actually enabled.
> 
> That's because the cmd64x driver enabled the ROM by just writing the 
> enable bit directly, and never actually told the resource layer that it 
> had done so. Not a big deal - we've properly allocated the resource 
> region, so there's no overlap, there's just this strange disconnect 
> between what the hardware thinks and what the resource handling things.
> 
> Anyway, it all looks reasonable. Of course, exactly like with the hpt 
> driver, there doesn't seem to be any real _reason_ to enable the ROM in 
> the first place, and that code is #ifdef __i386__ anyway (so if there 
> _was_ a reason, it wouldn't work on anything else than an x86), so I 
> suspect we should just remove the ROM enable entirely.
> 
> But it really shouldn't matter - at least we now enable the ROM
> _correctly_, and I'm pretty sure (and certainly sincerely hope ;) that
> your lockup is gone.
> 
> 			Linus
> 

Hi,
system is stable again (I'm way beyond the point where I got lockups
before).  Thanks a bunch for the quick fix!  I'd recommend to include
this patch in 2.6.13.2.

Best,
  Norbert


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

  reply	other threads:[~2005-09-13 21:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-12 23:59 2.6.13.1 locks machine after some time, 2.6.12.5 work fine Norbert Kiesel
2005-09-13  3:00 ` Linus Torvalds
2005-09-13  3:38   ` Norbert Kiesel
2005-09-13 14:25     ` Linus Torvalds
2005-09-13 14:57       ` Linus Torvalds
2005-09-13 16:02         ` Adam Kropelin
2005-09-13 15:55           ` Linus Torvalds
2005-09-13 20:22             ` David S. Miller
2005-09-13 22:25               ` Adam Kropelin
2005-09-13 22:43                 ` [PATCH] ibmphp: Use dword accessors for PCI_ROM_ADDRESS Adam Kropelin
2005-09-13 23:11                   ` Adam Kropelin
2005-09-13 23:15                 ` [PATCH] pciehp: " Adam Kropelin
2005-09-13 23:17                 ` [PATCH] shpchp: " Adam Kropelin
2005-09-13 23:20                 ` [PATCH] qla2xxx: " Adam Kropelin
2005-09-13 16:27       ` 2.6.13.1 locks machine after some time, 2.6.12.5 work fine Norbert Kiesel
2005-09-13 17:09       ` Norbert Kiesel
2005-09-13 17:23         ` Linus Torvalds
2005-09-13 21:23           ` Norbert Kiesel [this message]
2005-09-13 22:24             ` Chris Wright

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=1126646605.4555.26.camel@defiant \
    --to=nkiesel@tbdnetworks.com \
    --cc=chrisw@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /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.