Re: unable to read from IDE tape
Upgrade to mt-st version .5b or greater. Older mt versions had known bugs particularly with positioning. I suggest scsi emulation + scsi tape rather than ATAPI tape. rgds, tim. ... hdd: HP COLORADO 20GB, ATAPI TAPE drive ... scsi0 : SCSI host adapter emulation for IDE ATAPI devices scsi : 1 host. Vendor: HPModel: COLORADO 20GB Rev: 4.01 Type: Sequential-Access ANSI SCSI revision: 02 Detected scsi tape st0 at scsi0, channel 0, id 0, lun 0 ... [17:12] abit:/etc/dump > mt -v mt-st v. 0.5b [17:12] abit:/etc/dump > tar --version | head -1 tar (GNU tar) 1.13.17 [17:12] abit:/etc/dump > ls -l /dev/tape lrwxrwxrwx1 root root4 Jul 14 2000 /dev/tape -> nst0 [17:12] abit:/etc/dump > mt status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 512 bytes. Density code 0x47 (unknown to this mt). Soft error count since last status=0 General status bits on (4101): BOT ONLINE IM_REP_EN [17:12] abit:/etc/dump > tar cvf /dev/tape /boot tar: Removing leading `/' from member names boot/ boot/kernel.h boot/vmlinuz-2.2.14-12 boot/vmlinuz.prev boot/System.map.prev boot/linux-2.2.14-12 boot/linux-prev boot/linux-2.2.20p6ai boot/module-info boot/boot.b boot/chain.b ... [17:12] abit:/etc/dump > mt status SCSI 2 tape drive: File number=1, block number=0, partition=0. Tape block size 512 bytes. Density code 0x47 (unknown to this mt). Soft error count since last status=0 General status bits on (8101): EOF ONLINE IM_REP_EN [17:12] abit:/etc/dump > mt tell At block 11421. [17:12] abit:/etc/dump > mt rewind [17:13] abit:/etc/dump > mt status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 512 bytes. Density code 0x47 (unknown to this mt). Soft error count since last status=0 General status bits on (4101): BOT ONLINE IM_REP_EN [17:13] abit:/etc/dump > mt tell At block 0. [17:13] abit:/etc/dump > tar tvf /dev/tape drwxr-xr-x root/root 0 2001-06-25 22:21:52 boot/ -rw-r--r-- root/root 237 2001-05-03 23:04:36 boot/kernel.h -r--r--r-- root/root589225 2000-05-09 05:43:45 boot/vmlinuz-2.2.14-12 -rw-rw-r-- root/root606292 2001-06-25 18:08:21 boot/vmlinuz.prev -rw-rw-r-- root/root195903 2001-06-25 18:08:21 boot/System.map.prev lrwxrwxrwx root/root 0 2001-05-03 23:10:10 boot/linux-2.2.14-12 -> vmlinuz-2.2.14-12 lrwxrwxrwx root/root 0 2001-06-25 18:08:21 boot/linux-prev -> vmlinuz.prev lrwxrwxrwx root/root 0 2001-06-25 18:08:21 boot/linux-2.2.20p6ai -> vmlinuz-2.2.20p6ai-0625-18:08:09 lrwxrwxrwx root/root 0 2000-04-10 21:15:54 boot/module-info -> module-info-2.2.14-5.0 -rw-r--r-- root/root 4568 2000-02-02 14:03:10 boot/boot.b -rw-r--r-- root/root 612 2000-02-02 14:03:10 boot/chain.b ... [17:13] abit:/etc/dump > mt tell At block 11420. [17:14] abit:/etc/dump > mt status SCSI 2 tape drive: File number=0, block number=11420, partition=0. Tape block size 512 bytes. Density code 0x47 (unknown to this mt). Soft error count since last status=0 General status bits on (101): ONLINE IM_REP_EN [17:14] abit:/etc/dump > mt fsf 1 [17:14] abit:/etc/dump > mt tell At block 11421. [17:14] abit:/etc/dump > mt status SCSI 2 tape drive: File number=1, block number=0, partition=0. Tape block size 512 bytes. Density code 0x47 (unknown to this mt). Soft error count since last status=0 General status bits on (8101): EOF ONLINE IM_REP_EN -- - 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/
Re: unable to read from IDE tape
Upgrade to mt-st version .5b or greater. Older mt versions had known bugs particularly with positioning. I suggest scsi emulation + scsi tape rather than ATAPI tape. rgds, tim. ... hdd: HP COLORADO 20GB, ATAPI TAPE drive ... scsi0 : SCSI host adapter emulation for IDE ATAPI devices scsi : 1 host. Vendor: HPModel: COLORADO 20GB Rev: 4.01 Type: Sequential-Access ANSI SCSI revision: 02 Detected scsi tape st0 at scsi0, channel 0, id 0, lun 0 ... [17:12] abit:/etc/dump mt -v mt-st v. 0.5b [17:12] abit:/etc/dump tar --version | head -1 tar (GNU tar) 1.13.17 [17:12] abit:/etc/dump ls -l /dev/tape lrwxrwxrwx1 root root4 Jul 14 2000 /dev/tape - nst0 [17:12] abit:/etc/dump mt status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 512 bytes. Density code 0x47 (unknown to this mt). Soft error count since last status=0 General status bits on (4101): BOT ONLINE IM_REP_EN [17:12] abit:/etc/dump tar cvf /dev/tape /boot tar: Removing leading `/' from member names boot/ boot/kernel.h boot/vmlinuz-2.2.14-12 boot/vmlinuz.prev boot/System.map.prev boot/linux-2.2.14-12 boot/linux-prev boot/linux-2.2.20p6ai boot/module-info boot/boot.b boot/chain.b ... [17:12] abit:/etc/dump mt status SCSI 2 tape drive: File number=1, block number=0, partition=0. Tape block size 512 bytes. Density code 0x47 (unknown to this mt). Soft error count since last status=0 General status bits on (8101): EOF ONLINE IM_REP_EN [17:12] abit:/etc/dump mt tell At block 11421. [17:12] abit:/etc/dump mt rewind [17:13] abit:/etc/dump mt status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 512 bytes. Density code 0x47 (unknown to this mt). Soft error count since last status=0 General status bits on (4101): BOT ONLINE IM_REP_EN [17:13] abit:/etc/dump mt tell At block 0. [17:13] abit:/etc/dump tar tvf /dev/tape drwxr-xr-x root/root 0 2001-06-25 22:21:52 boot/ -rw-r--r-- root/root 237 2001-05-03 23:04:36 boot/kernel.h -r--r--r-- root/root589225 2000-05-09 05:43:45 boot/vmlinuz-2.2.14-12 -rw-rw-r-- root/root606292 2001-06-25 18:08:21 boot/vmlinuz.prev -rw-rw-r-- root/root195903 2001-06-25 18:08:21 boot/System.map.prev lrwxrwxrwx root/root 0 2001-05-03 23:10:10 boot/linux-2.2.14-12 - vmlinuz-2.2.14-12 lrwxrwxrwx root/root 0 2001-06-25 18:08:21 boot/linux-prev - vmlinuz.prev lrwxrwxrwx root/root 0 2001-06-25 18:08:21 boot/linux-2.2.20p6ai - vmlinuz-2.2.20p6ai-0625-18:08:09 lrwxrwxrwx root/root 0 2000-04-10 21:15:54 boot/module-info - module-info-2.2.14-5.0 -rw-r--r-- root/root 4568 2000-02-02 14:03:10 boot/boot.b -rw-r--r-- root/root 612 2000-02-02 14:03:10 boot/chain.b ... [17:13] abit:/etc/dump mt tell At block 11420. [17:14] abit:/etc/dump mt status SCSI 2 tape drive: File number=0, block number=11420, partition=0. Tape block size 512 bytes. Density code 0x47 (unknown to this mt). Soft error count since last status=0 General status bits on (101): ONLINE IM_REP_EN [17:14] abit:/etc/dump mt fsf 1 [17:14] abit:/etc/dump mt tell At block 11421. [17:14] abit:/etc/dump mt status SCSI 2 tape drive: File number=1, block number=0, partition=0. Tape block size 512 bytes. Density code 0x47 (unknown to this mt). Soft error count since last status=0 General status bits on (8101): EOF ONLINE IM_REP_EN -- - 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/
Re: AMD thunderbird oops
[EMAIL PROTECTED] wrote: > > Well considering the other night the power supply went dead, I think that is part of >the problem. It is brand new, and I am being sent another one (free of course). > > I also had my mb loaded at the time (scsi cd-rw, cdrom, internal zip, floppy, 1 hd, >Sound card, video, modem, NIC, scsi card) but my last tyan was fine with that load it >may be a kt7a thing. > > Several people said that random (keyword here) oopses are more often a hardware >thing. I wonder if the kt7a is going to be able to perform fully loaded.. > > is anyone running one fully loaded? 4 ide drives, 2 floppy, (5 pci and 1 isa) or >6pci, agp, 512MEG+ RAM? > > Joe Similar board (KA7) had non-heat related lockups with 133MHz FSB (1756 BogoM). 100MHz FSB + 4 way interleave has been fast and stable (1690 BogoM). /dev/hda: Timing buffer-cache reads: 128 MB in 1.00 seconds =128.00 MB/sec Abit KA7 (VT82C686a, rev 22), Athlon 850, 2x256MB PC133@CL2, 2 ide, CR-RW, Colorado Travan, linux 2.2.20p6+ide.2.2.19.04092001, SPI 300W power, PCI: Firewire, Netgear FA310TX, Turtle Beach Santa Cruz audio, AGP: 32MB TNT2. CONFIG_M686=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_1GB=y CONFIG_MTRR=y -- - 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/
Re: AMD thunderbird oops
> Some ASUS boards (mostly P3B-F) would either freeze or self reboot when using > PhotoShop 5. Everything else would run perfectly. > > Disabling MMX optimizations in this software would "solve" the problem. Another > solution found on the web (sorry, I don't have the URL at hand) is to add two > or three additionnal capacitors on the back of the board, to solve the electric > instabilities that cause the reboots. This is incorrect information. Abit BP6 early revs suffered under load from a 100uF cap (EC10, between the CPU sockets) that should have been 1500uF. This was compounded by a weak or otherwise inadequate power supply. Having run literally 7 P3F-Fs and 6 of their P2B-F predecessors, not a single one had any problems. They were the premiere overclocking boards of their day. rgds, Tim. -- - 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/
Re: AMD thunderbird oops
Some ASUS boards (mostly P3B-F) would either freeze or self reboot when using PhotoShop 5. Everything else would run perfectly. Disabling MMX optimizations in this software would solve the problem. Another solution found on the web (sorry, I don't have the URL at hand) is to add two or three additionnal capacitors on the back of the board, to solve the electric instabilities that cause the reboots. This is incorrect information. Abit BP6 early revs suffered under load from a 100uF cap (EC10, between the CPU sockets) that should have been 1500uF. This was compounded by a weak or otherwise inadequate power supply. Having run literally 7 P3F-Fs and 6 of their P2B-F predecessors, not a single one had any problems. They were the premiere overclocking boards of their day. rgds, Tim. -- - 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/
Re: AMD thunderbird oops
[EMAIL PROTECTED] wrote: Well considering the other night the power supply went dead, I think that is part of the problem. It is brand new, and I am being sent another one (free of course). I also had my mb loaded at the time (scsi cd-rw, cdrom, internal zip, floppy, 1 hd, Sound card, video, modem, NIC, scsi card) but my last tyan was fine with that load it may be a kt7a thing. Several people said that random (keyword here) oopses are more often a hardware thing. I wonder if the kt7a is going to be able to perform fully loaded.. is anyone running one fully loaded? 4 ide drives, 2 floppy, (5 pci and 1 isa) or 6pci, agp, 512MEG+ RAM? Joe Similar board (KA7) had non-heat related lockups with 133MHz FSB (1756 BogoM). 100MHz FSB + 4 way interleave has been fast and stable (1690 BogoM). /dev/hda: Timing buffer-cache reads: 128 MB in 1.00 seconds =128.00 MB/sec Abit KA7 (VT82C686a, rev 22), Athlon 850, 2x256MB PC133@CL2, 2 ide, CR-RW, Colorado Travan, linux 2.2.20p6+ide.2.2.19.04092001, SPI 300W power, PCI: Firewire, Netgear FA310TX, Turtle Beach Santa Cruz audio, AGP: 32MB TNT2. CONFIG_M686=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_1GB=y CONFIG_MTRR=y -- - 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/
Re: [BUG] 2.2.19 -> 80% Packet Loss
[EMAIL PROTECTED] wrote: > ... > 2. A "ping -f -s 64589" to a machine running kernel 2.2.19 results in 0% > packet loss. By incrementing the packetsize by one "ping -f -s 64590" or > higher, I consistently see 80% packet loss. ifconfig on the receiving > machine shows no anomolies. > ... > 4. Linux version 2.2.19-7.0.1 ([EMAIL PROTECTED]) (gcc version > egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue Apr 10 00:55:03 > EDT 2001 No problems here. rgds, tim. [note: -ai = athlon kernel + ide patch] [tim@abit cron.daily]# cat /proc/version Linux version 2.2.20p2-ai (root@abit) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #12 Fri May 25 16:31:02 PDT 2001 [tim@abit cron.daily]# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:A0:CC:57:89:93 inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10204 errors:0 dropped:0 overruns:0 frame:0 TX packets:15280 errors:1 dropped:0 overruns:0 carrier:1 collisions:0 txqueuelen:100 Interrupt:11 Base address:0xec00 [tim@abit cron.daily]# ping -f -s 64590 dell PING dell.yoyodyne.org (192.168.1.11) from 192.168.1.10 : 64590(64618) bytes of data. Warning: no SO_RCVTIMEO support, falling back to poll .. --- dell.yoyodyne.org ping statistics --- 639 packets transmitted, 637 packets received, 0% packet loss round-trip min/avg/max/mdev = 15.852/16.406/38.972/2.068 ms [tim@abit cron.daily]# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:A0:CC:57:89:93 inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:38312 errors:0 dropped:0 overruns:0 frame:0 TX packets:43421 errors:3 dropped:0 overruns:2 carrier:1 collisions:0 txqueuelen:100 Interrupt:11 Base address:0xec00 [tim@abit cron.daily]# ping dell -c 3 PING dell.yoyodyne.org (192.168.1.11) from 192.168.1.10 : 56(84) bytes of data. 64 bytes from dell.yoyodyne.org (192.168.1.11): icmp_seq=0 ttl=255 time=334 usec 64 bytes from dell.yoyodyne.org (192.168.1.11): icmp_seq=1 ttl=255 time=294 usec 64 bytes from dell.yoyodyne.org (192.168.1.11): icmp_seq=2 ttl=255 time=296 usec --- dell.yoyodyne.org ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.294/0.308/0.334/0.018 ms [tim@abit cron.daily]# ifconfig lo loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:724500 errors:0 dropped:0 overruns:0 frame:0 TX packets:724500 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 [tim@abit cron.daily]# ping -f -s 64590 localhost PING localhost (127.0.0.1) from 127.0.0.1 : 64590(64618) bytes of data. Warning: no SO_RCVTIMEO support, falling back to poll . --- localhost ping statistics --- 7754 packets transmitted, 7754 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.960/1.011/25.556/0.623 ms [tim@abit cron.daily]# ifconfig lo loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:988136 errors:0 dropped:0 overruns:0 frame:0 TX packets:988136 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 -- - 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/
Re: [BUG] 2.2.19 -> 80% Packet Loss
José Luis Domingo López wrote: > > On Thursday, 14 June 2001, at 14:17:11 -0700, > [EMAIL PROTECTED] wrote: > > > > > 1. When pinging a machine using kernel 2.2.19 I consistently get an 80% > > packet loss when doing a ping -f with a packet size of 64590 or higher. > > > What happens here is (under kernel 2.2.19): > ping -f -s 49092 localhost -->> 0 % packet loss > ping -f -s 49093 localhost -->> 100 % packet loss [tim@abit cron.daily]# ping -w 10 -f -s 49093 localhost PING localhost (127.0.0.1) from 127.0.0.1 : 49093(49121) bytes of data. Warning: no SO_RCVTIMEO support, falling back to poll . --- localhost ping statistics --- 8051 packets transmitted, 8051 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.517/0.751/25.336/0.678 ms > Maybe this has something to do with fragmentation of IP packets to fit in > the underlying protocol's MTU (3929 in my loopback device). [tim@abit cron.daily]# ifconfig lo loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:1197462 errors:0 dropped:0 overruns:0 frame:0 TX packets:1197462 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 [tim@abit cron.daily]# cat /proc/version Linux version 2.2.20p2-ai (root@abit) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #12 Fri May 25 16:31:02 PDT 2001 -- - 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/
Re: [BUG] 2.2.19 - 80% Packet Loss
[EMAIL PROTECTED] wrote: ... 2. A ping -f -s 64589 to a machine running kernel 2.2.19 results in 0% packet loss. By incrementing the packetsize by one ping -f -s 64590 or higher, I consistently see 80% packet loss. ifconfig on the receiving machine shows no anomolies. ... 4. Linux version 2.2.19-7.0.1 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue Apr 10 00:55:03 EDT 2001 No problems here. rgds, tim. [note: -ai = athlon kernel + ide patch] [tim@abit cron.daily]# cat /proc/version Linux version 2.2.20p2-ai (root@abit) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #12 Fri May 25 16:31:02 PDT 2001 [tim@abit cron.daily]# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:A0:CC:57:89:93 inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10204 errors:0 dropped:0 overruns:0 frame:0 TX packets:15280 errors:1 dropped:0 overruns:0 carrier:1 collisions:0 txqueuelen:100 Interrupt:11 Base address:0xec00 [tim@abit cron.daily]# ping -f -s 64590 dell PING dell.yoyodyne.org (192.168.1.11) from 192.168.1.10 : 64590(64618) bytes of data. Warning: no SO_RCVTIMEO support, falling back to poll .. --- dell.yoyodyne.org ping statistics --- 639 packets transmitted, 637 packets received, 0% packet loss round-trip min/avg/max/mdev = 15.852/16.406/38.972/2.068 ms [tim@abit cron.daily]# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:A0:CC:57:89:93 inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:38312 errors:0 dropped:0 overruns:0 frame:0 TX packets:43421 errors:3 dropped:0 overruns:2 carrier:1 collisions:0 txqueuelen:100 Interrupt:11 Base address:0xec00 [tim@abit cron.daily]# ping dell -c 3 PING dell.yoyodyne.org (192.168.1.11) from 192.168.1.10 : 56(84) bytes of data. 64 bytes from dell.yoyodyne.org (192.168.1.11): icmp_seq=0 ttl=255 time=334 usec 64 bytes from dell.yoyodyne.org (192.168.1.11): icmp_seq=1 ttl=255 time=294 usec 64 bytes from dell.yoyodyne.org (192.168.1.11): icmp_seq=2 ttl=255 time=296 usec --- dell.yoyodyne.org ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.294/0.308/0.334/0.018 ms [tim@abit cron.daily]# ifconfig lo loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:724500 errors:0 dropped:0 overruns:0 frame:0 TX packets:724500 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 [tim@abit cron.daily]# ping -f -s 64590 localhost PING localhost (127.0.0.1) from 127.0.0.1 : 64590(64618) bytes of data. Warning: no SO_RCVTIMEO support, falling back to poll . --- localhost ping statistics --- 7754 packets transmitted, 7754 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.960/1.011/25.556/0.623 ms [tim@abit cron.daily]# ifconfig lo loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:988136 errors:0 dropped:0 overruns:0 frame:0 TX packets:988136 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 -- - 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/
Re: [BUG] 2.2.19 - 80% Packet Loss
José Luis Domingo López wrote: On Thursday, 14 June 2001, at 14:17:11 -0700, [EMAIL PROTECTED] wrote: 1. When pinging a machine using kernel 2.2.19 I consistently get an 80% packet loss when doing a ping -f with a packet size of 64590 or higher. What happens here is (under kernel 2.2.19): ping -f -s 49092 localhost -- 0 % packet loss ping -f -s 49093 localhost -- 100 % packet loss [tim@abit cron.daily]# ping -w 10 -f -s 49093 localhost PING localhost (127.0.0.1) from 127.0.0.1 : 49093(49121) bytes of data. Warning: no SO_RCVTIMEO support, falling back to poll . --- localhost ping statistics --- 8051 packets transmitted, 8051 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.517/0.751/25.336/0.678 ms Maybe this has something to do with fragmentation of IP packets to fit in the underlying protocol's MTU (3929 in my loopback device). [tim@abit cron.daily]# ifconfig lo loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:1197462 errors:0 dropped:0 overruns:0 frame:0 TX packets:1197462 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 [tim@abit cron.daily]# cat /proc/version Linux version 2.2.20p2-ai (root@abit) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #12 Fri May 25 16:31:02 PDT 2001 -- - 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/
Re: nfs mount by label not working.
v2.10r works. [tim@abit tim]# mount -V mount: mount-2.10r [tim@abit tim]# tune2fs -L spare /dev/hda10 tune2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 [tim@abit tim]# mount -L spare /mnt [tim@abit tim]# df /mnt Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda10 3028080 2100116927964 69% /mnt [tim@abit tim]# cat /proc/version Linux version 2.2.20p2aa1-a (root@abit) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #2 Sat May 19 18:46:38 PDT 2001 Dave Mielke wrote: > > Using kernel 2.2.17-14 as supplied by RedHat, and using mount from > mount-2.9u-4, mounting by label using the -L option does not work. > > mount -L backup1 /a > mount: no such partition found ... > Does something need to be enabled to make this work? What else might I be doing > wrong? -- - 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/
Re: nfs mount by label not working.
v2.10r works. [tim@abit tim]# mount -V mount: mount-2.10r [tim@abit tim]# tune2fs -L spare /dev/hda10 tune2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 [tim@abit tim]# mount -L spare /mnt [tim@abit tim]# df /mnt Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda10 3028080 2100116927964 69% /mnt [tim@abit tim]# cat /proc/version Linux version 2.2.20p2aa1-a (root@abit) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #2 Sat May 19 18:46:38 PDT 2001 Dave Mielke wrote: Using kernel 2.2.17-14 as supplied by RedHat, and using mount from mount-2.9u-4, mounting by label using the -L option does not work. mount -L backup1 /a mount: no such partition found ... Does something need to be enabled to make this work? What else might I be doing wrong? -- - 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/
[OT] IBM offers 6% ThinkPad linux discount on phone
While browsing IBM ThinkPads online I noticed only one high-end model with linux. I called 1-888-SHOP-IBMx7000 (phone sales) to inquire how to get a ThinkPad without Windows given I would be immediately installing linux. I was offered 6% off the online price for any Thinkpad which in my case was $118 US. That sounded about right for a per unit bundle deal between IBM and MS. I called from the US and the phone rep was in Canada. rgds, tim. -- - 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/
[OT] IBM offers 6% ThinkPad linux discount on phone
While browsing IBM ThinkPads online I noticed only one high-end model with linux. I called 1-888-SHOP-IBMx7000 (phone sales) to inquire how to get a ThinkPad without Windows given I would be immediately installing linux. I was offered 6% off the online price for any Thinkpad which in my case was $118 US. That sounded about right for a per unit bundle deal between IBM and MS. I called from the US and the phone rep was in Canada. rgds, tim. -- - 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/
ncr53c8xx - DAT detection problem - 2.2.14-5
Any clues as to why /dev/st0 is never initialized for DAT tape? Please cc [EMAIL PROTECTED] if more info is needed. rgds, tim. ... ncr53c8xx: at PCI bus 1, device 9, function 0 ncr53c8xx: 53c876 detected ncr53c8xx: at PCI bus 1, device 9, function 1 ncr53c8xx: 53c876 detected ncr53c876-0: rev=0x14, base=0xc6ffdf00, io_port=0x3000, irq=5 ncr53c876-0: ID 7, Fast-20, Parity Checking ncr53c876-0: on-chip RAM at 0xc6fff000 ncr53c876-0: restart (scsi reset). ncr53c876-0: Downloading SCSI SCRIPTS. ncr53c876-1: rev=0x14, base=0xc6ffde00, io_port=0x3400, irq=9 ncr53c876-1: ID 7, Fast-20, Parity Checking ncr53c876-1: on-chip RAM at 0xc6ffe000 ncr53c876-1: restart (scsi reset). ncr53c876-1: Downloading SCSI SCRIPTS. scsi0 : ncr53c8xx - version 3.2a-2 scsi1 : ncr53c8xx - version 3.2a-2 scsi : 2 hosts. Vendor: COMPAQModel: BD0096349ARev: 3B05 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 Vendor: COMPAQModel: BD0096349ARev: 3B05 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sdb at scsi0, channel 0, id 1, lun 0 ncr53c876-0-<0,0>: tagged command queue depth set to 8 ncr53c876-0-<1,0>: tagged command queue depth set to 8 Vendor: SEAGATE Model: DAT04106-XXX Rev: 735B Type: Sequential-Access ANSI SCSI revision: 02 ncr53c876-0-<0,*>: FAST-20 WIDE SCSI 40.0 MB/s (50 ns, offset 16) SCSI device sda: hdwr sector= 512 bytes. Sectors= 17773524 [8678 MB] [8.7 GB] sda: sda1 sda2 < sda5 > ncr53c876-0-<1,*>: FAST-20 WIDE SCSI 40.0 MB/s (50 ns, offset 16) SCSI device sdb: hdwr sector= 512 bytes. Sectors= 17773524 [8678 MB] [8.7 GB] sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 > ... /sbin/lspci -v 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (AGP disa bled) (rev 03) Flags: bus master, medium devsel, latency 64 Memory at (32-bit, prefetchable) 00:0b.0 VGA compatible controller: Cirrus Logic GD 5446 (rev 45) (prog-if 00 [VGA] ) Flags: medium devsel Memory at c400 (32-bit, prefetchable) Memory at c6dff000 (32-bit, non-prefetchable) 00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 04) (prog-if 00 [Normal decode]) Flags: bus master, medium devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 Capabilities: [dc] Power Management version 1 00:0e.0 System peripheral: Compaq Computer Corporation: Unknown device a0f0 Subsystem: Compaq Computer Corporation: Unknown device b0f3 Flags: medium devsel I/O ports at 1800 Memory at c6dfdf00 (32-bit, non-prefetchable) 00:12.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) Subsystem: Intel Corporation EtherExpress PRO/100+ Management Adapter Flags: bus master, medium devsel, latency 64, IRQ 10 Memory at c6dfe000 (32-bit, non-prefetchable) I/O ports at 2000 Memory at c6e0 (32-bit, non-prefetchable) Capabilities: [dc] Power Management version 2 00:14.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) Flags: bus master, medium devsel, latency 0 00:14.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80 [Master]) Flags: bus master, medium devsel, latency 64 I/O ports at f100 00:14.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)(prog-if 00 [UHCI]) Flags: medium devsel I/O ports at 5800 00:14.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) Flags: medium devsel 01:07.0 Network controller: Compaq Computer Corporation ProLiant Integrated Netelligent 10/100 (rev 10) Flags: medium devsel I/O ports at 5820 01:09.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 14) Subsystem: Compaq Computer Corporation Embedded Ultra Wide SCSI Controller Flags: bus master, medium devsel, latency 255, IRQ 5 I/O ports at 3000 Memory at c6ffdf00 (32-bit, non-prefetchable) Memory at c6fff000 (32-bit, non-prefetchable) 01:09.1 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 14) Subsystem: Compaq Computer Corporation Embedded Ultra Wide SCSI Controller Flags: bus master, medium devsel, latency 255, IRQ 9 I/O ports at 3400 Memory at c6ffde00 (32-bit, non-prefetchable) Memory at c6ffe000 (32-bit, non-prefetchable) -- - 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/
Re: ATAPI Tape Driver Failure in Kernel 2.4.4, More
> > to do is be able to write to the tape, but not read from it. > > Even in 2.2.x, putting the IDE patches in, breaks it. Apparently > > the HP's aren't completely ATAPI compatible scsi0 : SCSI host adapter emulation for IDE ATAPI devices scsi : 1 host. Vendor: HPModel: COLORADO 20GB Rev: 4.01 Type: Sequential-Access ANSI SCSI revision: 02 Detected scsi tape st0 at scsi0, channel 0, id 0, lun 0 The following all work with the above, either ide.2.2.19.04092001.patch or ide.2.2.18.1221.patch: linux-2.2.19pre17-ide linux-2.2.19-intel-hpt-smp linux-2.2.19-amd-via-ide linux-2.2.20p2-amd-via-ide [14:17] abit:/etc/dump > more *.block :: dump0-abit-2.2.19-050401-06:43:36.block :: / 0 dump /usr90113 dump /var3593378 dump /tmp3675075 dump /home 3692644 dump /kits 5237605 dump /big9440550 dump :: dump1-abit-2.2.20-050901-17:10:08.block :: / 14567911dump /usr14574120dump /var14810569dump /tmp14832970dump /home 14833227dump /kits 15199116dump /big15850029dump [14:17] abit:/etc/dump > mt seek 14567911 [14:18] abit:/etc/dump > mt tell At block 14567911. [14:20] abit:/etc/dump > /sbin/restore -t -f /dev/nst0 | head Level 1 dump of / on abit:/dev/hda2 Label: "abit-2.2.20" Dump date: Wed May 9 17:11:53 2001 Dumped from: Fri May 4 06:43:36 2001 2 . 11 ./lost+found 4065 ./lost+found/#4065 4019 ./dev 4030 ./dev/initctl 4083 ./dev/audio 4084 ./dev/audio1 4111 ./dev/console rgds, tim. -- - 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/
Re: ATAPI Tape Driver Failure in Kernel 2.4.4, More
to do is be able to write to the tape, but not read from it. Even in 2.2.x, putting the IDE patches in, breaks it. Apparently the HP's aren't completely ATAPI compatible scsi0 : SCSI host adapter emulation for IDE ATAPI devices scsi : 1 host. Vendor: HPModel: COLORADO 20GB Rev: 4.01 Type: Sequential-Access ANSI SCSI revision: 02 Detected scsi tape st0 at scsi0, channel 0, id 0, lun 0 The following all work with the above, either ide.2.2.19.04092001.patch or ide.2.2.18.1221.patch: linux-2.2.19pre17-ide linux-2.2.19-intel-hpt-smp linux-2.2.19-amd-via-ide linux-2.2.20p2-amd-via-ide [14:17] abit:/etc/dump more *.block :: dump0-abit-2.2.19-050401-06:43:36.block :: / 0 dump /usr90113 dump /var3593378 dump /tmp3675075 dump /home 3692644 dump /kits 5237605 dump /big9440550 dump :: dump1-abit-2.2.20-050901-17:10:08.block :: / 14567911dump /usr14574120dump /var14810569dump /tmp14832970dump /home 14833227dump /kits 15199116dump /big15850029dump [14:17] abit:/etc/dump mt seek 14567911 [14:18] abit:/etc/dump mt tell At block 14567911. [14:20] abit:/etc/dump /sbin/restore -t -f /dev/nst0 | head Level 1 dump of / on abit:/dev/hda2 Label: abit-2.2.20 Dump date: Wed May 9 17:11:53 2001 Dumped from: Fri May 4 06:43:36 2001 2 . 11 ./lost+found 4065 ./lost+found/#4065 4019 ./dev 4030 ./dev/initctl 4083 ./dev/audio 4084 ./dev/audio1 4111 ./dev/console rgds, tim. -- - 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/
ncr53c8xx - DAT detection problem - 2.2.14-5
Any clues as to why /dev/st0 is never initialized for DAT tape? Please cc [EMAIL PROTECTED] if more info is needed. rgds, tim. ... ncr53c8xx: at PCI bus 1, device 9, function 0 ncr53c8xx: 53c876 detected ncr53c8xx: at PCI bus 1, device 9, function 1 ncr53c8xx: 53c876 detected ncr53c876-0: rev=0x14, base=0xc6ffdf00, io_port=0x3000, irq=5 ncr53c876-0: ID 7, Fast-20, Parity Checking ncr53c876-0: on-chip RAM at 0xc6fff000 ncr53c876-0: restart (scsi reset). ncr53c876-0: Downloading SCSI SCRIPTS. ncr53c876-1: rev=0x14, base=0xc6ffde00, io_port=0x3400, irq=9 ncr53c876-1: ID 7, Fast-20, Parity Checking ncr53c876-1: on-chip RAM at 0xc6ffe000 ncr53c876-1: restart (scsi reset). ncr53c876-1: Downloading SCSI SCRIPTS. scsi0 : ncr53c8xx - version 3.2a-2 scsi1 : ncr53c8xx - version 3.2a-2 scsi : 2 hosts. Vendor: COMPAQModel: BD0096349ARev: 3B05 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 Vendor: COMPAQModel: BD0096349ARev: 3B05 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sdb at scsi0, channel 0, id 1, lun 0 ncr53c876-0-0,0: tagged command queue depth set to 8 ncr53c876-0-1,0: tagged command queue depth set to 8 Vendor: SEAGATE Model: DAT04106-XXX Rev: 735B Type: Sequential-Access ANSI SCSI revision: 02 ncr53c876-0-0,*: FAST-20 WIDE SCSI 40.0 MB/s (50 ns, offset 16) SCSI device sda: hdwr sector= 512 bytes. Sectors= 17773524 [8678 MB] [8.7 GB] sda: sda1 sda2 sda5 ncr53c876-0-1,*: FAST-20 WIDE SCSI 40.0 MB/s (50 ns, offset 16) SCSI device sdb: hdwr sector= 512 bytes. Sectors= 17773524 [8678 MB] [8.7 GB] sdb: sdb1 sdb2 sdb5 sdb6 sdb7 ... /sbin/lspci -v 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (AGP disa bled) (rev 03) Flags: bus master, medium devsel, latency 64 Memory at unassigned (32-bit, prefetchable) 00:0b.0 VGA compatible controller: Cirrus Logic GD 5446 (rev 45) (prog-if 00 [VGA] ) Flags: medium devsel Memory at c400 (32-bit, prefetchable) Memory at c6dff000 (32-bit, non-prefetchable) 00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 04) (prog-if 00 [Normal decode]) Flags: bus master, medium devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 Capabilities: [dc] Power Management version 1 00:0e.0 System peripheral: Compaq Computer Corporation: Unknown device a0f0 Subsystem: Compaq Computer Corporation: Unknown device b0f3 Flags: medium devsel I/O ports at 1800 Memory at c6dfdf00 (32-bit, non-prefetchable) 00:12.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) Subsystem: Intel Corporation EtherExpress PRO/100+ Management Adapter Flags: bus master, medium devsel, latency 64, IRQ 10 Memory at c6dfe000 (32-bit, non-prefetchable) I/O ports at 2000 Memory at c6e0 (32-bit, non-prefetchable) Capabilities: [dc] Power Management version 2 00:14.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) Flags: bus master, medium devsel, latency 0 00:14.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80 [Master]) Flags: bus master, medium devsel, latency 64 I/O ports at f100 00:14.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)(prog-if 00 [UHCI]) Flags: medium devsel I/O ports at 5800 00:14.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) Flags: medium devsel 01:07.0 Network controller: Compaq Computer Corporation ProLiant Integrated Netelligent 10/100 (rev 10) Flags: medium devsel I/O ports at 5820 01:09.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 14) Subsystem: Compaq Computer Corporation Embedded Ultra Wide SCSI Controller Flags: bus master, medium devsel, latency 255, IRQ 5 I/O ports at 3000 Memory at c6ffdf00 (32-bit, non-prefetchable) Memory at c6fff000 (32-bit, non-prefetchable) 01:09.1 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 14) Subsystem: Compaq Computer Corporation Embedded Ultra Wide SCSI Controller Flags: bus master, medium devsel, latency 255, IRQ 9 I/O ports at 3400 Memory at c6ffde00 (32-bit, non-prefetchable) Memory at c6ffe000 (32-bit, non-prefetchable) -- - 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/
Re: ATAPI Tape Driver Failure in Kernel 2.4.4, More
Use SCSI emulation instead of ATAPI for the tape device. Also make sure
your mt is >= 0.5.
[tim@abit tim]# mt -v
mt-st v. 0.5b
[tim@abit linux]# dump -v
dump 0.4b
[tim@abit linux]# restore -v
restore 0.4b17
[dmesg exerpts - tape is /dev/st0]
...
hdd: HP COLORADO 20GB, ATAPI TAPE drive
...
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
scsi : 1 host.
Vendor: HPModel: COLORADO 20GB Rev: 4.01
Type: Sequential-Access ANSI SCSI revision: 02
Detected scsi tape st0 at scsi0, channel 0, id 0, lun 0
...
for 2.2.x .config:
CONFIG_BLK_DEV_IDESCSI
#CONFIG_BLK_DEV_IDETAPE
CONFIG_SCSI
CONFIG_CHR_DEV_ST
> immediately after the backup completes and I try to write a file mark with "mt":
>
> May 9 16:50:49 isaiah kernel: ide-tape: Reached idetape_chrdev_open
> May 9 16:52:05 isaiah kernel: hdd: irq timeout: status=0xd0 { Busy }
> May 9 16:52:05 isaiah kernel: hdd: ATAPI reset complete
> May 9 16:52:05 isaiah kernel: ide-tape: Couldn't write a filemark
> May 9 16:52:06 isaiah kernel: ide-tape: Reached idetape_chrdev_open
> May 9 16:54:06 isaiah kernel: ide-tape: ht0: DSC timeout
> May 9 16:54:06 isaiah kernel: hdd: ATAPI reset complete
> ...
--
| 650.390.9613 | [EMAIL PROTECTED]
-
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/
Re: ATAPI Tape Driver Failure in Kernel 2.4.4, More
Use SCSI emulation instead of ATAPI for the tape device. Also make sure
your mt is = 0.5.
[tim@abit tim]# mt -v
mt-st v. 0.5b
[tim@abit linux]# dump -v
dump 0.4b
[tim@abit linux]# restore -v
restore 0.4b17
[dmesg exerpts - tape is /dev/st0]
...
hdd: HP COLORADO 20GB, ATAPI TAPE drive
...
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
scsi : 1 host.
Vendor: HPModel: COLORADO 20GB Rev: 4.01
Type: Sequential-Access ANSI SCSI revision: 02
Detected scsi tape st0 at scsi0, channel 0, id 0, lun 0
...
for 2.2.x .config:
CONFIG_BLK_DEV_IDESCSI
#CONFIG_BLK_DEV_IDETAPE
CONFIG_SCSI
CONFIG_CHR_DEV_ST
immediately after the backup completes and I try to write a file mark with mt:
May 9 16:50:49 isaiah kernel: ide-tape: Reached idetape_chrdev_open
May 9 16:52:05 isaiah kernel: hdd: irq timeout: status=0xd0 { Busy }
May 9 16:52:05 isaiah kernel: hdd: ATAPI reset complete
May 9 16:52:05 isaiah kernel: ide-tape: Couldn't write a filemark
May 9 16:52:06 isaiah kernel: ide-tape: Reached idetape_chrdev_open
May 9 16:54:06 isaiah kernel: ide-tape: ht0: DSC timeout
May 9 16:54:06 isaiah kernel: hdd: ATAPI reset complete
...
--
| 650.390.9613 | [EMAIL PROTECTED]
-
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/
Re: 2.2.19 locks up on SMP
> > Obvious question is, which compiler. > > I hadn't seen any locks, but (on a dual Pmmx 200) it started crawling > right after the NIC module (tulip) was loaded. System load decided to > skyrocket. > > Yadda... 2.2.19 with devfs patch. > bicycle:~# gcc -v > Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.3/specs > gcc version 2.95.3 20010315 (Debian release) > > Might be the same problem. Twin Abit BP6's, 2.2.19 + 9-Apr ide patch, no problems. egcs-2.91.66 tulip.c:v0.91g-ppc 7/16/99 [EMAIL PROTECTED] eth0: Lite-On 82c168 PNIC rev 32 at 0xc800, 00:A0:CC:57:89:93, IRQ 16. -- | 650.390.9613 | [EMAIL PROTECTED] - 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/
Re: linux and high volume web sites
David Lang wrote: > > watch the resonate heartbeat and see if it is getting lost in the network > traffic (the resonate logs will show missing heartbeat packets). think > seriously of setting the resonate stuff to run at a higher priority so > that it doesn't get behind. > > depending on how high your network traffic is seriously look at putting in > a second nic and switch to move the NFS traffic off the network that has > the internet traffic and hearbeat. > > I had the same problem with central dispatch a couple years ago when first > implementing it. the exact details of the problem that I ran into should > have been fixed by now (mostly having to do with large number of virtual > IP addresses) but the symptoms were the same. In addition to the above make sure there's enough bandwidth to the filer (eg- good switches, multiple ethernets). Consider moving to 2.2.19. Significant VM changes after 2.2.19pre3 which could account for the freezes. rgds, tim. > > I have a high volume web site under linux : > > kernel is 2.2.17 > > hardware is 5 bi-PIII 700Mhz / 512Mb, eepro100 > > all server are diskless (nfs on an netapp filer) except for tmp and swap > > > > dispatch is done by the Resonate product > > > > web server is apache+php (something like 400 processes), database > > backend is a mysql on the same hardware > > > > in high volume from time to time machines are "freezing" then after a > > few seconds they "reappear" and response timne is > > > > > > how can I investigate all these problems ? -- - 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/
Re: 2.2.19 locks up on SMP
Obvious question is, which compiler. I hadn't seen any locks, but (on a dual Pmmx 200) it started crawling right after the NIC module (tulip) was loaded. System load decided to skyrocket. Yadda... 2.2.19 with devfs patch. bicycle:~# gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.3/specs gcc version 2.95.3 20010315 (Debian release) Might be the same problem. Twin Abit BP6's, 2.2.19 + 9-Apr ide patch, no problems. egcs-2.91.66 tulip.c:v0.91g-ppc 7/16/99 [EMAIL PROTECTED] eth0: Lite-On 82c168 PNIC rev 32 at 0xc800, 00:A0:CC:57:89:93, IRQ 16. -- | 650.390.9613 | [EMAIL PROTECTED] - 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/
[PATCH] hpt366.c, *bad_ata66_4 additions (2.2.19 + ide.2.2.19.04092001.patch)
(2.2.19 + ide.2.2.19.04092001.patch)
--- drivers/block/hpt366.c Fri Apr 20 14:23:54 2001
+++ drivers/block/hpt366.new.c Fri Apr 27 16:30:13 2001
@@ -56,8 +56,11 @@
const char *bad_ata66_4[] = {
"IBM-DTLA-307075",
+ "IBM-DTLA-307060",
"IBM-DTLA-307045",
"IBM-DTLA-307030",
+ "IBM-DTLA-307020",
+ "IBM-DTLA-307015",
"WDC AC310200R",
NULL
};
Can we assume the rest of the Deskstar 75GXP family has the same problems?
hdg: IBM-DTLA-307020, 19623MB w/1916kB Cache, CHS=39870/16/63, UDMA(66)
hdh: IBM-DTLA-307020, 19623MB w/1916kB Cache, CHS=39870/16/63, UDMA(66)
http://www.storage.ibm.com/hardsoft/diskdrdl/desk/ds75gxp.htm
Deskstar 75GXP Interface Capacity (GB) RPM
DTLA-307015 Ultra ATA/100 15.36 7200
DTLA-307020 Ultra ATA/100 20.57 7200
DTLA-307030 Ultra ATA/100 30.73 7200
DTLA-307045 Ultra ATA/100 46.11 7200
DTLA-307060 Ultra ATA/100 61.49 7200
DTLA-307075 Ultra ATA/100 76.86 7200
rgds,
tim.
--
-
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/
Re: Can't read SCSI TAPE
> mt : mt-st v. 0.4 Also mt-st < v0.5b were fairly broken especially with positioning. rgds, tim. -- - 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/
Re: 2.2.19 Realaudio masq problem
I've been running masquerading unchanged from 2.2.13, currently 2.2.19 as: real IP + masq. 192.168.1.NNN DSL <-> gateway <-> switch <-> client 1 server <-> client 2 ... <-> client n There was some general slowness over the last few days (Bay Area, California <-> US East Coast) including realaudio being unable to locate servers and/or content. This one is working right now: RealPlayer v 7.0.3.338 abit:~ > cat On24ram.asp rtsp://rm.on24.com/media/news/04192001/palumbo_ted6.rm --stop-- http://rm.on24.com/media/news/04192001/palumbo_ted6.rm Try '# strace /usr/bin/X11/realplay On24ram.asp > log' and see where the connect fails if you aren't getting specific error messages. rgds, tim. Whit Blauvelt wrote: > > The Release Notes say "Fix problems with realaudio masquerading". Looked > promising, since with 2.2.17 one masqueraded system (but not another) was > having occassional problems with realaudio at some (but not all) sites. > > Compiled 2.2.19 with 'make oldconfig,' no to new options. Otherwise running > with the same firewall and masquerading settings (and yes I built and > installed ip_masq_raudio.o). Masquerading is otherwise working, but now > neither masqueraded system can connect with realaudio - the realplay routine > to find a way to make a connection automatically fails for both. rgds, tim. -- - 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/
Re: 2.2.19 Realaudio masq problem
I've been running masquerading unchanged from 2.2.13, currently 2.2.19 as: real IP + masq. 192.168.1.NNN DSL - gateway - switch - client 1 server - client 2 ... - client n There was some general slowness over the last few days (Bay Area, California - US East Coast) including realaudio being unable to locate servers and/or content. This one is working right now: RealPlayer v 7.0.3.338 abit:~ cat On24ram.asp rtsp://rm.on24.com/media/news/04192001/palumbo_ted6.rm --stop-- http://rm.on24.com/media/news/04192001/palumbo_ted6.rm Try '# strace /usr/bin/X11/realplay On24ram.asp log' and see where the connect fails if you aren't getting specific error messages. rgds, tim. Whit Blauvelt wrote: The Release Notes say Fix problems with realaudio masquerading. Looked promising, since with 2.2.17 one masqueraded system (but not another) was having occassional problems with realaudio at some (but not all) sites. Compiled 2.2.19 with 'make oldconfig,' no to new options. Otherwise running with the same firewall and masquerading settings (and yes I built and installed ip_masq_raudio.o). Masquerading is otherwise working, but now neither masqueraded system can connect with realaudio - the realplay routine to find a way to make a connection automatically fails for both. rgds, tim. -- - 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/
Re: Can't read SCSI TAPE
mt : mt-st v. 0.4 Also mt-st v0.5b were fairly broken especially with positioning. rgds, tim. -- - 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/
Re: SW-RAID0 Performance problems
David Rees wrote: > What happens if your run hdparm -t /dev/hda and /dev/hdc at the same time? Try 'hdparm -tT' with simultaneous /dev/hda3 and /dev/hdc3. This gives you a baseline on the actual partitions involved. rgds, tim. -- - 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/
Re: SW-RAID0 Performance problems
David Rees wrote: What happens if your run hdparm -t /dev/hda and /dev/hdc at the same time? Try 'hdparm -tT' with simultaneous /dev/hda3 and /dev/hdc3. This gives you a baseline on the actual partitions involved. rgds, tim. -- - 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/
Re: Help with Fasttrack/100 Raid on Linux
> > FrastTrack/100 Raid controller working. I finally found the ft.o driver Did you try building it from source? Their docs say beta ft.o is RH 6.2-7.0 which would make me a bit nervous. ftp://ftp.promise.com/Controllers/IDE/FastTrak100/Linux/LinuxBETA/ -- - 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/
Re: Help with Fasttrack/100 Raid on Linux
FrastTrack/100 Raid controller working. I finally found the ft.o driver Did you try building it from source? Their docs say beta ft.o is RH 6.2-7.0 which would make me a bit nervous. ftp://ftp.promise.com/Controllers/IDE/FastTrak100/Linux/LinuxBETA/ -- - 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/
Re: UDMA 100 / PIIX4 question
> I am afraid that I do not know how to change my partition type. I can confirm. >however, that the BIOS is set to Auto / LBA and that BIOS confirms UDMA 5 is set (and >cannot be set unless the correct cabling is detected). [tim@abit tim]# fdisk /dev/hdc Command (m for help): t Partition number (1-4): 1 Hex code (type L to list codes): c Changed system type of partition 1 to c (Win95 FAT32 (LBA)) ... > But is my controller, though detected as a PIIX4 (and described as such in the Asus >manual), really a PIIX4? lspci : > > 00:00.0 Host bridge: Intel Corporation: Unknown device 1130 (rev 02) > 00:01.0 PCI bridge: Intel Corporation: Unknown device 1131 (rev 02) > 00:1e.0 PCI bridge: Intel Corporation: Unknown device 244e (rev 01) > 00:1f.0 ISA bridge: Intel Corporation: Unknown device 2440 (rev 01) > 00:1f.1 IDE interface: Intel Corporation: Unknown device 244b (rev 01) > 00:1f.2 USB Controller: Intel Corporation: Unknown device 2442 (rev 01) > ... > > On the other hand, cat /proc/ide/piix : > >Intel PIIX4 Ultra 100 Chipset. > --- Primary Channel Secondary Channel - > enabled enabled > --- drive0 - drive1 drive0 -- drive1 -- > DMA enabled:yes no yes no > UDMA enabled: yes no yes no > UDMA enabled: 5X 2 X > UDMA > DMA > PI ICH2 is marked '80821BA' and is rated ATA/100 by intel, PIIX4 is '82371AB' so you can look on your motherboard. Andre is the one to say if the driver is compatible. I can't find a single reference to the 80821 in drivers/block/*.c for 2.2.19pre17 + ide.2.2.18.1221. Here's what a PIIX4 looks like. [tim@smp ide]# cat /proc/ide/ide0/config pci bus 00 device 39 vid 8086 did 7111 channel 0 86 80 11 71 05 00 80 02 01 80 01 01 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 a3 00 80 00 00 00 00 01 00 02 00 00 00 00 00 ... 00 00 00 00 00 00 00 00 30 0f 00 00 00 00 00 00 [tim@smp ide]# cat /proc/ide/piix Intel PIIX4 Ultra 33 Chipset. --- Primary Channel Secondary Channel - enabled enabled --- drive0 - drive1 drive0 -- drive1 -- DMA enabled:yes no nono UDMA enabled: yes no nono UDMA enabled: 2X X X UDMA DMA PIO [tim@smp tim]# lspci | grep IDE 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) [tim@smp tim]# lspci -n | grep 7.1 00:07.1 Class 0101: 8086:7111 (rev 01) -- - 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/
Re: UDMA 100 / PIIX4 question
I am afraid that I do not know how to change my partition type. I can confirm. however, that the BIOS is set to Auto / LBA and that BIOS confirms UDMA 5 is set (and cannot be set unless the correct cabling is detected). [tim@abit tim]# fdisk /dev/hdc Command (m for help): t Partition number (1-4): 1 Hex code (type L to list codes): c Changed system type of partition 1 to c (Win95 FAT32 (LBA)) ... But is my controller, though detected as a PIIX4 (and described as such in the Asus manual), really a PIIX4? lspci : 00:00.0 Host bridge: Intel Corporation: Unknown device 1130 (rev 02) 00:01.0 PCI bridge: Intel Corporation: Unknown device 1131 (rev 02) 00:1e.0 PCI bridge: Intel Corporation: Unknown device 244e (rev 01) 00:1f.0 ISA bridge: Intel Corporation: Unknown device 2440 (rev 01) 00:1f.1 IDE interface: Intel Corporation: Unknown device 244b (rev 01) 00:1f.2 USB Controller: Intel Corporation: Unknown device 2442 (rev 01) ... On the other hand, cat /proc/ide/piix : Intel PIIX4 Ultra 100 Chipset. --- Primary Channel Secondary Channel - enabled enabled --- drive0 - drive1 drive0 -- drive1 -- DMA enabled:yes no yes no UDMA enabled: yes no yes no UDMA enabled: 5X 2 X UDMA DMA PI ICH2 is marked '80821BA' and is rated ATA/100 by intel, PIIX4 is '82371AB' so you can look on your motherboard. Andre is the one to say if the driver is compatible. I can't find a single reference to the 80821 in drivers/block/*.c for 2.2.19pre17 + ide.2.2.18.1221. Here's what a PIIX4 looks like. [tim@smp ide]# cat /proc/ide/ide0/config pci bus 00 device 39 vid 8086 did 7111 channel 0 86 80 11 71 05 00 80 02 01 80 01 01 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 a3 00 80 00 00 00 00 01 00 02 00 00 00 00 00 ... 00 00 00 00 00 00 00 00 30 0f 00 00 00 00 00 00 [tim@smp ide]# cat /proc/ide/piix Intel PIIX4 Ultra 33 Chipset. --- Primary Channel Secondary Channel - enabled enabled --- drive0 - drive1 drive0 -- drive1 -- DMA enabled:yes no nono UDMA enabled: yes no nono UDMA enabled: 2X X X UDMA DMA PIO [tim@smp tim]# lspci | grep IDE 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) [tim@smp tim]# lspci -n | grep 7.1 00:07.1 Class 0101: 8086:7111 (rev 01) -- - 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/
Re: UDMA 100 / PIIX4 question
>Device BootStart EndBlocks Id System > /dev/hda1 * 1 932 7486258+ b Win95 FAT32 Try changing to 'c' (fat32+LBA) and check BIOS settings (s/b AUTO or USER, and LBA). rgds, tim. -- - 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/
Re: UDMA 100 / PIIX4 question
> >Device BootStart EndBlocks Id System
> > /dev/hda1 * 1 932 7486258+ b Win95 FAT32
> > ...
> > I also ran hdparm -tT /dev/hda1:
> >
> > Timing buffer-cache reads: 128 MB in 1.28 seconds =100.00 MB/sec
> > Timing buffered disk reads: 64 MB in 4.35 seconds = 14.71 MB/sec
> >
> > I then tried hdparm -tT /dev/hda7:
> >
> > Timing buffer-cache reads: 128 MB in 1.28 seconds =100.00 MB/sec
> > Timing buffered disk reads: 64 MB in 2.12 seconds = 30.19 MB/sec
Change partition type to 'c' (fat32+LBA); check that BIOS is set for
(AUTO or USER) and LBA.
Regarding the PIIX4, I reran basic throughput read tests on a more
recent UDMA5, 5400RPM Maxtor on the PIIX4 and HPT366 (Abit BP6 +
2.2.19p17 + ide.2.2.18.1221.patch) chipsets.
Since pin 30 is plugged on my ATA66 cable, I used an Asus P3B-F as a
ATA66+PIIX4 sanity check. Neither the Abit or Asus PIIX4 controller
would go higher than UDMA2. Although hdparm -i reported UDMA4, neither
the -tT or dd tests demonstrated faster results. The kernel logged
'ide0: Speed warnings UDMA 3/4/5 is not functional' when attempting a
setting higher than UDMA2 on the PIIX4.
Apparently IDE drive technology has improved over the last year,
however real world PIIX4 speeds are still in the 14-19MB/s range.
UDMA2/PIIX4 16-21MB/s
UDMA4/HPT36619-28MB/s
rgds,
tim.
[tim@asus tim]# lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
(rev 03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev
03)
00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:0d.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev20)
00:0f.0 VGA compatible unclassified device: 3DLabs Permedia II 2D+3D (rev
01)
00:13.0 Unknown mass storage controller: Triones Technologies, Inc. HPT366
(rev 01)
00:13.1 Unknown mass storage controller: Triones Technologies, Inc. HPT366
(rev 01)
PIIX4 -
[tim@asus tim]# hdparm -iv /dev/hdb
/dev/hdb:
multcount= 0 (off)
I/O support = 0 (default 16-bit)
unmaskirq= 0 (off)
using_dma= 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead= 8 (on)
geometry = 2491/255/63, sectors = 40021632, start = 0
Model=Maxtor 32049H2, FwRev=YAH814Y0, SerialNo=L21R7EKC
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=40021632
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5
[tim@asus tim]# hdparm -tT /dev/hdb
/dev/hdb:
Timing buffer-cache reads: 128 MB in 1.47 seconds = 87.07 MB/sec
Timing buffered disk reads: 64 MB in 3.02 seconds = 21.19 MB/sec
[tim@asus tim]# time dd if=/dev/hdb of=/dev/null bs=1k count=512k
524288+0 records in
524288+0 records out
0.540u 10.520s 0:32.85 33.6%0+0k 0+0io 115pf+0w
[tim@asus tim]# echo "514288/32.85" | bc -q
15655
HPT366
[tim@asus tim]# hdparm -iv /dev/hdf
/dev/hdf:
multcount= 0 (off)
I/O support = 0 (default 16-bit)
unmaskirq= 0 (off)
using_dma= 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead= 8 (on)
geometry = 2491/255/63, sectors = 40021632, start = 0
Model=Maxtor 32049H2, FwRev=YAH814Y0, SerialNo=L21R7EKC
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=40021632
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5
[tim@asus tim]# hdparm -tT /dev/hdf
/dev/hdf:
Timing buffer-cache reads: 128 MB in 1.50 seconds = 85.33 MB/sec
Timing buffered disk reads: 64 MB in 2.28 seconds = 28.07 MB/sec
[tim@asus tim]# time dd if=/dev/hdf of=/dev/null bs=1k count=512k
524288+0 records in
524288+0 records out
0.530u 11.140s 0:27.45 42.5%0+0k 0+0io 115pf+0w
[tim@asus tim]# echo "524288/27.45" | bc -q
19099
--
-
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/
Re: UDMA 100 / PIIX4 question
Device BootStart EndBlocks Id System
/dev/hda1 * 1 932 7486258+ b Win95 FAT32
...
I also ran hdparm -tT /dev/hda1:
Timing buffer-cache reads: 128 MB in 1.28 seconds =100.00 MB/sec
Timing buffered disk reads: 64 MB in 4.35 seconds = 14.71 MB/sec
I then tried hdparm -tT /dev/hda7:
Timing buffer-cache reads: 128 MB in 1.28 seconds =100.00 MB/sec
Timing buffered disk reads: 64 MB in 2.12 seconds = 30.19 MB/sec
Change partition type to 'c' (fat32+LBA); check that BIOS is set for
(AUTO or USER) and LBA.
Regarding the PIIX4, I reran basic throughput read tests on a more
recent UDMA5, 5400RPM Maxtor on the PIIX4 and HPT366 (Abit BP6 +
2.2.19p17 + ide.2.2.18.1221.patch) chipsets.
Since pin 30 is plugged on my ATA66 cable, I used an Asus P3B-F as a
ATA66+PIIX4 sanity check. Neither the Abit or Asus PIIX4 controller
would go higher than UDMA2. Although hdparm -i reported UDMA4, neither
the -tT or dd tests demonstrated faster results. The kernel logged
'ide0: Speed warnings UDMA 3/4/5 is not functional' when attempting a
setting higher than UDMA2 on the PIIX4.
Apparently IDE drive technology has improved over the last year,
however real world PIIX4 speeds are still in the 14-19MB/s range.
UDMA2/PIIX4 16-21MB/s
UDMA4/HPT36619-28MB/s
rgds,
tim.
[tim@asus tim]# lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
(rev 03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev
03)
00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:0d.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev20)
00:0f.0 VGA compatible unclassified device: 3DLabs Permedia II 2D+3D (rev
01)
00:13.0 Unknown mass storage controller: Triones Technologies, Inc. HPT366
(rev 01)
00:13.1 Unknown mass storage controller: Triones Technologies, Inc. HPT366
(rev 01)
PIIX4 -
[tim@asus tim]# hdparm -iv /dev/hdb
/dev/hdb:
multcount= 0 (off)
I/O support = 0 (default 16-bit)
unmaskirq= 0 (off)
using_dma= 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead= 8 (on)
geometry = 2491/255/63, sectors = 40021632, start = 0
Model=Maxtor 32049H2, FwRev=YAH814Y0, SerialNo=L21R7EKC
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=40021632
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5
[tim@asus tim]# hdparm -tT /dev/hdb
/dev/hdb:
Timing buffer-cache reads: 128 MB in 1.47 seconds = 87.07 MB/sec
Timing buffered disk reads: 64 MB in 3.02 seconds = 21.19 MB/sec
[tim@asus tim]# time dd if=/dev/hdb of=/dev/null bs=1k count=512k
524288+0 records in
524288+0 records out
0.540u 10.520s 0:32.85 33.6%0+0k 0+0io 115pf+0w
[tim@asus tim]# echo "514288/32.85" | bc -q
15655
HPT366
[tim@asus tim]# hdparm -iv /dev/hdf
/dev/hdf:
multcount= 0 (off)
I/O support = 0 (default 16-bit)
unmaskirq= 0 (off)
using_dma= 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead= 8 (on)
geometry = 2491/255/63, sectors = 40021632, start = 0
Model=Maxtor 32049H2, FwRev=YAH814Y0, SerialNo=L21R7EKC
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=40021632
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5
[tim@asus tim]# hdparm -tT /dev/hdf
/dev/hdf:
Timing buffer-cache reads: 128 MB in 1.50 seconds = 85.33 MB/sec
Timing buffered disk reads: 64 MB in 2.28 seconds = 28.07 MB/sec
[tim@asus tim]# time dd if=/dev/hdf of=/dev/null bs=1k count=512k
524288+0 records in
524288+0 records out
0.530u 11.140s 0:27.45 42.5%0+0k 0+0io 115pf+0w
[tim@asus tim]# echo "524288/27.45" | bc -q
19099
--
-
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/
Re: UDMA 100 / PIIX4 question
Device BootStart EndBlocks Id System /dev/hda1 * 1 932 7486258+ b Win95 FAT32 Try changing to 'c' (fat32+LBA) and check BIOS settings (s/b AUTO or USER, and LBA). rgds, tim. -- - 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/
Re: UDMA 100 / PIIX4 question
Mark Hahn wrote: > > > > > I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), >which has a PIIX4 controller. > > > > ... > > > > My problem is that (according to hdparm -t), I never get a better transfer >rate than approximately 15.8 Mb/sec > > > > > > 15MB/s for hdparm is about right. > > it's definitely not right: this disk sustains around 35 MB/s. The 815e does not use a PIIX4 chipset. My references were to PIIX4 chipsets. > nonsequitur: the controller and disk are both quite capable of > sustaining 20-35 MB/s (depending on zone.) here's hdparm output > for a disk of the same rpm and density as the DTLA's: > > Timing buffer-cache reads: 128 MB in 1.07 seconds =119.63 MB/sec > Timing buffered disk reads: 64 MB in 2.02 seconds = 31.68 MB/sec > > (maxtor dm+45, hpt366 controller) > regards, mark hahn. Again, this is not a PIIX4 chipset. rgds, tim. -- - 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/
Re: UDMA 100 / PIIX4 question
Jeremy Jackson wrote:
>
> Tim Moore wrote:
> > 15MB/s for hdparm is about right.
>
> Yes, since hdparm -t measures *SUSTAINED* transfers... the actual "head rate" of
>data reads from
> disk surface. Only if you read *only* data that is alread in harddrive's cache will
>you get a speed
> close to the UDMA mode of the drive/controller. The cache is around 1Mbyte, so for
>a split-second
> re-read of some data
Apologies for the too brief answer. Sustained real world transfer rates for the PIIX4
under ideal
setup conditions and a quiet bus are 14-18MB/s. Faster disk architecture and forcing
ide driver
parameters will not change this.
Here's what you might expect from this disk family with an ATA-66 capable chipset:
[tim@abit tim]# hdparm -i /dev/hda; hdparm -tT /dev/hda
/dev/hda:
Model=IBM-DTLA-307020, FwRev=TX3OA50C, SerialNo=YH0YHF45553
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=40188960
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5
/dev/hda:
Timing buffer-cache reads: 128 MB in 0.81 seconds =158.02 MB/sec
Timing buffered disk reads: 64 MB in 1.85 seconds = 34.59 MB/sec
Larger sustained transfers are about 75% of the burst/cache influenced hdparm timings.
[tim@abit tim]# time dd if=/dev/hda of=/dev/null bs=1k count=500k
512000+0 records in
512000+0 records out
0.340u 6.780s 0:19.68 36.1% 0+0k 0+0io 115pf+0w
[tim@abit tim]# echo "512000/19.68" | bc -q
26016
--
| 650.390.9613 | [EMAIL PROTECTED]
-
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/
Re: UDMA 100 / PIIX4 question
> You should be able to get about 30 MB/s at the start of the disk (zone 0) according
>to IBM's datasheet at
>
> http://ssdweb01.storage.ibm.com/techsup/hddtech/prodspec/dtla_spw.pdf
>
> so if you were testing say /dev/hda1 which is at the start of the disk it should be
>faster.
"should be" is yes and yes, but you will not see 30MB/s and there is no actual
difference between
/dev/hda and /dev/had1.
> Try hdparm -i /dev/hda (or whatever) .. . note the reported MaxMultSect= value,
> and put it in place of X in command:
>
> hdparm -u 1 -d 1 -m X -c 1 /dev/hda
I've spent more time with real world data transfer testing than god, both PIIX4-based
motherboards
and network based (Network Appliance <-> linux). The only hdparm parameter that makes
any
measurable, significnat difference for most modern drive and chipset combinations is
-d1 and the
correct UDMA mode.
Try partitioning your disk in 4 equal segments and run multiple tests in runlevel1 on
/dev/hda[1-4]
for '/usr/bin/time hdparm -tT' plus permutations of -a[0248]c[013]m[024816]u[01],
and /usr/bin/time dd if=/dev/hda[1-4] of=/dev/null bs=1k
count={32,64,128,256,512,1024}k.
rgds,
tim.
--
-
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/
Re: UDMA 100 / PIIX4 question
[EMAIL PROTECTED] wrote: > I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), which >has a PIIX4 controller. > ... > My problem is that (according to hdparm -t), I never get a better transfer rate than >approximately 15.8 Mb/sec. I achieve this when DMA is enabled, - without it I fall >back to about 5 Mb /sec. No amount of fiddling with other hdparm settings makes any >difference. > ... 15MB/s for hdparm is about right. "...four IDE devices can be supported in Bus Master mode. PIIX4 contains support for "Ultra DMA/33" synchronous DMA compatible devices." http://developer.intel.com/design/intarch/techinfo/440BX/PIIX4_intro.htm -- - 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/
Re: UDMA 100 / PIIX4 question
[EMAIL PROTECTED] wrote: I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), which has a PIIX4 controller. ... My problem is that (according to hdparm -t), I never get a better transfer rate than approximately 15.8 Mb/sec. I achieve this when DMA is enabled, - without it I fall back to about 5 Mb /sec. No amount of fiddling with other hdparm settings makes any difference. ... 15MB/s for hdparm is about right. "...four IDE devices can be supported in Bus Master mode. PIIX4 contains support for "Ultra DMA/33" synchronous DMA compatible devices." http://developer.intel.com/design/intarch/techinfo/440BX/PIIX4_intro.htm -- - 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/
Re: UDMA 100 / PIIX4 question
You should be able to get about 30 MB/s at the start of the disk (zone 0) according
to IBM's datasheet at
http://ssdweb01.storage.ibm.com/techsup/hddtech/prodspec/dtla_spw.pdf
so if you were testing say /dev/hda1 which is at the start of the disk it should be
faster.
"should be" is yes and yes, but you will not see 30MB/s and there is no actual
difference between
/dev/hda and /dev/had1.
Try hdparm -i /dev/hda (or whatever) .. . note the reported MaxMultSect= value,
and put it in place of X in command:
hdparm -u 1 -d 1 -m X -c 1 /dev/hda
I've spent more time with real world data transfer testing than god, both PIIX4-based
motherboards
and network based (Network Appliance - linux). The only hdparm parameter that makes
any
measurable, significnat difference for most modern drive and chipset combinations is
-d1 and the
correct UDMA mode.
Try partitioning your disk in 4 equal segments and run multiple tests in runlevel1 on
/dev/hda[1-4]
for '/usr/bin/time hdparm -tT' plus permutations of -a[0248]c[013]m[024816]u[01],
and /usr/bin/time dd if=/dev/hda[1-4] of=/dev/null bs=1k
count={32,64,128,256,512,1024}k.
rgds,
tim.
--
-
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/
Re: UDMA 100 / PIIX4 question
Jeremy Jackson wrote:
Tim Moore wrote:
15MB/s for hdparm is about right.
Yes, since hdparm -t measures *SUSTAINED* transfers... the actual "head rate" of
data reads from
disk surface. Only if you read *only* data that is alread in harddrive's cache will
you get a speed
close to the UDMA mode of the drive/controller. The cache is around 1Mbyte, so for
a split-second
re-read of some data
Apologies for the too brief answer. Sustained real world transfer rates for the PIIX4
under ideal
setup conditions and a quiet bus are 14-18MB/s. Faster disk architecture and forcing
ide driver
parameters will not change this.
Here's what you might expect from this disk family with an ATA-66 capable chipset:
[tim@abit tim]# hdparm -i /dev/hda; hdparm -tT /dev/hda
/dev/hda:
Model=IBM-DTLA-307020, FwRev=TX3OA50C, SerialNo=YH0YHF45553
Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=40188960
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5
/dev/hda:
Timing buffer-cache reads: 128 MB in 0.81 seconds =158.02 MB/sec
Timing buffered disk reads: 64 MB in 1.85 seconds = 34.59 MB/sec
Larger sustained transfers are about 75% of the burst/cache influenced hdparm timings.
[tim@abit tim]# time dd if=/dev/hda of=/dev/null bs=1k count=500k
512000+0 records in
512000+0 records out
0.340u 6.780s 0:19.68 36.1% 0+0k 0+0io 115pf+0w
[tim@abit tim]# echo "512000/19.68" | bc -q
26016
--
| 650.390.9613 | [EMAIL PROTECTED]
-
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/
Re: UDMA 100 / PIIX4 question
Mark Hahn wrote: I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), which has a PIIX4 controller. ... My problem is that (according to hdparm -t), I never get a better transfer rate than approximately 15.8 Mb/sec 15MB/s for hdparm is about right. it's definitely not right: this disk sustains around 35 MB/s. The 815e does not use a PIIX4 chipset. My references were to PIIX4 chipsets. nonsequitur: the controller and disk are both quite capable of sustaining 20-35 MB/s (depending on zone.) here's hdparm output for a disk of the same rpm and density as the DTLA's: Timing buffer-cache reads: 128 MB in 1.07 seconds =119.63 MB/sec Timing buffered disk reads: 64 MB in 2.02 seconds = 31.68 MB/sec (maxtor dm+45, hpt366 controller) regards, mark hahn. Again, this is not a PIIX4 chipset. rgds, tim. -- - 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/
Re: [PATCH] /proc/uptime on SMP machines
The patch works on 2.2.19pre17. The second machine (asus) has Uwe's patch modified for 2.2. The machine 'smp' is not patched. rgds, tim. [tim@smp ~]# cat /proc/uptime ; cat /proc/stat | grep cpu ; yes > /dev/null & ; sleep 180 ; killall yes ; cat /proc/uptime ; cat /proc/stat | grep cpu [2] 1485 22689.88 21324.40 cpu 175685 0 32321 4329972 cpu0 121396 0 15195 2132398 cpu1 54289 0 17126 2197574 Terminated 22869.90 21324.40 cpu 193551 0 33066 4347365 cpu0 139179 0 15414 2132398 cpu1 54372 0 17652 2214967 [2] - Exit 143 ( cat /proc/uptime; cat /proc/stat | grep cpu; yes > /dev/null ) [tim@asus ~]# date ; cat /proc/uptime ; cat /proc/stat | grep cpu ; yes > /dev/null & ; sleep 180 ; killall yes ; cat /proc/uptime ; cat /proc/stat | grep cpu [1] 870 Sat Mar 17 20:41:49 PST 2001 3260.19 2337.13 cpu 174676 0 9849 467515 cpu0 90385 0 4666 230969 cpu1 84291 0 5183 236546 Terminated 3440.20 2424.73 cpu 192352 0 10656 485034 cpu0 108059 0 4992 230970 cpu1 84293 0 5664 254064 [1] + Exit 143 ( date; cat /proc/uptime; cat /proc/stat | grep cpu; yes > /dev/null ) [tim@asus ~]# cat /proc/version Linux version 2.2.19pre17 (root@asus) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #5 SMP Sat Mar 17 19:44:42 PST 2001 -- - 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/
Re: [PATCH] /proc/uptime on SMP machines
> Same for 2.2.19p17
except that init_tasks is a 2.4 struc. Corrected as below.
rgds,
tim
--- 2.2.19pre17/fs/proc/array.c.old Fri Mar 16 04:09:41 2001
+++ 2.2.19pre17/fs/proc/array.c.idleSat Mar 17 19:35:36 2001
@@ -339,9 +339,16 @@
{
unsigned long uptime;
unsigned long idle;
+ int i;
uptime = jiffies;
+#ifdef CONFIG_SMP
+ for (idle =0,i = 0; i < smp_num_cpus; i++)
+ idle += (task[i]->times.tms_utime +
+ task[i]->times.tms_stime)/smp_num_cpus;
+#else
idle = task[0]->times.tms_utime + task[0]->times.tms_stime;
+#endif
/* The formula for the fraction parts really is ((t * 100) / HZ) % 100, but
that would overflow about every five days at HZ == 100.
--
-
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/
Re: [PATCH] /proc/uptime on SMP machines
> At present the idle value in /proc/uptime is only the idle time for the first
> processor. With 2.4, processes seam "stickier" for my, and e.g "yes
> >/dev/null" on an otherwise idle machine can stay for a long time on one
> processor of my (intel) SMP machine. That way, the present output of
> /proc/uptime can lead to a wrong conclusion.
Same for 2.2.19p17
[tim@smp ~]# cat /proc/uptime
19262.25 18487.44
[tim@smp ~]# cat /proc/stat | grep cpu
cpu 108661 0 24741 3719438
cpu0 65697 0 11814 1848909
cpu1 42964 0 12927 1870529
--- 2.2.19pre17/fs/proc/array.c Fri Mar 16 04:09:41 2001
+++ 2.2.19pre17/fs/proc/array.c.idleSat Mar 17 19:20:22 2001
@@ -339,9 +339,16 @@
{
unsigned long uptime;
unsigned long idle;
+ int i;
uptime = jiffies;
+#ifdef CONFIG_SMP
+ for (idle =0,i = 0; i < smp_num_cpus; i++)
+ idle += (init_tasks[i]->times.tms_utime +
+ init_tasks[i]->times.tms_stime)/smp_num_cpus;
+#else
idle = task[0]->times.tms_utime + task[0]->times.tms_stime;
+#endif
/* The formula for the fraction parts really is ((t * 100) / HZ)
% 100, but
that would overflow about every five days at HZ == 100.
--
-
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/
Re: [PATCH] /proc/uptime on SMP machines
At present the idle value in /proc/uptime is only the idle time for the first
processor. With 2.4, processes seam "stickier" for my, and e.g "yes
/dev/null" on an otherwise idle machine can stay for a long time on one
processor of my (intel) SMP machine. That way, the present output of
/proc/uptime can lead to a wrong conclusion.
Same for 2.2.19p17
[tim@smp ~]# cat /proc/uptime
19262.25 18487.44
[tim@smp ~]# cat /proc/stat | grep cpu
cpu 108661 0 24741 3719438
cpu0 65697 0 11814 1848909
cpu1 42964 0 12927 1870529
--- 2.2.19pre17/fs/proc/array.c Fri Mar 16 04:09:41 2001
+++ 2.2.19pre17/fs/proc/array.c.idleSat Mar 17 19:20:22 2001
@@ -339,9 +339,16 @@
{
unsigned long uptime;
unsigned long idle;
+ int i;
uptime = jiffies;
+#ifdef CONFIG_SMP
+ for (idle =0,i = 0; i smp_num_cpus; i++)
+ idle += (init_tasks[i]-times.tms_utime +
+ init_tasks[i]-times.tms_stime)/smp_num_cpus;
+#else
idle = task[0]-times.tms_utime + task[0]-times.tms_stime;
+#endif
/* The formula for the fraction parts really is ((t * 100) / HZ)
% 100, but
that would overflow about every five days at HZ == 100.
--
-
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/
Re: [PATCH] /proc/uptime on SMP machines
Same for 2.2.19p17
except that init_tasks is a 2.4 struc. Corrected as below.
rgds,
tim
--- 2.2.19pre17/fs/proc/array.c.old Fri Mar 16 04:09:41 2001
+++ 2.2.19pre17/fs/proc/array.c.idleSat Mar 17 19:35:36 2001
@@ -339,9 +339,16 @@
{
unsigned long uptime;
unsigned long idle;
+ int i;
uptime = jiffies;
+#ifdef CONFIG_SMP
+ for (idle =0,i = 0; i smp_num_cpus; i++)
+ idle += (task[i]-times.tms_utime +
+ task[i]-times.tms_stime)/smp_num_cpus;
+#else
idle = task[0]-times.tms_utime + task[0]-times.tms_stime;
+#endif
/* The formula for the fraction parts really is ((t * 100) / HZ) % 100, but
that would overflow about every five days at HZ == 100.
--
-
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/
Re: [PATCH] /proc/uptime on SMP machines
The patch works on 2.2.19pre17. The second machine (asus) has Uwe's patch modified for 2.2. The machine 'smp' is not patched. rgds, tim. [tim@smp ~]# cat /proc/uptime ; cat /proc/stat | grep cpu ; yes /dev/null ; sleep 180 ; killall yes ; cat /proc/uptime ; cat /proc/stat | grep cpu [2] 1485 22689.88 21324.40 cpu 175685 0 32321 4329972 cpu0 121396 0 15195 2132398 cpu1 54289 0 17126 2197574 Terminated 22869.90 21324.40 cpu 193551 0 33066 4347365 cpu0 139179 0 15414 2132398 cpu1 54372 0 17652 2214967 [2] - Exit 143 ( cat /proc/uptime; cat /proc/stat | grep cpu; yes /dev/null ) [tim@asus ~]# date ; cat /proc/uptime ; cat /proc/stat | grep cpu ; yes /dev/null ; sleep 180 ; killall yes ; cat /proc/uptime ; cat /proc/stat | grep cpu [1] 870 Sat Mar 17 20:41:49 PST 2001 3260.19 2337.13 cpu 174676 0 9849 467515 cpu0 90385 0 4666 230969 cpu1 84291 0 5183 236546 Terminated 3440.20 2424.73 cpu 192352 0 10656 485034 cpu0 108059 0 4992 230970 cpu1 84293 0 5664 254064 [1] + Exit 143 ( date; cat /proc/uptime; cat /proc/stat | grep cpu; yes /dev/null ) [tim@asus ~]# cat /proc/version Linux version 2.2.19pre17 (root@asus) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #5 SMP Sat Mar 17 19:44:42 PST 2001 -- - 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/
Re: parport not detected
> The parallel port is not being detected on my ABIT KT7A KT133 w/ Athlon Also try comp.os.linux.hardware. BIOS 278/irq5 378/irq7 EPP 1.9 .config --- CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PNP=y CONFIG_PNP_PARPORT=y CONFIG_PRINTER=y CONFIG_PRINTER_READBACK=y kernal boot params -- append="parport=0x378,7 parport=0x278,5" options for /etc/rc.d/rc.local -- # abort on error, careful error check, trust IRQ. # see tunelp(8) & /usr/src/linux/drivers/misc/lp.c /usr/sbin/tunelp /dev/lp0 -a on -o on -T on /usr/sbin/tunelp /dev/lp1 -a on -o on -T on looks like this (lp1 was powered down at boot time) Feb 25 02:57:39 dell kernel: parport0: PC-style at 0x378, irq 7 [SPP,PS2,EPP] Feb 25 02:57:39 dell kernel: parport0: Printer, Hewlett-Packard HP LaserJet 1100 Feb 25 02:57:39 dell kernel: parport1: PC-style at 0x278, irq 5 [SPP,PS2,EPP] Feb 25 02:57:39 dell kernel: parport1: no IEEE-1284 device present. Feb 25 02:57:40 dell kernel: lp0: using parport0 (interrupt-driven). Feb 25 02:57:40 dell kernel: lp1: using parport1 (interrupt-driven). -- - 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/
Re: parport not detected
The parallel port is not being detected on my ABIT KT7A KT133 w/ Athlon Also try comp.os.linux.hardware. BIOS 278/irq5 378/irq7 EPP 1.9 .config --- CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PNP=y CONFIG_PNP_PARPORT=y CONFIG_PRINTER=y CONFIG_PRINTER_READBACK=y kernal boot params -- append="parport=0x378,7 parport=0x278,5" options for /etc/rc.d/rc.local -- # abort on error, careful error check, trust IRQ. # see tunelp(8) /usr/src/linux/drivers/misc/lp.c /usr/sbin/tunelp /dev/lp0 -a on -o on -T on /usr/sbin/tunelp /dev/lp1 -a on -o on -T on looks like this (lp1 was powered down at boot time) Feb 25 02:57:39 dell kernel: parport0: PC-style at 0x378, irq 7 [SPP,PS2,EPP] Feb 25 02:57:39 dell kernel: parport0: Printer, Hewlett-Packard HP LaserJet 1100 Feb 25 02:57:39 dell kernel: parport1: PC-style at 0x278, irq 5 [SPP,PS2,EPP] Feb 25 02:57:39 dell kernel: parport1: no IEEE-1284 device present. Feb 25 02:57:40 dell kernel: lp0: using parport0 (interrupt-driven). Feb 25 02:57:40 dell kernel: lp1: using parport1 (interrupt-driven). -- - 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/
Re: VM problem with 2.2.18 ?
> i had a small problem with a program i was running > which got stuck in a loop allocing memory by the time i > found out it was doing it these were appearing > > VM: do_try_to_free_pages failed for ypbind... > ... > etc.. etc.. for many more processes > then it all ended in a hangup Patch to 2.2.19pre2 or higher. http://www.linuxhq.com/kernel/v2.2/changes/pre-2.2.19.html -- - 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/
Re: VM problem with 2.2.18 ?
i had a small problem with a program i was running which got stuck in a loop allocing memory by the time i found out it was doing it these were appearing VM: do_try_to_free_pages failed for ypbind... ... etc.. etc.. for many more processes then it all ended in a hangup Patch to 2.2.19pre2 or higher. http://www.linuxhq.com/kernel/v2.2/changes/pre-2.2.19.html -- - 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/
Re: Questions about Enterprise Storage with Linux
Tom Sightler wrote: > ... > For example if we purchase a NetApp Filer, or EMC Celerra with 1TB of > storage, and elect to export that entire amount as a single NFS mount, and > then use that storage to allow several Linux boxes to share 100GB > (admittedly temporary) files, will Linux handle that, at least in theory? Linux/NFS works very well with Filers. I did a lot of throughput testing at Netapp circa 2.2.10-12 with Gigabit Ethernet (AceNIC). Why would you need to put 1TB on a single mount point? Filers are also blessed by Oracle and can take care of the volume management and backup issues. The principle advantage is avalibility (balanced against cost of course). If you do talk to Netapp, ask for someone that has linux/Filer experience. rgds, tim. -- - 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/
Re: Questions about Enterprise Storage with Linux
Tom Sightler wrote: ... For example if we purchase a NetApp Filer, or EMC Celerra with 1TB of storage, and elect to export that entire amount as a single NFS mount, and then use that storage to allow several Linux boxes to share 100GB (admittedly temporary) files, will Linux handle that, at least in theory? Linux/NFS works very well with Filers. I did a lot of throughput testing at Netapp circa 2.2.10-12 with Gigabit Ethernet (AceNIC). Why would you need to put 1TB on a single mount point? Filers are also blessed by Oracle and can take care of the volume management and backup issues. The principle advantage is avalibility (balanced against cost of course). If you do talk to Netapp, ask for someone that has linux/Filer experience. rgds, tim. -- - 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/
Re: "clock timer configuration lost" error?
Interesting. This is a KA7 with all power management turned off in the latest Abit BIOS. > The kernel puts the timer back and life appears happy again Ahhh. The kernel *is* god. Alan Cox wrote: > > > Feb 26 00:19:52 abit kernel: probable hardware bug: clock timer > > configuration lost - probably a VIA686a. > > Feb 26 00:19:52 abit kernel: probable hardware bug: restoring chip > > configuration. > > Feb 26 00:26:53 abit xntpd[886]: synchronized to 132.239.254.5, > > stratum=2 > > ... > > Small number of VIA 686 boxes randomly jump from 100Hz back to the DOS 18Hz > timeout. We dont know if its hardware or maybe APM bios bugs. The kernel puts > the timer back and life appears happy again -- - 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/
"clock timer configuration lost" error?
For no apparent reason: ... Feb 26 00:15:50 abit xntpd[886]: synchronized to 192.6.38.127, stratum=1 Feb 26 00:19:52 abit kernel: probable hardware bug: clock timer configuration lost - probably a VIA686a. Feb 26 00:19:52 abit kernel: probable hardware bug: restoring chip configuration. Feb 26 00:26:53 abit xntpd[886]: synchronized to 132.239.254.5, stratum=2 ... Anyone have a clue about the 'probable hdw bug' messages? No disk activity to speak of, no other symptoms and/or messages. rgds, tim. # cat proc/version; lspci Linux version 2.2.19pre8+IDE (root@abit) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #8 Thu Feb 22 18:12:29 PST 2001 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0391 (rev 02) 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8391 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) 00:08.0 FireWire (IEEE 1394): Texas Instruments TSB12LV23 OHCI Compliant IEEE-1394 Controller 00:09.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] 00:0b.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) 01:00.0 VGA compatible controller: nVidia Corporation Riva TNT2 Model 64 (rev 11) -- - 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/
clock timer configuration lost error?
For no apparent reason: ... Feb 26 00:15:50 abit xntpd[886]: synchronized to 192.6.38.127, stratum=1 Feb 26 00:19:52 abit kernel: probable hardware bug: clock timer configuration lost - probably a VIA686a. Feb 26 00:19:52 abit kernel: probable hardware bug: restoring chip configuration. Feb 26 00:26:53 abit xntpd[886]: synchronized to 132.239.254.5, stratum=2 ... Anyone have a clue about the 'probable hdw bug' messages? No disk activity to speak of, no other symptoms and/or messages. rgds, tim. # cat proc/version; lspci Linux version 2.2.19pre8+IDE (root@abit) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #8 Thu Feb 22 18:12:29 PST 2001 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0391 (rev 02) 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8391 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) 00:08.0 FireWire (IEEE 1394): Texas Instruments TSB12LV23 OHCI Compliant IEEE-1394 Controller 00:09.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] 00:0b.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) 01:00.0 VGA compatible controller: nVidia Corporation Riva TNT2 Model 64 (rev 11) -- - 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/
Re: clock timer configuration lost error?
Interesting. This is a KA7 with all power management turned off in the latest Abit BIOS. The kernel puts the timer back and life appears happy again Ahhh. The kernel *is* god. Alan Cox wrote: Feb 26 00:19:52 abit kernel: probable hardware bug: clock timer configuration lost - probably a VIA686a. Feb 26 00:19:52 abit kernel: probable hardware bug: restoring chip configuration. Feb 26 00:26:53 abit xntpd[886]: synchronized to 132.239.254.5, stratum=2 ... Small number of VIA 686 boxes randomly jump from 100Hz back to the DOS 18Hz timeout. We dont know if its hardware or maybe APM bios bugs. The kernel puts the timer back and life appears happy again -- - 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/
Re: partition table: chs question
> for partitions not in the first 8gb of a harddisk, what > should the c/h/s start and end value be ? http://www.linuxdoc.org/HOWTO/Large-Disk-HOWTO.html -- - 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/
Re: ide / usb problem
...
> It happens when dma is enabled by hdparm -d1 /dev/hda or when dma is
> enabled automatically by the kernel.
>
> I have an Abit kt7 mb with the kt133 chipset,Athlon 900 , 128MB mem,
> quantum fireball 20G disk, gcc 2-95-2 , glibc 2-2-1.
>
> There are no problems with dma disabled.
>
> I was not sure if the VIA82CXXX option should be set with the via kt133
> chipset , but setting it results in hundreds of
> hda: dma_intr:status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr:error=0x84 { DriveStatusError BadCRC }
> mesages along with the uhci: errors mentioned above.
...
Try passing kernel params (eg- idebus=33 ide0=ata66 ide1=ata6) rather
than relying on hdparm to set up disks.
I'm on 2.2.19pre8 + ide.2.2.18.1221 but same board and cables, zero
errors. Also run a check with nothing but graphics, kbd, disks. KA7
seems to be particularly edgy with some addon cards (ES1370 & Promise
controller in my case) and <300W power (compared to P3B-F).
rgds,
tim
# hdparm -iv /dev/hdc
/dev/hdc:
multcount= 0 (off)
I/O support = 0 (default 16-bit)
unmaskirq= 0 (off)
using_dma= 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead= 8 (on)
geometry = 2501/255/63, sectors = 40188960, start = 0
Model=IBM-DTLA-307020, FwRev=TX3OA50C, SerialNo=YH0YHF45553
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=40188960
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5
# hdparm -tT /dev/hdc
/dev/hdc:
Timing buffer-cache reads: 128 MB in 0.94 seconds =136.17 MB/sec
Timing buffered disk reads: 64 MB in 1.87 seconds = 34.22 MB/sec
# lspci
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0391 (rev
02)
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8391
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev
22)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev
10)
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
(rev 30)
00:08.0 FireWire (IEEE 1394): Texas Instruments TSB12LV23 OHCI Compliant
IEEE-1394 Controller
00:09.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI]
00:0b.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev
20)
01:00.0 VGA compatible controller: nVidia Corporation Riva TNT2 Model 64
(rev 11)
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_IDEDMA_PCI_EXPERIMENTAL=y
CONFIG_BLK_DEV_VIA82CXXX=y
Linux version 2.2.19pre8+IDE (root@abit) (gcc version egcs-2.91.66
19990314/Linux (egcs-1.1.2 release)) #8 Thu Feb 22 18:12:29 PST 2001
USER-provided physical RAM map:
USER: 0009f000 @ (usable)
USER: 1ff0 @ 0010 (usable)
Detected 800062 kHz processor.
ide_setup: idebus=33
ide_setup: ide0=ata66
ide_setup: ide1=ata66
Console: colour VGA+ 80x25
Calibrating delay loop... 1595.80 BogoMIPS
Memory: 517196k/524288k available (1120k kernel code, 412k reserved,
5512k data, 48k init)
Dentry hash table entries: 65536 (order 7, 512k)
Buffer cache hash table entries: 524288 (order 9, 2048k)
Page cache hash table entries: 131072 (order 7, 512k)
CPU: L1 I Cache: 64K L1 D Cache: 64K
CPU: L2 Cache: 512K
CPU: AMD Athlon(tm) Processor stepping 02
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.35a (19990819) Richard Gooch ([EMAIL PROTECTED])
PCI: PCI BIOS revision 2.10 entry at 0xfb4d0
...
Uniform Multi-Platform E-IDE driver Revision: 6.30
ide: Assuming 33MHz system bus speed for PIO modes
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VT 8371
Chipset Core ATA-66
VP_IDE: ATA-66/100 forced bit set (WARNING)!!
Split FIFO Configuration: 8 Primary buffers, threshold = 1/2
8 Second. buffers, threshold = 1/2
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
ide0: VIA Bus-Master (U)DMA Timing Config Success
VP_IDE: ATA-66/100 forced bit set (WARNING)!!
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
ide1: VIA Bus-Master (U)DMA Timing Config Success
hda: IBM-DTLA-307020, ATA DISK drive
hdb: YAMAHA CRW4416E, ATAPI CDROM drive
hdc: IBM-DTLA-307020, ATA DISK drive
hdd: HP COLORADO 20GB, ATAPI TAPE drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: IBM-DTLA-307020, 19623MB w/1916kB Cache, CHS=2501/255/63, UDMA(66)
hdc: IBM-DTLA-307020, 19623MB w/1916kB Cache, CHS=39870/16/63, UDMA(66)
...
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Re: ide / usb problem
...
It happens when dma is enabled by hdparm -d1 /dev/hda or when dma is
enabled automatically by the kernel.
I have an Abit kt7 mb with the kt133 chipset,Athlon 900 , 128MB mem,
quantum fireball 20G disk, gcc 2-95-2 , glibc 2-2-1.
There are no problems with dma disabled.
I was not sure if the VIA82CXXX option should be set with the via kt133
chipset , but setting it results in hundreds of
hda: dma_intr:status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr:error=0x84 { DriveStatusError BadCRC }
mesages along with the uhci: errors mentioned above.
...
Try passing kernel params (eg- idebus=33 ide0=ata66 ide1=ata6) rather
than relying on hdparm to set up disks.
I'm on 2.2.19pre8 + ide.2.2.18.1221 but same board and cables, zero
errors. Also run a check with nothing but graphics, kbd, disks. KA7
seems to be particularly edgy with some addon cards (ES1370 Promise
controller in my case) and 300W power (compared to P3B-F).
rgds,
tim
# hdparm -iv /dev/hdc
/dev/hdc:
multcount= 0 (off)
I/O support = 0 (default 16-bit)
unmaskirq= 0 (off)
using_dma= 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead= 8 (on)
geometry = 2501/255/63, sectors = 40188960, start = 0
Model=IBM-DTLA-307020, FwRev=TX3OA50C, SerialNo=YH0YHF45553
Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=40188960
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5
# hdparm -tT /dev/hdc
/dev/hdc:
Timing buffer-cache reads: 128 MB in 0.94 seconds =136.17 MB/sec
Timing buffered disk reads: 64 MB in 1.87 seconds = 34.22 MB/sec
# lspci
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0391 (rev
02)
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8391
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev
22)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev
10)
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
(rev 30)
00:08.0 FireWire (IEEE 1394): Texas Instruments TSB12LV23 OHCI Compliant
IEEE-1394 Controller
00:09.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI]
00:0b.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev
20)
01:00.0 VGA compatible controller: nVidia Corporation Riva TNT2 Model 64
(rev 11)
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_IDEDMA_PCI_EXPERIMENTAL=y
CONFIG_BLK_DEV_VIA82CXXX=y
Linux version 2.2.19pre8+IDE (root@abit) (gcc version egcs-2.91.66
19990314/Linux (egcs-1.1.2 release)) #8 Thu Feb 22 18:12:29 PST 2001
USER-provided physical RAM map:
USER: 0009f000 @ (usable)
USER: 1ff0 @ 0010 (usable)
Detected 800062 kHz processor.
ide_setup: idebus=33
ide_setup: ide0=ata66
ide_setup: ide1=ata66
Console: colour VGA+ 80x25
Calibrating delay loop... 1595.80 BogoMIPS
Memory: 517196k/524288k available (1120k kernel code, 412k reserved,
5512k data, 48k init)
Dentry hash table entries: 65536 (order 7, 512k)
Buffer cache hash table entries: 524288 (order 9, 2048k)
Page cache hash table entries: 131072 (order 7, 512k)
CPU: L1 I Cache: 64K L1 D Cache: 64K
CPU: L2 Cache: 512K
CPU: AMD Athlon(tm) Processor stepping 02
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.35a (19990819) Richard Gooch ([EMAIL PROTECTED])
PCI: PCI BIOS revision 2.10 entry at 0xfb4d0
...
Uniform Multi-Platform E-IDE driver Revision: 6.30
ide: Assuming 33MHz system bus speed for PIO modes
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VT 8371
Chipset Core ATA-66
VP_IDE: ATA-66/100 forced bit set (WARNING)!!
Split FIFO Configuration: 8 Primary buffers, threshold = 1/2
8 Second. buffers, threshold = 1/2
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
ide0: VIA Bus-Master (U)DMA Timing Config Success
VP_IDE: ATA-66/100 forced bit set (WARNING)!!
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
ide1: VIA Bus-Master (U)DMA Timing Config Success
hda: IBM-DTLA-307020, ATA DISK drive
hdb: YAMAHA CRW4416E, ATAPI CDROM drive
hdc: IBM-DTLA-307020, ATA DISK drive
hdd: HP COLORADO 20GB, ATAPI TAPE drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: IBM-DTLA-307020, 19623MB w/1916kB Cache, CHS=2501/255/63, UDMA(66)
hdc: IBM-DTLA-307020, 19623MB w/1916kB Cache, CHS=39870/16/63, UDMA(66)
...
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Re: partition table: chs question
for partitions not in the first 8gb of a harddisk, what should the c/h/s start and end value be ? http://www.linuxdoc.org/HOWTO/Large-Disk-HOWTO.html -- - 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/
Re: 2.2.17 Lockup and ATA-66/100 forced bit set (WARNING)
> I've enabled the higher performance features for my ATA drive by getting > 2.2.17, applying Andre Hendrick's IDE patch, adding: > append="idebus=66 ide0=ata66" > to lilo.conf. I was told that Alan's patches from here: > should be used. Is this true if I used Andre's patch? Is the warning > message in my bootlog anything to worry about? The board is an ABIT KT7A > w/ KT133A chipset. Alan = kernel, Andre = IDE. 2.2.18 (kernel) + ide.2.2.18.1221 (IDE patch) + 2.2.19pre8 (kernel patch). See samples below. > Also, the machine locked up once (hard, couldn't connect via network). I > am using the Matrox G450 beta driver with XF 4.0.2 though. Maybe that > was the cause? Ensoniq AudioPCI (ES1370) was problematic if I tried to assign IRQ5 on the KA7 (hard trailess lockups, all IRQ's migrated to 10 or 11 regardless of config, digital audio ScreamOfAgony), whereas IRQ 3 worked fine. Similar experiements with Intel chipset boards P3B-F & BP6 suffer no such issues so I assume it's VT82C686/ES1370 specific. Abit KA7, 2.2.19pre8 + ide.2.2.18.1221 -- Linux version 2.2.19pre8+IDE (root@abit) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #6 Tue Feb 20 01:14:30 PST 2001 USER-provided physical RAM map: USER: 0009f000 @ (usable) USER: 1ff0 @ 0010 (usable) Detected 800063 kHz processor. ide_setup: idebus=33 ide_setup: ide0=ata66 ide_setup: ide1=ata66 Console: colour VGA+ 80x25 Calibrating delay loop... 1595.80 BogoMIPS Memory: 517204k/524288k available (1116k kernel code, 412k reserved, 5508k data, 48k init) Dentry hash table entries: 65536 (order 7, 512k) Buffer cache hash table entries: 524288 (order 9, 2048k) Page cache hash table entries: 131072 (order 7, 512k) CPU: L1 I Cache: 64K L1 D Cache: 64K CPU: L2 Cache: 512K CPU: AMD Athlon(tm) Processor stepping 02 Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.35a (19990819) Richard Gooch ([EMAIL PROTECTED]) PCI: PCI BIOS revision 2.10 entry at 0xfb4d0 PCI: Probing PCI hardware ... Uniform Multi-Platform E-IDE driver Revision: 6.30 ide: Assuming 33MHz system bus speed for PIO modes VP_IDE: IDE controller on PCI bus 00 dev 39 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later VT 8371 Chipset Core ATA-66 VP_IDE: ATA-66/100 forced bit set (WARNING)!! Split FIFO Configuration: 8 Primary buffers, threshold = 1/2 8 Second. buffers, threshold = 1/2 ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA ide0: VIA Bus-Master (U)DMA Timing Config Success VP_IDE: ATA-66/100 forced bit set (WARNING)!! ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA ide1: VIA Bus-Master (U)DMA Timing Config Success hda: IBM-DTLA-307020, ATA DISK drive hdb: YAMAHA CRW4416E, ATAPI CDROM drive hdc: IBM-DTLA-307020, ATA DISK drive hdd: HP COLORADO 20GB, ATAPI TAPE drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: IBM-DTLA-307020, 19623MB w/1916kB Cache, CHS=2501/255/63, UDMA(66) hdc: IBM-DTLA-307020, 19623MB w/1916kB Cache, CHS=39870/16/63, UDMA(66) ... # lspci -v 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0391 (rev 02) Flags: bus master, medium devsel, latency 0 Memory at d000 (32-bit, prefetchable) Capabilities: [a0] AGP version 2.0 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8391 (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: d200-d3ff Prefetchable memory behind bridge: d400-d5ff Capabilities: [80] Power Management version 2 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: VIA Technologies, Inc.: Unknown device Flags: bus master, stepping, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at d000 Capabilities: [c0] Power Management version 2 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Flags: medium devsel Capabilities: [68] Power Management version 2 Generic Socket7, 2.2.19pre8 + ide.2.2.18.1221 - Linux version 2.2.19pre8+IDE ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #3 Mon Feb 19 21:07:58 PST 2001 BIOS-provided physical RAM map: BIOS-e820: 0009f000 @ (usable) BIOS-e820: 03f0 @ 0010 (usable) Detected 166405 kHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 331.77 BogoMIPS Memory: 63060k/65536k available (1044k kernel code, 412k reserved, 972k data, 48k init) Dentry hash table
Re: 2.2.17 Lockup and ATA-66/100 forced bit set (WARNING)
I've enabled the higher performance features for my ATA drive by getting 2.2.17, applying Andre Hendrick's IDE patch, adding: append="idebus=66 ide0=ata66" to lilo.conf. I was told that Alan's patches from here: should be used. Is this true if I used Andre's patch? Is the warning message in my bootlog anything to worry about? The board is an ABIT KT7A w/ KT133A chipset. Alan = kernel, Andre = IDE. 2.2.18 (kernel) + ide.2.2.18.1221 (IDE patch) + 2.2.19pre8 (kernel patch). See samples below. Also, the machine locked up once (hard, couldn't connect via network). I am using the Matrox G450 beta driver with XF 4.0.2 though. Maybe that was the cause? Ensoniq AudioPCI (ES1370) was problematic if I tried to assign IRQ5 on the KA7 (hard trailess lockups, all IRQ's migrated to 10 or 11 regardless of config, digital audio ScreamOfAgony), whereas IRQ 3 worked fine. Similar experiements with Intel chipset boards P3B-F BP6 suffer no such issues so I assume it's VT82C686/ES1370 specific. Abit KA7, 2.2.19pre8 + ide.2.2.18.1221 -- Linux version 2.2.19pre8+IDE (root@abit) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #6 Tue Feb 20 01:14:30 PST 2001 USER-provided physical RAM map: USER: 0009f000 @ (usable) USER: 1ff0 @ 0010 (usable) Detected 800063 kHz processor. ide_setup: idebus=33 ide_setup: ide0=ata66 ide_setup: ide1=ata66 Console: colour VGA+ 80x25 Calibrating delay loop... 1595.80 BogoMIPS Memory: 517204k/524288k available (1116k kernel code, 412k reserved, 5508k data, 48k init) Dentry hash table entries: 65536 (order 7, 512k) Buffer cache hash table entries: 524288 (order 9, 2048k) Page cache hash table entries: 131072 (order 7, 512k) CPU: L1 I Cache: 64K L1 D Cache: 64K CPU: L2 Cache: 512K CPU: AMD Athlon(tm) Processor stepping 02 Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.35a (19990819) Richard Gooch ([EMAIL PROTECTED]) PCI: PCI BIOS revision 2.10 entry at 0xfb4d0 PCI: Probing PCI hardware ... Uniform Multi-Platform E-IDE driver Revision: 6.30 ide: Assuming 33MHz system bus speed for PIO modes VP_IDE: IDE controller on PCI bus 00 dev 39 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later VT 8371 Chipset Core ATA-66 VP_IDE: ATA-66/100 forced bit set (WARNING)!! Split FIFO Configuration: 8 Primary buffers, threshold = 1/2 8 Second. buffers, threshold = 1/2 ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA ide0: VIA Bus-Master (U)DMA Timing Config Success VP_IDE: ATA-66/100 forced bit set (WARNING)!! ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA ide1: VIA Bus-Master (U)DMA Timing Config Success hda: IBM-DTLA-307020, ATA DISK drive hdb: YAMAHA CRW4416E, ATAPI CDROM drive hdc: IBM-DTLA-307020, ATA DISK drive hdd: HP COLORADO 20GB, ATAPI TAPE drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: IBM-DTLA-307020, 19623MB w/1916kB Cache, CHS=2501/255/63, UDMA(66) hdc: IBM-DTLA-307020, 19623MB w/1916kB Cache, CHS=39870/16/63, UDMA(66) ... # lspci -v 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0391 (rev 02) Flags: bus master, medium devsel, latency 0 Memory at d000 (32-bit, prefetchable) Capabilities: [a0] AGP version 2.0 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8391 (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: d200-d3ff Prefetchable memory behind bridge: d400-d5ff Capabilities: [80] Power Management version 2 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: VIA Technologies, Inc.: Unknown device Flags: bus master, stepping, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at d000 Capabilities: [c0] Power Management version 2 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Flags: medium devsel Capabilities: [68] Power Management version 2 Generic Socket7, 2.2.19pre8 + ide.2.2.18.1221 - Linux version 2.2.19pre8+IDE ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #3 Mon Feb 19 21:07:58 PST 2001 BIOS-provided physical RAM map: BIOS-e820: 0009f000 @ (usable) BIOS-e820: 03f0 @ 0010 (usable) Detected 166405 kHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 331.77 BogoMIPS Memory: 63060k/65536k available (1044k kernel code, 412k reserved, 972k data, 48k init) Dentry hash table entries: 8192
via82cxxx.c,v 3.17 + 2.2.18 errors
Is via82cxxx.c v3.17 a 2.4.x only patch or did I miss something else?
[tim@asus linux]# ../build
dep ===
clean ===
bzImage ===
via82cxxx.c:108: `PCI_DEVICE_ID_VIA_8233_0' undeclared here (not in a
function)
via82cxxx.c:108: initializer element for `via_isa_bridges[0].id' is not
constant
via82cxxx.c:114: `PCI_DEVICE_ID_VIA_82C596' undeclared here (not in a
function)
via82cxxx.c:114: initializer element for `via_isa_bridges[6].id' is not
constant
via82cxxx.c:115: `PCI_DEVICE_ID_VIA_82C596' undeclared here (not in a
function)
via82cxxx.c:115: initializer element for `via_isa_bridges[7].id' is not
constant
via82cxxx.c:116: `PCI_DEVICE_ID_VIA_82C596' undeclared here (not in a
function)
via82cxxx.c:116: initializer element for `via_isa_bridges[8].id' is not
constant
via82cxxx.c: In function `pci_init_via82cxxx':
via82cxxx.c:486: warning: implicit declaration of function
`pci_resource_flags'
via82cxxx.c:486: `IORESOURCE_IO' undeclared (first use in this function)
via82cxxx.c:486: (Each undeclared identifier is reported only once
via82cxxx.c:486: for each function it appears in.)
via82cxxx.c:489: warning: implicit declaration of function
`pci_resource_start'
make[3]: *** [via82cxxx.o] Error 1
make[2]: *** [first_rule] Error 2
make[1]: *** [_subdir_block] Error 2
make: *** [_dir_drivers] Error 2
make: *** Waiting for unfinished jobs
Command exited with non-zero status 2
[tim@asus linux]# grep Id drivers/block/{via*.c,ide-timing.h}
drivers/block/via82cxxx.c: * $Id: via82cxxx.c,v 3.17 2001/01/19 16:45:60
vojtech Exp $
drivers/block/ide-timing.h: * $Id: ide-timing.h,v 1.5 2001/01/15
21:48:56 vojtech Exp $
[tim@asus 2.2]# cat /proc/version
Linux version 2.2.18RAID+IDE (root@asus) (gcc version egcs-2.91.66
19990314/Linux (egcs-1.1.2 release)) #9 Fri Jan 26 14:16:15 PST 2001
Note: pristine + ide.2.2.18.1221 + raid-2.2.18-B0
[tim@asus 2.2]# lspci
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0391 (rev
02)
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8391
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev
22)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev
10)
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
(rev 30)
00:09.0 FireWire (IEEE 1394): Texas Instruments TSB12LV23 OHCI Compliant
IEEE-1394 Controller
00:0b.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI]
00:0f.0 RAID bus controller: Promise Technology, Inc. 20246 (rev 01)
00:11.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev
20)
01:00.0 VGA compatible controller: nVidia Corporation Riva TNT2 Model 64
(rev 11)
[tim@asus 2.2]# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 2
model name : AMD Athlon(tm) Processor
stepping: 2
cpu MHz : 800.065
cache size : 512 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmxext mmx fxsr 3dnowext 3dnow
bogomips: 1595.80
--
-
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/
via82cxxx.c,v 3.17 + 2.2.18 errors
Is via82cxxx.c v3.17 a 2.4.x only patch or did I miss something else?
[tim@asus linux]# ../build
dep ===
clean ===
bzImage ===
via82cxxx.c:108: `PCI_DEVICE_ID_VIA_8233_0' undeclared here (not in a
function)
via82cxxx.c:108: initializer element for `via_isa_bridges[0].id' is not
constant
via82cxxx.c:114: `PCI_DEVICE_ID_VIA_82C596' undeclared here (not in a
function)
via82cxxx.c:114: initializer element for `via_isa_bridges[6].id' is not
constant
via82cxxx.c:115: `PCI_DEVICE_ID_VIA_82C596' undeclared here (not in a
function)
via82cxxx.c:115: initializer element for `via_isa_bridges[7].id' is not
constant
via82cxxx.c:116: `PCI_DEVICE_ID_VIA_82C596' undeclared here (not in a
function)
via82cxxx.c:116: initializer element for `via_isa_bridges[8].id' is not
constant
via82cxxx.c: In function `pci_init_via82cxxx':
via82cxxx.c:486: warning: implicit declaration of function
`pci_resource_flags'
via82cxxx.c:486: `IORESOURCE_IO' undeclared (first use in this function)
via82cxxx.c:486: (Each undeclared identifier is reported only once
via82cxxx.c:486: for each function it appears in.)
via82cxxx.c:489: warning: implicit declaration of function
`pci_resource_start'
make[3]: *** [via82cxxx.o] Error 1
make[2]: *** [first_rule] Error 2
make[1]: *** [_subdir_block] Error 2
make: *** [_dir_drivers] Error 2
make: *** Waiting for unfinished jobs
Command exited with non-zero status 2
[tim@asus linux]# grep Id drivers/block/{via*.c,ide-timing.h}
drivers/block/via82cxxx.c: * $Id: via82cxxx.c,v 3.17 2001/01/19 16:45:60
vojtech Exp $
drivers/block/ide-timing.h: * $Id: ide-timing.h,v 1.5 2001/01/15
21:48:56 vojtech Exp $
[tim@asus 2.2]# cat /proc/version
Linux version 2.2.18RAID+IDE (root@asus) (gcc version egcs-2.91.66
19990314/Linux (egcs-1.1.2 release)) #9 Fri Jan 26 14:16:15 PST 2001
Note: pristine + ide.2.2.18.1221 + raid-2.2.18-B0
[tim@asus 2.2]# lspci
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0391 (rev
02)
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8391
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev
22)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev
10)
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
(rev 30)
00:09.0 FireWire (IEEE 1394): Texas Instruments TSB12LV23 OHCI Compliant
IEEE-1394 Controller
00:0b.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI]
00:0f.0 RAID bus controller: Promise Technology, Inc. 20246 (rev 01)
00:11.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev
20)
01:00.0 VGA compatible controller: nVidia Corporation Riva TNT2 Model 64
(rev 11)
[tim@asus 2.2]# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 2
model name : AMD Athlon(tm) Processor
stepping: 2
cpu MHz : 800.065
cache size : 512 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmxext mmx fxsr 3dnowext 3dnow
bogomips: 1595.80
--
-
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: 2.2.18 and mkraid
> What version of the raidtools to I need for 2.2.18 software raid? > Documentation/md.txt has a non-functional URL in it. 0.90 http://www.kernel.org/pub/linux/kernel/people/mingo/raid-patches/ http://www.kernel.org/pub/linux/daemons/raid/alpha/ -- | Work like you don't need the money. Love like you've never been hurt. Dance like nobody's watching. - 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: 2.2.18 and mkraid
What version of the raidtools to I need for 2.2.18 software raid? Documentation/md.txt has a non-functional URL in it. 0.90 http://www.kernel.org/pub/linux/kernel/people/mingo/raid-patches/ http://www.kernel.org/pub/linux/daemons/raid/alpha/ -- | Work like you don't need the money. Love like you've never been hurt. Dance like nobody's watching. - 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/
