ISDN massive packet drops while DVD burn/verify
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.
Signature · 2 lines
Regards, Stephan
Quoted 9 lines · Stephan von Krawczynski
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
Quoted 12 lines · On Fri, 18 Apr 2003 09:25:21 -0500 (CDT) Kai Germaschewski…
Quoted 9 lines · Stephan von Krawczynski
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.
Quoted 3 lines
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 ...
Quoted 1 line
--Kai
Regards
Stephan
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 13 lines · On Sat, 19 Apr 2003 20:50:00 +0200 Christian Vogel…
Hi Stephan,
Quoted 9 lines · Stephan von Krawczynski
Quoted 3 lines
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 ...
Quoted 5 lines
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 ...
Quoted 2 lines
I would recommend doing
/sbin/hdparm-u1 -c1 -d1/dev/hdawhich makes all systems I know more performant and better responding.
You cannot issue that command to a DVD-writer used with ide-scsi.
Quoted 9 lines
Chris
Signature · 4 lines
The code was willing, It considered your request, But the chips were weak. -- Barry L. Brumitt
Regards,
Stephan
Quoted 5 lines · Stephan von Krawczynski
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.
Quoted 9 lines · On 19 Apr 2003 23:01:32 +0100 Alan Cox <[email protected]> wrote:
Quoted 5 lines · Stephan von Krawczynski
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
Quoted 1 line · Stephan von Krawczynski
Sorry Alan, "been there, done that"
Me too, ex 3Com engineer. He's still right.
Quoted 4 lines
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.
Hi Stephan,
Quoted 13 lines · Stephan von Krawczynski
Quoted 9 lines · On 19 Apr 2003 23:01:32 +0100 Alan Cox <[email protected]> wrote:
Quoted 5 lines · Stephan von Krawczynski
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.
Quoted 8 lines
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).
Signature · 3 lines
Karsten Keil SuSE Labs ISDN development
Quoted 1 line · On Mon, 5 May 2003 16:23:00 +0200 Karsten Keil <[email protected]> wrote:
Hi Stephan,
Hi Karsten,
long time no hear ;-)
Quoted 10 lines
Quoted 9 lines
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_.
Quoted 7 lines
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?
Quoted 3 lines
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.
Signature · 2 lines
Regards, Stephan
Quoted 9 lines · Stephan von Krawczynski
Quoted 1 line · On Mon, 5 May 2003 16:23:00 +0200 Karsten Keil <[email protected]> wrote:
Hi Stephan,
Hi Karsten,
long time no hear ;-)
Yes.
Quoted 18 lines
Quoted 10 lines
Quoted 9 lines
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_.Quoted 7 lines
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.
Quoted 3 lines
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.
Quoted 7 lines
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.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 4 lines
Signature · 3 lines
-- Regards, Stephan
Signature · 3 lines
Karsten Keil SuSE Labs ISDN development
Quoted 7 lines · On Mon, 5 May 2003 18:46:53 +0200 Karsten Keil <[email protected]> wrote:
Quoted 1 line
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
Quoted 2 lines
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 ...
Signature · 2 lines
Regards, Stephan
Quoted 17 lines · Stephan von Krawczynski
Quoted 7 lines · On Mon, 5 May 2003 18:46:53 +0200 Karsten Keil <[email protected]> wrote:
Quoted 1 line
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:
Quoted 12 lines
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
Quoted 5 lines
Quoted 2 lines
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.
Signature · 3 lines
Karsten Keil SuSE Labs ISDN development
Quoted 1 line · Stephan von Krawczynski
You mean UDMA 2 does not make it (which I had in the test case)?
But is the transfer being done in UDMA mode ?
Quoted 4 lines · On 06 May 2003 11:53:32 +0100 Alan Cox <[email protected]> wrote:
Quoted 1 line · Stephan von Krawczynski
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
Quoted 18 lines · Stephan von Krawczynski
Quoted 4 lines · On 06 May 2003 11:53:32 +0100 Alan Cox <[email protected]> wrote:
Quoted 1 line · Stephan von Krawczynski
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_MULTCOUNTfailed: Invalid argumentIO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off)
Quoted 6 lines
BLKRAGET failed: Invalid argument
HDIO_GETGEOfailed: Invalid argument
using_dmameans 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).
Signature · 3 lines
Karsten Keil SuSE Labs ISDN development
Quoted 11 lines · Stephan von Krawczynski
HDIO_GET_MULTCOUNTfailed: Invalid argumentIO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off)BLKRAGET failed: Invalid argument
HDIO_GETGEOfailed: Invalid argument
using_dmameans it's using dma for transfer, right?
Except for certain operations like audio cd ripping
Quoted 1 line · Alan Cox
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
Quoted 11 lines · On 06 May 2003 13:56:37 +0100 Alan Cox <[email protected]> wrote:
Quoted 10 lines · Stephan von Krawczynski
HDIO_GET_MULTCOUNTfailed: Invalid argumentIO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off)BLKRAGET failed: Invalid argument
HDIO_GETGEOfailed: Invalid argument
Quoted 3 lines
Quoted 1 line
using_dmameans 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
Quoted 18 lines · Stephan von Krawczynski
Quoted 14 lines · On 06 May 2003 13:56:37 +0100 Alan Cox <[email protected]> wrote:
Quoted 11 lines · Stephan von Krawczynski
HDIO_GET_MULTCOUNTfailed: Invalid argumentIO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off)BLKRAGET failed: Invalid argument
HDIO_GETGEOfailed: Invalid argument
using_dmameans it's using dma for transfer, right?
Quoted 8 lines
Quoted 1 line
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
Quoted 8 lines
Regards,
Stephan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 6 lines · Stephan von Krawczynski
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.