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
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).
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 ...)