Re: limit-timer_pm-printk-storms.patch

Re: limit-timer_pm-printk-storms.patch

[Andrew Morton]

Bongani Hlope <bonganilinux@mweb.co.za> 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?

Re: limit-timer_pm-printk-storms.patch

[Bongani Hlope]

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

On Tue, 20 Jan 2004 11:57:51 -0800
Andrew Morton <akpm@osdl.org> wrote:

> Bongani Hlope <bonganilinux@mweb.co.za> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: limit-timer_pm-printk-storms.patch

[john stultz]

On Tue, 2004-01-20 at 11:57, Andrew Morton wrote:
> Bongani Hlope <bonganilinux@mweb.co.za> 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

Re: limit-timer_pm-printk-storms.patch

[Dominik Brodowski]

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

On Tue, Jan 20, 2004 at 11:57:51AM -0800, Andrew Morton wrote:
> Bongani Hlope <bonganilinux@mweb.co.za> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]