* 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
[parent not found: <20030419205000.A3541@skunk.physik.uni-erlangen.de>]
* 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 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: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 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
* 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 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-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
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).