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

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

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

[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.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