2004-01-20 19:56:40

by Andrew Morton

[permalink] [raw]
Subject: Re: limit-timer_pm-printk-storms.patch

Bongani Hlope <[email protected]> wrote:
>
> This patch has been inspired by the limit-IO-error-printk-storms patch. On my PII when I enable
> CONFIG_X86_PM_TIMER this gets called a lot of times, I guess my VIA chipset is too broken to play with this.
>
> <example>
> ...
> Jan 19 04:21:46 bongani kernel: bad pmtmr read: (15567390, 15567423, 15567393)
> Jan 19 04:21:46 bongani kernel: bad pmtmr read: (1746710, 1746719, 1746713)
> Jan 19 04:21:47 bongani kernel: bad pmtmr read: (2239982, 2239999, 2239986)

Does the PM timer actually do the right thing once these printk's are
suppressed?

If not, it would be better to recover somehow - presumably by blacklisting
this machine or by falling back to a different time source. Possible?



2004-01-20 20:27:22

by Bongani Hlope

[permalink] [raw]
Subject: Re: limit-timer_pm-printk-storms.patch

On Tue, 20 Jan 2004 11:57:51 -0800
Andrew Morton <[email protected]> wrote:

> Bongani Hlope <[email protected]> wrote:
> >
> > This patch has been inspired by the limit-IO-error-printk-storms patch. On my PII when I enable
> > CONFIG_X86_PM_TIMER this gets called a lot of times, I guess my VIA chipset is too broken to play with this.
> >
> > <example>
> > ...
> > Jan 19 04:21:46 bongani kernel: bad pmtmr read: (15567390, 15567423, 15567393)
> > Jan 19 04:21:46 bongani kernel: bad pmtmr read: (1746710, 1746719, 1746713)
> > Jan 19 04:21:47 bongani kernel: bad pmtmr read: (2239982, 2239999, 2239986)
>
> Does the PM timer actually do the right thing once these printk's are
> suppressed?
>

No this is just to reduce the noise, my /var/log/messages file is about 33M in size

> If not, it would be better to recover somehow - presumably by blacklisting
> this machine or by falling back to a different time source. Possible?

I think it is better to blacklist for know because according to the comment on that function
it is suppose to e workaround for some broken chipsets.


[root@bongani bongani]# lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev 01)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 47)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 02)
00:07.3 Host bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)
00:09.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 07)
00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
00:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2)

>From dmesg

ACPI: RSDP (v000 VIA691 ) @ 0x000f5f70
ACPI: RSDT (v001 AWARD AWRDACPI 0x30302e31 AWRD 0x00000000) @ 0x0fff3000
ACPI: FADT (v001 AWARD AWRDACPI 0x30302e31 AWRD 0x00000000) @ 0x0fff3040
ACPI: DSDT (v001 AWARD AWRDACPI 0x00001000 MSFT 0x0100000a) @ 0x00000000


Attachments:
(No filename) (2.21 kB)
(No filename) (189.00 B)
Download all attachments

2004-01-20 21:07:39

by john stultz

[permalink] [raw]
Subject: Re: limit-timer_pm-printk-storms.patch

On Tue, 2004-01-20 at 11:57, Andrew Morton wrote:
> Bongani Hlope <[email protected]> wrote:
> >
> > This patch has been inspired by the limit-IO-error-printk-storms patch. On my PII when I enable
> > CONFIG_X86_PM_TIMER this gets called a lot of times, I guess my VIA chipset is too broken to play with this.
> >
> > <example>
> > ...
> > Jan 19 04:21:46 bongani kernel: bad pmtmr read: (15567390, 15567423, 15567393)
> > Jan 19 04:21:46 bongani kernel: bad pmtmr read: (1746710, 1746719, 1746713)
> > Jan 19 04:21:47 bongani kernel: bad pmtmr read: (2239982, 2239999, 2239986)
>
> Does the PM timer actually do the right thing once these printk's are
> suppressed?

Yep, as I have no hardware affected by this issue, the debug output was
just there to confirm we were catching the cases we expected to. Looks
like its working.

> If not, it would be better to recover somehow - presumably by blacklisting
> this machine or by falling back to a different time source. Possible?

Don't think that's necessary. We can probably #ifdef DEBUG_PMTMR the
printks.

thanks
-john


2004-01-21 08:27:36

by Dominik Brodowski

[permalink] [raw]
Subject: Re: limit-timer_pm-printk-storms.patch

On Tue, Jan 20, 2004 at 11:57:51AM -0800, Andrew Morton wrote:
> Bongani Hlope <[email protected]> wrote:
> >
> > This patch has been inspired by the limit-IO-error-printk-storms patch. On my PII when I enable
> > CONFIG_X86_PM_TIMER this gets called a lot of times, I guess my VIA chipset is too broken to play with this.
> >
> > <example>
> > ...
> > Jan 19 04:21:46 bongani kernel: bad pmtmr read: (15567390, 15567423, 15567393)
> > Jan 19 04:21:46 bongani kernel: bad pmtmr read: (1746710, 1746719, 1746713)
> > Jan 19 04:21:47 bongani kernel: bad pmtmr read: (2239982, 2239999, 2239986)
>
> Does the PM timer actually do the right thing once these printk's are
> suppressed?

Just recognized my backup notebook, a Pentium III / Intel 440-BX-AGPset
does the same thing -- the pmtmr readings are always quite close to each
other, but not linear.

However, overall the PM timer _does_ the right thing all the time [it always
did the right thing on that system, as that's where the original patch was
created....]

Dominik


Attachments:
(No filename) (1.01 kB)
(No filename) (189.00 B)
Download all attachments