Bug 7437

Created attachment 9379 [details]
verbose pci output

Created attachment 9380 [details]
verbose numeric pci output

(switched to email - please retain all cc's)

On Mon, 30 Oct 2006 16:20:16 -0800
bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=7437
> 
>            Summary: VIA VT8233 seems to suffer from the via latency quirk
>     Kernel Version: 2.6.19-rc3
>             Status: NEW
>           Severity: normal
>              Owner: greg@kroah.com
>          Submitter: sylvain.bertrand@gmail.com
> 
> 
> Most recent kernel where this bug did not occur: 2.6.19-rc3

Nope.  We're asking which kernel did _not_ have this bug?

> Distribution: All
> Hardware Environment: ASUS A7V266-E motherboad (northbridge VIA KT266A,
> southbridge VIA 8233), PCI SB LIVE!, onboard promise IDE controller, additional
> PCI USB2 card.
> Software Environment: any
> 
> Problem Description: Fear to load the PCI bus, because it seems to cause a hard
> crash with hard drive data corruption. Too much similar to quirk_vialatency in 
> drivers/pci/quirks.c (see description line 163) to be innocent.
> 
> Steps to reproduce: Load the PCI bus with, for instance, a big file transfer
> from an usb mass storage media v2 connected on a PCI USB2 card to the main hard
> drive and at the same time play music. Randomly crashes the computer and
> corrupts hard drive data (sometimes beyond repair).
> 

argh.  Are you able to identify a change to the via quirk-handling code
which prevents this from happening?

Unfortunately, this has always happened since kernel 2.4 from years
back, even with USB1 devices and I had to drop software raid 0.
As far as I understand the quirk code, it's not enabled for the VT8233
southbridge.
I can add the PCI ID of this VT8233 for this quirk code, if it's
compatible, and do some crash tests. Crashes are usually easy to
produce and not hardware destructive since I got plenty of them. But
you may want to proceed in another way.

2006/10/31, Andrew Morton <akpm@osdl.org>:
>
> (switched to email - please retain all cc's)
>
> On Mon, 30 Oct 2006 16:20:16 -0800
> bugme-daemon@bugzilla.kernel.org wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=7437
> >
> >            Summary: VIA VT8233 seems to suffer from the via latency quirk
> >     Kernel Version: 2.6.19-rc3
> >             Status: NEW
> >           Severity: normal
> >              Owner: greg@kroah.com
> >          Submitter: sylvain.bertrand@gmail.com
> >
> >
> > Most recent kernel where this bug did not occur: 2.6.19-rc3
>
> Nope.  We're asking which kernel did _not_ have this bug?
>
> > Distribution: All
> > Hardware Environment: ASUS A7V266-E motherboad (northbridge VIA KT266A,
> > southbridge VIA 8233), PCI SB LIVE!, onboard promise IDE controller, additional
> > PCI USB2 card.
> > Software Environment: any
> >
> > Problem Description: Fear to load the PCI bus, because it seems to cause a hard
> > crash with hard drive data corruption. Too much similar to quirk_vialatency in
> > drivers/pci/quirks.c (see description line 163) to be innocent.
> >
> > Steps to reproduce: Load the PCI bus with, for instance, a big file transfer
> > from an usb mass storage media v2 connected on a PCI USB2 card to the main hard
> > drive and at the same time play music. Randomly crashes the computer and
> > corrupts hard drive data (sometimes beyond repair).
> >
>
> argh.  Are you able to identify a change to the via quirk-handling code
> which prevents this from happening?
>
>

On Tue, Oct 31, 2006 at 02:03:02AM +0100, Sylvain Bertrand wrote:
> Unfortunately, this has always happened since kernel 2.4 from years
> back, even with USB1 devices and I had to drop software raid 0.
> As far as I understand the quirk code, it's not enabled for the VT8233
> southbridge.
> I can add the PCI ID of this VT8233 for this quirk code, if it's
> compatible, and do some crash tests. Crashes are usually easy to
> produce and not hardware destructive since I got plenty of them. But
> you may want to proceed in another way.

That would be the best way to proceed.  If you add your device ids to
the quirk, does the machine work properly afterward?

thanks,

greg k-h

I enabled the via latency quirk code for my chipset and my workstation
does crash the same way.
Then, my crash problem seems not related to this quirk even if
symptoms are quite similar.

2006/10/31, Greg KH <greg@kroah.com>:
> That would be the best way to proceed.  If you add your device ids to
> the quirk, does the machine work properly afterward?
>
> thanks,
>
> greg k-h

On Wed, Nov 01, 2006 at 02:55:18AM +0100, Sylvain Bertrand wrote:
> I enabled the via latency quirk code for my chipset and my workstation
> does crash the same way.
> Then, my crash problem seems not related to this quirk even if
> symptoms are quite similar.

Thank you for testing.  Can you try contacting VIA to find out what
needs to be fixed here?

Ok, I will send an email. In the mean time, I may experiment enabling
some of the PCI quirks. Do you have some hints on the quirks which
could be good candidates?

2006/11/1, Greg KH <greg@kroah.com>:
> On Wed, Nov 01, 2006 at 02:55:18AM +0100, Sylvain Bertrand wrote:
> > I enabled the via latency quirk code for my chipset and my workstation
> > does crash the same way.
> > Then, my crash problem seems not related to this quirk even if
> > symptoms are quite similar.
>
> Thank you for testing.  Can you try contacting VIA to find out what
> needs to be fixed here?
>

On Wed, Nov 01, 2006 at 11:57:02AM +0100, Sylvain Bertrand wrote:
> Do you have some hints on the quirks which could be good candidates?

I do not, sorry.

Good luck.

I posted a message on the viaarena forums, which are supposed to be the way to
have support. I fear that my queries will stay answered...

Any update on this bug, was it resolved for you Sylvain?
Thanks.

I checked the via forums:no answer.
Regarding the buggy system, I gave it and I have a new one. I won't be able to try to reproduce the bug since I would corrupt data on a disk which is not mine anymore (and I would have to go quite far away).
Ok to close the bug.

Thanks for the update. Closing the bug until someone perhaps runs into this problem and reopens it.