I am out of ideas and a bit desperate really. The laptop is a Toshiba Satellite L300 with an Insyde H20 Bios. Until I updated the Bios from 1.60 to 1.80, I had no problems. Now, to even get X going, I needed kernel 2.6.30.x. Symptoms: --------- 1) Non-random crashes: when the screen saver is on, X does come back but keyboard and mouse immediately freeze. Not using the intel driver from X and instead using the generic vesa does not change a thing. 2) Random crashes: when this happens, the last key that was pressed gets stuck. If I am lucky and have an editor or office open, I see the last pressed key printed endlessly. After the key got stuck the mouse still moves for a while without click function. Still a little while later the mouse freezes and the hole system stops responding. I have turned debugging output in the kernel for ACPI and USB, but I cannot see anything suspicious in the log after reboot. Nothing suspicious. There is, however, this: ACPI: EC: GPE storm detected, transactions will use polling mode ACPI: EC: missing confirmations, switch off interrupt mode but since I have the very same on my other laptop which runs rock solidly, I do not think that the ACPI messages cause the trouble on the L300.
Not an IA64 bug :) I'll reassign this to acpi, thanks.
Thanks.
Because I get the ACPI warnings on my other Laptop which does not freeze. shoud we not discout the ACPI here? If we do this would the freezes not be an IA64 issue?
IA64 is Intel Itanium. You don't have it in your notebook, this is what Andrew tried to say :) Could you please try to uncomment "#define DEBUG" in drivers/acpi/ec.c and attach dmesg here? if it does not contain beginning of boot, please attach /var/log/messages instead (the one _containing_ "storm detected" message).
Created attachment 22603 [details] dmesg with define DEBUG on
Please see dmesg as requested. Except for the first two lines after reboot, all other lines are there.
Do we need CONFIG_ACPI_DEBUG=y as well? I have turned it off again since I first reported the bug.
nothing here suggests to me that this hang is ACPI related, but please attach the output from acpidump for reference. after your BIOS update did you go into SETUP and select the defaults?
Created attachment 22707 [details] dmesg_ACPI_DEBUG_ON After the update I did chnge the BIOS values to default and booted into Linux. Same freezes. The I went back into the BIOS and turned on what I wanted, again, same freezes.
Created attachment 22708 [details] acpidump
does the problem still exists if using boot option "idle=poll"?
Currently traveling, will try when I am back next week.
I have tried boot option 'idle=poll' and the freezes still occur. I have contacted Toshiba. Because they insist this is a hardware fault I will ask them to collect the laptop for repair.
Hi, Thoralf Will you please confirm whether it still freeze under console mode? Will you please add the boot option of "nolapic_timer" and see whether it still freezes? Thanks.
Will do before I phone Toshiba.
nolapic_timer didn't help. Now I am testing without X. This is going take some time because I gave the laptop something to do in console mode and will leave it for a few days. I left the laptop in console mode over night with nothing to do and this morning it was still responding normally.
1) Testing without X for 3 days continuous did not freeze the computer. 2) I updated to Slackware 13.0, which, according to its official announcement, comes with an updated xorg. After 2 days, the Laptop has not frozen. Should we close the bug?
I don't know. As the freeze happens only when X is started, re-assign this to video category
Thanks. Update: is is 3 days now that the laptop has not frozen while running X. This looks as though the xorg update that came with the latest release of my Distro has done the trick.
or you can close this bug and open a bug at https://bugs.freedesktop.org/. :)
closing. If you see new issues, please file new bugs according to http://www.intellinuxgraphics.org/how_to_report_bug.html.
Update: Toshiba have released another BIOS update. Now the video driver works again as it did before the previous BIOS update.