Most recent kernel where this bug did not occur: 2.6.15-1.1833_FC4 Distribution: Fedora Core 4 Hardware Environment: Matsonic 8177c mobo via chipset 8237 south bridge. 2 sata devices. Software Environment: Problem Description: sata drive fails to set xfer mode Steps to reproduce:
Created attachment 12381 [details] dmesg
Created attachment 12382 [details] hdparm -I /dev/sda
Created attachment 12383 [details] hdparm -I /dev/sdb
Created attachment 12384 [details] lspci -nnv
Hmmm... I have a similar, though not the same, drive WD2600YS-01S and it's happy with HPA on my machine (intel and via ahci). I wanna make sure the drives are the problem before proceeding. Can you try to connect the drives to a different controller and see whether the problem persists? Thanks.
I tried booting with a SiL pci sata controller. Same exact error. Will post dmesg if requested.
Created attachment 12392 [details] hpa-update.patch Please apply the attached patch on top of 2.6.23-rc3 and report the result. Thanks.
Created attachment 12394 [details] hpa-update-1.patch Oops, that was the wrong patch. Please test this one. Thanks.
Will test when I return home from work. Thanks.
Patch does not work, ata2 is still getting disabled. I'm not sure how I can post the dmesg log as the kernel panic exits without booting.
If you don't have serial or net console set up, digital camera comes pretty handy.
Created attachment 12412 [details] dmesg from combined.patch this will have to suffice until I get a serial console up.
Created attachment 12413 [details] dmesg from combined patch - part 2
Created attachment 12416 [details] hpa-update-2.patch Please give a shot at this one. Thanks.
Richard wrote > I forgot to mention.. what it does now is just an endless cycle of trying to > set > the xfer modes. it cycles through all modes, then gets caught in an infinate > loop attempting to set it to udma/33. Hmmm... That seems to be caused by a different problem. Probably IRQ mis-delivery. Please give a shot at 'acpi=noirq', if that doesn't work 'noapic' and lastly 'irqpoll'. Thanks.
Created attachment 12451 [details] dmesg w/ noapic & irqpoll it seems to get past the point where it hung before. But now it brings a different error.
oh. And acpi=noirq has no change to the boot msg.
Thanks. It seems IRQ delivery on VIA is broken again but I'm not sure why it failed to boot with irqpoll. What's your root device? Kernel detected disks okay but failed to mount the root partition with error 6 (ENXIO). Could it be the wrong "root=" parameter?
This patched booted fine with the proper root= parameter. Sorry for the oversight, it was pointing to a different install on a different drive. I have been up and running on 2.6.23-rc3 with your patch for a day and so far no problems.
Please post boot kernel log && file a separate bug report for the IRQ routing problem. Thanks.