Re: [2/6] 2.6.21-rc2: known regressions

[Ingo Molnar]

* Pavel Machek <pavel@xxxxxxx> wrote:

> > Even if one doesn't use the fb console at all, radeonfb apparently 
> > is still required on some ThinkPad models to work around BIOS bugs:
> > 
> > http://www.thinkwiki.org/wiki/Problem_with_high_power_drain_in_ACPI_sleep#Radeon_GPU_not_powered_off
> 
> 
> s2ram should be able to work around this, it has parts from 
> radeontool. (suspend.sf.net).

i'm wondering, do you have any idea how Windows handles the 
suspend/resume quirks problem area? Do they "curse BIOS vendors and 
maintain a large DB of DMI-driven exceptions", or do they perhaps have 
some fundamentally better approach than us? If it's the former, then we 
might as well try to bring more automatism (and more of your database) 
into the kernel itself.

btw., the s2ram database seems quite a bit spotty:

 $ ./s2ram -n
 Machine is unknown.
 This machine can be identified by:
     sys_vendor   = "System manufacturer"
     sys_product  = "System Product Name"
     sys_version  = "System Version"
     bios_version = "ASUS A8N-E ACPI BIOS Revision 1008"

 $ ./s2ram -n
 Machine is unknown.
 This machine can be identified by:
    sys_vendor   = "Hewlett-Packard "
    sys_product  = "compaq nx9030 (PG630ET#ABD)       "
    sys_version  = "Rev 1           "
    bios_version = "F.15    "
 See http://en.opensuse.org/S2ram for details.

even at the link above i didnt find any clear algorithm about how to 
extend the quirks-list and the white-list - while i expect that most 
people experience what i did: that s2ram doesnt know their boxes. 
(otherwise they would not visit that URL at all i suspect)

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/