There seems to be an issue with the VESA driver for my laptop's video
card. I can install any version of the kernel (tested with
2.4.{23,24}, 2.4.31, and various 2.6.XX > 2.6.8) and the system turns
on and boots fine. However, if I go into suspend to ram (which I
think is ACPI S3) where the display is turned off -or- I reboot
without shutting down first, the display is not re-initialized.
The system seems to come back on into a semi-usable state (i.e. if I
reboot the kernel seems to boot and the system comes up), but the
display remains solid black, so I have not been able to verify this.
Come to think of it, I could probably connect the laptop up to my home
network and SSH into it after this happens, but I haven't yet done so.
My laptop is a Toshiba Satellite 1800 S207 with a Trident XPAi1 video
card. If I use the tridentfb driver (at least as of kernel 2.4) at
boot time, the screen turns various shades of gold immediately after
the kernel loads. Can someone help me debug this issue so that a fix
can be written? The problem happens even with a pristine installation
of Slackware 10.2 with the default bare 2.4.31 kernel.
TIA
Mike
This isn't just a problem with ACPI's suspend. If I reboot the
machine, without without power management, the screen isn't properly
reinitialized. The problem with the suspend is certainly an issue
with ACPI; however, the reboot issue probably isn't. Unless someone
can enlighten me?
On 9/16/05, Michal Jaegermann <[email protected]> wrote:
> On Fri, Sep 16, 2005 at 11:57:16AM -0700, Mike Mohr wrote:
> > However, if I go into suspend to ram (which I
> > think is ACPI S3) where the display is turned off -or- I reboot
> > without shutting down first, the display is not re-initialized.
>
> Did you try with 'acpi_sleep=s3_bios' kernel parameter as documentation
> suggests? I have the same problem with video on Acer Travelmate and
> this helps. Remember that with ACPI (or APM) you are to a great extent
> at a mercy of your BIOS supplier and that part is often seriously buggy.
> APM is simpler so it often used to be in a better shape.
>
> Michal
>
Hi!
> This isn't just a problem with ACPI's suspend. If I reboot the
> machine, without without power management, the screen isn't properly
> reinitialized. The problem with the suspend is certainly an issue
> with ACPI; however, the reboot issue probably isn't. Unless someone
> can enlighten me?
Well, the reboot issue is broken BIOS... It should reset the hardware
when you are rebooting.
Read Doc*/power/video.txt for suspend issues.
Pavel
--
if you have sharp zaurus hardware you don't need... you know my address
Hmm. It seems unlikely to me that Toshiba will bother fixing a bug
like this (even as serious as this one is) for a 3-yr-old laptop on my
request. I checked, and I already have the latest BIOS released by
them on 9-24-2002. The fact that they let a bug as serious as this
through their QA really shocks me, esp. since my wife works for
Panasonic QA and I know the procedures they go through. I will never
buy from Toshiba again.
Thanks for the responses guys!
Mike
On 9/19/05, Pavel Machek <[email protected]> wrote:
> Hi!
>
> > This isn't just a problem with ACPI's suspend. If I reboot the
> > machine, without without power management, the screen isn't properly
> > reinitialized. The problem with the suspend is certainly an issue
> > with ACPI; however, the reboot issue probably isn't. Unless someone
> > can enlighten me?
>
> Well, the reboot issue is broken BIOS... It should reset the hardware
> when you are rebooting.
>
> Read Doc*/power/video.txt for suspend issues.
> Pavel
> --
> if you have sharp zaurus hardware you don't need... you know my address
>
Hi!
> Hmm. It seems unlikely to me that Toshiba will bother fixing a bug
> like this (even as serious as this one is) for a 3-yr-old laptop on my
> request. I checked, and I already have the latest BIOS released by
> them on 9-24-2002. The fact that they let a bug as serious as this
> through their QA really shocks me, esp. since my wife works for
> Panasonic QA and I know the procedures they go through. I will never
> buy from Toshiba again.
Okay, sorry, it is not EC; I was replying to wrong mail. Chance of linux workaround
still exists.
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
Hi!
Don't top-post.
> Hmm. It seems unlikely to me that Toshiba will bother fixing a bug
> like this (even as serious as this one is) for a 3-yr-old laptop on my
> request. I checked, and I already have the latest BIOS released by
> them on 9-24-2002. The fact that they let a bug as serious as this
> through their QA really shocks me, esp. since my wife works for
Actually I'm not surprised. Embedded controller locked up because
Linux did something unexpected. That's still hardware problem, but quite tricky
to catch.
You can still try to find "what us it that upsets EC", and work around it
in Linux. printk/mdelay is your friend.
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms