Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Edward King]

John:

Quick fix to the problem is remove devfs -- it appears that the devfs 
code doesn't like to have the raid layered on top of it, and it loses 
interrupts.

I've got two systems now running 4 200GB WD's connected to a single 
promise card (ATA100/TX2)  with the booting drive (a 5th drive) attached 
to the motherboard.  The raid works flawlessly and is fast -- I imagine 
there'd be a speedup by keeping all the drives as master (with 2 pdc's) 
and it would be more robust, but those aren't issues.

Hope this helps -- I'll post this to the mailing list to help anyone 
else with this problem.

- Ed

John V. Martinez wrote:

> Hi Ed,
>
> I found a linux-kernel post you made back in March about problems 
> running two Promise IDE controllers in the same system. I have a 
> similar configuration, (and a similar problem,) and I was wondering if 
> you ever found a solution, or if one of the more recent 2.4.21-foo 
> kernels solved it for you.
>
> (I have two Promise ATA-100/TX2 (20268 chip) controllers, and I have 
> one 200GB WD drive as a single master on each channel. The two 
> controllers are sharing interrupts with othwer cards, but not with 
> each other. I can access each disk individually, but when I tried to 
> make them work hard: mkraid a RAID5 array using these four drives, the 
> system freezes HARD until I hit the big red button. [Then it reboots, 
> spots the raid superblock, tries to rebuild my RAID5 array, and 
> freezes again, until I get a clue and unplug the drives in question 
> while powered down :^))
>
> Anyway, if you have any more insight into this problem than you did in 
> March, and care to share, I'd be much obliged.
>
> Cheers,
>
> -(-- John

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[John V. Martinez]

Hi Ed,


Thanks for the quick reply. Sadly, I think I have a different
(possibly related?) problem, as I am not currently using devfs.

(clarification: my kernel does have devfs support compiled in, but it
is not mounted on my system -- you don't think just having it compiled
in makes any difference, do you? I can't see why it would, but
stranger things have happened -- to me, at least :^) -- I'm currently
running a Debian 3.0 system with their 'Pentium Classic' 2.4.18 kernel
(2.4.18-586tsc) flavor, but the problem was still present when I tried
switching to the 2.4.20 kernel currently in testing. I guess I'll try
building 2.4.21 when I get a chance - trouble is, it's (supposed to
be) a 24x7 server, so I can't afford too much downtime for these
experiments. (Which is why I was searching the web, hoping to find a
definitive checkin comment somewhere that said "John's problem with
two promise controllers locking up his system when he rebuild his RAID
array is fixed now in 2.4.21-cheesewhiz" but no such luck.

:^)

I guess if all else fails, I'll use the setup you have: 4-drive RAID
on one controller. My concern was not so much the performance hit of
using both master&slave, but the possibility of a bad drive hosing the
connection to both drives on that controller, thus taking down 1/2 of my
RAID5 array at once. 

Do you happen to know if anybody makes a (Linux-friendly) IDE
controller card with more than two channels? All the cards I have
found which will connect more than 4 drives are hardware RAID
controllers, (or faux-hardware raid, like Promise.)

Anyway, thanks again for your time,

-(-- John V. Martinez



On Tue, Jul 22, 2003 at 09:44:10AM -0500, Edward King wrote:
> John:
> 
> Quick fix to the problem is remove devfs -- it appears that the devfs 
> code doesn't like to have the raid layered on top of it, and it loses 
> interrupts.
> 
> I've got two systems now running 4 200GB WD's connected to a single 
> promise card (ATA100/TX2)  with the booting drive (a 5th drive) attached 
> to the motherboard.  The raid works flawlessly and is fast -- I imagine 
> there'd be a speedup by keeping all the drives as master (with 2 pdc's) 
> and it would be more robust, but those aren't issues.
> 
> Hope this helps -- I'll post this to the mailing list to help anyone 
> else with this problem.
> 
> - Ed
> 
> John V. Martinez wrote:
> 
> >Hi Ed,
> >
> >I found a linux-kernel post you made back in March about problems 
> >running two Promise IDE controllers in the same system. I have a 
> >similar configuration, (and a similar problem,) and I was wondering if 
> >you ever found a solution, or if one of the more recent 2.4.21-foo 
> >kernels solved it for you.
> >
> >(I have two Promise ATA-100/TX2 (20268 chip) controllers, and I have 
> >one 200GB WD drive as a single master on each channel. The two 
> >controllers are sharing interrupts with othwer cards, but not with 
> >each other. I can access each disk individually, but when I tried to 
> >make them work hard: mkraid a RAID5 array using these four drives, the 
> >system freezes HARD until I hit the big red button. [Then it reboots, 
> >spots the raid superblock, tries to rebuild my RAID5 array, and 
> >freezes again, until I get a clue and unplug the drives in question 
> >while powered down :^))
> >
> >Anyway, if you have any more insight into this problem than you did in 
> >March, and care to share, I'd be much obliged.
> >
> >Cheers,
> >
> >-(-- John
> 
> 

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Edward King]

Do not compile the devfs -- I beleive if you compile it, it will be used 
(it can't be compiled as a module).

I caught the error because partimage didn't find /dev/hda1 but found the 
path devfs uses natively (don't remember, something like bsd, not 
important) which I beleive (and could be really off base here) that the 
/dev/hda1 actually pointed to if devfs code was compiled in (I _think_ 
-- big stress on not being sure -- that devfs makes itself transparent.)

Compile without devfs and try it.  It doesn't matter how many ide 
controllers you use, where you put the drives, DMA settings, etc.  I 
found with devfs the raid would crash in a heartbeat but single drives 
would respond without a hiccup -- even running bonnie on each drive 
simultaneously for hours.

As for more ide ports, no idea.  Maybe the new SATA will help there but 
I haven't played with them.

- Ed

John V. Martinez wrote:

>Hi Ed,
>
>
>Thanks for the quick reply. Sadly, I think I have a different
>(possibly related?) problem, as I am not currently using devfs.
>
>(clarification: my kernel does have devfs support compiled in, but it
>is not mounted on my system -- you don't think just having it compiled
>in makes any difference, do you? I can't see why it would, but
>stranger things have happened -- to me, at least :^) -- I'm currently
>running a Debian 3.0 system with their 'Pentium Classic' 2.4.18 kernel
>(2.4.18-586tsc) flavor, but the problem was still present when I tried
>switching to the 2.4.20 kernel currently in testing. I guess I'll try
>building 2.4.21 when I get a chance - trouble is, it's (supposed to
>be) a 24x7 server, so I can't afford too much downtime for these
>experiments. (Which is why I was searching the web, hoping to find a
>definitive checkin comment somewhere that said "John's problem with
>two promise controllers locking up his system when he rebuild his RAID
>array is fixed now in 2.4.21-cheesewhiz" but no such luck.
>
>:^)
>
>I guess if all else fails, I'll use the setup you have: 4-drive RAID
>on one controller. My concern was not so much the performance hit of
>using both master&slave, but the possibility of a bad drive hosing the
>connection to both drives on that controller, thus taking down 1/2 of my
>RAID5 array at once. 
>
>Do you happen to know if anybody makes a (Linux-friendly) IDE
>controller card with more than two channels? All the cards I have
>found which will connect more than 4 drives are hardware RAID
>controllers, (or faux-hardware raid, like Promise.)
>
>Anyway, thanks again for your time,
>
>-(-- John V. Martinez
>
>
>
>On Tue, Jul 22, 2003 at 09:44:10AM -0500, Edward King wrote:
>  
>
>>John:
>>
>>Quick fix to the problem is remove devfs -- it appears that the devfs 
>>code doesn't like to have the raid layered on top of it, and it loses 
>>interrupts.
>>
>>I've got two systems now running 4 200GB WD's connected to a single 
>>promise card (ATA100/TX2)  with the booting drive (a 5th drive) attached 
>>to the motherboard.  The raid works flawlessly and is fast -- I imagine 
>>there'd be a speedup by keeping all the drives as master (with 2 pdc's) 
>>and it would be more robust, but those aren't issues.
>>
>>Hope this helps -- I'll post this to the mailing list to help anyone 
>>else with this problem.
>>
>>- Ed
>>
>>John V. Martinez wrote:
>>
>>    
>>
>>>Hi Ed,
>>>
>>>I found a linux-kernel post you made back in March about problems 
>>>running two Promise IDE controllers in the same system. I have a 
>>>similar configuration, (and a similar problem,) and I was wondering if 
>>>you ever found a solution, or if one of the more recent 2.4.21-foo 
>>>kernels solved it for you.
>>>
>>>(I have two Promise ATA-100/TX2 (20268 chip) controllers, and I have 
>>>one 200GB WD drive as a single master on each channel. The two 
>>>controllers are sharing interrupts with othwer cards, but not with 
>>>each other. I can access each disk individually, but when I tried to 
>>>make them work hard: mkraid a RAID5 array using these four drives, the 
>>>system freezes HARD until I hit the big red button. [Then it reboots, 
>>>spots the raid superblock, tries to rebuild my RAID5 array, and 
>>>freezes again, until I get a clue and unplug the drives in question 
>>>while powered down :^))
>>>
>>>Anyway, if you have any more insight into this problem than you did in 
>>>March, and care to share, I'd be much obliged.
>>>
>>>Cheers,
>>>
>>>-(-- John
>>>      
>>>
>>    
>>
>
>  
>

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Stephan von Krawczynski]

On 23 Feb 2003 16:04:31 +0100
Arjan van de Ven <arjan@fenrus.demon.nl> wrote:

> On Sun, 2003-02-23 at 15:33, Stephan von Krawczynski wrote:
> > On Thu, 06 Feb 2003 15:51:47 +0100
> > Hans Lambrechts <hans.lambrechts@skynet.be> wrote:
> > 
> > > Stephan von Krawczynski wrote:
> > > 
> > > <---snip--->
> > > 
> > > > 
> > > >            CPU0       CPU1
> > > >   0:      71158          0    IO-APIC-edge  timer
> > > >   1:        941          0    IO-APIC-edge  keyboard
> > > >   2:          0          0          XT-PIC  cascade
> > > >  12:      33166          0    IO-APIC-edge  PS/2 Mouse
> > > >  15:          4          0    IO-APIC-edge  ide1
> 
> <snip>
> 
> > I am sorry, but this patch is:
> > a) already included in 2.4.21-pre4 (which I run)
> > b) does therefore obviously not help
> > 
> > Any other suggestions? 
> 
> could you give the irqbalance daemon from
> 
> http://people.redhat.com/arjanv/irqbalance/irqbalance-0.06.tar.gz
> 
> a try ?

Hella Arjan,

I tried it and it looks as if it performs as expected:

           CPU0       CPU1       
  0:    1288917      35375    IO-APIC-edge  timer
  1:       8917        244    IO-APIC-edge  keyboard
  2:          0          0          XT-PIC  cascade
 12:     350644        552    IO-APIC-edge  PS/2 Mouse
 15:          6          0    IO-APIC-edge  ide1
 17:     426082       7881   IO-APIC-level  ide2, ide3
 18:     329936        919   IO-APIC-level  eth0, eth1
 20:         43          0   IO-APIC-level  aic7xxx
 21:   10439503          0   IO-APIC-level  eth2
 22:    1596851     122119   IO-APIC-level  aic7xxx
 23:         16          0   IO-APIC-level  aic7xxx
 25:       1304         36   IO-APIC-level  HiSax
 26:          0          0   IO-APIC-level  EMU10K1
NMI:          0          0 
LOC:    1324228    1324203 
ERR:          0
MIS:          0

Within a few minutes I see the above. The only thing left: I am not able to
produce interrupts from eth2 (tg3) on CPU1. I have not looked at the daemons
policies so far, so maybe this is normal...
It looks interesting. Did you decribe it somewhere?
-- 
Regards,
Stephan

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Arjan van de Ven]

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

On Sun, 2003-02-23 at 15:33, Stephan von Krawczynski wrote:
> On Thu, 06 Feb 2003 15:51:47 +0100
> Hans Lambrechts <hans.lambrechts@skynet.be> wrote:
> 
> > Stephan von Krawczynski wrote:
> > 
> > <---snip--->
> > 
> > > 
> > >            CPU0       CPU1
> > >   0:      71158          0    IO-APIC-edge  timer
> > >   1:        941          0    IO-APIC-edge  keyboard
> > >   2:          0          0          XT-PIC  cascade
> > >  12:      33166          0    IO-APIC-edge  PS/2 Mouse
> > >  15:          4          0    IO-APIC-edge  ide1

<snip>

> I am sorry, but this patch is:
> a) already included in 2.4.21-pre4 (which I run)
> b) does therefore obviously not help
> 
> Any other suggestions? 

could you give the irqbalance daemon from

http://people.redhat.com/arjanv/irqbalance/irqbalance-0.06.tar.gz

a try ?

Greetings,
   Arjan van de Ven

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Stephan von Krawczynski]

On Thu, 06 Feb 2003 15:51:47 +0100
Hans Lambrechts <hans.lambrechts@skynet.be> wrote:

> Stephan von Krawczynski wrote:
> 
> <---snip--->
> 
> > 
> >            CPU0       CPU1
> >   0:      71158          0    IO-APIC-edge  timer
> >   1:        941          0    IO-APIC-edge  keyboard
> >   2:          0          0          XT-PIC  cascade
> >  12:      33166          0    IO-APIC-edge  PS/2 Mouse
> >  15:          4          0    IO-APIC-edge  ide1
> >  17:       1732          0   IO-APIC-level  ide2, ide3
> >  18:       3423          0   IO-APIC-level  eth0, eth1
> >  21:       8177          0   IO-APIC-level  eth2
> >  22:     112943          0   IO-APIC-level  aic7xxx
> >  23:         16          0   IO-APIC-level  aic7xxx
> >  25:         74          0   IO-APIC-level  HiSax
> >  26:          0          0   IO-APIC-level  EMU10K1
> > NMI:          0          0
> > LOC:      71085      71059
> > ERR:          0
> > MIS:          0
> > 
> > ??
> > (kernel 2.4.21-pre4)
> 
> Stephan,
> this patch should fix the interrupt problem.
> 
> Marcelo, please apply.
> 
> Greetings,
> Hans Lambrechts
> 
> 
> --- linux/include/asm-i386/smpboot.h    2003-01-20 16:45:13.000000000 +0100
> +++ linux/include/asm-i386/smpboot.h.orig       2003-01-20 
> 16:44:05.000000000 +0100
> @@ -116,6 +116,6 @@
>         return cpu_online_map;
>  }
>  #else
> -#define target_cpus() (0xFFFFFFFF)
> +#define target_cpus() (0x01)
>  #endif
>  #endif

I am sorry, but this patch is:
a) already included in 2.4.21-pre4 (which I run)
b) does therefore obviously not help

Any other suggestions? 


-- 
Regards,
Stephan

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Benjamin Herrenschmidt]

On Fri, 2003-02-14 at 15:41, Edward King wrote:

> Just wanted to jump in here -- I'm setting up a box using two PDC20268
> controllers for a 4 drive software raid.  The system locks on heavy
> disk activity only if dma is active.
> 
> I was watching this thread and put in the patch to remove the
> "drive->waiting_for_dma++;" line.  I still get lockups and the message
> on the console is:
> 
> hdg: dma_timer_expiry: dma status == 0x21
> hde: dma_timer_expiry: dma status == 0x21
> hdg: timeout waiting for DMA
> PDC202XX: Secondary channel reset
> hdg: timeout waiting for DMA
> hdg: (__ide_dma_test_irq) called while not waiting
> hdg: status error: status = 0x58 { DriveReady SeekComplete DataRequest

The above error is a different problem. Before trying to track it
down, I'd strongly suggest that you first check if it still happens
with the latest 2.4.21-pre4-acX from kernel.org


Ben.

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Edward King]

> On Thu, 2003-02-06 at 13:20, Stephan von Krawczynski wrote:
> > On 05 Feb 2003 18:12:31 +0100
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > 
> > 
> > > Stephan: Can you try editing ide-dma.c, function
> > > __ide_dma_test_irq(), and remove that line:
> > > 
> > > -	drive->waiting_for_dma++;
> > > 
> > > And tell us if it helps in any way.
> > > 
> > > Ben.
> > 
> > Hello Ben,
> > 
> > as requested I tried the above "patch" and had no problem so far. Current
> > situation is:
> > (ide2, ide3 are PDC, eth2 is tg3)
> 
> Ok, well, if it' still stable by now, I beleive we can safely remove
> that line from ide_dma_test_irq(). AFAIK, it really have nothing to do
> here.

Just wanted to jump in here -- I'm setting up a box using two PDC20268
controllers for a 4 drive software raid.  The system locks on heavy
disk activity only if dma is active.

I was watching this thread and put in the patch to remove the
"drive->waiting_for_dma++;" line.  I still get lockups and the message
on the console is:

hdg: dma_timer_expiry: dma status == 0x21
hde: dma_timer_expiry: dma status == 0x21
hdg: timeout waiting for DMA
PDC202XX: Secondary channel reset
hdg: timeout waiting for DMA
hdg: (__ide_dma_test_irq) called while not waiting
hdg: status error: status = 0x58 { DriveReady SeekComplete DataRequest
}
hdg: drive not ready for command
hde: timeout waiting for DMA
PDC202XX: Primary channel reset
hde: timeout waiting for DMA
hde: (__ide_dma_test_irq) called while not waiting

I copied these -- everything with with dma disabled.  I beleive this
is the same problem, and can reproduce it (this occurred deleting a
400MB file on a reiserfs.)

The kernel is 2.4.21-pre4
The chipset is nVidia
The controllers each have their own interrupt (not shared)

I have used PDC controllers for raids in the past, but only one PDC
and the other drives used the onboard ide -- this works fine.

Regards,

edk@cendatsys.com

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Stephan von Krawczynski]

On 07 Feb 2003 00:04:18 +0100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Thu, 2003-02-06 at 13:20, Stephan von Krawczynski wrote:
> > On 05 Feb 2003 18:12:31 +0100
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > 
> > 
> > > Stephan: Can you try editing ide-dma.c, function
> > > __ide_dma_test_irq(), and remove that line:
> > > 
> > > -	drive->waiting_for_dma++;
> > > 
> > > And tell us if it helps in any way.
> > > 
> > > Ben.
> > 
> > Hello Ben,
> > 
> > as requested I tried the above "patch" and had no problem so far. Current
> > situation is:
> > (ide2, ide3 are PDC, eth2 is tg3)
> 
> Ok, well, if it' still stable by now, I beleive we can safely remove
> that line from ide_dma_test_irq(). AFAIK, it really have nothing to do
> here.

Hello all,

it is still working ok, currently we are at:

           CPU0       
  0:   13848205          XT-PIC  timer
  1:      54117          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:          0          XT-PIC  EMU10K1
  7:      27260          XT-PIC  HiSax
  9:   67048861          XT-PIC  ide2, ide3, aic7xxx, aic7xxx, eth0, eth1, eth2
 12:     765541          XT-PIC  PS/2 Mouse
 15:        229          XT-PIC  ide1
NMI:          0 
LOC:          0 
ERR:          0
MIS:          0

Regards,
Stephan

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Benjamin Herrenschmidt]

On Thu, 2003-02-06 at 13:20, Stephan von Krawczynski wrote:
> On 05 Feb 2003 18:12:31 +0100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
> 
> > Stephan: Can you try editing ide-dma.c, function
> > __ide_dma_test_irq(), and remove that line:
> > 
> > -	drive->waiting_for_dma++;
> > 
> > And tell us if it helps in any way.
> > 
> > Ben.
> 
> Hello Ben,
> 
> as requested I tried the above "patch" and had no problem so far. Current
> situation is:
> (ide2, ide3 are PDC, eth2 is tg3)

Ok, well, if it' still stable by now, I beleive we can safely remove
that line from ide_dma_test_irq(). AFAIK, it really have nothing to do
here.

(I suspect it got copied from ide-pmac somewhat... I use it as a counter
in there to implement some timeout when the DMA engine didn't start at
all because the disk issued an error, and on these, I know for sure
the IRQ isn't shared...)

Alan, can you include that ?

===== drivers/ide/ide-dma.c 1.10 vs edited =====
--- 1.10/drivers/ide/ide-dma.c  Sat Feb  1 20:37:36 2003
+++ edited/drivers/ide/ide-dma.c        Fri Feb  7 00:03:43 2003
@@ -826,7 +826,6 @@
        if (!drive->waiting_for_dma)
                printk(KERN_WARNING "%s: (%s) called while not
waiting\n",
                        drive->name, __FUNCTION__);
-       drive->waiting_for_dma++;
        return 0;
 }

(Patch against Marcelo's 2.4.21-pre4)

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Stephan von Krawczynski]

On 05 Feb 2003 18:12:31 +0100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:


> Stephan: Can you try editing ide-dma.c, function
> __ide_dma_test_irq(), and remove that line:
> 
> -	drive->waiting_for_dma++;
> 
> And tell us if it helps in any way.
> 
> Ben.

Hello Ben,

as requested I tried the above "patch" and had no problem so far. Current
situation is:
(ide2, ide3 are PDC, eth2 is tg3)

           CPU0       
  0:    6332048          XT-PIC  timer
  1:      14112          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:          0          XT-PIC  EMU10K1
  7:      14950          XT-PIC  HiSax
  9:   30600647          XT-PIC  ide2, ide3, aic7xxx, aic7xxx, eth0, eth1, eth2
 12:     234451          XT-PIC  PS/2 Mouse
 15:          2          XT-PIC  ide1
NMI:          0 
LOC:          0 
ERR:          0
MIS:          0

I would not say this is a rock-solid test case. I will continue to stress the
setup and keep you informed. Anyway it looks stable up to now.

Regards,
Stephan

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Bryan Andersen]

> Ok, yet another small brick in the wall: this mb has 64bit/66MHz PCI slots. PDC
> is only 32bit/33MHz PCI. So it may well be that others are in fact _able_ to
> produce a damn lot more data/interrupts than the PDC. I am pretty astonished by
> the number of interrupts created by the 3com tg3 cards anyways...

On my box one of the devices sharing the interrupt with the disk
is the display, the USB is quiet with no devices connected.  I am 
running 2.4.21-pre4-ac2.  I'd have redistributed interrupts but the 
motherboard dosen't allow me to specifically set them and APIC isn't 
supposed to work on the nForce2 yet.

cat /proc/interrupts
            CPU0
   0:     273068          XT-PIC  timer
   1:       5547          XT-PIC  keyboard
   2:          0          XT-PIC  cascade
   5:     122188          XT-PIC  eth0
  10:     641526          XT-PIC  ide2, ide3, usb-ohci, nvidia
  11:          0          XT-PIC  NVIDIA nForce Audio, usb-ohci
  12:      78237          XT-PIC  PS/2 Mouse
  14:     109475          XT-PIC  ide0
  15:     114178          XT-PIC  ide1
NMI:          0
LOC:     273027
ERR:      18344
MIS:          0

- Bryan

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Bryan Andersen]

This looks similar to what I complained about in "PDC292XX DMA
loss in 2.4.21-pre3-ac4".  I can reproduce my problem but it only 
happens randomly under heavy load.  I have to load down accesses
to both disks (each on their own channel as master) on the
controller.  The same task running on only one of the disks sees
no problems.

    http://www.ussg.iu.edu/hypermail/linux/kernel/0301.3/0239.html

The only differnce now is I have seen it on both disks on the
PDC29269.  I have one disk on each channel.  I've ruled out problems 
with the hardware.  I'm now using different cables and a differnt 
PDC29269 controller.

This is from earlier today.

Feb  5 10:57:11 blip kernel: hdg: dma_intr: status=0xd0 { Busy }
Feb  5 10:57:11 blip kernel:
Feb  5 10:57:11 blip kernel: hdg: DMA disabled
Feb  5 10:57:11 blip kernel: PDC202XX: Secondary channel reset.
Feb  5 10:57:11 blip kernel: ide3: reset: success

This one is recent after the reboot after the one above.

Feb  5 13:22:42 blip kernel: hde: dma_intr: status=0xd0 { Busy }
Feb  5 13:22:42 blip kernel:
Feb  5 13:22:42 blip kernel: hde: DMA disabled
Feb  5 13:22:42 blip kernel: PDC202XX: Primary channel reset.
Feb  5 13:22:43 blip kernel: ide2: reset: success

It happened after about 12 minutes run time on the script below.

#!/bin/bash
mount1=/data5 # {mount point of disk one}
mount2=/data6 # {mount point of disk two}
mount3=/usr   # Further load to use up DMA channel time

(while(true)
do
    find /$mount1 -type f -print | xargs wc
done > /dev/null) &
(while(true)
do
    find /$mount2 -type f -print | xargs wc
done > /dev/null) &
(while(true)
do
    find /$mount3 -type f -print | xargs wc
done > /dev/null) &
wait

exit 0


I haven't looked at the code yet, but it comes to mind what
happens when one has run out of DMA channels or interrupts
to service requests?  My system has both the PDC29269 channels
on a shared interrupt with the a couple of other devices.  My
motherboard is a ASUS A7N8X with the nForce2 chipset.

- Bryan

Robbert Kouprie wrote:
 > Benjamin Herrenschmidt wrote:
 >
 >
 >>>Feb 4 01:02:22 admin kernel: hde: dma_intr: status=0xd0 { Busy }
 >>>Feb 4 01:02:22 admin kernel:
 >>>Feb 4 01:02:22 admin kernel: PDC202XX: Primary channel reset.
 >>>Feb 4 01:02:22 admin kernel: ide2: reset: success
 >>>Feb 4 01:02:23 admin kernel: hde: status error: status=0x58 { DriveReady
 >>
 > SeekComplete DataRequest }
 >
 >>>Feb 4 01:02:23 admin kernel:
 >>>Feb 4 01:02:23 admin kernel: hde: drive not ready for command
 >>>Feb 4 01:02:23 admin kernel: hde: status error: status=0x50 { DriveReady
 >>
 > SeekComplete }
 >
 >>>Feb 4 01:02:23 admin kernel:
 >>>Feb 4 01:02:23 admin kernel: hde: no DRQ after issuing WRITE
 >>>Feb 4 01:02:23 admin kernel: hde: status timeout: status=0xd0 { Busy }
 >>>Feb 4 01:02:23 admin kernel:
 >>
 >>Hi Alan !
 >>
 >>I'm trying to get some sense out of the above report as it seem to match
 >>a problem a user reported me as well. It's interesting because it's
 >>apparently running UP, so it's not the SMP race found by Ross. It's
 >>definitely a problem with shared interrupt though.
 >
 >
 > Hi all,
 >
 > I experience a similar problem too on UP (and UP kernel, no preempt, no
 > taskfile, no acpi). Having replaced almost all hardware involved, I'm 99%
 > sure it isn't a hardware problem. I reported to Alan & Andre privately at
 > the time, but unfortunately there was no way to reproduce it, so nothing
 > came out of it. Also there have been a few threads where it looks like
 > people report the same problem.
 >
 > Like:
 > http://www.uwsg.indiana.edu/hypermail/linux/kernel/0210.3/0416.html (2nd
 > paragraph)
 > http://www.uwsg.indiana.edu/hypermail/linux/kernel/0301.1/0547.html
 > (replacing the cable actually _didn't_ fix it in the end)
 >
 > System is a PIII-866 on an Asus board, WD1800JB 180Gb on pri master
 > (UDMA100), WD1200BB 120Gb sec master (UDMA100) on an Promise PDC20269 PCI
 > card, kernel 2.4.20-rc1-ac4 (yes it's an older one, but testing is 
hard, as
 > it sometimes takes a month for the problem to show up again).
 >
 > In a shared interrupt setup (i.e. 2 disks on each channel of the 
PDC), the
 > machine will just crash in unpredictable ways, without leaving 
traces. With
 > only the 180Gb drive on the PDC, there's no interrupt sharing, and the
 > system is able to stay alive when the error happens, it's just the 
disk that
 > drops dead in that case. Box has to be powered off (resetting doesn't 
help)
 > for the drive to get alive again. The logs say:
 >
 > Nov  1 08:24:14 Bambi kernel: hde: dma_timer_expiry: dma status == 0x21
 > Nov  1 08:24:24 Bambi kernel: PDC202XX: Primary channel reset.
 > Nov  1 08:24:24 Bambi kernel: hde: timeout waiting for DMA
 > Nov  1 08:24:24 Bambi kernel: hde: (__ide_dma_test_irq) called while not
 > waiting
 > Nov  1 08:24:24 Bambi kernel: blk: queue c02d5e58, I/O limit 4095Mb (mask
 > 0xffffffff)
 > Nov  1 08:24:34 Bambi kernel: hde: irq timeout: status=0xd0 { Busy }
 > Nov  1 08:24:34 Bambi kernel:
 > Nov  1 08:24:34 Bambi kernel: hde: DMA disabled
 > Nov  1 08:24:34 Bambi kernel: PDC202XX: Primary channel reset.
 > Nov  1 08:25:04 Bambi kernel: ide2: reset timed-out, status=0xd0
 > Nov  1 08:25:04 Bambi kernel: hde: status timeout: status=0xd0 { Busy }
 > Nov  1 08:25:04 Bambi kernel:
 > Nov  1 08:25:04 Bambi kernel: PDC202XX: Primary channel reset.
 > Nov  1 08:25:34 Bambi kernel: ide2: reset timed-out, status=0xd0
 >
 > A few times I tried to reset the drive with hdparm using "hdparm -w
 > /dev/hde". This didn't have success and produced the following log 
messages:
 >
 > Nov  1 12:02:57 Bambi kernel: hde: DMA disabled
 > Nov  1 12:02:57 Bambi kernel: PDC202XX: Primary channel reset.
 > Nov  1 12:02:57 Bambi kernel: hde: ide_timer_expiry: hwgroup->busy 
was 0 ??
 > Nov  1 12:03:27 Bambi kernel: ide2: reset timed-out, status=0xd0
 >
 > Does anyone have any theory of how to reproduce this (maybe with the new
 > theory of Benjamin)? I would be glad to test new kernels, but some 
testcase
 > is required to be able to supply more results (within a reasonable 
amount of
 > time that is ;)).
 >
 > Below all specs in the shared irq setup, 2 drives on the 20269, one 
on each
 > channel. (In the non-shared setup, I moved the WD 120Gb to an extra
 > PDC20262, no interrupts were shared.)
 >
 > Regards,
 > - Robbert Kouprie
 >

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Alan Cox]

On Wed, 2003-02-05 at 17:19, Ross Biro wrote:
> I've actually had a manufacturer tell me that they don't worry about the 
> spec, just making things work with Windows.

Its very common. As a customer always ask the vendor if they are 
compliant to each appropriate standard in writing. If they say yes it
has nice little liability issues should they be lying 8)

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Stephan von Krawczynski]

On 05 Feb 2003 18:44:51 +0100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Wed, 2003-02-05 at 18:38, Stephan von Krawczynski wrote:
> > On 05 Feb 2003 18:34:55 +0100
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > 
> > > On Wed, 2003-02-05 at 18:19, Ross Biro wrote:
> > > > Benjamin Herrenschmidt wrote:
> > > > 
> > > > >While I agree with you here, I don't think it's what's happening.
> > > > >	/* clear INTR & ERROR flags */
> > > > >	hwif->OUTB(dma_stat|6, hwif->dma_status);
> > > > >
> > > > >  
> > > > >
> > > > You have way to much faith in the hardware.  Promise is especially
> > > > known for not keeping to the spec.  I wouldn't trust the interrupt bit
> > > > to be valid unless a dma is actually active, i.e. that
> > > > 
> > > >                   hwif->OUTB(hwif->INB(dma_base)|1, dma_base);
> > > > 
> > > > has actually been written.  
> > > > 
> > > > I've actually had a manufacturer tell me that they don't worry about
> > > > the spec, just making things work with Windows.
> > > 
> > > Ok, so that gives us 2 possibilities. The above problem, which would be
> > > fixed by locking all around ide_dma_read/write (or rather in the
> > > _caller_, seems better so we don't have to drop the lock for ATAPI).
> > > 
> > > And a possible wraparound of waiting_for_dma if 255 IRQs come in from
> > > whatever device we share the IRQ line with.
> > > 
> > > I beleive both need fixing...
> > > 
> > > Ben.
> > 
> > Ok, yet another small brick in the wall: this mb has 64bit/66MHz PCI slots.
> > PDC is only 32bit/33MHz PCI. So it may well be that others are in fact
> > _able_ to produce a damn lot more data/interrupts than the PDC. I am pretty
> > astonished by the number of interrupts created by the 3com tg3 cards
> > anyways...
> 
> Ok, then please try my "fix" to remove the increment of waiting_for_dma
> and let us know if it helps.

I will try, in the meantime can any kind soul please give me a hint why I
cannot see the interrupts distributed among the CPUs when enabling smp and
apic on this very same box:

           CPU0       CPU1       
  0:      71158          0    IO-APIC-edge  timer
  1:        941          0    IO-APIC-edge  keyboard
  2:          0          0          XT-PIC  cascade
 12:      33166          0    IO-APIC-edge  PS/2 Mouse
 15:          4          0    IO-APIC-edge  ide1
 17:       1732          0   IO-APIC-level  ide2, ide3
 18:       3423          0   IO-APIC-level  eth0, eth1
 21:       8177          0   IO-APIC-level  eth2
 22:     112943          0   IO-APIC-level  aic7xxx
 23:         16          0   IO-APIC-level  aic7xxx
 25:         74          0   IO-APIC-level  HiSax
 26:          0          0   IO-APIC-level  EMU10K1
NMI:          0          0 
LOC:      71085      71059 
ERR:          0
MIS:          0

??
(kernel 2.4.21-pre4)
-- 
Regards,
Stephan

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Stephan von Krawczynski]

On 05 Feb 2003 18:34:55 +0100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Wed, 2003-02-05 at 18:19, Ross Biro wrote:
> > Benjamin Herrenschmidt wrote:
> > 
> > >While I agree with you here, I don't think it's what's happening.
> > >	/* clear INTR & ERROR flags */
> > >	hwif->OUTB(dma_stat|6, hwif->dma_status);
> > >
> > >  
> > >
> > You have way to much faith in the hardware.  Promise is especially known 
> > for not keeping to the spec.  I wouldn't trust the interrupt bit to be 
> > valid unless a dma is actually active, i.e. that
> > 
> >                   hwif->OUTB(hwif->INB(dma_base)|1, dma_base);
> > 
> > has actually been written.  
> > 
> > I've actually had a manufacturer tell me that they don't worry about the 
> > spec, just making things work with Windows.
> 
> Ok, so that gives us 2 possibilities. The above problem, which would be
> fixed by locking all around ide_dma_read/write (or rather in the
> _caller_, seems better so we don't have to drop the lock for ATAPI).
> 
> And a possible wraparound of waiting_for_dma if 255 IRQs come in from
> whatever device we share the IRQ line with.
> 
> I beleive both need fixing...
> 
> Ben.

Ok, yet another small brick in the wall: this mb has 64bit/66MHz PCI slots. PDC
is only 32bit/33MHz PCI. So it may well be that others are in fact _able_ to
produce a damn lot more data/interrupts than the PDC. I am pretty astonished by
the number of interrupts created by the 3com tg3 cards anyways...

-- 
Regards,
Stephan

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Benjamin Herrenschmidt]

On Wed, 2003-02-05 at 18:19, Ross Biro wrote:
> Benjamin Herrenschmidt wrote:
> 
> >While I agree with you here, I don't think it's what's happening.
> >	/* clear INTR & ERROR flags */
> >	hwif->OUTB(dma_stat|6, hwif->dma_status);
> >
> >  
> >
> You have way to much faith in the hardware.  Promise is especially known 
> for not keeping to the spec.  I wouldn't trust the interrupt bit to be 
> valid unless a dma is actually active, i.e. that
> 
>                   hwif->OUTB(hwif->INB(dma_base)|1, dma_base);
> 
> has actually been written.  
> 
> I've actually had a manufacturer tell me that they don't worry about the 
> spec, just making things work with Windows.

Ok, so that gives us 2 possibilities. The above problem, which would be
fixed by locking all around ide_dma_read/write (or rather in the
_caller_, seems better so we don't have to drop the lock for ATAPI).

And a possible wraparound of waiting_for_dma if 255 IRQs come in from
whatever device we share the IRQ line with.

I beleive both need fixing...

Ben.

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Ross Biro]

Benjamin Herrenschmidt wrote:

>While I agree with you here, I don't think it's what's happening.
>	/* clear INTR & ERROR flags */
>	hwif->OUTB(dma_stat|6, hwif->dma_status);
>
>  
>
You have way to much faith in the hardware.  Promise is especially known 
for not keeping to the spec.  I wouldn't trust the interrupt bit to be 
valid unless a dma is actually active, i.e. that

                  hwif->OUTB(hwif->INB(dma_base)|1, dma_base);

has actually been written.  

I've actually had a manufacturer tell me that they don't worry about the 
spec, just making things work with Windows.

    Ross

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Benjamin Herrenschmidt]

On Wed, 2003-02-05 at 17:56, Ross Biro wrote:
> Benjamin Herrenschmidt wrote:
> 
> >>Okay, I had to watch for it a bit longer and it turns out that the kernel PDC driver has a problem in this shared interrupt setup. When loads get high it seems to run into some timing problem which causes things like:
> >>
> >>Feb  4 01:02:22 admin kernel: hde: dma_intr: status=0xd0 { Busy }
> >>
> >>    
> >>
> Since the busy bit is set, we know the drive must have received a 
> command.  Since dma_intr thought the drive was not busy, an interrupt 
> must have snuck through between the command being issued and the dma 
> being started.  I think in my original patch, I had the dma start 
> outside of the spinlock, that is a bug.  The command to the controller 
> to start the dma must be inside of the spinlock.

While I agree with you here, I don't think it's what's happening.

In ide-disk, do_rw_disk sets up the taskfile, then basically calls
hwif->ide_dma_read/write to start the command.

In ide-dma.c in 2.4.21-pre4, what happens is:

	/* PRD table */
	hwif->OUTL(hwif->dmatable_dma, hwif->dma_prdtable);
	/* specify r/w */
	hwif->OUTB(reading, hwif->dma_command);
	/* read dma_status for INTR & ERROR flags */
	dma_stat = hwif->INB(hwif->dma_status);
	/* clear INTR & ERROR flags */
	hwif->OUTB(dma_stat|6, hwif->dma_status);
	drive->waiting_for_dma = 1;
	if (drive->media != ide_disk)
		return 0;
        .../...
        Then issue command byte.

Below we clear the DMA status _and_ set waiting_for_dma to 1.
That means that if an IRQ sneaks in, we will call
drive_is_ready(), which shouldn't return INTR 1 since we
just cleared it. I don't see how a race could happen here,
but I might have missed something.

Even if, on SMP, the code below executes _simultaneously_
with ide_intr, the later will check for handler beeing
non-NULL before checking waiting_for_dma (drive_is_ready),
and thus will not race since we set the handler after.

The only thing I see is a possible wraparound of
waiting_for_dma. It's an u8, so it wraps at 255. However,
it's incremented in each __ide_dma_test_irq call. So if you
get more than 255 shared (network in your case) interrupts
before the end of the command, you die.

Alan: you can remove safely the waiting_for_dma++, I beleive,
in drive_is_ready(). I don't know how that code sneaked in
ide-dma. I indeed do that in ppc/pmac.c for other reasons
(sort of timeout condition on the DMA controller that happens
when I get an initial error), but this is totally unrelated
HW on which I know I have no shared IRQ.
   
Stephan: Can you try editing ide-dma.c, function
__ide_dma_test_irq(), and remove that line:

-	drive->waiting_for_dma++;

And tell us if it helps in any way.

Ben.

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Ross Biro]

Benjamin Herrenschmidt wrote:

>>Okay, I had to watch for it a bit longer and it turns out that the kernel PDC driver has a problem in this shared interrupt setup. When loads get high it seems to run into some timing problem which causes things like:
>>
>>Feb  4 01:02:22 admin kernel: hde: dma_intr: status=0xd0 { Busy }
>>
>>    
>>
Since the busy bit is set, we know the drive must have received a 
command.  Since dma_intr thought the drive was not busy, an interrupt 
must have snuck through between the command being issued and the dma 
being started.  I think in my original patch, I had the dma start 
outside of the spinlock, that is a bug.  The command to the controller 
to start the dma must be inside of the spinlock.

I have not looked at 2.4.21-pre4 at all, so I could be entirely off base 
here.

    Ross

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Robbert Kouprie]

Benjamin Herrenschmidt wrote:

> > Feb 4 01:02:22 admin kernel: hde: dma_intr: status=0xd0 { Busy } 
> > Feb 4 01:02:22 admin kernel: 
> > Feb 4 01:02:22 admin kernel: PDC202XX: Primary channel reset. 
> > Feb 4 01:02:22 admin kernel: ide2: reset: success 
> > Feb 4 01:02:23 admin kernel: hde: status error: status=0x58 { DriveReady
SeekComplete DataRequest } 
> > Feb 4 01:02:23 admin kernel: 
> > Feb 4 01:02:23 admin kernel: hde: drive not ready for command 
> > Feb 4 01:02:23 admin kernel: hde: status error: status=0x50 { DriveReady
SeekComplete } 
> > Feb 4 01:02:23 admin kernel: 
> > Feb 4 01:02:23 admin kernel: hde: no DRQ after issuing WRITE 
> > Feb 4 01:02:23 admin kernel: hde: status timeout: status=0xd0 { Busy } 
> > Feb 4 01:02:23 admin kernel: 
>
> Hi Alan ! 
>
> I'm trying to get some sense out of the above report as it seem to match 
> a problem a user reported me as well. It's interesting because it's 
> apparently running UP, so it's not the SMP race found by Ross. It's 
> definitely a problem with shared interrupt though. 

Hi all,

I experience a similar problem too on UP (and UP kernel, no preempt, no
taskfile, no acpi). Having replaced almost all hardware involved, I'm 99%
sure it isn't a hardware problem. I reported to Alan & Andre privately at
the time, but unfortunately there was no way to reproduce it, so nothing
came out of it. Also there have been a few threads where it looks like
people report the same problem.

Like:
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0210.3/0416.html (2nd
paragraph)
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0301.1/0547.html
(replacing the cable actually _didn't_ fix it in the end)

System is a PIII-866 on an Asus board, WD1800JB 180Gb on pri master
(UDMA100), WD1200BB 120Gb sec master (UDMA100) on an Promise PDC20269 PCI
card, kernel 2.4.20-rc1-ac4 (yes it's an older one, but testing is hard, as
it sometimes takes a month for the problem to show up again).

In a shared interrupt setup (i.e. 2 disks on each channel of the PDC), the
machine will just crash in unpredictable ways, without leaving traces. With
only the 180Gb drive on the PDC, there's no interrupt sharing, and the
system is able to stay alive when the error happens, it's just the disk that
drops dead in that case. Box has to be powered off (resetting doesn't help)
for the drive to get alive again. The logs say:

Nov  1 08:24:14 Bambi kernel: hde: dma_timer_expiry: dma status == 0x21
Nov  1 08:24:24 Bambi kernel: PDC202XX: Primary channel reset.
Nov  1 08:24:24 Bambi kernel: hde: timeout waiting for DMA
Nov  1 08:24:24 Bambi kernel: hde: (__ide_dma_test_irq) called while not
waiting
Nov  1 08:24:24 Bambi kernel: blk: queue c02d5e58, I/O limit 4095Mb (mask
0xffffffff)
Nov  1 08:24:34 Bambi kernel: hde: irq timeout: status=0xd0 { Busy }
Nov  1 08:24:34 Bambi kernel: 
Nov  1 08:24:34 Bambi kernel: hde: DMA disabled
Nov  1 08:24:34 Bambi kernel: PDC202XX: Primary channel reset.
Nov  1 08:25:04 Bambi kernel: ide2: reset timed-out, status=0xd0
Nov  1 08:25:04 Bambi kernel: hde: status timeout: status=0xd0 { Busy }
Nov  1 08:25:04 Bambi kernel: 
Nov  1 08:25:04 Bambi kernel: PDC202XX: Primary channel reset.
Nov  1 08:25:34 Bambi kernel: ide2: reset timed-out, status=0xd0

A few times I tried to reset the drive with hdparm using "hdparm -w
/dev/hde". This didn't have success and produced the following log messages:

Nov  1 12:02:57 Bambi kernel: hde: DMA disabled
Nov  1 12:02:57 Bambi kernel: PDC202XX: Primary channel reset.
Nov  1 12:02:57 Bambi kernel: hde: ide_timer_expiry: hwgroup->busy was 0 ??
Nov  1 12:03:27 Bambi kernel: ide2: reset timed-out, status=0xd0

Does anyone have any theory of how to reproduce this (maybe with the new
theory of Benjamin)? I would be glad to test new kernels, but some testcase
is required to be able to supply more results (within a reasonable amount of
time that is ;)).

Below all specs in the shared irq setup, 2 drives on the 20269, one on each
channel. (In the non-shared setup, I moved the WD 120Gb to an extra
PDC20262, no interrupts were shared.)

Regards,
- Robbert Kouprie


System specs:
-------------
CUSL2-C BIOS 1009 (also tried 1008)
PIII 866 (also tried a PIII-800)
Promise Ultra133TX2 (PDC20269) BIOS 2.20.0.14 (also tried 2.20.0.12)
1x Maxtor 30GB 7200RPM on ICH2, Primary Master, UDM100
1x Maxtor 80GB 7200RPM on ICH2, Secondary Master, UDMA100 (also tried this
one as Quarternary Slave)
1x WD 180GB 7200RPM on Promise Ultra133, Primary [Tertiary] Master UDMA 100
(RMA'd the first one, second one makes no difference)
1x WD 120GB 7200RPM on Promise Ultra133, secondary [Quarternary] Master
UDMA100
Ultra133 on PCI slot #1
Intel eepro100 on PCI slot #3 (also tried a 3com 3C905B-TX)
S3 Virge on PCI slot #5
1x256MB PC133, 2x128MB PC133 (memtested for a full night, tried in different
combinations, locations)
A-Open 300W PSU (also tried with an Enermax 430W)

NOTE: All the things mentioned as "also tried" didn't make it stop crashing.

cat /proc/interrupts:
---------------------
           CPU0       
  0:      77362          XT-PIC  timer
  1:          2          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  4:      74310          XT-PIC  eth0
 12:     146397          XT-PIC  ide2, ide3
 14:      15335          XT-PIC  ide0
 15:         35          XT-PIC  ide1
NMI:          0 
LOC:      77319 
ERR:          0
MIS:          0

lspci -vvvx:
------------
00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and
Memory Controller Hub (rev 02)
        Subsystem: Asustek Computer, Inc. TUSL2-C Mainboard
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
        Latency: 0
        Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
        Capabilities: [88] #09 [f104]
        Capabilities: [a0] AGP version 2.0
                Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
                Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
00: 86 80 30 11 06 00 90 20 02 00 00 06 00 00 00 00
10: 08 00 00 f8 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 27 80
30: 00 00 00 00 88 00 00 00 00 00 00 00 00 00 00 00

00:01.0 PCI bridge: Intel Corp. 82815 815 Chipset AGP Bridge (rev 02)

(prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        I/O behind bridge: 0000e000-0000dfff
        Memory behind bridge: f7b00000-f7bfffff
        Prefetchable memory behind bridge: f7f00000-f7ffffff
        BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
00: 86 80 31 11 07 00 20 00 02 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 e0 d0 a0 22
20: b0 f7 b0 f7 f0 f7 f0 f7 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 01)

(prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
        I/O behind bridge: 0000b000-0000dfff
        Memory behind bridge: f0000000-f7afffff
        Prefetchable memory behind bridge: f7c00000-f7efffff
        BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- >Reset- FastB2B-
00: 86 80 4e 24 07 01 80 00 01 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 02 02 20 b0 d0 80 22
20: 00 f0 a0 f7 c0 f7 e0 f7 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0e 00

00:1f.0 ISA bridge: Intel Corp. 82801BA ISA Bridge (LPC) (rev 01)

        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
00: 86 80 40 24 0f 01 80 02 01 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:1f.1 IDE interface: Intel Corp. 82801BA IDE U100 (rev 01) (prog-if 80

[Master])
        Subsystem: Asustek Computer, Inc. TUSL2-C Mainboard
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Region 4: I/O ports at a800 [size=16]
00: 86 80 4b 24 05 00 80 02 01 80 01 01 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 a8 00 00 00 00 00 00 00 00 00 00 43 10 27 80
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:1f.3 SMBus: Intel Corp. 82801BA/BAM SMBus (rev 01)

        Subsystem: Asustek Computer, Inc. TUSL2-C Mainboard
        Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin B routed to IRQ 11
        Region 4: I/O ports at e800 [size=16]
00: 86 80 43 24 01 00 80 02 01 00 05 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 e8 00 00 00 00 00 00 00 00 00 00 43 10 27 80
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 02 00 00

02:09.0 Unknown mass storage controller: Promise Technology, Inc. 20269

(rev 02) (prog-if 85)
        Subsystem: Promise Technology, Inc.: Unknown device 4d68
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (1000ns min, 4500ns max), cache line size 08
        Interrupt: pin A routed to IRQ 4
        Region 0: I/O ports at d800 [size=8]
        Region 1: I/O ports at d400 [size=4]
        Region 2: I/O ports at d000 [size=8]
        Region 3: I/O ports at b800 [size=4]
        Region 4: I/O ports at b400 [size=16]
        Region 5: Memory at f7000000 (32-bit, non-prefetchable)
[size=16K]
        Expansion ROM at <unassigned> [disabled] [size=16K]
        Capabilities: [60] Power Management version 1
                Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 5a 10 69 4d 07 00 30 04 02 85 80 01 08 20 00 00
10: 01 d8 00 00 01 d4 00 00 01 d0 00 00 01 b8 00 00
20: 01 b4 00 00 00 00 00 f7 00 00 00 00 5a 10 68 4d
30: 00 00 00 00 60 00 00 00 00 00 00 00 04 01 04 12

02:0b.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100]

(rev 09)
        Subsystem: Intel Corp. EtherExpress PRO/100 S Management Adapter
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (2000ns min, 14000ns max), cache line size 08
        Interrupt: pin A routed to IRQ 3
        Region 0: Memory at f6800000 (32-bit, non-prefetchable)
[size=4K]
        Region 1: I/O ports at b000 [size=64]
        Region 2: Memory at f6000000 (32-bit, non-prefetchable)
[size=128K]
        Expansion ROM at <unassigned> [disabled] [size=1M]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-
00: 86 80 29 12 17 00 90 02 09 00 00 02 08 20 00 00
10: 00 00 80 f6 01 b0 00 00 00 00 00 f6 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 11 00
30: 00 00 00 00 dc 00 00 00 00 00 00 00 03 01 08 38

02:0e.0 VGA compatible controller: S3 Inc. 86c325 [ViRGE] (rev 06)

(prog-if 00 [VGA])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (1000ns min, 63750ns max)
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at f0000000 (32-bit, non-prefetchable)
[size=64M]
        Expansion ROM at f7cf0000 [disabled] [size=64K]
00: 33 53 31 56 07 00 00 02 06 00 00 03 00 20 00 00
10: 00 00 00 f0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 cf f7 00 00 00 00 00 00 00 00 0a 01 04 ff

------
Linux version 2.4.20-pre10-ac2 (root@Bambi) (gcc version 2.95.4 20011002
(Debian prerelease)) #1 Tue Oct 29 16:04:06 CET 2002
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009e800 (usable)
 BIOS-e820: 000000000009e800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 0000000017feb000 (usable)
 BIOS-e820: 0000000017feb000 - 0000000017fef000 (ACPI data)
 BIOS-e820: 0000000017fef000 - 0000000017fff000 (reserved)
 BIOS-e820: 0000000017fff000 - 0000000018000000 (ACPI NVS)
 BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
383MB LOWMEM available.
On node 0 totalpages: 98283
zone(0): 4096 pages.
zone(1): 94187 pages.
zone(2): 0 pages.
Kernel command line: auto BOOT_IMAGE=Linux ro root=301 ide2=ata66 ide3=ata66
ide_setup: ide2=ata66
ide_setup: ide3=ata66
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Initializing CPU#0
Detected 871.032 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1736.70 BogoMIPS
Memory: 383624k/393132k available (1109k kernel code, 6940k reserved, 336k
data, 248k init, 0k highmem)
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode cache hash table entries: 32768 (order: 6, 262144 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
ramfs: mounted with options: <defaults>
ramfs: max_pages=48225 max_file_pages=0 max_inodes=0 max_dentries=48225
Buffer cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: 0383fbff 00000000 00000000 00000000
CPU:             Common caps: 0383fbff 00000000 00000000 00000000
CPU: Intel Pentium III (Coppermine) stepping 0a
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 871.0616 MHz.
..... host bus clock speed is 134.0092 MHz.
cpu: 0, clocks: 1340092, slice: 670046
CPU0<T0:1340080,T1:670032,D:2,S:670046,C:1340092>
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xf0df0, last bus=2
PCI: Using configuration type 1
PCI: Probing PCI hardware
Scanning bus 00
Found 00:00 [8086/1130] 000600 00
Found 00:08 [8086/1131] 000604 01
Found 00:f0 [8086/244e] 000604 01
Found 00:f8 [8086/2440] 000601 00
Found 00:f9 [8086/244b] 000101 00
Found 00:fb [8086/2443] 000c05 00
Fixups for bus 00
Scanning behind PCI bridge 00:01.0, config 010100, pass 0
Scanning bus 01
Fixups for bus 01
Bus scan for 01 returning with max=01
Scanning behind PCI bridge 00:1e.0, config 020200, pass 0
Scanning bus 02
Found 02:48 [105a/4d69] 000180 00
Found 02:58 [8086/1229] 000200 00
Found 02:68 [5333/5631] 000300 00
Fixups for bus 02
Transparent bridge - Intel Corp. 82801BA/CA/DB PCI Bridge
Bus scan for 02 returning with max=02
Scanning behind PCI bridge 00:01.0, config 010100, pass 1
Scanning behind PCI bridge 00:1e.0, config 020200, pass 1
Bus scan for 00 returning with max=02
PCI: Bus 01 already known
PCI: Bus 02 already known
PCI: Using IRQ router PIIX [8086/2440] at 00:1f.0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
IA-32 Microcode Update Driver: v1.11 <tigran@veritas.com>
Starting kswapd
Journalled Block Device driver loaded
NTFS driver v1.1.22 [Flags: R/O]
i2c-core.o: i2c core module
i2c-dev.o: i2c /dev entries driver module
i2c-core.o: driver i2c-dev dummy driver registered.
i2c-proc.o version 2.6.1 (20010825)
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
i810 TCO timer, v0.05: timer margin: 30 sec (0xe460) (nowayout=0)
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Intel(R) PRO/100 Network Driver - version 2.1.15-k1
Copyright (c) 2002 Intel Corporation

PCI: Found IRQ 4 for device 02:0b.0
e100: eth0: Intel(R) PRO/100 S Management Adapter
  Mem:0xf6800000  IRQ:4  Speed:0 Mbps  Dx:N/A
  Failed to detect cable link
  Speed and duplex will be determined at time of connection
  Hardware receive checksums enabled
  cpu cycle saver enabled

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH2: IDE controller at PCI slot 00:1f.1
ICH2: chipset revision 1
ICH2: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xa800-0xa807, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xa808-0xa80f, BIOS settings: hdc:DMA, hdd:pio
PDC20269: IDE controller at PCI slot 02:09.0
PCI: Found IRQ 12 for device 02:09.0
PCI: Sharing IRQ 12 with 02:0d.0
PDC20269: chipset revision 2
PDC20269: not 100% native mode: will probe irqs later
    ide2: BM-DMA at 0xb400-0xb407, BIOS settings: hde:pio, hdf:pio
    ide3: BM-DMA at 0xb408-0xb40f, BIOS settings: hdg:pio, hdh:pio
hda: Maxtor 6E030L0, ATA DISK drive
blk: queue c02d5580, I/O limit 4095Mb (mask 0xffffffff)
hdc: Maxtor 4D080H4, ATA DISK drive
blk: queue c02d59ec, I/O limit 4095Mb (mask 0xffffffff)
hde: WDC WD1800JB-00DUA0, ATA DISK drive
blk: queue c02d5e58, I/O limit 4095Mb (mask 0xffffffff)
hdg: WDC WD1200BB-00CAA0, ATA DISK drive
blk: queue c02d62c4, I/O limit 4095Mb (mask 0xffffffff)
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0xd800-0xd807,0xd402 on irq 12
ide3 at 0xd000-0xd007,0xb802 on irq 12
hda: host protected area => 1
hda: 60058656 sectors (30750 MB) w/2048KiB Cache, CHS=3738/255/63, UDMA(100)
hdc: host protected area => 1
hdc: 160086528 sectors (81964 MB) w/2048KiB Cache, CHS=158816/16/63,
UDMA(100)
hde: host protected area => 1
hde: 351651888 sectors (180046 MB) w/8192KiB Cache, CHS=21889/255/63,
UDMA(100)
hdg: host protected area => 1
hdg: 234441648 sectors (120034 MB) w/2048KiB Cache, CHS=232581/16/63,
UDMA(100)
Partition check:
 hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
 hdc: hdc1
 hde: hde1
 hdg: hdg1
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 32768)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 248k freed
Adding Swap: 1461872k swap-space (priority -1)
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,1), internal journal
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,3), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,6), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide1(22,1), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide2(33,1), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide3(34,1), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
e100: eth0 NIC Link is Up 100 Mbps Full duplex

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Stephan von Krawczynski]

On 05 Feb 2003 13:22:19 +0100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> 
> > I have to give a short note on this one:
> > indeed is the system currently running with a single CPU, _but_ since it is a
> > dual-mb the kernel is already compiled for SMP. It is started with "nosmp"
> > option though. I wanted to mention this not knowing if it is important for the
> > codepath.
> 
> Shouldn be an issue. I suppose you don't use fancy stuff like preempt or
> IDE taskfile IO, right ?

No, not at all. Pure and simple filesystem-I/O (reiserfs).

-- 
Regards,
Stephan

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Alan Cox]

> > dual-mb the kernel is already compiled for SMP. It is started with "nosmp"
> > option though. I wanted to mention this not knowing if it is important for the
> > codepath.
> 
> Shouldn be an issue. I suppose you don't use fancy stuff like preempt or
> IDE taskfile IO, right ?

IDE taskfile I/O is disabled. Pre-empt and 2.4 IDE don't work together at
all yet, and probably never will (see the /proc code for why its basically
unfixable in 2.4)

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Alan Cox]

> ide_dma_intr() called while the drive was busy. This is strange for a
> simple reason: Even if we got the wrong interrupt (shared interrupt),
> __ide_dma_test_irq() should have returned 0, and so ide_dma_intr
> shouldn't have been called.

Ok the other mail makes more sense now 8)

> drive->waiting_for_dma is set before setting up the handler and
> issuing the command, and while the DMA engine is indeed started
> only after sending the command, it's INTR bit have been cleared
> previously (I suppose it can't be stale, or can it while the DMA
> haven't been started yet ? In this case we would need to take
> the lock here).

I'd have to go digging. I think that can occur however.

Andre ?

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Benjamin Herrenschmidt]

> I have to give a short note on this one:
> indeed is the system currently running with a single CPU, _but_ since it is a
> dual-mb the kernel is already compiled for SMP. It is started with "nosmp"
> option though. I wanted to mention this not knowing if it is important for the
> codepath.

Shouldn be an issue. I suppose you don't use fancy stuff like preempt or
IDE taskfile IO, right ?

Ben.

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Alan Cox]

> > a problem a user reported me as well. It's interesting because it's
> > apparently running UP, so it's not the SMP race found by Ross. It's
> > definitely a problem with shared interrupt though.

The race Ross found can bite you on a uniprocessor box as well I think.
It just needs the irq to hit in the right spot. The more interesting 
question is how the current -ac behaves under the same treatment

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Stephan von Krawczynski]

On 05 Feb 2003 12:16:02 +0100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> 
> > Okay, I had to watch for it a bit longer and it turns out that the kernel
> > PDC driver has a problem in this shared interrupt setup. When loads get
> > high it seems to run into some timing problem which causes things like:
> > 
> > Feb  4 01:02:22 admin kernel: hde: dma_intr: status=0xd0 { Busy }
> > Feb  4 01:02:22 admin kernel: 
> > Feb  4 01:02:22 admin kernel: PDC202XX: Primary channel reset.
> > Feb  4 01:02:22 admin kernel: ide2: reset: success
> > Feb  4 01:02:23 admin kernel: hde: status error: status=0x58 { DriveReady
> > SeekComplete DataRequest } Feb  4 01:02:23 admin kernel: 
> > Feb  4 01:02:23 admin kernel: hde: drive not ready for command
> > Feb  4 01:02:23 admin kernel: hde: status error: status=0x50 { DriveReady
> > SeekComplete } Feb  4 01:02:23 admin kernel: 
> > Feb  4 01:02:23 admin kernel: hde: no DRQ after issuing WRITE
> > Feb  4 01:02:23 admin kernel: hde: status timeout: status=0xd0 { Busy }
> > Feb  4 01:02:23 admin kernel: 
> 
> Hi Alan !
> 
> I'm trying to get some sense out of the above report as it seem to match
> a problem a user reported me as well. It's interesting because it's
> apparently running UP, so it's not the SMP race found by Ross. It's
> definitely a problem with shared interrupt though.

Hello Benjamin,

I have to give a short note on this one:
indeed is the system currently running with a single CPU, _but_ since it is a
dual-mb the kernel is already compiled for SMP. It is started with "nosmp"
option though. I wanted to mention this not knowing if it is important for the
codepath.

-- 
Regards,
Stephan

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Benjamin Herrenschmidt]

> Okay, I had to watch for it a bit longer and it turns out that the kernel PDC driver has a problem in this shared interrupt setup. When loads get high it seems to run into some timing problem which causes things like:
> 
> Feb  4 01:02:22 admin kernel: hde: dma_intr: status=0xd0 { Busy }
> Feb  4 01:02:22 admin kernel: 
> Feb  4 01:02:22 admin kernel: PDC202XX: Primary channel reset.
> Feb  4 01:02:22 admin kernel: ide2: reset: success
> Feb  4 01:02:23 admin kernel: hde: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> Feb  4 01:02:23 admin kernel: 
> Feb  4 01:02:23 admin kernel: hde: drive not ready for command
> Feb  4 01:02:23 admin kernel: hde: status error: status=0x50 { DriveReady SeekComplete }
> Feb  4 01:02:23 admin kernel: 
> Feb  4 01:02:23 admin kernel: hde: no DRQ after issuing WRITE
> Feb  4 01:02:23 admin kernel: hde: status timeout: status=0xd0 { Busy }
> Feb  4 01:02:23 admin kernel: 

Hi Alan !

I'm trying to get some sense out of the above report as it seem to match
a problem a user reported me as well. It's interesting because it's
apparently running UP, so it's not the SMP race found by Ross. It's
definitely a problem with shared interrupt though.

I've followed the code path involved here. Basically, we had
ide_dma_intr() called while the drive was busy. This is strange for a
simple reason: Even if we got the wrong interrupt (shared interrupt),
__ide_dma_test_irq() should have returned 0, and so ide_dma_intr
shouldn't have been called.

Assuming the driver was doing basic read/write operations, I checked
the code, and while it seems that do_rw_disk() is called without
the lock held nor interrupts masked, I see no obvious race.
drive->waiting_for_dma is set before setting up the handler and
issuing the command, and while the DMA engine is indeed started
only after sending the command, it's INTR bit have been cleared
previously (I suppose it can't be stale, or can it while the DMA
haven't been started yet ? In this case we would need to take
the lock here).

> Results are that the drive itself just hangs and has to be powered off (resetting the box does not work). The drives worked (and works) fine in non shared-interrupt context. Controller is:
> 
> <6>PDC20268: IDE controller at PCI slot 01:02.0
> <6>PCI: Found IRQ 11 for device 01:02.0
> <6>PDC20268: chipset revision 1
> <6>PDC20268: not 100%% native mode: will probe irqs later
> <6>    ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:pio, hdf:pio
> <6>    ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:pio, hdh:pio
> <4>hdc: AOPEN CD-RW CRW2440, ATAPI CD/DVD-ROM drive
> <4>hde: ST380021A, ATA DISK drive
> <4>blk: queue c034e1f8, I/O limit 4095Mb (mask 0xffffffff)
> <4>hdg: IC35L060AVER07-0, ATA DISK drive
> <4>blk: queue c034e664, I/O limit 4095Mb (mask 0xffffffff)
> <4>ide1 at 0x170-0x177,0x376 on irq 15
> <4>ide2 at 0x8800-0x8807,0x8402 on irq 11
> <4>ide3 at 0x8000-0x8007,0x7802 on irq 11
> <4>hde: host protected area => 1
> <6>hde: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=155061/16/63, UDMA(100)
> <4>hdg: host protected area => 1
> <6>hdg: 120103200 sectors (61493 MB) w/1916KiB Cache, CHS=119150/16/63, UDMA(100)
> <6>Partition check:
> <6> hde: hde1
> <6> hdg:<6> [PTBL] [7476/255/63] hdg1
> 
> Regards,
> Stephan
> 
> PS: tg3 does great! Good job, Jeff...
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>

Re: 2.4.21-pre4: PDC ide driver problems with shared interrupts

[Stephan von Krawczynski]

On Sun, 02 Feb 2003 13:28:55 -0500
Jeff Garzik <jgarzik@pobox.com> wrote:

> > To make sure I will let it stress-test overnight and send you the results in
> > about 15 hours from now on. If everything does fine I will redo with ide2,ide3
> > on same interrupt, too. Just to see what happens with these Promise things...
> 
> 
> great.
> 
> though who knows with the Promise stuff... :)  I hope it's not their 
> binary-only junk...
> 
> 	Jeff

Okay, I had to watch for it a bit longer and it turns out that the kernel PDC driver has a problem in this shared interrupt setup. When loads get high it seems to run into some timing problem which causes things like:

Feb  4 01:02:22 admin kernel: hde: dma_intr: status=0xd0 { Busy }
Feb  4 01:02:22 admin kernel: 
Feb  4 01:02:22 admin kernel: PDC202XX: Primary channel reset.
Feb  4 01:02:22 admin kernel: ide2: reset: success
Feb  4 01:02:23 admin kernel: hde: status error: status=0x58 { DriveReady SeekComplete DataRequest }
Feb  4 01:02:23 admin kernel: 
Feb  4 01:02:23 admin kernel: hde: drive not ready for command
Feb  4 01:02:23 admin kernel: hde: status error: status=0x50 { DriveReady SeekComplete }
Feb  4 01:02:23 admin kernel: 
Feb  4 01:02:23 admin kernel: hde: no DRQ after issuing WRITE
Feb  4 01:02:23 admin kernel: hde: status timeout: status=0xd0 { Busy }
Feb  4 01:02:23 admin kernel: 

Results are that the drive itself just hangs and has to be powered off (resetting the box does not work). The drives worked (and works) fine in non shared-interrupt context. Controller is:

<6>PDC20268: IDE controller at PCI slot 01:02.0
<6>PCI: Found IRQ 11 for device 01:02.0
<6>PDC20268: chipset revision 1
<6>PDC20268: not 100%% native mode: will probe irqs later
<6>    ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:pio, hdf:pio
<6>    ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:pio, hdh:pio
<4>hdc: AOPEN CD-RW CRW2440, ATAPI CD/DVD-ROM drive
<4>hde: ST380021A, ATA DISK drive
<4>blk: queue c034e1f8, I/O limit 4095Mb (mask 0xffffffff)
<4>hdg: IC35L060AVER07-0, ATA DISK drive
<4>blk: queue c034e664, I/O limit 4095Mb (mask 0xffffffff)
<4>ide1 at 0x170-0x177,0x376 on irq 15
<4>ide2 at 0x8800-0x8807,0x8402 on irq 11
<4>ide3 at 0x8000-0x8007,0x7802 on irq 11
<4>hde: host protected area => 1
<6>hde: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=155061/16/63, UDMA(100)
<4>hdg: host protected area => 1
<6>hdg: 120103200 sectors (61493 MB) w/1916KiB Cache, CHS=119150/16/63, UDMA(100)
<6>Partition check:
<6> hde: hde1
<6> hdg:<6> [PTBL] [7476/255/63] hdg1

Regards,
Stephan

PS: tg3 does great! Good job, Jeff...