Re: Poor SCSI drive performance FIXED on SMP machine, 2.2.16
Thanks! I have added a terminator to the SCSI bus and also turned on TCQ and now I can write out 100 MB in 10 seconds (as opposed to several minutes) Regards, Para-dox ([EMAIL PROTECTED]) - Original Message - From: "Trevor Hemsley" <[EMAIL PROTECTED]> To: "paradox3" <[EMAIL PROTECTED]> Sent: Sunday, January 28, 2001 8:56 PM Subject: Re: Poor SCSI drive performance on SMP machine, 2.2.16 > On Sun, 28 Jan 2001 19:58:04 -0500, paradox3 wrote: > > >I've attached the output in the kernel ring buffer as it initializes the > >scsi drive. I haven't been > >able to find IBM's website for DGHS09U to see if it self terminates. Maybe > >you > >can tell. > > Yeah, I have the PDF manual for that one here too - I used to have one. It's a Single ended > (ie not LVD), fast, wide 7200rpm drive with a 68 pin connector. It has a top speed of about > 14MB/sec. Pretty good drive in its day. It's the 7200rpm drive of the same generation as my > DGVS09U - the manual I have is dated October 1997. > > From the manual... > > Enable Active Termination > Single Ended 50 and 68 pin models are available with on card SCSI Bus Active Terminators. > The Active Termination feature can be enabled by installing a jumper between pins 13 and 14 > of the Front Option Jumper Block or connecting pins 9 and 10 of the Auxiliary Connector on > 68 SCSI pin models. SCA-2 80 pin has no termination. > > If you need more information about the drive, IBM are usually pretty good at keeping it on > their web site, http://www.storage.ibm.com should get you more. > > I'd guess you need to jumper pins 13+14 of the front jumper block *or* pins 9+10 of the jumper > block on the back that lies between the power connector and the 68 pin cable connector. On > the back connector pins 1+2 are the ones nearest the power connector. On the front connector > pin 1 is the lefthandmost pin when you look at it with the PCB downwards and the front of the > drive towards you. > > Since this looks like it's the only device you have attached to the controller then you should also > look in the BIOS setup (Ctrl-A at boot time) and find the section that talks about controller > termination. You can either set this to Automatic which usually works but sometimes gets it > wrong or you can set it to Low On/High ON which is correct if you have no external devices > and no devices attached to the internal 50 pin connector. > > > Trevor Hemsley, Brighton, UK. > [EMAIL PROTECTED] > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor SCSI drive performance on SMP machine, 2.2.16
Here is the output from dmesg. How do I tell if it is improperly terminated? Thanks, Para-dox ([EMAIL PROTECTED]) - Original Message - From: "Michael Brown" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, January 28, 2001 11:12 PM Subject: Re: Poor SCSI drive performance on SMP machine, 2.2.16 > Your problem appears to be improper SCSI termination. > > You need to either > 1) make sure your SCSI drive has termination enabled > or > 2) move your SCSI drive to the middle connector and put a terminator on > the last connector > > Check your syslog and post to l-k the part where it detects your drives. > I'll bet the adapter is throttling back quite dramatically in the presence > of improper termination. > > -- > Michael Brown > > _ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > (scsi0) found at PCI 0/12/0 (scsi0) Wide Channel, SCSI ID=7, 32/255 SCBs (scsi0) Downloading sequencer code... 392 instructions downloaded scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.31/3.2.4 scsi : 1 host. (scsi0:0:0:0) Synchronous at 40.0 Mbyte/sec, offset 15. Vendor: IBM Model: DGHS09U Rev: 0350 Type: Direct-Access ANSI SCSI revision: 03 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 scsi : detected 1 SCSI disk total. SCSI device sda: hdwr sector= 512 bytes. Sectors= 17916240 [8748 MB] [8.7 GB] Partition check: sda: sda1 sda2 sda3
Re: Poor SCSI drive performance on SMP machine, 2.2.16
> It sounds to me like you have a SCSI bus problem. Have you checked > termination? Cable quality? Cable lengths? Forgive me, I'm rather ignorant of SCSI hardware.All that I have is a cable (appears to be good quality, came with motherboard) about 60 centimeters long going from the motherboard to my hard drive. There is an unused/empty port in between. > > Do you have tagged queuing enabled for aic7xxx? It's a config option > and you can adjust the maximum queue depth. You can see the current > settings by cat /proc/scsi/aic7xxx/0 > /proc/scsi only contains a single file named "scsi" with brief info about the drive According to my last save kernel config, tagged command queueing is not enabled by default. Could this be the problem? > Do you have write caching enabled on the drive? scsiinfo -c /dev/sdx > will tell you if you do. I don't seem to have scsiinfo. > > As a data point, I copied a 650MB file to another file on the same > 10krpm disk and sync'ed in about the same time it takes you to write > 100MB. I've also copied it from a slower 7200rpm disk to my 10krpm IBM > drive and sync'ed in 1 min 19 secs which is about the read speed of > the slower disk. > > -- > Trevor Hemsley, Brighton, UK. > [EMAIL PROTECTED] > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor SCSI drive performance on SMP machine, 2.2.16
Sorry, forget this last email. Here is hdparm output. hdparm
Re: Poor SCSI drive performance on SMP machine, 2.2.16
I did this: date dd if=/dev/zero of=TESTFILE bs=1024 count=102400 date sync date and I gave the time differences from the first to the last timestamp. Regards, Para-dox ([EMAIL PROTECTED]) - Original Message - From: "Bruce Harada" <[EMAIL PROTECTED]> To: "paradox3" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, January 28, 2001 2:31 PM Subject: Re: Poor SCSI drive performance on SMP machine, 2.2.16 > > Hm. As a point of comparison, I use a similar system to yours (full SCSI, > though, no IDE) and I can copy a 100MB file from disk-to-disk, or on the > same disk, in around 13 seconds. Where are you copying to the SCSI drive > from - the same drive, an IDE disk, CDROM? If IDE, what are its > particulars? (Check with hdparm -iI /dev/hd?) > > -- > Bruce Harada > [EMAIL PROTECTED] > > > > On Sun, 28 Jan 2001 12:44:29 -0500 > "paradox3" <[EMAIL PROTECTED]> wrote: > > > > I don't get any messages relating to the drives in any syslog output. > > > > > > > > Do you get messages like the ones below in /var/log/messages? > > > > > > sym53c875-0-<0,0>: QUEUE FULL! 8 busy, 7 disconnected CCBs > > > sym53c875-0-<0,0>: tagged command queue depth set to 7 > > > > > > In fact, do you get any messages in your log files that look like they > > > might be related? > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor SCSI drive performance on SMP machine, 2.2.16
I don't get any messages relating to the drives in any syslog output. - Original Message - From: "Bruce Harada" <[EMAIL PROTECTED]> To: "paradox3" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, January 28, 2001 3:40 AM Subject: Re: Poor SCSI drive performance on SMP machine, 2.2.16 > > Hi. > > Do you get messages like the ones below in /var/log/messages? > > sym53c875-0-<0,0>: QUEUE FULL! 8 busy, 7 disconnected CCBs > sym53c875-0-<0,0>: tagged command queue depth set to 7 > > In fact, do you get any messages in your log files that look like they > might be related? > > -- > Bruce Harada > [EMAIL PROTECTED] > > > On Sun, 28 Jan 2001 02:26:32 -0500 > "paradox3" <[EMAIL PROTECTED]> wrote: > > > I have an SMP machine (dual PII 400s) running 2.2.16 with one 10,000 RPM > > IBM > > 10 GB SCSI drive > > (AIC 7890 on motherboard, using aic7xxx.o), and four various IDE drives. > > The > > SCSI drive > > performs the worst. In tests of writing 100 MB and sync'ing, one of my > > IDE > > drives takes 31 seconds. The SCSI drive (while doing nothing else) took > > 2 minutes, 10 seconds. This is extremely noticable in file transfers > > that > > completely > > monopolize the SCSI drive, and are much slower than when involving the > > IDE > > drives. > > After a large data operation on the SCSI drive, the system will hang for > > several minutes. > > Anyone know what could be causing this? Thanks. > > > > Attached are some data to help. > > > > > > Thanks, > > Para-dox ([EMAIL PROTECTED]) > > > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor SCSI drive performance on SMP machine, 2.2.16
I don't get any messages relating to the drives in any syslog output. - Original Message - From: "Bruce Harada" [EMAIL PROTECTED] To: "paradox3" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, January 28, 2001 3:40 AM Subject: Re: Poor SCSI drive performance on SMP machine, 2.2.16 Hi. Do you get messages like the ones below in /var/log/messages? sym53c875-0-0,0: QUEUE FULL! 8 busy, 7 disconnected CCBs sym53c875-0-0,0: tagged command queue depth set to 7 In fact, do you get any messages in your log files that look like they might be related? -- Bruce Harada [EMAIL PROTECTED] On Sun, 28 Jan 2001 02:26:32 -0500 "paradox3" [EMAIL PROTECTED] wrote: I have an SMP machine (dual PII 400s) running 2.2.16 with one 10,000 RPM IBM 10 GB SCSI drive (AIC 7890 on motherboard, using aic7xxx.o), and four various IDE drives. The SCSI drive performs the worst. In tests of writing 100 MB and sync'ing, one of my IDE drives takes 31 seconds. The SCSI drive (while doing nothing else) took 2 minutes, 10 seconds. This is extremely noticable in file transfers that completely monopolize the SCSI drive, and are much slower than when involving the IDE drives. After a large data operation on the SCSI drive, the system will hang for several minutes. Anyone know what could be causing this? Thanks. Attached are some data to help. Thanks, Para-dox ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor SCSI drive performance on SMP machine, 2.2.16
I did this: date dd if=/dev/zero of=TESTFILE bs=1024 count=102400 date sync date and I gave the time differences from the first to the last timestamp. Regards, Para-dox ([EMAIL PROTECTED]) - Original Message - From: "Bruce Harada" [EMAIL PROTECTED] To: "paradox3" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, January 28, 2001 2:31 PM Subject: Re: Poor SCSI drive performance on SMP machine, 2.2.16 Hm. As a point of comparison, I use a similar system to yours (full SCSI, though, no IDE) and I can copy a 100MB file from disk-to-disk, or on the same disk, in around 13 seconds. Where are you copying to the SCSI drive from - the same drive, an IDE disk, CDROM? If IDE, what are its particulars? (Check with hdparm -iI /dev/hd?) -- Bruce Harada [EMAIL PROTECTED] On Sun, 28 Jan 2001 12:44:29 -0500 "paradox3" [EMAIL PROTECTED] wrote: I don't get any messages relating to the drives in any syslog output. Do you get messages like the ones below in /var/log/messages? sym53c875-0-0,0: QUEUE FULL! 8 busy, 7 disconnected CCBs sym53c875-0-0,0: tagged command queue depth set to 7 In fact, do you get any messages in your log files that look like they might be related? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor SCSI drive performance on SMP machine, 2.2.16
Sorry, forget this last email. Here is hdparm output. hdparm
Re: Poor SCSI drive performance on SMP machine, 2.2.16
It sounds to me like you have a SCSI bus problem. Have you checked termination? Cable quality? Cable lengths? Forgive me, I'm rather ignorant of SCSI hardware.All that I have is a cable (appears to be good quality, came with motherboard) about 60 centimeters long going from the motherboard to my hard drive. There is an unused/empty port in between. Do you have tagged queuing enabled for aic7xxx? It's a config option and you can adjust the maximum queue depth. You can see the current settings by cat /proc/scsi/aic7xxx/0 /proc/scsi only contains a single file named "scsi" with brief info about the drive According to my last save kernel config, tagged command queueing is not enabled by default. Could this be the problem? Do you have write caching enabled on the drive? scsiinfo -c /dev/sdx will tell you if you do. I don't seem to have scsiinfo. As a data point, I copied a 650MB file to another file on the same 10krpm disk and sync'ed in about the same time it takes you to write 100MB. I've also copied it from a slower 7200rpm disk to my 10krpm IBM drive and sync'ed in 1 min 19 secs which is about the read speed of the slower disk. -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor SCSI drive performance on SMP machine, 2.2.16
Here is the output from dmesg. How do I tell if it is improperly terminated? Thanks, Para-dox ([EMAIL PROTECTED]) - Original Message - From: "Michael Brown" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 28, 2001 11:12 PM Subject: Re: Poor SCSI drive performance on SMP machine, 2.2.16 Your problem appears to be improper SCSI termination. You need to either 1) make sure your SCSI drive has termination enabled or 2) move your SCSI drive to the middle connector and put a terminator on the last connector Check your syslog and post to l-k the part where it detects your drives. I'll bet the adapter is throttling back quite dramatically in the presence of improper termination. -- Michael Brown _ Get your FREE download of MSN Explorer at http://explorer.msn.com (scsi0) Adaptec AIC-7890/1 Ultra2 SCSI host adapter found at PCI 0/12/0 (scsi0) Wide Channel, SCSI ID=7, 32/255 SCBs (scsi0) Downloading sequencer code... 392 instructions downloaded scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.31/3.2.4 Adaptec AIC-7890/1 Ultra2 SCSI host adapter scsi : 1 host. (scsi0:0:0:0) Synchronous at 40.0 Mbyte/sec, offset 15. Vendor: IBM Model: DGHS09U Rev: 0350 Type: Direct-Access ANSI SCSI revision: 03 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 scsi : detected 1 SCSI disk total. SCSI device sda: hdwr sector= 512 bytes. Sectors= 17916240 [8748 MB] [8.7 GB] Partition check: sda: sda1 sda2 sda3
Poor SCSI drive performance on SMP machine, 2.2.16
I have an SMP machine (dual PII 400s) running 2.2.16 with one 10,000 RPM IBM 10 GB SCSI drive (AIC 7890 on motherboard, using aic7xxx.o), and four various IDE drives. The SCSI drive performs the worst. In tests of writing 100 MB and sync'ing, one of my IDE drives takes 31 seconds. The SCSI drive (while doing nothing else) took 2 minutes, 10 seconds. This is extremely noticable in file transfers that completely monopolize the SCSI drive, and are much slower than when involving the IDE drives. After a large data operation on the SCSI drive, the system will hang for several minutes. Anyone know what could be causing this? Thanks. Attached are some data to help. Thanks, Para-dox ([EMAIL PROTECTED]) CPU0 CPU1 0: 43661720 59171710IO-APIC-edge timer 1: 233992 282694IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 8: 1 0IO-APIC-edge rtc 13: 1 0 XT-PIC fpu 14: 20 10IO-APIC-edge ide0 15: 46455293 50354306IO-APIC-edge ide1 16: 14508949 14462778 IO-APIC-level eth0 17:39395544293901 IO-APIC-level eth1 18: 750747 761816 IO-APIC-level aic7xxx NMI: 0 ERR: 0 PCI devices found: Bus 0, device 0, function 0: Host bridge: Intel 440BX - 82443BX Host (rev 2). Medium devsel. Master Capable. Latency=64. Prefetchable 32 bit memory at 0xe800 [0xe808]. Bus 0, device 1, function 0: PCI bridge: Intel 440BX - 82443BX AGP (rev 2). Medium devsel. Master Capable. Latency=64. Min Gnt=136. Bus 0, device 7, function 0: ISA bridge: Intel 82371AB PIIX4 ISA (rev 2). Medium devsel. Fast back-to-back capable. Master Capable. No bursts. Bus 0, device 7, function 1: IDE interface: Intel 82371AB PIIX4 IDE (rev 1). Medium devsel. Fast back-to-back capable. Master Capable. Latency=64. I/O at 0xf000 [0xf001]. Bus 0, device 7, function 2: USB Controller: Intel 82371AB PIIX4 USB (rev 1). Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. Latency=64. I/O at 0xe000 [0xe001]. Bus 0, device 7, function 3: Bridge: Intel 82371AB PIIX4 ACPI (rev 2). Medium devsel. Fast back-to-back capable. Bus 0, device 8, function 0: Ethernet controller: Intel 82557 (rev 5). Medium devsel. Fast back-to-back capable. IRQ 16. Master Capable. Latency=64. Min Gnt=8.Max Lat=56. Prefetchable 32 bit memory at 0xef101000 [0xef101008]. I/O at 0xe400 [0xe401]. Non-prefetchable 32 bit memory at 0xef00 [0xef00]. Bus 0, device 9, function 0: Ethernet controller: Winbond NE2000-PCI (rev 0). Medium devsel. Fast back-to-back capable. IRQ 17. I/O at 0xe800 [0xe801]. Bus 0, device 12, function 0: SCSI storage controller: Adaptec AIC-7890/1 (rev 0). Medium devsel. Fast back-to-back capable. BIST capable. IRQ 18. Master Capable. Latency=64. Min Gnt=39.Max Lat=25. I/O at 0xec00 [0xec01]. Non-prefetchable 64 bit memory at 0xef10 [0xef14]. Bus 1, device 0, function 0: VGA compatible controller: S3 Inc. ViRGE/GX2 (rev 6). Medium devsel. IRQ 16. Master Capable. Latency=64. Min Gnt=4.Max Lat=255. Non-prefetchable 32 bit memory at 0xe000 [0xe000].
Poor SCSI drive performance on SMP machine, 2.2.16
I have an SMP machine (dual PII 400s) running 2.2.16 with one 10,000 RPM IBM 10 GB SCSI drive (AIC 7890 on motherboard, using aic7xxx.o), and four various IDE drives. The SCSI drive performs the worst. In tests of writing 100 MB and sync'ing, one of my IDE drives takes 31 seconds. The SCSI drive (while doing nothing else) took 2 minutes, 10 seconds. This is extremely noticable in file transfers that completely monopolize the SCSI drive, and are much slower than when involving the IDE drives. After a large data operation on the SCSI drive, the system will hang for several minutes. Anyone know what could be causing this? Thanks. Attached are some data to help. Thanks, Para-dox ([EMAIL PROTECTED]) CPU0 CPU1 0: 43661720 59171710IO-APIC-edge timer 1: 233992 282694IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 8: 1 0IO-APIC-edge rtc 13: 1 0 XT-PIC fpu 14: 20 10IO-APIC-edge ide0 15: 46455293 50354306IO-APIC-edge ide1 16: 14508949 14462778 IO-APIC-level eth0 17:39395544293901 IO-APIC-level eth1 18: 750747 761816 IO-APIC-level aic7xxx NMI: 0 ERR: 0 PCI devices found: Bus 0, device 0, function 0: Host bridge: Intel 440BX - 82443BX Host (rev 2). Medium devsel. Master Capable. Latency=64. Prefetchable 32 bit memory at 0xe800 [0xe808]. Bus 0, device 1, function 0: PCI bridge: Intel 440BX - 82443BX AGP (rev 2). Medium devsel. Master Capable. Latency=64. Min Gnt=136. Bus 0, device 7, function 0: ISA bridge: Intel 82371AB PIIX4 ISA (rev 2). Medium devsel. Fast back-to-back capable. Master Capable. No bursts. Bus 0, device 7, function 1: IDE interface: Intel 82371AB PIIX4 IDE (rev 1). Medium devsel. Fast back-to-back capable. Master Capable. Latency=64. I/O at 0xf000 [0xf001]. Bus 0, device 7, function 2: USB Controller: Intel 82371AB PIIX4 USB (rev 1). Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. Latency=64. I/O at 0xe000 [0xe001]. Bus 0, device 7, function 3: Bridge: Intel 82371AB PIIX4 ACPI (rev 2). Medium devsel. Fast back-to-back capable. Bus 0, device 8, function 0: Ethernet controller: Intel 82557 (rev 5). Medium devsel. Fast back-to-back capable. IRQ 16. Master Capable. Latency=64. Min Gnt=8.Max Lat=56. Prefetchable 32 bit memory at 0xef101000 [0xef101008]. I/O at 0xe400 [0xe401]. Non-prefetchable 32 bit memory at 0xef00 [0xef00]. Bus 0, device 9, function 0: Ethernet controller: Winbond NE2000-PCI (rev 0). Medium devsel. Fast back-to-back capable. IRQ 17. I/O at 0xe800 [0xe801]. Bus 0, device 12, function 0: SCSI storage controller: Adaptec AIC-7890/1 (rev 0). Medium devsel. Fast back-to-back capable. BIST capable. IRQ 18. Master Capable. Latency=64. Min Gnt=39.Max Lat=25. I/O at 0xec00 [0xec01]. Non-prefetchable 64 bit memory at 0xef10 [0xef14]. Bus 1, device 0, function 0: VGA compatible controller: S3 Inc. ViRGE/GX2 (rev 6). Medium devsel. IRQ 16. Master Capable. Latency=64. Min Gnt=4.Max Lat=255. Non-prefetchable 32 bit memory at 0xe000 [0xe000].
*Very* weird behavior from 2.2.14
My machine is/has: > Linux 2.2.14 > Red Hat 6.2 > Two PII 400 Mhz processors, but the kernel doesn't currently have SMP support compiled in > 256 MB RAM > Two ethernet cards using PCI NE2000 (ne2k-pci.c), vpre-1.00e 5/27/99 > One SCSI hard drive (boot, using aic7xxx.o), and four IDE drives. > Uptime of 93 days > eth0 is network connection using DHCP (dhcpcd) > eth1 is 100 MBPS LAN as address 192.168.1.1 Weird behavior is as follows: 1) When I ping other machines on the LAN from the linux machine, I get unpredictable behavior. Sometimes ping shows nothing, yet watching tcpdump and the hub between the machines, it is clear that the ICMPs are being sent and responded to accordingly in under 10 ms, but ping displays nothing except for, at random intervals, a single response with a normal or abnormally high time. 2) When I ping the machine's own IP (192.168.1.1), there is no network activity as normal, but the results reported are random. Sometimes there will be 100% packet loss, but sometimes it will work fine with intermitted periods of high ping times (going from 0.0 ms to 9000 ms). Strangely enough, even when the machine can't ping itself, from other computers on the LAN, it will respond fine. 3) I run samba to serve files to a windows machine on my LAN (192.168.1.70), and file transfer between them has suddenly become very slow. It was not like this before. I watch tcpdump from the linux machine and see the netbios packets happening at a slow rate, sometimes stalling. When I am streaming something like an mp3, the interrupts can last for 5 to 10 seconds and cause the mp3 to stop playing. This has never been this way before. It can even sometimes cut out completely. This is the first strange behavior I noticed after coming back from a week vacation, while the machine was left on. 4) This may or may not be related, but when I look up man-pages from tty1 as any user, certain text, such as variables names of C functions, do not show up on the screen. This only happens on tty1. They are perfectly fine on other terminals. I've tried "reset" to no success. Notes: 1) Attached are several pieces of log/program output to assist in debugging. 2) The follow messages may or not be related. These types of messages have been appearing in the kernel ring buffer (dmesg) for some time but I have never paid attention to it (nor do I know what it means): eth0: bogus packet: status=0x80 nxpg=0x57 size=1438 eth0: bogus packet: status=0x80 nxpg=0x58 size=1518 3) It has occured to me this may be due to outside attackers, but I have found no evidence to suggest this. Regards and thanks, Para-dox ([EMAIL PROTECTED]) ifconfig proc_cpuinfo proc_interrupts proc_ioports route rp_ping rp_tcpdump self_ping
*Very* weird behavior from 2.2.14
My machine is/has: Linux 2.2.14 Red Hat 6.2 Two PII 400 Mhz processors, but the kernel doesn't currently have SMP support compiled in 256 MB RAM Two ethernet cards using PCI NE2000 (ne2k-pci.c), vpre-1.00e 5/27/99 One SCSI hard drive (boot, using aic7xxx.o), and four IDE drives. Uptime of 93 days eth0 is network connection using DHCP (dhcpcd) eth1 is 100 MBPS LAN as address 192.168.1.1 Weird behavior is as follows: 1) When I ping other machines on the LAN from the linux machine, I get unpredictable behavior. Sometimes ping shows nothing, yet watching tcpdump and the hub between the machines, it is clear that the ICMPs are being sent and responded to accordingly in under 10 ms, but ping displays nothing except for, at random intervals, a single response with a normal or abnormally high time. 2) When I ping the machine's own IP (192.168.1.1), there is no network activity as normal, but the results reported are random. Sometimes there will be 100% packet loss, but sometimes it will work fine with intermitted periods of high ping times (going from 0.0 ms to 9000 ms). Strangely enough, even when the machine can't ping itself, from other computers on the LAN, it will respond fine. 3) I run samba to serve files to a windows machine on my LAN (192.168.1.70), and file transfer between them has suddenly become very slow. It was not like this before. I watch tcpdump from the linux machine and see the netbios packets happening at a slow rate, sometimes stalling. When I am streaming something like an mp3, the interrupts can last for 5 to 10 seconds and cause the mp3 to stop playing. This has never been this way before. It can even sometimes cut out completely. This is the first strange behavior I noticed after coming back from a week vacation, while the machine was left on. 4) This may or may not be related, but when I look up man-pages from tty1 as any user, certain text, such as variables names of C functions, do not show up on the screen. This only happens on tty1. They are perfectly fine on other terminals. I've tried "reset" to no success. Notes: 1) Attached are several pieces of log/program output to assist in debugging. 2) The follow messages may or not be related. These types of messages have been appearing in the kernel ring buffer (dmesg) for some time but I have never paid attention to it (nor do I know what it means): eth0: bogus packet: status=0x80 nxpg=0x57 size=1438 eth0: bogus packet: status=0x80 nxpg=0x58 size=1518 3) It has occured to me this may be due to outside attackers, but I have found no evidence to suggest this. Regards and thanks, Para-dox ([EMAIL PROTECTED]) ifconfig proc_cpuinfo proc_interrupts proc_ioports route rp_ping rp_tcpdump self_ping
