kernel: i8253 counting too high! resetting..

kernel: i8253 counting too high! resetting..

[CN]

Hi!

I get several

kernel: i8253 counting too high! resetting..

entries in syslog from kernel 2.4.22 upgraded from Debian woody (gcc
2.95.4) running on AMD K6II 450MHz with 64MB RAM. I don't have such
problem in kernel 2.4.20 upgraded from Slackware (gcc 2.95.3) running on
another box with the identical CPU and main board (but with 192MB RAM).
Does this message hurt anything?

Regards,
CN

-- 
http://www.fastmail.fm - Faster than the air-speed velocity of an
                          unladen european swallow

Re: kernel: i8253 counting too high! resetting..

[Dan Bernard]

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

On 20031028 2350, CN wrote:
> entries in syslog from kernel 2.4.22 upgraded from Debian woody (gcc
> 2.95.4) running on AMD K6II 450MHz with 64MB RAM. I don't have such
> problem in kernel 2.4.20 upgraded from Slackware (gcc 2.95.3) running on
> another box with the identical CPU and main board (but with 192MB RAM).
> Does this message hurt anything?

Can you please provide additional details about your hardware?
What kind of main board are you using, and what southbridge?
What is the reported latency of your IDE interface?

These messages always appear on virtual consoles of one particular machine.
These messages are kernel warnings regarding some kind of locking/timing
issue with a certain bridge controller, as far as I know.  I suspect one
of the ALi chips on my TransMeta TM5800 (ALi M1535 integrated southbridge)
to be the culprit, likely the M1533 PCI-ISA bridge or M5229 IDE controller,
which claims to be bridged with an ALi M7101 PMU, although I have a number
of other unidentified ALi chips on that board, including an ALi M5819P,
which I'm guessing is some kind of timing chip that doesn't register
with the kernel.

Details aside, this message is an increasingly common problem.  Simply
do a Google search for i8253 and you'll see what I mean.  As far as I
can tell, since my LFS system running 2.4.21-xfs on this hardware has
been up for over 63 days and counting, these reset messages are not
harmful.  They are only a bit of a nuisance as they constantly overflow
my /proc/kmsg, rendering dmesg rather useless.  Anyway, I would be very
interested to see what other hardware on which this may be seen.

Regards,
Dan Bernard


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

Re: kernel: i8253 counting too high! resetting..

[CN]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="Big5", Size: 2710 bytes --]

Thank you a lot!

> > entries in syslog from kernel 2.4.22 upgraded from Debian woody (gcc
> > 2.95.4) running on AMD K6II 450MHz with 64MB RAM. I don't have such
> > problem in kernel 2.4.20 upgraded from Slackware (gcc 2.95.3) running on
> > another box with the identical CPU and main board (but with 192MB RAM).
> > Does this message hurt anything?
> 
> Can you please provide additional details about your hardware?
> What kind of main board are you using, and what southbridge?

Now I found that the two boards are slightly different. The printings on
the biggest 2 chips on the problematic board are:

ALi
M1542 A1
100MHz
9949 TS05

ALi
M1543C B1
9947 TM07

respectively. While the board having no i8253 messages has the chips:

ALi
M1542 A1
100MHz
9937 TS05

ALi
M1543C B1
0002 TM05

> What is the reported latency of your IDE interface?

Sorry! I don't quite understand the meanings! I am trying to report all I
know about. dmesg on the problematic box shows:

Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
hda: FUJITSU MPE3064AT, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: attached ide-disk driver.
hda: 12672450 sectors (6488 MB) w/512KiB Cache, CHS=13410/15/63
Partition check:
 hda: [PTBL] [788/255/63] hda1

One thing I want to mention here is that this disk supports 66MHz DMA
access according to Fjuitsu's whitepaper. OTOH, the board running kernel
2.4.20 reports:

Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
ALI15X3: IDE controller on PCI bus 00 dev 78
PCI: Assigned IRQ 10 for device 00:0f.0
ALI15X3: chipset revision 194
ALI15X3: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
hda: Maxtor 91021U2, ATA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
hdc: Maxtor 91021U2, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
blk: queue c02c60a4, I/O limit 4095Mb (mask 0xffffffff)
hda: 20010816 sectors (10246 MB) w/512KiB Cache, CHS=1245/255/63,
UDMA(66)
blk: queue c02c6408, I/O limit 4095Mb (mask 0xffffffff)
hdc: 20010816 sectors (10246 MB) w/512KiB Cache, CHS=19852/16/63,
UDMA(66)
Partition check:
 hda: hda1
 hdc: [PTBL] [1245/255/63] hdc1

which looks to me that it supports DMA 66 as expected. I set the bios' of
these 2 boxes to the same parameters related to IDE in menu "Integrated
Peripherals".

Best Regards,

CN

-- 
http://www.fastmail.fm - And now for something completely different…

Re: kernel: i8253 counting too high! resetting..

[Gene Heskett]

On Friday 31 October 2003 00:04, CN wrote:
>Thank you a lot!
>
>> > entries in syslog from kernel 2.4.22 upgraded from Debian woody
>> > (gcc 2.95.4) running on AMD K6II 450MHz with 64MB RAM. I don't
>> > have such problem in kernel 2.4.20 upgraded from Slackware (gcc
>> > 2.95.3) running on another box with the identical CPU and main
>> > board (but with 192MB RAM). Does this message hurt anything?
>>
>> Can you please provide additional details about your hardware?
>> What kind of main board are you using, and what southbridge?
>
>Now I found that the two boards are slightly different. The
> printings on the biggest 2 chips on the problematic board are:
>
>ALi
>M1542 A1
>100MHz
>9949 TS05
>
>ALi
>M1543C B1
>9947 TM07
>
>respectively. While the board having no i8253 messages has the
> chips:
>
>ALi
>M1542 A1
>100MHz
>9937 TS05
>
>ALi
>M1543C B1
>0002 TM05
>
The last line of each chips data above seems inconsequential as thats 
only the mfgr's code date and such.  The chips themselves really 
should be functionally identical.

>> What is the reported latency of your IDE interface?
>
>Sorry! I don't quite understand the meanings! I am trying to report
> all I know about. dmesg on the problematic box shows:
>
>Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
>ide: Assuming 33MHz system bus speed for PIO modes; override with
>idebus=xx
>hda: FUJITSU MPE3064AT, ATA DISK drive
>ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
>hda: attached ide-disk driver.
>hda: 12672450 sectors (6488 MB) w/512KiB Cache, CHS=13410/15/63
>Partition check:
> hda: [PTBL] [788/255/63] hda1
>
>One thing I want to mention here is that this disk supports 66MHz
> DMA access according to Fjuitsu's whitepaper. OTOH, the board
> running kernel 2.4.20 reports:
>
>Uniform Multi-Platform E-IDE driver Revision: 6.31
>ide: Assuming 33MHz system bus speed for PIO modes; override with
>idebus=xx

This is correct, and for 2.4.20, I don't think the override works.

>ALI15X3: IDE controller on PCI bus 00 dev 78
>PCI: Assigned IRQ 10 for device 00:0f.0
>ALI15X3: chipset revision 194
>ALI15X3: not 100% native mode: will probe irqs later
>    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
>    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
>hda: Maxtor 91021U2, ATA DISK drive
>ide: Assuming 33MHz system bus speed for PIO modes; override with
>idebus=xx

And again, while slower, this is the default bus speed FOR PIO, 
Programmed I/O, not DMA.  Another animal entirely.  Running at this 
33MHZ speed, but without any handshaking, it can move 132Mb a second 
because each access is 32 bits, or 4 bytes, wide.  Which is still far 
faster than your drives can bring data past the heads.  You are 
confusing the UDMA66 mode which exists on the drive cable, with the 
bus speed the IDE card is plugged into, 2 entirely different animals.

>hdc: Maxtor 91021U2, ATA DISK drive
>ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
>ide1 at 0x170-0x177,0x376 on irq 15
>blk: queue c02c60a4, I/O limit 4095Mb (mask 0xffffffff)
>hda: 20010816 sectors (10246 MB) w/512KiB Cache, CHS=1245/255/63,
>UDMA(66)
>blk: queue c02c6408, I/O limit 4095Mb (mask 0xffffffff)
>hdc: 20010816 sectors (10246 MB) w/512KiB Cache, CHS=19852/16/63,
>UDMA(66)
>Partition check:
> hda: hda1
> hdc: [PTBL] [1245/255/63] hdc1
>
>which looks to me that it supports DMA 66 as expected. I set the
> bios' of these 2 boxes to the same parameters related to IDE in
> menu "Integrated Peripherals".

You'll need good cables, and a lengthy read of the hdparm manpage.  
Then you can put the correct hdparm command to enable the UDMA66 mode 
right into your /etc/rc.d/rc.local script.

>Best Regards,
>
>CN

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Re: kernel: i8253 counting too high! resetting..

[Dan Bernard]

On 20031031 0040, Gene Heskett wrote:
> >
> >ALi
> >M1542 A1
> >100MHz
> >Uniform Multi-Platform E-IDE driver Revision: 6.31
> >ide: Assuming 33MHz system bus speed for PIO modes; override with
> >idebus=xx
> 
> This is correct, and for 2.4.20, I don't think the override works.
> 
> > ...
> 
> And again, while slower, this is the default bus speed FOR PIO, 
> Programmed I/O, not DMA.  Another animal entirely.  Running at this 
> 33MHZ speed, but without any handshaking, it can move 132Mb a second 
> because each access is 32 bits, or 4 bytes, wide.  Which is still far 
> faster than your drives can bring data past the heads.  You are 
> confusing the UDMA66 mode which exists on the drive cable, with the 
> bus speed the IDE card is plugged into, 2 entirely different animals.
> 
> > ...
> 
> You'll need good cables, and a lengthy read of the hdparm manpage.  
> Then you can put the correct hdparm command to enable the UDMA66 mode 
> right into your /etc/rc.d/rc.local script.

ALi M1542 chipset is probably not too different from mine.  That's good,
because if it were not ALi, then this would be much more complicated.

The main problem here is not any kind of malfunction, but simply a
component or group of components performing slightly below what is
expected, and the software therefore generates unnecessary noise.

I do not try to tweak any settings with hdparm unless something is broken.
However, it looks like that may be your best bet in this particular case.
I shall just continue putting up with the warnings for now.

Still, if anyone gets these warnings without ALi chipsets, please do tell.

Regards,
Dan Bernard

Re: kernel: i8253 counting too high! resetting..

[Gene Heskett]

On Friday 31 October 2003 01:36, Dan Bernard wrote:
>On 20031031 0040, Gene Heskett wrote:
>> >ALi
>> >M1542 A1
>> >100MHz
>> >Uniform Multi-Platform E-IDE driver Revision: 6.31
>> >ide: Assuming 33MHz system bus speed for PIO modes; override with
>> >idebus=xx
>>
>> This is correct, and for 2.4.20, I don't think the override works.
>>
>> > ...
>>
>> And again, while slower, this is the default bus speed FOR PIO,
>> Programmed I/O, not DMA.  Another animal entirely.  Running at
>> this 33MHZ speed, but without any handshaking, it can move 132Mb a
>> second because each access is 32 bits, or 4 bytes, wide.  Which is
>> still far faster than your drives can bring data past the heads. 
>> You are confusing the UDMA66 mode which exists on the drive cable,
>> with the bus speed the IDE card is plugged into, 2 entirely
>> different animals.
>>
>> > ...
>>
>> You'll need good cables, and a lengthy read of the hdparm manpage.
>> Then you can put the correct hdparm command to enable the UDMA66
>> mode right into your /etc/rc.d/rc.local script.
>
>ALi M1542 chipset is probably not too different from mine.  That's
> good, because if it were not ALi, then this would be much more
> complicated.
>
>The main problem here is not any kind of malfunction, but simply a
>component or group of components performing slightly below what is
>expected, and the software therefore generates unnecessary noise.
>
>I do not try to tweak any settings with hdparm unless something is
> broken. However, it looks like that may be your best bet in this
> particular case. I shall just continue putting up with the warnings
> for now.
>
>Still, if anyone gets these warnings without ALi chipsets, please do
> tell.
>
>Regards,
>Dan Bernard

Unforch, for this scene, both of my boards have VIA chipsets, so its 
not from personal experience, I'm just a CET with 55 years of chasing 
electrons for a living.  I've looked at the top of a lot of chips 
since IC's were invented.  If the boards are really fresh, maybe you 
could warranty the noisy one as being defective?

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Re: kernel: i8253 counting too high! resetting..

[CN]

On Fri, 31 Oct 2003 06:36:36 +0000, "Dan Bernard" <djb29@cwru.edu> said:
> ALi M1542 chipset is probably not too different from mine.  That's good,
> because if it were not ALi, then this would be much more complicated.
> 
> The main problem here is not any kind of malfunction, but simply a
> component or group of components performing slightly below what is
> expected, and the software therefore generates unnecessary noise.
> 
> I do not try to tweak any settings with hdparm unless something is
> broken.
> However, it looks like that may be your best bet in this particular case.
> I shall just continue putting up with the warnings for now.
> 
> Still, if anyone gets these warnings without ALi chipsets, please do
> tell.

I'm sorry for the late follow up as I lost Internet connection during the
period of OS reinstallation. The following symptom I have newly noticed
is a follow up to my first post in this thread.

As reported in my first message, the box running kernel 2.4.22 and
Fjuitsu HD generated i8253 message while the other box running 2.4.20 and
Maxtor did not. During the past 3 days I wiped out everything from the HD
and reinstalled Debian woody on to the "normal" box (with Maxtor) and
rebuilt the kernel to 2.4.22. This used-to-be normal box started to
generate the i8253 message since then.

Then I downgraded both boxes to kernel 2.4.20. Now both boxes are running
woody and kernel 2.4.20 on identical hardware exept HD's and RAM's. Well,
both boxes completely stop the i8253 message since the OS downgrade :). I
don't have any knowledge regarding the technical details but I think
reporting this "history" to this list should be a good idea.

Best Regards,
CN

-- 
http://www.fastmail.fm - Send your email first class

Re: kernel: i8253 counting too high! resetting..

[Willy Tarreau]

Hi,

On Sun, Nov 02, 2003 at 08:41:55PM -0800, CN wrote:
> As reported in my first message, the box running kernel 2.4.22 and
> Fjuitsu HD generated i8253 message while the other box running 2.4.20 and
> Maxtor did not. During the past 3 days I wiped out everything from the HD
> and reinstalled Debian woody on to the "normal" box (with Maxtor) and
> rebuilt the kernel to 2.4.22. This used-to-be normal box started to
> generate the i8253 message since then.

There's a simple reason for what you see : this message was introduced in
2.4.21 to detect buggy hardware. Before 2.4.21, you only had the luck to
see time go backwards without any apparent reason. There was a very long
thread about gettimeofday() jumping backwards a few months ago in which
you may find detailed informations about this problem.

Regards,
Willy

Re: kernel: i8253 counting too high! resetting..

[Dan Bernard]

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

On 20031103 0616, Willy Tarreau wrote:
> There's a simple reason for what you see : this message was introduced in
> 2.4.21 to detect buggy hardware. Before 2.4.21, you only had the luck to
> see time go backwards without any apparent reason. There was a very long
> thread about gettimeofday() jumping backwards a few months ago in which
> you may find detailed informations about this problem.

That would be the other piece that I'm currently missing regarding the ALi
M5819P on the TM5800.  On similar "buggy hardware" roughly eight months ago,
I got the mysterious chronometer jumps, although none seemed to go backwards
in time.  Whenever I watched it, it seemed normal, although when I left it
alone, the clock, on average, advanced only a few hours per day.  I saw
this problem persist up to 2.4.20, when I lost hope on that machine and
turned it into a FreeBSD workstation.  I do not currently remember whether
it had any ALi chipsets, and I never saw any weird messages, probably
because I never installed any Linux kernels after 2.4.20.  Maybe if I run
across any Knoppix CD's with recent kernels, I could test that machine
for the i8253 messages, but that is not likely at the moment.

Regards,
Dan Bernard


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