Created attachment 326877 [details] lspci -v output Description of problem: I'm trying to install F10 (or Rawhide) on a Toshiba NB100 Intel-Atom-Netbook. The kernel fails to recognize the sata-drive: ata1.00: qc timeout (cmd 0xec) ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) The netbook came with ubuntu hardy preinstalled (which worked), I can also successfully access the HDD when booting the grml-livecd (debian based, 2.6.26 kernel). The F8-Gold-Kernel (2.6.23) also boots and installs fine on this machine. After updating to the latest available F8-Kernel (2.6.26) the boot fails unless I add irqpoll to the boot-options. Using the F9, F10 and Rawhide boot.iso it also failes to recognize the disk. Adding noapic and/or irqpoll to the bootoptions on F10 and rawhide doesn't help. Switching the SATA-Controller mode to Compatibility (from AHCI) in the Bios gets me different errors but the boot still fails. Version-Release number of selected component (if applicable): All tests have been done using the F10-livecd but afaiks the same issue exists in rawhide (using yesterdays boot.iso). How reproducible: Aquire Toshiba NB100, boot fedora live-cd or boot.iso
Created attachment 326878 [details] dmesg from live-cd with no additional options
Created attachment 326879 [details] dmesg from live-cd with irqpoll added
Switching version to rawhide as I have now managed to install rawhide onto a usb stick on the machine. The hdd is still not recognized using the 2.6.28-1 kernel (new dmesg attached). I also reinstalled ubuntu onto the harddrive from the vendor- supplied cd. Running said ubuntu (2.6.24 Kernel) install, I compiled a monolithic vanilla 2.6.28-rc9 kernel (dmesg attached too) and that boots fine (into ubuntu). So could this be an issue with either one of the fedora kernel-patches or some weird initrd-interaction going on?
Created attachment 327843 [details] dmesg from rawhide kernel booting into rawhide installed on a usb stick
Created attachment 327844 [details] dmesg from 2.6.28-rc9 vanilla booting into ubuntu hardy
Toshiba released an updated bios (v1.60) for this machine in January - updating to this bios-version solves the described issue. So - not a (Fedora)-Bug (still strange that a vanilla-kernel did boot ...)