Hi all.
Linus' GIT tree 2.6.26-05752-g93ded9b shows this message:
i801_smbus 0000:00:1f.3: PCI INT B -> GSI 19 (level, low) -> IRQ 19
ACPI: I/O resource 0000:00:1f.3 [0x18e0-0x18ff] conflicts with ACPI
region SMBI [0x18e0-0x18ef]
ACPI: Device needs an ACPI driver
There is no equivalent in 2.6.26 or previous kernels.
Please find the output of lspci in the body of the email and .config
attached. Please let me know if you need more details.
Regards,
Fabio
-------------------
00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML
Express Processor to DRAM Controller (rev 04)
00:01.0 PCI bridge: Intel Corporation Mobile 915GM/PM Express PCI
Express Root Port (rev 04)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) PCI Express Port 1 (rev 04)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #1 (rev 04)
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #2 (rev 04)
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #3 (rev 04)
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #4 (rev 04)
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB2 EHCI Controller (rev 04)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d4)
00:1e.2 Multimedia audio controller: Intel Corporation
82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 04)
00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
AC'97 Modem Controller (rev 04)
00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface
Bridge (rev 04)
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) IDE Controller (rev 04)
00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
SMBus Controller (rev 04)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon
Mobility X700 (PCIE)
06:05.0 Network controller: Intel Corporation PRO/Wireless 2200BG
Network Connection (rev 05)
06:06.0 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller
06:06.2 FireWire (IEEE 1394): Texas Instruments OHCI Compliant IEEE
1394 Host Controller
06:06.3 Mass storage controller: Texas Instruments PCIxx21 Integrated
FlashMedia Controller
06:06.4 SD Host controller: Texas Instruments
PCI6411/6421/6611/6621/7411/7421/7611/7621 Secure Digital Controller
06:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
On 22-07-08 20:56, Fabio Comolli wrote:
> Linus' GIT tree 2.6.26-05752-g93ded9b shows this message:
>
> i801_smbus 0000:00:1f.3: PCI INT B -> GSI 19 (level, low) -> IRQ 19
> ACPI: I/O resource 0000:00:1f.3 [0x18e0-0x18ff] conflicts with ACPI
> region SMBI [0x18e0-0x18ef]
> ACPI: Device needs an ACPI driver
>
> There is no equivalent in 2.6.26 or previous kernels.
[ snip ]
> 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
I believe this message in itself needn't be a problem but the code
producing this warning isn't new...
Bjorn, this reminds me of the:
pnp-have-quirk_system_pci_resources-include-io-resources.patch
in Andrew's tree that I need to have my soundcard not fail due to the IO
resource being claimed by PNPACPI. The fact that I needed it was new to
2.6.26 (but going back to 2.6.25 I all of a sudden also needed it there
which made me conclude that some BIOS reconfig had occured).
ACPI isn't doing odd things I hope?
Rene.
On 22-07-08 22:00, Rene Herman wrote:
>> Linus' GIT tree 2.6.26-05752-g93ded9b shows this message:
There doesn't seem to be a g93ded9b in Linus' tree as of now. What tree
are you on and does it perhaps already include the below patch?
This one:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.26-rc8/2.6.26-rc8-mm1/broken-out/pnp-have-quirk_system_pci_resources-include-io-resources.patch
>> i801_smbus 0000:00:1f.3: PCI INT B -> GSI 19 (level, low) -> IRQ 19
>> ACPI: I/O resource 0000:00:1f.3 [0x18e0-0x18ff] conflicts with ACPI
>> region SMBI [0x18e0-0x18ef]
>> ACPI: Device needs an ACPI driver
>>
>> There is no equivalent in 2.6.26 or previous kernels.
>
> [ snip ]
>
>> 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
>
> I believe this message in itself needn't be a problem but the code
> producing this warning isn't new...
>
> Bjorn, this reminds me of the:
>
> pnp-have-quirk_system_pci_resources-include-io-resources.patch
>
> in Andrew's tree that I need to have my soundcard not fail due to the IO
> resource being claimed by PNPACPI. The fact that I needed it was new to
> 2.6.26 (but going back to 2.6.25 I all of a sudden also needed it there
> which made me conclude that some BIOS reconfig had occured).
>
> ACPI isn't doing odd things I hope?
Rene.
hi Rene.
On Tue, Jul 22, 2008 at 10:14 PM, Rene Herman <[email protected]> wrote:
> On 22-07-08 22:00, Rene Herman wrote:
>
>>> Linus' GIT tree 2.6.26-05752-g93ded9b shows this message:
>
> There doesn't seem to be a g93ded9b in Linus' tree as of now. What tree are
> you on and does it perhaps already include the below patch?
>
Well, this is strange because it should be a clone of Linus' tree. I
will re-clone it tonight.
> This one:
>
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.26-rc8/2.6.26-rc8-mm1/broken-out/pnp-have-quirk_system_pci_resources-include-io-resources.patch
>
I did not add it manually for sure. By the way, I don't see any ACPI
related problems with this kernel.
Regards,
Fabio
>>> i801_smbus 0000:00:1f.3: PCI INT B -> GSI 19 (level, low) -> IRQ 19
>>> ACPI: I/O resource 0000:00:1f.3 [0x18e0-0x18ff] conflicts with ACPI
>>> region SMBI [0x18e0-0x18ef]
>>> ACPI: Device needs an ACPI driver
>>>
>>> There is no equivalent in 2.6.26 or previous kernels.
>>
>> [ snip ]
>>
>>> 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
>>
>> I believe this message in itself needn't be a problem but the code
>> producing this warning isn't new...
>>
>> Bjorn, this reminds me of the:
>>
>> pnp-have-quirk_system_pci_resources-include-io-resources.patch
>>
>> in Andrew's tree that I need to have my soundcard not fail due to the IO
>> resource being claimed by PNPACPI. The fact that I needed it was new to
>> 2.6.26 (but going back to 2.6.25 I all of a sudden also needed it there
>> which made me conclude that some BIOS reconfig had occured).
>>
>> ACPI isn't doing odd things I hope?
>
> Rene.
>
On 23-07-08 09:17, Fabio Comolli wrote:
>> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.26-rc8/2.6.26-rc8-mm1/broken-out/pnp-have-quirk_system_pci_resources-include-io-resources.patch
>
> I did not add it manually for sure. By the way, I don't see any ACPI
> related problems with this kernel.
You can just look at drivers/pnp/quirks.c:quirk_system_pci_resources()
and see if it's still IORESOURCE_MEM only (current linus) or includes
IORESOURCE_IO resources as per that patch.
Had a momentary notion that if we specifically exclude ACPI in favour of
PCI as that patch does this could _cause_ the message -- before, the PCI
smbus driver just would've failed but perhaps you don't even have such a
driver or something.
Probably way of base. Just had a deja vu to my own soundcard trouble.
Rene
Hi Rene.
I can only confirm that Linus' tree 2.6.26-06077-gc010b2f
(commit c010b2f... Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6)
shows the message.
Grepping the file you suggested gives:
fcomolli@hawking:~/software/GIT-TREES/linux-2.6/drivers/pnp> egrep
'RESOURCE_IO|RESOURCE_MEM' quirks.c
option->type == IORESOURCE_IO) {
if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM) ||
(res = pnp_get_resource(dev, IORESOURCE_MEM, j));
fcomolli@hawking:~/software/GIT-TREES/linux-2.6/drivers/pnp>
so both IORESOURCE_IO and IORESOURCE_MEM are present in the file...
But definitely this is Linus' tree.
Cheers,
Fabio
On Wed, Jul 23, 2008 at 10:01 AM, Rene Herman <[email protected]> wrote:
> On 23-07-08 09:17, Fabio Comolli wrote:
>
>>>
>>> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.26-rc8/2.6.26-rc8-mm1/broken-out/pnp-have-quirk_system_pci_resources-include-io-resources.patch
>>
>> I did not add it manually for sure. By the way, I don't see any ACPI
>> related problems with this kernel.
>
> You can just look at drivers/pnp/quirks.c:quirk_system_pci_resources() and
> see if it's still IORESOURCE_MEM only (current linus) or includes
> IORESOURCE_IO resources as per that patch.
>
> Had a momentary notion that if we specifically exclude ACPI in favour of PCI
> as that patch does this could _cause_ the message -- before, the PCI smbus
> driver just would've failed but perhaps you don't even have such a driver or
> something.
>
> Probably way of base. Just had a deja vu to my own soundcard trouble.
>
> Rene
>
On 23-07-08 20:11, Fabio Comolli wrote:
> But definitely this is Linus' tree.
I failed to delete the "g" prefix I see. In any case, fine, this is not
helping then. Butting out...
Rene.
On Tuesday 22 July 2008 12:56:36 pm Fabio Comolli wrote:
> Linus' GIT tree 2.6.26-05752-g93ded9b shows this message:
>
> i801_smbus 0000:00:1f.3: PCI INT B -> GSI 19 (level, low) -> IRQ 19
> ACPI: I/O resource 0000:00:1f.3 [0x18e0-0x18ff] conflicts with ACPI
> region SMBI [0x18e0-0x18ef]
> ACPI: Device needs an ACPI driver
>
> There is no equivalent in 2.6.26 or previous kernels.
The "ACPI: I/O resource ... conflicts with ..." message was added by
Thomas:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=df92e695998e1bc6e426a840eb86d6d1ee87e2a5
That conflict checking infrastructure was in 2.6.26, but Jean's
change to make the i801_smbus driver use it didn't happen until
about a week ago:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=54fb4a05af0a4b814e6716cfdf3fa97fc6be7a32
The message is telling us that the i801_smbus driver thinks it owns
the 0x18e0-0x18ff region, but there's also an ACPI opregion that
references that region. There's no coordination between ACPI and
the i801_smbus driver, so there may be issues where nearly
simultaneous accesses cause incorrect behavior, e.g,. one may
read the wrong value from a temperature sensor. That, of course,
can lead to more serious things like unintended machine shutdowns.
I don't have any ideas about how to address this. I think Thomas's
intent was to collect better information for unreproducible bugs.
(Maybe this sort of conflict should even set a taint flag?)
Bjorn
Hi.
On Wed, Jul 23, 2008 at 8:56 PM, Bjorn Helgaas <[email protected]> wrote:
> On Tuesday 22 July 2008 12:56:36 pm Fabio Comolli wrote:
>> Linus' GIT tree 2.6.26-05752-g93ded9b shows this message:
>>
>> i801_smbus 0000:00:1f.3: PCI INT B -> GSI 19 (level, low) -> IRQ 19
>> ACPI: I/O resource 0000:00:1f.3 [0x18e0-0x18ff] conflicts with ACPI
>> region SMBI [0x18e0-0x18ef]
>> ACPI: Device needs an ACPI driver
>>
>> There is no equivalent in 2.6.26 or previous kernels.
>
> The "ACPI: I/O resource ... conflicts with ..." message was added by
> Thomas:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=df92e695998e1bc6e426a840eb86d6d1ee87e2a5
>
> That conflict checking infrastructure was in 2.6.26, but Jean's
> change to make the i801_smbus driver use it didn't happen until
> about a week ago:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=54fb4a05af0a4b814e6716cfdf3fa97fc6be7a32
>
> The message is telling us that the i801_smbus driver thinks it owns
> the 0x18e0-0x18ff region, but there's also an ACPI opregion that
> references that region. There's no coordination between ACPI and
> the i801_smbus driver, so there may be issues where nearly
> simultaneous accesses cause incorrect behavior, e.g,. one may
> read the wrong value from a temperature sensor. That, of course,
> can lead to more serious things like unintended machine shutdowns.
>
> I don't have any ideas about how to address this. I think Thomas's
> intent was to collect better information for unreproducible bugs.
> (Maybe this sort of conflict should even set a taint flag?)
>
OK, I actually didn't even know what i801_smbus (i2c_801 I suppose)
was. It seems that my laptop has a super-IO chip which is detected by
lm-sensors as `Nat. Semi. PC87591 Super IO' which doesn't have a
driver and never will.
So, if I'm correct, this modules is totally useless for me and I
better compile it out. Am I correct?
> Bjorn
>
>
Regards,
Fabio
Hi Fabio,
On Wed, 23 Jul 2008 21:50:24 +0200, Fabio Comolli wrote:
> Hi.
>
> On Wed, Jul 23, 2008 at 8:56 PM, Bjorn Helgaas <[email protected]> wrote:
> > On Tuesday 22 July 2008 12:56:36 pm Fabio Comolli wrote:
> >> Linus' GIT tree 2.6.26-05752-g93ded9b shows this message:
> >>
> >> i801_smbus 0000:00:1f.3: PCI INT B -> GSI 19 (level, low) -> IRQ 19
> >> ACPI: I/O resource 0000:00:1f.3 [0x18e0-0x18ff] conflicts with ACPI
> >> region SMBI [0x18e0-0x18ef]
> >> ACPI: Device needs an ACPI driver
> >>
> >> There is no equivalent in 2.6.26 or previous kernels.
> >
> > The "ACPI: I/O resource ... conflicts with ..." message was added by
> > Thomas:
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=df92e695998e1bc6e426a840eb86d6d1ee87e2a5
> >
> > That conflict checking infrastructure was in 2.6.26, but Jean's
> > change to make the i801_smbus driver use it didn't happen until
> > about a week ago:
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=54fb4a05af0a4b814e6716cfdf3fa97fc6be7a32
> >
> > The message is telling us that the i801_smbus driver thinks it owns
> > the 0x18e0-0x18ff region, but there's also an ACPI opregion that
> > references that region. There's no coordination between ACPI and
> > the i801_smbus driver, so there may be issues where nearly
> > simultaneous accesses cause incorrect behavior, e.g,. one may
> > read the wrong value from a temperature sensor. That, of course,
> > can lead to more serious things like unintended machine shutdowns.
> >
> > I don't have any ideas about how to address this. I think Thomas's
> > intent was to collect better information for unreproducible bugs.
> > (Maybe this sort of conflict should even set a taint flag?)
Yes, at this point these messages are informative only and displayed as
a hint when investigating bug reports. In the long run, we might
decide to grant exclusive access to the shared region to either ACPI or
the native driver, or to setup a safe concurrent access mechanism.
That's a long way to go though, due to the diversity of BIOSes out
there and the fact that many of them declare opregions in bogus ways.
> OK, I actually didn't even know what i801_smbus (i2c_801 I suppose)
> was. It seems that my laptop has a super-IO chip which is detected by
> lm-sensors as `Nat. Semi. PC87591 Super IO' which doesn't have a
> driver and never will.
>
> So, if I'm correct, this modules is totally useless for me and I
> better compile it out. Am I correct?
Yes you are. If you don't need i2c-i801 on this machine, best is to not
build it or to prevent it from loading. Or you can boot with
acpi_enforce_resources=strict to prevent the i2c-i801 driver from
attaching to the device.
I am a bit curious though, why ACPI would declare an opregion for a
device that isn't used. Might be yet another case of BIOS copied from
another machine and not cleaned up appropriately.
--
Jean Delvare
Hi Jean.
On Sat, Aug 9, 2008 at 6:13 PM, Jean Delvare <[email protected]> wrote:
> Hi Fabio,
>
> On Wed, 23 Jul 2008 21:50:24 +0200, Fabio Comolli wrote:
>> Hi.
>>
>> On Wed, Jul 23, 2008 at 8:56 PM, Bjorn Helgaas <[email protected]> wrote:
>> > On Tuesday 22 July 2008 12:56:36 pm Fabio Comolli wrote:
>> >> Linus' GIT tree 2.6.26-05752-g93ded9b shows this message:
>> >>
>> >> i801_smbus 0000:00:1f.3: PCI INT B -> GSI 19 (level, low) -> IRQ 19
>> >> ACPI: I/O resource 0000:00:1f.3 [0x18e0-0x18ff] conflicts with ACPI
>> >> region SMBI [0x18e0-0x18ef]
>> >> ACPI: Device needs an ACPI driver
>> >>
>> >> There is no equivalent in 2.6.26 or previous kernels.
>> >
>> > The "ACPI: I/O resource ... conflicts with ..." message was added by
>> > Thomas:
>> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=df92e695998e1bc6e426a840eb86d6d1ee87e2a5
>> >
>> > That conflict checking infrastructure was in 2.6.26, but Jean's
>> > change to make the i801_smbus driver use it didn't happen until
>> > about a week ago:
>> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=54fb4a05af0a4b814e6716cfdf3fa97fc6be7a32
>> >
>> > The message is telling us that the i801_smbus driver thinks it owns
>> > the 0x18e0-0x18ff region, but there's also an ACPI opregion that
>> > references that region. There's no coordination between ACPI and
>> > the i801_smbus driver, so there may be issues where nearly
>> > simultaneous accesses cause incorrect behavior, e.g,. one may
>> > read the wrong value from a temperature sensor. That, of course,
>> > can lead to more serious things like unintended machine shutdowns.
>> >
>> > I don't have any ideas about how to address this. I think Thomas's
>> > intent was to collect better information for unreproducible bugs.
>> > (Maybe this sort of conflict should even set a taint flag?)
>
> Yes, at this point these messages are informative only and displayed as
> a hint when investigating bug reports. In the long run, we might
> decide to grant exclusive access to the shared region to either ACPI or
> the native driver, or to setup a safe concurrent access mechanism.
> That's a long way to go though, due to the diversity of BIOSes out
> there and the fact that many of them declare opregions in bogus ways.
>
>> OK, I actually didn't even know what i801_smbus (i2c_801 I suppose)
>> was. It seems that my laptop has a super-IO chip which is detected by
>> lm-sensors as `Nat. Semi. PC87591 Super IO' which doesn't have a
>> driver and never will.
>>
>> So, if I'm correct, this modules is totally useless for me and I
>> better compile it out. Am I correct?
>
> Yes you are. If you don't need i2c-i801 on this machine, best is to not
> build it or to prevent it from loading. Or you can boot with
> acpi_enforce_resources=strict to prevent the i2c-i801 driver from
> attaching to the device.
>
Ok, thanks for confirming it.
> I am a bit curious though, why ACPI would declare an opregion for a
> device that isn't used. Might be yet another case of BIOS copied from
> another machine and not cleaned up appropriately.
>
Well, you should ask HP for that :-)
Anyway, as usual linux is not supported at all on this laptop, it came
with XP. One thing that puzzles me is why bothering adding a
monitoring chip for which drivers do not exist for any OS?
> --
> Jean Delvare
>
Regards,
Fabio
On Sat, 9 Aug 2008 18:32:31 +0200, Fabio Comolli wrote:
> Anyway, as usual linux is not supported at all on this laptop, it came
> with XP. One thing that puzzles me is why bothering adding a
> monitoring chip for which drivers do not exist for any OS?
If you refer to the PC87591: that's a Super-I/O chip, including many
different functions. Hardware monitoring is only one of these
functions. Manufacturers might be interested in some of the other
features and chose this chip because of them. Windows doesn't support
hardware monitoring at all without 3rd party tools anyway, so that's
hardly a decision factor for vendors.
Additionally, on laptops, thermal management is most often done by ACPI
rather than native OS drivers. Maybe the ACPI implementation in your
laptop actually gets the temperature from the PC87591.
--
Jean Delvare
Hi.
On Sat, Aug 9, 2008 at 7:03 PM, Jean Delvare <[email protected]> wrote:
> On Sat, 9 Aug 2008 18:32:31 +0200, Fabio Comolli wrote:
>> Anyway, as usual linux is not supported at all on this laptop, it came
>> with XP. One thing that puzzles me is why bothering adding a
>> monitoring chip for which drivers do not exist for any OS?
>
> If you refer to the PC87591: that's a Super-I/O chip, including many
> different functions. Hardware monitoring is only one of these
> functions. Manufacturers might be interested in some of the other
> features and chose this chip because of them. Windows doesn't support
> hardware monitoring at all without 3rd party tools anyway, so that's
> hardly a decision factor for vendors.
>
> Additionally, on laptops, thermal management is most often done by ACPI
> rather than native OS drivers. Maybe the ACPI implementation in your
> laptop actually gets the temperature from the PC87591.
>
Oh, I see. Thanks for the explanation.
> --
> Jean Delvare
Regards,
Fabio
>