On Thursday 18 January 2007 12:12, Stuart Henderson wrote: > On 2007/01/18 11:46, Vijay Sankar wrote: > > apps1# vmstat -i > > interrupt total rate > > irq7/ohci0 3 0 > > irq5/ehci0 128 0 > > irq10/pciide1 12694 6 > > irq5/azalia0 576 0 > > irq11/nfe0 3782 1 > > irq0/clock 195337 100 > > irq8/rtc 250015 128 > > Total 462535 237 > > nothing stands out there. if you leave it doing something which > should use a particular device (e.g. ls -lR /, or ping -f something) > you should see a bunch of interrupts against that device. if you > see a bunch of interrupts against an unrelated device that's a sure > sign there's a problem. > > 'systat vmstat' gives a full-screen display which may be easier to > watch interactively if you're testing like that. > > anything wierd there, try a new bios if there is one before you spend > a long time chasing it. some vendors release new bioses that fix up > interrupt tables and don't bother listing it in the changelog... > (hello supermicro). > > > I did not see anything unusual with top -- most of the time is being > > taken by cc1.
Thank you very much for the detailed explanation, I will try all your suggestions -- will look for a new bios as well as look more closely at what is happening with top and vmstat when compiling. Vijay > > you should look at the cpu states line. When the system is idle all > should be low. When compiling a kernel you'd expect most cpu% should be > in user, some system, maybe a bit in interrupt. > > Also see what state any blocked processes which you expect to be > running are in. (WAIT column) > > > !DSPAM:1,45afba7f219262517112723! -- Vijay Sankar ForeTell Technologies Limited 59 Flamingo Avenue, Winnipeg, MB, Canada R3J 0X6 Phone: +1 (204) 885-9535, E-Mail: [EMAIL PROTECTED]
