linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* ISDN massive packet drops while DVD burn/verify
@ 2003-04-16 13:12 Stephan von Krawczynski
  2003-04-18 14:25 ` Kai Germaschewski
  0 siblings, 1 reply; 20+ messages in thread
From: Stephan von Krawczynski @ 2003-04-16 13:12 UTC (permalink / raw)
  To: linux-kernel; +Cc: Kai Germaschewski

Hello all,

I just experienced a massive ISDN problem while writing DVDs.
It looks like bigger IP packets (bigger than normal ICMP ping)
get simply dropped most of the time.
I think the packets get lost because some allocation continously fails and disk
i/o is faster in re-gaining the mem, but I am not quite sure. Could as well be
ide-scsi is partially busy-looping the box to death.
As soon as DVD writing is stopped everything comes back to normal.
Reading DVDs does not show the problem btw.
ping -s 1500 a.b.c.d shows about 5 packets, then stops.

This is with 2.4.21-pre6.

The box is:

00:00.0 Host bridge: ServerWorks CNB20HE Host Bridge (rev 23)
00:00.1 Host bridge: ServerWorks CNB20HE Host Bridge (rev 01)
00:00.2 Host bridge: ServerWorks: Unknown device 0006 (rev 01)
00:00.3 Host bridge: ServerWorks: Unknown device 0006 (rev 01)
00:02.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 0d)
00:03.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 0d)
00:04.0 Network controller: Elsa AG QuickStep 1000 (rev 01)
00:05.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)
00:05.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 07)
00:07.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
00:0f.0 ISA bridge: ServerWorks CSB5 South Bridge (rev 93)
00:0f.1 IDE interface: ServerWorks CSB5 IDE Controller (rev 93)
00:0f.2 USB Controller: ServerWorks OSB4/CSB5 USB Controller (rev 05)
00:0f.3 Host bridge: ServerWorks: Unknown device 0225
01:02.0 RAID bus controller: 3ware Inc 3ware 7000-series ATA-RAID (rev 01)
01:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet (rev 15)
02:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet (rev 15)
02:03.0 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01)
02:03.1 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01)

/proc/meminfo

Mem:  3180371968 3171123200  9248768        0 544501760 2174619648
Swap: 2147467264 129138688 2018328576
MemTotal:      3105832 kB
MemFree:          9032 kB
MemShared:           0 kB
Buffers:        531740 kB
Cached:        2100388 kB
SwapCached:      23264 kB
Active:         724880 kB
Inactive:      2157696 kB
HighTotal:     2228204 kB
HighFree:         2896 kB
LowTotal:       877628 kB
LowFree:          6136 kB
SwapTotal:     2097136 kB
SwapFree:      1971024 kB


DVD is connected via ide-scsi. Data is on a disk connected to 3ware controller.

-- 
Regards,
Stephan

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: ISDN massive packet drops while DVD burn/verify
  2003-04-16 13:12 ISDN massive packet drops while DVD burn/verify Stephan von Krawczynski
@ 2003-04-18 14:25 ` Kai Germaschewski
  2003-04-19 17:38   ` Stephan von Krawczynski
  0 siblings, 1 reply; 20+ messages in thread
From: Kai Germaschewski @ 2003-04-18 14:25 UTC (permalink / raw)
  To: Stephan von Krawczynski; +Cc: linux-kernel

On Wed, 16 Apr 2003, Stephan von Krawczynski wrote:

> I just experienced a massive ISDN problem while writing DVDs.
> It looks like bigger IP packets (bigger than normal ICMP ping)
> get simply dropped most of the time.
> I think the packets get lost because some allocation continously fails and disk
> i/o is faster in re-gaining the mem, but I am not quite sure. Could as well be
> ide-scsi is partially busy-looping the box to death.
> As soon as DVD writing is stopped everything comes back to normal.
> Reading DVDs does not show the problem btw.
> ping -s 1500 a.b.c.d shows about 5 packets, then stops.

My best guess would be that IDE blocks IRQs for too long and hisax 
interrupts get lost. You could try whether hdparm -u1 helps, and a 
debugging log from the hisax driver may confirm over/underruns.

--Kai




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: ISDN massive packet drops while DVD burn/verify
  2003-04-18 14:25 ` Kai Germaschewski
@ 2003-04-19 17:38   ` Stephan von Krawczynski
       [not found]     ` <20030419205000.A3541@skunk.physik.uni-erlangen.de>
  2003-04-19 22:01     ` Alan Cox
  0 siblings, 2 replies; 20+ messages in thread
From: Stephan von Krawczynski @ 2003-04-19 17:38 UTC (permalink / raw)
  To: Kai Germaschewski; +Cc: linux-kernel

On Fri, 18 Apr 2003 09:25:21 -0500 (CDT)
Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de> wrote:

> On Wed, 16 Apr 2003, Stephan von Krawczynski wrote:
> 
> > I just experienced a massive ISDN problem while writing DVDs.
> > It looks like bigger IP packets (bigger than normal ICMP ping)
> > get simply dropped most of the time.
> > I think the packets get lost because some allocation continously fails and
> > disk i/o is faster in re-gaining the mem, but I am not quite sure. Could as
> > well be ide-scsi is partially busy-looping the box to death.
> > As soon as DVD writing is stopped everything comes back to normal.
> > Reading DVDs does not show the problem btw.
> > ping -s 1500 a.b.c.d shows about 5 packets, then stops.
> 
> My best guess would be that IDE blocks IRQs for too long and hisax 
> interrupts get lost. You could try whether hdparm -u1 helps, and a 
> debugging log from the hisax driver may confirm over/underruns.

I don't buy that explanation. Reason is simple: during this all network
connections work flawlessly, and they do have quite a lot of interrupts
compared to ISDN. ISDN is so slow and has so few interrupts that it is quite
unlikely in a SMP-beyond-GHz-limit box that you loose some. The ancient
hardware days are long gone ...

> --Kai

Regards
Stephan

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: ISDN massive packet drops while DVD burn/verify
       [not found]     ` <20030419205000.A3541@skunk.physik.uni-erlangen.de>
@ 2003-04-19 20:23       ` Stephan von Krawczynski
  0 siblings, 0 replies; 20+ messages in thread
From: Stephan von Krawczynski @ 2003-04-19 20:23 UTC (permalink / raw)
  To: Christian Vogel; +Cc: linux-kernel

On Sat, 19 Apr 2003 20:50:00 +0200
Christian Vogel <vogel@skunk.physik.uni-erlangen.de> wrote:

> Hi Stephan,
> 
> On Sat, Apr 19, 2003 at 07:38:48PM +0200, Stephan von Krawczynski wrote:
> > > My best guess would be that IDE blocks IRQs for too long and hisax 
> > > interrupts get lost. You could try whether hdparm -u1 helps, and a 
> > > debugging log from the hisax driver may confirm over/underruns.
> 
> > I don't buy that explanation. Reason is simple: during this all network
> > connections work flawlessly, and they do have quite a lot of interrupts
> > compared to ISDN. ISDN is so slow and has so few interrupts that it is
> > quite unlikely in a SMP-beyond-GHz-limit box that you loose some. The
> > ancient hardware days are long gone ...
> 
> I would. At least try it. Network connections are not subject to smaller
> delays, ISDN on the other hand depends on a synchronous processing of the
> data (it's like a sync serial port after all...). It's not important how
> fast your CPU is if it's just doing nothing while waiting for your
> harddisk...

First: we are not talking about harddisks by any means.

Second: if it is doing _nothing_ while waiting for ide-whatever, then it is
presumably also not updating my mouse position or performing anything else
useful. This is _not_ the case here.

Third: a full-blown (1 channel) ISDN-download has around 8kBytes/sec of data.
The worst chipsets ever will create around 250 interrupts/sec for this (32 byte
fifo per hdlc-chunk). Don't count on the exact number, it may be some few more
than 250, but not a lot. This may have been a problem on very old boxes from
some years back, but for sure not on todays GHz monsters. You can only kill it
by completely braindead interrupt programming, which - I honor Alans' IDE stuff
quite a lot - I do not presume existing somewhere inside the current kernel.

Forth: There are parts in the ISDN code like:

static int
isdn_writebuf_stub(int drvidx, int chan, const u_char * buf, int len,
                   int user)
{
        int ret;
        int hl = dev->drv[drvidx]->interface->hl_hdrlen;
        struct sk_buff *skb = alloc_skb(hl + len, GFP_ATOMIC);

        if (!skb)
                return 0;


Used here:
		lock_kernel();
		...

                while (isdn_writebuf_stub(drvidx, chidx, buf, count, 1) != count)
                        interruptible_sleep_on(&dev->drv[drvidx]->snd_waitq[chidx]);


Which basically means we are looping around for some mem without telling anybody... or not?
This is probably not a very good example of what I mean, but nevertheless ...

> I would recommend doing /sbin/hdparm -u1 -c1 -d1 /dev/hda which makes
> all systems I know more performant and better responding.

You cannot issue that command to a DVD-writer used with ide-scsi.

> 
> 	Chris
> 
> -- 
> The code was willing,
> It considered your request,
> But the chips were weak.
> -- Barry L. Brumitt
> 

Regards,
Stephan



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: ISDN massive packet drops while DVD burn/verify
  2003-04-19 17:38   ` Stephan von Krawczynski
       [not found]     ` <20030419205000.A3541@skunk.physik.uni-erlangen.de>
@ 2003-04-19 22:01     ` Alan Cox
  2003-04-20 16:18       ` Stephan von Krawczynski
  1 sibling, 1 reply; 20+ messages in thread
From: Alan Cox @ 2003-04-19 22:01 UTC (permalink / raw)
  To: Stephan von Krawczynski; +Cc: Kai Germaschewski, Linux Kernel Mailing List

On Sad, 2003-04-19 at 18:38, Stephan von Krawczynski wrote:
> I don't buy that explanation. Reason is simple: during this all network
> connections work flawlessly, and they do have quite a lot of interrupts
> compared to ISDN. ISDN is so slow and has so few interrupts that it is quite
> unlikely in a SMP-beyond-GHz-limit box that you loose some. The ancient
> hardware days are long gone ...

I'd suggest buying his explanation, because he's right. You are
confusing quantity and latency.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: ISDN massive packet drops while DVD burn/verify
  2003-04-19 22:01     ` Alan Cox
@ 2003-04-20 16:18       ` Stephan von Krawczynski
  2003-04-20 18:53         ` Alan Cox
  2003-05-05 14:23         ` Karsten Keil
  0 siblings, 2 replies; 20+ messages in thread
From: Stephan von Krawczynski @ 2003-04-20 16:18 UTC (permalink / raw)
  To: Alan Cox; +Cc: kai, linux-kernel

On 19 Apr 2003 23:01:32 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Sad, 2003-04-19 at 18:38, Stephan von Krawczynski wrote:
> > I don't buy that explanation. Reason is simple: during this all network
> > connections work flawlessly, and they do have quite a lot of interrupts
> > compared to ISDN. ISDN is so slow and has so few interrupts that it is
> > quite unlikely in a SMP-beyond-GHz-limit box that you loose some. The
> > ancient hardware days are long gone ...
> 
> I'd suggest buying his explanation, because he's right. You are
> confusing quantity and latency.

Sorry Alan, "been there, done that"
I made ISDN work on just about anything that you would call an OS on sometimes
quite ancient hardware (compared to nowadays), and I really cannot imagine that
the combined (though sometimes confusing) efforts of you, Andre, Pavel, name-one
on IDE made a dual 1.4 GHz PIII slower (responding) than a M68k 7,14 MHz with a
polling IDE interface - which happens to be the slowest thing I ever did ISDN
programming on _flawlessly_.

Regards,
Stephan

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: ISDN massive packet drops while DVD burn/verify
  2003-04-20 16:18       ` Stephan von Krawczynski
@ 2003-04-20 18:53         ` Alan Cox
  2003-05-05 14:23         ` Karsten Keil
  1 sibling, 0 replies; 20+ messages in thread
From: Alan Cox @ 2003-04-20 18:53 UTC (permalink / raw)
  To: Stephan von Krawczynski; +Cc: kai, Linux Kernel Mailing List

On Sul, 2003-04-20 at 17:18, Stephan von Krawczynski wrote:
> Sorry Alan, "been there, done that"

Me too, ex 3Com engineer. He's still right.

> the combined (though sometimes confusing) efforts of you, Andre, Pavel, name-one
> on IDE made a dual 1.4 GHz PIII slower (responding) than a M68k 7,14 MHz with a
> polling IDE interface - which happens to be the slowest thing I ever did ISDN
> programming on _flawlessly_.

Look up the word "latency" in a dictionary. Look up the word "throughput" in a 
dictionary. Note the difference.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: ISDN massive packet drops while DVD burn/verify
  2003-04-20 16:18       ` Stephan von Krawczynski
  2003-04-20 18:53         ` Alan Cox
@ 2003-05-05 14:23         ` Karsten Keil
  2003-05-05 15:32           ` Stephan von Krawczynski
  1 sibling, 1 reply; 20+ messages in thread
From: Karsten Keil @ 2003-05-05 14:23 UTC (permalink / raw)
  To: Stephan von Krawczynski; +Cc: Alan Cox, kai, linux-kernel

Hi Stephan,

On Sun, Apr 20, 2003 at 06:18:12PM +0200, Stephan von Krawczynski wrote:
> On 19 Apr 2003 23:01:32 +0100
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
> > On Sad, 2003-04-19 at 18:38, Stephan von Krawczynski wrote:
> > > I don't buy that explanation. Reason is simple: during this all network
> > > connections work flawlessly, and they do have quite a lot of interrupts
> > > compared to ISDN. ISDN is so slow and has so few interrupts that it is
> > > quite unlikely in a SMP-beyond-GHz-limit box that you loose some. The
> > > ancient hardware days are long gone ...
> > 
> > I'd suggest buying his explanation, because he's right. You are
> > confusing quantity and latency.
> 
> Sorry Alan, "been there, done that"
> I made ISDN work on just about anything that you would call an OS on sometimes
> quite ancient hardware (compared to nowadays), and I really cannot imagine that
> the combined (though sometimes confusing) efforts of you, Andre, Pavel, name-one
> on IDE made a dual 1.4 GHz PIII slower (responding) than a M68k 7,14 MHz with a
> polling IDE interface - which happens to be the slowest thing I ever did ISDN
> programming on _flawlessly_.
> 

No Alan and Kai are right.

The problem with the Infineon ISDN chips is that the fifos are small and so IRQ 
latency is relativ critical. 32 or 64 bytes are only 4/8 ms, and if one of these
32 Byte is dropped, the complete frame is lost. Modern ethernet cards allways
have fifos for multiple complete frames, so that such things don't happen here.

You can try to use HFC based ISDN cards (e.g. Conrad: ISDN TA 128K) the
fifos are much bigger (7.5kB) so at least 4 complete 1500 byte frames can be 
handled without segmentation. That increase the IRQ latency a lot (~900 ms).

-- 
Karsten Keil
SuSE Labs
ISDN development

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: ISDN massive packet drops while DVD burn/verify
  2003-05-05 14:23         ` Karsten Keil
@ 2003-05-05 15:32           ` Stephan von Krawczynski
  2003-05-05 16:46             ` Karsten Keil
  2003-05-06  9:52             ` Alan Cox
  0 siblings, 2 replies; 20+ messages in thread
From: Stephan von Krawczynski @ 2003-05-05 15:32 UTC (permalink / raw)
  To: Karsten Keil; +Cc: alan, kai, linux-kernel

On Mon, 5 May 2003 16:23:00 +0200
Karsten Keil <kkeil@suse.de> wrote:

> Hi Stephan,

Hi Karsten,

long time no hear ;-)

> > Sorry Alan, "been there, done that"
> > I made ISDN work on just about anything that you would call an OS on
> > sometimes quite ancient hardware (compared to nowadays), and I really
> > cannot imagine that the combined (though sometimes confusing) efforts of
> > you, Andre, Pavel, name-one on IDE made a dual 1.4 GHz PIII slower
> > (responding) than a M68k 7,14 MHz with a polling IDE interface - which
> > happens to be the slowest thing I ever did ISDN programming on
> > _flawlessly_.
> > 
> 
> No Alan and Kai are right.
> 
> The problem with the Infineon ISDN chips is that the fifos are small and so
> IRQ latency is relativ critical. 32 or 64 bytes are only 4/8 ms, and if one
> of these 32 Byte is dropped, the complete frame is lost. Modern ethernet
> cards allways have fifos for multiple complete frames, so that such things
> don't happen here.

I know the relatively small fifos. On the other hand compared to the ridiculous
throughput of 8 kByte/sec (single channel) (which most people seem to ignore in
this discussion), it is ok.

Let me simply ask back: is the IDE code in nowadays 2.4 kernel so bad, that a
dual 1,4 GHz PIII cpu with 3 GB ram performs much worse than a 90 MHz P I with
64 MB and OS/2 on it???
_My_ isdn drivers showed _no_ such problems under OS/2 and IDE load...

How did we manage to become that bad?

> You can try to use HFC based ISDN cards (e.g. Conrad: ISDN TA 128K) the
> fifos are much bigger (7.5kB) so at least 4 complete 1500 byte frames can be 
> handled without segmentation. That increase the IRQ latency a lot (~900 ms).

I know HFC is nice. But that cannot mean ISAC/HSCX must have dropouts. You have
to have long interrupt lock outs for such a behaviour, which cannot be intended
at all.

-- 
Regards,
Stephan

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: ISDN massive packet drops while DVD burn/verify
  2003-05-05 15:32           ` Stephan von Krawczynski
@ 2003-05-05 16:46             ` Karsten Keil
  2003-05-05 17:26               ` Stephan von Krawczynski
  2003-05-06  9:52             ` Alan Cox
  1 sibling, 1 reply; 20+ messages in thread
From: Karsten Keil @ 2003-05-05 16:46 UTC (permalink / raw)
  To: Stephan von Krawczynski; +Cc: alan, kai, linux-kernel

On Mon, May 05, 2003 at 05:32:49PM +0200, Stephan von Krawczynski wrote:
> On Mon, 5 May 2003 16:23:00 +0200
> Karsten Keil <kkeil@suse.de> wrote:
> 
> > Hi Stephan,
> 
> Hi Karsten,
> 
> long time no hear ;-)
> 

Yes.

> > > Sorry Alan, "been there, done that"
> > > I made ISDN work on just about anything that you would call an OS on
> > > sometimes quite ancient hardware (compared to nowadays), and I really
> > > cannot imagine that the combined (though sometimes confusing) efforts of
> > > you, Andre, Pavel, name-one on IDE made a dual 1.4 GHz PIII slower
> > > (responding) than a M68k 7,14 MHz with a polling IDE interface - which
> > > happens to be the slowest thing I ever did ISDN programming on
> > > _flawlessly_.
> > > 
> > 
> > No Alan and Kai are right.
> > 
> > The problem with the Infineon ISDN chips is that the fifos are small and so
> > IRQ latency is relativ critical. 32 or 64 bytes are only 4/8 ms, and if one
> > of these 32 Byte is dropped, the complete frame is lost. Modern ethernet
> > cards allways have fifos for multiple complete frames, so that such things
> > don't happen here.
> 
> I know the relatively small fifos. On the other hand compared to the ridiculous
> throughput of 8 kByte/sec (single channel) (which most people seem to ignore in
> this discussion), it is ok.

Again, the throughput doesn't matter so much.
The problem is latency and fifo size.
You lost a complete frame of 1500 Byte if one IRQ is missed and you need
about 46 IRQ per 1500 byte frame. So if you only miss 1% of RX IRQ, you
loose 33% of you troughput (every 3. frame).
On a High Speed Ethernet controller with 1% IRQ loss you don't see a effect,
since you loose also only 1%.
Thats why throughput doesn't matter in this case.

> 
> Let me simply ask back: is the IDE code in nowadays 2.4 kernel so bad, that a
> dual 1,4 GHz PIII cpu with 3 GB ram performs much worse than a 90 MHz P I with
> 64 MB and OS/2 on it???
> _My_ isdn drivers showed _no_ such problems under OS/2 and IDE load...
> 
> How did we manage to become that bad?

Its not so bad, the problem is how do you tune the system. If you prefer to
not interrupt the IDE transfers, which seems to be the default case, you
loose IRQ latency, which doesn't matter in much cases, but not on
this. You can tune it (hdparm work also with cdwriters, since
even if it use ide-scsi, the underlying driver is the ide driver.


> 
> > You can try to use HFC based ISDN cards (e.g. Conrad: ISDN TA 128K) the
> > fifos are much bigger (7.5kB) so at least 4 complete 1500 byte frames can be 
> > handled without segmentation. That increase the IRQ latency a lot (~900 ms).
> 
> I know HFC is nice. But that cannot mean ISAC/HSCX must have dropouts. You have
> to have long interrupt lock outs for such a behaviour, which cannot be intended
> at all.

Yes at least you must have 4+x ms interrupt lock outs, I didn't meassure it,
but reports show that hdparm -u1 helps in much cases. Note enabling IRQ
don't say that now the ISDN IRQ will handled, here maybe other IRQs with
higher priority which are served first and add extra latency.

This all don't say that here maybe also other problems around, but I have no
better explanation.

> 
> -- 
> Regards,
> Stephan

-- 
Karsten Keil
SuSE Labs
ISDN development

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: ISDN massive packet drops while DVD burn/verify
  2003-05-05 16:46             ` Karsten Keil
@ 2003-05-05 17:26               ` Stephan von Krawczynski
  2003-05-05 18:31                 ` Karsten Keil
  2003-05-06 10:53                 ` Alan Cox
  0 siblings, 2 replies; 20+ messages in thread
From: Stephan von Krawczynski @ 2003-05-05 17:26 UTC (permalink / raw)
  To: Karsten Keil; +Cc: alan, kai, linux-kernel

On Mon, 5 May 2003 18:46:53 +0200
Karsten Keil <kkeil@suse.de> wrote:

> > How did we manage to become that bad?
> 
> Its not so bad, the problem is how do you tune the system. If you prefer to
> not interrupt the IDE transfers, which seems to be the default case, you
> loose IRQ latency, which doesn't matter in much cases, but not on
> this. You can tune it (hdparm work also with cdwriters, since
> even if it use ide-scsi, the underlying driver is the ide driver.

You mean UDMA 2 does not make it (which I had in the test case)?

# hdparm -i /dev/hdc

/dev/hdc:

 Model=SONY DVD RW DRU-500A, FwRev=2.0c, SerialNo=DA5B9D3D
 Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
 RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=0kB, MaxMultSect=0
 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
 IORDY=on/off, tPIO={min:180,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 *udma2 
 AdvancedPM=no
 Drive conforms to: device does not report version:  4 5 6

> This all don't say that here maybe also other problems around, but I have no
> better explanation.

Hm, this looks like the unresolved sleeping AVM Fritz2 syndrome to me: no idea
of what's really going on ...

-- 
Regards,
Stephan

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: ISDN massive packet drops while DVD burn/verify
  2003-05-05 17:26               ` Stephan von Krawczynski
@ 2003-05-05 18:31                 ` Karsten Keil
  2003-05-06 10:53                 ` Alan Cox
  1 sibling, 0 replies; 20+ messages in thread
From: Karsten Keil @ 2003-05-05 18:31 UTC (permalink / raw)
  To: Stephan von Krawczynski; +Cc: alan, kai, linux-kernel

On Mon, May 05, 2003 at 07:26:52PM +0200, Stephan von Krawczynski wrote:
> On Mon, 5 May 2003 18:46:53 +0200
> Karsten Keil <kkeil@suse.de> wrote:
> 
> > > How did we manage to become that bad?
> > 
> > Its not so bad, the problem is how do you tune the system. If you prefer to
> > not interrupt the IDE transfers, which seems to be the default case, you
> > loose IRQ latency, which doesn't matter in much cases, but not on
> > this. You can tune it (hdparm work also with cdwriters, since
> > even if it use ide-scsi, the underlying driver is the ide driver.
> 
> You mean UDMA 2 does not make it (which I had in the test case)?
> 
> # hdparm -i /dev/hdc
> 
> /dev/hdc:
> 
>  Model=SONY DVD RW DRU-500A, FwRev=2.0c, SerialNo=DA5B9D3D
>  Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
>  RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
>  BuffType=unknown, BuffSize=0kB, MaxMultSect=0
>  (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
>  IORDY=on/off, tPIO={min:180,w/IORDY:120}, tDMA={min:120,rec:120}
>  PIO modes:  pio0 pio1 pio2 pio3 pio4 
>  DMA modes:  mdma0 mdma1 mdma2 
>  UDMA modes: udma0 udma1 *udma2 
>  AdvancedPM=no
>  Drive conforms to: device does not report version:  4 5 6
> 

No the mode doesn't matter so much here, what give

hdparm -v /dev/hdc


> > This all don't say that here maybe also other problems around, but I have no
> > better explanation.
> 
> Hm, this looks like the unresolved sleeping AVM Fritz2 syndrome to me: no idea
> of what's really going on ...

Hmm, don't remember this issue at the moment.

-- 
Karsten Keil
SuSE Labs
ISDN development

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: ISDN massive packet drops while DVD burn/verify
  2003-05-05 15:32           ` Stephan von Krawczynski
  2003-05-05 16:46             ` Karsten Keil
@ 2003-05-06  9:52             ` Alan Cox
  1 sibling, 0 replies; 20+ messages in thread
From: Alan Cox @ 2003-05-06  9:52 UTC (permalink / raw)
  To: Stephan von Krawczynski; +Cc: Karsten Keil, kai, Linux Kernel Mailing List

On Llu, 2003-05-05 at 16:32, Stephan von Krawczynski wrote:
> Let me simply ask back: is the IDE code in nowadays 2.4 kernel so bad, that a
> dual 1,4 GHz PIII cpu with 3 GB ram performs much worse than a 90 MHz P I with
> 64 MB and OS/2 on it???
> _My_ isdn drivers showed _no_ such problems under OS/2 and IDE load...
> 
> How did we manage to become that bad?

Our default behaviour in PIO mode is defensive to handle very old controller setups
that chew up disks when the disk gets ahead of the pio transfer.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: ISDN massive packet drops while DVD burn/verify
  2003-05-05 17:26               ` Stephan von Krawczynski
  2003-05-05 18:31                 ` Karsten Keil
@ 2003-05-06 10:53                 ` Alan Cox
  2003-05-06 12:39                   ` Stephan von Krawczynski
  1 sibling, 1 reply; 20+ messages in thread
From: Alan Cox @ 2003-05-06 10:53 UTC (permalink / raw)
  To: Stephan von Krawczynski; +Cc: Karsten Keil, kai, Linux Kernel Mailing List

On Llu, 2003-05-05 at 18:26, Stephan von Krawczynski wrote:
> You mean UDMA 2 does not make it (which I had in the test case)?

But is the transfer being done in UDMA mode ?


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: ISDN massive packet drops while DVD burn/verify
  2003-05-06 10:53                 ` Alan Cox
@ 2003-05-06 12:39                   ` Stephan von Krawczynski
  2003-05-06 12:56                     ` Alan Cox
  2003-05-06 13:06                     ` Karsten Keil
  0 siblings, 2 replies; 20+ messages in thread
From: Stephan von Krawczynski @ 2003-05-06 12:39 UTC (permalink / raw)
  To: Alan Cox; +Cc: kkeil, kai, linux-kernel

On 06 May 2003 11:53:32 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Llu, 2003-05-05 at 18:26, Stephan von Krawczynski wrote:
> > You mean UDMA 2 does not make it (which I had in the test case)?
> 
> But is the transfer being done in UDMA mode ?


# hdparm -v /dev/hdc

/dev/hdc:
 HDIO_GET_MULTCOUNT failed: Invalid argument
 IO_support   =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 BLKRAGET failed: Invalid argument
 HDIO_GETGEO failed: Invalid argument
 

using_dma means it's using dma for transfer, right?

Regards,
Stephan




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: ISDN massive packet drops while DVD burn/verify
  2003-05-06 12:39                   ` Stephan von Krawczynski
@ 2003-05-06 12:56                     ` Alan Cox
  2003-05-06 14:01                       ` Stephan von Krawczynski
  2003-05-06 14:13                       ` Mike Dresser
  2003-05-06 13:06                     ` Karsten Keil
  1 sibling, 2 replies; 20+ messages in thread
From: Alan Cox @ 2003-05-06 12:56 UTC (permalink / raw)
  To: Stephan von Krawczynski; +Cc: kkeil, kai, Linux Kernel Mailing List

On Maw, 2003-05-06 at 13:39, Stephan von Krawczynski wrote:
>  HDIO_GET_MULTCOUNT failed: Invalid argument
>  IO_support   =  0 (default 16-bit)
>  unmaskirq    =  0 (off)
>  using_dma    =  1 (on)
>  keepsettings =  0 (off)
>  readonly     =  0 (off)
>  BLKRAGET failed: Invalid argument
>  HDIO_GETGEO failed: Invalid argument
>  
> 
> using_dma means it's using dma for transfer, right?

Except for certain operations like audio cd ripping


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: ISDN massive packet drops while DVD burn/verify
  2003-05-06 12:39                   ` Stephan von Krawczynski
  2003-05-06 12:56                     ` Alan Cox
@ 2003-05-06 13:06                     ` Karsten Keil
  1 sibling, 0 replies; 20+ messages in thread
From: Karsten Keil @ 2003-05-06 13:06 UTC (permalink / raw)
  To: Stephan von Krawczynski; +Cc: Alan Cox, kai, linux-kernel

On Tue, May 06, 2003 at 02:39:02PM +0200, Stephan von Krawczynski wrote:
> On 06 May 2003 11:53:32 +0100
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
> > On Llu, 2003-05-05 at 18:26, Stephan von Krawczynski wrote:
> > > You mean UDMA 2 does not make it (which I had in the test case)?
> > 
> > But is the transfer being done in UDMA mode ?
> 
> 
> # hdparm -v /dev/hdc
> 
> /dev/hdc:
>  HDIO_GET_MULTCOUNT failed: Invalid argument
>  IO_support   =  0 (default 16-bit)
>  unmaskirq    =  0 (off)
>  using_dma    =  1 (on)
>  keepsettings =  0 (off)
>  readonly     =  0 (off)
>  BLKRAGET failed: Invalid argument
>  HDIO_GETGEO failed: Invalid argument
>  
> 
> using_dma means it's using dma for transfer, right?
> 

It should, but so far I know it cannot do every thing with
dma.
My writer use:

pingi2:~ # hdparm -v /dev/hdc

/dev/hdc:
 HDIO_GET_MULTCOUNT failed: Input/output error
 IO_support   =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  0 (off)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 BLKRAGET failed: Input/output error
 HDIO_GETGEO failed: Invalid argument

And I see no problems.

At least you can try hdparm -u1 (use a RW media).

-- 
Karsten Keil
SuSE Labs
ISDN development

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: ISDN massive packet drops while DVD burn/verify
  2003-05-06 12:56                     ` Alan Cox
@ 2003-05-06 14:01                       ` Stephan von Krawczynski
  2003-05-06 16:46                         ` Wolfgang Fritz
  2003-05-06 14:13                       ` Mike Dresser
  1 sibling, 1 reply; 20+ messages in thread
From: Stephan von Krawczynski @ 2003-05-06 14:01 UTC (permalink / raw)
  To: Alan Cox; +Cc: kkeil, kai, linux-kernel

On 06 May 2003 13:56:37 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Maw, 2003-05-06 at 13:39, Stephan von Krawczynski wrote:
> >  HDIO_GET_MULTCOUNT failed: Invalid argument
> >  IO_support   =  0 (default 16-bit)
> >  unmaskirq    =  0 (off)
> >  using_dma    =  1 (on)
> >  keepsettings =  0 (off)
> >  readonly     =  0 (off)
> >  BLKRAGET failed: Invalid argument
> >  HDIO_GETGEO failed: Invalid argument
> >  
> > 
> > using_dma means it's using dma for transfer, right?
> 
> Except for certain operations like audio cd ripping

Not used here.
We are using the DVDs (DVD-R) for data backups, some dozens a month.
And keep in mind: the problem occurs currently only while writing to DVD, not
while reading it.

Regards,
Stephan

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: ISDN massive packet drops while DVD burn/verify
  2003-05-06 12:56                     ` Alan Cox
  2003-05-06 14:01                       ` Stephan von Krawczynski
@ 2003-05-06 14:13                       ` Mike Dresser
  1 sibling, 0 replies; 20+ messages in thread
From: Mike Dresser @ 2003-05-06 14:13 UTC (permalink / raw)
  To: linux-kernel

On 6 May 2003, Alan Cox wrote:

> Except for certain operations like audio cd ripping

Burning audio cd's too, right?

I've noticed that burnfree gets triggered quite often while burning audio
cd's on my LiteOn LTR-48125W at 40x(maximum my cds will let me do).

Actually, speaking of that, I'm using burnfree under cdrecord 2.01a10.
Once in awhile I'll burn a cd and the red light turns to orange, indicating
burnproof has triggered on the drive.

Yet, at the end of the burn using -v, cdrecord will claim burnfree was
never needed even though it has triggered dozens of times.

Very weird.

Mike


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: ISDN massive packet drops while DVD burn/verify
  2003-05-06 14:01                       ` Stephan von Krawczynski
@ 2003-05-06 16:46                         ` Wolfgang Fritz
  0 siblings, 0 replies; 20+ messages in thread
From: Wolfgang Fritz @ 2003-05-06 16:46 UTC (permalink / raw)
  To: linux-kernel

Stephan von Krawczynski wrote:
> On 06 May 2003 13:56:37 +0100
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
> 
>>On Maw, 2003-05-06 at 13:39, Stephan von Krawczynski wrote:
>>
>>> HDIO_GET_MULTCOUNT failed: Invalid argument
>>> IO_support   =  0 (default 16-bit)
>>> unmaskirq    =  0 (off)
>>> using_dma    =  1 (on)
>>> keepsettings =  0 (off)
>>> readonly     =  0 (off)
>>> BLKRAGET failed: Invalid argument
>>> HDIO_GETGEO failed: Invalid argument
>>> 
>>>
>>>using_dma means it's using dma for transfer, right?
>>
>>Except for certain operations like audio cd ripping
> 
> 
> Not used here.
> We are using the DVDs (DVD-R) for data backups, some dozens a month.
> And keep in mind: the problem occurs currently only while writing to DVD, not
> while reading it.
> 

DVD writing seems to be problematic in other places too. I lose several
minutes of system time when I write a DVD. This is with SuSE 8.2 (SuSE
vendor kernel 2.4.20 based)

Wolfgang

> Regards,
> Stephan
> -
> 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/
> 



^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2003-05-06 17:03 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-16 13:12 ISDN massive packet drops while DVD burn/verify Stephan von Krawczynski
2003-04-18 14:25 ` Kai Germaschewski
2003-04-19 17:38   ` Stephan von Krawczynski
     [not found]     ` <20030419205000.A3541@skunk.physik.uni-erlangen.de>
2003-04-19 20:23       ` Stephan von Krawczynski
2003-04-19 22:01     ` Alan Cox
2003-04-20 16:18       ` Stephan von Krawczynski
2003-04-20 18:53         ` Alan Cox
2003-05-05 14:23         ` Karsten Keil
2003-05-05 15:32           ` Stephan von Krawczynski
2003-05-05 16:46             ` Karsten Keil
2003-05-05 17:26               ` Stephan von Krawczynski
2003-05-05 18:31                 ` Karsten Keil
2003-05-06 10:53                 ` Alan Cox
2003-05-06 12:39                   ` Stephan von Krawczynski
2003-05-06 12:56                     ` Alan Cox
2003-05-06 14:01                       ` Stephan von Krawczynski
2003-05-06 16:46                         ` Wolfgang Fritz
2003-05-06 14:13                       ` Mike Dresser
2003-05-06 13:06                     ` Karsten Keil
2003-05-06  9:52             ` Alan Cox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).