* kernel: i8253 counting too high! resetting..
@ 2003-10-29 7:50 CN
2003-10-30 17:12 ` Dan Bernard
0 siblings, 1 reply; 9+ messages in thread
From: CN @ 2003-10-29 7:50 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: kernel: i8253 counting too high! resetting.. 2003-10-29 7:50 kernel: i8253 counting too high! resetting CN @ 2003-10-30 17:12 ` Dan Bernard 2003-10-31 5:04 ` CN 0 siblings, 1 reply; 9+ messages in thread From: Dan Bernard @ 2003-10-30 17:12 UTC (permalink / raw) To: CN; +Cc: linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: kernel: i8253 counting too high! resetting.. 2003-10-30 17:12 ` Dan Bernard @ 2003-10-31 5:04 ` CN 2003-10-31 5:40 ` Gene Heskett 0 siblings, 1 reply; 9+ messages in thread From: CN @ 2003-10-31 5:04 UTC (permalink / raw) To: linux-kernel [-- 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… ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: kernel: i8253 counting too high! resetting.. 2003-10-31 5:04 ` CN @ 2003-10-31 5:40 ` Gene Heskett 2003-10-31 6:36 ` Dan Bernard 0 siblings, 1 reply; 9+ messages in thread From: Gene Heskett @ 2003-10-31 5:40 UTC (permalink / raw) To: CN, linux-kernel 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: kernel: i8253 counting too high! resetting.. 2003-10-31 5:40 ` Gene Heskett @ 2003-10-31 6:36 ` Dan Bernard 2003-10-31 13:00 ` Gene Heskett 2003-11-03 4:41 ` CN 0 siblings, 2 replies; 9+ messages in thread From: Dan Bernard @ 2003-10-31 6:36 UTC (permalink / raw) To: Gene Heskett; +Cc: CN, linux-kernel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: kernel: i8253 counting too high! resetting.. 2003-10-31 6:36 ` Dan Bernard @ 2003-10-31 13:00 ` Gene Heskett 2003-11-03 4:41 ` CN 1 sibling, 0 replies; 9+ messages in thread From: Gene Heskett @ 2003-10-31 13:00 UTC (permalink / raw) To: Dan Bernard; +Cc: CN, linux-kernel 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: kernel: i8253 counting too high! resetting.. 2003-10-31 6:36 ` Dan Bernard 2003-10-31 13:00 ` Gene Heskett @ 2003-11-03 4:41 ` CN 2003-11-03 5:16 ` Willy Tarreau 1 sibling, 1 reply; 9+ messages in thread From: CN @ 2003-11-03 4:41 UTC (permalink / raw) To: linux-kernel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: kernel: i8253 counting too high! resetting.. 2003-11-03 4:41 ` CN @ 2003-11-03 5:16 ` Willy Tarreau 2003-11-03 18:52 ` Dan Bernard 0 siblings, 1 reply; 9+ messages in thread From: Willy Tarreau @ 2003-11-03 5:16 UTC (permalink / raw) To: CN; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: kernel: i8253 counting too high! resetting.. 2003-11-03 5:16 ` Willy Tarreau @ 2003-11-03 18:52 ` Dan Bernard 0 siblings, 0 replies; 9+ messages in thread From: Dan Bernard @ 2003-11-03 18:52 UTC (permalink / raw) To: Willy Tarreau; +Cc: CN, linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-11-03 18:52 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-10-29 7:50 kernel: i8253 counting too high! resetting CN 2003-10-30 17:12 ` Dan Bernard 2003-10-31 5:04 ` CN 2003-10-31 5:40 ` Gene Heskett 2003-10-31 6:36 ` Dan Bernard 2003-10-31 13:00 ` Gene Heskett 2003-11-03 4:41 ` CN 2003-11-03 5:16 ` Willy Tarreau 2003-11-03 18:52 ` Dan Bernard
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).