* RE: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later [not found] <beb91d720701110549r346991beh95547e912f68d98f@mail.gmail.com> @ 2007-01-11 14:15 ` Karasyov, Konstantin A 2007-01-11 14:37 ` Salatiel Filho 2007-01-13 12:29 ` Matthew Brett 0 siblings, 2 replies; 27+ messages in thread From: Karasyov, Konstantin A @ 2007-01-11 14:15 UTC (permalink / raw) To: Salatiel Filho; +Cc: linux-acpi Hi, Unfortunately, thermal zones defined in your DSDT doesn't contain any trip points except critical, but the fan control requires at least one active trip point (_ACx) to be defined. Also, there are no fan devices (i.e. device with 'PNP0C0B' HID) defined. This means, that no fan and minimal thermal control is available on your system through the ACPI functionality. Regards. Konstantin. >-----Original Message----- >From: Salatiel Filho [mailto:salatiel.filho@gmail.com] >Sent: Thursday, January 11, 2007 4:50 PM >To: Karasyov, Konstantin A >Cc: Matthew Brett; linux-acpi@vger.kernel.org >Subject: Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 >and later > >On 1/11/07, Karasyov, Konstantin A <konstantin.a.karasyov@intel.com> wrote: >> Hi, >> >> Could you send acpidump command output? >> >sure. Attached >> >> Regards. >> Konstantin. >> >-----Original Message----- >> >From: Salatiel Filho [mailto:salatiel.filho@gmail.com] >> >Sent: Wednesday, January 10, 2007 6:19 AM >> >To: Karasyov, Konstantin A >> >Cc: Matthew Brett; linux-acpi@vger.kernel.org >> >Subject: Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel >2.6.18 >> >and later >> > >> >On 1/9/07, Karasyov, Konstantin A <konstantin.a.karasyov@intel.com> >wrote: >> >> Hi Matthew, >> >> >> >> Could you please perform the following testing: >> > >> > >> > >> >Well , i tried to perform this steps in my machine since i think my >> >fans are not working in linux. Well , for my surprise , i have >> >absolutely nothing in >> > >> ># ls -lh /proc/acpi/fan/ >> >total 0 >> > >> > >> > >> >> >> >> 1. boot, make sure the fan doesn't spin. >> >> >> >> 2. do 'cat /proc/acpi/thermal/*/*', check the following: >> >> - the 'state' field shows 'active[<smthng>]' >> >> (if not - perform some CPU-intensive task); >> >> - fan still doesn't spin, >> > >> >#cat /proc/acpi/thermal/*/* >> >cat: /proc/acpi/thermal/*/*: No such file or directory >> > >> >#cat /proc/acpi/thermal_zone/*/* >> ><setting not supported> >> >cooling mode: critical >> ><polling disabled> >> >state: ok >> >temperature: 60 C >> >critical (S5): 99 C >> ><setting not supported> >> >cooling mode: critical >> ><polling disabled> >> >state: ok >> >temperature: 27 C >> >critical (S5): 105 C >> > >> > >> > >> > >> >> >> >> 3. do 'cat /proc/acpi/fan/*/state', check the following: >> >> - the 'status' field shows 'on' (at least one of them); >> >> - fan still doesn't spin, >> >> >> > >> ># cat /proc/acpi/fan/*/state >> >cat: /proc/acpi/fan/*/state: No such file or directory >> > >> > >> > >> > >> >> 4a. do consequently (as root) the following: >> >> - 'echo 3 > /proc/acpi/fan/*/state' >> >> - 'echo 0 > /proc/acpi/fan/*/state' >> >> (the fan should be that one, which shown 'on' in step 3) >> >> >> >> 4b. (if step 3 failed) do (as root) 'echo 0 > /proc/acpi/fan/*/state' >> >> consequently for each fan device under /proc/acpi/fan/, check the >> >> following: >> >> - fans start spinning; >> >> - fans' states are correct ('cat /proc/acpi/fan/*/state' >> >> command) >> >> >> >> 5. check if the fan(s) start spinning. >> >> >> >> Please, get back to me with the results, test flow description and >> >> commands' outputs. >> >> >> >> Also, you could try the patches from bugs ##7122, 7570 for 2.6.20-rc3 >to >> >> see if it help. >> >> >> > >> >any ideas why i have no /proc/acpi/fan/*? >> > >> >Notebook HP Pavillion dv8230us >> > >> >-- >> >[]'s >> >Salatiel >> > >> >"O maior prazer do inteligente é bancar o idiota >> > diante de um idiota que banca o inteligente". >> > > >-- >[]'s >Salatiel > >"O maior prazer do inteligente é bancar o idiota > diante de um idiota que banca o inteligente". - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-11 14:15 ` PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later Karasyov, Konstantin A @ 2007-01-11 14:37 ` Salatiel Filho 2007-01-13 12:29 ` Matthew Brett 1 sibling, 0 replies; 27+ messages in thread From: Salatiel Filho @ 2007-01-11 14:37 UTC (permalink / raw) To: Karasyov, Konstantin A; +Cc: linux-acpi On 1/11/07, Karasyov, Konstantin A <konstantin.a.karasyov@intel.com> wrote: > Hi, > > Unfortunately, thermal zones defined in your DSDT doesn't contain any trip points except critical, but the fan control requires at least one active trip point (_ACx) to be defined. > Also, there are no fan devices (i.e. device with 'PNP0C0B' HID) defined. > > This means, that no fan and minimal thermal control is available on your system through the ACPI functionality. So who controls fan on and off when i am on linux ? > > > Regards. > Konstantin. > > >-----Original Message----- > >From: Salatiel Filho [mailto:salatiel.filho@gmail.com] > >Sent: Thursday, January 11, 2007 4:50 PM > >To: Karasyov, Konstantin A > >Cc: Matthew Brett; linux-acpi@vger.kernel.org > >Subject: Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 > >and later > > > >On 1/11/07, Karasyov, Konstantin A <konstantin.a.karasyov@intel.com> wrote: > >> Hi, > >> > >> Could you send acpidump command output? > >> > >sure. Attached > >> > >> Regards. > >> Konstantin. > >> >-----Original Message----- > >> >From: Salatiel Filho [mailto:salatiel.filho@gmail.com] > >> >Sent: Wednesday, January 10, 2007 6:19 AM > >> >To: Karasyov, Konstantin A > >> >Cc: Matthew Brett; linux-acpi@vger.kernel.org > >> >Subject: Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel > >2.6.18 > >> >and later > >> > > >> >On 1/9/07, Karasyov, Konstantin A <konstantin.a.karasyov@intel.com> > >wrote: > >> >> Hi Matthew, > >> >> > >> >> Could you please perform the following testing: > >> > > >> > > >> > > >> >Well , i tried to perform this steps in my machine since i think my > >> >fans are not working in linux. Well , for my surprise , i have > >> >absolutely nothing in > >> > > >> ># ls -lh /proc/acpi/fan/ > >> >total 0 > >> > > >> > > >> > > >> >> > >> >> 1. boot, make sure the fan doesn't spin. > >> >> > >> >> 2. do 'cat /proc/acpi/thermal/*/*', check the following: > >> >> - the 'state' field shows 'active[<smthng>]' > >> >> (if not - perform some CPU-intensive task); > >> >> - fan still doesn't spin, > >> > > >> >#cat /proc/acpi/thermal/*/* > >> >cat: /proc/acpi/thermal/*/*: No such file or directory > >> > > >> >#cat /proc/acpi/thermal_zone/*/* > >> ><setting not supported> > >> >cooling mode: critical > >> ><polling disabled> > >> >state: ok > >> >temperature: 60 C > >> >critical (S5): 99 C > >> ><setting not supported> > >> >cooling mode: critical > >> ><polling disabled> > >> >state: ok > >> >temperature: 27 C > >> >critical (S5): 105 C > >> > > >> > > >> > > >> > > >> >> > >> >> 3. do 'cat /proc/acpi/fan/*/state', check the following: > >> >> - the 'status' field shows 'on' (at least one of them); > >> >> - fan still doesn't spin, > >> >> > >> > > >> ># cat /proc/acpi/fan/*/state > >> >cat: /proc/acpi/fan/*/state: No such file or directory > >> > > >> > > >> > > >> > > >> >> 4a. do consequently (as root) the following: > >> >> - 'echo 3 > /proc/acpi/fan/*/state' > >> >> - 'echo 0 > /proc/acpi/fan/*/state' > >> >> (the fan should be that one, which shown 'on' in step 3) > >> >> > >> >> 4b. (if step 3 failed) do (as root) 'echo 0 > /proc/acpi/fan/*/state' > >> >> consequently for each fan device under /proc/acpi/fan/, check the > >> >> following: > >> >> - fans start spinning; > >> >> - fans' states are correct ('cat /proc/acpi/fan/*/state' > >> >> command) > >> >> > >> >> 5. check if the fan(s) start spinning. > >> >> > >> >> Please, get back to me with the results, test flow description and > >> >> commands' outputs. > >> >> > >> >> Also, you could try the patches from bugs ##7122, 7570 for 2.6.20-rc3 > >to > >> >> see if it help. > >> >> > >> > > >> >any ideas why i have no /proc/acpi/fan/*? > >> > > >> >Notebook HP Pavillion dv8230us > >> > > >> >-- > >> >[]'s > >> >Salatiel > >> > > >> >"O maior prazer do inteligente é bancar o idiota > >> > diante de um idiota que banca o inteligente". > >> > > > > > >-- > >[]'s > >Salatiel > > > >"O maior prazer do inteligente é bancar o idiota > > diante de um idiota que banca o inteligente". > -- []'s Salatiel "O maior prazer do inteligente é bancar o idiota diante de um idiota que banca o inteligente". - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-11 14:15 ` PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later Karasyov, Konstantin A 2007-01-11 14:37 ` Salatiel Filho @ 2007-01-13 12:29 ` Matthew Brett 2007-01-13 13:12 ` Alexey Starikovskiy 1 sibling, 1 reply; 27+ messages in thread From: Matthew Brett @ 2007-01-13 12:29 UTC (permalink / raw) To: Karasyov, Konstantin A; +Cc: Salatiel Filho, linux-acpi Hi, > Unfortunately, thermal zones defined in your DSDT doesn't contain any trip points except critical, but the fan control requires at least one active trip point (_ACx) to be defined. > Also, there are no fan devices (i.e. device with 'PNP0C0B' HID) defined. > > This means, that no fan and minimal thermal control is available on your system through the ACPI functionality. Hmm - I guess I had the idea that my ACPI was broken, but in this case, the inadequacy of the ACPI means that the linux kernel had become dangerous for the hardware, in a way that Windows is not. Is there any way of making it less likely that problems in the ACPI will shut off the fan? Best, Matthew ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-13 12:29 ` Matthew Brett @ 2007-01-13 13:12 ` Alexey Starikovskiy 2007-01-13 13:33 ` Matthew Brett 0 siblings, 1 reply; 27+ messages in thread From: Alexey Starikovskiy @ 2007-01-13 13:12 UTC (permalink / raw) To: Matthew Brett; +Cc: Karasyov, Konstantin A, Salatiel Filho, linux-acpi Matthew Brett wrote: > Hi, > >> Unfortunately, thermal zones defined in your DSDT doesn't contain any >> trip points except critical, but the fan control requires at least >> one active trip point (_ACx) to be defined. >> Also, there are no fan devices (i.e. device with 'PNP0C0B' HID) defined. >> >> This means, that no fan and minimal thermal control is available on >> your system through the ACPI functionality. > > Hmm - I guess I had the idea that my ACPI was broken, but in this > case, the inadequacy of the ACPI means that the linux kernel had > become dangerous for the hardware, in a way that Windows is not. Is > there any way of making it less likely that problems in the ACPI will > shut off the fan? > Matthew, If BIOS does not export fan controls to OS via DSDT, it means that BIOS wants to control fans via its own means (hardware), this doesn't mean that your machine is at risk, it only means that you are not allowed to tamper with it... Regards, Alex. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-13 13:12 ` Alexey Starikovskiy @ 2007-01-13 13:33 ` Matthew Brett 2007-01-13 15:51 ` Alexey Starikovskiy 0 siblings, 1 reply; 27+ messages in thread From: Matthew Brett @ 2007-01-13 13:33 UTC (permalink / raw) To: Alexey Starikovskiy; +Cc: Karasyov, Konstantin A, Salatiel Filho, linux-acpi Hi, > If BIOS does not export fan controls to OS via DSDT, it means that BIOS > wants to control fans via its own means (hardware), this doesn't mean > that your machine is at risk, it only means that you are not allowed to > tamper with it... Well, except the original poster complained that linux but not windows was shutting down the fan - meaning - surely - that somehow linux is tampering with the fan when it should not. Best, Matthew ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-13 13:33 ` Matthew Brett @ 2007-01-13 15:51 ` Alexey Starikovskiy 2007-01-14 5:24 ` Bjorn Helgaas 0 siblings, 1 reply; 27+ messages in thread From: Alexey Starikovskiy @ 2007-01-13 15:51 UTC (permalink / raw) To: Matthew Brett; +Cc: Karasyov, Konstantin A, Salatiel Filho, linux-acpi Matthew Brett wrote: > Hi, > >> If BIOS does not export fan controls to OS via DSDT, it means that BIOS >> wants to control fans via its own means (hardware), this doesn't mean >> that your machine is at risk, it only means that you are not allowed to >> tamper with it... > > Well, except the original poster complained that linux but not windows > was shutting down the fan - meaning - surely - that somehow linux is > tampering with the fan when it should not. > > Best, > > Matthew > - > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html As it was said above, Linux has no means to do that. At least through ACPI framework. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-13 15:51 ` Alexey Starikovskiy @ 2007-01-14 5:24 ` Bjorn Helgaas 2007-01-15 13:33 ` Karasyov, Konstantin A 0 siblings, 1 reply; 27+ messages in thread From: Bjorn Helgaas @ 2007-01-14 5:24 UTC (permalink / raw) To: Alexey Starikovskiy Cc: Matthew Brett, Karasyov, Konstantin A, Salatiel Filho, linux-acpi On Saturday 13 January 2007 08:51, Alexey Starikovskiy wrote: > Matthew Brett wrote: > >> If BIOS does not export fan controls to OS via DSDT, it means that BIOS > >> wants to control fans via its own means (hardware), this doesn't mean > >> that your machine is at risk, it only means that you are not allowed to > >> tamper with it... > > > > Well, except the original poster complained that linux but not windows > > was shutting down the fan - meaning - surely - that somehow linux is > > tampering with the fan when it should not. > > > As it was said above, Linux has no means to do that. At least through > ACPI framework. I think there are two things being confused here: 1) Matthew's report, which clearly says that loading fan.ko turns off the fan, and it doesn't come back on when it should. His BIOS provides a PNP0C0B fan device and an _AC0 trip point, so Linux *should* be able to control the fan. 2) Salatiel's report, which is rather vague: "I think my fans are not working in Linux." I haven't seen Salatiel's acpidump, but Konstantin says it has no fan devices and no active trip points. Since Salatiel has no PNP0C0B device, his problem is unrelated to the fan.ko driver. So let's concentrate on Matthew's problem first. Loading fan.ko turns off the fan. If the machine is cool, as it likely is at boot-time, this might be appropriate. When the system gets hot, the thermal driver is supposed to turn the fan(s) on, and this doesn't seem to happen. But the experiments Konstantin suggested showed that the thermal driver did notice the temperature above the active trip point, it switched to active cooling, and ACPI claims the fan is on, thought it apparently is not. Are there any messages in dmesg about problems turning on cooling devices? With 2.6.17, loading fan.ko leaves the fan on. Manually turning off the fan works. But manually turning it back on again fails, which looks suspiciously like the 2.6.20-rc3 problem where the thermal driver can't turn the fan on again. Maybe there's some firmware or mechanical problem such that the fan can only be turned on via reset or a power cycle? Does the fan *ever* turn off and then back on again under 2.6.17? I don't suppose you can try this under Windows? Vacuum out the dust bunnies? Try a different fan? Bjorn ^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-14 5:24 ` Bjorn Helgaas @ 2007-01-15 13:33 ` Karasyov, Konstantin A 2007-01-15 17:06 ` Bjorn Helgaas 2007-01-16 16:54 ` Bjorn Helgaas 0 siblings, 2 replies; 27+ messages in thread From: Karasyov, Konstantin A @ 2007-01-15 13:33 UTC (permalink / raw) To: Bjorn Helgaas, Alexey Starikovskiy, Matthew Brett Cc: Salatiel Filho, linux-acpi [-- Attachment #1: Type: text/plain, Size: 5946 bytes --] Hi All, >I think there are two things being confused here: > ............ > > 2) Salatiel's report, which is rather vague: "I think my fans > are not working in Linux." I haven't seen Salatiel's acpidump, > but Konstantin says it has no fan devices and no active trip > points. Since Salatiel has no PNP0C0B device, his problem is > unrelated to the fan.ko driver. > Right, and later we've find out that the fan on Salatiel's system being turned on by hardware at the point of 80C. >So let's concentrate on Matthew's problem first. Loading fan.ko >turns off the fan. If the machine is cool, as it likely is at >boot-time, this might be appropriate. > Yes, this is possible... >When the system gets hot, the thermal driver is supposed to turn >the fan(s) on, and this doesn't seem to happen. But the experiments >Konstantin suggested showed that the thermal driver did notice the >temperature above the active trip point, it switched to active >cooling, and ACPI claims the fan is on, thought it apparently is >not. Well, here is the excerpt from decompiled Matthew's DSDT: PowerResource (FN01, 0x00, 0x0000) { Method (_STA, 0, NotSerialized) { Return (0x01) } Method (_ON, 0, NotSerialized) { \_SB.PCI0.LPC0.SIO.WR00 (0x07, 0x0A) \_SB.PCI0.LPC0.SIO.WR00 (0x30, 0x01) Store (0x7E, \FAN1) Store (0x7E, \FAN2) Store (0x01, \_TZ.THRM.FNON) Notify (\_TZ.THRM, 0x81) Store (0xCC, DBGP) \_SB.PCI0.LPC0.SIO.WR00 (0x30, 0x00) } Method (_OFF, 0, NotSerialized) { \_SB.PCI0.LPC0.SIO.WR00 (0x07, 0x0A) \_SB.PCI0.LPC0.SIO.WR00 (0x30, 0x01) Store (0x04, \FAN1) Store (0x6A, \FAN2) Store (0x00, \_TZ.THRM.FNON) Notify (\_TZ.THRM, 0x81) Store (0xDD, DBGP) \_SB.PCI0.LPC0.SIO.WR00 (0x30, 0x00) } } Device (FAN1) { Name (_HID, EisaId ("PNP0C0B")) Name (_UID, 0x01) Name (_PR0, Package (0x01) { FN01 }) } The fan device FAN1 defines object FN01 as its power resource. _STA method of FN01 always return 0x01, i.e. resource is on. So the fan driver is unable to turn the fan on, because it thinks that it is already in that state. But, _ON and _OFF methods set \_TZ.THRM.FNON object to 1 and 0 respectively, so, I think, it could be used as value returned by _STA method. Attached patch for DSDT should solve the fan issue. Regards. Konstantin. >-----Original Message----- >From: Bjorn Helgaas [mailto:bjorn.helgaas@hp.com] >Sent: Sunday, January 14, 2007 8:25 AM >To: Alexey Starikovskiy >Cc: Matthew Brett; Karasyov, Konstantin A; Salatiel Filho; linux- >acpi@vger.kernel.org >Subject: Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 >and later > >On Saturday 13 January 2007 08:51, Alexey Starikovskiy wrote: >> Matthew Brett wrote: >> >> If BIOS does not export fan controls to OS via DSDT, it means that >BIOS >> >> wants to control fans via its own means (hardware), this doesn't mean >> >> that your machine is at risk, it only means that you are not allowed >to >> >> tamper with it... >> > >> > Well, except the original poster complained that linux but not windows >> > was shutting down the fan - meaning - surely - that somehow linux is >> > tampering with the fan when it should not. >> > >> As it was said above, Linux has no means to do that. At least through >> ACPI framework. > >I think there are two things being confused here: > > 1) Matthew's report, which clearly says that loading fan.ko > turns off the fan, and it doesn't come back on when it should. > His BIOS provides a PNP0C0B fan device and an _AC0 trip point, > so Linux *should* be able to control the fan. > > 2) Salatiel's report, which is rather vague: "I think my fans > are not working in Linux." I haven't seen Salatiel's acpidump, > but Konstantin says it has no fan devices and no active trip > points. Since Salatiel has no PNP0C0B device, his problem is > unrelated to the fan.ko driver. > >So let's concentrate on Matthew's problem first. Loading fan.ko >turns off the fan. If the machine is cool, as it likely is at >boot-time, this might be appropriate. > >When the system gets hot, the thermal driver is supposed to turn >the fan(s) on, and this doesn't seem to happen. But the experiments >Konstantin suggested showed that the thermal driver did notice the >temperature above the active trip point, it switched to active >cooling, and ACPI claims the fan is on, thought it apparently is >not. > >Are there any messages in dmesg about problems turning on cooling >devices? > >With 2.6.17, loading fan.ko leaves the fan on. Manually turning >off the fan works. But manually turning it back on again fails, >which looks suspiciously like the 2.6.20-rc3 problem where the >thermal driver can't turn the fan on again. > >Maybe there's some firmware or mechanical problem such that the >fan can only be turned on via reset or a power cycle? Does the >fan *ever* turn off and then back on again under 2.6.17? I don't >suppose you can try this under Windows? Vacuum out the dust >bunnies? Try a different fan? > >Bjorn [-- Attachment #2: dsdt_fan.patch --] [-- Type: application/octet-stream, Size: 382 bytes --] --- DSDT.dsl 2007-01-15 15:23:52.000000000 +0300 +++ new_DSDT.dsl 2007-01-15 15:46:24.000000000 +0300 @@ -114,7 +114,7 @@ { Method (_STA, 0, NotSerialized) { - Return (0x01) + Return (\_TZ.THRM.FNON) } Method (_ON, 0, NotSerialized) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-15 13:33 ` Karasyov, Konstantin A @ 2007-01-15 17:06 ` Bjorn Helgaas 2007-01-16 0:39 ` Matthew Brett 2007-01-16 16:54 ` Bjorn Helgaas 1 sibling, 1 reply; 27+ messages in thread From: Bjorn Helgaas @ 2007-01-15 17:06 UTC (permalink / raw) To: Karasyov, Konstantin A Cc: Alexey Starikovskiy, Matthew Brett, Salatiel Filho, linux-acpi On Monday 15 January 2007 06:33, Karasyov, Konstantin A wrote: > The fan device FAN1 defines object FN01 as its power resource. _STA > method of FN01 always return 0x01, i.e. resource is on Ugh. Matthew, have you checked to see whether there are any BIOS updates available for your box? > So the fan > driver is unable to turn the fan on, because it thinks that it is > already in that state. I suppose the fan driver could use force_power_state to work around this BIOS bug. > But, _ON and _OFF methods set \_TZ.THRM.FNON object to 1 and 0 > respectively, so, I think, it could be used as value returned by _STA > method. Attached patch for DSDT should solve the fan issue. But we can't expect users to apply DSDT patches. So if there's no BIOS update available, don't we have to figure out a way to work around it? Maybe we could notice when the BIOS reports the device is "on" even when we've turned it off, decide that the BIOS is lying, and always use force_power_state. Bjorn ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-15 17:06 ` Bjorn Helgaas @ 2007-01-16 0:39 ` Matthew Brett 2007-01-17 2:49 ` Luming Yu 0 siblings, 1 reply; 27+ messages in thread From: Matthew Brett @ 2007-01-16 0:39 UTC (permalink / raw) To: Bjorn Helgaas Cc: Karasyov, Konstantin A, Alexey Starikovskiy, Salatiel Filho, linux-acpi Hi, On 1/15/07, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote: > On Monday 15 January 2007 06:33, Karasyov, Konstantin A wrote: > > The fan device FAN1 defines object FN01 as its power resource. _STA > > method of FN01 always return 0x01, i.e. resource is on > > Ugh. Matthew, have you checked to see whether there are any > BIOS updates available for your box? Ah - my machine is so ill-supported that I was afraid to try any what-seemed-to-be-appropriate bios updates. > > But, _ON and _OFF methods set \_TZ.THRM.FNON object to 1 and 0 > > respectively, so, I think, it could be used as value returned by _STA > > method. Attached patch for DSDT should solve the fan issue. For reference, it does solve the fan issue - fan stays on during boot, echo 0 and 3 to /proc/acpi/fan/*/state cause the fan to switch on and off respectively. > But we can't expect users to apply DSDT patches. So if there's > no BIOS update available, don't we have to figure out a way to > work around it? Maybe we could notice when the BIOS reports the > device is "on" even when we've turned it off, decide that the > BIOS is lying, and always use force_power_state. >From a position of extreme ignorance, a workaround does sound safer - it's such a dangerous problem, Best, Matthew ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-16 0:39 ` Matthew Brett @ 2007-01-17 2:49 ` Luming Yu 2007-01-17 9:02 ` Matthew Brett 0 siblings, 1 reply; 27+ messages in thread From: Luming Yu @ 2007-01-17 2:49 UTC (permalink / raw) To: Matthew Brett Cc: Bjorn Helgaas, Karasyov, Konstantin A, Alexey Starikovskiy, Salatiel Filho, linux-acpi > > > > But, _ON and _OFF methods set \_TZ.THRM.FNON object to 1 and 0 > > > respectively, so, I think, it could be used as value returned by _STA > > > method. Attached patch for DSDT should solve the fan issue. > > For reference, it does solve the fan issue - fan stays on during boot, > echo 0 and 3 to /proc/acpi/fan/*/state cause the fan to switch on and > off respectively. > Does it really solve the problem of CPU fan shutting down on load of fan.ko? Could you just re-test, since that is the problem from the beginning. --Luming ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-17 2:49 ` Luming Yu @ 2007-01-17 9:02 ` Matthew Brett 0 siblings, 0 replies; 27+ messages in thread From: Matthew Brett @ 2007-01-17 9:02 UTC (permalink / raw) To: Luming Yu Cc: Bjorn Helgaas, Karasyov, Konstantin A, Alexey Starikovskiy, Salatiel Filho, linux-acpi Hi, > Does it really solve the problem of CPU fan shutting down on load of fan.ko? > Could you just re-test, since that is the problem from the beginning. Yes; normally fan.ko is insmodded in my boot sequence. At that point in the boot sequence the fan turns off and cannot be turned on again (see results of echos to fan state earlier). After the DSDT patch, the fan stays on through the boot sequence, fan.ko is shown as loaded via lsmod, and echos to fan state behave as expected. Best, Matthew ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-15 13:33 ` Karasyov, Konstantin A 2007-01-15 17:06 ` Bjorn Helgaas @ 2007-01-16 16:54 ` Bjorn Helgaas 2007-01-19 12:37 ` Karasyov, Konstantin A 1 sibling, 1 reply; 27+ messages in thread From: Bjorn Helgaas @ 2007-01-16 16:54 UTC (permalink / raw) To: Karasyov, Konstantin A Cc: Alexey Starikovskiy, Matthew Brett, Salatiel Filho, linux-acpi On Monday 15 January 2007 06:33, Karasyov, Konstantin A wrote: > The fan device FAN1 defines object FN01 as its power resource. _STA > method of FN01 always return 0x01, i.e. resource is on. So the fan > driver is unable to turn the fan on, because it thinks that it is > already in that state. The code looks like this: int acpi_bus_set_power(acpi_handle handle, int state) { ... if (!device->flags.force_power_state) { if (device->power.state == ACPI_STATE_UNKNOWN) acpi_bus_get_power(device->handle, &device->power.state) if (state == device->power.state) { return 0; /* already at desired state */ } ... acpi_power_transition(device, state); Why do we bother with the "acpi_bus_get_power" at all? The problem Matthew is seeing wouldn't happen at all if we just deleted everything in the force_power_state block. Then we could execute _ON, _PS0, etc for a device that is already on. Does that cause bad things to happen? I assume the fan probably works as desired under Windows, so they probably do something like this. Bjorn ^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-16 16:54 ` Bjorn Helgaas @ 2007-01-19 12:37 ` Karasyov, Konstantin A 0 siblings, 0 replies; 27+ messages in thread From: Karasyov, Konstantin A @ 2007-01-19 12:37 UTC (permalink / raw) To: Bjorn Helgaas Cc: Alexey Starikovskiy, Matthew Brett, Salatiel Filho, linux-acpi >Why do we bother with the "acpi_bus_get_power" at all? The problem >Matthew is seeing wouldn't happen at all if we just deleted everything >in the force_power_state block. > >Then we could execute _ON, _PS0, etc for a device that is already on. >Does that cause bad things to happen? I assume the fan probably works >as desired under Windows, so they probably do something like this. This would work for _PSx (if device power states are controlled via _PSx methods, we should only execute method, defined for desired power state), but if power states are controlled via power resources, we should execute _ON method of power resource, assigned for desired state AND _OFF method of power resource, assigned for the current power state, so we cannot just ignore the current device power state. Regards. Konstantin. >-----Original Message----- >From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi- >owner@vger.kernel.org] On Behalf Of Bjorn Helgaas >Sent: Tuesday, January 16, 2007 7:54 PM >To: Karasyov, Konstantin A >Cc: Alexey Starikovskiy; Matthew Brett; Salatiel Filho; linux- >acpi@vger.kernel.org >Subject: Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 >and later > >On Monday 15 January 2007 06:33, Karasyov, Konstantin A wrote: >> The fan device FAN1 defines object FN01 as its power resource. _STA >> method of FN01 always return 0x01, i.e. resource is on. So the fan >> driver is unable to turn the fan on, because it thinks that it is >> already in that state. > >The code looks like this: > > int acpi_bus_set_power(acpi_handle handle, int state) > { > ... > if (!device->flags.force_power_state) { > if (device->power.state == ACPI_STATE_UNKNOWN) > acpi_bus_get_power(device->handle, &device->power.state) > if (state == device->power.state) { > return 0; /* already at desired state */ > } > ... > acpi_power_transition(device, state); > >Why do we bother with the "acpi_bus_get_power" at all? The problem >Matthew is seeing wouldn't happen at all if we just deleted everything >in the force_power_state block. > >Then we could execute _ON, _PS0, etc for a device that is already on. >Does that cause bad things to happen? I assume the fan probably works >as desired under Windows, so they probably do something like this. > >Bjorn > >- >To unsubscribe from this list: send the line "unsubscribe linux-acpi" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later
@ 2006-12-28 17:14 Matthew Brett
2006-12-28 21:03 ` Alexey Starikovskiy
2007-01-09 16:53 ` Karasyov, Konstantin A
0 siblings, 2 replies; 27+ messages in thread
From: Matthew Brett @ 2006-12-28 17:14 UTC (permalink / raw)
To: linux-acpi
Hi,
CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later
On my emachines 370, the CPU fan stops immediately on load of fan.ko
during boot up. It does not seem to come back on again even on high
CPU load and very hot heatsink. Removing fan.ko from the drivers/acpi
directory solves the problem, but insmodding fan.ko after boot again
stops the fan. 2.6.17 vanilla does not show the problem, nor does
2.6.17-5mdv (Mandriva) but 2.6.18, 2.6.19.1, and 2.6.20-rc2 do. The
problem seems to have been noticed before on Suse:
http://www.suseforums.net/lofiversion/index.php/t28013.html
The machine is an otherwise well behaved celeron 1.8, 1GB memory,
with Trigem imperial GL VE motherboard, phoenix bios.
Keywords: fan, cpu, acpi, driver
To reproduce: boot sequence inserting fan.ko, or insmod fan.ko after
boot.
Other bug report details follow,
Thanks a lot,
Matthew
Environment:
Linux bob.dynevor.org 2.6.20-rc2emach #0 SMP Thu Dec 28 09:55:13 GMT
2006 i686 Intel(R) Celeron(R) CPU 1.80GHz GNU/Linux
Gnu C 4.1.1
Gnu make 3.81
binutils 2.16.91.0.7
util-linux 2.12r
mount 2.12r
module-init-tools 3.2.2
e2fsprogs 1.39
PPP 2.4.3
Linux C Library > libc.2.4
Dynamic linker (ldd) 2.4
Procps 3.2.6
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.97
udev 098
wireless-tools 28
Modules Loaded i915 drm autofs4 ipv6 usblp rfcomm snd_pcm_oss
snd_mixer_oss snd_usb_audio snd_pcm snd_timer l2cap snd_page_alloc
bluetooth snd_usb_lib snd_rawmidi snd_seq_device snd_hwdep snd
soundcore 8139too mii af_packet ide_cd binfmt_misc loop vfat fat
dm_mod video thermal processor fan container button battery asus_acpi
backlight ac cpufreq_ondemand cpufreq_conservative cpufreq_powersave
p4_clockmod speedstep_lib freq_table intel_agp agpgart nvram sr_mod
scsi_mod evdev tsdev usbmouse usbhid hid ehci_hcd ff_memless uhci_hcd
usbcore ext3 jbd
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 1
model name : Intel(R) Celeron(R) CPU 1.80GHz
stepping : 3
cpu MHz : 1800.000
cache size : 128 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm up
bogomips : 3584.28
cat /proc/modules
i915 24448 2 - Live 0xf8b9e000
drm 71444 3 i915, Live 0xf8bac000
autofs4 20740 1 - Live 0xf8b72000
ipv6 242848 16 - Live 0xf8bdd000
usblp 15232 0 - Live 0xf89ad000
rfcomm 38552 2 - Live 0xf8b8a000
snd_pcm_oss 40864 0 - Live 0xf8b7f000
snd_mixer_oss 17536 1 snd_pcm_oss, Live 0xf8b6c000
snd_usb_audio 75360 0 - Live 0xf8b44000
snd_pcm 68996 2 snd_pcm_oss,snd_usb_audio, Live 0xf8b5a000
snd_timer 21508 1 snd_pcm, Live 0xf8b3d000
l2cap 26624 5 rfcomm, Live 0xf8b27000
snd_page_alloc 11400 1 snd_pcm, Live 0xf8b11000
bluetooth 50916 4 rfcomm,l2cap, Live 0xf8b2f000
snd_usb_lib 17408 1 snd_usb_audio, Live 0xf8b18000
snd_rawmidi 21920 1 snd_usb_lib, Live 0xf8afd000
snd_seq_device 10252 1 snd_rawmidi, Live 0xf8af9000
snd_hwdep 10500 1 snd_usb_audio, Live 0xf8af5000
snd 45668 8 snd_pcm_oss,snd_mixer_oss,snd_usb_audio,snd_pcm,snd_timer,snd_rawmidi,snd_seq_device,snd_hwdep,
Live 0xf8b04000
soundcore 9824 1 snd, Live 0xf8af1000
8139too 25344 0 - Live 0xf8ade000
mii 8576 1 8139too, Live 0xf8ada000
af_packet 23304 2 - Live 0xf89b7000
ide_cd 37920 0 - Live 0xf8ae6000
binfmt_misc 12680 1 - Live 0xf89b2000
loop 16264 0 - Live 0xf8995000
vfat 13952 0 - Live 0xf899a000
fat 47772 1 vfat, Live 0xf8acd000
dm_mod 50252 0 - Live 0xf89be000
video 17668 0 - Live 0xf89a7000
thermal 15240 0 - Live 0xf88ee000
processor 28520 1 thermal, Live 0xf899f000
fan 7556 0 - Live 0xf8992000
container 7296 0 - Live 0xf898f000
button 10000 0 - Live 0xf8985000
battery 12036 0 - Live 0xf8981000
asus_acpi 18972 0 - Live 0xf8989000
backlight 8448 1 asus_acpi, Live 0xf88fa000
ac 7812 0 - Live 0xf88f7000
cpufreq_ondemand 10508 0 - Live 0xf88f3000
cpufreq_conservative 9992 0 - Live 0xf88b4000
cpufreq_powersave 5632 0 - Live 0xf88cb000
p4_clockmod 8708 0 - Live 0xf88c7000
speedstep_lib 7940 1 p4_clockmod, Live 0xf88bb000
freq_table 7936 2 cpufreq_ondemand,p4_clockmod, Live 0xf88b8000
intel_agp 24092 1 - Live 0xf88a7000
agpgart 29128 3 drm,intel_agp, Live 0xf88be000
nvram 11144 0 - Live 0xf8898000
sr_mod 17828 0 - Live 0xf88ae000
scsi_mod 122124 1 sr_mod, Live 0xf88cf000
evdev 11904 1 - Live 0xf8894000
tsdev 10048 0 - Live 0xf8890000
usbmouse 8192 0 - Live 0xf885a000
usbhid 36896 0 - Live 0xf889c000
hid 27268 1 usbhid, Live 0xf887d000
ehci_hcd 31500 0 - Live 0xf8887000
ff_memless 8840 1 usbhid, Live 0xf881c000
uhci_hcd 24080 0 - Live 0xf8825000
usbcore 115720 8
usblp,snd_usb_audio,snd_usb_lib,usbmouse,usbhid,ehci_hcd,uhci_hcd,
Live 0xf883c000
ext3 117128 1 - Live 0xf885f000
jbd 52008 1 ext3, Live 0xf882e000
cat /proc/ioports
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : 0000:00:1f.1
0170-0177 : ide1
01f0-01f7 : 0000:00:1f.1
01f0-01f7 : ide0
0376-0376 : 0000:00:1f.1
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : 0000:00:1f.1
03f6-03f6 : ide0
03f8-03ff : serial
0cf8-0cff : PCI conf1
1000-107f : 0000:00:1f.0
1000-107f : motherboard
1000-1003 : ACPI PM1a_EVT_BLK
1004-1005 : ACPI PM1a_CNT_BLK
1008-100b : ACPI PM_TMR
1010-1015 : ACPI CPU throttle
1020-1020 : ACPI PM2_CNT_BLK
1028-102f : ACPI GPE0_BLK
1180-11bf : 0000:00:1f.0
1180-11bf : motherboard
1800-181f : 0000:00:1d.0
1800-181f : uhci_hcd
1820-183f : 0000:00:1d.1
1820-183f : uhci_hcd
1840-185f : 0000:00:1d.2
1840-185f : uhci_hcd
1860-186f : 0000:00:1f.1
1860-1867 : ide0
1868-186f : ide1
1880-189f : 0000:00:1f.3
18c0-18ff : 0000:00:1f.5
1c00-1cff : 0000:00:1f.5
2000-2fff : PCI Bus #02
2000-20ff : 0000:02:02.0
cat /proc/ioports
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : 0000:00:1f.1
0170-0177 : ide1
01f0-01f7 : 0000:00:1f.1
01f0-01f7 : ide0
0376-0376 : 0000:00:1f.1
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : 0000:00:1f.1
03f6-03f6 : ide0
03f8-03ff : serial
0cf8-0cff : PCI conf1
1000-107f : 0000:00:1f.0
1000-107f : motherboard
1000-1003 : ACPI PM1a_EVT_BLK
1004-1005 : ACPI PM1a_CNT_BLK
1008-100b : ACPI PM_TMR
1010-1015 : ACPI CPU throttle
1020-1020 : ACPI PM2_CNT_BLK
1028-102f : ACPI GPE0_BLK
1180-11bf : 0000:00:1f.0
1180-11bf : motherboard
1800-181f : 0000:00:1d.0
1800-181f : uhci_hcd
1820-183f : 0000:00:1d.1
1820-183f : uhci_hcd
1840-185f : 0000:00:1d.2
1840-185f : uhci_hcd
1860-186f : 0000:00:1f.1
1860-1867 : ide0
1868-186f : ide1
1880-189f : 0000:00:1f.3
18c0-18ff : 0000:00:1f.5
1c00-1cff : 0000:00:1f.5
2000-2fff : PCI Bus #02
2000-20ff : 0000:02:02.0
2000-20ff : 8139too
fe00-fe00 : motherboard
[root@bob ~]#
[root@bob ~]# cat /proc/iomem
00000000-0009efff : System RAM
00000000-00000000 : Crash kernel
0009f000-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-3fceffff : System RAM
00100000-002e9ef0 : Kernel code
002e9ef1-003a23f3 : Kernel data
3fcf0000-3fcfefff : ACPI Tables
3fcff000-3fcfffff : ACPI Non-volatile Storage
3fd00000-3fe7ffff : System RAM
3fe80000-3fffffff : reserved
50000000-500003ff : 0000:00:1f.1
e8000000-e807ffff : 0000:00:02.0
e8080000-e80803ff : 0000:00:1d.7
e8080000-e80803ff : ehci_hcd
e8080800-e80808ff : 0000:00:1f.5
e8080c00-e8080dff : 0000:00:1f.5
e8100000-e81fffff : PCI Bus #02
e8100000-e81000ff : 0000:02:02.0
e8100000-e81000ff : 8139too
ec000000-efffffff : 0000:00:00.0
f0000000-f7ffffff : 0000:00:02.0
ff800000-ffbfffff : reserved
fff00000-ffffffff : reserved
lspci -vvv
00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE
DRAM Controller/Host-Hub Interface (rev 01)
Subsystem: Trigem Computer Inc. Unknown device 3189
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
Latency: 0
Region 0: Memory at ec000000 (32-bit, prefetchable) [size=64M]
Capabilities: [e4] Vendor Specific Information
00:02.0 VGA compatible controller: Intel Corporation
82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)
(prog-if 00 [VGA])
Subsystem: Trigem Computer Inc. Unknown device 3189
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 17
Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M]
Region 1: Memory at e8000000 (32-bit, non-prefetchable) [size=512K]
Capabilities: [d0] Power Management version 1
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) (prog-if 00
[UHCI])
Subsystem: Trigem Computer Inc. Unknown device 3189
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 17
Region 4: I/O ports at 1800 [size=32]
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) (prog-if 00
[UHCI])
Subsystem: Trigem Computer Inc. Unknown device 3189
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 18
Region 4: I/O ports at 1820 [size=32]
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) (prog-if 00
[UHCI])
Subsystem: Trigem Computer Inc. Unknown device 3189
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin C routed to IRQ 16
Region 4: I/O ports at 1840 [size=32]
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M)
USB2 EHCI Controller (rev 01) (prog-if 20 [EHCI])
Subsystem: Trigem Computer Inc. Unknown device 3189
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin D routed to IRQ 19
Region 0: Memory at e8080000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 81)
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR+
Latency: 0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
I/O behind bridge: 00002000-00002fff
Memory behind bridge: e8100000-e81fffff
Prefetchable memory behind bridge: fff00000-000fffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC
Interface Bridge (rev 01)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller
(rev 01) (prog-if 8a [Master SecP PriP])
Subsystem: Trigem Computer Inc. Unknown device 3189
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at 01f0 [size=8]
Region 1: I/O ports at 03f4 [size=1]
Region 2: I/O ports at 0170 [size=8]
Region 3: I/O ports at 0374 [size=1]
Region 4: I/O ports at 1860 [size=16]
Region 5: Memory at 50000000 (32-bit, non-prefetchable) [size=1K]
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
SMBus Controller (rev 01)
Subsystem: Trigem Computer Inc. Unknown device 3189
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin B routed to IRQ 9
Region 4: I/O ports at 1880 [size=32]
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
Subsystem: Trigem Computer Inc. Unknown device 3189
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 9
Region 0: I/O ports at 1c00 [size=256]
Region 1: I/O ports at 18c0 [size=64]
Region 2: Memory at e8080c00 (32-bit, non-prefetchable) [size=512]
Region 3: Memory at e8080800 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
02:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Trigem Computer Inc. Unknown device 3189
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (8000ns min, 16000ns max)
Interrupt: pin A routed to IRQ 20
Region 0: I/O ports at 2000 [size=256]
Region 1: Memory at e8100000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2006-12-28 17:14 Matthew Brett @ 2006-12-28 21:03 ` Alexey Starikovskiy 2006-12-28 23:36 ` Matthew Brett 2007-01-09 16:53 ` Karasyov, Konstantin A 1 sibling, 1 reply; 27+ messages in thread From: Alexey Starikovskiy @ 2006-12-28 21:03 UTC (permalink / raw) To: Matthew Brett; +Cc: linux-acpi Hi, Please look at bugzilla.kernel.org #7570, it could be same issue. Regards, Alex. Matthew Brett wrote: > Hi, > > CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later > > On my emachines 370, the CPU fan stops immediately on load of fan.ko > during boot up. It does not seem to come back on again even on high > CPU load and very hot heatsink. Removing fan.ko from the drivers/acpi > directory solves the problem, but insmodding fan.ko after boot again > stops the fan. 2.6.17 vanilla does not show the problem, nor does > 2.6.17-5mdv (Mandriva) but 2.6.18, 2.6.19.1, and 2.6.20-rc2 do. The > problem seems to have been noticed before on Suse: > > http://www.suseforums.net/lofiversion/index.php/t28013.html > > The machine is an otherwise well behaved celeron 1.8, 1GB memory, > with Trigem imperial GL VE motherboard, phoenix bios. > > Keywords: fan, cpu, acpi, driver > > To reproduce: boot sequence inserting fan.ko, or insmod fan.ko after > boot. > > Other bug report details follow, > > Thanks a lot, > > Matthew > > > Environment: > > Linux bob.dynevor.org 2.6.20-rc2emach #0 SMP Thu Dec 28 09:55:13 GMT > 2006 i686 Intel(R) Celeron(R) CPU 1.80GHz GNU/Linux > > Gnu C 4.1.1 > Gnu make 3.81 > binutils 2.16.91.0.7 > util-linux 2.12r > mount 2.12r > module-init-tools 3.2.2 > e2fsprogs 1.39 > PPP 2.4.3 > Linux C Library > libc.2.4 > Dynamic linker (ldd) 2.4 > Procps 3.2.6 > Net-tools 1.60 > Console-tools 0.2.3 > Sh-utils 5.97 > udev 098 > wireless-tools 28 > Modules Loaded i915 drm autofs4 ipv6 usblp rfcomm snd_pcm_oss > snd_mixer_oss snd_usb_audio snd_pcm snd_timer l2cap snd_page_alloc > bluetooth snd_usb_lib snd_rawmidi snd_seq_device snd_hwdep snd > soundcore 8139too mii af_packet ide_cd binfmt_misc loop vfat fat > dm_mod video thermal processor fan container button battery asus_acpi > backlight ac cpufreq_ondemand cpufreq_conservative cpufreq_powersave > p4_clockmod speedstep_lib freq_table intel_agp agpgart nvram sr_mod > scsi_mod evdev tsdev usbmouse usbhid hid ehci_hcd ff_memless uhci_hcd > usbcore ext3 jbd > > cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 15 > model : 1 > model name : Intel(R) Celeron(R) CPU 1.80GHz > stepping : 3 > cpu MHz : 1800.000 > cache size : 128 KB > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 2 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm up > bogomips : 3584.28 > > cat /proc/modules > i915 24448 2 - Live 0xf8b9e000 > drm 71444 3 i915, Live 0xf8bac000 > autofs4 20740 1 - Live 0xf8b72000 > ipv6 242848 16 - Live 0xf8bdd000 > usblp 15232 0 - Live 0xf89ad000 > rfcomm 38552 2 - Live 0xf8b8a000 > snd_pcm_oss 40864 0 - Live 0xf8b7f000 > snd_mixer_oss 17536 1 snd_pcm_oss, Live 0xf8b6c000 > snd_usb_audio 75360 0 - Live 0xf8b44000 > snd_pcm 68996 2 snd_pcm_oss,snd_usb_audio, Live 0xf8b5a000 > snd_timer 21508 1 snd_pcm, Live 0xf8b3d000 > l2cap 26624 5 rfcomm, Live 0xf8b27000 > snd_page_alloc 11400 1 snd_pcm, Live 0xf8b11000 > bluetooth 50916 4 rfcomm,l2cap, Live 0xf8b2f000 > snd_usb_lib 17408 1 snd_usb_audio, Live 0xf8b18000 > snd_rawmidi 21920 1 snd_usb_lib, Live 0xf8afd000 > snd_seq_device 10252 1 snd_rawmidi, Live 0xf8af9000 > snd_hwdep 10500 1 snd_usb_audio, Live 0xf8af5000 > snd 45668 8 > snd_pcm_oss,snd_mixer_oss,snd_usb_audio,snd_pcm,snd_timer,snd_rawmidi,snd_seq_device,snd_hwdep, > > Live 0xf8b04000 > soundcore 9824 1 snd, Live 0xf8af1000 > 8139too 25344 0 - Live 0xf8ade000 > mii 8576 1 8139too, Live 0xf8ada000 > af_packet 23304 2 - Live 0xf89b7000 > ide_cd 37920 0 - Live 0xf8ae6000 > binfmt_misc 12680 1 - Live 0xf89b2000 > loop 16264 0 - Live 0xf8995000 > vfat 13952 0 - Live 0xf899a000 > fat 47772 1 vfat, Live 0xf8acd000 > dm_mod 50252 0 - Live 0xf89be000 > video 17668 0 - Live 0xf89a7000 > thermal 15240 0 - Live 0xf88ee000 > processor 28520 1 thermal, Live 0xf899f000 > fan 7556 0 - Live 0xf8992000 > container 7296 0 - Live 0xf898f000 > button 10000 0 - Live 0xf8985000 > battery 12036 0 - Live 0xf8981000 > asus_acpi 18972 0 - Live 0xf8989000 > backlight 8448 1 asus_acpi, Live 0xf88fa000 > ac 7812 0 - Live 0xf88f7000 > cpufreq_ondemand 10508 0 - Live 0xf88f3000 > cpufreq_conservative 9992 0 - Live 0xf88b4000 > cpufreq_powersave 5632 0 - Live 0xf88cb000 > p4_clockmod 8708 0 - Live 0xf88c7000 > speedstep_lib 7940 1 p4_clockmod, Live 0xf88bb000 > freq_table 7936 2 cpufreq_ondemand,p4_clockmod, Live 0xf88b8000 > intel_agp 24092 1 - Live 0xf88a7000 > agpgart 29128 3 drm,intel_agp, Live 0xf88be000 > nvram 11144 0 - Live 0xf8898000 > sr_mod 17828 0 - Live 0xf88ae000 > scsi_mod 122124 1 sr_mod, Live 0xf88cf000 > evdev 11904 1 - Live 0xf8894000 > tsdev 10048 0 - Live 0xf8890000 > usbmouse 8192 0 - Live 0xf885a000 > usbhid 36896 0 - Live 0xf889c000 > hid 27268 1 usbhid, Live 0xf887d000 > ehci_hcd 31500 0 - Live 0xf8887000 > ff_memless 8840 1 usbhid, Live 0xf881c000 > uhci_hcd 24080 0 - Live 0xf8825000 > usbcore 115720 8 > usblp,snd_usb_audio,snd_usb_lib,usbmouse,usbhid,ehci_hcd,uhci_hcd, > Live 0xf883c000 > ext3 117128 1 - Live 0xf885f000 > jbd 52008 1 ext3, Live 0xf882e000 > > cat /proc/ioports > 0000-001f : dma1 > 0020-0021 : pic1 > 0040-0043 : timer0 > 0050-0053 : timer1 > 0060-006f : keyboard > 0070-0077 : rtc > 0080-008f : dma page reg > 00a0-00a1 : pic2 > 00c0-00df : dma2 > 00f0-00ff : fpu > 0170-0177 : 0000:00:1f.1 > 0170-0177 : ide1 > 01f0-01f7 : 0000:00:1f.1 > 01f0-01f7 : ide0 > 0376-0376 : 0000:00:1f.1 > 0376-0376 : ide1 > 03c0-03df : vga+ > 03f6-03f6 : 0000:00:1f.1 > 03f6-03f6 : ide0 > 03f8-03ff : serial > 0cf8-0cff : PCI conf1 > 1000-107f : 0000:00:1f.0 > 1000-107f : motherboard > 1000-1003 : ACPI PM1a_EVT_BLK > 1004-1005 : ACPI PM1a_CNT_BLK > 1008-100b : ACPI PM_TMR > 1010-1015 : ACPI CPU throttle > 1020-1020 : ACPI PM2_CNT_BLK > 1028-102f : ACPI GPE0_BLK > 1180-11bf : 0000:00:1f.0 > 1180-11bf : motherboard > 1800-181f : 0000:00:1d.0 > 1800-181f : uhci_hcd > 1820-183f : 0000:00:1d.1 > 1820-183f : uhci_hcd > 1840-185f : 0000:00:1d.2 > 1840-185f : uhci_hcd > 1860-186f : 0000:00:1f.1 > 1860-1867 : ide0 > 1868-186f : ide1 > 1880-189f : 0000:00:1f.3 > 18c0-18ff : 0000:00:1f.5 > 1c00-1cff : 0000:00:1f.5 > 2000-2fff : PCI Bus #02 > 2000-20ff : 0000:02:02.0 > > cat /proc/ioports > 0000-001f : dma1 > 0020-0021 : pic1 > 0040-0043 : timer0 > 0050-0053 : timer1 > 0060-006f : keyboard > 0070-0077 : rtc > 0080-008f : dma page reg > 00a0-00a1 : pic2 > 00c0-00df : dma2 > 00f0-00ff : fpu > 0170-0177 : 0000:00:1f.1 > 0170-0177 : ide1 > 01f0-01f7 : 0000:00:1f.1 > 01f0-01f7 : ide0 > 0376-0376 : 0000:00:1f.1 > 0376-0376 : ide1 > 03c0-03df : vga+ > 03f6-03f6 : 0000:00:1f.1 > 03f6-03f6 : ide0 > 03f8-03ff : serial > 0cf8-0cff : PCI conf1 > 1000-107f : 0000:00:1f.0 > 1000-107f : motherboard > 1000-1003 : ACPI PM1a_EVT_BLK > 1004-1005 : ACPI PM1a_CNT_BLK > 1008-100b : ACPI PM_TMR > 1010-1015 : ACPI CPU throttle > 1020-1020 : ACPI PM2_CNT_BLK > 1028-102f : ACPI GPE0_BLK > 1180-11bf : 0000:00:1f.0 > 1180-11bf : motherboard > 1800-181f : 0000:00:1d.0 > 1800-181f : uhci_hcd > 1820-183f : 0000:00:1d.1 > 1820-183f : uhci_hcd > 1840-185f : 0000:00:1d.2 > 1840-185f : uhci_hcd > 1860-186f : 0000:00:1f.1 > 1860-1867 : ide0 > 1868-186f : ide1 > 1880-189f : 0000:00:1f.3 > 18c0-18ff : 0000:00:1f.5 > 1c00-1cff : 0000:00:1f.5 > 2000-2fff : PCI Bus #02 > 2000-20ff : 0000:02:02.0 > 2000-20ff : 8139too > fe00-fe00 : motherboard > [root@bob ~]# > [root@bob ~]# cat /proc/iomem > 00000000-0009efff : System RAM > 00000000-00000000 : Crash kernel > 0009f000-0009ffff : reserved > 000a0000-000bffff : Video RAM area > 000c0000-000c7fff : Video ROM > 000f0000-000fffff : System ROM > 00100000-3fceffff : System RAM > 00100000-002e9ef0 : Kernel code > 002e9ef1-003a23f3 : Kernel data > 3fcf0000-3fcfefff : ACPI Tables > 3fcff000-3fcfffff : ACPI Non-volatile Storage > 3fd00000-3fe7ffff : System RAM > 3fe80000-3fffffff : reserved > 50000000-500003ff : 0000:00:1f.1 > e8000000-e807ffff : 0000:00:02.0 > e8080000-e80803ff : 0000:00:1d.7 > e8080000-e80803ff : ehci_hcd > e8080800-e80808ff : 0000:00:1f.5 > e8080c00-e8080dff : 0000:00:1f.5 > e8100000-e81fffff : PCI Bus #02 > e8100000-e81000ff : 0000:02:02.0 > e8100000-e81000ff : 8139too > ec000000-efffffff : 0000:00:00.0 > f0000000-f7ffffff : 0000:00:02.0 > ff800000-ffbfffff : reserved > fff00000-ffffffff : reserved > > lspci -vvv > 00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE > DRAM Controller/Host-Hub Interface (rev 01) > Subsystem: Trigem Computer Inc. Unknown device 3189 > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- > <TAbort- <MAbort+ >SERR- <PERR- > Latency: 0 > Region 0: Memory at ec000000 (32-bit, prefetchable) [size=64M] > Capabilities: [e4] Vendor Specific Information > > 00:02.0 VGA compatible controller: Intel Corporation > 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01) > (prog-if 00 [VGA]) > Subsystem: Trigem Computer Inc. Unknown device 3189 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- > <TAbort- <MAbort- >SERR- <PERR- > Latency: 0 > Interrupt: pin A routed to IRQ 17 > Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M] > Region 1: Memory at e8000000 (32-bit, non-prefetchable) > [size=512K] > Capabilities: [d0] Power Management version 1 > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > > 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM > (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) (prog-if 00 > [UHCI]) > Subsystem: Trigem Computer Inc. Unknown device 3189 > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >> TAbort- <TAbort- <MAbort- >SERR- <PERR- > Latency: 0 > Interrupt: pin A routed to IRQ 17 > Region 4: I/O ports at 1800 [size=32] > > 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM > (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) (prog-if 00 > [UHCI]) > Subsystem: Trigem Computer Inc. Unknown device 3189 > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >> TAbort- <TAbort- <MAbort- >SERR- <PERR- > Latency: 0 > Interrupt: pin B routed to IRQ 18 > Region 4: I/O ports at 1820 [size=32] > > 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM > (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) (prog-if 00 > [UHCI]) > Subsystem: Trigem Computer Inc. Unknown device 3189 > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >> TAbort- <TAbort- <MAbort- >SERR- <PERR- > Latency: 0 > Interrupt: pin C routed to IRQ 16 > Region 4: I/O ports at 1840 [size=32] > > 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) > USB2 EHCI Controller (rev 01) (prog-if 20 [EHCI]) > Subsystem: Trigem Computer Inc. Unknown device 3189 > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >> TAbort- <TAbort- <MAbort- >SERR- <PERR- > Latency: 0 > Interrupt: pin D routed to IRQ 19 > Region 0: Memory at e8080000 (32-bit, non-prefetchable) [size=1K] > Capabilities: [50] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA > PME(D0+,D1-,D2-,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 81) > (prog-if 00 [Normal decode]) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR+ FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- > <TAbort- <MAbort- >SERR- <PERR+ > Latency: 0 > Bus: primary=00, secondary=02, subordinate=02, sec-latency=32 > I/O behind bridge: 00002000-00002fff > Memory behind bridge: e8100000-e81fffff > Prefetchable memory behind bridge: fff00000-000fffff > Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >> TAbort- <TAbort- <MAbort+ <SERR- <PERR- > BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- > > 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC > Interface Bridge (rev 01) > Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >> TAbort- <TAbort- <MAbort- >SERR- <PERR- > Latency: 0 > > 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller > (rev 01) (prog-if 8a [Master SecP PriP]) > Subsystem: Trigem Computer Inc. Unknown device 3189 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >> TAbort- <TAbort- <MAbort- >SERR- <PERR- > Latency: 0 > Interrupt: pin A routed to IRQ 16 > Region 0: I/O ports at 01f0 [size=8] > Region 1: I/O ports at 03f4 [size=1] > Region 2: I/O ports at 0170 [size=8] > Region 3: I/O ports at 0374 [size=1] > Region 4: I/O ports at 1860 [size=16] > Region 5: Memory at 50000000 (32-bit, non-prefetchable) [size=1K] > > 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) > SMBus Controller (rev 01) > Subsystem: Trigem Computer Inc. Unknown device 3189 > Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >> TAbort- <TAbort- <MAbort- >SERR- <PERR- > Interrupt: pin B routed to IRQ 9 > Region 4: I/O ports at 1880 [size=32] > > 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM > (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) > Subsystem: Trigem Computer Inc. Unknown device 3189 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >> TAbort- <TAbort- <MAbort- >SERR- <PERR- > Latency: 0 > Interrupt: pin B routed to IRQ 9 > Region 0: I/O ports at 1c00 [size=256] > Region 1: I/O ports at 18c0 [size=64] > Region 2: Memory at e8080c00 (32-bit, non-prefetchable) [size=512] > Region 3: Memory at e8080800 (32-bit, non-prefetchable) [size=256] > Capabilities: [50] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA > PME(D0+,D1-,D2-,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > > 02:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL-8139/8139C/8139C+ (rev 10) > Subsystem: Trigem Computer Inc. Unknown device 3189 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >> TAbort- <TAbort- <MAbort- >SERR- <PERR- > Latency: 64 (8000ns min, 16000ns max) > Interrupt: pin A routed to IRQ 20 > Region 0: I/O ports at 2000 [size=256] > Region 1: Memory at e8100000 (32-bit, non-prefetchable) [size=256] > Capabilities: [50] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA > PME(D0-,D1+,D2+,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > - > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2006-12-28 21:03 ` Alexey Starikovskiy @ 2006-12-28 23:36 ` Matthew Brett 2007-01-03 11:40 ` Matthew Brett 0 siblings, 1 reply; 27+ messages in thread From: Matthew Brett @ 2006-12-28 23:36 UTC (permalink / raw) To: Alexey Starikovskiy; +Cc: linux-acpi Hi, > Please look at bugzilla.kernel.org #7570, it could be same issue. ... > > CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later Thanks for the feedback - but it may be a different problem. First it occurs in a fully booted machine on insmod fan.ko (rather than on resume), and second, the patch for that bug does not fix it (2.6.20-rc2 tree). Best, Matthew ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2006-12-28 23:36 ` Matthew Brett @ 2007-01-03 11:40 ` Matthew Brett 2007-01-03 20:29 ` Bjorn Helgaas 0 siblings, 1 reply; 27+ messages in thread From: Matthew Brett @ 2007-01-03 11:40 UTC (permalink / raw) Cc: linux-acpi Hi, > > > CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later I am sorry to persist - but is there anything I can do further to help debug this problem? Or somewhere else that I should ask? I would not keep posting, but am worried that others with the same problem may not notice it until they have fried their hardware... Best, Matthew ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-03 11:40 ` Matthew Brett @ 2007-01-03 20:29 ` Bjorn Helgaas 2007-01-03 20:45 ` Alexey Starikovskiy 2007-01-07 20:10 ` Matthew Brett 0 siblings, 2 replies; 27+ messages in thread From: Bjorn Helgaas @ 2007-01-03 20:29 UTC (permalink / raw) To: Matthew Brett; +Cc: linux-acpi, konstantin.a.karasyov On Wednesday 03 January 2007 04:40, Matthew Brett wrote: > > > > CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later > > I am sorry to persist - but is there anything I can do further to help > debug this problem? Or somewhere else that I should ask? Thanks for your report and for persisting. This is exactly the right place to complain, but people might still be recovering from the holidays. There weren't many interesting changes in fan.c between 2.6.17 and 2.6.18. The problem you found is probably related to this: http://bugzilla.kernel.org/show_bug.cgi?id=5000 The patch in comment #24 looks like this for add and resume: result = acpi_bus_get_power(device->handle, &state); + if (state == ACPI_STATE_D0) + acpi_bus_set_power(fan->handle, ACPI_STATE_D3); + else if (state == ACPI_STATE_D3) + acpi_bus_set_power(fan->handle, ACPI_STATE_D0); + acpi_bus_set_power(fan->handle, state); whereas the code in 2.6.18 is this: result = acpi_bus_get_power(device->handle, &state); + device->flags.force_power_state = 1; + acpi_bus_set_power(device->handle, state); + device->flags.force_power_state = 0; It's interesting that the bugzilla patch inverts the fan power state while the 2.6.18 code does not. Konstantin can probably give you more useful help. I don't know the details of how the fan state is controlled. Bjorn ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-03 20:29 ` Bjorn Helgaas @ 2007-01-03 20:45 ` Alexey Starikovskiy 2007-01-07 20:10 ` Matthew Brett 1 sibling, 0 replies; 27+ messages in thread From: Alexey Starikovskiy @ 2007-01-03 20:45 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: Matthew Brett, linux-acpi, konstantin.a.karasyov Bjorn Helgaas wrote: > There weren't many interesting changes in fan.c between 2.6.17 and > 2.6.18. The problem you found is probably related to this: > http://bugzilla.kernel.org/show_bug.cgi?id=5000 > > The patch in comment #24 looks like this for add and resume: > > result = acpi_bus_get_power(device->handle, &state); > > + if (state == ACPI_STATE_D0) > + acpi_bus_set_power(fan->handle, ACPI_STATE_D3); > + else if (state == ACPI_STATE_D3) > + acpi_bus_set_power(fan->handle, ACPI_STATE_D0); > + acpi_bus_set_power(fan->handle, state); > > whereas the code in 2.6.18 is this: > > result = acpi_bus_get_power(device->handle, &state); > > + device->flags.force_power_state = 1; > + acpi_bus_set_power(device->handle, state); > + device->flags.force_power_state = 0; > > It's interesting that the bugzilla patch inverts the fan power state > while the 2.6.18 code does not. > > Konstantin can probably give you more useful help. I don't know > the details of how the fan state is controlled. > > Bjorn > I talked to Konstantin some time ago about this problem and he said that 2.6.18 contains some debug patch used in very beginning of 5000, which was picked up by someone else. Konstantin already sent a patch to convert to correct behavior, but its got stuck in ACPI pipeline... Regards, Alex. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-03 20:29 ` Bjorn Helgaas 2007-01-03 20:45 ` Alexey Starikovskiy @ 2007-01-07 20:10 ` Matthew Brett 2007-01-08 5:08 ` Bjorn Helgaas 1 sibling, 1 reply; 27+ messages in thread From: Matthew Brett @ 2007-01-07 20:10 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: linux-acpi, konstantin.a.karasyov Hi, I am sorry, I am a bit lost. Should I expect replacing: > + device->flags.force_power_state = 1; > + acpi_bus_set_power(device->handle, state); > + device->flags.force_power_state = 0; with: > + if (state == ACPI_STATE_D0) > + acpi_bus_set_power(fan->handle, ACPI_STATE_D3); > + else if (state == ACPI_STATE_D3) > + acpi_bus_set_power(fan->handle, ACPI_STATE_D0); > + acpi_bus_set_power(fan->handle, state); in fan.c from 2.6.20-rc3 should solve the problem (replacing fan->handle with device->handle)? It does not seem to. Thanks a lot for the feedback... Matthew ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-07 20:10 ` Matthew Brett @ 2007-01-08 5:08 ` Bjorn Helgaas 0 siblings, 0 replies; 27+ messages in thread From: Bjorn Helgaas @ 2007-01-08 5:08 UTC (permalink / raw) To: Matthew Brett; +Cc: linux-acpi, konstantin.a.karasyov On Sunday 07 January 2007 13:10, Matthew Brett wrote: > I am sorry, I am a bit lost. Should I expect replacing: > > > + device->flags.force_power_state = 1; > > + acpi_bus_set_power(device->handle, state); > > + device->flags.force_power_state = 0; > > with: > > > + if (state == ACPI_STATE_D0) > > + acpi_bus_set_power(fan->handle, ACPI_STATE_D3); > > + else if (state == ACPI_STATE_D3) > > + acpi_bus_set_power(fan->handle, ACPI_STATE_D0); > > + acpi_bus_set_power(fan->handle, state); > > in fan.c from 2.6.20-rc3 should solve the problem (replacing > fan->handle with device->handle)? It does not seem to. I think the "acpi_bus_set_power" call was added after 2.6.17. So if you remove it, I suspect your fan might work like it used to. I doubt that's the correct fix, though, because that call was probably added for a reason. Konstantin can probably speak to that. If you feel like experimenting, you could print out what state the BIOS tells you the fan is in (from the acpi_bus_get_power() call), try setting it to either ACPI_STATE_D0 or ACPI_STATE_D3, and see what the fan does. ^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2006-12-28 17:14 Matthew Brett 2006-12-28 21:03 ` Alexey Starikovskiy @ 2007-01-09 16:53 ` Karasyov, Konstantin A 2007-01-10 1:12 ` Matthew Brett 2007-01-10 3:18 ` Salatiel Filho 1 sibling, 2 replies; 27+ messages in thread From: Karasyov, Konstantin A @ 2007-01-09 16:53 UTC (permalink / raw) To: Matthew Brett, linux-acpi Hi Matthew, Could you please perform the following testing: 1. boot, make sure the fan doesn't spin. 2. do 'cat /proc/acpi/thermal/*/*', check the following: - the 'state' field shows 'active[<smthng>]' (if not - perform some CPU-intensive task); - fan still doesn't spin, 3. do 'cat /proc/acpi/fan/*/state', check the following: - the 'status' field shows 'on' (at least one of them); - fan still doesn't spin, 4a. do consequently (as root) the following: - 'echo 3 > /proc/acpi/fan/*/state' - 'echo 0 > /proc/acpi/fan/*/state' (the fan should be that one, which shown 'on' in step 3) 4b. (if step 3 failed) do (as root) 'echo 0 > /proc/acpi/fan/*/state' consequently for each fan device under /proc/acpi/fan/, check the following: - fans start spinning; - fans' states are correct ('cat /proc/acpi/fan/*/state' command) 5. check if the fan(s) start spinning. Please, get back to me with the results, test flow description and commands' outputs. Also, you could try the patches from bugs ##7122, 7570 for 2.6.20-rc3 to see if it help. Regards. Konstantin. >-----Original Message----- >From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi- >owner@vger.kernel.org] On Behalf Of Matthew Brett >Sent: Thursday, December 28, 2006 8:15 PM >To: linux-acpi@vger.kernel.org >Subject: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and >later > >Hi, > >CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later > >On my emachines 370, the CPU fan stops immediately on load of fan.ko >during boot up. It does not seem to come back on again even on high >CPU load and very hot heatsink. Removing fan.ko from the drivers/acpi >directory solves the problem, but insmodding fan.ko after boot again >stops the fan. 2.6.17 vanilla does not show the problem, nor does >2.6.17-5mdv (Mandriva) but 2.6.18, 2.6.19.1, and 2.6.20-rc2 do. The >problem seems to have been noticed before on Suse: > >http://www.suseforums.net/lofiversion/index.php/t28013.html > >The machine is an otherwise well behaved celeron 1.8, 1GB memory, >with Trigem imperial GL VE motherboard, phoenix bios. > >Keywords: fan, cpu, acpi, driver > >To reproduce: boot sequence inserting fan.ko, or insmod fan.ko after >boot. > >Other bug report details follow, > >Thanks a lot, > >Matthew > > >Environment: > >Linux bob.dynevor.org 2.6.20-rc2emach #0 SMP Thu Dec 28 09:55:13 GMT >2006 i686 Intel(R) Celeron(R) CPU 1.80GHz GNU/Linux > >Gnu C 4.1.1 >Gnu make 3.81 >binutils 2.16.91.0.7 >util-linux 2.12r >mount 2.12r >module-init-tools 3.2.2 >e2fsprogs 1.39 >PPP 2.4.3 >Linux C Library > libc.2.4 >Dynamic linker (ldd) 2.4 >Procps 3.2.6 >Net-tools 1.60 >Console-tools 0.2.3 >Sh-utils 5.97 >udev 098 >wireless-tools 28 >Modules Loaded i915 drm autofs4 ipv6 usblp rfcomm snd_pcm_oss >snd_mixer_oss snd_usb_audio snd_pcm snd_timer l2cap snd_page_alloc >bluetooth snd_usb_lib snd_rawmidi snd_seq_device snd_hwdep snd >soundcore 8139too mii af_packet ide_cd binfmt_misc loop vfat fat >dm_mod video thermal processor fan container button battery asus_acpi >backlight ac cpufreq_ondemand cpufreq_conservative cpufreq_powersave >p4_clockmod speedstep_lib freq_table intel_agp agpgart nvram sr_mod >scsi_mod evdev tsdev usbmouse usbhid hid ehci_hcd ff_memless uhci_hcd >usbcore ext3 jbd > >cat /proc/cpuinfo >processor : 0 >vendor_id : GenuineIntel >cpu family : 15 >model : 1 >model name : Intel(R) Celeron(R) CPU 1.80GHz >stepping : 3 >cpu MHz : 1800.000 >cache size : 128 KB >fdiv_bug : no >hlt_bug : no >f00f_bug : no >coma_bug : no >fpu : yes >fpu_exception : yes >cpuid level : 2 >wp : yes >flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge >mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm up >bogomips : 3584.28 > >cat /proc/modules >i915 24448 2 - Live 0xf8b9e000 >drm 71444 3 i915, Live 0xf8bac000 >autofs4 20740 1 - Live 0xf8b72000 >ipv6 242848 16 - Live 0xf8bdd000 >usblp 15232 0 - Live 0xf89ad000 >rfcomm 38552 2 - Live 0xf8b8a000 >snd_pcm_oss 40864 0 - Live 0xf8b7f000 >snd_mixer_oss 17536 1 snd_pcm_oss, Live 0xf8b6c000 >snd_usb_audio 75360 0 - Live 0xf8b44000 >snd_pcm 68996 2 snd_pcm_oss,snd_usb_audio, Live 0xf8b5a000 >snd_timer 21508 1 snd_pcm, Live 0xf8b3d000 >l2cap 26624 5 rfcomm, Live 0xf8b27000 >snd_page_alloc 11400 1 snd_pcm, Live 0xf8b11000 >bluetooth 50916 4 rfcomm,l2cap, Live 0xf8b2f000 >snd_usb_lib 17408 1 snd_usb_audio, Live 0xf8b18000 >snd_rawmidi 21920 1 snd_usb_lib, Live 0xf8afd000 >snd_seq_device 10252 1 snd_rawmidi, Live 0xf8af9000 >snd_hwdep 10500 1 snd_usb_audio, Live 0xf8af5000 >snd 45668 8 >snd_pcm_oss,snd_mixer_oss,snd_usb_audio,snd_pcm,snd_timer,snd_rawmidi,s nd_s >eq_device,snd_hwdep, >Live 0xf8b04000 >soundcore 9824 1 snd, Live 0xf8af1000 >8139too 25344 0 - Live 0xf8ade000 >mii 8576 1 8139too, Live 0xf8ada000 >af_packet 23304 2 - Live 0xf89b7000 >ide_cd 37920 0 - Live 0xf8ae6000 >binfmt_misc 12680 1 - Live 0xf89b2000 >loop 16264 0 - Live 0xf8995000 >vfat 13952 0 - Live 0xf899a000 >fat 47772 1 vfat, Live 0xf8acd000 >dm_mod 50252 0 - Live 0xf89be000 >video 17668 0 - Live 0xf89a7000 >thermal 15240 0 - Live 0xf88ee000 >processor 28520 1 thermal, Live 0xf899f000 >fan 7556 0 - Live 0xf8992000 >container 7296 0 - Live 0xf898f000 >button 10000 0 - Live 0xf8985000 >battery 12036 0 - Live 0xf8981000 >asus_acpi 18972 0 - Live 0xf8989000 >backlight 8448 1 asus_acpi, Live 0xf88fa000 >ac 7812 0 - Live 0xf88f7000 >cpufreq_ondemand 10508 0 - Live 0xf88f3000 >cpufreq_conservative 9992 0 - Live 0xf88b4000 >cpufreq_powersave 5632 0 - Live 0xf88cb000 >p4_clockmod 8708 0 - Live 0xf88c7000 >speedstep_lib 7940 1 p4_clockmod, Live 0xf88bb000 >freq_table 7936 2 cpufreq_ondemand,p4_clockmod, Live 0xf88b8000 >intel_agp 24092 1 - Live 0xf88a7000 >agpgart 29128 3 drm,intel_agp, Live 0xf88be000 >nvram 11144 0 - Live 0xf8898000 >sr_mod 17828 0 - Live 0xf88ae000 >scsi_mod 122124 1 sr_mod, Live 0xf88cf000 >evdev 11904 1 - Live 0xf8894000 >tsdev 10048 0 - Live 0xf8890000 >usbmouse 8192 0 - Live 0xf885a000 >usbhid 36896 0 - Live 0xf889c000 >hid 27268 1 usbhid, Live 0xf887d000 >ehci_hcd 31500 0 - Live 0xf8887000 >ff_memless 8840 1 usbhid, Live 0xf881c000 >uhci_hcd 24080 0 - Live 0xf8825000 >usbcore 115720 8 >usblp,snd_usb_audio,snd_usb_lib,usbmouse,usbhid,ehci_hcd,uhci_hcd, >Live 0xf883c000 >ext3 117128 1 - Live 0xf885f000 >jbd 52008 1 ext3, Live 0xf882e000 > >cat /proc/ioports >0000-001f : dma1 >0020-0021 : pic1 >0040-0043 : timer0 >0050-0053 : timer1 >0060-006f : keyboard >0070-0077 : rtc >0080-008f : dma page reg >00a0-00a1 : pic2 >00c0-00df : dma2 >00f0-00ff : fpu >0170-0177 : 0000:00:1f.1 > 0170-0177 : ide1 >01f0-01f7 : 0000:00:1f.1 > 01f0-01f7 : ide0 >0376-0376 : 0000:00:1f.1 > 0376-0376 : ide1 >03c0-03df : vga+ >03f6-03f6 : 0000:00:1f.1 > 03f6-03f6 : ide0 >03f8-03ff : serial >0cf8-0cff : PCI conf1 >1000-107f : 0000:00:1f.0 > 1000-107f : motherboard > 1000-1003 : ACPI PM1a_EVT_BLK > 1004-1005 : ACPI PM1a_CNT_BLK > 1008-100b : ACPI PM_TMR > 1010-1015 : ACPI CPU throttle > 1020-1020 : ACPI PM2_CNT_BLK > 1028-102f : ACPI GPE0_BLK >1180-11bf : 0000:00:1f.0 > 1180-11bf : motherboard >1800-181f : 0000:00:1d.0 > 1800-181f : uhci_hcd >1820-183f : 0000:00:1d.1 > 1820-183f : uhci_hcd >1840-185f : 0000:00:1d.2 > 1840-185f : uhci_hcd >1860-186f : 0000:00:1f.1 > 1860-1867 : ide0 > 1868-186f : ide1 >1880-189f : 0000:00:1f.3 >18c0-18ff : 0000:00:1f.5 >1c00-1cff : 0000:00:1f.5 >2000-2fff : PCI Bus #02 > 2000-20ff : 0000:02:02.0 > >cat /proc/ioports >0000-001f : dma1 >0020-0021 : pic1 >0040-0043 : timer0 >0050-0053 : timer1 >0060-006f : keyboard >0070-0077 : rtc >0080-008f : dma page reg >00a0-00a1 : pic2 >00c0-00df : dma2 >00f0-00ff : fpu >0170-0177 : 0000:00:1f.1 > 0170-0177 : ide1 >01f0-01f7 : 0000:00:1f.1 > 01f0-01f7 : ide0 >0376-0376 : 0000:00:1f.1 > 0376-0376 : ide1 >03c0-03df : vga+ >03f6-03f6 : 0000:00:1f.1 > 03f6-03f6 : ide0 >03f8-03ff : serial >0cf8-0cff : PCI conf1 >1000-107f : 0000:00:1f.0 > 1000-107f : motherboard > 1000-1003 : ACPI PM1a_EVT_BLK > 1004-1005 : ACPI PM1a_CNT_BLK > 1008-100b : ACPI PM_TMR > 1010-1015 : ACPI CPU throttle > 1020-1020 : ACPI PM2_CNT_BLK > 1028-102f : ACPI GPE0_BLK >1180-11bf : 0000:00:1f.0 > 1180-11bf : motherboard >1800-181f : 0000:00:1d.0 > 1800-181f : uhci_hcd >1820-183f : 0000:00:1d.1 > 1820-183f : uhci_hcd >1840-185f : 0000:00:1d.2 > 1840-185f : uhci_hcd >1860-186f : 0000:00:1f.1 > 1860-1867 : ide0 > 1868-186f : ide1 >1880-189f : 0000:00:1f.3 >18c0-18ff : 0000:00:1f.5 >1c00-1cff : 0000:00:1f.5 >2000-2fff : PCI Bus #02 > 2000-20ff : 0000:02:02.0 > 2000-20ff : 8139too >fe00-fe00 : motherboard >[root@bob ~]# >[root@bob ~]# cat /proc/iomem >00000000-0009efff : System RAM > 00000000-00000000 : Crash kernel >0009f000-0009ffff : reserved >000a0000-000bffff : Video RAM area >000c0000-000c7fff : Video ROM >000f0000-000fffff : System ROM >00100000-3fceffff : System RAM > 00100000-002e9ef0 : Kernel code > 002e9ef1-003a23f3 : Kernel data >3fcf0000-3fcfefff : ACPI Tables >3fcff000-3fcfffff : ACPI Non-volatile Storage >3fd00000-3fe7ffff : System RAM >3fe80000-3fffffff : reserved >50000000-500003ff : 0000:00:1f.1 >e8000000-e807ffff : 0000:00:02.0 >e8080000-e80803ff : 0000:00:1d.7 > e8080000-e80803ff : ehci_hcd >e8080800-e80808ff : 0000:00:1f.5 >e8080c00-e8080dff : 0000:00:1f.5 >e8100000-e81fffff : PCI Bus #02 > e8100000-e81000ff : 0000:02:02.0 > e8100000-e81000ff : 8139too >ec000000-efffffff : 0000:00:00.0 >f0000000-f7ffffff : 0000:00:02.0 >ff800000-ffbfffff : reserved >fff00000-ffffffff : reserved > >lspci -vvv >00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE >DRAM Controller/Host-Hub Interface (rev 01) > Subsystem: Trigem Computer Inc. Unknown device 3189 > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >ParErr- Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- ><TAbort- <MAbort+ >SERR- <PERR- > Latency: 0 > Region 0: Memory at ec000000 (32-bit, prefetchable) [size=64M] > Capabilities: [e4] Vendor Specific Information > >00:02.0 VGA compatible controller: Intel Corporation >82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01) >(prog-if 00 [VGA]) > Subsystem: Trigem Computer Inc. Unknown device 3189 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >ParErr- Stepping- SERR- FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- ><TAbort- <MAbort- >SERR- <PERR- > Latency: 0 > Interrupt: pin A routed to IRQ 17 > Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M] > Region 1: Memory at e8000000 (32-bit, non-prefetchable) [size=512K] > Capabilities: [d0] Power Management version 1 > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA >PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > >00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM >(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) (prog-if 00 >[UHCI]) > Subsystem: Trigem Computer Inc. Unknown device 3189 > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- >ParErr- Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >>TAbort- <TAbort- <MAbort- >SERR- <PERR- > Latency: 0 > Interrupt: pin A routed to IRQ 17 > Region 4: I/O ports at 1800 [size=32] > >00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM >(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) (prog-if 00 >[UHCI]) > Subsystem: Trigem Computer Inc. Unknown device 3189 > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- >ParErr- Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >>TAbort- <TAbort- <MAbort- >SERR- <PERR- > Latency: 0 > Interrupt: pin B routed to IRQ 18 > Region 4: I/O ports at 1820 [size=32] > >00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM >(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) (prog-if 00 >[UHCI]) > Subsystem: Trigem Computer Inc. Unknown device 3189 > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- >ParErr- Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >>TAbort- <TAbort- <MAbort- >SERR- <PERR- > Latency: 0 > Interrupt: pin C routed to IRQ 16 > Region 4: I/O ports at 1840 [size=32] > >00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) >USB2 EHCI Controller (rev 01) (prog-if 20 [EHCI]) > Subsystem: Trigem Computer Inc. Unknown device 3189 > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >ParErr- Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >>TAbort- <TAbort- <MAbort- >SERR- <PERR- > Latency: 0 > Interrupt: pin D routed to IRQ 19 > Region 0: Memory at e8080000 (32-bit, non-prefetchable) [size=1K] > Capabilities: [50] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA >PME(D0+,D1-,D2-,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > >00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 81) >(prog-if 00 [Normal decode]) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >ParErr- Stepping- SERR+ FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- ><TAbort- <MAbort- >SERR- <PERR+ > Latency: 0 > Bus: primary=00, secondary=02, subordinate=02, sec-latency=32 > I/O behind bridge: 00002000-00002fff > Memory behind bridge: e8100000-e81fffff > Prefetchable memory behind bridge: fff00000-000fffff > Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >>TAbort- <TAbort- <MAbort+ <SERR- <PERR- > BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- > >00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC >Interface Bridge (rev 01) > Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- >ParErr- Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >>TAbort- <TAbort- <MAbort- >SERR- <PERR- > Latency: 0 > >00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller >(rev 01) (prog-if 8a [Master SecP PriP]) > Subsystem: Trigem Computer Inc. Unknown device 3189 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >ParErr- Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >>TAbort- <TAbort- <MAbort- >SERR- <PERR- > Latency: 0 > Interrupt: pin A routed to IRQ 16 > Region 0: I/O ports at 01f0 [size=8] > Region 1: I/O ports at 03f4 [size=1] > Region 2: I/O ports at 0170 [size=8] > Region 3: I/O ports at 0374 [size=1] > Region 4: I/O ports at 1860 [size=16] > Region 5: Memory at 50000000 (32-bit, non-prefetchable) [size=1K] > >00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) >SMBus Controller (rev 01) > Subsystem: Trigem Computer Inc. Unknown device 3189 > Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- >ParErr- Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >>TAbort- <TAbort- <MAbort- >SERR- <PERR- > Interrupt: pin B routed to IRQ 9 > Region 4: I/O ports at 1880 [size=32] > >00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM >(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) > Subsystem: Trigem Computer Inc. Unknown device 3189 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >ParErr- Stepping- SERR- FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >>TAbort- <TAbort- <MAbort- >SERR- <PERR- > Latency: 0 > Interrupt: pin B routed to IRQ 9 > Region 0: I/O ports at 1c00 [size=256] > Region 1: I/O ports at 18c0 [size=64] > Region 2: Memory at e8080c00 (32-bit, non-prefetchable) [size=512] > Region 3: Memory at e8080800 (32-bit, non-prefetchable) [size=256] > Capabilities: [50] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA >PME(D0+,D1-,D2-,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > >02:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. >RTL-8139/8139C/8139C+ (rev 10) > Subsystem: Trigem Computer Inc. Unknown device 3189 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >ParErr- Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >>TAbort- <TAbort- <MAbort- >SERR- <PERR- > Latency: 64 (8000ns min, 16000ns max) > Interrupt: pin A routed to IRQ 20 > Region 0: I/O ports at 2000 [size=256] > Region 1: Memory at e8100000 (32-bit, non-prefetchable) [size=256] > Capabilities: [50] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA >PME(D0-,D1+,D2+,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- >- >To unsubscribe from this list: send the line "unsubscribe linux-acpi" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-09 16:53 ` Karasyov, Konstantin A @ 2007-01-10 1:12 ` Matthew Brett 2007-01-10 3:18 ` Salatiel Filho 1 sibling, 0 replies; 27+ messages in thread From: Matthew Brett @ 2007-01-10 1:12 UTC (permalink / raw) To: Karasyov, Konstantin A; +Cc: linux-acpi Hi, > Could you please perform the following testing: Thanks a lot for the reply. Results of tests below. I've included the output from the 2.6.17 kernel and 2.6.20-rc3 kernel with comments. Patched kernel gave identical output to unpatched... CPU load did not turn on the fan as before. Best, Matthew 2.6.17 kernel, fan on at boot [root@bob ~]# cat /proc/acpi/thermal/*/* cat: /proc/acpi/thermal/*/*: No such file or directory [root@bob ~]# cat /proc/acpi/thermal_zone/*/* <setting not supported> cooling mode: passive <polling disabled> state: passive temperature: -270 C critical (S5): -264 C passive: -273 C: tc1=0 tc2=0 tsp=600 devices=0xf7ffd340 active[0]: -267 C: devices=0xf7ffd5c0 [root@bob ~]# cat /proc/acpi/fan/*/state status: on [root@bob ~]# echo 3 > /proc/acpi/fan/*/state -bash: echo: write error: Exec format error [Fan goes off] [root@bob ~]# echo 0 > /proc/acpi/fan/*/state [No effect, fan stays off] [root@bob ~]# 2.6.20-rc3 kernel, fan off at boot [root@bob ~]# cat /proc/acpi/thermal/*/* cat: /proc/acpi/thermal/*/*: No such file or directory [root@bob ~]# cat /proc/acpi/thermal_zone/*/* <setting not supported> cooling mode: passive <polling disabled> state: passive active[0] temperature: -266 C critical (S5): -264 C passive: -273 C: tc1=0 tc2=0 tsp=600 devices=0xc18fd2c0 active[0]: -267 C: devices=0xc18fd798 [root@bob ~]# cat /proc/acpi/fan/*/state status: on [root@bob ~]# echo 3 > /proc/acpi/fan/*/state -bash: echo: write error: Exec format error [No effect] [root@bob ~]# echo 0 > /proc/acpi/fan/*/state [No effect] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-09 16:53 ` Karasyov, Konstantin A 2007-01-10 1:12 ` Matthew Brett @ 2007-01-10 3:18 ` Salatiel Filho 2007-01-11 13:37 ` Karasyov, Konstantin A 1 sibling, 1 reply; 27+ messages in thread From: Salatiel Filho @ 2007-01-10 3:18 UTC (permalink / raw) To: Karasyov, Konstantin A; +Cc: Matthew Brett, linux-acpi On 1/9/07, Karasyov, Konstantin A <konstantin.a.karasyov@intel.com> wrote: > Hi Matthew, > > Could you please perform the following testing: Well , i tried to perform this steps in my machine since i think my fans are not working in linux. Well , for my surprise , i have absolutely nothing in # ls -lh /proc/acpi/fan/ total 0 > > 1. boot, make sure the fan doesn't spin. > > 2. do 'cat /proc/acpi/thermal/*/*', check the following: > - the 'state' field shows 'active[<smthng>]' > (if not - perform some CPU-intensive task); > - fan still doesn't spin, #cat /proc/acpi/thermal/*/* cat: /proc/acpi/thermal/*/*: No such file or directory #cat /proc/acpi/thermal_zone/*/* <setting not supported> cooling mode: critical <polling disabled> state: ok temperature: 60 C critical (S5): 99 C <setting not supported> cooling mode: critical <polling disabled> state: ok temperature: 27 C critical (S5): 105 C > > 3. do 'cat /proc/acpi/fan/*/state', check the following: > - the 'status' field shows 'on' (at least one of them); > - fan still doesn't spin, > # cat /proc/acpi/fan/*/state cat: /proc/acpi/fan/*/state: No such file or directory > 4a. do consequently (as root) the following: > - 'echo 3 > /proc/acpi/fan/*/state' > - 'echo 0 > /proc/acpi/fan/*/state' > (the fan should be that one, which shown 'on' in step 3) > > 4b. (if step 3 failed) do (as root) 'echo 0 > /proc/acpi/fan/*/state' > consequently for each fan device under /proc/acpi/fan/, check the > following: > - fans start spinning; > - fans' states are correct ('cat /proc/acpi/fan/*/state' > command) > > 5. check if the fan(s) start spinning. > > Please, get back to me with the results, test flow description and > commands' outputs. > > Also, you could try the patches from bugs ##7122, 7570 for 2.6.20-rc3 to > see if it help. > any ideas why i have no /proc/acpi/fan/*? Notebook HP Pavillion dv8230us -- []'s Salatiel "O maior prazer do inteligente é bancar o idiota diante de um idiota que banca o inteligente". - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-10 3:18 ` Salatiel Filho @ 2007-01-11 13:37 ` Karasyov, Konstantin A 2007-01-13 12:23 ` Matthew Brett 0 siblings, 1 reply; 27+ messages in thread From: Karasyov, Konstantin A @ 2007-01-11 13:37 UTC (permalink / raw) To: Salatiel Filho, Matthew Brett; +Cc: linux-acpi Hi, Could you send acpidump command output? Regards. Konstantin. >-----Original Message----- >From: Salatiel Filho [mailto:salatiel.filho@gmail.com] >Sent: Wednesday, January 10, 2007 6:19 AM >To: Karasyov, Konstantin A >Cc: Matthew Brett; linux-acpi@vger.kernel.org >Subject: Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 >and later > >On 1/9/07, Karasyov, Konstantin A <konstantin.a.karasyov@intel.com> wrote: >> Hi Matthew, >> >> Could you please perform the following testing: > > > >Well , i tried to perform this steps in my machine since i think my >fans are not working in linux. Well , for my surprise , i have >absolutely nothing in > ># ls -lh /proc/acpi/fan/ >total 0 > > > >> >> 1. boot, make sure the fan doesn't spin. >> >> 2. do 'cat /proc/acpi/thermal/*/*', check the following: >> - the 'state' field shows 'active[<smthng>]' >> (if not - perform some CPU-intensive task); >> - fan still doesn't spin, > >#cat /proc/acpi/thermal/*/* >cat: /proc/acpi/thermal/*/*: No such file or directory > >#cat /proc/acpi/thermal_zone/*/* ><setting not supported> >cooling mode: critical ><polling disabled> >state: ok >temperature: 60 C >critical (S5): 99 C ><setting not supported> >cooling mode: critical ><polling disabled> >state: ok >temperature: 27 C >critical (S5): 105 C > > > > >> >> 3. do 'cat /proc/acpi/fan/*/state', check the following: >> - the 'status' field shows 'on' (at least one of them); >> - fan still doesn't spin, >> > ># cat /proc/acpi/fan/*/state >cat: /proc/acpi/fan/*/state: No such file or directory > > > > >> 4a. do consequently (as root) the following: >> - 'echo 3 > /proc/acpi/fan/*/state' >> - 'echo 0 > /proc/acpi/fan/*/state' >> (the fan should be that one, which shown 'on' in step 3) >> >> 4b. (if step 3 failed) do (as root) 'echo 0 > /proc/acpi/fan/*/state' >> consequently for each fan device under /proc/acpi/fan/, check the >> following: >> - fans start spinning; >> - fans' states are correct ('cat /proc/acpi/fan/*/state' >> command) >> >> 5. check if the fan(s) start spinning. >> >> Please, get back to me with the results, test flow description and >> commands' outputs. >> >> Also, you could try the patches from bugs ##7122, 7570 for 2.6.20-rc3 to >> see if it help. >> > >any ideas why i have no /proc/acpi/fan/*? > >Notebook HP Pavillion dv8230us > >-- >[]'s >Salatiel > >"O maior prazer do inteligente é bancar o idiota > diante de um idiota que banca o inteligente". - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later 2007-01-11 13:37 ` Karasyov, Konstantin A @ 2007-01-13 12:23 ` Matthew Brett 0 siblings, 0 replies; 27+ messages in thread From: Matthew Brett @ 2007-01-13 12:23 UTC (permalink / raw) To: Karasyov, Konstantin A; +Cc: Salatiel Filho, linux-acpi [-- Attachment #1: Type: text/plain, Size: 89 bytes --] Hi, > Could you send acpidump command output? Sorry for the delay - attached, Matthew [-- Attachment #2: emach_acpi_dump.gz --] [-- Type: application/x-gzip, Size: 30999 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2007-01-19 12:37 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <beb91d720701110549r346991beh95547e912f68d98f@mail.gmail.com>
2007-01-11 14:15 ` PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later Karasyov, Konstantin A
2007-01-11 14:37 ` Salatiel Filho
2007-01-13 12:29 ` Matthew Brett
2007-01-13 13:12 ` Alexey Starikovskiy
2007-01-13 13:33 ` Matthew Brett
2007-01-13 15:51 ` Alexey Starikovskiy
2007-01-14 5:24 ` Bjorn Helgaas
2007-01-15 13:33 ` Karasyov, Konstantin A
2007-01-15 17:06 ` Bjorn Helgaas
2007-01-16 0:39 ` Matthew Brett
2007-01-17 2:49 ` Luming Yu
2007-01-17 9:02 ` Matthew Brett
2007-01-16 16:54 ` Bjorn Helgaas
2007-01-19 12:37 ` Karasyov, Konstantin A
2006-12-28 17:14 Matthew Brett
2006-12-28 21:03 ` Alexey Starikovskiy
2006-12-28 23:36 ` Matthew Brett
2007-01-03 11:40 ` Matthew Brett
2007-01-03 20:29 ` Bjorn Helgaas
2007-01-03 20:45 ` Alexey Starikovskiy
2007-01-07 20:10 ` Matthew Brett
2007-01-08 5:08 ` Bjorn Helgaas
2007-01-09 16:53 ` Karasyov, Konstantin A
2007-01-10 1:12 ` Matthew Brett
2007-01-10 3:18 ` Salatiel Filho
2007-01-11 13:37 ` Karasyov, Konstantin A
2007-01-13 12:23 ` Matthew Brett
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox