Created attachment 439158 [details] Call trace for kernel panic Description of problem: FC13 (kernel 2.6.33.6-147.2.4.fc13.x86_64) on a Toshiba Satellite A505D will not boot using default boot parameters due to an issue with ACPI. The laptop will boot normally when "acpi=off" or "acpi=ht" is specified, but will suffer a kernel panic otherwise (see attached). Combinations of "pci=noacpi", "acpi=noirq", "pnpacpi=off", "noapic", "nolapic", and "intel_iommu=off" do not seem to help this issue at all. All of my packages have been updated and this is the latest released version of the kernel at the point of writing. How reproducible: Without fail (no pun intended). Steps to Reproduce: 1. Attempt to boot the installation DVD or the most recent version of the kernel Expected results: It should boot properly with full support for ACPI. Actual results: You'll end up enjoying a kernel panic.
I confirm the bug on a Toshiba Satellite T135 when update Fedora 13 to kernel 2.6.34.6-47.fc13.x86_64. The laptop boot normally when "acpi=off" but then can't power off. I have to use previous kernel.
(In reply to comment #1) > I confirm the bug on a Toshiba Satellite T135 when update Fedora 13 to kernel > 2.6.34.6-47.fc13.x86_64. > > The laptop boot normally when "acpi=off" but then can't power off. I have to > use previous kernel. You have the exact same trace, with the oops happening at kmem_cache_alloc_notrace?
Created attachment 446619 [details] Trace from Toshiba T135
(In reply to comment #2) > (In reply to comment #1) > > I confirm the bug on a Toshiba Satellite T135 when update Fedora 13 to kernel > > 2.6.34.6-47.fc13.x86_64. > > > > The laptop boot normally when "acpi=off" but then can't power off. I have to > > use previous kernel. > > You have the exact same trace, with the oops happening at > kmem_cache_alloc_notrace? Yes, I upload an attachment with my trace and the last 7 lines are the same. Now the kernel is 2.6.34.6-54.fc13.x86_64. I try Fedora 14 Alpha, but when update the kernel the same problem happens.
I had this exact same problem with a Toshiba Satellite Pro C650 (PSC13E), I was forced to add the kernel parameters 'noacpi noapic nolapic irqpoll' to fix the kernel panic and stop USB devices from being incredibly slow... however ACPI was obviously disabled. This was using 2.6.34.6-54.fc13.x86_64. I managed to get ACPI working by upgrading the kernel version to 2.6.35.4-12.fc14.x86_64 and adding the kernel parameter 'acpi=copy_dsdt'. Hope this helps :)
(In reply to comment #5) > > I managed to get ACPI working by upgrading the kernel version to > 2.6.35.4-12.fc14.x86_64 and adding the kernel parameter 'acpi=copy_dsdt'. > > Hope this helps :) Don't help in my case :( I upgrade the kernel and add parameter 'acpi=copy_dsdt' in the grub.conf file like this: kernel /boot/vmlinuz-2.6.35.4-12.fc14.x86_64 ro root=UUID=7cc0412a-85a1-4002-bb3d-9b65fb62411e rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=es_CO.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=es rhgb quiet acpi=copy_dsdt But still have the same problem. Maybe I did something wrong?
(In reply to comment #6) > (In reply to comment #5) > > > > I managed to get ACPI working by upgrading the kernel version to > > 2.6.35.4-12.fc14.x86_64 and adding the kernel parameter 'acpi=copy_dsdt'. > > > > Hope this helps :) > > Don't help in my case :( > > I upgrade the kernel and add parameter 'acpi=copy_dsdt' in the grub.conf file > like this: > > kernel /boot/vmlinuz-2.6.35.4-12.fc14.x86_64 ro > root=UUID=7cc0412a-85a1-4002-bb3d-9b65fb62411e rd_NO_LUKS rd_NO_LVM rd_NO_MD > rd_NO_DM LANG=es_CO.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=es > rhgb quiet acpi=copy_dsdt > > But still have the same problem. Maybe I did something wrong? I'm not sure if this would make a difference but it is worth trying... When I upgraded to 2.6.35.4-12 I left out all "acpi=*" parameters and the kernel panic went away... however I did get another problem where while booting, messages like 'usb 1-1 not accepting address' and 'ata1 lost interrupt' would just keep looping. Fortunately one of the messages did comment that if you have problems to use "acpi=copy_dsdt" which worked for me. From what I can tell from research on google, this seems to be a problem with Insyde H2O BIOSes on many Toshiba laptops... and possibly with 64-bit kernels?
(In reply to comment #7) > > From what I can tell from research on google, this seems to be a problem with > Insyde H2O BIOSes on many Toshiba laptops... and possibly with 64-bit kernels? I make a clean install of 32-bit Fedora 13 and everything with this problem happens the same way, even with kernel-2.6.35.4-28.fc14.i686 and the "acpi=copy_dsdt" option, so in my case is not a 64-bit kernel problem. I keep booting kernel-2.6.33.3-85.fc13.i686 by default for regular use. I don't know if this is helpful, but this is the bios information get by dmidecode (I can't check if this is a Insyde H2O bios): Handle 0x0000, DMI type 0, 24 bytes BIOS Information Vendor: TOSHIBA Version: V2.70 Release Date: 07/08/2010 Address: 0xE43D0 Runtime Size: 113712 bytes ROM Size: 2048 kB Characteristics: ISA is supported PCI is supported PC Card (PCMCIA) is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported ACPI is supported USB legacy is supported BIOS boot specification is supported Targeted content distribution is supported
Solved in my case: Today I install Fedora 14 Beta and try some parameters to kernel 2.6.35.4-28.fc14.i686, acpi=copy_dsdt don't work, but acpi_no_auto_ssdt works fine.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping