Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Sunday 23 December 2007 2:28:05 am Jean Delvare wrote: > Le 23/12/2007, Bjorn Helgaas a écrit: > >On Saturday 22 December 2007 4:21:41 am Jean Delvare wrote: > >> >This patch makes the it87 driver request only the two ports used for > >> > the Environment Controller device. > >> > >> The problem is that the IT87xxF chips do decode 4 ports (recent chips, > >> 0x294-0x297) or 8 ports (older chips, 0x290-0x297), not 2 as the > >> datasheets say. The ITE Super-I/O chips differ from the Winbond > >> Super-I/O chips in this respect. The it87 driver only needs to access > >> ports 0x295 and 0x296, true, but the device itself decodes more > >> addresses than that. So, with this proposed patch, ports which are busy > >> will be shown as being free. This pretty much voids the point of > >> resource declarations, doesn't it? This might not cause too much > >> trouble in practice, but to me this still looks like the wrong way to > >> go. > > > >Yes, all the ports decoded by the chip should certainly be reserved, > >but I think the entire range should be reserved at a higher level, > >like the PNP core, and the driver should reserve only the ports it > >uses. Then the entire range is reserved even if there is no driver > >or the driver is not loaded. > > The problem is that the it87 driver is used on a variety of motherboards, > some where the hardware monitoring device I/O ports are reserved by the > BIOS, some where they aren't. How am I supposed to deal with this? I assume you mean some boards describe those ports in ACPI, and some don't? I think the ideal solution would be to figure out how the BIOS writers intended the device to be used, and do that. But the documentation may be lacking, and it degenerates into an OEM-specific mess. Second-best seems like a PNP quirk that pokes enough to determine that a Super I/O device is present, and then reserves resources for it. Then we avoid the collision even if it87 isn't present. > >That's the approach we use for PCI, e.g., > > > > e810-e81f : :00:08.0 <-- reserved by PCI core > >e810-e8102fff : CS46xx_BA1_data0<-- reserved by driver > >e811-e81137ff : CS46xx_BA1_data1 > >e812-e8126fff : CS46xx_BA1_pmem > >e813-e81300ff : CS46xx_BA1_reg > > PCI is an entirely different beast. With PCI you know the PCI device ID > that is associated with the resources, and for a given device, the > resources are always declared (if standard BARs are used) or never > declared; there's no "may be". So it's much easier to handle the > resources properly. That's the way PNP is supposed to work, too (more about this below). > >> The resource declarations made by these motherboard BIOSes are totally > >> bogus. 0x290-0x29f is much larger than what the chip decodes. > >> 0x290-0x294 is a subset that doesn't make any sense. The GA-K8N Ultra 9 > >> is even funnier with 0x295-0x314, which again doesn't correspond to > >> anything real. > > > >I agree those declarations are probably wrong. But at least they're > >larger than required, so they should be safe. > > That's not really safe, no. They may overlap with other device resources > and prevent those drivers from loading. True. If that happens, I think we definitely need some kind of DMI- based quirk to fix the resources. My points are (a) the quirk needs to be at the PNP level; it can't be in a driver, and (b) I'm lazy and would wait until a problem happens before implementing it, because I know so little about PNP and the specific board, and by waiting, there's a chance I'll learn enough to avoid a mistake :-) > >> All these happen to not intersect with 0x295-0x296 but I > >> wouldn't count on it. If Gigabyte (and possibly others) care that > >> little about these declarations, pretty much anything could be seen. So > >> while your proposed workaround happens to fix the problem at hand, it is > >> not really correct technically, and could break again soon. > >> > >> I'd rather fix the problem at its source, or, as fixing it as the source > >> isn't very realistic in this case, as near of the source as possible. > >> That would mean DMI-based quirks for the affected motherboards, that > >> would discard or adjust the bogus resource declarations. > > > >Well, I think the driver change *is* correct, assuming that the > >entire range can be reserved at a higher level. In this case, > >it is, via a PNP0C02 device. > > As I wrote above, the problem is that you can't assume that. Some > motherboards do declare the range at PNP level but some don't. That's > the reason why the it87 driver (and most other hwmon drivers for > Super-I/O devices) do declare the I/O resource again. The overlapping device problem is a subsystem problem, not a driver problem. We can't solve it in the driver because we can't depend on the it87 driver being loaded. > Another problem is how do I connect this specific I/O port range of the > PNP0C02 device with the it87 driver? I am by far no PNP
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
Hi Bjorn, Le 23/12/2007, Bjorn Helgaas a écrit: >On Saturday 22 December 2007 4:21:41 am Jean Delvare wrote: >> >This patch makes the it87 driver request only the two ports used for the >> >Environment Controller device. >> >> The problem is that the IT87xxF chips do decode 4 ports (recent chips, >> 0x294-0x297) or 8 ports (older chips, 0x290-0x297), not 2 as the >> datasheets say. The ITE Super-I/O chips differ from the Winbond >> Super-I/O chips in this respect. The it87 driver only needs to access >> ports 0x295 and 0x296, true, but the device itself decodes more >> addresses than that. So, with this proposed patch, ports which are busy >> will be shown as being free. This pretty much voids the point of >> resource declarations, doesn't it? This might not cause too much >> trouble in practice, but to me this still looks like the wrong way to go. > >Yes, all the ports decoded by the chip should certainly be reserved, >but I think the entire range should be reserved at a higher level, >like the PNP core, and the driver should reserve only the ports it >uses. Then the entire range is reserved even if there is no driver >or the driver is not loaded. The problem is that the it87 driver is used on a variety of motherboards, some where the hardware monitoring device I/O ports are reserved by the BIOS, some where they aren't. How am I supposed to deal with this? >That's the approach we use for PCI, e.g., > > e810-e81f : :00:08.0 <-- reserved by PCI core >e810-e8102fff : CS46xx_BA1_data0<-- reserved by driver >e811-e81137ff : CS46xx_BA1_data1 >e812-e8126fff : CS46xx_BA1_pmem >e813-e81300ff : CS46xx_BA1_reg PCI is an entirely different beast. With PCI you know the PCI device ID that is associated with the resources, and for a given device, the resources are always declared (if standard BARs are used) or never declared; there's no "may be". So it's much easier to handle the resources properly. >> The resource declarations made by these motherboard BIOSes are totally >> bogus. 0x290-0x29f is much larger than what the chip decodes. >> 0x290-0x294 is a subset that doesn't make any sense. The GA-K8N Ultra 9 >> is even funnier with 0x295-0x314, which again doesn't correspond to >> anything real. > >I agree those declarations are probably wrong. But at least they're >larger than required, so they should be safe. That's not really safe, no. They may overlap with other device resources and prevent those drivers from loading. >> All these happen to not intersect with 0x295-0x296 but I >> wouldn't count on it. If Gigabyte (and possibly others) care that >> little about these declarations, pretty much anything could be seen. So >> while your proposed workaround happens to fix the problem at hand, it is >> not really correct technically, and could break again soon. >> >> I'd rather fix the problem at its source, or, as fixing it as the source >> isn't very realistic in this case, as near of the source as possible. >> That would mean DMI-based quirks for the affected motherboards, that >> would discard or adjust the bogus resource declarations. > >Well, I think the driver change *is* correct, assuming that the >entire range can be reserved at a higher level. In this case, >it is, via a PNP0C02 device. As I wrote above, the problem is that you can't assume that. Some motherboards do declare the range at PNP level but some don't. That's the reason why the it87 driver (and most other hwmon drivers for Super-I/O devices) do declare the I/O resource again. Another problem is how do I connect this specific I/O port range of the PNP0C02 device with the it87 driver? I am by far no PNP expert but it looks to me like this PNP device covers more than one actual device, and I/O port ranges do not have labels nor identifiers that would let me find the one that corresponds to the IT87xxF device (if it exists at all.) I'm all for integrating the it87 driver into the PNP subsystem if it is going to solve problems, but I just don't know how it works. I you do some work in this direction, I'll be happy to help with reviews and testing. >I think a DMI-based quirk to fix the PNP0C02 resources would be >a good approach, but we shouldn't do that until those resources >cause some other problem. Well these resources already do cause problems, otherwise we wouldn't be having this discussion ;) >(...) >I'm sure these boxes still have PNPBIOS, so pnpacpi=off would >probably work fine. But it feels like a bigger hammer than >necessary for this problem. OK. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
Hi Bjorn, Le 23/12/2007, Bjorn Helgaas a écrit: On Saturday 22 December 2007 4:21:41 am Jean Delvare wrote: This patch makes the it87 driver request only the two ports used for the Environment Controller device. The problem is that the IT87xxF chips do decode 4 ports (recent chips, 0x294-0x297) or 8 ports (older chips, 0x290-0x297), not 2 as the datasheets say. The ITE Super-I/O chips differ from the Winbond Super-I/O chips in this respect. The it87 driver only needs to access ports 0x295 and 0x296, true, but the device itself decodes more addresses than that. So, with this proposed patch, ports which are busy will be shown as being free. This pretty much voids the point of resource declarations, doesn't it? This might not cause too much trouble in practice, but to me this still looks like the wrong way to go. Yes, all the ports decoded by the chip should certainly be reserved, but I think the entire range should be reserved at a higher level, like the PNP core, and the driver should reserve only the ports it uses. Then the entire range is reserved even if there is no driver or the driver is not loaded. The problem is that the it87 driver is used on a variety of motherboards, some where the hardware monitoring device I/O ports are reserved by the BIOS, some where they aren't. How am I supposed to deal with this? That's the approach we use for PCI, e.g., e810-e81f : :00:08.0 -- reserved by PCI core e810-e8102fff : CS46xx_BA1_data0-- reserved by driver e811-e81137ff : CS46xx_BA1_data1 e812-e8126fff : CS46xx_BA1_pmem e813-e81300ff : CS46xx_BA1_reg PCI is an entirely different beast. With PCI you know the PCI device ID that is associated with the resources, and for a given device, the resources are always declared (if standard BARs are used) or never declared; there's no may be. So it's much easier to handle the resources properly. The resource declarations made by these motherboard BIOSes are totally bogus. 0x290-0x29f is much larger than what the chip decodes. 0x290-0x294 is a subset that doesn't make any sense. The GA-K8N Ultra 9 is even funnier with 0x295-0x314, which again doesn't correspond to anything real. I agree those declarations are probably wrong. But at least they're larger than required, so they should be safe. That's not really safe, no. They may overlap with other device resources and prevent those drivers from loading. All these happen to not intersect with 0x295-0x296 but I wouldn't count on it. If Gigabyte (and possibly others) care that little about these declarations, pretty much anything could be seen. So while your proposed workaround happens to fix the problem at hand, it is not really correct technically, and could break again soon. I'd rather fix the problem at its source, or, as fixing it as the source isn't very realistic in this case, as near of the source as possible. That would mean DMI-based quirks for the affected motherboards, that would discard or adjust the bogus resource declarations. Well, I think the driver change *is* correct, assuming that the entire range can be reserved at a higher level. In this case, it is, via a PNP0C02 device. As I wrote above, the problem is that you can't assume that. Some motherboards do declare the range at PNP level but some don't. That's the reason why the it87 driver (and most other hwmon drivers for Super-I/O devices) do declare the I/O resource again. Another problem is how do I connect this specific I/O port range of the PNP0C02 device with the it87 driver? I am by far no PNP expert but it looks to me like this PNP device covers more than one actual device, and I/O port ranges do not have labels nor identifiers that would let me find the one that corresponds to the IT87xxF device (if it exists at all.) I'm all for integrating the it87 driver into the PNP subsystem if it is going to solve problems, but I just don't know how it works. I you do some work in this direction, I'll be happy to help with reviews and testing. I think a DMI-based quirk to fix the PNP0C02 resources would be a good approach, but we shouldn't do that until those resources cause some other problem. Well these resources already do cause problems, otherwise we wouldn't be having this discussion ;) (...) I'm sure these boxes still have PNPBIOS, so pnpacpi=off would probably work fine. But it feels like a bigger hammer than necessary for this problem. OK. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Sunday 23 December 2007 2:28:05 am Jean Delvare wrote: Le 23/12/2007, Bjorn Helgaas a écrit: On Saturday 22 December 2007 4:21:41 am Jean Delvare wrote: This patch makes the it87 driver request only the two ports used for the Environment Controller device. The problem is that the IT87xxF chips do decode 4 ports (recent chips, 0x294-0x297) or 8 ports (older chips, 0x290-0x297), not 2 as the datasheets say. The ITE Super-I/O chips differ from the Winbond Super-I/O chips in this respect. The it87 driver only needs to access ports 0x295 and 0x296, true, but the device itself decodes more addresses than that. So, with this proposed patch, ports which are busy will be shown as being free. This pretty much voids the point of resource declarations, doesn't it? This might not cause too much trouble in practice, but to me this still looks like the wrong way to go. Yes, all the ports decoded by the chip should certainly be reserved, but I think the entire range should be reserved at a higher level, like the PNP core, and the driver should reserve only the ports it uses. Then the entire range is reserved even if there is no driver or the driver is not loaded. The problem is that the it87 driver is used on a variety of motherboards, some where the hardware monitoring device I/O ports are reserved by the BIOS, some where they aren't. How am I supposed to deal with this? I assume you mean some boards describe those ports in ACPI, and some don't? I think the ideal solution would be to figure out how the BIOS writers intended the device to be used, and do that. But the documentation may be lacking, and it degenerates into an OEM-specific mess. Second-best seems like a PNP quirk that pokes enough to determine that a Super I/O device is present, and then reserves resources for it. Then we avoid the collision even if it87 isn't present. That's the approach we use for PCI, e.g., e810-e81f : :00:08.0 -- reserved by PCI core e810-e8102fff : CS46xx_BA1_data0-- reserved by driver e811-e81137ff : CS46xx_BA1_data1 e812-e8126fff : CS46xx_BA1_pmem e813-e81300ff : CS46xx_BA1_reg PCI is an entirely different beast. With PCI you know the PCI device ID that is associated with the resources, and for a given device, the resources are always declared (if standard BARs are used) or never declared; there's no may be. So it's much easier to handle the resources properly. That's the way PNP is supposed to work, too (more about this below). The resource declarations made by these motherboard BIOSes are totally bogus. 0x290-0x29f is much larger than what the chip decodes. 0x290-0x294 is a subset that doesn't make any sense. The GA-K8N Ultra 9 is even funnier with 0x295-0x314, which again doesn't correspond to anything real. I agree those declarations are probably wrong. But at least they're larger than required, so they should be safe. That's not really safe, no. They may overlap with other device resources and prevent those drivers from loading. True. If that happens, I think we definitely need some kind of DMI- based quirk to fix the resources. My points are (a) the quirk needs to be at the PNP level; it can't be in a driver, and (b) I'm lazy and would wait until a problem happens before implementing it, because I know so little about PNP and the specific board, and by waiting, there's a chance I'll learn enough to avoid a mistake :-) All these happen to not intersect with 0x295-0x296 but I wouldn't count on it. If Gigabyte (and possibly others) care that little about these declarations, pretty much anything could be seen. So while your proposed workaround happens to fix the problem at hand, it is not really correct technically, and could break again soon. I'd rather fix the problem at its source, or, as fixing it as the source isn't very realistic in this case, as near of the source as possible. That would mean DMI-based quirks for the affected motherboards, that would discard or adjust the bogus resource declarations. Well, I think the driver change *is* correct, assuming that the entire range can be reserved at a higher level. In this case, it is, via a PNP0C02 device. As I wrote above, the problem is that you can't assume that. Some motherboards do declare the range at PNP level but some don't. That's the reason why the it87 driver (and most other hwmon drivers for Super-I/O devices) do declare the I/O resource again. The overlapping device problem is a subsystem problem, not a driver problem. We can't solve it in the driver because we can't depend on the it87 driver being loaded. Another problem is how do I connect this specific I/O port range of the PNP0C02 device with the it87 driver? I am by far no PNP expert but it looks to me like this PNP device covers more than one actual device, and I/O port ranges do not have labels nor identifiers that would let me
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Saturday 22 December 2007 4:21:41 am Jean Delvare wrote: > >This patch makes the it87 driver request only the two ports used for the > >Environment Controller device. > > The problem is that the IT87xxF chips do decode 4 ports (recent chips, > 0x294-0x297) or 8 ports (older chips, 0x290-0x297), not 2 as the > datasheets say. The ITE Super-I/O chips differ from the Winbond > Super-I/O chips in this respect. The it87 driver only needs to access > ports 0x295 and 0x296, true, but the device itself decodes more > addresses than that. So, with this proposed patch, ports which are busy > will be shown as being free. This pretty much voids the point of > resource declarations, doesn't it? This might not cause too much > trouble in practice, but to me this still looks like the wrong way to go. Yes, all the ports decoded by the chip should certainly be reserved, but I think the entire range should be reserved at a higher level, like the PNP core, and the driver should reserve only the ports it uses. Then the entire range is reserved even if there is no driver or the driver is not loaded. That's the approach we use for PCI, e.g., e810-e81f : :00:08.0 <-- reserved by PCI core e810-e8102fff : CS46xx_BA1_data0<-- reserved by driver e811-e81137ff : CS46xx_BA1_data1 e812-e8126fff : CS46xx_BA1_pmem e813-e81300ff : CS46xx_BA1_reg > The resource declarations made by these motherboard BIOSes are totally > bogus. 0x290-0x29f is much larger than what the chip decodes. > 0x290-0x294 is a subset that doesn't make any sense. The GA-K8N Ultra 9 > is even funnier with 0x295-0x314, which again doesn't correspond to > anything real. I agree those declarations are probably wrong. But at least they're larger than required, so they should be safe. > All these happen to not intersect with 0x295-0x296 but I > wouldn't count on it. If Gigabyte (and possibly others) care that > little about these declarations, pretty much anything could be seen. So > while your proposed workaround happens to fix the problem at hand, it is > not really correct technically, and could break again soon. > > I'd rather fix the problem at its source, or, as fixing it as the source > isn't very realistic in this case, as near of the source as possible. > That would mean DMI-based quirks for the affected motherboards, that > would discard or adjust the bogus resource declarations. Well, I think the driver change *is* correct, assuming that the entire range can be reserved at a higher level. In this case, it is, via a PNP0C02 device. I think a DMI-based quirk to fix the PNP0C02 resources would be a good approach, but we shouldn't do that until those resources cause some other problem. > I also don't fully understand what pnpacpi is useful for. I have heard > about PCI drivers that might request resources that the motherboard > doesn't want them to touch, but I don't know the details, I also > don't know if it is a theoretical issue or if it really happens on some > systems, and I don't know if there are other uses for pnpacpi. It is a real issue. It's probably not very common because many ACPI devices use "legacy" resources like ports below 0x1000, and the kernel has heuristics to avoid placing other devices there. But I have seen the kernel place a CardBus device on top of an ACPI device, so it does happen. Apart from preventing resource conflicts, PNP has framework for driver/device binding, suspend/resume, etc. Without PNPACPI, we'll fall back to PNPBIOS, but my guess is that nowadays, the ACPI namespace is better-tested than PNPBIOS. And I wouldn't be surprised if PNPBIOS disappears from new boxes. > I'm > asking because I want to know if forcing pnpacpi=off on the faulty > motherboards would be good enough or if we really need finer-grained > quirks (assuming that we go the DMI-based quirks route at all.) The > former would obviously be easier. I'm sure these boxes still have PNPBIOS, so pnpacpi=off would probably work fine. But it feels like a bigger hammer than necessary for this problem. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
Hi Bjorn, Le 21/12/2007, "Bjorn Helgaas" <[EMAIL PROTECTED]> a écrit: >On Tuesday 18 December 2007 10:59:18 am Jean Delvare wrote: >> My initial idea was to identify the faulty motherboard using DMI and to >> force pnpacpi=off on the faulty motherboards. If this is considered too >> aggressive, maybe we can just reject resource declarations that >> intersect (but don't match) 0x290-0x297 for these motherboards. Either >> way, we have to do something, and we have to do it quickly. 2.6.24 >> final isn't too far away, and more importantly, the patch that revealed >> the problem has been backported to 2.6.23.10 so people are experiencing >> regressions already. > >What do you think of something like the following patch? If we do >this, I don't think we'd need to force pnpacpi=off or change the >way PNP reserves resources. > >I'll be on vacation until about January 2, so I won't be able to >do much with this until then. > > > >[patch] it87: request only Environment Controller ports > >The IT8705F and related parts are Super I/O controllers that contain >many separate devices. > >Some BIOSes describe IT8705F I/O port usage under a motherboard device >(PNP0C02) with overlapping regions, e.g., 0x290-0x29f and 0x290-0x294. > >The it87 driver supports only the Environment Controller, which requires >only two ISA ports, but it used to request an eight-port range. If that >range exceeds a range reported by the BIOS, as 0x290-0x297 would, the >request fails, and the it87 driver cannot claim the device. > >This patch makes the it87 driver request only the two ports used for the >Environment Controller device. The problem is that the IT87xxF chips do decode 4 ports (recent chips, 0x294-0x297) or 8 ports (older chips, 0x290-0x297), not 2 as the datasheets say. The ITE Super-I/O chips differ from the Winbond Super-I/O chips in this respect. The it87 driver only needs to access ports 0x295 and 0x296, true, but the device itself decodes more addresses than that. So, with this proposed patch, ports which are busy will be shown as being free. This pretty much voids the point of resource declarations, doesn't it? This might not cause too much trouble in practice, but to me this still looks like the wrong way to go. The resource declarations made by these motherboard BIOSes are totally bogus. 0x290-0x29f is much larger than what the chip decodes. 0x290-0x294 is a subset that doesn't make any sense. The GA-K8N Ultra 9 is even funnier with 0x295-0x314, which again doesn't correspond to anything real. All these happen to not intersect with 0x295-0x296 but I wouldn't count on it. If Gigabyte (and possibly others) care that little about these declarations, pretty much anything could be seen. So while your proposed workaround happens to fix the problem at hand, it is not really correct technically, and could break again soon. I'd rather fix the problem at its source, or, as fixing it as the source isn't very realistic in this case, as near of the source as possible. That would mean DMI-based quirks for the affected motherboards, that would discard or adjust the bogus resource declarations. I have not yet looked at what the code would look like, as I am not familiar with the pnp system driver, I don't know what it would take to implement my proposal. I also don't fully understand what pnpacpi is useful for. I have heard about PCI drivers that might request resources that the motherboard doesn't want them to touch, but I don't know the details, I also don't know if it is a theoretical issue or if it really happens on some systems, and I don't know if there are other uses for pnpacpi. I'm asking because I want to know if forcing pnpacpi=off on the faulty motherboards would be good enough or if we really need finer-grained quirks (assuming that we go the DMI-based quirks route at all.) The former would obviously be easier. > >Systems where this problem has been reported: >Gigabyte GA-K8N Ultra 9 >Gigabyte M56S-S3 >Gigabyte GA-965G-DS3 > (...) Thanks, -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
Hi Bjorn, Le 21/12/2007, Bjorn Helgaas [EMAIL PROTECTED] a écrit: On Tuesday 18 December 2007 10:59:18 am Jean Delvare wrote: My initial idea was to identify the faulty motherboard using DMI and to force pnpacpi=off on the faulty motherboards. If this is considered too aggressive, maybe we can just reject resource declarations that intersect (but don't match) 0x290-0x297 for these motherboards. Either way, we have to do something, and we have to do it quickly. 2.6.24 final isn't too far away, and more importantly, the patch that revealed the problem has been backported to 2.6.23.10 so people are experiencing regressions already. What do you think of something like the following patch? If we do this, I don't think we'd need to force pnpacpi=off or change the way PNP reserves resources. I'll be on vacation until about January 2, so I won't be able to do much with this until then. [patch] it87: request only Environment Controller ports The IT8705F and related parts are Super I/O controllers that contain many separate devices. Some BIOSes describe IT8705F I/O port usage under a motherboard device (PNP0C02) with overlapping regions, e.g., 0x290-0x29f and 0x290-0x294. The it87 driver supports only the Environment Controller, which requires only two ISA ports, but it used to request an eight-port range. If that range exceeds a range reported by the BIOS, as 0x290-0x297 would, the request fails, and the it87 driver cannot claim the device. This patch makes the it87 driver request only the two ports used for the Environment Controller device. The problem is that the IT87xxF chips do decode 4 ports (recent chips, 0x294-0x297) or 8 ports (older chips, 0x290-0x297), not 2 as the datasheets say. The ITE Super-I/O chips differ from the Winbond Super-I/O chips in this respect. The it87 driver only needs to access ports 0x295 and 0x296, true, but the device itself decodes more addresses than that. So, with this proposed patch, ports which are busy will be shown as being free. This pretty much voids the point of resource declarations, doesn't it? This might not cause too much trouble in practice, but to me this still looks like the wrong way to go. The resource declarations made by these motherboard BIOSes are totally bogus. 0x290-0x29f is much larger than what the chip decodes. 0x290-0x294 is a subset that doesn't make any sense. The GA-K8N Ultra 9 is even funnier with 0x295-0x314, which again doesn't correspond to anything real. All these happen to not intersect with 0x295-0x296 but I wouldn't count on it. If Gigabyte (and possibly others) care that little about these declarations, pretty much anything could be seen. So while your proposed workaround happens to fix the problem at hand, it is not really correct technically, and could break again soon. I'd rather fix the problem at its source, or, as fixing it as the source isn't very realistic in this case, as near of the source as possible. That would mean DMI-based quirks for the affected motherboards, that would discard or adjust the bogus resource declarations. I have not yet looked at what the code would look like, as I am not familiar with the pnp system driver, I don't know what it would take to implement my proposal. I also don't fully understand what pnpacpi is useful for. I have heard about PCI drivers that might request resources that the motherboard doesn't want them to touch, but I don't know the details, I also don't know if it is a theoretical issue or if it really happens on some systems, and I don't know if there are other uses for pnpacpi. I'm asking because I want to know if forcing pnpacpi=off on the faulty motherboards would be good enough or if we really need finer-grained quirks (assuming that we go the DMI-based quirks route at all.) The former would obviously be easier. Systems where this problem has been reported: Gigabyte GA-K8N Ultra 9 Gigabyte M56S-S3 Gigabyte GA-965G-DS3 (...) Thanks, -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Saturday 22 December 2007 4:21:41 am Jean Delvare wrote: This patch makes the it87 driver request only the two ports used for the Environment Controller device. The problem is that the IT87xxF chips do decode 4 ports (recent chips, 0x294-0x297) or 8 ports (older chips, 0x290-0x297), not 2 as the datasheets say. The ITE Super-I/O chips differ from the Winbond Super-I/O chips in this respect. The it87 driver only needs to access ports 0x295 and 0x296, true, but the device itself decodes more addresses than that. So, with this proposed patch, ports which are busy will be shown as being free. This pretty much voids the point of resource declarations, doesn't it? This might not cause too much trouble in practice, but to me this still looks like the wrong way to go. Yes, all the ports decoded by the chip should certainly be reserved, but I think the entire range should be reserved at a higher level, like the PNP core, and the driver should reserve only the ports it uses. Then the entire range is reserved even if there is no driver or the driver is not loaded. That's the approach we use for PCI, e.g., e810-e81f : :00:08.0 -- reserved by PCI core e810-e8102fff : CS46xx_BA1_data0-- reserved by driver e811-e81137ff : CS46xx_BA1_data1 e812-e8126fff : CS46xx_BA1_pmem e813-e81300ff : CS46xx_BA1_reg The resource declarations made by these motherboard BIOSes are totally bogus. 0x290-0x29f is much larger than what the chip decodes. 0x290-0x294 is a subset that doesn't make any sense. The GA-K8N Ultra 9 is even funnier with 0x295-0x314, which again doesn't correspond to anything real. I agree those declarations are probably wrong. But at least they're larger than required, so they should be safe. All these happen to not intersect with 0x295-0x296 but I wouldn't count on it. If Gigabyte (and possibly others) care that little about these declarations, pretty much anything could be seen. So while your proposed workaround happens to fix the problem at hand, it is not really correct technically, and could break again soon. I'd rather fix the problem at its source, or, as fixing it as the source isn't very realistic in this case, as near of the source as possible. That would mean DMI-based quirks for the affected motherboards, that would discard or adjust the bogus resource declarations. Well, I think the driver change *is* correct, assuming that the entire range can be reserved at a higher level. In this case, it is, via a PNP0C02 device. I think a DMI-based quirk to fix the PNP0C02 resources would be a good approach, but we shouldn't do that until those resources cause some other problem. I also don't fully understand what pnpacpi is useful for. I have heard about PCI drivers that might request resources that the motherboard doesn't want them to touch, but I don't know the details, I also don't know if it is a theoretical issue or if it really happens on some systems, and I don't know if there are other uses for pnpacpi. It is a real issue. It's probably not very common because many ACPI devices use legacy resources like ports below 0x1000, and the kernel has heuristics to avoid placing other devices there. But I have seen the kernel place a CardBus device on top of an ACPI device, so it does happen. Apart from preventing resource conflicts, PNP has framework for driver/device binding, suspend/resume, etc. Without PNPACPI, we'll fall back to PNPBIOS, but my guess is that nowadays, the ACPI namespace is better-tested than PNPBIOS. And I wouldn't be surprised if PNPBIOS disappears from new boxes. I'm asking because I want to know if forcing pnpacpi=off on the faulty motherboards would be good enough or if we really need finer-grained quirks (assuming that we go the DMI-based quirks route at all.) The former would obviously be easier. I'm sure these boxes still have PNPBIOS, so pnpacpi=off would probably work fine. But it feels like a bigger hammer than necessary for this problem. Bjorn -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Fri, 21 Dec 2007 12:00:30 -0700 Bjorn Helgaas <[EMAIL PROTECTED]> wrote: > What do you think of something like the following patch? If we do > this, I don't think we'd need to force pnpacpi=off or change the > way PNP reserves resources. > > I'll be on vacation until about January 2, so I won't be able to > do much with this until then. > > > > [patch] it87: request only Environment Controller ports I'm not qualified to give an opinion on what's proper for the kernel, so all I can say is that I've applied it (to fresh 2.6.24-rc6 source without Shaohua's pnpacpi patch) and it works nicely for me. >From /proc/ioports: 0290-029f : pnp 00:01 0290-0294 : pnp 00:01 0295-0296 : it87 0295-0296 : it87 >From dmesg: system 00:01: ioport range 0x290-0x29f has been reserved ... system 00:01: ioport range 0x290-0x294 has been reserved My sensors work. Thanks for this patch, Mike Houston -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Tuesday 18 December 2007 10:59:18 am Jean Delvare wrote:
> My initial idea was to identify the faulty motherboard using DMI and to
> force pnpacpi=off on the faulty motherboards. If this is considered too
> aggressive, maybe we can just reject resource declarations that
> intersect (but don't match) 0x290-0x297 for these motherboards. Either
> way, we have to do something, and we have to do it quickly. 2.6.24
> final isn't too far away, and more importantly, the patch that revealed
> the problem has been backported to 2.6.23.10 so people are experiencing
> regressions already.
What do you think of something like the following patch? If we do
this, I don't think we'd need to force pnpacpi=off or change the
way PNP reserves resources.
I'll be on vacation until about January 2, so I won't be able to
do much with this until then.
[patch] it87: request only Environment Controller ports
The IT8705F and related parts are Super I/O controllers that contain
many separate devices.
Some BIOSes describe IT8705F I/O port usage under a motherboard device
(PNP0C02) with overlapping regions, e.g., 0x290-0x29f and 0x290-0x294.
The it87 driver supports only the Environment Controller, which requires
only two ISA ports, but it used to request an eight-port range. If that
range exceeds a range reported by the BIOS, as 0x290-0x297 would, the
request fails, and the it87 driver cannot claim the device.
This patch makes the it87 driver request only the two ports used for the
Environment Controller device.
Systems where this problem has been reported:
Gigabyte GA-K8N Ultra 9
Gigabyte M56S-S3
Gigabyte GA-965G-DS3
Kernel bug reports:
http://bugzilla.kernel.org/show_bug.cgi?id=9514
http://lkml.org/lkml/2007/12/4/466
Related change:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a7839e960675b549f06209d18283d5cee2ce9261
The patch above increases the number of PNP port resources we support.
Prior to this patch, we ignored some port resources, which masked the
it87 problem.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work4/drivers/hwmon/it87.c
===
--- work4.orig/drivers/hwmon/it87.c 2007-12-21 10:38:46.0 -0700
+++ work4/drivers/hwmon/it87.c 2007-12-21 11:43:50.0 -0700
@@ -2,6 +2,14 @@
it87.c - Part of lm_sensors, Linux kernel modules for hardware
monitoring.
+The IT8705F is an LPC-based Super I/O part that contains UARTs, a
+parallel port, an IR port, a MIDI port, a floppy controller, etc., in
+addition to an Environment Controller (Enhanced Hardware Monitor and
+Fan Controller)
+
+This driver supports only the Environment Controller in the IT8705F and
+similar parts. The other devices are supported by different drivers.
+
Supports: IT8705F Super I/O chip w/LPC interface
IT8712F Super I/O chip w/LPC interface
IT8716F Super I/O chip w/LPC interface
@@ -118,9 +126,15 @@
/* Length of ISA address segment */
#define IT87_EXTENT 8
-/* Where are the ISA address/data registers relative to the base address */
-#define IT87_ADDR_REG_OFFSET 5
-#define IT87_DATA_REG_OFFSET 6
+/* Length of ISA address segment for Environmental Controller */
+#define IT87_EC_EXTENT 2
+
+/* Offset of EC registers from ISA base address */
+#define IT87_EC_OFFSET 5
+
+/* Where are the ISA address/data registers relative to the EC base address */
+#define IT87_ADDR_REG_OFFSET 0
+#define IT87_DATA_REG_OFFSET 1
/*- The IT87 registers -*/
@@ -968,10 +982,10 @@
};
res = platform_get_resource(pdev, IORESOURCE_IO, 0);
- if (!request_region(res->start, IT87_EXTENT, DRVNAME)) {
+ if (!request_region(res->start, IT87_EC_EXTENT, DRVNAME)) {
dev_err(dev, "Failed to request region 0x%lx-0x%lx\n",
(unsigned long)res->start,
- (unsigned long)(res->start + IT87_EXTENT - 1));
+ (unsigned long)(res->start + IT87_EC_EXTENT - 1));
err = -EBUSY;
goto ERROR0;
}
@@ -1124,7 +1138,7 @@
platform_set_drvdata(pdev, NULL);
kfree(data);
ERROR1:
- release_region(res->start, IT87_EXTENT);
+ release_region(res->start, IT87_EC_EXTENT);
ERROR0:
return err;
}
@@ -1137,7 +1151,7 @@
sysfs_remove_group(>dev.kobj, _group);
sysfs_remove_group(>dev.kobj, _group_opt);
- release_region(data->addr, IT87_EXTENT);
+ release_region(data->addr, IT87_EC_EXTENT);
platform_set_drvdata(pdev, NULL);
kfree(data);
@@ -1402,8 +1416,8 @@
const struct it87_sio_data *sio_data)
{
struct resource res = {
- .start = address ,
- .end= address + IT87_EXTENT - 1,
+ .start = address + IT87_EC_OFFSET,
+ .end=
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Tuesday 18 December 2007 10:59:18 am Jean Delvare wrote:
My initial idea was to identify the faulty motherboard using DMI and to
force pnpacpi=off on the faulty motherboards. If this is considered too
aggressive, maybe we can just reject resource declarations that
intersect (but don't match) 0x290-0x297 for these motherboards. Either
way, we have to do something, and we have to do it quickly. 2.6.24
final isn't too far away, and more importantly, the patch that revealed
the problem has been backported to 2.6.23.10 so people are experiencing
regressions already.
What do you think of something like the following patch? If we do
this, I don't think we'd need to force pnpacpi=off or change the
way PNP reserves resources.
I'll be on vacation until about January 2, so I won't be able to
do much with this until then.
[patch] it87: request only Environment Controller ports
The IT8705F and related parts are Super I/O controllers that contain
many separate devices.
Some BIOSes describe IT8705F I/O port usage under a motherboard device
(PNP0C02) with overlapping regions, e.g., 0x290-0x29f and 0x290-0x294.
The it87 driver supports only the Environment Controller, which requires
only two ISA ports, but it used to request an eight-port range. If that
range exceeds a range reported by the BIOS, as 0x290-0x297 would, the
request fails, and the it87 driver cannot claim the device.
This patch makes the it87 driver request only the two ports used for the
Environment Controller device.
Systems where this problem has been reported:
Gigabyte GA-K8N Ultra 9
Gigabyte M56S-S3
Gigabyte GA-965G-DS3
Kernel bug reports:
http://bugzilla.kernel.org/show_bug.cgi?id=9514
http://lkml.org/lkml/2007/12/4/466
Related change:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a7839e960675b549f06209d18283d5cee2ce9261
The patch above increases the number of PNP port resources we support.
Prior to this patch, we ignored some port resources, which masked the
it87 problem.
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
Index: work4/drivers/hwmon/it87.c
===
--- work4.orig/drivers/hwmon/it87.c 2007-12-21 10:38:46.0 -0700
+++ work4/drivers/hwmon/it87.c 2007-12-21 11:43:50.0 -0700
@@ -2,6 +2,14 @@
it87.c - Part of lm_sensors, Linux kernel modules for hardware
monitoring.
+The IT8705F is an LPC-based Super I/O part that contains UARTs, a
+parallel port, an IR port, a MIDI port, a floppy controller, etc., in
+addition to an Environment Controller (Enhanced Hardware Monitor and
+Fan Controller)
+
+This driver supports only the Environment Controller in the IT8705F and
+similar parts. The other devices are supported by different drivers.
+
Supports: IT8705F Super I/O chip w/LPC interface
IT8712F Super I/O chip w/LPC interface
IT8716F Super I/O chip w/LPC interface
@@ -118,9 +126,15 @@
/* Length of ISA address segment */
#define IT87_EXTENT 8
-/* Where are the ISA address/data registers relative to the base address */
-#define IT87_ADDR_REG_OFFSET 5
-#define IT87_DATA_REG_OFFSET 6
+/* Length of ISA address segment for Environmental Controller */
+#define IT87_EC_EXTENT 2
+
+/* Offset of EC registers from ISA base address */
+#define IT87_EC_OFFSET 5
+
+/* Where are the ISA address/data registers relative to the EC base address */
+#define IT87_ADDR_REG_OFFSET 0
+#define IT87_DATA_REG_OFFSET 1
/*- The IT87 registers -*/
@@ -968,10 +982,10 @@
};
res = platform_get_resource(pdev, IORESOURCE_IO, 0);
- if (!request_region(res-start, IT87_EXTENT, DRVNAME)) {
+ if (!request_region(res-start, IT87_EC_EXTENT, DRVNAME)) {
dev_err(dev, Failed to request region 0x%lx-0x%lx\n,
(unsigned long)res-start,
- (unsigned long)(res-start + IT87_EXTENT - 1));
+ (unsigned long)(res-start + IT87_EC_EXTENT - 1));
err = -EBUSY;
goto ERROR0;
}
@@ -1124,7 +1138,7 @@
platform_set_drvdata(pdev, NULL);
kfree(data);
ERROR1:
- release_region(res-start, IT87_EXTENT);
+ release_region(res-start, IT87_EC_EXTENT);
ERROR0:
return err;
}
@@ -1137,7 +1151,7 @@
sysfs_remove_group(pdev-dev.kobj, it87_group);
sysfs_remove_group(pdev-dev.kobj, it87_group_opt);
- release_region(data-addr, IT87_EXTENT);
+ release_region(data-addr, IT87_EC_EXTENT);
platform_set_drvdata(pdev, NULL);
kfree(data);
@@ -1402,8 +1416,8 @@
const struct it87_sio_data *sio_data)
{
struct resource res = {
- .start = address ,
- .end= address + IT87_EXTENT - 1,
+ .start = address + IT87_EC_OFFSET,
+ .end=
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Fri, 21 Dec 2007 12:00:30 -0700 Bjorn Helgaas [EMAIL PROTECTED] wrote: What do you think of something like the following patch? If we do this, I don't think we'd need to force pnpacpi=off or change the way PNP reserves resources. I'll be on vacation until about January 2, so I won't be able to do much with this until then. [patch] it87: request only Environment Controller ports I'm not qualified to give an opinion on what's proper for the kernel, so all I can say is that I've applied it (to fresh 2.6.24-rc6 source without Shaohua's pnpacpi patch) and it works nicely for me. From /proc/ioports: 0290-029f : pnp 00:01 0290-0294 : pnp 00:01 0295-0296 : it87 0295-0296 : it87 From dmesg: system 00:01: ioport range 0x290-0x29f has been reserved ... system 00:01: ioport range 0x290-0x294 has been reserved My sensors work. Thanks for this patch, Mike Houston -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Thursday 20 December 2007 02:13:22 Elvis Pranskevichus wrote: > Hi Carlos, > > I've attached the DSDT for Gigabyte GA-965G-DS3 (rev 1.0, bios rev. F9) to > bugzilla entry #9514: > > http://bugzilla.kernel.org/attachment.cgi?id=14132 A quick look over the DSDT shows that there is no ACPI-WMI mapper device (PNP0C14) on this board; so WMI is, at least in this case, not the solution to this bug. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Wednesday December 19 2007 07:45:14 pm Carlos Corbacho wrote: > On Thursday 20 December 2007 00:20:21 Bjorn Helgaas wrote: > > I suspect the manufacturers would say "Oh, the sensors? The BIOS > > isn't broken, you're just supposed to use WMI or some (undocumented) > > ACPI device to get at those." > > It's quite possible - can we have DSDTs for the boards in question so we > can quickly check if this is a possibility? (Basically, to see if they have > PNP0C14 devices - if they don't, then I'm afraid it's nothing to do with > WMI). > > -Carlos Hi Carlos, I've attached the DSDT for Gigabyte GA-965G-DS3 (rev 1.0, bios rev. F9) to bugzilla entry #9514: http://bugzilla.kernel.org/attachment.cgi?id=14132 Thanks, -- Elvis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
Carlos Corbacho wrote: On Thursday 20 December 2007 00:20:21 Bjorn Helgaas wrote: I suspect the manufacturers would say "Oh, the sensors? The BIOS isn't broken, you're just supposed to use WMI or some (undocumented) ACPI device to get at those." It's quite possible - can we have DSDTs for the boards in question so we can quickly check if this is a possibility? (Basically, to see if they have PNP0C14 devices - if they don't, then I'm afraid it's nothing to do with WMI). -Carlos It's quite possible that the BIOS accesses the device either from ACPI AML or possibly even from SMI. In that case it would be quite reasonable for the BIOS to reserve that region to prevent another driver from loading and trying to take conflicting control of the device. One has to be careful before assuming that any such reservation is bogus. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Thursday 20 December 2007 00:20:21 Bjorn Helgaas wrote: > I suspect the manufacturers would say "Oh, the sensors? The BIOS > isn't broken, you're just supposed to use WMI or some (undocumented) > ACPI device to get at those." It's quite possible - can we have DSDTs for the boards in question so we can quickly check if this is a possibility? (Basically, to see if they have PNP0C14 devices - if they don't, then I'm afraid it's nothing to do with WMI). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Tuesday 18 December 2007 10:59:18 am Jean Delvare wrote: > The real cause is pretty clear here: broken BIOS. In an ideal world we > would ask the manufacturer for a fixed BIOS and they would give that to > us, unfortunately my experience is that it won't happen. So, unless we > accept that idea that some users won't be able to use some of their > devices because of broken resource enumeration in their BIOS, we will > have to find a workaround, whatever it is. I suspect the manufacturers would say "Oh, the sensors? The BIOS isn't broken, you're just supposed to use WMI or some (undocumented) ACPI device to get at those." I know next to nothing about WMI, and there are probably IP issues in that area. But I'd rather spend effort in figuring out the "right" way to do this. Until we do it the same way as Windows, we can pile on hacks till the cows come home, and we'll still have issues. I added Carlos to the cc: list because he's been doing a lot of interesting-looking work on WMI. > My initial idea was to identify the faulty motherboard using DMI and to > force pnpacpi=off on the faulty motherboards. If this is considered too > aggressive, maybe we can just reject resource declarations that > intersect (but don't match) 0x290-0x297 for these motherboards. Either > way, we have to do something, and we have to do it quickly. 2.6.24 > final isn't too far away, and more importantly, the patch that revealed > the problem has been backported to 2.6.23.10 so people are experiencing > regressions already. Windows apparently doesn't reject those resource declarations, so I'm a bit hesitant to do it in Linux. That tends to cover up problems, and then it becomes very difficult to remove the band-aid and figure out a correct fix in the future. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Sunday 09 December 2007 09:02:11 pm Mike Houston wrote: > On Mon, 10 Dec 2007 10:31:27 +0800 > Shaohua Li <[EMAIL PROTECTED]> wrote: > > This should exist in previous kernel (before we remove acpi > > motherboard driver) too. Basically it's a broken BIOS. Could below > > patch work around it? > > > > Thanks, > > Shaohua > > > > Index: linux/drivers/pnp/system.c > > === > > --- linux.orig/drivers/pnp/system.c 2007-12-10 > > 10:17:46.0 +0800 +++ linux/drivers/pnp/system.c > > Thanks Shaohua, I tested this as well and it appears to have worked > around the issue for me. > > Now, in dmesg, I get: > > system 00:01: ioport range 0x290-0x29f has been reserved > (...) > system 00:01: ioport range 0x290-0x294 could not be reserved > > In /proc/ioports I see: > > 0290-029f : pnp 00:01 > 0290-0297 : it87 > 0290-0297 : it87 > > The it87 sensor now works without disabling acpipnp This whole thing is too ugly for words. First of all, it87 only accesses two I/O ports: IT87_ADDR_REG_OFFSET and IT87_DATA_REG_OFFSET, which are at offsets 5 and 6 from the base. So if it87 reserved only those ports, e.g., 0x295-0x296, I think things would work fine (or at least, as well as they used to). Secondly, it87 ignores any information from the BIOS and grubs around for a superio chip at a magic address and tries to figure out what's behind it. I know this is because we don't know the "real" way to read those sensors, but it still sucks, and it still means we're likely to have conflicts with ACPI usage of the device. And no, I don't have anything useful like an ACPI driver to offer :-) Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Sunday 09 December 2007 09:02:11 pm Mike Houston wrote: On Mon, 10 Dec 2007 10:31:27 +0800 Shaohua Li [EMAIL PROTECTED] wrote: This should exist in previous kernel (before we remove acpi motherboard driver) too. Basically it's a broken BIOS. Could below patch work around it? Thanks, Shaohua Index: linux/drivers/pnp/system.c === --- linux.orig/drivers/pnp/system.c 2007-12-10 10:17:46.0 +0800 +++ linux/drivers/pnp/system.c Thanks Shaohua, I tested this as well and it appears to have worked around the issue for me. Now, in dmesg, I get: system 00:01: ioport range 0x290-0x29f has been reserved (...) system 00:01: ioport range 0x290-0x294 could not be reserved In /proc/ioports I see: 0290-029f : pnp 00:01 0290-0297 : it87 0290-0297 : it87 The it87 sensor now works without disabling acpipnp This whole thing is too ugly for words. First of all, it87 only accesses two I/O ports: IT87_ADDR_REG_OFFSET and IT87_DATA_REG_OFFSET, which are at offsets 5 and 6 from the base. So if it87 reserved only those ports, e.g., 0x295-0x296, I think things would work fine (or at least, as well as they used to). Secondly, it87 ignores any information from the BIOS and grubs around for a superio chip at a magic address and tries to figure out what's behind it. I know this is because we don't know the real way to read those sensors, but it still sucks, and it still means we're likely to have conflicts with ACPI usage of the device. And no, I don't have anything useful like an ACPI driver to offer :-) Bjorn -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Tuesday 18 December 2007 10:59:18 am Jean Delvare wrote: The real cause is pretty clear here: broken BIOS. In an ideal world we would ask the manufacturer for a fixed BIOS and they would give that to us, unfortunately my experience is that it won't happen. So, unless we accept that idea that some users won't be able to use some of their devices because of broken resource enumeration in their BIOS, we will have to find a workaround, whatever it is. I suspect the manufacturers would say Oh, the sensors? The BIOS isn't broken, you're just supposed to use WMI or some (undocumented) ACPI device to get at those. I know next to nothing about WMI, and there are probably IP issues in that area. But I'd rather spend effort in figuring out the right way to do this. Until we do it the same way as Windows, we can pile on hacks till the cows come home, and we'll still have issues. I added Carlos to the cc: list because he's been doing a lot of interesting-looking work on WMI. My initial idea was to identify the faulty motherboard using DMI and to force pnpacpi=off on the faulty motherboards. If this is considered too aggressive, maybe we can just reject resource declarations that intersect (but don't match) 0x290-0x297 for these motherboards. Either way, we have to do something, and we have to do it quickly. 2.6.24 final isn't too far away, and more importantly, the patch that revealed the problem has been backported to 2.6.23.10 so people are experiencing regressions already. Windows apparently doesn't reject those resource declarations, so I'm a bit hesitant to do it in Linux. That tends to cover up problems, and then it becomes very difficult to remove the band-aid and figure out a correct fix in the future. Bjorn -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Thursday 20 December 2007 00:20:21 Bjorn Helgaas wrote: I suspect the manufacturers would say Oh, the sensors? The BIOS isn't broken, you're just supposed to use WMI or some (undocumented) ACPI device to get at those. It's quite possible - can we have DSDTs for the boards in question so we can quickly check if this is a possibility? (Basically, to see if they have PNP0C14 devices - if they don't, then I'm afraid it's nothing to do with WMI). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
Carlos Corbacho wrote: On Thursday 20 December 2007 00:20:21 Bjorn Helgaas wrote: I suspect the manufacturers would say Oh, the sensors? The BIOS isn't broken, you're just supposed to use WMI or some (undocumented) ACPI device to get at those. It's quite possible - can we have DSDTs for the boards in question so we can quickly check if this is a possibility? (Basically, to see if they have PNP0C14 devices - if they don't, then I'm afraid it's nothing to do with WMI). -Carlos It's quite possible that the BIOS accesses the device either from ACPI AML or possibly even from SMI. In that case it would be quite reasonable for the BIOS to reserve that region to prevent another driver from loading and trying to take conflicting control of the device. One has to be careful before assuming that any such reservation is bogus. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Wednesday December 19 2007 07:45:14 pm Carlos Corbacho wrote: On Thursday 20 December 2007 00:20:21 Bjorn Helgaas wrote: I suspect the manufacturers would say Oh, the sensors? The BIOS isn't broken, you're just supposed to use WMI or some (undocumented) ACPI device to get at those. It's quite possible - can we have DSDTs for the boards in question so we can quickly check if this is a possibility? (Basically, to see if they have PNP0C14 devices - if they don't, then I'm afraid it's nothing to do with WMI). -Carlos Hi Carlos, I've attached the DSDT for Gigabyte GA-965G-DS3 (rev 1.0, bios rev. F9) to bugzilla entry #9514: http://bugzilla.kernel.org/attachment.cgi?id=14132 Thanks, -- Elvis -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Thursday 20 December 2007 02:13:22 Elvis Pranskevichus wrote: Hi Carlos, I've attached the DSDT for Gigabyte GA-965G-DS3 (rev 1.0, bios rev. F9) to bugzilla entry #9514: http://bugzilla.kernel.org/attachment.cgi?id=14132 A quick look over the DSDT shows that there is no ACPI-WMI mapper device (PNP0C14) on this board; so WMI is, at least in this case, not the solution to this bug. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
Hi Bjorn, On Mon, 17 Dec 2007 10:14:43 -0700, Bjorn Helgaas wrote: > On Sunday 16 December 2007 06:59:39 pm Shaohua Li wrote: > > On Sun, 2007-12-09 at 23:02 -0500, Mike Houston wrote: > > > On Mon, 10 Dec 2007 10:31:27 +0800 > > > Shaohua Li <[EMAIL PROTECTED]> wrote: > > > > This should exist in previous kernel (before we remove acpi > > > > motherboard driver) too. Basically it's a broken BIOS. Could below > > > > patch work around it? > > > > > > > > Thanks, > > > > Shaohua > > > > > > > > Index: linux/drivers/pnp/system.c > > > > === > > > > --- linux.orig/drivers/pnp/system.c 2007-12-10 > > > > 10:17:46.0 +0800 +++ linux/drivers/pnp/system.c > > > > > > Thanks Shaohua, I tested this as well and it appears to have worked > > > around the issue for me. > > > > > > Now, in dmesg, I get: > > > > > > system 00:01: ioport range 0x290-0x29f has been reserved > > > (...) > > > system 00:01: ioport range 0x290-0x294 could not be reserved > > > > > > In /proc/ioports I see: > > > > > > 0290-029f : pnp 00:01 > > > 0290-0297 : it87 > > > 0290-0297 : it87 > > > > Unfortunately this can't solve all such issues. I don't see any issue here, but anyway it doesn't really matter as the proposed patch is not sufficient for all affected motherboards. > > > > Adam & Bjorn, > > Could we just reserve IO ports >= 0x1000 in pnp system driver? The > > purpose of the driver is to avoid resource conflict with PCI device, and > > PCI device can't user io port < 0x1000. > > The purpose of the PNP system driver is to avoid conflicts with > *all* devices. And if the PNP core were a little smarter, we > wouldn't need the system driver at all. We don't have one for > PCI -- the PCI core manages resources for all PCI devices, even > ones that have no driver. > > Why is 0x1000 a magic number? drivers/acpi/motherboard.c used to > ignore IO port ranges that ended below PCIBIOS_MIN_IO (== 0x1000 for > most architectures). I don't think Linux will assign IO ports below > PCIBIOS_MIN_IO to a PCI device, but the BIOS could, and I've seen > CardBus devices below PCIBIOS_MIN_IO. > > I think having drivers/pnp/system.c ignore resources below > PCIBIOS_MIN_IO would be a hack that happens to cover up problems > like this without understanding the real cause. The real cause is pretty clear here: broken BIOS. In an ideal world we would ask the manufacturer for a fixed BIOS and they would give that to us, unfortunately my experience is that it won't happen. So, unless we accept that idea that some users won't be able to use some of their devices because of broken resource enumeration in their BIOS, we will have to find a workaround, whatever it is. My initial idea was to identify the faulty motherboard using DMI and to force pnpacpi=off on the faulty motherboards. If this is considered too aggressive, maybe we can just reject resource declarations that intersect (but don't match) 0x290-0x297 for these motherboards. Either way, we have to do something, and we have to do it quickly. 2.6.24 final isn't too far away, and more importantly, the patch that revealed the problem has been backported to 2.6.23.10 so people are experiencing regressions already. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
Hi Bjorn, On Mon, 17 Dec 2007 10:14:43 -0700, Bjorn Helgaas wrote: On Sunday 16 December 2007 06:59:39 pm Shaohua Li wrote: On Sun, 2007-12-09 at 23:02 -0500, Mike Houston wrote: On Mon, 10 Dec 2007 10:31:27 +0800 Shaohua Li [EMAIL PROTECTED] wrote: This should exist in previous kernel (before we remove acpi motherboard driver) too. Basically it's a broken BIOS. Could below patch work around it? Thanks, Shaohua Index: linux/drivers/pnp/system.c === --- linux.orig/drivers/pnp/system.c 2007-12-10 10:17:46.0 +0800 +++ linux/drivers/pnp/system.c Thanks Shaohua, I tested this as well and it appears to have worked around the issue for me. Now, in dmesg, I get: system 00:01: ioport range 0x290-0x29f has been reserved (...) system 00:01: ioport range 0x290-0x294 could not be reserved In /proc/ioports I see: 0290-029f : pnp 00:01 0290-0297 : it87 0290-0297 : it87 Unfortunately this can't solve all such issues. I don't see any issue here, but anyway it doesn't really matter as the proposed patch is not sufficient for all affected motherboards. Adam Bjorn, Could we just reserve IO ports = 0x1000 in pnp system driver? The purpose of the driver is to avoid resource conflict with PCI device, and PCI device can't user io port 0x1000. The purpose of the PNP system driver is to avoid conflicts with *all* devices. And if the PNP core were a little smarter, we wouldn't need the system driver at all. We don't have one for PCI -- the PCI core manages resources for all PCI devices, even ones that have no driver. Why is 0x1000 a magic number? drivers/acpi/motherboard.c used to ignore IO port ranges that ended below PCIBIOS_MIN_IO (== 0x1000 for most architectures). I don't think Linux will assign IO ports below PCIBIOS_MIN_IO to a PCI device, but the BIOS could, and I've seen CardBus devices below PCIBIOS_MIN_IO. I think having drivers/pnp/system.c ignore resources below PCIBIOS_MIN_IO would be a hack that happens to cover up problems like this without understanding the real cause. The real cause is pretty clear here: broken BIOS. In an ideal world we would ask the manufacturer for a fixed BIOS and they would give that to us, unfortunately my experience is that it won't happen. So, unless we accept that idea that some users won't be able to use some of their devices because of broken resource enumeration in their BIOS, we will have to find a workaround, whatever it is. My initial idea was to identify the faulty motherboard using DMI and to force pnpacpi=off on the faulty motherboards. If this is considered too aggressive, maybe we can just reject resource declarations that intersect (but don't match) 0x290-0x297 for these motherboards. Either way, we have to do something, and we have to do it quickly. 2.6.24 final isn't too far away, and more importantly, the patch that revealed the problem has been backported to 2.6.23.10 so people are experiencing regressions already. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Sunday 16 December 2007 06:59:39 pm Shaohua Li wrote: > On Sun, 2007-12-09 at 23:02 -0500, Mike Houston wrote: > > On Mon, 10 Dec 2007 10:31:27 +0800 > > Shaohua Li <[EMAIL PROTECTED]> wrote: > > > This should exist in previous kernel (before we remove acpi > > > motherboard driver) too. Basically it's a broken BIOS. Could below > > > patch work around it? > > > > > > Thanks, > > > Shaohua > > > > > > Index: linux/drivers/pnp/system.c > > > === > > > --- linux.orig/drivers/pnp/system.c 2007-12-10 > > > 10:17:46.0 +0800 +++ linux/drivers/pnp/system.c > > > > Thanks Shaohua, I tested this as well and it appears to have worked > > around the issue for me. > > > > Now, in dmesg, I get: > > > > system 00:01: ioport range 0x290-0x29f has been reserved > > (...) > > system 00:01: ioport range 0x290-0x294 could not be reserved > > > > In /proc/ioports I see: > > > > 0290-029f : pnp 00:01 > > 0290-0297 : it87 > > 0290-0297 : it87 > Unfortunately this can't solve all such issues. > > Adam & Bjorn, > Could we just reserve IO ports >= 0x1000 in pnp system driver? The > purpose of the driver is to avoid resource conflict with PCI device, and > PCI device can't user io port < 0x1000. The purpose of the PNP system driver is to avoid conflicts with *all* devices. And if the PNP core were a little smarter, we wouldn't need the system driver at all. We don't have one for PCI -- the PCI core manages resources for all PCI devices, even ones that have no driver. Why is 0x1000 a magic number? drivers/acpi/motherboard.c used to ignore IO port ranges that ended below PCIBIOS_MIN_IO (== 0x1000 for most architectures). I don't think Linux will assign IO ports below PCIBIOS_MIN_IO to a PCI device, but the BIOS could, and I've seen CardBus devices below PCIBIOS_MIN_IO. I think having drivers/pnp/system.c ignore resources below PCIBIOS_MIN_IO would be a hack that happens to cover up problems like this without understanding the real cause. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Sunday 16 December 2007 06:59:39 pm Shaohua Li wrote: On Sun, 2007-12-09 at 23:02 -0500, Mike Houston wrote: On Mon, 10 Dec 2007 10:31:27 +0800 Shaohua Li [EMAIL PROTECTED] wrote: This should exist in previous kernel (before we remove acpi motherboard driver) too. Basically it's a broken BIOS. Could below patch work around it? Thanks, Shaohua Index: linux/drivers/pnp/system.c === --- linux.orig/drivers/pnp/system.c 2007-12-10 10:17:46.0 +0800 +++ linux/drivers/pnp/system.c Thanks Shaohua, I tested this as well and it appears to have worked around the issue for me. Now, in dmesg, I get: system 00:01: ioport range 0x290-0x29f has been reserved (...) system 00:01: ioport range 0x290-0x294 could not be reserved In /proc/ioports I see: 0290-029f : pnp 00:01 0290-0297 : it87 0290-0297 : it87 Unfortunately this can't solve all such issues. Adam Bjorn, Could we just reserve IO ports = 0x1000 in pnp system driver? The purpose of the driver is to avoid resource conflict with PCI device, and PCI device can't user io port 0x1000. The purpose of the PNP system driver is to avoid conflicts with *all* devices. And if the PNP core were a little smarter, we wouldn't need the system driver at all. We don't have one for PCI -- the PCI core manages resources for all PCI devices, even ones that have no driver. Why is 0x1000 a magic number? drivers/acpi/motherboard.c used to ignore IO port ranges that ended below PCIBIOS_MIN_IO (== 0x1000 for most architectures). I don't think Linux will assign IO ports below PCIBIOS_MIN_IO to a PCI device, but the BIOS could, and I've seen CardBus devices below PCIBIOS_MIN_IO. I think having drivers/pnp/system.c ignore resources below PCIBIOS_MIN_IO would be a hack that happens to cover up problems like this without understanding the real cause. Bjorn -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Sun, 2007-12-09 at 23:02 -0500, Mike Houston wrote: > On Mon, 10 Dec 2007 10:31:27 +0800 > Shaohua Li <[EMAIL PROTECTED]> wrote: > > This should exist in previous kernel (before we remove acpi > > motherboard driver) too. Basically it's a broken BIOS. Could below > > patch work around it? > > > > Thanks, > > Shaohua > > > > Index: linux/drivers/pnp/system.c > > === > > --- linux.orig/drivers/pnp/system.c 2007-12-10 > > 10:17:46.0 +0800 +++ linux/drivers/pnp/system.c > > Thanks Shaohua, I tested this as well and it appears to have worked > around the issue for me. > > Now, in dmesg, I get: > > system 00:01: ioport range 0x290-0x29f has been reserved > (...) > system 00:01: ioport range 0x290-0x294 could not be reserved > > In /proc/ioports I see: > > 0290-029f : pnp 00:01 > 0290-0297 : it87 > 0290-0297 : it87 Unfortunately this can't solve all such issues. Adam & Bjorn, Could we just reserve IO ports >= 0x1000 in pnp system driver? The purpose of the driver is to avoid resource conflict with PCI device, and PCI device can't user io port < 0x1000. Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Sun, 2007-12-09 at 23:02 -0500, Mike Houston wrote: On Mon, 10 Dec 2007 10:31:27 +0800 Shaohua Li [EMAIL PROTECTED] wrote: This should exist in previous kernel (before we remove acpi motherboard driver) too. Basically it's a broken BIOS. Could below patch work around it? Thanks, Shaohua Index: linux/drivers/pnp/system.c === --- linux.orig/drivers/pnp/system.c 2007-12-10 10:17:46.0 +0800 +++ linux/drivers/pnp/system.c Thanks Shaohua, I tested this as well and it appears to have worked around the issue for me. Now, in dmesg, I get: system 00:01: ioport range 0x290-0x29f has been reserved (...) system 00:01: ioport range 0x290-0x294 could not be reserved In /proc/ioports I see: 0290-029f : pnp 00:01 0290-0297 : it87 0290-0297 : it87 Unfortunately this can't solve all such issues. Adam Bjorn, Could we just reserve IO ports = 0x1000 in pnp system driver? The purpose of the driver is to avoid resource conflict with PCI device, and PCI device can't user io port 0x1000. Thanks, Shaohua -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Mon, 10 Dec 2007 10:31:27 +0800 Shaohua Li <[EMAIL PROTECTED]> wrote: > This should exist in previous kernel (before we remove acpi > motherboard driver) too. Basically it's a broken BIOS. Could below > patch work around it? > > Thanks, > Shaohua > > Index: linux/drivers/pnp/system.c > === > --- linux.orig/drivers/pnp/system.c 2007-12-10 > 10:17:46.0 +0800 +++ linux/drivers/pnp/system.c Thanks Shaohua, I tested this as well and it appears to have worked around the issue for me. Now, in dmesg, I get: system 00:01: ioport range 0x290-0x29f has been reserved (...) system 00:01: ioport range 0x290-0x294 could not be reserved In /proc/ioports I see: 0290-029f : pnp 00:01 0290-0297 : it87 0290-0297 : it87 The it87 sensor now works without disabling acpipnp Mike Houston -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Sunday December 9 2007 09:31:27 pm Shaohua Li wrote:
> On Sun, 2007-12-09 at 23:04 +0100, Adrian Bunk wrote:
> > On Sun, Dec 09, 2007 at 04:12:25PM -0500, Elvis Pranskevichus wrote:
> > > Jean Delvare wrote:
> > > > Hi Mike,
> > > >
> > > > On Sat, 8 Dec 2007 21:22:34 -0500, Mike Houston wrote:
> > > >> On Sun, 9 Dec 2007 01:05:54 +0100
> > > >>
> > > >> Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > >> > On Tue, Dec 04, 2007 at 09:51:54PM -0500, Mike Houston wrote:
> > > >> > > I finally got around to testing Linux 2.6.24 (2.6.24-rc4) and
> > > >> > > found that the it87 driver fails to probe and consequently, my
> > > >> > > sensors no longer work. This was fine with Linux 2.6.23.8 (the
> > > >> > > last kernel I was using)
> > > >> > >
> > > >> > > The necessary modules load, but:
> > > >> > >
> > > >> > > it87: Found IT8718F chip at 0x290, revision 2
> > > >> > > it87: in3 is VCC (+5V)
> > > >> > > it87 it87.656: Failed to request region 0x290-0x297
> > > >> > > it87: probe of it87.656 failed with error -16
> > > >> > >
> > > >> > > Coretemp still works.
> > > >> > >
> > > >> > > It appears it has something to do with the ioport range being
> > > >> > > reserved for some reason:
> > > >> > >
> > > >> > > system 00:01: ioport range 0x290-0x29f has been reserved
> > > >> >
> > > >> > Thanks for your report.
> > > >> >
> > > >> > Please also provide:
> > > >> > - dmesg from 2.6.23.8
> > > >> > - The output of "cat /proc/ioports" for both kernels
> > > >>
> > > >> Thanks Adrian, here is the information you have requested, for
> > > >> both kernels (I have 2.6.23.9 now though where it87 still works)
> > > >>
> > > >> Linux 2.6.23.9:
> > > >> http://www.mikeserv.com/temp/proc_ioports-2.6.23.9.txt
> > > >> http://www.mikeserv.com/temp/dmesg-2.6.23.9.txt
> > > >> http://www.mikeserv.com/temp/config-2.6.23.9.txt
> > > >>
> > > >> Linux 2.6.24-rc4:
> > > >> http://www.mikeserv.com/temp/proc_ioports-2.6.24-rc4.txt
> > > >> http://www.mikeserv.com/temp/dmesg-2.6.24-rc4.txt
> > > >
> > > > This one shows:
> > > >
> > > > system 00:01: ioport range 0x290-0x29f has been reserved
> > > > (...)
> > > > system 00:01: ioport range 0x290-0x294 has been reserved
> > > >
> > > > This is clearly not correct as both areas overlap. The second
> > > > reservation is responsible for the it87 breakage, because it
> > > > conflicts with what the it87 driver later attempts to request
> > > > (0x290-0x297). The first is wrong as well (the IT87xxF environment
> > > > controller I/O area is 8 port wide, not 16) but shouldn't be a
> > > > problem in practice.
> > > >
> > > > These port reservations weren't happening in 2.6.23.9 according to
> > > > your dmesg output for that kernel. I don't know what changed in this
> > > > area since 2.6.23.9, maybe Bjorn or Adam (Cc'd) can tell.
> > >
> > > Hi,
> > >
> > > I have exactly the same problem here on a Gigabyte GA-965G-DS3
> > > motherboard based box:
> > >
> > > it87: Found IT8718F chip at 0x290, revision 1
> > > it87: in3 is VCC (+5V)
> > > it87 it87.656: Failed to request region 0x290-0x297
> > > it87: probe of it87.656 failed with error -16
> > >
> > > git bisecting revealed the offending commit:
> > >
> > > a7839e960675b54: PNP: increase the maximum number of resources
> > >
> > > Happened between rc3 and rc4.
> >
> > Thanks for doing the work of bisecting!
> >
> > > > Either way, the overlapping areas smell like a BIOS bug, meaning that
> > > > you should look for an updated BIOS for your system first.
> > > >
> > > >> http://www.mikeserv.com/temp/config-2.6.24-rc4.txt
> > >
> > > This indeed looks like a broken ACPI BIOS since the aforementioned
> > > commit touches only the PNP ACPI driver. I'm not sure how to work
> > > around this, though. Ideas?
> >
> > People responsible for this commit + ACPI maintainer added to Cc.
>
> This should exist in previous kernel (before we remove acpi motherboard
> driver) too. Basically it's a broken BIOS. Could below patch work around
> it?
>
> Thanks,
> Shaohua
>
> Index: linux/drivers/pnp/system.c
> ===
> --- linux.orig/drivers/pnp/system.c 2007-12-10 10:17:46.0 +0800
> +++ linux/drivers/pnp/system.c2007-12-10 10:24:42.0 +0800
> @@ -22,7 +22,7 @@ static const struct pnp_device_id pnp_de
> {"", 0}
> };
>
> -static void reserve_range(struct pnp_dev *dev, resource_size_t start,
> +static struct resource* reserve_range(struct pnp_dev *dev, resource_size_t
> start, resource_size_t end, int port)
> {
> char *regionid;
> @@ -31,16 +31,14 @@ static void reserve_range(struct pnp_dev
>
> regionid = kmalloc(16, GFP_KERNEL);
> if (!regionid)
> - return;
> + return NULL;
>
> snprintf(regionid, 16, "pnp %s", pnpid);
> if (port)
> res = request_region(start, end - start + 1, regionid);
> else
> res = request_mem_region(start, end - start + 1, regionid);
> - if (res)
> -
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Sun, 2007-12-09 at 23:04 +0100, Adrian Bunk wrote:
> On Sun, Dec 09, 2007 at 04:12:25PM -0500, Elvis Pranskevichus wrote:
> > Jean Delvare wrote:
> >
> > > Hi Mike,
> > >
> > > On Sat, 8 Dec 2007 21:22:34 -0500, Mike Houston wrote:
> > >> On Sun, 9 Dec 2007 01:05:54 +0100
> > >> Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > >>
> > >> > On Tue, Dec 04, 2007 at 09:51:54PM -0500, Mike Houston wrote:
> > >> > > I finally got around to testing Linux 2.6.24 (2.6.24-rc4) and
> > >> > > found that the it87 driver fails to probe and consequently, my
> > >> > > sensors no longer work. This was fine with Linux 2.6.23.8 (the
> > >> > > last kernel I was using)
> > >> > >
> > >> > > The necessary modules load, but:
> > >> > >
> > >> > > it87: Found IT8718F chip at 0x290, revision 2
> > >> > > it87: in3 is VCC (+5V)
> > >> > > it87 it87.656: Failed to request region 0x290-0x297
> > >> > > it87: probe of it87.656 failed with error -16
> > >> > >
> > >> > > Coretemp still works.
> > >> > >
> > >> > > It appears it has something to do with the ioport range being
> > >> > > reserved for some reason:
> > >> > >
> > >> > > system 00:01: ioport range 0x290-0x29f has been reserved
> > >>
> > >> >
> > >> > Thanks for your report.
> > >> >
> > >> > Please also provide:
> > >> > - dmesg from 2.6.23.8
> > >> > - The output of "cat /proc/ioports" for both kernels
> > >>
> > >> Thanks Adrian, here is the information you have requested, for
> > >> both kernels (I have 2.6.23.9 now though where it87 still works)
> > >>
> > >> Linux 2.6.23.9:
> > >> http://www.mikeserv.com/temp/proc_ioports-2.6.23.9.txt
> > >> http://www.mikeserv.com/temp/dmesg-2.6.23.9.txt
> > >> http://www.mikeserv.com/temp/config-2.6.23.9.txt
> > >>
> > >> Linux 2.6.24-rc4:
> > >> http://www.mikeserv.com/temp/proc_ioports-2.6.24-rc4.txt
> > >> http://www.mikeserv.com/temp/dmesg-2.6.24-rc4.txt
> > >
> > > This one shows:
> > >
> > > system 00:01: ioport range 0x290-0x29f has been reserved
> > > (...)
> > > system 00:01: ioport range 0x290-0x294 has been reserved
> > >
> > > This is clearly not correct as both areas overlap. The second
> > > reservation is responsible for the it87 breakage, because it conflicts
> > > with what the it87 driver later attempts to request (0x290-0x297). The
> > > first is wrong as well (the IT87xxF environment controller I/O area is
> > > 8 port wide, not 16) but shouldn't be a problem in practice.
> > >
> > > These port reservations weren't happening in 2.6.23.9 according to your
> > > dmesg output for that kernel. I don't know what changed in this area
> > > since 2.6.23.9, maybe Bjorn or Adam (Cc'd) can tell.
> > >
> >
> > Hi,
> >
> > I have exactly the same problem here on a Gigabyte GA-965G-DS3 motherboard
> > based box:
> >
> > it87: Found IT8718F chip at 0x290, revision 1
> > it87: in3 is VCC (+5V)
> > it87 it87.656: Failed to request region 0x290-0x297
> > it87: probe of it87.656 failed with error -16
> >
> > git bisecting revealed the offending commit:
> >
> > a7839e960675b54: PNP: increase the maximum number of resources
> >
> > Happened between rc3 and rc4.
>
> Thanks for doing the work of bisecting!
>
> > > Either way, the overlapping areas smell like a BIOS bug, meaning that
> > > you should look for an updated BIOS for your system first.
> > >
> > >> http://www.mikeserv.com/temp/config-2.6.24-rc4.txt
> > >
> >
> > This indeed looks like a broken ACPI BIOS since the aforementioned commit
> > touches only the PNP ACPI driver. I'm not sure how to work around this,
> > though. Ideas?
>
> People responsible for this commit + ACPI maintainer added to Cc.
This should exist in previous kernel (before we remove acpi motherboard
driver) too. Basically it's a broken BIOS. Could below patch work around
it?
Thanks,
Shaohua
Index: linux/drivers/pnp/system.c
===
--- linux.orig/drivers/pnp/system.c 2007-12-10 10:17:46.0 +0800
+++ linux/drivers/pnp/system.c 2007-12-10 10:24:42.0 +0800
@@ -22,7 +22,7 @@ static const struct pnp_device_id pnp_de
{"", 0}
};
-static void reserve_range(struct pnp_dev *dev, resource_size_t start,
+static struct resource* reserve_range(struct pnp_dev *dev, resource_size_t
start,
resource_size_t end, int port)
{
char *regionid;
@@ -31,16 +31,14 @@ static void reserve_range(struct pnp_dev
regionid = kmalloc(16, GFP_KERNEL);
if (!regionid)
- return;
+ return NULL;
snprintf(regionid, 16, "pnp %s", pnpid);
if (port)
res = request_region(start, end - start + 1, regionid);
else
res = request_mem_region(start, end - start + 1, regionid);
- if (res)
- res->flags &= ~IORESOURCE_BUSY;
- else
+ if (!res)
kfree(regionid);
/*
@@ -52,12 +50,17 @@ static void reserve_range(struct pnp_dev
port ?
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
Mike Houston wrote: On Sun, 9 Dec 2007 23:42:15 +0100 Jean Delvare <[EMAIL PROTECTED]> wrote: On Sun, 09 Dec 2007 16:12:25 -0500, Elvis Pranskevichus wrote: This indeed looks like a broken ACPI BIOS since the aforementioned commit touches only the PNP ACPI driver. I'm not sure how to work around this, though. Ideas? Complaining to Gigabyte seems to be the best approach. I just happen to have a Windows Vista installation on this box as well, and I just thought to check. Sorry, I wish I'd have thought of it sooner but I don't go there often. You folks might be interested to know that Windows appears to have the same silly problem with the i/o resources (from Device Manager): [00290 - 00294] Motherboard resources [00290 - 0029F] Motherboard resources I don't have anything that reads sensors in Windows though, so I couldn't tell you if it could access that it87 chip or not. So this pretty much confirms that it's a motherboard/bios issue. Mike Houston I'm seeing this exact problem on an Asus Nforce4 based board. Prior to moving to 2.6.24-rc4 it worked just fine. No additional acpi options were selected in kernel config. So add Asus A8N-E to the list of broken pnpacpi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Sun, 9 Dec 2007 23:42:15 +0100 Jean Delvare <[EMAIL PROTECTED]> wrote: > On Sun, 09 Dec 2007 16:12:25 -0500, Elvis Pranskevichus wrote: > > This indeed looks like a broken ACPI BIOS since the > > aforementioned commit touches only the PNP ACPI driver. I'm not > > sure how to work around this, though. Ideas? > > Complaining to Gigabyte seems to be the best approach. I just happen to have a Windows Vista installation on this box as well, and I just thought to check. Sorry, I wish I'd have thought of it sooner but I don't go there often. You folks might be interested to know that Windows appears to have the same silly problem with the i/o resources (from Device Manager): [00290 - 00294] Motherboard resources [00290 - 0029F] Motherboard resources I don't have anything that reads sensors in Windows though, so I couldn't tell you if it could access that it87 chip or not. So this pretty much confirms that it's a motherboard/bios issue. Mike Houston -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Sun, 9 Dec 2007 23:42:15 +0100 Jean Delvare <[EMAIL PROTECTED]> wrote: > In the meantime, I guess that booting with pnpacpi=off should fix > your problem. But it might break something else; I'm not sure what > the PNP ACPI driver is good for in the first place. Ahh, thanks guys. Yes, that did indeed work around the problem. My sensors work again, and I don't appear to have any ill effects. At least my devices are all working, and resource assignments (irq, io) look ok. I'll put an append in my lilo.conf for pnpacpi=off for now. /proc/ioports with pnpacpi=off: -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 0290-0297 : it87 0290-0297 : it87 03c0-03df : vga+ 0400-047f : :00:1f.0 0400-0403 : ACPI PM1a_EVT_BLK 0404-0405 : ACPI PM1a_CNT_BLK 0408-040b : ACPI PM_TMR 0410-0415 : ACPI CPU throttle 0428-042f : ACPI GPE0_BLK 0480-04bf : :00:1f.0 0500-051f : :00:1f.3 0500-051f : i801_smbus 0cf8-0cff : PCI conf1 7000-7fff : PCI Bus #02 8000-8fff : PCI Bus #04 9000-9fff : PCI Bus #03 a000-afff : PCI Bus #01 a000-a07f : :01:00.0 b000-bfff : PCI Bus #05 b000-b0ff : :05:02.0 b000-b0ff : 8139too c000-c01f : :00:1a.1 c400-c41f : :00:1d.0 c800-c81f : :00:1d.1 cc00-cc1f : :00:1d.2 d000-d01f : :00:1a.0 d400-d407 : :00:1f.2 d800-d803 : :00:1f.2 dc00-dc07 : :00:1f.2 e000-e003 : :00:1f.2 e400-e41f : :00:1f.2 Mike Houston -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
Hi Elvis, On Sun, 09 Dec 2007 16:12:25 -0500, Elvis Pranskevichus wrote: > I have exactly the same problem here on a Gigabyte GA-965G-DS3 motherboard > based box: Same motherboard as Mike has. > it87: Found IT8718F chip at 0x290, revision 1 > it87: in3 is VCC (+5V) > it87 it87.656: Failed to request region 0x290-0x297 > it87: probe of it87.656 failed with error -16 > > git bisecting revealed the offending commit: > > a7839e960675b54: PNP: increase the maximum number of resources > > Happened between rc3 and rc4. > > > Either way, the overlapping areas smell like a BIOS bug, meaning that > > you should look for an updated BIOS for your system first. > > > >> http://www.mikeserv.com/temp/config-2.6.24-rc4.txt > > > > This indeed looks like a broken ACPI BIOS since the aforementioned commit > touches only the PNP ACPI driver. I'm not sure how to work around this, > though. Ideas? Complaining to Gigabyte seems to be the best approach. In the meantime, I guess that booting with pnpacpi=off should fix your problem. But it might break something else; I'm not sure what the PNP ACPI driver is good for in the first place. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Sun, Dec 09, 2007 at 04:12:25PM -0500, Elvis Pranskevichus wrote: > Jean Delvare wrote: > > > Hi Mike, > > > > On Sat, 8 Dec 2007 21:22:34 -0500, Mike Houston wrote: > >> On Sun, 9 Dec 2007 01:05:54 +0100 > >> Adrian Bunk <[EMAIL PROTECTED]> wrote: > >> > >> > On Tue, Dec 04, 2007 at 09:51:54PM -0500, Mike Houston wrote: > >> > > I finally got around to testing Linux 2.6.24 (2.6.24-rc4) and > >> > > found that the it87 driver fails to probe and consequently, my > >> > > sensors no longer work. This was fine with Linux 2.6.23.8 (the > >> > > last kernel I was using) > >> > > > >> > > The necessary modules load, but: > >> > > > >> > > it87: Found IT8718F chip at 0x290, revision 2 > >> > > it87: in3 is VCC (+5V) > >> > > it87 it87.656: Failed to request region 0x290-0x297 > >> > > it87: probe of it87.656 failed with error -16 > >> > > > >> > > Coretemp still works. > >> > > > >> > > It appears it has something to do with the ioport range being > >> > > reserved for some reason: > >> > > > >> > > system 00:01: ioport range 0x290-0x29f has been reserved > >> > >> > > >> > Thanks for your report. > >> > > >> > Please also provide: > >> > - dmesg from 2.6.23.8 > >> > - The output of "cat /proc/ioports" for both kernels > >> > >> Thanks Adrian, here is the information you have requested, for > >> both kernels (I have 2.6.23.9 now though where it87 still works) > >> > >> Linux 2.6.23.9: > >> http://www.mikeserv.com/temp/proc_ioports-2.6.23.9.txt > >> http://www.mikeserv.com/temp/dmesg-2.6.23.9.txt > >> http://www.mikeserv.com/temp/config-2.6.23.9.txt > >> > >> Linux 2.6.24-rc4: > >> http://www.mikeserv.com/temp/proc_ioports-2.6.24-rc4.txt > >> http://www.mikeserv.com/temp/dmesg-2.6.24-rc4.txt > > > > This one shows: > > > > system 00:01: ioport range 0x290-0x29f has been reserved > > (...) > > system 00:01: ioport range 0x290-0x294 has been reserved > > > > This is clearly not correct as both areas overlap. The second > > reservation is responsible for the it87 breakage, because it conflicts > > with what the it87 driver later attempts to request (0x290-0x297). The > > first is wrong as well (the IT87xxF environment controller I/O area is > > 8 port wide, not 16) but shouldn't be a problem in practice. > > > > These port reservations weren't happening in 2.6.23.9 according to your > > dmesg output for that kernel. I don't know what changed in this area > > since 2.6.23.9, maybe Bjorn or Adam (Cc'd) can tell. > > > > Hi, > > I have exactly the same problem here on a Gigabyte GA-965G-DS3 motherboard > based box: > > it87: Found IT8718F chip at 0x290, revision 1 > it87: in3 is VCC (+5V) > it87 it87.656: Failed to request region 0x290-0x297 > it87: probe of it87.656 failed with error -16 > > git bisecting revealed the offending commit: > > a7839e960675b54: PNP: increase the maximum number of resources > > Happened between rc3 and rc4. Thanks for doing the work of bisecting! > > Either way, the overlapping areas smell like a BIOS bug, meaning that > > you should look for an updated BIOS for your system first. > > > >> http://www.mikeserv.com/temp/config-2.6.24-rc4.txt > > > > This indeed looks like a broken ACPI BIOS since the aforementioned commit > touches only the PNP ACPI driver. I'm not sure how to work around this, > though. Ideas? People responsible for this commit + ACPI maintainer added to Cc. > Elvis cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
Jean Delvare wrote: > Hi Mike, > > On Sat, 8 Dec 2007 21:22:34 -0500, Mike Houston wrote: >> On Sun, 9 Dec 2007 01:05:54 +0100 >> Adrian Bunk <[EMAIL PROTECTED]> wrote: >> >> > On Tue, Dec 04, 2007 at 09:51:54PM -0500, Mike Houston wrote: >> > > I finally got around to testing Linux 2.6.24 (2.6.24-rc4) and >> > > found that the it87 driver fails to probe and consequently, my >> > > sensors no longer work. This was fine with Linux 2.6.23.8 (the >> > > last kernel I was using) >> > > >> > > The necessary modules load, but: >> > > >> > > it87: Found IT8718F chip at 0x290, revision 2 >> > > it87: in3 is VCC (+5V) >> > > it87 it87.656: Failed to request region 0x290-0x297 >> > > it87: probe of it87.656 failed with error -16 >> > > >> > > Coretemp still works. >> > > >> > > It appears it has something to do with the ioport range being >> > > reserved for some reason: >> > > >> > > system 00:01: ioport range 0x290-0x29f has been reserved >> >> > >> > Thanks for your report. >> > >> > Please also provide: >> > - dmesg from 2.6.23.8 >> > - The output of "cat /proc/ioports" for both kernels >> >> Thanks Adrian, here is the information you have requested, for >> both kernels (I have 2.6.23.9 now though where it87 still works) >> >> Linux 2.6.23.9: >> http://www.mikeserv.com/temp/proc_ioports-2.6.23.9.txt >> http://www.mikeserv.com/temp/dmesg-2.6.23.9.txt >> http://www.mikeserv.com/temp/config-2.6.23.9.txt >> >> Linux 2.6.24-rc4: >> http://www.mikeserv.com/temp/proc_ioports-2.6.24-rc4.txt >> http://www.mikeserv.com/temp/dmesg-2.6.24-rc4.txt > > This one shows: > > system 00:01: ioport range 0x290-0x29f has been reserved > (...) > system 00:01: ioport range 0x290-0x294 has been reserved > > This is clearly not correct as both areas overlap. The second > reservation is responsible for the it87 breakage, because it conflicts > with what the it87 driver later attempts to request (0x290-0x297). The > first is wrong as well (the IT87xxF environment controller I/O area is > 8 port wide, not 16) but shouldn't be a problem in practice. > > These port reservations weren't happening in 2.6.23.9 according to your > dmesg output for that kernel. I don't know what changed in this area > since 2.6.23.9, maybe Bjorn or Adam (Cc'd) can tell. > Hi, I have exactly the same problem here on a Gigabyte GA-965G-DS3 motherboard based box: it87: Found IT8718F chip at 0x290, revision 1 it87: in3 is VCC (+5V) it87 it87.656: Failed to request region 0x290-0x297 it87: probe of it87.656 failed with error -16 git bisecting revealed the offending commit: a7839e960675b54: PNP: increase the maximum number of resources Happened between rc3 and rc4. > Either way, the overlapping areas smell like a BIOS bug, meaning that > you should look for an updated BIOS for your system first. > >> http://www.mikeserv.com/temp/config-2.6.24-rc4.txt > This indeed looks like a broken ACPI BIOS since the aforementioned commit touches only the PNP ACPI driver. I'm not sure how to work around this, though. Ideas? -- Elvis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Sun, 9 Dec 2007 10:50:28 +0100 Jean Delvare <[EMAIL PROTECTED]> wrote: > This one shows: > > system 00:01: ioport range 0x290-0x29f has been reserved > (...) > system 00:01: ioport range 0x290-0x294 has been reserved > > This is clearly not correct as both areas overlap. The second > reservation is responsible for the it87 breakage, because it > conflicts with what the it87 driver later attempts to request > (0x290-0x297). The first is wrong as well (the IT87xxF environment > controller I/O area is 8 port wide, not 16) but shouldn't be a > problem in practice. > > These port reservations weren't happening in 2.6.23.9 according to > your dmesg output for that kernel. I don't know what changed in > this area since 2.6.23.9, maybe Bjorn or Adam (Cc'd) can tell. > > Either way, the overlapping areas smell like a BIOS bug, meaning > that you should look for an updated BIOS for your system first. > > > http://www.mikeserv.com/temp/config-2.6.24-rc4.txt Thanks for the suggestion, Jean. I flashed my bios to the latest (F12) for my Gigabyte GA-965P-DS3 (rev. 3.3) motherboard http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=2456 Unfortunately, there has been no change to the situation. The same ioport ranges are being reserved when booting with 2.6.24-rc4 and it87 does not work. No change to the situation in 2.6.23.9 either, the io conflict is not occuring and it87 still works there. Mike Houston -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
Hi Mike, On Sat, 8 Dec 2007 21:22:34 -0500, Mike Houston wrote: > On Sun, 9 Dec 2007 01:05:54 +0100 > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > On Tue, Dec 04, 2007 at 09:51:54PM -0500, Mike Houston wrote: > > > I finally got around to testing Linux 2.6.24 (2.6.24-rc4) and > > > found that the it87 driver fails to probe and consequently, my > > > sensors no longer work. This was fine with Linux 2.6.23.8 (the > > > last kernel I was using) > > > > > > The necessary modules load, but: > > > > > > it87: Found IT8718F chip at 0x290, revision 2 > > > it87: in3 is VCC (+5V) > > > it87 it87.656: Failed to request region 0x290-0x297 > > > it87: probe of it87.656 failed with error -16 > > > > > > Coretemp still works. > > > > > > It appears it has something to do with the ioport range being > > > reserved for some reason: > > > > > > system 00:01: ioport range 0x290-0x29f has been reserved > > > > > Thanks for your report. > > > > Please also provide: > > - dmesg from 2.6.23.8 > > - The output of "cat /proc/ioports" for both kernels > > Thanks Adrian, here is the information you have requested, for > both kernels (I have 2.6.23.9 now though where it87 still works) > > Linux 2.6.23.9: > http://www.mikeserv.com/temp/proc_ioports-2.6.23.9.txt > http://www.mikeserv.com/temp/dmesg-2.6.23.9.txt > http://www.mikeserv.com/temp/config-2.6.23.9.txt > > Linux 2.6.24-rc4: > http://www.mikeserv.com/temp/proc_ioports-2.6.24-rc4.txt > http://www.mikeserv.com/temp/dmesg-2.6.24-rc4.txt This one shows: system 00:01: ioport range 0x290-0x29f has been reserved (...) system 00:01: ioport range 0x290-0x294 has been reserved This is clearly not correct as both areas overlap. The second reservation is responsible for the it87 breakage, because it conflicts with what the it87 driver later attempts to request (0x290-0x297). The first is wrong as well (the IT87xxF environment controller I/O area is 8 port wide, not 16) but shouldn't be a problem in practice. These port reservations weren't happening in 2.6.23.9 according to your dmesg output for that kernel. I don't know what changed in this area since 2.6.23.9, maybe Bjorn or Adam (Cc'd) can tell. Either way, the overlapping areas smell like a BIOS bug, meaning that you should look for an updated BIOS for your system first. > http://www.mikeserv.com/temp/config-2.6.24-rc4.txt -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
Hi Mike, On Sat, 8 Dec 2007 21:22:34 -0500, Mike Houston wrote: On Sun, 9 Dec 2007 01:05:54 +0100 Adrian Bunk [EMAIL PROTECTED] wrote: On Tue, Dec 04, 2007 at 09:51:54PM -0500, Mike Houston wrote: I finally got around to testing Linux 2.6.24 (2.6.24-rc4) and found that the it87 driver fails to probe and consequently, my sensors no longer work. This was fine with Linux 2.6.23.8 (the last kernel I was using) The necessary modules load, but: it87: Found IT8718F chip at 0x290, revision 2 it87: in3 is VCC (+5V) it87 it87.656: Failed to request region 0x290-0x297 it87: probe of it87.656 failed with error -16 Coretemp still works. It appears it has something to do with the ioport range being reserved for some reason: system 00:01: ioport range 0x290-0x29f has been reserved Thanks for your report. Please also provide: - dmesg from 2.6.23.8 - The output of cat /proc/ioports for both kernels Thanks Adrian, here is the information you have requested, for both kernels (I have 2.6.23.9 now though where it87 still works) Linux 2.6.23.9: http://www.mikeserv.com/temp/proc_ioports-2.6.23.9.txt http://www.mikeserv.com/temp/dmesg-2.6.23.9.txt http://www.mikeserv.com/temp/config-2.6.23.9.txt Linux 2.6.24-rc4: http://www.mikeserv.com/temp/proc_ioports-2.6.24-rc4.txt http://www.mikeserv.com/temp/dmesg-2.6.24-rc4.txt This one shows: system 00:01: ioport range 0x290-0x29f has been reserved (...) system 00:01: ioport range 0x290-0x294 has been reserved This is clearly not correct as both areas overlap. The second reservation is responsible for the it87 breakage, because it conflicts with what the it87 driver later attempts to request (0x290-0x297). The first is wrong as well (the IT87xxF environment controller I/O area is 8 port wide, not 16) but shouldn't be a problem in practice. These port reservations weren't happening in 2.6.23.9 according to your dmesg output for that kernel. I don't know what changed in this area since 2.6.23.9, maybe Bjorn or Adam (Cc'd) can tell. Either way, the overlapping areas smell like a BIOS bug, meaning that you should look for an updated BIOS for your system first. http://www.mikeserv.com/temp/config-2.6.24-rc4.txt -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Sun, 9 Dec 2007 10:50:28 +0100 Jean Delvare [EMAIL PROTECTED] wrote: This one shows: system 00:01: ioport range 0x290-0x29f has been reserved (...) system 00:01: ioport range 0x290-0x294 has been reserved This is clearly not correct as both areas overlap. The second reservation is responsible for the it87 breakage, because it conflicts with what the it87 driver later attempts to request (0x290-0x297). The first is wrong as well (the IT87xxF environment controller I/O area is 8 port wide, not 16) but shouldn't be a problem in practice. These port reservations weren't happening in 2.6.23.9 according to your dmesg output for that kernel. I don't know what changed in this area since 2.6.23.9, maybe Bjorn or Adam (Cc'd) can tell. Either way, the overlapping areas smell like a BIOS bug, meaning that you should look for an updated BIOS for your system first. http://www.mikeserv.com/temp/config-2.6.24-rc4.txt Thanks for the suggestion, Jean. I flashed my bios to the latest (F12) for my Gigabyte GA-965P-DS3 (rev. 3.3) motherboard http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=2456 Unfortunately, there has been no change to the situation. The same ioport ranges are being reserved when booting with 2.6.24-rc4 and it87 does not work. No change to the situation in 2.6.23.9 either, the io conflict is not occuring and it87 still works there. Mike Houston -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
Jean Delvare wrote: Hi Mike, On Sat, 8 Dec 2007 21:22:34 -0500, Mike Houston wrote: On Sun, 9 Dec 2007 01:05:54 +0100 Adrian Bunk [EMAIL PROTECTED] wrote: On Tue, Dec 04, 2007 at 09:51:54PM -0500, Mike Houston wrote: I finally got around to testing Linux 2.6.24 (2.6.24-rc4) and found that the it87 driver fails to probe and consequently, my sensors no longer work. This was fine with Linux 2.6.23.8 (the last kernel I was using) The necessary modules load, but: it87: Found IT8718F chip at 0x290, revision 2 it87: in3 is VCC (+5V) it87 it87.656: Failed to request region 0x290-0x297 it87: probe of it87.656 failed with error -16 Coretemp still works. It appears it has something to do with the ioport range being reserved for some reason: system 00:01: ioport range 0x290-0x29f has been reserved Thanks for your report. Please also provide: - dmesg from 2.6.23.8 - The output of cat /proc/ioports for both kernels Thanks Adrian, here is the information you have requested, for both kernels (I have 2.6.23.9 now though where it87 still works) Linux 2.6.23.9: http://www.mikeserv.com/temp/proc_ioports-2.6.23.9.txt http://www.mikeserv.com/temp/dmesg-2.6.23.9.txt http://www.mikeserv.com/temp/config-2.6.23.9.txt Linux 2.6.24-rc4: http://www.mikeserv.com/temp/proc_ioports-2.6.24-rc4.txt http://www.mikeserv.com/temp/dmesg-2.6.24-rc4.txt This one shows: system 00:01: ioport range 0x290-0x29f has been reserved (...) system 00:01: ioport range 0x290-0x294 has been reserved This is clearly not correct as both areas overlap. The second reservation is responsible for the it87 breakage, because it conflicts with what the it87 driver later attempts to request (0x290-0x297). The first is wrong as well (the IT87xxF environment controller I/O area is 8 port wide, not 16) but shouldn't be a problem in practice. These port reservations weren't happening in 2.6.23.9 according to your dmesg output for that kernel. I don't know what changed in this area since 2.6.23.9, maybe Bjorn or Adam (Cc'd) can tell. Hi, I have exactly the same problem here on a Gigabyte GA-965G-DS3 motherboard based box: it87: Found IT8718F chip at 0x290, revision 1 it87: in3 is VCC (+5V) it87 it87.656: Failed to request region 0x290-0x297 it87: probe of it87.656 failed with error -16 git bisecting revealed the offending commit: a7839e960675b54: PNP: increase the maximum number of resources Happened between rc3 and rc4. Either way, the overlapping areas smell like a BIOS bug, meaning that you should look for an updated BIOS for your system first. http://www.mikeserv.com/temp/config-2.6.24-rc4.txt This indeed looks like a broken ACPI BIOS since the aforementioned commit touches only the PNP ACPI driver. I'm not sure how to work around this, though. Ideas? -- Elvis -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Sun, Dec 09, 2007 at 04:12:25PM -0500, Elvis Pranskevichus wrote: Jean Delvare wrote: Hi Mike, On Sat, 8 Dec 2007 21:22:34 -0500, Mike Houston wrote: On Sun, 9 Dec 2007 01:05:54 +0100 Adrian Bunk [EMAIL PROTECTED] wrote: On Tue, Dec 04, 2007 at 09:51:54PM -0500, Mike Houston wrote: I finally got around to testing Linux 2.6.24 (2.6.24-rc4) and found that the it87 driver fails to probe and consequently, my sensors no longer work. This was fine with Linux 2.6.23.8 (the last kernel I was using) The necessary modules load, but: it87: Found IT8718F chip at 0x290, revision 2 it87: in3 is VCC (+5V) it87 it87.656: Failed to request region 0x290-0x297 it87: probe of it87.656 failed with error -16 Coretemp still works. It appears it has something to do with the ioport range being reserved for some reason: system 00:01: ioport range 0x290-0x29f has been reserved Thanks for your report. Please also provide: - dmesg from 2.6.23.8 - The output of cat /proc/ioports for both kernels Thanks Adrian, here is the information you have requested, for both kernels (I have 2.6.23.9 now though where it87 still works) Linux 2.6.23.9: http://www.mikeserv.com/temp/proc_ioports-2.6.23.9.txt http://www.mikeserv.com/temp/dmesg-2.6.23.9.txt http://www.mikeserv.com/temp/config-2.6.23.9.txt Linux 2.6.24-rc4: http://www.mikeserv.com/temp/proc_ioports-2.6.24-rc4.txt http://www.mikeserv.com/temp/dmesg-2.6.24-rc4.txt This one shows: system 00:01: ioport range 0x290-0x29f has been reserved (...) system 00:01: ioport range 0x290-0x294 has been reserved This is clearly not correct as both areas overlap. The second reservation is responsible for the it87 breakage, because it conflicts with what the it87 driver later attempts to request (0x290-0x297). The first is wrong as well (the IT87xxF environment controller I/O area is 8 port wide, not 16) but shouldn't be a problem in practice. These port reservations weren't happening in 2.6.23.9 according to your dmesg output for that kernel. I don't know what changed in this area since 2.6.23.9, maybe Bjorn or Adam (Cc'd) can tell. Hi, I have exactly the same problem here on a Gigabyte GA-965G-DS3 motherboard based box: it87: Found IT8718F chip at 0x290, revision 1 it87: in3 is VCC (+5V) it87 it87.656: Failed to request region 0x290-0x297 it87: probe of it87.656 failed with error -16 git bisecting revealed the offending commit: a7839e960675b54: PNP: increase the maximum number of resources Happened between rc3 and rc4. Thanks for doing the work of bisecting! Either way, the overlapping areas smell like a BIOS bug, meaning that you should look for an updated BIOS for your system first. http://www.mikeserv.com/temp/config-2.6.24-rc4.txt This indeed looks like a broken ACPI BIOS since the aforementioned commit touches only the PNP ACPI driver. I'm not sure how to work around this, though. Ideas? People responsible for this commit + ACPI maintainer added to Cc. Elvis cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
Hi Elvis, On Sun, 09 Dec 2007 16:12:25 -0500, Elvis Pranskevichus wrote: I have exactly the same problem here on a Gigabyte GA-965G-DS3 motherboard based box: Same motherboard as Mike has. it87: Found IT8718F chip at 0x290, revision 1 it87: in3 is VCC (+5V) it87 it87.656: Failed to request region 0x290-0x297 it87: probe of it87.656 failed with error -16 git bisecting revealed the offending commit: a7839e960675b54: PNP: increase the maximum number of resources Happened between rc3 and rc4. Either way, the overlapping areas smell like a BIOS bug, meaning that you should look for an updated BIOS for your system first. http://www.mikeserv.com/temp/config-2.6.24-rc4.txt This indeed looks like a broken ACPI BIOS since the aforementioned commit touches only the PNP ACPI driver. I'm not sure how to work around this, though. Ideas? Complaining to Gigabyte seems to be the best approach. In the meantime, I guess that booting with pnpacpi=off should fix your problem. But it might break something else; I'm not sure what the PNP ACPI driver is good for in the first place. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Sun, 9 Dec 2007 23:42:15 +0100 Jean Delvare [EMAIL PROTECTED] wrote: In the meantime, I guess that booting with pnpacpi=off should fix your problem. But it might break something else; I'm not sure what the PNP ACPI driver is good for in the first place. Ahh, thanks guys. Yes, that did indeed work around the problem. My sensors work again, and I don't appear to have any ill effects. At least my devices are all working, and resource assignments (irq, io) look ok. I'll put an append in my lilo.conf for pnpacpi=off for now. /proc/ioports with pnpacpi=off: -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 0290-0297 : it87 0290-0297 : it87 03c0-03df : vga+ 0400-047f : :00:1f.0 0400-0403 : ACPI PM1a_EVT_BLK 0404-0405 : ACPI PM1a_CNT_BLK 0408-040b : ACPI PM_TMR 0410-0415 : ACPI CPU throttle 0428-042f : ACPI GPE0_BLK 0480-04bf : :00:1f.0 0500-051f : :00:1f.3 0500-051f : i801_smbus 0cf8-0cff : PCI conf1 7000-7fff : PCI Bus #02 8000-8fff : PCI Bus #04 9000-9fff : PCI Bus #03 a000-afff : PCI Bus #01 a000-a07f : :01:00.0 b000-bfff : PCI Bus #05 b000-b0ff : :05:02.0 b000-b0ff : 8139too c000-c01f : :00:1a.1 c400-c41f : :00:1d.0 c800-c81f : :00:1d.1 cc00-cc1f : :00:1d.2 d000-d01f : :00:1a.0 d400-d407 : :00:1f.2 d800-d803 : :00:1f.2 dc00-dc07 : :00:1f.2 e000-e003 : :00:1f.2 e400-e41f : :00:1f.2 Mike Houston -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Sun, 9 Dec 2007 23:42:15 +0100 Jean Delvare [EMAIL PROTECTED] wrote: On Sun, 09 Dec 2007 16:12:25 -0500, Elvis Pranskevichus wrote: This indeed looks like a broken ACPI BIOS since the aforementioned commit touches only the PNP ACPI driver. I'm not sure how to work around this, though. Ideas? Complaining to Gigabyte seems to be the best approach. I just happen to have a Windows Vista installation on this box as well, and I just thought to check. Sorry, I wish I'd have thought of it sooner but I don't go there often. You folks might be interested to know that Windows appears to have the same silly problem with the i/o resources (from Device Manager): [00290 - 00294] Motherboard resources [00290 - 0029F] Motherboard resources I don't have anything that reads sensors in Windows though, so I couldn't tell you if it could access that it87 chip or not. So this pretty much confirms that it's a motherboard/bios issue. Mike Houston -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
Mike Houston wrote: On Sun, 9 Dec 2007 23:42:15 +0100 Jean Delvare [EMAIL PROTECTED] wrote: On Sun, 09 Dec 2007 16:12:25 -0500, Elvis Pranskevichus wrote: This indeed looks like a broken ACPI BIOS since the aforementioned commit touches only the PNP ACPI driver. I'm not sure how to work around this, though. Ideas? Complaining to Gigabyte seems to be the best approach. I just happen to have a Windows Vista installation on this box as well, and I just thought to check. Sorry, I wish I'd have thought of it sooner but I don't go there often. You folks might be interested to know that Windows appears to have the same silly problem with the i/o resources (from Device Manager): [00290 - 00294] Motherboard resources [00290 - 0029F] Motherboard resources I don't have anything that reads sensors in Windows though, so I couldn't tell you if it could access that it87 chip or not. So this pretty much confirms that it's a motherboard/bios issue. Mike Houston I'm seeing this exact problem on an Asus Nforce4 based board. Prior to moving to 2.6.24-rc4 it worked just fine. No additional acpi options were selected in kernel config. So add Asus A8N-E to the list of broken pnpacpi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Sun, 2007-12-09 at 23:04 +0100, Adrian Bunk wrote:
On Sun, Dec 09, 2007 at 04:12:25PM -0500, Elvis Pranskevichus wrote:
Jean Delvare wrote:
Hi Mike,
On Sat, 8 Dec 2007 21:22:34 -0500, Mike Houston wrote:
On Sun, 9 Dec 2007 01:05:54 +0100
Adrian Bunk [EMAIL PROTECTED] wrote:
On Tue, Dec 04, 2007 at 09:51:54PM -0500, Mike Houston wrote:
I finally got around to testing Linux 2.6.24 (2.6.24-rc4) and
found that the it87 driver fails to probe and consequently, my
sensors no longer work. This was fine with Linux 2.6.23.8 (the
last kernel I was using)
The necessary modules load, but:
it87: Found IT8718F chip at 0x290, revision 2
it87: in3 is VCC (+5V)
it87 it87.656: Failed to request region 0x290-0x297
it87: probe of it87.656 failed with error -16
Coretemp still works.
It appears it has something to do with the ioport range being
reserved for some reason:
system 00:01: ioport range 0x290-0x29f has been reserved
Thanks for your report.
Please also provide:
- dmesg from 2.6.23.8
- The output of cat /proc/ioports for both kernels
Thanks Adrian, here is the information you have requested, for
both kernels (I have 2.6.23.9 now though where it87 still works)
Linux 2.6.23.9:
http://www.mikeserv.com/temp/proc_ioports-2.6.23.9.txt
http://www.mikeserv.com/temp/dmesg-2.6.23.9.txt
http://www.mikeserv.com/temp/config-2.6.23.9.txt
Linux 2.6.24-rc4:
http://www.mikeserv.com/temp/proc_ioports-2.6.24-rc4.txt
http://www.mikeserv.com/temp/dmesg-2.6.24-rc4.txt
This one shows:
system 00:01: ioport range 0x290-0x29f has been reserved
(...)
system 00:01: ioport range 0x290-0x294 has been reserved
This is clearly not correct as both areas overlap. The second
reservation is responsible for the it87 breakage, because it conflicts
with what the it87 driver later attempts to request (0x290-0x297). The
first is wrong as well (the IT87xxF environment controller I/O area is
8 port wide, not 16) but shouldn't be a problem in practice.
These port reservations weren't happening in 2.6.23.9 according to your
dmesg output for that kernel. I don't know what changed in this area
since 2.6.23.9, maybe Bjorn or Adam (Cc'd) can tell.
Hi,
I have exactly the same problem here on a Gigabyte GA-965G-DS3 motherboard
based box:
it87: Found IT8718F chip at 0x290, revision 1
it87: in3 is VCC (+5V)
it87 it87.656: Failed to request region 0x290-0x297
it87: probe of it87.656 failed with error -16
git bisecting revealed the offending commit:
a7839e960675b54: PNP: increase the maximum number of resources
Happened between rc3 and rc4.
Thanks for doing the work of bisecting!
Either way, the overlapping areas smell like a BIOS bug, meaning that
you should look for an updated BIOS for your system first.
http://www.mikeserv.com/temp/config-2.6.24-rc4.txt
This indeed looks like a broken ACPI BIOS since the aforementioned commit
touches only the PNP ACPI driver. I'm not sure how to work around this,
though. Ideas?
People responsible for this commit + ACPI maintainer added to Cc.
This should exist in previous kernel (before we remove acpi motherboard
driver) too. Basically it's a broken BIOS. Could below patch work around
it?
Thanks,
Shaohua
Index: linux/drivers/pnp/system.c
===
--- linux.orig/drivers/pnp/system.c 2007-12-10 10:17:46.0 +0800
+++ linux/drivers/pnp/system.c 2007-12-10 10:24:42.0 +0800
@@ -22,7 +22,7 @@ static const struct pnp_device_id pnp_de
{, 0}
};
-static void reserve_range(struct pnp_dev *dev, resource_size_t start,
+static struct resource* reserve_range(struct pnp_dev *dev, resource_size_t
start,
resource_size_t end, int port)
{
char *regionid;
@@ -31,16 +31,14 @@ static void reserve_range(struct pnp_dev
regionid = kmalloc(16, GFP_KERNEL);
if (!regionid)
- return;
+ return NULL;
snprintf(regionid, 16, pnp %s, pnpid);
if (port)
res = request_region(start, end - start + 1, regionid);
else
res = request_mem_region(start, end - start + 1, regionid);
- if (res)
- res-flags = ~IORESOURCE_BUSY;
- else
+ if (!res)
kfree(regionid);
/*
@@ -52,12 +50,17 @@ static void reserve_range(struct pnp_dev
port ? ioport : iomem,
(unsigned long long) start, (unsigned long long) end,
res ? has been : could not be);
+ return res;
}
static void reserve_resources_of_dev(struct pnp_dev *dev)
{
int i;
+ struct resource **res;
+ res = kzalloc(sizeof(struct resource *) * PNP_MAX_PORT,
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Sunday December 9 2007 09:31:27 pm Shaohua Li wrote:
On Sun, 2007-12-09 at 23:04 +0100, Adrian Bunk wrote:
On Sun, Dec 09, 2007 at 04:12:25PM -0500, Elvis Pranskevichus wrote:
Jean Delvare wrote:
Hi Mike,
On Sat, 8 Dec 2007 21:22:34 -0500, Mike Houston wrote:
On Sun, 9 Dec 2007 01:05:54 +0100
Adrian Bunk [EMAIL PROTECTED] wrote:
On Tue, Dec 04, 2007 at 09:51:54PM -0500, Mike Houston wrote:
I finally got around to testing Linux 2.6.24 (2.6.24-rc4) and
found that the it87 driver fails to probe and consequently, my
sensors no longer work. This was fine with Linux 2.6.23.8 (the
last kernel I was using)
The necessary modules load, but:
it87: Found IT8718F chip at 0x290, revision 2
it87: in3 is VCC (+5V)
it87 it87.656: Failed to request region 0x290-0x297
it87: probe of it87.656 failed with error -16
Coretemp still works.
It appears it has something to do with the ioport range being
reserved for some reason:
system 00:01: ioport range 0x290-0x29f has been reserved
Thanks for your report.
Please also provide:
- dmesg from 2.6.23.8
- The output of cat /proc/ioports for both kernels
Thanks Adrian, here is the information you have requested, for
both kernels (I have 2.6.23.9 now though where it87 still works)
Linux 2.6.23.9:
http://www.mikeserv.com/temp/proc_ioports-2.6.23.9.txt
http://www.mikeserv.com/temp/dmesg-2.6.23.9.txt
http://www.mikeserv.com/temp/config-2.6.23.9.txt
Linux 2.6.24-rc4:
http://www.mikeserv.com/temp/proc_ioports-2.6.24-rc4.txt
http://www.mikeserv.com/temp/dmesg-2.6.24-rc4.txt
This one shows:
system 00:01: ioport range 0x290-0x29f has been reserved
(...)
system 00:01: ioport range 0x290-0x294 has been reserved
This is clearly not correct as both areas overlap. The second
reservation is responsible for the it87 breakage, because it
conflicts with what the it87 driver later attempts to request
(0x290-0x297). The first is wrong as well (the IT87xxF environment
controller I/O area is 8 port wide, not 16) but shouldn't be a
problem in practice.
These port reservations weren't happening in 2.6.23.9 according to
your dmesg output for that kernel. I don't know what changed in this
area since 2.6.23.9, maybe Bjorn or Adam (Cc'd) can tell.
Hi,
I have exactly the same problem here on a Gigabyte GA-965G-DS3
motherboard based box:
it87: Found IT8718F chip at 0x290, revision 1
it87: in3 is VCC (+5V)
it87 it87.656: Failed to request region 0x290-0x297
it87: probe of it87.656 failed with error -16
git bisecting revealed the offending commit:
a7839e960675b54: PNP: increase the maximum number of resources
Happened between rc3 and rc4.
Thanks for doing the work of bisecting!
Either way, the overlapping areas smell like a BIOS bug, meaning that
you should look for an updated BIOS for your system first.
http://www.mikeserv.com/temp/config-2.6.24-rc4.txt
This indeed looks like a broken ACPI BIOS since the aforementioned
commit touches only the PNP ACPI driver. I'm not sure how to work
around this, though. Ideas?
People responsible for this commit + ACPI maintainer added to Cc.
This should exist in previous kernel (before we remove acpi motherboard
driver) too. Basically it's a broken BIOS. Could below patch work around
it?
Thanks,
Shaohua
Index: linux/drivers/pnp/system.c
===
--- linux.orig/drivers/pnp/system.c 2007-12-10 10:17:46.0 +0800
+++ linux/drivers/pnp/system.c2007-12-10 10:24:42.0 +0800
@@ -22,7 +22,7 @@ static const struct pnp_device_id pnp_de
{, 0}
};
-static void reserve_range(struct pnp_dev *dev, resource_size_t start,
+static struct resource* reserve_range(struct pnp_dev *dev, resource_size_t
start, resource_size_t end, int port)
{
char *regionid;
@@ -31,16 +31,14 @@ static void reserve_range(struct pnp_dev
regionid = kmalloc(16, GFP_KERNEL);
if (!regionid)
- return;
+ return NULL;
snprintf(regionid, 16, pnp %s, pnpid);
if (port)
res = request_region(start, end - start + 1, regionid);
else
res = request_mem_region(start, end - start + 1, regionid);
- if (res)
- res-flags = ~IORESOURCE_BUSY;
- else
+ if (!res)
kfree(regionid);
/*
@@ -52,12 +50,17 @@ static void reserve_range(struct pnp_dev
port ? ioport : iomem,
(unsigned long long) start, (unsigned long long) end,
res ? has been : could not be);
+ return res;
}
static void reserve_resources_of_dev(struct pnp_dev *dev)
{
int i;
+ struct resource
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Mon, 10 Dec 2007 10:31:27 +0800 Shaohua Li [EMAIL PROTECTED] wrote: This should exist in previous kernel (before we remove acpi motherboard driver) too. Basically it's a broken BIOS. Could below patch work around it? Thanks, Shaohua Index: linux/drivers/pnp/system.c === --- linux.orig/drivers/pnp/system.c 2007-12-10 10:17:46.0 +0800 +++ linux/drivers/pnp/system.c Thanks Shaohua, I tested this as well and it appears to have worked around the issue for me. Now, in dmesg, I get: system 00:01: ioport range 0x290-0x29f has been reserved (...) system 00:01: ioport range 0x290-0x294 could not be reserved In /proc/ioports I see: 0290-029f : pnp 00:01 0290-0297 : it87 0290-0297 : it87 The it87 sensor now works without disabling acpipnp Mike Houston -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
