public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Yuval Hager <yuval@avramzon.net>
To: Michael Buesch <mb@bu3sch.de>
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
	bcm43xx-dev@lists.berlios.de, LKML <linux-kernel@vger.kernel.org>,
	wireless <linux-wireless@vger.kernel.org>,
	Peter Stuge <peter@stuge.se>
Subject: Re: BCM4312 Fails when xdm is started
Date: Sun, 23 Nov 2008 09:26:25 +0200	[thread overview]
Message-ID: <200811230926.28948.yuval@avramzon.net> (raw)
In-Reply-To: <200811221654.09399.mb@bu3sch.de>

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

On Saturday 22 November 2008, Michael Buesch wrote:
> On Saturday 22 November 2008 16:32:08 Larry Finger wrote:
> > Michael Buesch wrote:
> > > Somebody disabled MMIO and busmastering.
> > > And somebody cleared the CACHE_LINE_SIZE register.
> >
> > Are these all the read/write bits in the configuration area? Should I
> > conclude that someone zeroed this area?
>
> Yeah well. I'm not sure. It _looks_ like someone completely cut the
> physical power line to the card and it reset its complete PCI config.
> So well, X does poke with the PCI devices. But as you said it also happens
> if X doesn't run, I'd rule that out.
> But I would not rule out a fucked BIOS, yet.
> Does the BIOS have any powersave options and/or spread-spectrum options for
> the PCI-bus? Can you try to turn them all off?
> I have a machine that has PCI-slot autodetect and turns of the PCI clock,
> if it doesn't detect a card on that slot. Also turn that off, if you have
> it, too.
>
> > In case the kernel memory diagnostics don't help, is there any way to
> > trap writes to the configuration registers?
>
> Well, if we have random memory corruption, that can hit memory and MMIO.
> It doesn't hurt to turn on all debugging options. Often you get some hint
> by doing so.

I've enabled all CONFIG*DEBUG I could find relevant, and ran the system with:
'debug memory_corruption_check=1 devres.log=1 debug_objects debugpat 
acpi.debug_layer=0x00410002 acpi.debug_level=0xffffffff'
but no hint appears in the logs during the failure.

I did find that certain events recreate the problem immediately. if I 'xset 
dpms force standby' it happens on wakeup. 'xset -dpms' causes this 
immediately as well. If I load X without DPMS support, it still happens after 
the monitor is waken up from (hardware?) blackness.

--yuval

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

  reply	other threads:[~2008-11-23  7:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200811151801.02369.yuval@avramzon.net>
     [not found] ` <491EFB9D.3040002@lwfinger.net>
     [not found]   ` <200811151907.05636.yuval@avramzon.net>
     [not found]     ` <20081115174623.27321.qmail@stuge.se>
2008-11-21 16:25       ` BCM4312 Fails when xdm is started Larry Finger
2008-11-21 17:42         ` Michael Buesch
2008-11-21 18:28           ` Larry Finger
2008-11-22  6:39             ` Yuval Hager
2008-11-22 15:13               ` Michael Buesch
2008-11-22 15:32                 ` Larry Finger
2008-11-22 15:54                   ` Michael Buesch
2008-11-23  7:26                     ` Yuval Hager [this message]
2008-11-23 11:49                     ` Yuval Hager
2008-11-23 12:20                       ` Michael Buesch
2008-11-23 15:42                         ` Larry Finger
2008-11-23 17:42                           ` Michael Buesch
     [not found]                             ` <200811231955.41722.yuval@avramzon.net>
2008-11-23 18:08                               ` Michael Buesch
2008-11-23 20:46                         ` Peter Stuge
2008-11-23 21:09                           ` Larry Finger
2008-11-24  8:49                             ` Yuval Hager
2008-11-24 10:55                               ` Michael Buesch
2008-11-24 16:11                                 ` Larry Finger
2008-11-25  5:43                                   ` Yuval Hager
2008-11-25  7:18                                     ` Peter Stuge
2008-12-07  9:29                                       ` Yuval Hager
2008-12-07 16:15                                         ` Larry Finger
2008-11-25 11:05                                     ` Michael Buesch

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=200811230926.28948.yuval@avramzon.net \
    --to=yuval@avramzon.net \
    --cc=Larry.Finger@lwfinger.net \
    --cc=bcm43xx-dev@lists.berlios.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mb@bu3sch.de \
    --cc=peter@stuge.se \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox