src-test2/sys/dev, branch stable/4

Add tested known good version of Areca SATA RAID driver (arcmsr) working

2014-04-30T05:59:31Z

in stable/4. An MFC of slightly later code than that of r144411 (scottl). This is a direct commit to stable/4. Obtained from: Erich Chen

MFC: r179705

2008-06-10T18:51:05Z

Add support for the P212, P410, P410i, P411, and P812 HP Smart Array controllers.

Add the missing support for the P800

2008-06-10T18:50:14Z

MFC: rev 1.88

2008-05-19T19:21:14Z

Remove a check that didn't allow > 12 byte CDB's to be issued to ciss. This should allow volumes > 2TB to work.

Fix pointy-hat problem with BUS_DMA_ROOTARG macro that caused problems for sparc64.

2007-05-11T06:29:23Z

MFC rev 1.5: Add PCI Ids

2007-05-09T17:33:00Z

MFC to synchronize with -current. The bugs fixed are relatively few and

2007-05-08T17:47:08Z

hopefully the bugs introduved are even fewer.

EOL of RELENG_4 support.

2007-04-01T17:22:03Z

MFC of constification, cleanups of pre-7.X compiles, additions of SYNC_REG memory barriers and so on.

This commit was manufactured by cvs2svn to create branch 'RELENG_4'.

2007-03-10T02:39:55Z

MFC (if_bge.c 1.108, etc., less some style bugs: eliminate one PCI

2007-02-15T10:33:49Z

read per call to bge_start()). In packet blasting tests using ttcp with tiny udp packets on an A64-3200 with a 64-bit 5701 on a 32-bit 33MHz PCI bus, this gives a speedup from 347 kpps to 623 kpps. sendto() has a lot of software overheads, but even with these the single PCI write per call to bge_start() almost doubled the per-packet time. This is partly because the software overheads are so large that the CPU can't keep up with a Gbps NIC that can actually get anywhere near Gbps speed for tiny packets (347 kppps for tiny packets is only about 21% of wire speed). When the CPU can't keep up, it gets further behind because it ends up calling bge_start() at least once for every packet, so any overheads in bge_start() are not amortized across multiple packets. Thus the PCI read had an especially high overhead. For larger packets, the speedup is closer to the 1.8% claimed in rev. 1.108. Rev.1.108 claims to eliminate a PCI write but actually eliminates a PCI read. The write of the tx product index is not so costly as its read, and cannot be eliminated completely. It could be coalesced in some cases.