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

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: [email protected]

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

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.

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

Thus wrote Len Brown:

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
[email protected]

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: [email protected]

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

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

-- eric

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

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

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: [email protected]

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: [email protected]

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

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
[email protected]

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

Thus wrote Eric Valette:

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
[email protected]

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