Hi Robert,
On Wed, 19 Dec 2007 19:09:54 -0600, Robert Hancock wrote:
> 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
>
Hi Bjorn,
Sorry for the late answer.
On Wed, 2 Jan 2008 11:30:55 -0700, Bjorn Helgaas wrote:
> Even if the BIOS does not declare an IT87xxF as an independent device,
> there may be AML that uses the chip internally. For example, the
> BIOS could declare a thermal zone with a _TMP method, and
Hi Bjorn,
Sorry for the late answer.
On Wed, 2 Jan 2008 11:30:55 -0700, Bjorn Helgaas wrote:
Even if the BIOS does not declare an IT87xxF as an independent device,
there may be AML that uses the chip internally. For example, the
BIOS could declare a thermal zone with a _TMP method, and the
Hi Robert,
On Wed, 19 Dec 2007 19:09:54 -0600, Robert Hancock wrote:
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
On Tuesday 25 December 2007 02:31:26 pm Jean Delvare wrote:
> Le 23/12/2007, "Bjorn Helgaas" <[EMAIL PROTECTED]> a écrit:
> >On Sunday 23 December 2007 2:28:05 am Jean Delvare wrote:
> >> The problem is that the it87 driver is used on a variety of motherboards,
> >> some where the hardware
On Tuesday 25 December 2007 02:31:26 pm Jean Delvare wrote:
Le 23/12/2007, Bjorn Helgaas [EMAIL PROTECTED] a écrit:
On Sunday 23 December 2007 2:28:05 am Jean Delvare wrote:
The problem is that the it87 driver is used on a variety of motherboards,
some where the hardware monitoring device
Hi Bjorn,
Le 23/12/2007, "Bjorn Helgaas" <[EMAIL PROTECTED]> a écrit:
>On Sunday 23 December 2007 2:28:05 am Jean Delvare wrote:
>> 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
Hi Bjorn,
Le 23/12/2007, Bjorn Helgaas [EMAIL PROTECTED] a écrit:
On Sunday 23 December 2007 2:28:05 am Jean Delvare wrote:
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
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
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
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,
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
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),
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,
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
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
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
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
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
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
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
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
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
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
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
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?
>
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?
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
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
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
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.
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
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
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
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.
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
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?
> >
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,
Hi Ed,
On Sun, 09 Dec 2007 20:32:41 -0500, Ed Sweetman wrote:
> 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
Hi Ed,
On Sun, 09 Dec 2007 20:32:41 -0500, Ed Sweetman wrote:
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
For
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
>
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, 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
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
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,
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
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
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
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
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
>
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
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
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
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
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
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
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
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.
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
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]
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
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
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.
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
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
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
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
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
68 matches
Mail list logo
