RE: aic7xxx (and sym53c8xx) plans
I must say, after I saw this post, I tried out the latest driver for my own purposes. This really improved the performance of my dual PIII-866 w/512MB Ram and AIC7899 scsi. I have a couple of cheetah drives that I am writing data that I get off of an ATM card.(about 12-14 MB/sec rate). This has significantly lowered the number of dropped packets on the ATM read. I would suggest, if at all possible, putting this in the 2.4.2 kernel. Nathan -Original Message- From: Chip Salzenberg [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 14, 2001 9:20 PM To: Matthew Jacob Cc: Wakko Warner; Alan Cox; J . A . Magallon; linux-kernel Subject: Re: aic7xxx (and sym53c8xx) plans According to Matthew Jacob: > See http://www.freebsd.org/~gibbs/linux. Here at VA we're already using Jason's driver -- it works on the Intel STL2 motherboard, while Doug's driver doesn't (or didn't, a month ago). While we're discussing SCSI drivers, I'd also like to put in a good word for the Sym-2 Symbios/NCR drivers from Gerard Roudier: ftp://ftp.tux.org/roudier/drivers/portable/sym-2.1.x/ Joe-Bob says: "Check it out." -- Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]> "Give me immortality, or give me death!" // Firesign Theatre - 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/ - 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: aic7xxx (and sym53c8xx) plans
Actuall, I have tried it on a few machines now. It "seems" to work very reliable with a 2940UW card, AIC 7890 chip, and a 2940U2W Card that I have on my machines.(obviously these are all different machines). Nathan -Original Message- From: Peter Samuelson [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 17, 2001 7:06 PM To: Nathan Black Cc: [EMAIL PROTECTED] Subject: Re: aic7xxx (and sym53c8xx) plans [Nathan Black] > This really improved the performance of my dual PIII-866 w/512MB Ram > and AIC7899 scsi. [...] > I would suggest, if at all possible, putting this in the 2.4.2 > kernel. Have you any idea the breadth of cards and chips that aic7xxx supports? Sure, Justin's driver does great with your shiny new 7899, but can you verify that it also drives the 8-year-old EISA AHA-2740 I still have sitting around (actually retired to the parts pile, but that's beside the point, I'm sure some still exist in the wild)? How about the VLB card I have in my 486 at home? IMHO there is no way Linus should consider replacing aic7xxx with 6.1 in a stable kernel. Not until it has gotten as much testing on as much obscure hardware as the old driver, which is not going to happen soon. Breaking existing working setups in 2.4.x is not an option. Possible solution: let the two drivers coexist, like ncr53c8xx vs sym53c8xx or tulip vs old_tulip. Peter - 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: PROBLEM- Segmentation fault occurs when dd'ing entire drive (9.x GB) to a vfat partition.
This is NOT a dd problem. I have been trying to write large files to a vfat filesystem. This is definitely a bug with the kernel. I have had the seg fault. Try running the program again, but look at your console. It think that it will result in a kernel bug statement.I think that mine said it was in File.c:89 . Nathan P.S. I was trying to capture atm data on the partition. The code I am using works great with an ext2fs partition, but the vfat dies at exactly the same place. -Original Message- From: Cappellini, Tony [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 28, 2001 4:09 PM To: '[EMAIL PROTECTED]' Subject: PROBLEM- Segmentation fault occurs when dd'ing entire drive (9.x GB) to a vfat partition. Importance: High Hello I am submitting this bug report. I've attached a file which I hope contains all of the approppriate information. Is it possible for someone to let me know if/when this problem is fixed ? Thanks Tony Cappellini Maxtor Corporation - 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/
Hardware problem detection? Linux 2.4.3-pre4 lockups.
I am at a total loss, But I have found some interesting anomalies with my hardware. My Current Setup: Supermicro S370DE6 (Serverworks Chipset) Dual PIII 866 2 x 256 MB PC133 ECC SDRAM onboard AIC 7899 SCSI Controller. 36G,73GB Seagate Cheetah Drive. Voodoo4 4500 AGP video, Fore PCA 200e ATM Problem, I have a program the can read a file(large, or small) it will then transmit the data over atm, ethernet, localhost,or write to a file. I have noticed that the machine will consistently crash(hard lockup) when I do a read loop of the File. It never locks up at the same place, and I have changed it so that it never actually does anything with the data after it reads. Still, same result. Things that have "fixed" the problem. Setting the FSB to 100(jumpered) will allow me to run forever. Also, Setting the L1 Cache to Write-through instead of write back will allow me to run forever at 133, but the performance hit is worse than setting the FSB to 100. Another note. When I have attempted to compile the kernel for Uni processor. I started getting segmentation faults with gcc. Now this tells me it might be the processor. But I have nothing overclocked, so I would think that it might be some kind of timing issue in the kernel. I have two machines set up this way. One is much more stable. But I do observe the occasional crash.(hard lockup) I have also seen fsck crash as well. when the system was not shut down correctly. ( as a hard lockup happens very frequently.) Here are some things that I have tried, but Have not fixed it. 1) SMP Kernel with "noapic" at lilo prompt ( and without the noapic) 2) Uni Kernel w/ & w/out apic I am at a total loss. Is there anything I can do(other than run at 100 FSB)? Nathan P.S. I have enclosed the dmesg output for my Uniprocessor kernel <> dmesg.out.uni
RE: No SCSI Ultra 160 with Adaptec Controller
What problem are you trying to solve, I just joined the group in hopes of finding a solution to a problem of mine. It sounds like they may be related. I am trying to write to a drive(raw, blank, whatever you want to call it) on kernel 2.4.1-pre10. I get great throughput at first, but then it slows to about 25 MB/sec. This isn't a problem except after writing a large amount of data, the system becomes unusable. I did not say it halts, oops, or anything like that, just extremely slow. ps takes about 10 minutes or more to complete.(4 tasks). I have a compaq smart array controller 2. Before I upgraded the kernel( I was at 2.4.0 released). I would get an oops. and a kernel panic/halt. I did see that running in uniprocessor mode with NMIs turned off would let me write without problems, but I was never sure how to fix it. Any ideas? -Original Message- From: Tom Sightler [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 24, 2001 3:08 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: No SCSI Ultra 160 with Adaptec Controller > Actually, aren't a number of newer drives getting upwards of 30MB/s? > Well, at 80MB/sec these drives are able to come in at an average of about 34MB/s across the board. > > Therefore, you only exceed the 80MB/sec bus speed if you > > have more than 4 disks all doing maximum I/O at the same time. Since the > > PowerApp.web 100 has at most 2 disks internally, you really shouldn't see > > any significant performance difference. I wouldn't dare argue that I'd get some huge performance boost, but I am running software raid1 on multiple spindles (we have some drives attached externally) so it should help some. Also, this unit is doing heavy read/write of small files and the lower latency, and burstable transfers do help some. I temporarily disabled that code and the increase in IO's per second is measurable, though not earth shattering, but I was afraid to leave it that way because fast corrupted data is worth much less that only slightly slower good data. It was really just an issue of if the code still needed to be there. Workarounds that are put in as temporary have a tendency to never get revisited until someone brings them up, and on top of that they make Linux look sloppy to me (the same drives work correctly at Ultra160 under that other OS, or at least appear to). I know it won't make a huge difference to me, but if some user has a 12 disk RAID array full of Quantum disks it will make a big difference to them. Later, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Bolck Device problem or Compaq Smart array 2 problem? kernel -2.4.0+
Here is my scenario. I have a smart array controller 2. I have 6 logical drives( one on it's own physical drive). I am using the one drive for data aquisition from an atm board. To locate my problem, I removed all of the atm stuff. and I am trying just a read/write. Both show the same symptoms. I have tried many different kernels. Here are my results. 2.2.18- works fine. 24 MBytes/sec at 100+ gigabytes (16GB looped many times ( lseek64(FD,SEEK_SET,0) )). 2.4.0 release SMP and Uniprocessor with NMI on- Kernel oops. I can reproduce if necessary( oops at about 700 MB) sometimes more, sometime less. (In BDFLUSH if I recall) 2.4.0 release UniProcessor NMI off- Works like the 2.2.18 2.4.1-pre10 & 11- Works but system becomes unusable(requires reboot) after completing. Here is my setup. Compaq Proliant 8500R 4GB Ram 4 Hot Swap 18GB hard disk. Compaq Smart Array Controller Linksys Network(10/100 BT) card 8 PIII Xeon w/ 2MB cache Processors. egcs-2.91.66 redhat 6.2 distribution I do have a 512 MB swap partition I am including the code that I have been playing with. It looks very ugly, but I have tried just about everything I could without going in and trying to learn how the kernel is written. I am including the source code for the block write device. and the kernel configuration from 2.4.1-pre11. Has anyone else see this problem. I have tried to write a file to on the filesystem. Looks like a similar problem. Nathan <> <> write.cpp kernel-2.4.1-pre11-config
RE: Bolck Device problem or Compaq Smart array 2 problem? kernel -2.4 .0+
It comes back with a command prompt. trying a "simple command... ps, ls it does not return. The hard disks(hardware raid) light up. But it seems like noone is home. It doesn't oops in the 2.4.1-pre11 or 10. That is a good thing. -Original Message- From: Jens Axboe [mailto:[EMAIL PROTECTED]] Sent: Monday, January 29, 2001 11:38 AM To: Nathan Black Cc: [EMAIL PROTECTED] Subject: Re: Bolck Device problem or Compaq Smart array 2 problem? kernel -2.4 .0+ On Mon, Jan 29 2001, Nathan Black wrote: > Here are my results. > > 2.2.18- works fine. 24 MBytes/sec at 100+ gigabytes (16GB looped many times > ( lseek64(FD,SEEK_SET,0) )). > > 2.4.0 release SMP and Uniprocessor with NMI on- Kernel oops. I can reproduce > if necessary( oops at about 700 MB) sometimes more, sometime less. (In > BDFLUSH if I recall) > > 2.4.0 release UniProcessor NMI off- Works like the 2.2.18 > > 2.4.1-pre10 & 11- Works but system becomes unusable(requires reboot) after > completing. Unusable how? Does it hang or oops? Does nmi and up/smp make any differences in 2.4.1-preXX? I did some fixes for cpq after the blk merge in 2.4.1-pre, and got reports that it works. However, I don't have the necessary hardware to test myself. -- Jens Axboe - 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: Bolck Device problem or Compaq Smart array 2 problem? kernel -2.4 .0+
I do have all of the raid stuff set up as hardware raid. I am using the latest bios( have it set up for linux). Unfortunately, I do not (yet) have another machine to test this out on to see if it is a block device problem. or strictly limited to the compaq. I should be getting another machine with an adaptec scsi 160 to see if that behaves better. Nathan -Original Message- From: Dr. Michael Weller [mailto:[EMAIL PROTECTED]] Sent: Monday, January 29, 2001 11:39 AM To: Nathan Black Cc: [EMAIL PROTECTED] Subject: Re: Bolck Device problem or Compaq Smart array 2 problem? kernel -2.4 .0+ On Mon, 29 Jan 2001, Nathan Black wrote: > > Here is my scenario. I have a smart array controller 2. I have 6 logical > drives( one on it's own physical drive). I am using the one drive for data > aquisition from an atm board. To locate my problem, I removed all of the atm > stuff. and I am trying just a read/write. Both show the same symptoms. I > have tried many different kernels. > > Here are my results. > > 2.2.18- works fine. 24 MBytes/sec at 100+ gigabytes (16GB looped many times > ( lseek64(FD,SEEK_SET,0) )). > > 2.4.0 release SMP and Uniprocessor with NMI on- Kernel oops. I can reproduce > if necessary( oops at about 700 MB) sometimes more, sometime less. (In > BDFLUSH if I recall) > > 2.4.0 release UniProcessor NMI off- Works like the 2.2.18 Esp. for SMP problems (that is running on an SMP machine). Proper setup of the board, the APIC and what else is mandatory. For the Proliant, you should check the operating system setting with the compaq setup tool/diagnosis. Definitely first upgrade all firmware to the latest release... The new releases usually already support the setting: linux. However, private experience: DOS/other -- works, but UP only, linux -- only on new machines, one case known where it doesn't work. Windows NT -- known not to work on old machines, but works in above case where linux doesn't. Unixware (v7?) -- some SMP unix, works on old machines, again doesn't work on some new hardware. So, you might have to try several settings. Even if 2.2.18 works, 2.4's setup might need other, better hardware initialisation. If this doesn't help (or you knew about it and just didn't mention it). I'd more think about hardware/CPU (esp. SMP setup)/memory problems. I don't see the raid adapter affected here. If all this doesn't help, you might want to contact Compaq, they are recently very helpful to resolve such issues. How do lesser CPU's work? -- Michael Weller: [EMAIL PROTECTED], [EMAIL PROTECTED], or even [EMAIL PROTECTED] If you encounter an eowmob account on any machine in the net, it's very likely it's me. - 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/
drive/block device write scheduling, buffer flushing?
I was wondering if there is a way to make the kernel write to disk faster. I need to maintain a 10 MB /sec write rate to a 10K scsi disk in a computer, but it caches and doesn't start writing to disk until I hit about 700 MB. At that point, it pauses(presumably while the kernel is flushing some of the buffers) and I will have missed data that I am trying to capture. Any ideas? Nathan - 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: drive/block device write scheduling, buffer flushing?
That is what I wanted to do...Write directly to the disk. But the kernel(2.4.1) is caching the io... -Original Message- From: bert hubert [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 31, 2001 12:51 PM To: Nathan Black Cc: [EMAIL PROTECTED] Subject: Re: drive/block device write scheduling, buffer flushing? On Wed, Jan 31, 2001 at 11:52:25AM -0500, Nathan Black wrote: > I was wondering if there is a way to make the kernel write to disk faster. > I need to maintain a 10 MB /sec write rate to a 10K scsi disk in a computer, > but it caches and doesn't start writing to disk until I hit about 700 MB. At > that point, it pauses(presumably while the kernel is flushing some of the > buffers) and I will have missed data that I am trying to capture. try opening with O_SYNC, or call fsync() every once in a while. Otherwise, this sounds like an application for a raw device, whereby you can write directly to the disk, with no caching in between. Regards, bert -- PowerDNS Versatile DNS Services Trilab The Technology People 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet - 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: rawio usage
need 512 byte alignment
i.e.
change
char writeBuf[512];
to:
char writeBuf[1023];
writeBuf = (char *)(((int )&writeBuf[0] + 511) &~511);
This will typecast the writeBuffer address to an int and add 511 to the
address. When you and that with ~511( invert 511). That will result int
something in a multiple of 512 for the address.
Then just typecast it back.
That is how to align it. Jens Was kind enough to tell me how to do this.
Nathan
-Original Message-
From: Mayank Vasa [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 06, 2001 1:37 AM
To: Linux-Kernel
Subject: rawio usage
Hi,
I am quite new to rawio and am experimenting with with its usage. My test
environment is Redhat 7.0, kernel version 2.2.16-22 having an external fibre
channel drive having 2 disks (/dev/sda1 and /dev/sdb1)
All I am trying to do is to write and read to & from the disk using a raw
device. Externally I did a "raw /dev/raw/raw1 /dev/sdb1" and then I wrote a
small program to do the read/write. The program is:
#include
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char *argv[])
{
int fd;
char writeBuf[512];
char readBuf[100];
memset(readBuf, '\0', 100);
memset(writeBuf, '\0', 100);
memcpy(writeBuf, "This is a test", 14);
printf("writeBuf = %s\n", writeBuf);
fd = open(argv[1], O_RDWR);
if (fd < 0) {
perror("open");
exit (1);
}
if ((lseek(fd, 0L, 0)) < 0){
perror("lseek");
exit (1);
}
if ((write(fd, writeBuf, 512)) < 0) {
printf ("errno = %d\n", errno);
perror("write");
exit(1);
}
lseek(fd, 0L, 0);
if ((read(fd, readBuf, 512)) < 0) {
perror("read");
exit(1);
}
printf("The readbuf is %s\n", readBuf);
return 0;
}
When I run this program as root, I get the error "write: Invalid argument".
It is basically returning errno = 22 which is EINVAL and as per the write
manpage means that fd is attached to an object which is unsuitable for
writing.
Could someone guide me on where I am going wrong & how to use raw devices?
--
Mayank Vasa
Confluence Networks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
