Comment 22 for bug 425756

Looking at the hardy boot we can see that the cdrom is on IDE (as we would expect). We believe that it is the slave on the first channel:

    [ 38.531261] hdb: host max PIO4 wanted PIO255(auto-tune) selected PIO4
    [ 38.531534] hdb: UDMA/33 mode selected
    [ 38.531827] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
    [ 38.554642] hdb: ATAPI 40X DVD-ROM CD-R/RW drive, 1536kB Cache

If we look at the karmic boot we see the following:

    [ 0.717102] pata_atiixp 0000:00:14.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
    [ 0.717229] scsi4 : pata_atiixp
    [ 0.717372] scsi5 : pata_atiixp
    [ 0.718087] ata5: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xf900 irq 14
    [ 0.718090] ata6: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xf908 irq 15
    [...]
    [ 1.000067] ata5.01: NODEV after polling detection

Looking at the trigger for this message we find that is can only be emmitted when talking to a PATA device, there seem to be three ways this can be triggered, though the second of these ought to emit a message:

    /* If diagnostic failed and this is
     * IDENTIFY, it's likely a phantom
     * device. Mark hint.
     */
or
    /* HSM violation. Let EH handle this.
     * Phantom devices also trigger this
     * condition. Mark hint.
     */
or
    /* There are oddball controllers with
     * status register stuck at 0x7f and
     * lbal/m/h at zero which makes it
     * pass all other presence detection
     * mechanisms we have. Set NODEV_HINT
     * for it. Kernel bz#7241.
     */

It might be informative to know which of these it is however. I have added some diagnostics for these various cases and built test kernels. Perhaps you could test those and report back here. There should be some APW: lines in the dmesg output, if you could attach that from the debug kernel. Kernels can be found at the URL below:

    http://people.canonical.com/~apw/lp425756-karmic/