Hi, On Tuesday 16 October 2007, Mark Lord wrote: > Sergei Shtylyov wrote: > > Martin Rogge 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! Find the guilty and we will make him atone his sins in IDE quarry! ;) Now speaking seriously: 2.6.21-git5 to 2.6.21-git6 still means 375 commits and almost 2MB patch (with five patches for cmd64x alone - and looking at the bugreport we really can't be 100% sure if this is IDE regression, it could be IRQ routing as well). However you are right that Martin has already provided us with a lot of information, so... Martin, could you run git-bisect (http://kerneltrap.org/node/11753 - sorry for not explaining the procudure myself but Linus did it really well) starting with: git bisect good 688a87d145e04f6761c63e7f2e19fd9b3e4ca060 git bisect bad 826a1b6502d0d1d67fc41043fc831e90f2ef5835 The "good" one is the last commit before cmd64x changes and the "bad" one is the first commit after them. Since there is only 5 commits in between it should be really quick find the bad one (worst-case: 3 recompiles/reboots). If this "fastpath" doesn't work we are back to bisecting all 375 commits between 2.6.21-git5 and 2.6.21-git6 with: git bisect good 62ea6d80211ecc88ef516927ecebf64cb505be3f git bisect bad b7405e16435f710edfae6ba32bef4ca20d3de145 Which still doesn't look (that) bad with worst-case being 9 recompile/reboot cycles. > 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) These two were merged just few days ago (probably some git related issue). Thanks, Bart - 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
