PC speaker beeping on high CPU loads on an nForce2

PC speaker beeping on high CPU loads on an nForce2

[Martin Drab]

Hi,

on an nForce2 system (GigaByte 7NNXP) when the CPU is under heavy load 
(like during kernel compilation for instance, or any compilation of any 
bigger project, for that matter), I hear some beeps comming out of the PC 
speaker. It's like few short beeps per second for a while, then silence 
for few seconds, then a beep here and there, and again, and so on. It is 
quite strange. It happens ever since I remember (I mean in kernel 
versions of course, I have the board for about 1.5 years). I've just been 
kind of ignoring it until now. Does anybody else happen to see the same 
symptoms? What could be the cause of this. Is it something about timing? 
But how come the PC speaker gets kiced in, while it's not being used at 
all (well, at least not intentionally) for anything. Perhaps something is 
writing some ports it is not supposed to?

Martin

Re: PC speaker beeping on high CPU loads on an nForce2

[Petr Vandrovec]

Martin Drab wrote:
> Hi,
> 
> on an nForce2 system (GigaByte 7NNXP) when the CPU is under heavy load 
> (like during kernel compilation for instance, or any compilation of any 
> bigger project, for that matter), I hear some beeps comming out of the PC 
> speaker. It's like few short beeps per second for a while, then silence 
> for few seconds, then a beep here and there, and again, and so on. It is 
> quite strange. It happens ever since I remember (I mean in kernel 
> versions of course, I have the board for about 1.5 years). I've just been 
> kind of ignoring it until now. Does anybody else happen to see the same 
> symptoms? What could be the cause of this. Is it something about timing? 
> But how come the PC speaker gets kiced in, while it's not being used at 
> all (well, at least not intentionally) for anything. Perhaps something is 
> writing some ports it is not supposed to?

Nope.  Your system is overheating, and on-board temperature sensors are 
complaining.  Probably you should find whether lm-sensors have drivers for chips 
your motherboard has, and look at sensors output in that case...

Maybe ACPI could report thermal zone as well, try looking at 
/proc/acpi/thermal_zone/* tree.
								Petr

Re: PC speaker beeping on high CPU loads on an nForce2

[Gene Heskett]

On Saturday 26 November 2005 22:23, Martin Drab wrote:
>Hi,
>
>on an nForce2 system (GigaByte 7NNXP) when the CPU is under heavy load
>(like during kernel compilation for instance, or any compilation of any
>bigger project, for that matter), I hear some beeps comming out of the
> PC speaker. It's like few short beeps per second for a while, then
> silence for few seconds, then a beep here and there, and again, and so
> on. It is quite strange. It happens ever since I remember (I mean in
> kernel versions of course, I have the board for about 1.5 years). I've
> just been kind of ignoring it until now. Does anybody else happen to
> see the same symptoms? What could be the cause of this. Is it
> something about timing? But how come the PC speaker gets kiced in,
> while it's not being used at all (well, at least not intentionally)
> for anything. Perhaps something is writing some ports it is not
> supposed to?
>
>Martin

Usually, thats a sign of cpu overheating.  At 18 months, if the cpu
fan/heat sink hasn't been blown out by an air hose, its so packed full
of dust bunnies that no amount of rpms can force any air thru the cpu's 
heat
sink fins.

If its been doing it for a while, I expect the grease between the
bottom of the heat sink and the top pf the cpu has also dried out and
is no longer as effective at moving the heat from the cpu into the
heat sink itself.  So its probably a good idea to do a shut down,
remove the heat sink/fan combo, clean it all up and put a dab of new
grease under the heat sink before ytou clip it back on.  I'm partial
to a fancy bit of stuff called artic silver, which when fresh, is
pretty darned good at moving the heat.

If you aren't comfortable doing all that, find someone who is.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: PC speaker beeping on high CPU loads on an nForce2

[Martin Drab]

On Sun, 27 Nov 2005, Petr Vandrovec wrote:

> Martin Drab wrote:
>
> > on an nForce2 system (GigaByte 7NNXP) when the CPU is under heavy load (like
> > during kernel compilation for instance, or any compilation of any bigger
> > project, for that matter), I hear some beeps comming out of the PC speaker.
> > It's like few short beeps per second for a while, then silence for few
> > seconds, then a beep here and there, and again, and so on. It is quite
> > strange. It happens ever since I remember (I mean in kernel versions of
> > course, I have the board for about 1.5 years). I've just been kind of
> > ignoring it until now. Does anybody else happen to see the same symptoms?
> > What could be the cause of this. Is it something about timing? But how come
> > the PC speaker gets kiced in, while it's not being used at all (well, at
> > least not intentionally) for anything. Perhaps something is writing some
> > ports it is not supposed to?
> 
> Nope.  Your system is overheating, and on-board temperature sensors are
> complaining.  Probably you should find whether lm-sensors have drivers for
> chips your motherboard has, and look at sensors output in that case...
> 
> Maybe ACPI could report thermal zone as well, try looking at
> /proc/acpi/thermal_zone/* tree.

Ah, that didn't occur to me. You are right. I'm about to install a new 
water cooling, so I hope that would help.

Sorry for bothering,
Martin

Re: PC speaker beeping on high CPU loads on an nForce2

[Ivan Yosifov]

On Sun, 2005-11-27 at 01:11 -0500, Gene Heskett wrote:
> On Saturday 26 November 2005 22:23, Martin Drab wrote:
> >Hi,
> >
> >on an nForce2 system (GigaByte 7NNXP) when the CPU is under heavy load
> >(like during kernel compilation for instance, or any compilation of any
> >bigger project, for that matter), I hear some beeps comming out of the
> > PC speaker. It's like few short beeps per second for a while, then
> > silence for few seconds, then a beep here and there, and again, and so
> > on. It is quite strange. It happens ever since I remember (I mean in
> > kernel versions of course, I have the board for about 1.5 years). I've
> > just been kind of ignoring it until now. Does anybody else happen to
> > see the same symptoms? What could be the cause of this. Is it
> > something about timing? But how come the PC speaker gets kiced in,
> > while it's not being used at all (well, at least not intentionally)
> > for anything. Perhaps something is writing some ports it is not
> > supposed to?
> >
> >Martin
> 
> Usually, thats a sign of cpu overheating.  At 18 months, if the cpu
> fan/heat sink hasn't been blown out by an air hose, its so packed full
> of dust bunnies that no amount of rpms can force any air thru the cpu's 
> heat
> sink fins.

Gee ! The timeframe is just 3 months here... :-/

> 
> If its been doing it for a while, I expect the grease between the
> bottom of the heat sink and the top pf the cpu has also dried out and
> is no longer as effective at moving the heat from the cpu into the
> heat sink itself.  So its probably a good idea to do a shut down,
> remove the heat sink/fan combo, clean it all up and put a dab of new
> grease under the heat sink before ytou clip it back on.  I'm partial
> to a fancy bit of stuff called artic silver, which when fresh, is
> pretty darned good at moving the heat.
> 
> If you aren't comfortable doing all that, find someone who is.
> 

Re: PC speaker beeping on high CPU loads on an nForce2

[Martin Drab]

On Sun, 27 Nov 2005, Gene Heskett wrote:

> On Saturday 26 November 2005 22:23, Martin Drab wrote:
> >Hi,
> >
> >on an nForce2 system (GigaByte 7NNXP) when the CPU is under heavy load
> >(like during kernel compilation for instance, or any compilation of any
> >bigger project, for that matter), I hear some beeps comming out of the
> > PC speaker. It's like few short beeps per second for a while, then
> > silence for few seconds, then a beep here and there, and again, and so
> > on. It is quite strange. It happens ever since I remember (I mean in
> > kernel versions of course, I have the board for about 1.5 years). I've
> > just been kind of ignoring it until now. Does anybody else happen to
> > see the same symptoms? What could be the cause of this. Is it
> > something about timing? But how come the PC speaker gets kiced in,
> > while it's not being used at all (well, at least not intentionally)
> > for anything. Perhaps something is writing some ports it is not
> > supposed to?
> >
> >Martin
> 
> Usually, thats a sign of cpu overheating.  At 18 months, if the cpu
> fan/heat sink hasn't been blown out by an air hose, its so packed full
> of dust bunnies that no amount of rpms can force any air thru the cpu's 
> heat sink fins.

No, it isn't a problem of dust or grease. It is a problem of a case full 
of devices and bad airflow within it. (There's 6 HDDs, 8 PCI cards, an 
AthlonXP 3200+ with massive Zalman CNPS6000-Cu on top of it and 10 fans 
that are doing all they can running at maximum (with the noise of a 
medium vacuum cleaner ;), trying to cool it all, but it just isn't 
enough.) So I'll try to solve it by a water cooling.

I just didn't connect these sounds with the MB alarm. (Even though I know 
that there is this kind of feature.)

However thanks for the advises anyway,
Martin

Re: PC speaker beeping on high CPU loads on an nForce2

[Willy Tarreau]

On Sun, Nov 27, 2005 at 06:56:23PM +0100, Martin Drab wrote:
> On Sun, 27 Nov 2005, Gene Heskett wrote:
> 
> > On Saturday 26 November 2005 22:23, Martin Drab wrote:
> > >Hi,
> > >
> > >on an nForce2 system (GigaByte 7NNXP) when the CPU is under heavy load
> > >(like during kernel compilation for instance, or any compilation of any
> > >bigger project, for that matter), I hear some beeps comming out of the
> > > PC speaker. It's like few short beeps per second for a while, then
> > > silence for few seconds, then a beep here and there, and again, and so
> > > on. It is quite strange. It happens ever since I remember (I mean in
> > > kernel versions of course, I have the board for about 1.5 years). I've
> > > just been kind of ignoring it until now. Does anybody else happen to
> > > see the same symptoms? What could be the cause of this. Is it
> > > something about timing? But how come the PC speaker gets kiced in,
> > > while it's not being used at all (well, at least not intentionally)
> > > for anything. Perhaps something is writing some ports it is not
> > > supposed to?
> > >
> > >Martin
> > 
> > Usually, thats a sign of cpu overheating.  At 18 months, if the cpu
> > fan/heat sink hasn't been blown out by an air hose, its so packed full
> > of dust bunnies that no amount of rpms can force any air thru the cpu's 
> > heat sink fins.
> 
> No, it isn't a problem of dust or grease. It is a problem of a case full 
> of devices and bad airflow within it. (There's 6 HDDs, 8 PCI cards, an 
> AthlonXP 3200+ with massive Zalman CNPS6000-Cu on top of it and 10 fans 
> that are doing all they can running at maximum (with the noise of a 
> medium vacuum cleaner ;), trying to cool it all, but it just isn't 
> enough.) So I'll try to solve it by a water cooling.

Should be cheaper to buy a bigger case with a *real airflow path, and
remove some of those fans. It's non-sense to put 10 fans in a mono-proc
system ! even with 6 disks (probably even IDE disks).

BTW, if you have the case FAN orthogonal to the CPU's and close to it,
you'd better stop it as ot will prevent part of the airflow from entering
the CPU's fan. It's amazing to see the number of boxes with a case FAN
which increases the CPU temperature by 5 degrees once it spins up ! I
too had one which made my dual athlon regularly crash, and it's OK now
that I have unplugged it. I noticed it first because the rear CPU was
5 degrees hotter than the front one.

> I just didn't connect these sounds with the MB alarm. (Even though I know 
> that there is this kind of feature.)

If your system is stable, you can also disable the alarm. It's very
conservative and will beep for nearly nothing. My dual athlon runs
up to 92 degrees celcius on summer without crashing. The highest alarm
threshold was something like 60 degrees...

> However thanks for the advises anyway,
> Martin

Regards,
Willy

Re: PC speaker beeping on high CPU loads on an nForce2

[Paul Jackson]

With that many fans, make sure you have good airflow,
with all the fans pushing the air the same way.

Good airflow is like good rush hour traffic on the
freeway - steady, consistent, minimal causes of
turbulence, wide lanes, no bottlenecks, ...

Cooling your Computer
http://www.atruereview.com/Articles/compcool.php

THE HEATSINK GUIDE: Case Cooling
http://www.heatsink-guide.com/content.php?content=case.shtml

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

Re: PC speaker beeping on high CPU loads on an nForce2

[Martin Drab]

On Sun, 27 Nov 2005, Willy Tarreau wrote:
> On Sun, Nov 27, 2005 at 06:56:23PM +0100, Martin Drab wrote:
> > No, it isn't a problem of dust or grease. It is a problem of a case full 
> > of devices and bad airflow within it. (There's 6 HDDs, 8 PCI cards, an 
> > AthlonXP 3200+ with massive Zalman CNPS6000-Cu on top of it and 10 fans 
> > that are doing all they can running at maximum (with the noise of a 
> > medium vacuum cleaner ;), trying to cool it all, but it just isn't 
> > enough.) So I'll try to solve it by a water cooling.
> 
> Should be cheaper to buy a bigger case with a *real airflow path, and
> remove some of those fans.

This is a big-tower (Chieftec DA-01BL-D 
<http://www.chieftec.de/?page=products_show&item=201&k_id=1&language=de>), 
the only bigger would be a very expensive server casing.

> It's non-sense to put 10 fans in a mono-proc system ! even with 6 disks 
> (probably even IDE disks).

Yes I agree, though I counted all fans in the system (1 Northbridge, 1 
Power, 1 dual-power add-on board, 1 graphics, 1 CPU, 2 for the RAID array 
[generally only 7200RPM, but still quite hot] ;), 1 more in front for 
incomming cool air, 2 additional on the back for the outgoing hot air, 1 
orthogonal case fan above the CPU, and 1 big 120mm orthogonal above CPU, 
NB, and memory placed approximatelly in the center of the case. So it's 
actually even 12 total. Unfortunatelly it turns out, that the big one in 
the center is the most important one, as it's diverting the airflow, that 
otherwise goes front to back along the casing wall, to the CPU, as 
otherwise the CPU is burried and surrounded with the RAID array and some 
cables from the front side of the case, by a rather big graphics card from 
below (where the frontal additional fan is inserting the cool air), and by 
the casing stiffner from above. So pretty much the two orthogonal fans are 
the only ones reaching the CPU.

This really is an insane configuration, I agree. However though the alarm 
is beeping sometimes during a big load. The system is perfectly stable.

> BTW, if you have the case FAN orthogonal to the CPU's and close to it,
> you'd better stop it as ot will prevent part of the airflow from entering
> the CPU's fan.

This is definitelly not the case here. I have most of the fans attached to 
a regulator, and if I turn the orthogonals off, the temperature of the CPU 
begins to rise very quickly.

> It's amazing to see the number of boxes with a case FAN
> which increases the CPU temperature by 5 degrees once it spins up ! I
> too had one which made my dual athlon regularly crash, and it's OK now
> that I have unplugged it. I noticed it first because the rear CPU was
> 5 degrees hotter than the front one.

Hmm, that may be the case for the dual system, as if the orthogonal fan is 
blowing at one of the CPUs the hot air from it may diverted horizontally 
along the MB to the other CPU and in fact heating it up again, or 
something. It shouldn't be the case for a UP.

Martin

Re: PC speaker beeping on high CPU loads on an nForce2

[Jan Engelhardt]

>> on an nForce2 system (GigaByte 7NNXP) when the CPU is under heavy load
>> (like during kernel compilation for instance, or any compilation of any
>> bigger project, for that matter), I hear some beeps comming out of the PC
>> speaker. It's like few short beeps per second for a while, then silence
>> for few seconds, then a beep here and there, and again, and so on. It is
>> quite strange. (I have the board for about 1.5 years).
>
> Nope.  Your system is overheating, and on-board temperature sensors are
> complaining.  Probably you should find whether lm-sensors have drivers for
> chips your motherboard has, and look at sensors output in that case...

Quite interesting, as I occassionally have short "drumbeat" on the PC 
speaker. It is like \e[10;x]\e[11;15], but seems irreproducible to me with 
any particular x. I do not suspect overheating, as the BIOS hardware 
monitor has shown 51 deg Celsius after some hours running for over two 
years now.

> Maybe ACPI could report thermal zone as well, try looking at
> /proc/acpi/thermal_zone/* tree.

MB is EliteGroup L7S7A2, CPU is AMD Athlon XP 2000+, and 
/proc/acpi/thermal_zone/ is empty. LM chip is a LM78, but lmsensors outputs 
only rubbish data.


Jan Engelhardt
-- 

ACPI: PCI Interrupt Link [LNKA] (IRQs *7)

[JaniD++]

Hi,

Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs
*7)
Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs
*7)
Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs
*7)
Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs
*7)
Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKE] (IRQs 3
4 5 6 7 10 11 12 14 15) *0, disabled.
Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKF] (IRQs 3
4 5 6 7 10 11 12 14 15) *0, disabled.
Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKG] (IRQs 3
4 5 6 7 10 11 12 14 15) *0, disabled.
Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKH] (IRQs 3
4 5 6 7 *10 11 12 14 15)

This is normal?  :-)

Thanks,

Janos

Re: ACPI: PCI Interrupt Link [LNKA] (IRQs *7)

[Denis Vlasenko]

On Monday 28 November 2005 18:05, JaniD++ wrote:
>References: <Pine.LNX.4.60.0511270409430.30055@kepler.fjfi.cvut.cz> <43892897.9020900@vc.cvut.cz> <Pine.LNX.4.61.0511270927130.14029@yvahk01.tjqt.qr>

You abuse your reply button

>X-Mailer: Microsoft Outlook Express 6.00.2800.1437
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441

No wonder...

> Hi,
> 
> Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs
> *7)
> Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs
> *7)
> Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs
> *7)
> Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs
> *7)
> Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKE] (IRQs 3
> 4 5 6 7 10 11 12 14 15) *0, disabled.
> Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKF] (IRQs 3
> 4 5 6 7 10 11 12 14 15) *0, disabled.
> Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKG] (IRQs 3
> 4 5 6 7 10 11 12 14 15) *0, disabled.
> Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKH] (IRQs 3
> 4 5 6 7 *10 11 12 14 15)
> 
> This is normal?  :-)

I do not understand your question
--
vda

Re: ACPI: PCI Interrupt Link [LNKA] (IRQs *7)

[Carlos Martín]

On 29/11/05, Denis Vlasenko <vda@ilport.com.ua> wrote:
> On Monday 28 November 2005 18:05, JaniD++ wrote:
> >References: <Pine.LNX.4.60.0511270409430.30055@kepler.fjfi.cvut.cz> <43892897.9020900@vc.cvut.cz> <Pine.LNX.4.61.0511270927130.14029@yvahk01.tjqt.qr>
>
> You abuse your reply button
>
> >X-Mailer: Microsoft Outlook Express 6.00.2800.1437
> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
>
> No wonder...

Hey, MS bashing! Can I join in?
Now, wouldn't it be sacrilege to post to any technical list with
something like Outlook?
>
> > Hi,
> >
> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs
> > *7)
> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs
> > *7)
> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs
> > *7)
> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs
> > *7)
> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKE] (IRQs 3
> > 4 5 6 7 10 11 12 14 15) *0, disabled.
> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKF] (IRQs 3
> > 4 5 6 7 10 11 12 14 15) *0, disabled.
> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKG] (IRQs 3
> > 4 5 6 7 10 11 12 14 15) *0, disabled.
> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKH] (IRQs 3
> > 4 5 6 7 *10 11 12 14 15)
> >
> > This is normal?  :-)
>
> I do not understand your question

That's output from the kernel bootup-sequence, he's seen it and is
asking if that is normal behavior/output.

To answer the question, yes, it is perfectly normal to see that.
That's just the kernel describing how the PCI IRQs are set up. You
have nothing to worry about.

   cmn
--
Carlos Martín Nieto        http://www.cmartin.tk

"¿Cómo voy a decir bobadas si soy mudo?" -- CACHAI

Re: ACPI: PCI Interrupt Link [LNKA] (IRQs *7)

[Jan Engelhardt]

>> > *7)
>> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs
>> > *7)
>> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKE] (IRQs 3
>> > 4 5 6 7 10 11 12 14 15) *0, disabled.
>> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKF] (IRQs 3
>> > 4 5 6 7 10 11 12 14 15) *0, disabled.
>> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKG] (IRQs 3
>> > 4 5 6 7 10 11 12 14 15) *0, disabled.
>> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKH] (IRQs 3
>> > 4 5 6 7 *10 11 12 14 15)
>> >
>> > This is normal?  :-)
>>
>> I do not understand your question
>
>To answer the question, yes, it is perfectly normal to see that.
>That's just the kernel describing how the PCI IRQs are set up. You
>have nothing to worry about.

I think it's the "disabled" that worries.



Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/

Re: ACPI: PCI Interrupt Link [LNKA] (IRQs *7)

[JaniD++]

----- Original Message ----- 
From: "Denis Vlasenko" <vda@ilport.com.ua>
To: "JaniD++" <djani22@dynamicweb.hu>
Cc: <linux-kernel@vger.kernel.org>
Sent: Tuesday, November 29, 2005 9:15 AM
Subject: Re: ACPI: PCI Interrupt Link [LNKA] (IRQs *7)


> On Monday 28 November 2005 18:05, JaniD++ wrote:
> >References: <Pine.LNX.4.60.0511270409430.30055@kepler.fjfi.cvut.cz>
<43892897.9020900@vc.cvut.cz>
<Pine.LNX.4.61.0511270927130.14029@yvahk01.tjqt.qr>
>
> You abuse your reply button

Sorry! :-)
I am a little bit lazy... :-P

>
> >X-Mailer: Microsoft Outlook Express 6.00.2800.1437
> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
>
> No wonder...
>
> > Hi,
> >
> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKA]
(IRQs
> > *7)
> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKB]
(IRQs
> > *7)
> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKC]
(IRQs
> > *7)
> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKD]
(IRQs
> > *7)
> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKE]
(IRQs 3
> > 4 5 6 7 10 11 12 14 15) *0, disabled.
> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKF]
(IRQs 3
> > 4 5 6 7 10 11 12 14 15) *0, disabled.
> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKG]
(IRQs 3
> > 4 5 6 7 10 11 12 14 15) *0, disabled.
> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKH]
(IRQs 3
> > 4 5 6 7 *10 11 12 14 15)
> >
> > This is normal?  :-)
>
> I do not understand your question

(next mail)

> --
> vda
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: ACPI: PCI Interrupt Link [LNKA] (IRQs *7)

[JaniD++]

Hi,


----- Original Message ----- 
From: "Carlos Martín" <carlosmn@gmail.com>
To: "JaniD++" <djani22@dynamicweb.hu>
Cc: <linux-kernel@vger.kernel.org>; "Denis Vlasenko" <vda@ilport.com.ua>
Sent: Tuesday, November 29, 2005 4:36 PM
Subject: Re: ACPI: PCI Interrupt Link [LNKA] (IRQs *7)


> On 29/11/05, Denis Vlasenko <vda@ilport.com.ua> wrote:
> > On Monday 28 November 2005 18:05, JaniD++ wrote:
> > >References: <Pine.LNX.4.60.0511270409430.30055@kepler.fjfi.cvut.cz>
<43892897.9020900@vc.cvut.cz>
<Pine.LNX.4.61.0511270927130.14029@yvahk01.tjqt.qr>
> >
> > You abuse your reply button
> >
> > >X-Mailer: Microsoft Outlook Express 6.00.2800.1437
> > >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
> >
> > No wonder...
>
> Hey, MS bashing! Can I join in?
> Now, wouldn't it be sacrilege to post to any technical list with
> something like Outlook?

Sorry, i hate M$ generally, but.... :-P
(....i like outlook....
this is the one exception.)


> >
> > > Hi,
> > >
> > > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKA]
(IRQs
> > > *7)
> > > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKB]
(IRQs
> > > *7)
> > > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKC]
(IRQs
> > > *7)
> > > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKD]
(IRQs
> > > *7)
> > > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKE]
(IRQs 3
> > > 4 5 6 7 10 11 12 14 15) *0, disabled.
> > > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKF]
(IRQs 3
> > > 4 5 6 7 10 11 12 14 15) *0, disabled.
> > > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKG]
(IRQs 3
> > > 4 5 6 7 10 11 12 14 15) *0, disabled.
> > > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKH]
(IRQs 3
> > > 4 5 6 7 *10 11 12 14 15)
> > >
> > > This is normal?  :-)
> >
> > I do not understand your question
>
> That's output from the kernel bootup-sequence, he's seen it and is
> asking if that is normal behavior/output.
>
> To answer the question, yes, it is perfectly normal to see that.
> That's just the kernel describing how the PCI IRQs are set up. You
> have nothing to worry about.

Thanks for the answer!
I ask that because i newer seen this format befor: "[LNKA] (IRQs *7)"

Thanks
Janos


>
>    cmn
> --
> Carlos Martín Nieto        http://www.cmartin.tk
>
> "¿Cómo voy a decir bobadas si soy mudo?" -- CACHAI
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: ACPI: PCI Interrupt Link [LNKA] (IRQs *7)

[JaniD++]

Hi,


----- Original Message ----- 
From: "Jan Engelhardt" <jengelh@linux01.gwdg.de>
To: "Carlos Martín" <carlosmn@gmail.com>
Cc: "JaniD++" <djani22@dynamicweb.hu>; <linux-kernel@vger.kernel.org>;
"Denis Vlasenko" <vda@ilport.com.ua>
Sent: Wednesday, November 30, 2005 6:35 PM
Subject: Re: ACPI: PCI Interrupt Link [LNKA] (IRQs *7)


> >> > *7)
> >> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKD]
(IRQs
> >> > *7)
> >> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKE]
(IRQs 3
> >> > 4 5 6 7 10 11 12 14 15) *0, disabled.
> >> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKF]
(IRQs 3
> >> > 4 5 6 7 10 11 12 14 15) *0, disabled.
> >> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKG]
(IRQs 3
> >> > 4 5 6 7 10 11 12 14 15) *0, disabled.
> >> > Nov 28 16:41:36 192.168.2.50 kernel: ACPI: PCI Interrupt Link [LNKH]
(IRQs 3
> >> > 4 5 6 7 *10 11 12 14 15)
> >> >
> >> > This is normal?  :-)
> >>
> >> I do not understand your question
> >
> >To answer the question, yes, it is perfectly normal to see that.
> >That's just the kernel describing how the PCI IRQs are set up. You
> >have nothing to worry about.
>
> I think it's the "disabled" that worries.

No, i worried about the " (IRQs *7)" format.
I never seen this before....

I searching the bottleneck of my system, and simply found these lines.

I have another question:

           CPU0       CPU1       CPU2       CPU3
  0:        112          0          0   12095059    IO-APIC-edge  timer
  8:          0          0          0       2005    IO-APIC-edge  rtc
  9:          0          0          0          0   IO-APIC-level  acpi
 14:          0          0          0    1922693    IO-APIC-edge  ide0
169:          0          0          0          0   IO-APIC-level
uhci_hcd:usb2
177:          0          0          0          0   IO-APIC-level
uhci_hcd:usb3
185:          0          0          0          0   IO-APIC-level
uhci_hcd:usb4
193:          0          0          0          0   IO-APIC-level
ehci_hcd:usb1
209:          0          0          0  204795144   IO-APIC-level  eth0
217:          0          0          0  424538586   IO-APIC-level  eth1
NMI:          0          0          0          0
LOC:   12095010   12095009   12094905   12094904
ERR:          0
MIS:          0

How can i avoid this?
(all irq on CPU 3)

The  echo /proc/irq/#smp_affinity # >smp_affinity

Has no effect. :-(

I tried it with kernel irq load balancing is on and off.
But nothing is changed. :(

Thanks

Janos



>
>
>
> Jan Engelhardt
> -- 
> | Alphagate Systems, http://alphagate.hopto.org/
> | jengelh's site, http://jengelh.hopto.org/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

RE: ACPI: PCI Interrupt Link [LNKA] (IRQs *7)

[Brown, Len]

> ACPI: PCI Interrupt Link [LNKG](IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
> ACPI: PCI Interrupt Link [LNKH](IRQs 3 4 5 6 7 *10 11 12 14 15)

ACPI PCI Interrupt Links are a way to connect device interrupt
wires to (an assortment of) interrupt controller IRQ inputs.

The "disabled" simply means that particular link
isn't being used -- likely because the link is used
only in another mode (eg. PIC vs APIC mode), or because
there is nothing attached to that interrupt wire.

The kernel will complain loudly if a device references
a disabled link, as it would be a BIOS bug.

The '*' is the IRQ that the link is currently using.

Later on in the dmesg you will be able to see
at device probe time which links are used by
which devices.

In PIC mode we don't balance the IRQs between
links -- though you could enable it with "acpi_irq_balance".
The reason we don't is because too many legacy BIOSs
fail when we do.

In IOAPIC mode, acpi_irq_balance is enabled by default.

This process assigns devices to IRQs, and the idea of
'balance' here is to minimize sharing of the same IRQ
wire between multiple devices.

This has nothing to do with the run-time balancing
to target a given IRQ at a specific CPU.

cheers,
-Len