All of lore.kernel.org
 help / color / mirror / Atom feed
From: Henrik Kretzschmar <henne-lmEOmhgwvqJeCmjzdEDfrw@public.gmane.org>
To: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
Cc: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Crash on reading the whole PCI config of PIIX4 SMBus
Date: Wed, 23 Sep 2009 17:49:22 +0200	[thread overview]
Message-ID: <4ABA4382.1000707@nachtwindheim.de> (raw)
In-Reply-To: <20090923161518.5cb29107-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>

Jean Delvare schrieb:

> That's right, but it doesn't explain why i2c-piix4 crashes in the first
> place, not why merely loading it causes further lspci -xxx to crash
> when they did not beforehand. I admit I am totally clueless.
>   
Sorry, I expressed myself a bit unclear.

With _worked_ I meant the system crashed (thats what killer commands are for).

lspci -xxx (and co) bring this system down in every case, module loaded or not.
Obvious this crash occuress when reading the config space in short periods.

lspci (or better proc-fs and sys-fs) do that, and i2c-piix4 does it sometimes.

Looking at read() of drivers/pci/proc.c i had the idea of stalking the critical area with:

#!/bin/sh
for i in `seq 100`; do
 dd if=/proc/bus/pci/00/07.3 of=/dev/null bs=1 count=n 2>/dev/null;
done


I got no crashes with n == 192, but with n == 193 theres no reaction from the system.

Maybe it's interesting, that (all the time after crashes) the screen
(in my case the console with a blinking cursor) can still be seen.
But no reaction on keyboard hits.

Also strange is, that the device works well IF those two read accesses have not done the crash.
I'll test tomorrow without the second read access, just to know if it works.

WARNING: multiple messages have this Message-ID (diff)
From: Henrik Kretzschmar <henne@nachtwindheim.de>
To: Jean Delvare <khali@linux-fr.org>
Cc: Wolfram Sang <w.sang@pengutronix.de>,
	linux-pci@vger.kernel.org, linux-i2c@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: Crash on reading the whole PCI config of PIIX4 SMBus
Date: Wed, 23 Sep 2009 17:49:22 +0200	[thread overview]
Message-ID: <4ABA4382.1000707@nachtwindheim.de> (raw)
In-Reply-To: <20090923161518.5cb29107@hyperion.delvare>

Jean Delvare schrieb:

> That's right, but it doesn't explain why i2c-piix4 crashes in the first
> place, not why merely loading it causes further lspci -xxx to crash
> when they did not beforehand. I admit I am totally clueless.
>   
Sorry, I expressed myself a bit unclear.

With _worked_ I meant the system crashed (thats what killer commands are for).

lspci -xxx (and co) bring this system down in every case, module loaded or not.
Obvious this crash occuress when reading the config space in short periods.

lspci (or better proc-fs and sys-fs) do that, and i2c-piix4 does it sometimes.

Looking at read() of drivers/pci/proc.c i had the idea of stalking the critical area with:

#!/bin/sh
for i in `seq 100`; do
 dd if=/proc/bus/pci/00/07.3 of=/dev/null bs=1 count=n 2>/dev/null;
done


I got no crashes with n == 192, but with n == 193 theres no reaction from the system.

Maybe it's interesting, that (all the time after crashes) the screen
(in my case the console with a blinking cursor) can still be seen.
But no reaction on keyboard hits.

Also strange is, that the device works well IF those two read accesses have not done the crash.
I'll test tomorrow without the second read access, just to know if it works.






  parent reply	other threads:[~2009-09-23 15:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-22 15:46 Crash on reading the whole PCI config of PIIX4 SMBus Henrik Kretzschmar
2009-09-22 17:04 ` Jean Delvare
     [not found] ` <4AB8F142.9090609-lmEOmhgwvqJeCmjzdEDfrw@public.gmane.org>
2009-09-22 18:07   ` Jean Delvare
2009-09-22 18:07     ` Jean Delvare
2009-09-22 23:18 ` Wolfram Sang
2009-09-23 12:59   ` Henrik Kretzschmar
2009-09-23 13:35     ` Jean Delvare
2009-09-23 14:11       ` Henrik Kretzschmar
     [not found]         ` <4ABA2CA1.8070806-lmEOmhgwvqJeCmjzdEDfrw@public.gmane.org>
2009-09-23 14:15           ` Jean Delvare
2009-09-23 14:15             ` Jean Delvare
     [not found]             ` <20090923161518.5cb29107-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-09-23 15:49               ` Henrik Kretzschmar [this message]
2009-09-23 15:49                 ` Henrik Kretzschmar
2009-09-23 16:30                 ` Jean Delvare

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=4ABA4382.1000707@nachtwindheim.de \
    --to=henne-lmeomhgwvqjecmjzdedfrw@public.gmane.org \
    --cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.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.