Hello.
Mark Lord wrote:
Could you git-bisect this?
Although I have a couple of patch suspects (dealing with
interrupts),
all worked fine with PCI-649 just fine. PCI-648 is not really much
different from 649 according to specs...
Yes, I found the same when I managed to send the CMD 648 into
UDMA-100 mode years ago (by treating it like a 649).
Anyway, I found the git patches on kernel.org and bisected away. For
completeness, this is the table containing all my results.
Kernel System reaction
============================================================================
2.6.21 CMD 648 working fine
2.6.21-git4 CMD 648 working fine
2.6.21-git5 CMD 648 working fine
2.6.21-git6 irg 15: nobody cared [...] Disabling IRQ #15 etc.
2.6.21-git8 irg 15: nobody cared [...] Disabling IRQ #15 etc.
2.6.22-rc1 irg 15: nobody cared [...] Disabling IRQ #15 etc.
2.6.22 irg 15: nobody cared [...] Disabling IRQ #15 etc.
2.6.23 irg 15: nobody cared [...] Disabling IRQ #15 etc.
Well, most likely the CMD related patches in git6 are the culprit.
Erm... usually bisection leaves you with one patch startting from
which kernel was broken. It seems you've done sort iof manual
bisecting. Thanks anyway. :-)
He's certainly provided way more than enough information here to find/fix
the bug. The onus for hours of slaving away here is really on the person
who *broke* it, not the innocent reporter!
In this case, there are two very likely commits:
7670df73fba373d19471a2ebedb3302ea0607be0 ide: mode limiting fixes for
user requested speed changes
26bcb879c03254545a19c6700fe5bcef6f21e7b1 ide: add ide_set{_max}_pio()
(take 4)
Hm, why do you think that these two are very likely, if there was 5
patches commiited exclusively to the cmd64x driver (two of them being
interrupt related)?..
Cheers
MBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
