Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?
On Saturday 20 October 2007 19:11:56 Sergei Shtylyov wrote: What I don't like is that both PIIX4 and PCI-648 are sharing IRQ15 (PIIX4 is in legacy mode, so it uses edge-triggered IRQ15 which is not shareable). You don't have drives connected to PIIX4, do you? However, it doesn't look like a glitch on IRQ15, it looks like MRDMODE reg. doesn't work as documented... Well, don't worry too much about the PIIX device. I have disabled it in the BIOS, and I haven't compiled the driver into the kernel. The IRQ sharing hasn't troubled any linux version yet, nor any OS from the other side. MOst likely you're on the right track with the mrdmode register. cu Martin - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?
Hello. Martin Rogge wrote: 00:04.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master]) Flags: medium devsel [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] How comes it's Memory and not I/O ports?! Looks like something is wrong in either lspci itself or where it fetches the data from... I/O ports at d800 [disabled] [size=16] 00:04.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI]) Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at d400 [size=32] 00:04.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02) Flags: medium devsel, IRQ 9 00:07.0 IDE interface: Silicon Image, Inc. PCI0648 (rev 01) (prog-if 8f [Master SecP SecO PriP PriO]) Yeah, that's exactly PCI-648 revision 1 that was described in the spec. Well, I'll send you a patch to try soon... MBR, Sergei - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?
Martin Rogge wrote: 00:04.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master]) Flags: medium devsel [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] I/O ports at d800 [disabled] [size=16] [...] 00:07.0 IDE interface: Silicon Image, Inc. PCI0648 (rev 01) (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: ASUSTeK Computer Inc. CUBX motherboard Flags: bus master, medium devsel, latency 64, IRQ 15 I/O ports at d000 [size=8] I/O ports at b800 [size=4] I/O ports at b400 [size=8] I/O ports at b000 [size=4] I/O ports at a800 [size=16] Capabilities: [60] Power Management version 1 What I don't like is that both PIIX4 and PCI-648 are sharing IRQ15 (PIIX4 is in legacy mode, so it uses edge-triggered IRQ15 which is not shareable). You don't have drives connected to PIIX4, do you? However, it doesn't look like a glitch on IRQ15, it looks like MRDMODE reg. doesn't work as documented... cu Martin MBR, Sergei - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?
On Friday 19 October 2007 22:26:23 Sergei Shtylyov wrote: Hello. Martin Rogge wrote: BTW, can you try adding #define DEBUG to the driver meanwhile?.. Yoda said: Try not. Do or do not. There is no try. :-) So I did it. To be precise, I #defined both DEBUG and CMD_DEBUG. However, I am not sure the result is conclusive. On a good kernel I get a lot of lines of the type hda: dma_stat: 0x24 irq_stat: 0x44 mask: 0x04 hdc: dma_stat: 0x24 irq_stat: 0x5c mask: 0x10 Yeah, this is what's emitted by the dma_end() method which used CFR/ARTTIM23 PCI config. regs. to chack the interrupt status. and variations thereof. On a broken kernel the middle part changes to hda: dma_stat: 0x24 mrdmode: 0x00 mask: 0x04 Hm... this means that the chip doesn't work as documented in the spec, i.e. MRDMODE reg. seems write only, like on older chips. Could you post the output of 'lspci -v'? Hope this is of any help, It is of great help. :-) cu Martin MBR, Sergei Here you go: [EMAIL PROTECTED]:~# lspci -v 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) Subsystem: ASUSTeK Computer Inc. Unknown device 8025 Flags: bus master, medium devsel, latency 64 Memory at e000 (32-bit, prefetchable) [size=128M] Capabilities: [a0] AGP version 1.0 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 Memory behind bridge: da00-dbdf Prefetchable memory behind bridge: dbf0-dfff 00:04.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02) Flags: bus master, medium devsel, latency 0 00:04.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master]) Flags: medium devsel [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] I/O ports at d800 [disabled] [size=16] 00:04.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI]) Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at d400 [size=32] 00:04.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02) Flags: medium devsel, IRQ 9 00:07.0 IDE interface: Silicon Image, Inc. PCI0648 (rev 01) (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: ASUSTeK Computer Inc. CUBX motherboard Flags: bus master, medium devsel, latency 64, IRQ 15 I/O ports at d000 [size=8] I/O ports at b800 [size=4] I/O ports at b400 [size=8] I/O ports at b000 [size=4] I/O ports at a800 [size=16] Capabilities: [60] Power Management version 1 00:09.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 08) Subsystem: Creative Labs CT4832 SBLive! Value Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at a400 [size=32] Capabilities: [dc] Power Management version 1 00:09.1 Input device controller: Creative Labs SB Live! Game Port (rev 08) Subsystem: Creative Labs Gameport Joystick Flags: bus master, medium devsel, latency 32 I/O ports at a000 [size=8] Capabilities: [dc] Power Management version 1 00:0a.0 FireWire (IEEE 1394): Texas Instruments TSB12LV23 IEEE-1394 Controller (prog-if 10 [OHCI]) Subsystem: Texas Instruments Unknown device 8010 Flags: bus master, medium devsel, latency 32, IRQ 14 Memory at d980 (32-bit, non-prefetchable) [size=2K] Memory at d900 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 1 00:0d.0 SCSI storage controller: LSI Logic / Symbios Logic 53c810 (rev 23) Subsystem: LSI Logic / Symbios Logic LSI53C810AE PCI to SCSI I/O Processor Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at 9800 [size=256] Memory at d880 (32-bit, non-prefetchable) [size=256] Capabilities: [40] Power Management version 1 00:0e.0 Ethernet controller: D-Link System Inc DGE-528T Gigabit Ethernet Adapter (rev 10) Subsystem: D-Link System Inc DGE-528T Gigabit Ethernet Adapter Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 14 I/O ports at 9400 [size=256] Memory at d800 (32-bit, non-prefetchable) [size=256] [virtual] Expansion ROM at 3000 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 01:00.0 VGA compatible controller: nVidia Corporation NV28 [GeForce4 Ti 4200 AGP 8x] (rev a1)
Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?
Hello. Martin Rogge wrote: BTW, can you try adding #define DEBUG to the driver meanwhile?.. Yoda said: Try not. Do or do not. There is no try. :-) So I did it. To be precise, I #defined both DEBUG and CMD_DEBUG. However, I am not sure the result is conclusive. On a good kernel I get a lot of lines of the type hda: dma_stat: 0x24 irq_stat: 0x44 mask: 0x04 hdc: dma_stat: 0x24 irq_stat: 0x5c mask: 0x10 Yeah, this is what's emitted by the dma_end() method which used CFR/ARTTIM23 PCI config. regs. to chack the interrupt status. and variations thereof. On a broken kernel the middle part changes to hda: dma_stat: 0x24 mrdmode: 0x00 mask: 0x04 Hm... this means that the chip doesn't work as documented in the spec, i.e. MRDMODE reg. seems write only, like on older chips. Could you post the output of 'lspci -v'? Hope this is of any help, It is of great help. :-) cu Martin MBR, Sergei - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?
On Wednesday 17 October 2007 22:40:21 Sergei Shtylyov wrote: BTW, can you try adding #define DEBUG to the driver meanwhile?.. Yoda said: Try not. Do or do not. There is no try. So I did it. To be precise, I #defined both DEBUG and CMD_DEBUG. However, I am not sure the result is conclusive. On a good kernel I get a lot of lines of the type hda: dma_stat: 0x24 irq_stat: 0x44 mask: 0x04 hdc: dma_stat: 0x24 irq_stat: 0x5c mask: 0x10 and variations thereof. On a broken kernel the middle part changes to hda: dma_stat: 0x24 mrdmode: 0x00 mask: 0x04 Hope this is of any help, cu Martin - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?
On Wednesday 17 October 2007 00:14:26 Bartlomiej Zolnierkiewicz wrote: 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). I'll do my best. I appear to have git 1.5.2.2 on my machine, but I've never used it. In the old days we used not to have such luxury! Give me a few days. I shall report back. cu Martin - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?
Hello. Martin Rogge wrote: 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). I'll do my best. I appear to have git 1.5.2.2 on my machine, but I've never used it. In the old days we used not to have such luxury! Give me a few days. I shall report back. BTW, can you try adding #define DEBUG to the driver meanwhile?.. cu Martin WBR, Sergei - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?
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-git4CMD 648 working fine 2.6.21-git5CMD 648 working fine 2.6.21-git6irg 15: nobody cared [...] Disabling IRQ #15 etc. 2.6.21-git8irg 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. :-) Regards, cu Martin MBR, Sergei - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?
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-git4CMD 648 working fine
2.6.21-git5CMD 648 working fine
2.6.21-git6irg 15: nobody cared [...] Disabling IRQ #15 etc.
2.6.21-git8irg 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)
Cheers
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?
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-git4CMD 648 working fine
2.6.21-git5CMD 648 working fine
2.6.21-git6irg 15: nobody cared [...] Disabling IRQ #15 etc.
2.6.21-git8irg 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?
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-git4CMD 648 working fine
2.6.21-git5CMD 648 working fine
2.6.21-git6irg 15: nobody cared [...] Disabling IRQ #15 etc.
2.6.21-git8irg 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?
Martin Rogge wrote: Hi Sergei and Bartlomiej, I have read in the changelog that both of you got linux kernel patches into 2.6.22-rc1 for the cmd64x driver. I found that some patches introduced in 2.6.22-rc1 break the CMD648 operation of one of my machines. (Actually I discovered it in 2.6.23 but since then verified that the fatal change was introduced between 2.6.21 and 2.6.22-rc1.) Your 2.6.22-rc1 patches may not be responsible for my problem. Nonetheless, could you take a look? If you need any additional info, or need me to try something out, please let me know. 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... Below I copied the mail I sent to lkml a few days ago. So far I have received no reaction. I'm not reading LKML, so CC your further mails to [EMAIL PROTECTED] WBR, Sergei - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
