Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?

Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?

[Sergei Shtylyov]

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 linux-ide@vger.kernel.org...

WBR, Sergei

Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?

[Sergei Shtylyov]

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. :-)

> Regards,

> cu Martin

MBR, Sergei

Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?

[Mark Lord]

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!

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

Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?

[Sergei Shtylyov]

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

Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?

[Bartlomiej Zolnierkiewicz]

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

Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?

[Martin Rogge]

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

Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?

[Sergei Shtylyov]

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

Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?

[Martin Rogge]

[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]

On Wednesday 17 October 2007 21:15:12 Martin Rogge wrote:
> 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

OK, the jury is in. This is the result of git bisecting:

66602c83dcb6a5d82772d88ae7a32cd4a1213528 is first bad commit
commit 66602c83dcb6a5d82772d88ae7a32cd4a1213528
Author: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Date:   Sat May 5 22:03:50 2007 +0200

    cmd64x: use interrupt status from MRDMODE register (take 2)

    Fold the parts of the ide_dma_end() methods identical to __ide_dma_end() 
into a
    mere call to it.
    Start using faster versions of the ide_dma_end() and ide_dma_test_irq() 
methods
    for the PCI0646U and newer chips that have the duplicate interrupt status 
bits
    in the I/O mapped MRDMODE register, determing what methods to use at the 
driver
    load time. Do some cleanup/renaming in the "old" ide_dma_test_irq() method 
too.

    Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
    Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

:040000 040000 e9596b9ff362a0bec73601baac84025f106846f9 
531d19102f9ff54ff870618c742ad81d930af533 M      drivers

I shall also attach the file BISECT_LOG. Hope this gives you some valuable 
input.

cu Martin


[-- Attachment #2: BISECT_LOG --]
[-- Type: text/plain, Size: 771 bytes --]

git-bisect start
# good: [688a87d145e04f6761c63e7f2e19fd9b3e4ca060] sl82c105: DMA support code cleanup (take 4)
git-bisect good 688a87d145e04f6761c63e7f2e19fd9b3e4ca060
# bad: [826a1b6502d0d1d67fc41043fc831e90f2ef5835] aec62xx: fix PIO/DMA setup issues
git-bisect bad 826a1b6502d0d1d67fc41043fc831e90f2ef5835
# good: [7accbffdb8163a59c7bdd3e4eb9a391198979522] cmd64x: add/fix enablebits (take 2)
git-bisect good 7accbffdb8163a59c7bdd3e4eb9a391198979522
# bad: [66602c83dcb6a5d82772d88ae7a32cd4a1213528] cmd64x: use interrupt status from MRDMODE register (take 2)
git-bisect bad 66602c83dcb6a5d82772d88ae7a32cd4a1213528
# good: [5826b318aa02e81575c352ca26f00773c999795b] cmd64x: procfs code fixes/cleanups (take 2)
git-bisect good 5826b318aa02e81575c352ca26f00773c999795b

Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?

[Martin Rogge]

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

Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?

[Sergei Shtylyov]

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

Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?

[Martin Rogge]

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:

root@fred:~# 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 e0000000 (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: da000000-dbdfffff
        Prefetchable memory behind bridge: dbf00000-dfffffff

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 000001f0 (32-bit, non-prefetchable) [disabled] 
[size=8]
        [virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] 
[size=1]
        [virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] 
[size=8]
        [virtual] Memory at 00000370 (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 d9800000 (32-bit, non-prefetchable) [size=2K]
        Memory at d9000000 (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 d8800000 (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 d8000000 (32-bit, non-prefetchable) [size=256]
        [virtual] Expansion ROM at 30000000 [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) (prog-if 00 [VGA])
        Subsystem: Micro-Star International Co., Ltd. Unknown device 8948
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11
        Memory at da000000 (32-bit, non-prefetchable) [size=16M]
        Memory at dc000000 (32-bit, prefetchable) [size=64M]
        Expansion ROM at dbfe0000 [disabled] [size=128K]
        Capabilities: [60] Power Management version 2
        Capabilities: [44] AGP version 3.0

cu Martin

Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?

[Sergei Shtylyov]

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 000001f0 (32-bit, non-prefetchable) [disabled] 
> [size=8]
>         [virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] 
> [size=1]
>         [virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] 
> [size=8]
>         [virtual] Memory at 00000370 (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

Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?

[Sergei Shtylyov]

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 000001f0 (32-bit, non-prefetchable) [disabled] 
> [size=8]
>         [virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] 
> [size=1]
>         [virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] 
> [size=8]
>         [virtual] Memory at 00000370 (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

Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?

[Martin Rogge]

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

Re: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?

[Sergei Shtylyov]

Hello.

Martin Rogge 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.

    You can't disable IRQ14/15 it uses this way.

> MOst likely you're on the right track with the mrdmode register.

    Yet I want to make sure the manual is lying...

> cu Martin

MBR, Sergei