Hi:
I have a DELL XPS 15z laptop with the latest BIOS (A12).
This piece of crap have never worked properly without special boot
parameters. Up to kernel 3.10, passing acpi_backlight=vendor was enough
to allow the machine to complete boot and be usable.
Now with 3.11 rc2 (also with today's linus tree) unbootable machine
problem is back.
In the past I spent many hours figuring out workarounds and they go
_now_ as the following.
Booting with:
"nox2apic" --> machine works, flawless.
"x2apic_phys acpi_backlight=vendor" --> machine works, except for the
big problem that the laptop keyboard and touchpad are unresponsive, I
have to plug USB keyboard/mouse to get anything done.
With no boot parameters the machine hangs at random points in the boot
sequence either:
-Very early at boot and there is no way to retrieve any useful debug
info. [OR]
- Somehow it looses "connection" with the ATA controller and the
filesystems cannot be mounted. [OR]
- In very few ocassions, the boot proceeds with no keyboard or touchpad
then the iwlwifi wireless card does something stupid (firmware error...)
The only possible hint in the logs I could ever find is:
[ 3.844586] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS
I tried in the past to obtain any debug information, with no luck.
Help is appreciated to get to the bottom of the problem. ;)
On 07/28/2013 01:19 AM, Cristian Rodríguez wrote:
> Hi:
>
> I have a DELL XPS 15z laptop with the latest BIOS (A12).
>
> This piece of crap have never worked properly without special boot
> parameters. Up to kernel 3.10, passing acpi_backlight=vendor was enough
> to allow the machine to complete boot and be usable.
>
> Now with 3.11 rc2 (also with today's linus tree) unbootable machine
> problem is back.
>
> In the past I spent many hours figuring out workarounds and they go
> _now_ as the following.
>
> Booting with:
>
> "nox2apic" --> machine works, flawless.
I've seen bug report with similar symptom:
https://bugzilla.kernel.org/show_bug.cgi?id=56051
It is possible the BIOS is not x2apic aware while Linux enabled x2apic,
then some ACPI control method to do things like change backlight
brightness level triggered SMI handler and freeze would occur. This
might be the reason why adding acpi_backlight=vendor fixed your problem,
since it would block ACPI video module's handling of backlight.
So does adding nox2apic still work for you with latest Linus' tree?
>
> "x2apic_phys acpi_backlight=vendor" --> machine works, except for the
> big problem that the laptop keyboard and touchpad are unresponsive, I
> have to plug USB keyboard/mouse to get anything done.
>
> With no boot parameters the machine hangs at random points in the boot
> sequence either:
>
> -Very early at boot and there is no way to retrieve any useful debug
> info. [OR]
Maybe this is when video.ko is loaded.
>
> - Somehow it looses "connection" with the ATA controller and the
> filesystems cannot be mounted. [OR]
>
> - In very few ocassions, the boot proceeds with no keyboard or touchpad
> then the iwlwifi wireless card does something stupid (firmware error...)
All sounds like related to irq problem.
>
> The only possible hint in the logs I could ever find is:
>
> [ 3.844586] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS
This is subtle, meaning the BIOS doesn't provide the required method.
-Aaron
>
>
> I tried in the past to obtain any debug information, with no luck.
>
> Help is appreciated to get to the bottom of the problem. ;)
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
El 28/07/13 21:05, Aaron Lu escribió:
> So does adding nox2apic still work for you with latest Linus' tree?
Yes, nox2apic makes things work again, but has always puzzled me why
acpi_backlight=vendor made it work previously with no apparent bad side
effect..
>> The only possible hint in the logs I could ever find is:
>>
>> [ 3.844586] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS
>
> This is subtle, meaning the BIOS doesn't provide the required method.
Yeah, I wonder what Windows 7/8 is doing..does not seem to care about that..