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