[Regression] toshiba_acpi crashes system since upgrade to 2.6.17-8-generic

oops, launchpad didnt die on me. one of the attachments is uploaded twice now.

Strange. The log file states that the xorg.conf was not found and therefore loaded config-defaults (vesafb-driver which never would be able to enable dri)... How did you change dri-settings? Via dpkg-reconfigure or manually? Does this still happen with 2.6.17-10-generic?

I dont remember touching dpkg-reconfigure recently, not sure if i have on this partition at all.

The uncommenting of the dri line was done manually, using vi.

Yes, this still happens with the latest 2.6.17-10-generic kernel.

Right.

I used sudo dpkg-reconfigure xserver-xorg, making sure that dri is enabled (leaving it at the defaults)

I went back to -10-generic, and got the latest log. This one appears to be reading the xorg.conf. Still the same problem though - startx and kdm show a blank screen where X crashes, then i cant get back to a terminal.

Interestingly, kdm still breaks on startup in recovery mode (same kernel), but startx (and sudo /etc/init.d/kdm restart) will work. And no, it's not my profile.

-7-generic and before work fine, which is what i'm using before this gets solved.

I'm not sure what you do mean by kdm-startup in recovery mode. Recovery-mode for me does mean sulogin, and this causes that not everything gets loaded to enable sane kdm-login.

Does kernel-2.6.17-7-generic still boot into sane state?

Do you have vesafb (or another fb) for console enabled? If so, try to boot without it and tell me what is happening.

ie, i can run "/etc/init.d/kdm restart, and login to kde that way. or just run startx.

2.6.17-7-generic boots fine, in all configurations, it seems.

I'm not sure - how do i test this?

"Recovery mode" boots without framebuffer by default, so if there it works on newer kernels, it may be (but not necessaryly is) a fb-issue.

Do a `grep "Kernel command line" /var/log/syslog`. When e.g. vesafb is enabled, something like vga=792 or vga=0x318 should appear.

Alternatively you can check /boot/grub/menu.lst for this setting. To en-/disable options for one boot, after reboot press key 'e' (edit) in grub-menu on highlighted Menu-entry you want to boot, then select "kernel" line and press key 'e' again. Do - if present of course - delelete vga=xxx entry (and only this!), leave editor pressing 'esc' and boot modified entry by pressing key 'b'. If unsure, consult the man pages.

on the -7-generic

sarah@LongPointyStickOfDoom:~$ grep "Kernel command line" /var/log/syslog
sarah@LongPointyStickOfDoom:~$

sarah@LongPointyStickOfDoom:~$ cat /boot/grub/menu.lst | grep vga
## e.g. defoptions=vga=791 resume=/dev/hda5
sarah@LongPointyStickOfDoom:~$

attaching grub menu.lst anyway.

on the -10-generic.

grep "Kernel command line" /var/log/syslog:

Sep 28 15:31:26 LongPointyStickOfDoom kernel: [17179569.184000] Kernel command line: root=UUID=a6fde999-3a70-40b3-bae9-87ea37069b92 ro quiet
Sep 28 15:32:51 LongPointyStickOfDoom kernel: [17179569.184000] Kernel command line: root=UUID=a6fde999-3a70-40b3-bae9-87ea37069b92 ro
Sep 28 15:37:32 LongPointyStickOfDoom kernel: [17179569.184000] Kernel command line: root=UUID=a6fde999-3a70-40b3-bae9-87ea37069b92 ro quiet splash

Booting without the splash, or without quiet splash, both make X still crash.

Ok, it is not the vesafb. It seems strange to me that this happens since update to 2.6.17-8, because changes to agp/drm-portions of kernel-code are documented for 2.6.17-9. Even with broken kernel-drm-code, X normally should start up disabeling dri-part automatically.

What completely seems strange to me is, that you say that a forced startx or sudo /etc/init.d/kdm restart works in some situations. How does the Xorg.0.log-file look like when you issue startx as mentioned earlier?

The attached file from Comment #8 shows, that X obiously hangs while trying to allocate graphics-memory (at least the log ends there, no further comments in log after that, what seems strange to me, too). Does the whole system crash in this situation? What says the syslog file? Can you still boot in a sane state when dri is disabled?

I've tried a current (2006-09-28, kernel 2.6.17-10-generic) edgy-desktop-cd. Everything works fine on my hpnx6110 with i810 driver (I'm still using live-system on that machine, commenting this bug-report ;-)). Boots clean into graphical mode, glxinfo shows dri enabled, nothing breaks. Maybe there is a config-issue responsible for the breakage? Working xorg.conf attached

Without information from your syslog I can't tell more at the moment.

Maybe you should try out a current live-cd, too. If there everything works, you should find out which program or configuration causes your broken X. You can fetch a current one from cdimage.ubuntu.com, located in the daily-live section (either torrent or iso download).

sorry...i've had a whole lot of work stuff come up...

I'll have more of a look on the weekend, and grab the latest files.

I thought i'd managed to get the startx and sudo /etc/init.d/kdm restart commands to work in recovery mode - but i'll go and double check that in a couple of days.

Does the whole system crash in this situation? What says the syslog file? Can you still boot in a sane state when dri is disabled?

Well, i cant get back to a virtual terminal, so i cant exactly tell if the system has crashed or not.

Even with dri disabled, i still get X dead.

Going back to try to reproduce, i cant seem to get *any* setting using the -10-generic kernel to get a working X, in normal mode.

In single user (aka. recovery) mode, i can /etc/init.d/kdm start, or run startx without a problem, and get a GUI.

Attaching various working and not working syslog files and xorg configs

I dont have a recent daily cd - only a knot 2, i believe.

Download limits make me not want to download it again.

It's a cdr, and i dont have the original .iso anymore, so i cant use rsync

You forgot to attach the syslog when starting X fails. Therefore you attached the Xorg.log twice. The working syslog you attached is not complete, unfortunately you took a file that were created after restarting syslogd. But the working one is not that important, the not working one is needed to say where the error may occur. Xorg.log still shows the same output like before, therefore another Xorg.log at the moment is not needed.

Argh....

Sorry for the idiocy.

Correct syslog (non-working) file attached.

I've discovered that the machine still responds - the hard drive light still flashes, and the machine obeys the power button, and shuts the machine down normally. (ie, not pressing and holding the power button). It's just the graphics that seem to die.

and it didnt attach...

trying to attach proper syslog

According to the syslog, your problem is similar to Bug #61981 and Bug #62932, both reporting Kernel Oops when trying to load "Toshiba Laptop ACPI Extras", especially the hotkey part of it. Seems to be specific to toshiba laptops, that's why I can't reproduce it. In Bug #61981 the reporter states, that disabling the option "hotkeys_over_acpi" in /etc/modprobe.d/toshiba_acpi.modprobe is a temporary workaround. Hope this could help you,

Regards,

Gert

Rejecting assignment to xserver-xorg-video-i810, because it's a kernel issue.

Setting state Unconfirmed --> Confirmed

Changed bug title

Wow!

You're absolutely correct. It boots fine now to -10-generic.

Added some more bugs that seem to be dupes.

I'm glad that I could help you :-)

Regards,

Gert

patch in https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/61981

BenC will fix it.

it's working from my side, thanks for the fix!

works here now, confirmed by multiple people.

Thanks!

Bug re-appears in Feisty.

For Feisty this bug is already reported as bug #77026. Sorry for the mess :(