2.6.8-rc4-mm1 : radeon_monitor.c broken vs CONFIG_FB_MODE_HELPERS + Hard freeze

2.6.8-rc4-mm1 : radeon_monitor.c broken vs CONFIG_FB_MODE_HELPERS + Hard freeze

[Eric Valette]

I tried 2.6.8-rc4-mm1 on my ASUS L3800C laptop (radeon 7500), defined 
CONFIG_FB_MODE_HELPERS and I have got a hard freeze when starting X and 
framebuffer console with a lot of yellow dot on the bottom screen. 
Suddently I hear the fan meaning the machine is dead

Trying to compile without CONFIG_FB_MODE_HELPERS set do not work because
drivers/video/aty/radeon_monitor.c unconditionnaly uses "vesa_modes" 
variable that depends on CONFIG_FB_MODE_HELPERS.

Defining vesa_modes unconditionnaly as it was previously does not help : 
machine freeze. Trying the pci=routeirq (as per 2.6.8-rc3-mm2)  make the 
machine to freeze immediately without even displaying something.

Due to compilation errors in 2.6.8-rc3-mm2, I did'nt tried it. 
2.6.8-rc3-mm1 was the best kernel even on this machine.

-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette@free.fr

2.6.8-rc4-mm1 : Hard freeze due to ACPI

[Eric Valette]

Eric Valette wrote:
> I tried 2.6.8-rc4-mm1 on my ASUS L3800C laptop (radeon 7500), defined 
> CONFIG_FB_MODE_HELPERS and I have got a hard freeze when starting X and 
> framebuffer console with a lot of yellow dot on the bottom screen. 
> Suddently I hear the fan meaning the machine is dead

OK I've reverted the most suspect change 
(remove-unconditional-pci-acpi-irq-routing.patch) and it did not fix the 
problem. As Karol Kozimor suspected ACPI, I then tried with acpi=off and 
then it boot but I will burn my CPU as fans are ACPI controlled...

So it is probably due to the bk-acpi.patch and more precisely the 
difference between what was in 2.6.8-rc3-mm1 and 2.6.8-rc4-mm1.

Len, any proposal as candidate patches to revert?

-- eric

Re: 2.6.8-rc4-mm1 : Hard freeze due to ACPI

[Len Brown]

On Tue, 2004-08-10 at 06:35, Eric Valette wrote:
> Eric Valette wrote:
> > I tried 2.6.8-rc4-mm1 on my ASUS L3800C laptop (radeon 7500),
> defined > CONFIG_FB_MODE_HELPERS and I have got a hard freeze when
> starting X and 
> > framebuffer console with a lot of yellow dot on the bottom screen. 
> > Suddently I hear the fan meaning the machine is dead
> 
> OK I've reverted the most suspect change 
> (remove-unconditional-pci-acpi-irq-routing.patch) and it did not fix
> the 
> problem. As Karol Kozimor suspected ACPI, I then tried with acpi=off
> and then it boot but I will burn my CPU as fans are ACPI controlled...
> 
> So it is probably due to the bk-acpi.patch and more precisely the 
> difference between what was in 2.6.8-rc3-mm1 and 2.6.8-rc4-mm1.
> 
> Len, any proposal as candidate patches to revert?

bk-acpi.patch is unchanged between 2.6.8-rc3-mm1 to 2.6.8-rc3-mm2
So it would be interesting if you ran 2.6.8-rc3-mm2 to see if
something else broke your system at that point, or if the breakage
happened later.

>From 2.6.8-rc3-mm2 to 2.6.8-rc4-mm1 there are only two additional
patches in bk-acpi.patch.  I don't expect them to have any effect on
your system, they are these two:

asus_acpi.c from Karol
http://linux-acpi.bkbits.net:8080/linux-acpi-test-2.6.7/gnupatch@4117a219yRjkVomavWT8WoMdRg7KHA

pci_link.c - resume fix from Nathan
http://linux-acpi.bkbits.net:8080/linux-acpi-test-2.6.7/gnupatch@41114fe37ez5dnzmR96KT2DHr4-elA

I'll poke around the mm patch to see if anything else looks suspicious.

cheers,
-Len

Re: 2.6.8-rc4-mm1 : Hard freeze due to ACPI

[Karol Kozimor]

Thus wrote Len Brown:
> I'll poke around the mm patch to see if anything else looks suspicious.

I remember my problem (with 2.6.8-rc3-mm1, I suppose) was a sort of an ACPI
mutex deadlock (or at least that's what the call trace suggested), I'm
sorry I didn't have time to post a proper report, I'm a bit busy right
these days.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: 2.6.8-rc4-mm1 : Hard freeze due to ACPI

[Andrew Morton]

Eric Valette <eric.valette@free.fr> wrote:
>
> Eric Valette wrote:
>  > I tried 2.6.8-rc4-mm1 on my ASUS L3800C laptop (radeon 7500), defined 
>  > CONFIG_FB_MODE_HELPERS and I have got a hard freeze when starting X and 
>  > framebuffer console with a lot of yellow dot on the bottom screen. 
>  > Suddently I hear the fan meaning the machine is dead
> 
>  OK I've reverted the most suspect change 
>  (remove-unconditional-pci-acpi-irq-routing.patch) and it did not fix the 
>  problem. As Karol Kozimor suspected ACPI, I then tried with acpi=off and 
>  then it boot but I will burn my CPU as fans are ACPI controlled...

Are you sure that the problem is due to ACPI?  I'd have been suspecting the
video mode database rewrite (video-mode-handling-*.patch).

Re: 2.6.8-rc4-mm1 : Hard freeze due to ACPI

[Eric Valette]

Len Brown wrote:

> asus_acpi.c from Karol
> http://linux-acpi.bkbits.net:8080/linux-acpi-test-2.6.7/gnupatch@4117a219yRjkVomavWT8WoMdRg7KHA
> 
> pci_link.c - resume fix from Nathan
> http://linux-acpi.bkbits.net:8080/linux-acpi-test-2.6.7/gnupatch@41114fe37ez5dnzmR96KT2DHr4-elA
> 
> I'll poke around the mm patch to see if anything else looks suspicious.

Thanks for answering Len. Due to the usual delay, I had the time to 
revert the paches myself before your answer and found that as expected 
the problem still persist (I browsed the patch quickly directly from 
bitkkeper acpi tree and found a priori nothing suspicious).

Curious that :
	- acpi=off boot option makes the problem vanish,
	- it looks like a deadlock due to an asynchronous event as it does not 
always occur at the same time after the boot finishes,
	- even without typing anything on the keyboard in single mode it deadlocks,
	- I never saw the fan suddenly wake-up (except of couse when 
temeratuire is too high) without a hard immediate reboot on this laptop. 
Here, during video (framebuffer) initialization, while the screen it 
still black they start spinning,

Will try andrew suggestion for the video-mode-handling-* patch

-- eric

Re: 2.6.8-rc4-mm1 : Hard freeze due to ACPI

[Eric Valette]

Eric Valette wrote:

> Will try andrew suggestion for the video-mode-handling-* patch

Tried without success. Will wait until other find other symptoms for the 
same problem.

-- eric

Re: 2.6.8-rc4-mm1 : Hard freeze due to ACPI

[Len Brown]

On Tue, 2004-08-10 at 15:53, Eric Valette wrote:
> Eric Valette wrote:
> 
> > Will try andrew suggestion for the video-mode-handling-* patch
> 
> Tried without success. Will wait until other find other symptoms for
> the 
> same problem.
> 

I suppose with the patches available  broken out, you can apply them
in groups and divide & conquor.

I'd be interested to know if the latest bk-acpi.patch is related to
the issue...

thanks,
-Len

Re: 2.6.8-rc4-mm1 : Hard freeze due to ACPI

[Eric Valette]

Len Brown wrote:


> I suppose with the patches available  broken out, you can apply them
> in groups and divide & conquor.

I already spend half the day on this (and the other half installing XP 
SP2 and fixing various issue after sucessfull installation :-))

> I'd be interested to know if the latest bk-acpi.patch is related to
> the issue...

Well, either the bk-acpi.patch for 2.6.8-rc4-mm1 is broken (I mean does 
not contain the right set of fixes) or, as you suggested (and I reached 
the same conclusion while browsing the acpi bitkeeper tree), I reverted 
all the ACPI related patches (bk + another one) to have something that 
should be _exactly_ equivalent to 2.6.8-rc3-mm1.

I've have seen someone on the ACPI mailing list complaining that its 
thermal zone disappear with 2.6.8-rc4-mm1. Maybe some ACPI related table 
get corrupted by someone else...

Last symtom I've found : I also have strange ide error message 
(something like wait for controller to be ready...),

-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette@free.fr

Re: 2.6.8-rc4-mm1 : Hard freeze due to ACPI

[Karol Kozimor]

Thus wrote Eric Valette:
> >I tried 2.6.8-rc4-mm1 on my ASUS L3800C laptop (radeon 7500), defined 
> >CONFIG_FB_MODE_HELPERS and I have got a hard freeze when starting X and 
> >framebuffer console with a lot of yellow dot on the bottom screen. 
> >Suddently I hear the fan meaning the machine is dead
> 
> OK I've reverted the most suspect change 
> (remove-unconditional-pci-acpi-irq-routing.patch) and it did not fix the 
> problem. As Karol Kozimor suspected ACPI, I then tried with acpi=off and 
> then it boot but I will burn my CPU as fans are ACPI controlled...

Here's more about my problem: it seems 2.6.8-rc3-mm1 sometimes manages to
boot here. Even so, kacpid completely hogs the CPU. dmesg and debug output
is at http://hell.org.pl/~sziwan/2.6.8-rc3-mm1.report (300 kB), DSDT is at
http://hell.org.pl/~sziwan/l3800c.dsl. Note the odd thermal zone output
(did somebody mention TZ problems?). Call trace below.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Pid: 5, comm:               kacpid
EIP: 0060:[<c01e65c7>] CPU: 0
EIP is at acpi_os_get_thread_id+0x1f/0x2b
 EFLAGS: 00000246    Not tainted  (2.6.8-rc3-mm1)
EAX: 00000000 EBX: 00000000 ECX: c1272030 EDX: 00000000
ESI: c136bf28 EDI: cfeec028 EBP: 00000048 DS: 007b ES: 007b
CR0: 8005003b CR2: b7bd4000 CR3: 0fdce000 CR4: 00000690
 [<c020a7c9>] acpi_ut_acquire_mutex+0x34/0x159
 [<c02088a8>] acpi_ut_release_to_cache+0x44/0x94
 [<c020ad54>] acpi_ut_delete_generic_state+0x37/0x49
 [<c020c1ea>] acpi_ut_update_object_reference+0x9e/0x27f
 [<c020c4a8>] acpi_ut_remove_reference+0x81/0x99
 [<c01e8eca>] acpi_ds_get_predicate_value+0x196/0x1bd
 [<c01e94a1>] acpi_ds_exec_end_op+0x3e7/0x426
 [<c02011e5>] acpi_ps_parse_loop+0x6be/0x9ef
 [<c02015d8>] acpi_ps_parse_aml+0xc2/0x26e
 [<c0202229>] acpi_psx_execute+0x1d9/0x274
 [<c01fd981>] acpi_ns_execute_control_method+0xe2/0x100
 [<c01fd870>] acpi_ns_evaluate_by_handle+0xd7/0x106
 [<c01fd618>] acpi_ns_evaluate_relative+0x158/0x1b2
 [<c01fcae7>] acpi_evaluate_object+0x16a/0x263
 [<c01e6a82>] acpi_evaluate_integer+0x89/0x19c
 [<c01ed5ce>] acpi_ev_sci_xrupt_handler+0x4e/0x57
 [<c02094ad>] acpi_ut_status_exit+0x3e/0x4a
 [<c02094ad>] acpi_ut_status_exit+0x3e/0x4a
 [<c02093af>] acpi_ut_trace+0x28/0x2e
 [<c02179de>] acpi_thermal_get_temperature+0x62/0x9e
 [<c02185f2>] acpi_thermal_check+0x6e/0x2c6
 [<c020e2ac>] acpi_bus_get_device+0x9c/0xa7
 [<c02193c2>] acpi_thermal_notify+0x88/0xf6
 [<c01ee20d>] acpi_ev_notify_dispatch+0x57/0x60
 [<c01e5ee5>] acpi_os_execute_deferred+0x59/0x72
 [<c01226ed>] worker_thread+0x1ad/0x273
 [<c0112036>] activate_task+0x5c/0x6f
 [<c01e5e8c>] acpi_os_execute_deferred+0x0/0x72
 [<c01128dc>] default_wake_function+0x0/0xc
 [<c011291b>] __wake_up_common+0x33/0x56
 [<c01128dc>] default_wake_function+0x0/0xc
 [<c0122540>] worker_thread+0x0/0x273
 [<c0125c40>] kthread+0x90/0x95
 [<c0125bb0>] kthread+0x0/0x95
 [<c0102249>] kernel_thread_helper+0x5/0xb

Re: 2.6.8-rc4-mm1 : Hard freeze due to ACPI

[Eric Valette]

Karol Kozimor wrote:

> Here's more about my problem: it seems 2.6.8-rc3-mm1 sometimes manages to
> boot here. Even so, kacpid completely hogs the CPU. dmesg and debug output
> is at http://hell.org.pl/~sziwan/2.6.8-rc3-mm1.report (300 kB), DSDT is at
> http://hell.org.pl/~sziwan/l3800c.dsl. Note the odd thermal zone output
> (did somebody mention TZ problems?). Call trace below.
> Best regards,

I've seen this problem long before 2.6.8-rc3-mm1 on LKML (e.g. 
http://www.ussg.iu.edu/hypermail/linux/kernel/0406.2/0040.html) and on 
different laptop (Dell). So may be, there is a deadlock window somephere 
that just open ups or close depending on :
	- Compiler,
	- Unrelated patches,
	- ...

I guess, hunting will be fun... I would start by the thermal problem as 
it seems to be hit also by a few people... I whish I could have kdb 
integrated to see what happens but on mm tree applying it is too painfull...

-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette@free.fr

Re: 2.6.8-rc4-mm1 : Hard freeze due to ACPI

[Eric Valette]

Len Brown wrote:

> I'd be interested to know if the latest bk-acpi.patch is related to
> the issue...

I finaly found the time to test it : result is that 2.6.8-rc4 + 
bk-acpi.patch boots fine. The thermal problem is also gone. SO something 
must corrupt the data used by thermal.c in 2.6.8-rc4-mm1 :-(  Did not 
managed to wake up from S3 once. Will retry to be sure...

I think a minimal check on THRM value should be performed (-129°C) is 
crazy as 150 probably...

-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette@free.fr

Re: 2.6.8.1-mm1 and Asus L3C : problematic change found, can be reverted. Real fix still missing

[Karol Kozimor]

Okay, so I think I've finally got what's happening here.
Enabling the SMBus device (00:1f.3) seems to mess up the resource
reservation code, specifically the 0xe800 port region. Here's the diff
between 2.6.8.1-mm1 acpi=off and the same kernel with no arguments:

#v+
 0cf8-0cff : PCI conf1
+1000-101f : 0000:00:1f.3
 4000-40ff : PCI CardBus #03
[...]
 e300-e37f : 0000:00:1f.6
-e400-e47f : pnp 00:11
-  e400-e47f : 0000:00:1f.0
-e800-e81f : 0000:00:1f.3
-ec00-ec3f : pnp 00:11
-  ec00-ec3f : 0000:00:1f.0
+e400-e47f : 0000:00:1f.0
+  e400-e47f : motherboard
+    e400-e403 : PM1a_EVT_BLK
+    e404-e405 : PM1a_CNT_BLK
+    e408-e40b : PM_TMR
+    e410-e415 : ACPI CPU throttle
+    e428-e42b : GPE0_BLK
+    e42c-e42f : GPE1_BLK
+e800-e81f : motherboard
+ec00-ec3f : 0000:00:1f.0
+  ec00-ec3f : motherboard
+    ec00-ec3f : pnp 00:11
 00000000-0009fbff : System RAM
#v-

Note that since ACPI reserves the 0xe800-0xe81f region, the SMBus gets
assigned a bogus port range. The next relevant piece of code is from the
DSDT:

#v+
Device (SBIO)
{
    Name (_HID, EisaId ("PNP0C02"))
    Name (_UID, 0x04)
    Method (_CRS, 0, NotSerialized)
    {
        Name (BUF1, ResourceTemplate ()
        {
            IO (Decode16, 0xE400, 0xE400, 0x01, 0x80)
=>          IO (Decode16, 0xE800, 0xE800, 0x01, 0x20)  <=
            IO (Decode16, 0xEC00, 0xEC00, 0x01, 0x40)
            IO (Decode16, 0x040B, 0x040B, 0x01, 0x01)
            IO (Decode16, 0x0480, 0x0480, 0x01, 0x10)
            IO (Decode16, 0x04D6, 0x04D6, 0x01, 0x01)
        })
        Return (BUF1)
    }
}
[...]
OperationRegion (SMB0, SystemIO, 0xE800, 0x10)
Field (SMB0, ByteAcc, NoLock, Preserve)
{
=>  HSTS,   8,  <=
    SSTS,   8,
    HSTC,   8,
    HCMD,   8,
[...]
}
#v-

And that leads us to the root of the problem: _TMP calls RTMP, which calls
RBYT and finally HBSY. The latter attempts to access HSTS and subsequently
fails (hence _TMP returns 0x7f and kacpid loops).

Now, I see two possibilities: either the resource allocation code is buggy
and should be fixed (hopefully by someone with better understanding than
me) or the code relies on the necessary information that is not exported by
the BIOS / DSDT (which wouldn't be strange assuming the system is supposed
to run with SMBus disabled), and in that case the SMBus fixup should be
reverted. 

A similar patch went in for ASUS M2400N, so I guess those systems could
also be affected.

Dmesg, ioports and iomem of plain 2.6.8.1-mm1 with and without acpi-off as
well as dmesg found at http://hell.org.pl/~sziwan/asus/l3c/ (note the extra
IRQ 0 and 0xe400 problem when ACPI is on).

Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: 2.6.8.1-mm1 and Asus L3C : problematic change found, can be reverted. Real fix still missing

[Eric Valette]

Karol Kozimor wrote:
> Okay, so I think I've finally got what's happening here.
> Enabling the SMBus device (00:1f.3) seems to mess up the resource
> reservation code, specifically the 0xe800 port region. Here's the diff
> between 2.6.8.1-mm1 acpi=off and the same kernel with no arguments:

Hi Karol,

This is the same problem on every asus motherboard including very old 
ones like my A7V : the ACPI pre-allocates the ioport region for the SMB 
bus because the DTSD contain indication to do so and special care should 
be used in order to reuse the IO port range already owned by ACPI 
(motherboard).

See :
<http://lkml.org/lkml/2004/8/3/160>

And especially the end of /proc/oprots current one (before ACPI fix, I 
was forced to avoid/not fail ioport reservation for SMB in i2c-viapro.c)

e800-e80f : 0000:00:04.4	<===============
    e800-e80f : motherboard

But with the shaohua li proposed fix for 
<http://bugme.osdl.org/show_bug.cgi?id=3049>, i2c-viapro.c becomes owner 
of part of this ioport range:

e800-e80f : 0000:00:04.4
   e800-e80f : motherboard
     e800-e807 : viapro-smbus    <========

So in other words, it is possible either to force reallocation of an 
ioport range already owned by ACPI now (at least in some configuration) 
or to avoid this io port allocation has it is already mapped like my 
proposed kludge to make A7V work...

However :
	1) I have no clue however of the correct way to do this,
	2) I do not know if the fix for 
<http://bugme.osdl.org/show_bug.cgi?id=3049> is also valid for this ASUS 
motherboard/laptop,
	3) I still would like to know what you want to do with the SMB bus...

-- eric

RE: 2.6.8.1-mm1 and Asus L3C : problematic change found, can be reverted. Real fix still missing

[Li, Shaohua]

Eric,
The patch for bug 3049 has been in 2.6.8.1 and should fix the IO port
problem. If the Asus quirk is just because of IO port problem, I'd like
to remove it. Note PNP driver also reserves the IO port for the SMBus
and lets SMBus driver to use it. ACPI motherboard driver behaves the
same as PNP driver.

Thanks,
Shaohua
>-----Original Message-----
>From: Eric Valette [mailto:eric.valette@free.fr]
>Sent: Thursday, August 19, 2004 3:17 PM
>To: Karol Kozimor
>Cc: Brown, Len; Wang, Zhenyu Z; Andrew Morton; Greg KH; linux@brodo.de;
>linux-kernel@vger.kernel.org; Li, Shaohua
>Subject: Re: 2.6.8.1-mm1 and Asus L3C : problematic change found, can
be
>reverted. Real fix still missing
>
>Karol Kozimor wrote:
>> Okay, so I think I've finally got what's happening here.
>> Enabling the SMBus device (00:1f.3) seems to mess up the resource
>> reservation code, specifically the 0xe800 port region. Here's the
diff
>> between 2.6.8.1-mm1 acpi=off and the same kernel with no arguments:
>
>Hi Karol,
>
>This is the same problem on every asus motherboard including very old
>ones like my A7V : the ACPI pre-allocates the ioport region for the SMB
>bus because the DTSD contain indication to do so and special care
should
>be used in order to reuse the IO port range already owned by ACPI
>(motherboard).
>
>See :
><http://lkml.org/lkml/2004/8/3/160>
>
>And especially the end of /proc/oprots current one (before ACPI fix, I
>was forced to avoid/not fail ioport reservation for SMB in
i2c-viapro.c)
>
>e800-e80f : 0000:00:04.4	<===============
>    e800-e80f : motherboard
>
>But with the shaohua li proposed fix for
><http://bugme.osdl.org/show_bug.cgi?id=3049>, i2c-viapro.c becomes
owner
>of part of this ioport range:
>
>e800-e80f : 0000:00:04.4
>   e800-e80f : motherboard
>     e800-e807 : viapro-smbus    <========
>
>So in other words, it is possible either to force reallocation of an
>ioport range already owned by ACPI now (at least in some configuration)
>or to avoid this io port allocation has it is already mapped like my
>proposed kludge to make A7V work...
>
>However :
>	1) I have no clue however of the correct way to do this,
>	2) I do not know if the fix for
><http://bugme.osdl.org/show_bug.cgi?id=3049> is also valid for this
ASUS
>motherboard/laptop,
>	3) I still would like to know what you want to do with the SMB
bus...
>
>-- eric
>
>
>

Re: 2.6.8.1-mm1 and Asus L3C : problematic change found, can be reverted. Real fix still missing

[Eric Valette]

Li, Shaohua wrote:
> Eric,
> The patch for bug 3049 has been in 2.6.8.1 and should fix the IO port
> problem. If the Asus quirk is just because of IO port problem, I'd like
> to remove it. Note PNP driver also reserves the IO port for the SMBus
> and lets SMBus driver to use it. ACPI motherboard driver behaves the
> same as PNP driver.

Unfortunately, as I understand it, the fix is done to "unhide" the SMBus 
that otherwyse is not seen but it has unexpected side effect of messing 
ioports allocation/reservation. I guess lspci with and without the fix 
could help to understand the problem. Here is the comment on top of the 
function :

/*
  * On ASUS P4B boards, the SMBus PCI Device within the ICH2/4 southbridge
  * is not activated. The myth is that Asus said that they do not want the
  * users to be irritated by just another PCI Device in the Win98 device
  * manager. (see the file prog/hotplug/README.p4b in the lm_sensors
  * package 2.7.0 for details)
  *
  * The SMBus PCI Device can be activated by setting a bit in the ICH LPC
  * bridge. Unfortunately, this device has no subvendor/subdevice ID. So it
  * becomes necessary to do this tweak in two steps -- I've chosen the Host
  * bridge as trigger.
  */

BTW, maybe we should change the comment because it is on many ASUS 
boards if not all ...

-- eric

Re: 2.6.8.1-mm1 and Asus L3C : problematic change found, can be reverted. Real fix still missing

[Eric Valette]

Eric Valette wrote:
> Li, Shaohua wrote:
> 
>> Eric,
>> The patch for bug 3049 has been in 2.6.8.1 and should fix the IO port
>> problem. If the Asus quirk is just because of IO port problem, I'd like
>> to remove it. Note PNP driver also reserves the IO port for the SMBus
>> and lets SMBus driver to use it. ACPI motherboard driver behaves the
>> same as PNP driver.
> 
> 
> Unfortunately, as I understand it, the fix is done to "unhide" the SMBus 
> that otherwyse is not seen but it has unexpected side effect of messing 
> ioports allocation/reservation. I guess lspci with and without the fix 
> could help to understand the problem. Here is the comment on top of the 
> function :

OK I've put my debugger hat and tried to go a little further. Here is an 
(I hope) interesting PCI tweaking session. For helping the readder here 
are the meaning of some value :
	1) 8086:248c : Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02)
	2) 8086:2483 : the PCI ID for the i801 SMB bus
	3) 0xF2 the register offset used to enable the SBus in the ISA Bridge
	4) 0x20 = SMBBA = SMBbus base address in the i2c-i801.c file


root@pink-floyd:/home/valette# setpci -H1 -v -d 8086:248c 0xF2.W 
00:1f.0:f2 = 8409
root@pink-floyd:/home/valette# pcitweak -l  > 
pci_devices_list_without_enabling_SMBus 2>&1
root@pink-floyd:/home/valette# setpci -H1 -v -d 8086:248c 0xF2.W=8401 
00:1f.0:f2 8401
root@pink-floyd:/home/valette# pcitweak -l  > 
pci_devices_list_after_enabling_SMBus 2>&1
root@pink-floyd:/home/valette# diff 
pci_devices_list_without_enabling_SMBus 
pci_devices_list_after_enabling_SMBus
10a11
 > PCI: 00:1f:3: chip 8086,2483 card 1043,1628 rev 02 class 0c,05,00 hdr 00
root@pink-floyd:/home/valette# setpci -H1 -v -d 8086:2483 20.w
00:1f.3:20 = e801

So my deduction are :
	1) The trick for enabling the SMBbus is working,
	2) The configured base IO range register value is e801 leading to 
theoritically request the e800 -> e808 IO region and curiously not e810 
as requested described by the DTST...

Now I do not understand why it get something else as io port region no 
that the ACPI fix for bug 3049 remove the IORESOURCE_BUSY flags


-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette@free.fr

Re: 2.6.8.1-mm1 and Asus L3C : problematic change found, can be reverted. Real fix still missing

[Dominik Brodowski]

On Thu, Aug 19, 2004 at 10:05:45AM +0200, Eric Valette wrote:
> Li, Shaohua wrote:
> >Eric,
> >The patch for bug 3049 has been in 2.6.8.1 and should fix the IO port
> >problem. If the Asus quirk is just because of IO port problem, I'd like
> >to remove it.
It's not because of the IO port problem -- actually, this "IO" problem is a
new appearance, while the Asus quirk works perfectly for many people.

> > Note PNP driver also reserves the IO port for the SMBus
> >and lets SMBus driver to use it. ACPI motherboard driver behaves the
> >same as PNP driver.
> 
> Unfortunately, as I understand it, the fix is done to "unhide" the SMBus 
> that otherwyse is not seen but it has unexpected side effect of messing 
> ioports allocation/reservation. I guess lspci with and without the fix 
> could help to understand the problem.

Indeed. lspci without the fix doesn't show the device, lspci with the fix
shows the device.

	Dominik

Re: 2.6.8.1-mm1 and Asus L3C : problematic change found, can be reverted. Real fix still missing

[Eric Valette]

Dominik Brodowski wrote:
> On Thu, Aug 19, 2004 at 10:05:45AM +0200, Eric Valette wrote:
> 
>>Li, Shaohua wrote:
>>
>>>Eric,
>>>The patch for bug 3049 has been in 2.6.8.1 and should fix the IO port
>>>problem. If the Asus quirk is just because of IO port problem, I'd like
>>>to remove it.
> 
> It's not because of the IO port problem -- actually, this "IO" problem is a
> new appearance, while the Asus quirk works perfectly for many people.
> 
> 
>>>Note PNP driver also reserves the IO port for the SMBus
>>>and lets SMBus driver to use it. ACPI motherboard driver behaves the
>>>same as PNP driver.
>>
>>Unfortunately, as I understand it, the fix is done to "unhide" the SMBus 
>>that otherwyse is not seen but it has unexpected side effect of messing 
>>ioports allocation/reservation. I guess lspci with and without the fix 
>>could help to understand the problem.
> 
> 
> Indeed. lspci without the fix doesn't show the device, lspci with the fix
> shows the device.
> 
> 	Dominik

Dominik,

This is a little bit late. There are already two fixes for the SMBus 
unhidding : one generic by linux, that is in 2.6.9-rc1-bk2 or 
2.6.9-rc1-mm1 that fixes the SMBus but that is not really SMBus related 
and one specific that you can find at 
<http://bugme.osdl.org/show_bug.cgi?id=3191>. Linux blessed this patch 
as it makes clear that unhiding the bus without reserving the IO space 
is the root of the real problem but did not incorporate it probably 
because the other fix is already in and mine should be done for buggy 
BIOS (DTST) that access the hidden SMBus not indirect the IO BAR but via 
  hardwired values,

Patch is not yet merged and may well never be as now problem is masked,


-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette@free.fr