* Re: limit-timer_pm-printk-storms.patch
2004-01-20 19:57 ` limit-timer_pm-printk-storms.patch Andrew Morton
@ 2004-01-20 20:27 ` Bongani Hlope
2004-01-20 21:05 ` limit-timer_pm-printk-storms.patch john stultz
2004-01-21 8:26 ` limit-timer_pm-printk-storms.patch Dominik Brodowski
2 siblings, 0 replies; 4+ messages in thread
From: Bongani Hlope @ 2004-01-20 20:27 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux, linux-kernel, john stultz
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: limit-timer_pm-printk-storms.patch
2004-01-20 19:57 ` limit-timer_pm-printk-storms.patch Andrew Morton
2004-01-20 20:27 ` limit-timer_pm-printk-storms.patch Bongani Hlope
@ 2004-01-20 21:05 ` john stultz
2004-01-21 8:26 ` limit-timer_pm-printk-storms.patch Dominik Brodowski
2 siblings, 0 replies; 4+ messages in thread
From: john stultz @ 2004-01-20 21:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: Bongani Hlope, Dominik Brodowski, lkml
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: limit-timer_pm-printk-storms.patch
2004-01-20 19:57 ` limit-timer_pm-printk-storms.patch Andrew Morton
2004-01-20 20:27 ` limit-timer_pm-printk-storms.patch Bongani Hlope
2004-01-20 21:05 ` limit-timer_pm-printk-storms.patch john stultz
@ 2004-01-21 8:26 ` Dominik Brodowski
2 siblings, 0 replies; 4+ messages in thread
From: Dominik Brodowski @ 2004-01-21 8:26 UTC (permalink / raw)
To: Andrew Morton; +Cc: Bongani Hlope, linux-kernel, john stultz
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread